devicetree overlay

[bm16ton]

Hello good sir. Im still trying to figure out the best (apparently gonna be non standard) way of passing platform data to my usb to i2c/spi etc devices. Your wiki for the devicetree info (awesome btw ty!) Im a little confused. I know combined modes are for simple bus devices with a single interface etc. Im just not sure If your pc was getting a phandle and setting it up without you supplying and devicetree data, or if the overlay in the writeup was an upgrade/update to a simple bus version? I havent seen it written as such but I guess since the two are combined/sharing it would be kinda like auto conf a phandle for yeah. Curious if a overlay fragment could add more interfaces or whatever and continue to share the handle. Ive tried all kinds of things most recently hacked in a live overlay interface into my drivers directly So no need to patch the kernel. Much Like your fdt_loader I just now seen. Yours may actually fill a gap I had being limited to overlays by allowing pdata as firmware files! Again you write the best stuff. That seems more reasonable when switching between x86 and arm. The other approach I like but probly just cuz I used it the most is have a usb driver setup the pdata then load its companion platform driver and pass that info off. I havent written any true mfd drivers but they look very similar in concept minus the data passing, probly trivial to add. Ive been getting something similiar going on my h7 with ulpi like your dln2 pico project. gpio/irq/spi/i2c/adc all work with kernel drivers, It needs some tlc but haven't implemented the platform stuff yet. Its written in libopencm3 so the usbhs and m4core booting etc (plus unfortunate amount more) was forrest gumped by myself (so its probly suspect lol) . But so little info on such devices and even less when you bring in kernel drivers. Thats why ive bothered you here a second time which I apologize for. I realize my project is beneath you but if your aware of anyone or even decent resources like examples and such Im all ears my friend :) And since i saw you used compression so successfully on pico with gud, well I just gotta try it on something cool. Im sure I can get something going faster then usbhs adc/spi something and give her hell. Thank you again. Just came to me I never looked by the dln2 is just a single interface? Guess not that suprising.

[notro]

Im still trying to figure out the best (apparently gonna be non standard) way of passing platform data to my usb to i2c/spi etc devices.

Can you be more specific by what you mean with "platform data", is this data that the kernel driver needs? To set up kernel devices? If so can you point to the driver.

I don't remember any details about how device tree worked for USB devices, so I can't give you any help with that.

The mfd subsystem has traditionally been used when a single device supports functions that spans multiple driver subsystems. There's now a AUX bus that I haven't studied, maybe it provides another way to write drivers for these USB IO devices, I don't know.

Just came to me I never looked by the dln2 is just a single interface?

Yes, the dln2 mfd driver is a USB interface driver.

[bm16ton]

"Yes, the dln2 mfd driver is a USB interface driver."

Sorry i wasnt clear, i meant a single usb interface (presented as simple bus) which afaik is that or usb hub is only devices that should be seen as combined like you described in the wiki. Totaly willing to admit im probly confused on that, so with your firmware also enumerating as 2 acm devices as well (if memory serves) seems like 3 interfaces total. As for platform data yeah that term pretty much covers a lot of data (my bad). My issue is anything not in board_info can become a problem. Between switching between arm and x86, the fact that various drivers dont support one method or another devicetree/acpi etc. Its hard to find a simple to use solution that will work on drivers/arch's. I see fwmode patches that start to address this and even populate devicetree automatically creating auto enumeration on devices that couldnt before making way thru kernel, so thats good. But to pass data that can possibly be anything, example your fbtft drivers. After they removed your module for collecting/passing that info easily from userland it sucked! Then they further reduced the amount of acceptable ways for those drivers to get the data months later. For my outa tree usb to spi drivers a simple single solution hasnt jumped at me yet :( My whole thing is i want to make easier for people to start playing with stuff and make spi/i2c available on more pc's etc, so that poorkid slinging newspapers can afford to play with sensors on his handme down laptop. I shoukd probly be clear by make it easy i decided if my solution requires rebuilding the kernel thats a nogo, no kernel mods/recompiles. If the module needs recompiling everytime i switch devices itd suck but falls under acceptable. Also seperate methods For x86 and arm seem unacceptable unless 100% hidden from end user. Christ im long winded so sorry friend.

On Fri, 10 Mar 2023, 12:46 pm Noralf Trønnes, @.***> wrote:

Im still trying to figure out the best (apparently gonna be non standard) way of passing platform data to my usb to i2c/spi etc devices.

Can you be more specific by what you mean with "platform data", is this data that the kernel driver needs? To set up kernel devices? If so can you point to the driver.

I don't remember any details about how device tree worked for USB devices, so I can't give you any help with that.

The mfd subsystem has traditionally been used when a single device supports functions that spans multiple driver subsystems. There's now a AUX bus https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html that I haven't studied, maybe it provides another way to write drivers for these USB IO devices, I don't know.

Just came to me I never looked by the dln2 is just a single interface?

Yes, the dln2 mfd driver is a USB interface driver.

— Reply to this email directly, view it on GitHub https://github.com/notro/pico-usb-io-board/issues/4#issuecomment-1464153475, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP4YZTRKVOJEMGGV3ULW3NSGLANCNFSM6AAAAAAVS3I53E . You are receiving this because you authored the thread.Message ID: @.***>

[notro]

"Yes, the dln2 mfd driver is a USB interface driver."

Sorry i wasnt clear, i meant a single usb interface (presented as simple bus) which afaik is that or usb hub is only devices that should be seen as combined like you described in the wiki. Totaly willing to admit im probly confused on that, so with your firmware also enumerating as 2 acm devices as well (if memory serves) seems like 3 interfaces total.

Yes 3 in total, 1 interface for the dln2 functions.

I see fwmode patches that start to address this and even populate devicetree automatically creating auto enumeration on devices that couldnt before making way thru kernel, so thats good.

Do you have a pointer to that, it would be interesting to have a look.

[bm16ton]

Oh yes, ok so in my excitement to share those patches im having a slight issue finding all the ones i wanted to share. But this one is interesting https://lwn.net/Articles/917999/ this not only creates a devicetree if none is present (acpi etc) it then autopopulates all the pci nodes, and final piece is in the devs kernel fork source. He has drivers (if memory serves one was a peculiar networking device) which has devicetree data included in driver and thus its node is autogenerated by this new code from these patches. His personal kernel source may have had more patches then posted in the link. I also see small patches for devices like the dln2 switching to fwnode. So hopefully these various pieces will come together and present a unified fwnode frontend to devicetree/acpi backends with ways to "bake in" devicetree entries in drivers. I have found a few other patchsets expanding the one i linked, closer to my end goals. Ill keep looking.

On Mon, 13 Mar 2023, 4:12 pm Noralf Trønnes, @.***> wrote:

"Yes, the dln2 mfd driver is a USB interface driver."

Sorry i wasnt clear, i meant a single usb interface (presented as simple bus) which afaik is that or usb hub is only devices that should be seen as combined like you described in the wiki. Totaly willing to admit im probly confused on that, so with your firmware also enumerating as 2 acm devices as well (if memory serves) seems like 3 interfaces total.

Yes 3 in total, 1 interface for the dln2 functions.

I see fwmode patches that start to address this and even populate devicetree automatically creating auto enumeration on devices that couldnt before making way thru kernel, so thats good.

Do you have a pointer to that, it would be interesting to have a look.

— Reply to this email directly, view it on GitHub https://github.com/notro/pico-usb-io-board/issues/4#issuecomment-1466891227, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP4R4OAT5X5XTKUFFMLW355RTANCNFSM6AAAAAAVS3I53E . You are receiving this because you authored the thread.Message ID: @.***>

[bm16ton]

I Just posted my stm32h7 usbhs usb2spi/gpio/irq firmware and drivers. I just rewrote it to be as close as possible to the ftdi mpsse spi/i2c drivers I maintain, because maintaining out of tree modules is slowly eating my soul. And I hoped this would save time patching in the future. But it uses a usb device to load a spi platform device and pass off platform data. So gpio lookup for gpio and platform data including board_info and any extra gpio descriptors. I then use properties (property.h i dunno what else to call it) for any other data the device may need. This works reasonably well for devices which support it. And of course for any simpler devices that just need standard spi pins and mode 0 I simply add a module param for modalias which works great for spi flash etc. I always add that to dln2 etc. This is like a 3rd grader sending his workout video to "The Rock" but here is my ruff draft but fully functional firmware/driver that does the two driver method mentioned above. https://github.com/bm16ton/usb-2-spi-stm32h7

[notro]

But this one is interesting https://lwn.net/Articles/917999/

This seems to be the latest version: https://lore.kernel.org/lkml/1674183732-5157-1-git-send-email-lizhi.hou@amd.com/

One positive take away for me after skimming through is that Rob Herring (DT maintainer) wants a solution for this, but it seems difficult to find a solution that everyone can tolerate.

[bm16ton]

Yes ive seen this before unfortunatly. The ftdi mpsse enabled chips have been out for over a decade, ive seen hundreds of discussions, dozens of patchsets for gpio/i2c/spi etc, but all we have mainline is usb2uart and sum gpio that only works on one of the chips. The reasons always seem superficial too. The few usb to io adapters that are mainlined, none of the manufacturers mention the kernel drivers anymore (some used to). This has lead to vendor lockin replacements, and people resorting to using chrome browser for custom usb devices (yeah not sure where the connection between chrome and usb devices comes in, but its a thing). I was very excited to see your pico io firmware. With iot and explosion of cheap sensors, and personally being a dumpster diver i see the importance. I didnt have my ftdi kernel drivers on github for long before a large company contacted me in need of such a device and more every week or so. And ive never posted anywhere about those drivers they had to search. Its a shame but i think its moving forward. Strange i gotta reread that patchset but did it add a devicetree to acpi devices? I remember reading in several places thats a no go, but if a mix and match becomes possible ill just have my drivers apply an overlay or create a new root node on acpi and call it the day. But anyway ive taken way to much of your time already, i realy tuely do appreciate your time and our conversation. Oh one last thing simple modparam patch to dln2_spi for simple devices if i did a small writeup for your wiki would that be welcome or more of a hassle? Could also do one for external kernel module that adds live dynamic overlays to compliment your devicetree patch. Realy anything i can do to contribute im down for. Again thank you

On Thu, 16 Mar 2023, 1:52 pm Noralf Trønnes, @.***> wrote:

But this one is interesting https://lwn.net/Articles/917999/

This seems to be the latest version: @.***/

One positive take away for me after skimming through is that Rob Herring (DT maintainer) wants a solution for this, but it seems difficult to find a solution that everyone can tolerate.

— Reply to this email directly, view it on GitHub https://github.com/notro/pico-usb-io-board/issues/4#issuecomment-1472445833, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP67TODIXSHZZV6HH3DW4NHNBANCNFSM6AAAAAAVS3I53E . You are receiving this because you authored the thread.Message ID: @.***>

[bm16ton]

Well i made some headway, I took this driver https://github.com/ikwzm/dtbocfg.git which adds dynamic overlay loading to deviectree systems that dont support it (like my laptop) and patched it to autoload a overlay that creates a new root node. The dtb it autoloads is generic and should work on any system and is compiled into module so all you hafta do is load the module whiich auto happens on usb insert. The overlays written for it should work unmodified on any devicetree system. I currently dont have my driver written to accept platform data from devicetree so its only been tested to load the driver and make the attempt.

After loading the driver with built in dtb, i get this is in device tree;

spi-tiny-usb {
    interrupts = <0x00 0x1d 0x04>;
    compatible = "spi-plat-usb";
};

and after a generic mcp2515 overlay via configfs

spi-tiny-usb {
    #address-cells = <0x01>;
    gpio-controller;
    interrupts = <0x00 0x1d 0x04>;
    #size-cells = <0x00>;
    compatible = "spi-plat-usb";

    can0_pins {
        spi-plat-usb,pins = <0x04>;
        spi-plat-usb,function = <0x00>;
        phandle = <0x222>;
    };

    mcp2515@0 {
        pinctrl-names = "default";
        pinctrl-0 = <0x222>;
        interrupts = <0x04 0x02>;
        clocks = <0x223>;
        spi-max-frequency = <0x3d0900>;
        compatible = "mcp2515";
        reg = <0x00>;
        phandle = <0x224>;
    };
};

and it tries to bring up mcp2515 but like earlier mentioned i havent written devicetree data support in my driver yet. But the data and phandles are present so im confident. My code; https://github.com/bm16ton/usb-2-spi-stm32h7/tree/master/usb-spi/auto-overlay

[notro]

Oh one last thing simple modparam patch to dln2_spi for simple devices if i did a small writeup for your wiki would that be welcome or more of a hassle?

A simple SPI device is that one that doesn't need DT? If so maybe this can be used: https://github.com/msperl/spi-config

A lot of DT drivers use device property access functions. Maybe it's possible to add those properties to the device using a module that add them using swnode. This sounds simpler than adding a Device Tree. Havien't looked into it in detail so I don't know how swnode works. But ofc this requires that the targeted device driver doesn't use the of_property_* functions.

[bm16ton]

oh very cool! Thank you! I will look into that today. I do use properties but right now its hard coded in the driver and id like to avoid recompiling the driver each time. But those options sound very promising. Again thank you

On Sun, 26 Mar 2023, 2:09 pm Noralf Trønnes, @.***> wrote:

Oh one last thing simple modparam patch to dln2_spi for simple devices if i did a small writeup for your wiki would that be welcome or more of a hassle?

A simple SPI device is that one that doesn't need DT? If so maybe this can be used: https://github.com/msperl/spi-config

A lot of DT drivers use device property https://elixir.bootlin.com/linux/latest/source/include/linux/property.h access functions. Maybe it's possible to add those properties to the device using a module that add them using swnode https://elixir.bootlin.com/linux/latest/source/drivers/base/swnode.c. This sounds simpler than adding a Device Tree. Havien't looked into it in detail so I don't know how swnode works. But ofc this requires that the targeted device driver doesn't use the ofproperty* functions.

— Reply to this email directly, view it on GitHub https://github.com/notro/pico-usb-io-board/issues/4#issuecomment-1484175553, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP5VU735GJEY4AZY623W6CIABANCNFSM6AAAAAAVS3I53E . You are receiving this because you authored the thread.Message ID: @.***>