On Sat, Mar 16, 2024 at 02:17:24AM +0530, Ayush Singh wrote:
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-onboard socket standard that offers maximum expandability withthe smallest number of pins. The mikroBUS driver instantiatesdevices on a mikroBUS port described by identifying data presentin an add-on board resident EEPROM, more details on the mikroBUSdriver 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-s...
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.
MikroElektronika _owns_ the standard for mikroBUS, they're the ones who publish it and it has their logo plastered all over it.
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.
None of the MikroElektronika "click" boards that I have (and thus officially produced boards) have any ID EEPROM on them, so your statement is false. For example, if you look at the "relay click" board schematic:
https://download.mikroe.com/documents/add-on-boards/click/relay/relay-click-...
you will find no EEPROM.
The "relay 3" click board also doesn't:
https://download.mikroe.com/documents/add-on-boards/click/relay-3/relay-3-sc...
However, the "relay 4" click board does:
https://download.mikroe.com/documents/add-on-boards/click/relay_4_click/Rela...
Now, ClickID is relatively new. Note that the mikroBUS standard dates from 2011, with v2 coming out in 2015. A blog post introducing ClickID was posted in November 2023, just some 5 months ago, so that leaves an awful lot of click boards out there at the moment which have no EEPROM on them.
If what you have written assumes that all click boards have this EEPROM then you are - in my opinion - intolerably constraining the usefulness of your idea for those of us who have click boards bought over the past few years, and this will confuse users who have these older boards. "I've enabled mikroBUS support in the kernel, but my board isn't recognised" will probably end up being a regular cry from people with this.
So, I think you need to consider how to support the already vast number of click boards that do not support ClickID.
At the moment, my own personal solution is currently to hack the platform's DT file for the board I wish to use, creating a new variant of the platform which configures the SoC so the mikroBUS connector pins are appropriately configured. It would be good to get away from the need to do that.