Getting your opinion about the best place to put one specific device driver...
Hello, Arnd, Olof. First, let me introduce myself quickly. I am working in Stericsson and i am a colleague of Linus Walleij. We are currently doing some cleaning in our mach-ux500 ARM machine.
Among other things, the U8500 SoC and its derivatives embed one small IP called the "hardware observer".
This is used for hardware debug purpose and it provides the ability to output some
modem, power, clocking, ..., hardware signals on 18 external wires.
We did one small platform device driver to handle this piece of hardware. In the patch attached to this file, we kept the code in the mach-ux500 machine folder.
But we are wondering where is the best place to put that stuff. So, the question is: where should we put this code in the kernel tree ?
Thanks in advance for your advises.
Regards. Jean-Nicolas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-ux500-introduce-hardware-observer-platform-drive.patch
Type: text/x-diff
Size: 27999 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130212/4c348ce9/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ARM-ux500-remove-hardware-observer-machine-code.patch
Type: text/x-diff
Size: 25978 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130212/4c348ce9/attachment-0003.bin>
Quoted 10 lines · Jean-Nicolas GRAUX
ello, Arnd, Olof. First, let me introduce myself quickly. I am working in Stericsson and i am a colleague of Linus Walleij. We are currently doing some cleaning in our mach-ux500 ARM machine.
Among other things, the U8500 SoC and its derivatives embed one small IP called the "hardware observer".
This is used for hardware debug purpose and it provides the ability to output some
modem, power, clocking, ..., hardware signals on 18 external wires.
Quoted 5 lines
We did one small platform device driver to handle this piece of hardware. In the patch attached to this file, we kept the code in the mach-ux500 machine folder.
But we are wondering where is the best place to put that stuff. So, the question is: where should we put this code in the kernel tree ?
Hi Jean-Nicolas,
I think I need some more information to understand what that interface you are driving is actually about, since that is not clear from your description or from reading the source code.
Why are there exactly 18 wires?
What is the protocol that is used on these wires (i2c, spi, rs232, ...)
Why do you actually need run-time configuration in the kernel?
It does look however like this code is related to the PRCMU, so maybe it should be part of the prcmu driver rather than a separate device?
Arnd
Arnd, here are my answers below.
Le 02/12/2013 03:54 PM, Arnd Bergmann a ?crit :
Quoted 17 lines · Jean-Nicolas GRAUX
Quoted 10 lines
ello, Arnd, Olof. First, let me introduce myself quickly. I am working in Stericsson and i am a colleague of Linus Walleij. We are currently doing some cleaning in our mach-ux500 ARM machine.
Among other things, the U8500 SoC and its derivatives embed one small IP called the "hardware observer".
This is used for hardware debug purpose and it provides the ability to output some
modem, power, clocking, ..., hardware signals on 18 external wires.Quoted 5 lines
We did one small platform device driver to handle this piece of hardware. In the patch attached to this file, we kept the code in the mach-ux500 machine folder.
But we are wondering where is the best place to put that stuff. So, the question is: where should we put this code in the kernel tree ?
Quoted 7 lines
Hi Jean-Nicolas,
I think I need some more information to understand what that interface you are driving is actually about, since that is not clear from your description or from reading the source code.
Why are there exactly 18 wires?
As you can imagine, this module is very specific to the ux500 digital baseband family.
So, ux500 SoCs simply provide 18 external IOs that may be used to observe some critical hardware signals.
Depending on what has been configured in the hwobs control registers, we are able to observe
signals from the modem, the ddr controllers, the prcmu, the gfx ip, the clock tree, ...
Quoted 2 lines
What is the protocol that is used on these wires (i2c, spi, rs232, ...)
There is no specific devices connected behind those wires. So, no protocol used.
Usually, once the required configuration has been set thanks to the debugfs interface,
we directly monitor the signals by connecting the wires to a oscilloscope or a digital analyser...
Quoted 2 lines
Why do you actually need run-time configuration in the kernel?
Main aim of this driver is just to provide a user interface to configure/enable the hardware observer
so that we may easily select the required signals to observe. Having that at run time is mandatory for us.
This is mainly used by software/hardware teams to debug and verify modem/ape power states.
Quoted 3 lines
It does look however like this code is related to the PRCMU, so maybe it should be part of the prcmu driver rather than a separate device?
It is true that the hardware observer registers are located in the "PRCM" unit.
But to my mind, it has no real link with the dbx500-prcmu driver itself yet. (dbx500-prcmu driver is dedicated to the handling of the communication between the kernel and the firmware that run inside PRCMU xp70 controller.) Moreover, I think we should keep a separate device for the harware observer since it need to acquire its own pinctrl state.
That said, we might consider moving it to the mfd folder ?
To be honest, in my initial patch, i was aiming to put the ux500_hwobs.* files in the "misc" folder.
But Linus told me that this was probably not the good place ;) Regards.
Quoted 2 lines
Arnd
Hi,
Quoted 26 lines · Jean-Nicolas GRAUX
Arnd, here are my answers below.
Le 02/12/2013 03:54 PM, Arnd Bergmann a ?crit :
Quoted 16 lines · Jean-Nicolas GRAUX
Quoted 10 lines
ello, Arnd, Olof. First, let me introduce myself quickly. I am working in Stericsson and i am a colleague of Linus Walleij. We are currently doing some cleaning in our mach-ux500 ARM machine.
Among other things, the U8500 SoC and its derivatives embed one small IP called the "hardware observer".
This is used for hardware debug purpose and it provides the ability to output some
modem, power, clocking, ..., hardware signals on 18 external wires.Quoted 5 lines
We did one small platform device driver to handle this piece of hardware. In the patch attached to this file, we kept the code in the mach-ux500 machine folder.
But we are wondering where is the best place to put that stuff. So, the question is: where should we put this code in the kernel tree ?Quoted 7 lines
Hi Jean-Nicolas,
I think I need some more information to understand what that interface you are driving is actually about, since that is not clear from your description or from reading the source code.
Why are there exactly 18 wires?
Quoted 8 lines
As you can imagine, this module is very specific to the ux500 digital baseband family.
So, ux500 SoCs simply provide 18 external IOs that may be used to observe some critical hardware signals.
Depending on what has been configured in the hwobs control registers, we are able to observe
signals from the modem, the ddr controllers, the prcmu, the gfx ip, the clock tree, ...
Sounds very similar to what we have on omaps as hwobs. AFAIK that module is just multiplexing signals. So maybe take a look how it would fit into drivers/pinctrl?
At least the omap hwobs could in theory already be handled by pinctrl-single.c.
Regards,
Tony
Quoted 7 lines · Jean-Nicolas GRAUX
Le 02/12/2013 03:54 PM, Arnd Bergmann a ?crit :
Quoted 6 lines · Jean-Nicolas GRAUX
I think I need some more information to understand what that interface you are driving is actually about, since that is not clear from your description or from reading the source code.
Why are there exactly 18 wires?
Quoted 8 lines
As you can imagine, this module is very specific to the ux500 digital baseband family.
So, ux500 SoCs simply provide 18 external IOs that may be used to observe some critical hardware signals.
Depending on what has been configured in the hwobs control registers, we are able to observe
signals from the modem, the ddr controllers, the prcmu, the gfx ip, the clock tree, ...
Ah, so these are signals that are internal to the SoC and that normally don't need to get routed to a pad unless you want to monitor them, right?
Quoted 7 lines
Quoted 1 line
What is the protocol that is used on these wires (i2c, spi, rs232, ...)
There is no specific devices connected behind those wires. So, no protocol used.
Usually, once the required configuration has been set thanks to the debugfs interface,
we directly monitor the signals by connecting the wires to a oscilloscope or a digital analyser...
Ok.
Quoted 7 lines
Quoted 1 line
Why do you actually need run-time configuration in the kernel?
Main aim of this driver is just to provide a user interface to configure/enable the hardware observer
so that we may easily select the required signals to observe. Having that at run time is mandatory for us.
This is mainly used by software/hardware teams to debug and verify modem/ape power states.
Ok, I see.
Quoted 12 lines
Quoted 2 lines
It does look however like this code is related to the PRCMU, so maybe it should be part of the prcmu driver rather than a separate device?
It is true that the hardware observer registers are located in the "PRCM" unit.
But to my mind, it has no real link with the dbx500-prcmu driver itself yet. (dbx500-prcmu driver is dedicated to the handling of the communication between the kernel and the firmware that run inside PRCMU xp70 controller.) Moreover, I think we should keep a separate device for the harware observer since it need to acquire its own pinctrl state.
That said, we might consider moving it to the mfd folder ?
Quoted 3 lines
To be honest, in my initial patch, i was aiming to put the ux500_hwobs.* files in the "misc" folder.
But Linus told me that this was probably not the good place ;)
Correct, I try my best to avoid adding random stuff in there that might need a generic interface later. Tony already pointed out the similarity to the OMAP specific hwopbs feature, and whatever user interface we introduce for one should be generic enough to work on the other one as well, and ideally also on future ones to the degree that we can anticipate them today.
I like the idea of making the in-kernel configuration part of this a pinctrl driver, which would already allow you to configure it through a custom device tree and no user interface at all.
If a more dynamic user interface is needed, I think it would be good to have a generic mechanism in the pinctrl subsystem to reroute pins like these, which can work for all pins in the system (or at least those that have not been claimed by another device). I don't know if that interface already exists, but Linus would be the right person to answer that.
If there is a generic way to configure pinmux from user space, you can essentially move this driver into an application running outside of the kernel.
Arnd
Le 02/12/2013 06:41 PM, Arnd Bergmann a ?crit :
Quoted 16 lines · Jean-Nicolas GRAUX
Quoted 7 lines
Le 02/12/2013 03:54 PM, Arnd Bergmann a ?crit :
Quoted 6 lines · Jean-Nicolas GRAUX
I think I need some more information to understand what that interface you are driving is actually about, since that is not clear from your description or from reading the source code.
Why are there exactly 18 wires?
Quoted 8 lines
As you can imagine, this module is very specific to the ux500 digital baseband family.
So, ux500 SoCs simply provide 18 external IOs that may be used to observe some critical hardware signals.
Depending on what has been configured in the hwobs control registers, we are able to observe
signals from the modem, the ddr controllers, the prcmu, the gfx ip, the clock tree, ...
Quoted 2 lines
Ah, so these are signals that are internal to the SoC and that normally don't need to get routed to a pad unless you want to monitor them, right?
Yes.
Quoted 39 lines
Quoted 7 lines
Quoted 1 line
What is the protocol that is used on these wires (i2c, spi, rs232, ...)
There is no specific devices connected behind those wires. So, no protocol used.
Usually, once the required configuration has been set thanks to the debugfs interface,
we directly monitor the signals by connecting the wires to a oscilloscope or a digital analyser...Ok.
Quoted 7 lines
Quoted 1 line
Why do you actually need run-time configuration in the kernel?
Main aim of this driver is just to provide a user interface to configure/enable the hardware observer
so that we may easily select the required signals to observe. Having that at run time is mandatory for us.
This is mainly used by software/hardware teams to debug and verify modem/ape power states.Ok, I see.
Quoted 11 lines
Quoted 2 lines
It does look however like this code is related to the PRCMU, so maybe it should be part of the prcmu driver rather than a separate device?
It is true that the hardware observer registers are located in the "PRCM" unit.
But to my mind, it has no real link with the dbx500-prcmu driver itself yet. (dbx500-prcmu driver is dedicated to the handling of the communication between the kernel and the firmware that run inside PRCMU xp70 controller.) Moreover, I think we should keep a separate device for the harware observer since it need to acquire its own pinctrl state.
That said, we might consider moving it to the mfd folder ?Quoted 3 lines
To be honest, in my initial patch, i was aiming to put the ux500_hwobs.* files in the "misc" folder.
But Linus told me that this was probably not the good place ;)Correct, I try my best to avoid adding random stuff in there that might need a generic interface later. Tony already pointed out the similarity to the OMAP specific hwopbs feature, and whatever user interface we introduce for one should be generic enough to work on the other one as well, and ideally also on future ones to the degree that we can anticipate them today.
Quoted 3 lines
I like the idea of making the in-kernel configuration part of this a pinctrl driver, which would already allow you to configure it through a custom device tree and no user interface at all.
Yes, that would be nice for sure.
Quoted 6 lines
If a more dynamic user interface is needed, I think it would be good to have a generic mechanism in the pinctrl subsystem to reroute pins like these, which can work for all pins in the system (or at least those that have not been claimed by another device). I don't know if that interface already exists, but Linus would be the right person to answer that.
I think i have one colleague that recently made a patch for that purpose. But i believe this is still in progress. It consists in improving the pinctrl
debugfs interface to be able to manually change the pin muxing and the gpio configuration for debug/testing purpose.
Quoted 5 lines
If there is a generic way to configure pinmux from user space, you can essentially move this driver into an application running outside of the kernel.
Arnd
The matter is that this hwobs driver do more than just changing the muxing of one pin group in the digital baseband.
It also control some specific registers to configure the hwobs IP. More in details, for each of the 18 external IOs, it is possible to select one observer mode among several. We also provide some facility for the user to easily detect the pin to monitor on the output connector.
Anyway, maybe this could be handled in one dedicated pinctrl driver as suggested by Tony.
Thank you for your advises.
Jean-Nicolas.
Quoted 9 lines · Jean-Nicolas GRAUX
Le 02/12/2013 06:41 PM, Arnd Bergmann a ?crit :
Quoted 7 lines · Jean-Nicolas GRAUX
If a more dynamic user interface is needed, I think it would be good to have a generic mechanism in the pinctrl subsystem to reroute pins like these, which can work for all pins in the system (or at least those that have not been claimed by another device). I don't know if that interface already exists, but Linus would be the right person to answer that.
Quoted 5 lines
I think i have one colleague that recently made a patch for that purpose. But i believe this is still in progress. It consists in improving the pinctrl
debugfs interface to be able to manually change the pin muxing and the gpio configuration for debug/testing purpose.
Sounds good to me. Peter, Tony, do you think that would be a good enough interface for other platforms as well?
Quoted 11 lines
Quoted 4 lines
If there is a generic way to configure pinmux from user space, you can essentially move this driver into an application running outside of the kernel.
The matter is that this hwobs driver do more than just changing the muxing of one pin group in the digital baseband.
It also control some specific registers to configure the hwobs IP. More in details, for each of the 18 external IOs, it is possible to select one observer mode among several. We also provide some facility for the user to easily detect the pin to monitor on the output connector.
Hmm, I wonder if that is something that makes sense to have in a generic pinctrl debugfs interface. Maybe it can instead be part of the new pinctrl driver for this hw block then, which should be able to create additional sysfs files in the pinctrl debugfs directories. Linus, does that make sense to you?
Arnd
Quoted 10 lines · Arnd Bergmann
Quoted 9 lines · Jean-Nicolas GRAUX
Le 02/12/2013 06:41 PM, Arnd Bergmann a ?crit :
Quoted 7 lines · Jean-Nicolas GRAUX
If a more dynamic user interface is needed, I think it would be good to have a generic mechanism in the pinctrl subsystem to reroute pins like these, which can work for all pins in the system (or at least those that have not been claimed by another device). I don't know if that interface already exists, but Linus would be the right person to answer that.
Quoted 8 lines
Quoted 5 lines
I think i have one colleague that recently made a patch for that purpose. But i believe this is still in progress. It consists in improving the pinctrl
debugfs interface to be able to manually change the pin muxing and the gpio configuration for debug/testing purpose.Sounds good to me. Peter, Tony, do you think that would be a good enough interface for other platforms as well?
Yes debugfs is the way to go for modifying the hwobs settings.
Quoted 12 lines
Quoted 11 lines
Quoted 4 lines
If there is a generic way to configure pinmux from user space, you can essentially move this driver into an application running outside of the kernel.
The matter is that this hwobs driver do more than just changing the muxing of one pin group in the digital baseband.
It also control some specific registers to configure the hwobs IP. More in details, for each of the 18 external IOs, it is possible to select one observer mode among several. We also provide some facility for the user to easily detect the pin to monitor on the output connector.
Quoted 5 lines
Hmm, I wonder if that is something that makes sense to have in a generic pinctrl debugfs interface. Maybe it can instead be part of the new pinctrl driver for this hw block then, which should be able to create additional sysfs files in the pinctrl debugfs directories. Linus, does that make sense to you?
Makes sense to me.
And pinctrl does not need to have any knowledge of the names of the hwobs signals etc. That can all be done in a user space app modifying the pinctrl registers via debugs.
Regards,
Tony
Quoted 17 lines · Tony Lindgren
Quoted 16 lines · Arnd Bergmann
Quoted 14 lines · Jean-Nicolas GRAUX
Le 02/12/2013 06:41 PM, Arnd Bergmann a ?crit :
Quoted 7 lines · Jean-Nicolas GRAUX
If a more dynamic user interface is needed, I think it would be good to have a generic mechanism in the pinctrl subsystem to reroute pins like these, which can work for all pins in the system (or at least those that have not been claimed by another device). I don't know if that interface already exists, but Linus would be the right person to answer that.
I think i have one colleague that recently made a patch for that purpose. But i believe this is still in progress. It consists in improving the pinctrl
debugfs interface to be able to manually change the pin muxing and the gpio configuration for debug/testing purpose.
Quoted 4 lines
Quoted 2 lines
Sounds good to me. Peter, Tony, do you think that would be a good enough interface for other platforms as well?
Yes debugfs is the way to go for modifying the hwobs settings.
Agreed. debugfs would be fine.
Cheers,
Peter.
Quoted 10 lines · Arnd Bergmann
Quoted 9 lines · Jean-Nicolas GRAUX
Le 02/12/2013 06:41 PM, Arnd Bergmann a ?crit :
Quoted 7 lines · Jean-Nicolas GRAUX
If a more dynamic user interface is needed, I think it would be good to have a generic mechanism in the pinctrl subsystem to reroute pins like these, which can work for all pins in the system (or at least those that have not been claimed by another device). I don't know if that interface already exists, but Linus would be the right person to answer that.
Quoted 8 lines
Quoted 5 lines
I think i have one colleague that recently made a patch for that purpose. But i believe this is still in progress. It consists in improving the pinctrl
debugfs interface to be able to manually change the pin muxing and the gpio configuration for debug/testing purpose.Sounds good to me. Peter, Tony, do you think that would be a good enough interface for other platforms as well?
We're talking about this:
http://marc.info/?l=linux-kernel&m=136052713530502&w=2
We're discussing it right now but Stephen Warren has some valid concerns so I'm pondering the right way forward.
However that patch is about pin configuration, which is dealing with an opaque unsigned long. This usecase would be a debugfs interface to set up muxing and a totally different piece of code in drivers/pinctrl/pinmux.c. But I think it's a good idea!
Traditionally, hardware observation and stuff like this has been kept out of the mainline kernel, and the fact that we're getting to it now is due to the fact that all the basic stuff is already quite nicely lined up. So it's basically a good sign.
Quoted 12 lines
Quoted 11 lines
Quoted 4 lines
If there is a generic way to configure pinmux from user space, you can essentially move this driver into an application running outside of the kernel.
The matter is that this hwobs driver do more than just changing the muxing of one pin group in the digital baseband.
It also control some specific registers to configure the hwobs IP. More in details, for each of the 18 external IOs, it is possible to select one observer mode among several. We also provide some facility for the user to easily detect the pin to monitor on the output connector.
Quoted 5 lines
Hmm, I wonder if that is something that makes sense to have in a generic pinctrl debugfs interface. Maybe it can instead be part of the new pinctrl driver for this hw block then, which should be able to create additional sysfs files in the pinctrl debugfs directories. Linus, does that make sense to you?
That is one way to achieve it, like this driver spawns some custom debugfs entries, fine.
The hardware observer already use the pinctrl interfaces from pinctrl-nomadik.c to set up the pins per se: i.e. to set up so that these pins are available to put signals on. But then we can plug this stuff as a front-end, and yeah. drivers/pinctrl/ux500-hwobs.c might be a good idea!
Yours,
Linus Walleij
Quoted 6 lines · Linus Walleij
The hardware observer already use the pinctrl interfaces from
pinctrl-nomadik.cto set up the pins per se: i.e. to set up so that these pins are available to put signals on. But then we can plug this stuff as a front-end, and yeah.drivers/pinctrl/ux500-hwobs.cmight be a good idea!
Just please try to keep the data added to kernel to minimum..
The user space app can decipher what each register means based on the register address + SoC model. Kernel just needs to be able to route the signals.
Otherwise we'll end up with data for each SoC in the kernel, which we're trying to avoid :)
Regards,
Tony
Quoted 8 lines
Correct, I try my best to avoid adding random stuff in there that might need a generic interface later. Tony already pointed out the similarity to the OMAP specific hwopbs feature, and whatever user interface we introduce for one should be generic enough to work on the other one as well, and ideally also on future ones to the degree that we can anticipate them today.
Quoted 4 lines
I like the idea of making the in-kernel configuration part of this a pinctrl driver, which would already allow you to configure it through a custom device tree and no user interface at all.
Having done significant work with the OMAP3 hwobs feature, you really want a userinterface. At least OMAP3 has limitations on which signal can be monitored on which hwobs pin. This means that depending on the measurements you want to do, you need to change the configuration. If you want to automate several measurements, having a user interface (eg using debugfs), makes things much easier. Also when using this for debugging, you probably will have to experiment with which signals to monitor to rootcause the problem. Also then having a userinterface will be much easier than modifying the devicetree and rebooting the system.
Cheers,
Peter.
Le 02/13/2013 10:45 AM, Peter De Schrijver a ?crit :
Quoted 21 lines
Quoted 11 lines
Correct, I try my best to avoid adding random stuff in there that might need a generic interface later. Tony already pointed out the similarity to the OMAP specific hwopbs feature, and whatever user interface we introduce for one should be generic enough to work on the other one as well, and ideally also on future ones to the degree that we can anticipate them today.
I like the idea of making the in-kernel configuration part of this a pinctrl driver, which would already allow you to configure it through a custom device tree and no user interface at all.
Having done significant work with the OMAP3 hwobs feature, you really want a userinterface. At least OMAP3 has limitations on which signal can be monitored on which hwobs pin. This means that depending on the measurements you want to do, you need to change the configuration. If you want to automate several measurements, having a user interface (eg using debugfs), makes things much easier. Also when using this for debugging, you probably will have to experiment with which signals to monitor to rootcause the problem. Also then having a userinterface will be much easier than modifying the devicetree and rebooting the system.
Quoted 4 lines
Cheers,
Peter.
Yep, that's true.
Quoted 22 lines · Jean-Nicolas GRAUX
Le 02/13/2013 10:45 AM, Peter De Schrijver a ?crit :
Quoted 11 lines
Quoted 11 lines
Correct, I try my best to avoid adding random stuff in there that might need a generic interface later. Tony already pointed out the similarity to the OMAP specific hwopbs feature, and whatever user interface we introduce for one should be generic enough to work on the other one as well, and ideally also on future ones to the degree that we can anticipate them today.
I like the idea of making the in-kernel configuration part of this a pinctrl driver, which would already allow you to configure it through a custom device tree and no user interface at all.
Quoted 10 lines
Having done significant work with the OMAP3 hwobs feature, you really want a userinterface. At least OMAP3 has limitations on which signal can be monitored on which hwobs pin. This means that depending on the measurements you want to do, you need to change the configuration. If you want to automate several measurements, having a user interface (eg using debugfs), makes things much easier. Also when using this for debugging, you probably will have to experiment with which signals to monitor to rootcause the problem. Also then having a userinterface will be much easier than modifying the devicetree and rebooting the system.
Quoted 1 line
Yep, that's true.
Yeah user space is the way to go for toggling the settings. For omap hwobs, that all should be pretty close doable via debugfs with pinctrl-single.c + the patches posted by Haojian to add debugfs write support.
Regards,
Tony
Quoted 5 lines · Jean-Nicolas GRAUX
We did one small platform device driver to handle this piece of hardware. In the patch attached to this file, we kept the code in the mach-ux500 machine folder.
But we are wondering where is the best place to put that stuff. So, the question is: where should we put this code in the kernel tree ?
That is one of the most difficult questions...
Definitely not in arch/arm. Device drivers do not belong under arch/ but under the drivers/ subtree. Several possibilities:
drivers/platform/<appropriate-new-subdirectory>
drivers/misc/<appropriate-new-subdirectory>drivers/misc
Also, consider getting rid of:
Quoted 2 lines
ST-Ericsson-ID: 478266
ST-Ericsson-FOSS-OUT-ID: Trivial
from your commit messages when you submit this upstream.
Quoted 8 lines
(quoted diff) +8
-0+static const char readme[] = + "\nHardware observer usage:\n\n" + "./available_modes: List supported hardware observer modes.\n" + "./ddr_select: Set/get current ddr instance (0|1) to monitor.\n" + "./enable: Enable/disable hardware observer.\n" + "./gpio_x: Configure hardware observer IO number x in gpio output:\n" + " Write IO number followed by 1 or 0 to select high/low output.\n" + " example: echo \"12 1\" > gpio_x\n"
Review
Quoted 10 lines
(quoted diff) +10
-0+ "./mode: Force a mode to all hardware observer IOs.\n" + "./mode_x: Set mode to one harware observer IO:\n" + " Write IO number followed by mode to set current io mode:\n" + " example: echo \"12 wake-up\" > mode_x\n" + "./status: Show current mode of all hardware observer IOs.\n"; + +static int hwobs_readme(struct seq_file *s, void *p) +{ + return seq_printf(s, "%s", readme); +}
Eww, yuck, no. We do not do stuff like that. Put this in a file under Documentation/ documenting the interface rather than littering the debugfs with such things. I'm sure if you started something like a Documentation/filesystems/debugfs/ directory, you may make some new friends!