Re: Adding compatible string to standard UART
Hello Ayush, On 29.08.23 18:58, Ayush Singh wrote: > Hello everyone. I have been working on submitting my GSoC23 driver [1] to be > merged upstream. > > BeaglePlay has a specific UART that is connected to the CC1352 Co-processor. > This UART is used to communicate with CC1352 co-processor. It is also used to > flash stuff to this co-processor using bsl. Thus, it should be possible to > disable it with an overlay and show it as a normal ttyS* device. Currently, > the beagle kernel uses the following dts [3]. > > My driver uses this UART and thus I need to patch the devicetree. However, I > am not too sure what I need to do to submit my device tree patch upstream. I > read the Submitting Devicetree (DT) binding patches' doc [2], but I don't > understand a few things: > > > 1. Should I even be using device tree? Maybe there is a better method? I haven't checked your links, but from your description, serdev might be what you're after. In the DT that would be a child node of the existing serial device. > 2. Is there some naming convention? I was thinking of `beagle,cc1352-uart` Not sure about the uart suffix. beagle,play-cc1352 sounds fine for a v1, I think. > > 3. Do I need a documentation entry at `Documentation/devicetree/bindings`? If > yes, should it go under serial? Only if the cc1352 is itself a UART adapter, which doesn't appear to be the case. Look what the function of the device has and choose the appropriate directory. For coprocessors that have multiple functions, the main node is described in mfd/ and the different functions in their respective directories. > > 4. I think I am supposed to use YAML now and not txt? Yes. > > 5. What are the required fields in this doc file? Just take a similar device as a template. See what's already in mfd/ and see what's similar to your usage. Cheers, Ahmad > > > Ayush Singh > > > > [1]: https://github.com/Ayush1325/linux/tree/gb-beagleplay > > [2]: https://docs.kernel.org/devicetree/bindings/submitting-patches.html > > [3]: > https://git.beagleboard.org/beagleboard/linux/-/blob/v5.10.168-ti-arm64-r103/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts#L1206 > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO and interrupt
Hello Tony, On 26.07.23 12:10, Tony He wrote: > Hi, > > I'm writing button driver. The button is based on GPIO.When the button > is pressed or released, the interrupt is generated. According to the > GPIO value(1 or 0) , I can know which action is taken(pressed or > released). > However, a question occurred to me. Do I need to consider when to get > the GPIO value? I mean is it possible that GPIO value will be changed > caused by another interrupt when I get the GPIO value in top or bottom > half > of first interrupt? I know the CPU is fast and pushing/releasing > button is slow, so it should not happen in practice. But let's just > consider this case in theory. You can assume the button is pushed or > released very very fast. This is not only a theoretical issue. The transition from button being pressed to unpressed and back is not noise free, so a naive translation of IRQ/GPIO state to input events may not be sufficient. Dealing with this is called debouncing and involves taking multiple samples before signalling the input event. > Seems that GPIO interrupt is special comparing with other device with > cache. There is no cache to store data(GPIO value) for GPIO. Right? > Can someone help to clarify this question? Thanks a lot. IRQ handlers have a second argument with a pointer to device specific data. You can store information there and many drivers do so. You need to take care that the data isn't accessed concurrently though, e.g. via a spinlock. You can see how all this is implemented in the Linux gpio_keys driver. Cheers, Ahmad > > Tony > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to find hook points for USB device additions and removals
On 25.08.22 14:49, Yang Hanlin wrote: > Hi all, > > I am learning about the Linux kernel, especially the eBPF subsystem, for > various observability and networking applications. As a practice, I am > developing a simple utility that detects additions and removals of USB devices > and performs actions accordingly. For the sake of practicing eBPF, I plan to > implement this utility by instrumenting kernel functions with kprobes rather > than writing udev rules etc. > > However, I found it not that easy to find the correct hook points. From the > kernel documentation for writing USB device drivers > (https://www.kernel.org/doc/html/latest/driver-api/usb/writing_usb_driver.html), > I learned that there is a `probe` function and a `disconnect` function > provided by a driver (in a `usb_driver` struct, > https://github.com/torvalds/linux/blob/e146caf303493c4f2458173d7f1598b76a9b1396/include/linux/usb.h#L1186-L1189) > for the kernel to call on additions and removals of USB devices respectively. > So I thought finding callers to `probe` and `disconnect` might help; but I did > not find such callers, either by searching `.probe(` in the repository or > using static analysis provided by an IDE. Search for ->probe( instead if you want to find callers. > Is there anything wrong with the methods I am using? How can I find > appropriate hook points for USB device additions & removals in the kernel? Or > is there an alternative solution using eBPF (such as instrumenting udev with a > uprobe)? > > Thanks in advance. > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Are there any requirements to sign up for Kernel Newbies?
Hi, On 21.02.22 00:35, Rogério Valentim Feitoza da Silva wrote: > Are there any requirements to sign up for Kernel Newbies? I want to sign up > for it and I don't know what is required to sign up. I know I need an > e-mail address (I have one, otherwise I wouldn't be sending this) and a > password (which I will create when signing up), and optionally my name > (which I might put while signing up), but are there any additional > requirements? If so, what are they? I got your Email via the mailing list and if you get this email, then there's nothing more you need to do to use the mailing list. Have fun, Ahmad > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to switch between installed kernel and developed kernel
Hello Gidi, On 22.03.21 13:11, Gidi Gal wrote: > Hello, > > I am new to kernel development, currently working on > https://kernelnewbies.org/FirstKernelPatch. I reached the step "Install > your changes" in "Modifying a driver on native Linux". I would like to > separate my developed kernel and my installed kernel and to switch between > the two in order to test my changes. I am not sure that my tutorial > explains how to do that. If you have a link that proposes a workflow for > this request (or if my tutorial does explain this workflow and I'm missing > the exact paragraph that does that) please let me know. I've found running a kernel under qemu with my normal rootfs to be quite useful to quickly try out things. See the qemu-test script in the RAUC project for an example: https://github.com/rauc/rauc/blob/master/qemu-test Don't forget to backup of course. Maybe you could even read-only mount the rootfs for added safety. Good luck, Ahmad > > Thanks, > Gidi > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to make .dtb from .dts file (how to set include path for #include .. ?)
Hello Chan, On 23.02.21 09:37, c...@etri.re.kr wrote: > I don't know how I should let the preprocessing kick in. > > I tried (because there is > include/dt-bindings/interrupt-controller/arm-gic.h) > > $ dtc -i include -I dts -O dtb -o juno.dtb > arch/arm64/boot/dts/arm/juno.dts > > But it doesn't work. dtc only handles /include/. #include is expanded by a C preprocessor that's explicitly run beforehand. Run make V=1 dtbs if you are curious to see the commands executed. > How can I use dtc program to make juno.dtb? > > Or if I have to use Makefile, what is the command? What reason for doing this by hand? Cheers, Ahmad > > > > Thanks, > > > > Chan Kim > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: the cost of EXPORT_SYMBOL_GPL
Hello, On 6/17/20 2:48 PM, Tomek The Messenger wrote: > This is the case about which Martin write shortly. Then let's assume on > another soc reset reason is not stored in chip's address space memory > mapped to address 0xfff but it is accessed via some spi operation. On > another soc reset reason is still memory mapped but to different address > 0xfff... And then let's assume there are 30-40 such functionalities like > reset_reason. If we have one unique sysfs interface then it is easier for > everyone: tester, developer to proceed with such device, testing or > debugging. You don't waste time to read documentation each time, checking > what address is/how to read each functionality. You have this hidden in > kernel modules code and can access via cat/echo to /sys. It also gets more interesting when you have multiple reset reasons in the same system, e.g. SoC power control differentiates between POR, external and Watchdog reset and Watchdog OTOH differentiates between watchdog reset and regular reset and then you might have an external PMIC with an integrated watchdog that overrides both. In projects I've been involved in, the bootloader did the boot reason computation[1] and was the one to act on it, so communication to the kernel wasn't of high importance. It would be great to have: 1) an upstream device tree binding for reset reason communication from bootloader to Linux 2) a mainline User API to query the reset reason 3) a mainline in-kernel API for drivers to set reset reasons Watchdog drivers already have a WDIOF_CARDRESET flag that could be folded into this. If you feel up to the task and go along with upstreaming it, you'll save yourself (and future colleagues who need to debug locking problems between your module and mainline kernel drivers) a lot of hassle. [1]: https://barebox.org/doc/latest/user/reset-reason.html Cheers Ahmad > > On Wed, Jun 17, 2020 at 2:36 PM Martin Kaiser wrote: > >> Hello Greg and all, >> >> Thus wrote Greg KH (g...@kroah.com): >> >>> Please do not do that. There are valid kernel apis to grant access to >>> registers easily, >> >> the most simple case would be a "reset reason" register within the >> chip's address space. A hand-crafted driver would ioremap the region and >> implement a sysfs show method that reads the register. >> >> What do you recommend for providing read access to such a register >> via sysfs? Is this a job for the userspace I/O (UIO) subsystem? >> >> Thanks, >> Martin >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
