|
On 3/16/24 01:02, Russell King (Oracle) wrote: On Sat, Mar 16, 2024 at 12:19:05AM +0530, Ayush Singh wrote:diff --git a/drivers/misc/mikrobus/Kconfig b/drivers/misc/mikrobus/Kconfig new file mode 100644 index 000000000000..f0770006b4fe --- /dev/null +++ b/drivers/misc/mikrobus/Kconfig @@ -0,0 +1,19 @@ +menuconfig MIKROBUS + tristate "Module for instantiating devices on mikroBUS ports" + depends on GPIOLIB + depends on W1 + depends on W1_MASTER_GPIO + help + This option enables the mikroBUS driver. mikroBUS is an add-on + board socket standard that offers maximum expandability with + the smallest number of pins. The mikroBUS driver instantiates + devices on a mikroBUS port described by identifying data present + in an add-on board resident EEPROM, more details on the mikroBUS + driver support and discussion can be found in this eLinux wiki : + elinux.org/MikrobusI think this is a fallacy. I have boards that support Mikrobus - some of the SolidRun products do. I have several Mikrobus "click" boards. This help text seems to imply that Mikrobus click boards include an EEPROM that identify them, hence you make the support for mikroBUS depend on it. No, this is not the case - the click boards do not contain a 1-wire EEPROM. Please fetch a copy of the official Mikrobus specification which is available here: https://download.mikroe.com/documents/standards/mikrobus/mikrobus-standard-specification-v200.pdf and rather than creating something that is implementation specific but appears to be generic, create something that is generic with implementation specific extensions. I think you mean mikroBUS addon boards? mikroBUS is an open
socket and click boards™ are MikroElektronika’s brand of mikroBUS™
add-on boards. So I think all click boards™ do have clickID
support, but yes, mikroBUS spec is not the same as clickID and
thus are not mutually dependent.
You'll find if you search that document, no mention is made of an "eprom". "identification" is also not found. "one wire", "onewire", "1-wire", "1wire" are also not found. What I'm concerned about is if we create this "Mikrobus" subsystem which appears to be dependent on one-wire EEPROMs somewhere in the system, and then end up with a load of drivers for various mikroBUS boards, what about cases where there is no one-wire EEPROM? I think you might be misunderstanding the current driver (and clickID in general) a bit. The driver currently reads and parses mikroBUS manifest and registers the device to the kernel which then loads the appropriate kernel driver. What this means is there will not be mikrobus_xxx but rather the xxx driver will directly be used.
If I understand correctly, what you are suggesting is having a base mikroBUS driver that allows creating mikrobus_xxx board specific drivers and have a mikrobus_click driver (which uses the mikroBUS driver) to handle click and any 1-wire eeprom supporting mikroBUS addon boards?
Of course, feel free to correct me if I got something wrong.
Ayush Singh |
_______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx
|