November 2015 - kernelnewbies@kernelnewbies.org

[PATCH v4 0/4] SysFS driver for QEMU fw_cfg device
by Gabriel L. Somlo Nov. 14, 2015

Nov. 14, 2015

From: "Gabriel Somlo" <somlo(a)cmu.edu> Allow access to QEMU firmware blobs, passed into the guest VM via the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, size, and fw_cfg key), as well as the raw binary blob data may be accessed. The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was selected based on overall similarity to the type of information exposed under /sys/firmware/dmi/entries/... New (since v3): Patch 1/4: Device probing now works with either ACPI, DT, or optionally by manually specifying a base, size, and register offsets on the command line. This way, all architectures offering fw_cfg can be supported, although x86 and ARM get *automatic* support via ACPI and/or DT. HUGE thanks to Laszlo Ersek <lersek(a)redhat.com> for pointing out drivers/virtio/virtio_mmio.c, as an example on how to pull this off !!! Stefan: I saw Marc's DMA patches to fw_cfg. Since only x86 and ARM will support it starting with QEMU 2.5, and since I expect to get lots of otherwise interesting (but otherwise orthogonal) feedback on this series, I'd like to stick with ioread8() across the board for now. We can always patch in DMA support in a backward compatible way later, once this series gets (hopefully) accepted :) Patch 2/4: (was 3/4 in v3): unchanged. Exports kset_find_obj() so modules can call it. Patch 3/4: (was 4/4 in v3): rebased, but otherwise the same. Essentially, creates a "human readable" directory hierarchy from "path-like" tokens making up fw_cfg blob names. I'm not really sure there's a way to make this happen via udev rules, but I have at least one potential use case for doing it *before* udev becomes available (cc: Andy Lutomirski <luto(a)amacapital.net>), so I'd be happy to leave this functionality in the kernel module. See further below for an illustration of this. Patch 4/4: Updates the existing ARM DT documentation for fw_cfg, mainly by pointing at the more comprehensive document introduced with Patch 1/4 for details on the fw_cfg device interface, leaving only the specific ARM/DT address/size node information in place. Thanks much, --Gabriel > In addition to the "by_key" blob listing, e.g.: > > $ tree /sys/firmware/qemu_fw_cfg/ > /sys/firmware/qemu_fw_cfg/ > |-- by_key > | |-- 32 > | | |-- key > | | |-- name ("etc/boot-fail-wait") > | | |-- raw > | | `-- size > | |-- 33 > | | |-- key > | | |-- name ("etc/smbios/smbios-tables") > | | |-- raw > | | `-- size > | |-- 34 > | | |-- key > | | |-- name ("etc/smbios/smbios-anchor") > | | |-- raw > | | `-- size > | |-- 35 > | | |-- key > | | |-- name ("etc/e820") > | | |-- raw > | | `-- size > | |-- 36 > | | |-- key > | | |-- name ("genroms/kvmvapic.bin") > | | |-- raw > | | `-- size > | |-- 37 > | | |-- key > | | |-- name ("etc/system-states") > | | |-- raw > | | `-- size > | |-- 38 > | | |-- key > | | |-- name ("etc/acpi/tables") > | | |-- raw > | | `-- size > | |-- 39 > | | |-- key > | | |-- name ("etc/table-loader") > | | |-- raw > | | `-- size > | |-- 40 > | | |-- key > | | |-- name ("etc/tpm/log") > | | |-- raw > | | `-- size > | |-- 41 > | | |-- key > | | |-- name ("etc/acpi/rsdp") > | | |-- raw > | | `-- size > | `-- 42 > | |-- key > | |-- name ("bootorder") > | |-- raw > | `-- size > | > ... > > Patch 3/4 also gets us a "human readable" "by_name" listing, like so: > > ... > |-- by_name > | |-- bootorder -> ../by_key/42 > | |-- etc > | | |-- acpi > | | | |-- rsdp -> ../../../by_key/41 > | | | `-- tables -> ../../../by_key/38 > | | |-- boot-fail-wait -> ../../by_key/32 > | | |-- e820 -> ../../by_key/35 > | | |-- smbios > | | | |-- smbios-anchor -> ../../../by_key/34 > | | | `-- smbios-tables -> ../../../by_key/33 > | | |-- system-states -> ../../by_key/37 > | | |-- table-loader -> ../../by_key/39 > | | `-- tpm > | | `-- log -> ../../../by_key/40 > | `-- genroms > | `-- kvmvapic.bin -> ../../by_key/36 > `-- rev Gabriel Somlo (4): firmware: introduce sysfs driver for QEMU's fw_cfg device kobject: export kset_find_obj() for module use firmware: create directory hierarchy for sysfs fw_cfg entries devicetree: update documentation for fw_cfg ARM bindings .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 240 +++++++ Documentation/devicetree/bindings/arm/fw-cfg.txt | 37 +- drivers/firmware/Kconfig | 19 + drivers/firmware/Makefile | 1 + drivers/firmware/qemu_fw_cfg.c | 714 +++++++++++++++++++++ lib/kobject.c | 1 + 6 files changed, 977 insertions(+), 35 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg create mode 100644 drivers/firmware/qemu_fw_cfg.c -- 2.4.3

1 2

is there a reason "usbhid.quirks" parameter is not root writable?
by Robert P. J. Day Nov. 13, 2015

Nov. 13, 2015

short form: is there some reason that the usbhid "quirks" parameter is not by default compiled to be writable in case you wanted to adjust those values on a running system? long form: i have a USB device that, sadly, is automatically claimed by the usbhid driver upon insertion, and i want to prevent that so it behaves as a regular USB device. from what i've read, the solution is to, at boot time, add the kernel command line parameter: usbhid.quirks=0x2123:0x1010:0x04 that's fine if i want to reboot so that that takes effect, but it would of course be convenient if i could add that info to /sys/module/usbhid/parameters/quirks at run-time. currently, on my fedora 22 system: $ cat /sys/module/usbhid/parameters/quirks (null),(null),(null),(null) $ with permissions: $ ls -l /sys/module/usbhid/parameters/quirks -r--r--r--. 1 root root 4096 Nov 12 02:41 /sys/module/usbhid/parameters/quirks $ and i can see in drivers/hid/usbhid/hid-core.c the fact that that array is defined as non-writable: /* Quirks specified at module load time */ static char *quirks_param[MAX_USBHID_BOOT_QUIRKS]; module_param_array_named(quirks, quirks_param, charp, NULL, 0444); MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying " " quirks=vendorID:productID:quirks" " where vendorID, productID, and quirks are all in" " 0x-prefixed hex"); so the obvious(?) question is, is there some reason that that parameter is defined as read-only rather than, say, writable by root? would it not be useful to be able to modify that parameter at run-time? or is there something about that parameter for which that would be a really bad idea? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

4 6

Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
by Greg KH Nov. 12, 2015

Nov. 12, 2015

On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > > -----Original Message----- > > From: Greg KH [mailto:greg@kroah.com] > > Sent: Friday, September 25, 2015 2:37 PM > > To: Rob Groner <rgroner(a)RTD.com> > > Cc: Valdis.Kletnieks(a)vt.edu; kernelnewbies(a)kernelnewbies.org > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > > > > > -----Original Message----- > > > > From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > > > > Sent: Friday, September 25, 2015 12:48 PM > > > > To: Rob Groner <rgroner(a)RTD.com> > > > > Cc: kernelnewbies(a)kernelnewbies.org > > > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > > > > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > > > Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > > > extra capabilities of the Exar-provided driver to allow > > > > > configuration of the board. When support for the Exar chip was > > > > > added to the kernel 8250_pci driver, this then prevented easy use > > > > > of the board by customers for anything other than standard serial usage > > in RS232 mode. > > > > > > > > Was it your intent to also prevent the use of this board in standard > > > > serial usage in RS232 mode (which I'd expect is the most common use > > case)? > > > > > > That is a byproduct of giving the non-average user the ability to > > > reconfigure their board. This will basically move us back to pre-3.8, > > > where the customer would simply have to insmod the provided Exar > > > driver. The small inconvenience to that more common user seems (to us > > > in Tech Support) outweighed by the much greater inconvenience to the > > > user who wants to reconfigure. > > > > Where is the exar driver, in the kernel already? > > > > confused, > > I'm sorry for the confusion. Let me summup: > > We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). > > Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. > > Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. > > The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. Can you point me at the driver and I'll be glad to add it to the kernel so that the proper driver will bind to the device and this will not be an issue for users? thanks, greg k-h

4 14

staging: wlan-ng: p80211conv.h: warning I don't understand
by Gavin O'Leary Nov. 12, 2015

Nov. 12, 2015

Hello all, I am new to the realm of linux kernel development. I've been sending in small patches to fix check-patch warnings. I was fixing up the file listed in the subject when I came across this warning. drivers/staging/wlan-ng/p80211conv.c:622: WARNING: Possible unnecessary 'out of memory' message Source Code: if (rxmeta == NULL) { netdev_err(wlandev->netdev, "%s: Failed to allocate rxmeta.\n", wlandev->name); result = 1; goto exit; } What is this warning about? How do I go about fixing it? Thank you, --Gavin

4 4

spi_async inside IRQ handler and spin_(un)lock_irq* doubt.
by Daniel. Nov. 11, 2015

Nov. 11, 2015

Hi everybody! I'm using an gpio expansion called MCP23s17 from Microchip as a digital input device. There are 6 input ports at my device. The MCP is configured to generate an interrupt at input state change (from 0 to 1, or 1 to 0, what ever), the interrupts are disabled on MCP until the INTCAP register is readed. This register holds a byte where each bit represent the input port state at interrupt time. So my code does like this: #1 An interrupt ocurred #2 I initialize a spi_message to get INTCAP and fires a spi_async_locked. #3 The SPI core do its stuff #4 The complete callback is called. It gets the INTCAP value and put it on a circular queue to be read after by the user application. So basicaly I enqueue INTCAP values to be consumed by user's application. So far not so good. I'm facing problems of NULL pointers at kernel after sometime when high throughput happens and/or when multiple inputs changes at same time. The spi_message used at #2 is always in the same memory area, allocated at probe time. What I'm think is happening is that a new interrupt is happening while step #3 is running, so spi_message_init() is called on a message about to be transferred, and when is transferred I got the NULL pointer handling error. So I put a spin_lockirqsave() at step #2 before messing up with the spi_message buffer and spin_unlock_irqrestore() at step #4. If spi_async_locked() fails I unlock it too. But this make a big doubt arises in my head. Since interrupts are disabled at the chip (this is farly common) until I read some register, should still I use spin_lock_irqsave()/restore() routines or I'm safe to keep with normal spin_lock() ones? What happens if an interrupt (from other hardware for example) happens while a spin lock is held? Here is the code: http://pastebin.com/JTubAHuz Thanks in advance, -- "Do or do not. There is no try" Yoda Master

1 0

How to read last oops message in Android kernel
by Umair Khan Nov. 11, 2015

Nov. 11, 2015

Hi, I'm working on the kernel of my xiaomi device. However, whenever I start it, it soft reboots to recovery. I'm guessing a kernel oops occur. I wanted to ask how to read kernel debug messages of the last run ? In my Nexus 5, I have /proc/last_kmsg which contains the messages from the last run. However, in my xiaomi kernel tree, that proc entry is removed. Responsible commit - https://github.com/omerjerk/android_kernel_xiaomi_ferrari/commit/15d7644620… It says that functionality has been moved to pstore. But I'm not able to get how to exactly read the debug messages of the last run. Thanks Umair

2 3

Informing kernel that a block device is offlined
by Alvin Abitria Nov. 11, 2015

Nov. 11, 2015

Hello, Good day. My inquiry is about block drivers. Suppose our device encounter problems and all error handling failed. The only remaining option I see for the driver to do is to offline it. The intention is for the system to be notified to avoid sending any future request to the device and be inaccessible so any wicked behavior, like system crash, are avoided. This should work whether the device is used standalone or with RAID. The question is how to do it cleanly. I've searched existing drivers in the kernel source (like sd, skd, etc), and all they do (as I see it) is to complete succeeding requests with -EIO (__blk_end_request_all(rq, -EIO)). So far this works with FIO, because once that happens and all fio requests are completed with -EIO, fio stops sending further requests. But if used with RAID and unrecoverable fault is triggered, just completing requests with error seems not to be working. RAID detects errors, but can't remove the erring device from its system. Sometimes kernel is still sending requests to the RAID'ed faulty device (which should stop). RAID becomes degraded (in a not-so-good way) and eventually crashes the system. So how does the block driver properly informs the upper layers that its device is faulty and must not be used again for that session? Best regards, Alvin

1 0

Re: Improvement of trails and tutorials to become a kernel developer / maintainer
by Albino B Neto Nov. 6, 2015

Nov. 6, 2015

2015-11-06 15:15 GMT-02:00 Patrick Plattes <patrick(a)erdbeere.net>: > ello, > > I'm interested since a very long time in kernel development, but I > never saw the right path to become familiar with parts of the kernel. > I read a bit of ipc code and ext* code, but since I often don't know > any possible next steps I moved back to something else in the user > space. > > I really like the tutorial on kernelnewbies.org FirstKernelPatch an I > had the idea to create this type of tutorial as a training for > specific kernel subsystems eg. ipc, file systems, usb drivers, ... > > A structure of such a tutorial could look like that: (eg scheduler) > > 1. Introduction / Goal > [5 sentences of the goal - what should be archived by this tutorial] > - understand scheduling in the linux kernel > - write your own scheduler > - ... > 2. Preparation > 2.1 Understand how to write a kernel patch: > http://kernelnewbies.org/FirstKernelPatch > 2.2 Understand the goal of Scheduling: https://en.wikipedia.org/wiki/Schedule > 3. User space view > 3.1 Read and understand: http://man7.org/linux/man-pages/man7/sched.7.html > 3.1.1 Questions > 3.2 Exercise: Write a program that does A > 3.3 Exercise: Write a program that does B > 3.4 Exercise: Write a program that does C > 4. Kernel > 4.1 Read and understand: http://man7.org/linux/man-pages/man7/sched.7.html > 4.1.1 Questions > 4.2 Read API description: http://... > 4.3 Exercise (understanding): Read and understand function xxxx_yyyy() > 4.4 Exercise (understanding: Change the implementation of xxxx_yyyy(), > so that ... > 4.5 Exercise (debugging): checkout version 123456 and fix the > following (old) bug > 4.6 Final Exercise (developing): Write your own scheduler with the > following algorithm... > > In my opinion that could help a lot of interested people to have a > guided tour though the kernel. It could really lower barriers, also in > terms of the fear of communication. > > I am NOT able to to produce it by myself, but I can help to structure > it, review it and also answer questions. I would also maintain them in > case of changes and test the tutorials on a regular basis to keep them > up to date. I also would improve the tutorial from a newbie point of > view ;) > > If there is someone out there that is also interested in doing it > please let me know. > > And if there is something like this out there please let me know, so I > can maybe support this project :) Add mailing kernelnewbies. Albino

1 0

How to mark suspicious code?
by Ivan Safonov Nov. 6, 2015

Nov. 6, 2015

Hi all! How can I mark suspicious code, if I can not fix it?

3 5

Regadring Linux Scatter Gather List
by babu subash Nov. 6, 2015

Nov. 6, 2015

Hi All, I have a basic query regarding the DMA. After the SG list is prepared and mapped using dma_map_sg(). we need to do DMA transfer. Here the list will give the bus addresses of source SG list. In my one of the earlier project in vxworks, I had a DMA registers which provided the src and dst address register and mode. where we use to fill both addresses, size and direction. But here how to specify the destination addresses. Please let me know. In one of the driver I saw this method: dmaflags = claim_dma_lock(); set_dma_mode(); /* Read / Write */ set_dma_addr(dma, dma_addr); set_dma_count(dma, size); enable_dma(dma); release_dma_lock(dmaflags); Here the dma_addr will be the address will be given that we get from the SG list mapped address list which becomes the src address for write on that channel. But to give the dest address where to write on to particular offset on data buffer?? Is the issue... Is there any other methods should we use? Regards, Subash

1 0