0

I am after some clarification/guidance. For a leaning experiment I am wanting to implement a driver for both the MCP23xxx gpio expander ICs. One series using i2c and the other SPI.

I have experience with i2c drivers for onboard sensors but am now a little unsure of the approach I should take. This exceptional answer and the LWM article it links gave some great insight into platform drivers. I understand that a platform drivers would make sense as thee gpio expanders are not discoverable devices. Now I am unsure of how one would implement a platform drivers that is really an i2c driver(focusing on just one of the chip variants for now). The sensors I have worked with in the past are instantiated in the device tree and the the device driver can make easy use of the i2c_client to interface with the device. Something that I am unsure of is how a platform driver would, for example, interface with i2c devices. I have struggled to find any resources in this.

I would be greatly appreciative if someone would quickly outline for me how platform drivers could be used as device drivers for devices that are, in their most basic form, i2c devices or spi devices. It could be that my understanding of platform drivers is also won't in this context. Clarification there would , as such, also be greatly appreciated.

Alex Hoffmann
  • 355
  • 4
  • 20
  • 1
    The modern way of doing this is to use **regmap** API (and respectively **regmap SPI** and **regmap I2C**) with a driver split to three parts, i.e. *core* driver, *I2C glue* driver and *SPI glue* driver. The simplest example comes to my mind is ADXL345 IIO driver: https://elixir.bootlin.com/linux/latest/source/drivers/iio/accel/adxl345_core.c (core, the rest is in the same folder). – 0andriy Apr 05 '20 at 18:02
  • Just in case, the driver for that chips used to be in the kernel: https://elixir.bootlin.com/linux/v4.12.14/source/drivers/gpio/gpio-mcp23s08.c (latest version) and then got removed by some reasons (you may still get it from the kernel Git tree if you wish). – 0andriy Apr 05 '20 at 18:18
  • Ah, not removed at all! See *commit 64ac43e6fa283f556f0a8f69ad52d6e7d550307d Author: Sebastian Reichel Date: Mon May 15 11:24:25 2017 +0200 gpio: mcp23s08: move to pinctrl* – 0andriy Apr 05 '20 at 18:19
  • Here we are: https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/pinctrl-mcp23s08.c – 0andriy Apr 05 '20 at 18:20
  • Thanks @0andriy. I don't have problems writing separate drivers but I am interesting in writing one driver to support both busses. regmap looks like a good start. Thanks for the tip! – Alex Hoffmann Apr 06 '20 at 11:20
  • As I understand you just want to study driver development based on the driver for that chip. Personally I would consider this not the best approach due to presence of the driver in upstream. I would rather recommend to find a component which has no driver at all and try to develop. You will kill few birds with one stone. – 0andriy Apr 06 '20 at 11:23
  • @0andriy I have hardware that is compatible with either protocol (can have either IC on the PCB) and was wanting to write a single driver for the hardware to cover both cases (reduce end user complexity). Writing standard subsystem drivers is something I have worked with in the past but I was curious of how one writes such a driver. :) – Alex Hoffmann Apr 06 '20 at 11:29
  • Mentioned driver covers both protocols. So, you may use it as is. – 0andriy Apr 06 '20 at 11:30
  • Oh, awesome. will have a look. Thanks! – Alex Hoffmann Apr 06 '20 at 11:49

0 Answers0