MFD device driver on top of UART/RS232
Hi,
I have an embedded system with microcontroller connected via UART/RS232 port. This microcontroller implements several low-level functions that need to be exposed as device drivers in other subsystems (watchdog, LEDs, HWMON, firmware read/write).
I checked many drivers implemented in the kernel, searched through mail list archives and it looks like there are three different ways to solve this task:
A) most of the devices that are connected using UART have user space program that configures and manages it (either directly or with help of dedicated line discipline, SLIP, SL-CAN, etc)
B) serio - mostly used for input devices
C) direct use of UART port taking control from serial_core.
The best match I have found so far is MFD driver for Atmel Microcontroller on iPaq h3xxx (drivers/mfd/ipaq-micro.c) that follows concept "C)"
Is this a good enough example to use for this task? This platform is a legacy one so I am confused a little if new driver will fit nicely into the mainline.
It would be great if someone could point me to another example to follow or advise better way to implement MFD driver without user space involvement.
Best regards,
Andrey
Hi Andrey,
+Cc NeilBrown <[email protected]>
Quoted 16 lines · Andrey Vostrikov
Hi,
I have an embedded system with microcontroller connected via UART/RS232 port. This microcontroller implements several low-level functions that need to be exposed as device drivers in other subsystems (watchdog, LEDs, HWMON, firmware read/write).
I checked many drivers implemented in the kernel, searched through mail list archives and it looks like there are three different ways to solve this task:
A) most of the devices that are connected using UART have user space program that configures and manages it (either directly or with help of dedicated line discipline, SLIP, SL-CAN, etc)
B) serio - mostly used for input devices
C) direct use of UART port taking control fromserial_core.
Quoted 3 lines
The best match I have found so far is MFD driver for Atmel Microcontroller on iPaq h3xxx (
drivers/mfd/ipaq-micro.c) that follows concept "C)"
There's also D) TTY slave device support: https://lkml.org/lkml/2015/3/18/40
Unfortunately this hasn't made it to mainline yet and it seems the parties lost interest after some lengthy discussion of device tree phandles vs. subnodes, but I think this is what you're looking for.
Sascha
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi Sascha,
Quoted 25 lines · Sascha Hauer
Hi Andrey,
+Cc NeilBrown <[email protected]>
Quoted 16 lines · Andrey Vostrikov
Hi,
I have an embedded system with microcontroller connected via UART/RS232 port. This microcontroller implements several low-level functions that need to be exposed as device drivers in other subsystems (watchdog, LEDs, HWMON, firmware read/write).
I checked many drivers implemented in the kernel, searched through mail list archives and it looks like there are three different ways to solve this task:
A) most of the devices that are connected using UART have user space program that configures and manages it (either directly or with help of dedicated line discipline, SLIP, SL-CAN, etc)
B) serio - mostly used for input devices
C) direct use of UART port taking control fromserial_core.Quoted 3 lines
The best match I have found so far is MFD driver for Atmel Microcontroller on iPaq h3xxx (
drivers/mfd/ipaq-micro.c) that follows concept "C)"
Quoted 5 lines
There's also D) TTY slave device support: https://lkml.org/lkml/2015/3/18/40
Unfortunately this hasn't made it to mainline yet and it seems the parties lost interest after some lengthy discussion of device tree phandles vs. subnodes, but I think this is what you're looking for.
Thank you for pointing out to another option. Looks like it was developed a little further and was submitted as patch by "H. Nikolaus Schaller",
https://lkml.org/lkml/2015/10/16/729
But I see no further traces of it.
Cc'ed Nikolaus, may be he could comment on state of UART slave patch.
Best regards,
Andrey
Quoted 3 lines
Sascha
Hi Andrey,
Am 17.11.2015 um 13:45 schrieb Andrey Vostrikov <[email protected]>:
Quoted 30 lines
Hi Sascha,
Quoted 27 lines · Sascha Hauer
Hi Andrey,
+Cc NeilBrown <[email protected]>
Quoted 16 lines · Andrey Vostrikov
Hi,
I have an embedded system with microcontroller connected via UART/RS232 port. This microcontroller implements several low-level functions that need to be exposed as device drivers in other subsystems (watchdog, LEDs, HWMON, firmware read/write).
I checked many drivers implemented in the kernel, searched through mail list archives and it looks like there are three different ways to solve this task:
A) most of the devices that are connected using UART have user space program that configures and manages it (either directly or with help of dedicated line discipline, SLIP, SL-CAN, etc)
B) serio - mostly used for input devices
C) direct use of UART port taking control fromserial_core.Quoted 3 lines
The best match I have found so far is MFD driver for Atmel Microcontroller on iPaq h3xxx (
drivers/mfd/ipaq-micro.c) that follows concept "C)"There's also D) TTY slave device support: https://lkml.org/lkml/2015/3/18/40
Quoted 8 lines
Quoted 3 lines
Unfortunately this hasn't made it to mainline yet and it seems the parties lost interest after some lengthy discussion of device tree phandles vs. subnodes, but I think this is what you're looking for.
Thank you for pointing out to another option. Looks like it was developed a little further and was submitted as patch by "H. Nikolaus Schaller",
https://lkml.org/lkml/2015/10/16/729But I see no further traces of it.
Well, I was still missing a technical discussion of our proposals and a real evaluation of the benefits of subnode vs. phandle. In my view it was very ideologic and it was not an exchange of arguments.
Quoted 1 line
Cc'ed Nikolaus, may be he could comment on state of UART slave patch.
And we are currently working on a compromise. So that the DT developer can simply choose if he prefers subnode or phandle. And the driver is capable of handling both. This is not yet finished, so we have not yet submitted an update.
BR,
Nikolaus