On Wed, Nov 25, 2020 at 6:09 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 11/25/20 12:20 PM, Andy Shevchenko wrote: > > On Wed, Nov 25, 2020 at 1:11 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >> On 11/25/20 11:55 AM, Andy Shevchenko wrote: ... > >> i2c-BOSC0200:base > > What if you have two devices with the same ID and both have two > > I2cSerialBusV2() resources? Second one can't be instantiated because > > 'base' is already here. > > Making it like i2c-BOSC0200:00.base would be much better in my opinion. > > Ah I see, that is a somewhat valid point. But I really never expect > there to be 2 ACPI devices with a BOSC0200 hw-id, while also specifying > more then 1 i2c-client per node. That would just be all kinds of messed-up. I also don't expect such, but probability is still greater than zero (somebody may copy'n'paste the ASL excerpt from this device and apply as SSDT in one of DIYs kinda projects). > Thinking about this I think that getting a WARN_ON (and thus a bug report) > about a duplicate kobject-name when this happens would actually be good, > because then we need to figure out what the beep is going on on that > system. Note that other then triggering a WARN_ON the second > i2c_acpi_new_device will simply fail in this very unlikely scenario > (I know because I triggered this by accident while working on the patch). > > Since in a way getting this WARN_ON is actually good (lets us know about > completely unexpected circumstances) and that making the name dynamic > as you suggest requires a bit of extra code I would actually prefer to > keep this as. Please let me know if that is ok with you. Can you put a comment in the code that this name is considered global for now as we do not expect such circumstances. Then I'll be fine. -- With Best Regards, Andy Shevchenko
