Re: [RFC PATCH 0/3] i2c: Introduce i2c bus extensions

[Herve Codina <herve.codina@bootlin.com>]

Hi Ayush,

On Thu, 3 Jul 2025 16:56:20 +0530
Ayush Singh <ayush@beagleboard.org> wrote:

> On 6/13/25 13:00, Herve Codina wrote:
> 
> > Hi Ayush,
> >
> > On Thu, 12 Jun 2025 13:22:45 +0530
> > Ayush Singh <ayush@beagleboard.org> wrote:
> >  
> >> I have tested this patch series for use with pocketbeagle 2 connector
> >> driver [0]. To get a better idea how it looks in real devicetree, see
> >> the base tree [1] and the overlay [2]. Since it also used gpio and pwm
> >> nexus nodes, along with providing pinmux for pins, it can provide a
> >> better picture of how the different pieces (export-symbols, nexus nodes,
> >> etc) look when combined.  
> > Nice. Happy to see that I am no more alone with a system using these
> > features.
> >  
> >>
> >> I also have a question for Herve. Do you already have any working
> >> patches for similar extension for SPI and UART in some private tree?  
> > No, I didn't do anything related to SPI nor UART.
> >
> > On my system, no SPI nor UART are wired to my connector and so, I haven't
> > got any needs to implement extension busses for SPI an UART (serial dev bus)
> > nor any support for nexus nodes for other kind of components.
> >
> > Best regards,
> > Hervé  
> 
> 
> I have added SPI bus extension to my kernel tree [0]. Now, the techlab 
> cape (other than mikrobus port) works using export-symbols + i2c and spi 
> bus extension + eeprom auto detection.
> 
> 
> Here is a list of everything currently working on the tree:
> 
> 1. EEPROM based auto-detection.
> 
> 2. SPI
> 
> 3. I2C
> 
> 4. PWM
> 
> 5. GPIO
> 
> 
> Missing:
> 
> 1. UART (Don't have a cape that has something using the UART yet. Maybe 
> need to experiment with MikroBUS).
> 
> 
> Not quite sure what else to do to move things forward.
> 
> 
> Best Regards,
> 
> Ayush Singh
> 
> 
> [0]: https://github.com/Ayush1325/linux/tree/beagle-cape-v1
> 

I've just looked at your code related to SPI. It is closed to the I2C code
and that's pretty nice!

I think to move forward we have to wrote the SPI bus extension binding and
propose the binding + the code upstream.

Compared to I2C bus extension, only one repo is involved for SPI, the Linux
kernel repo. On I2C bus extension, I am stuck on the binding which is a
modification on the dtschema repo [0].

The SPI binding modifications for SPI bus extension will probably take place
in spi-controller.yaml [1] and should be pretty close to modifications done
for the I2C binding.

When one of the two series (I2C or SPI) is accepted, it will be easier
for the other one to follow (Same concept, same kind of binding, same kind
of code).

The advantage of the SPI series, I think, is that only one repo is involved.

Best regards,
Hervé

[0]: https://lore.kernel.org/all/20250618082313.549140-1-herve.codina@bootlin.com/
[1]: https://elixir.bootlin.com/linux/v6.16-rc4/source/Documentation/devicetree/bindings/spi/spi-controller.yaml