| Message ID | 20240423233622.1494708-1-florian.fainelli@broadcom.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Define i2c_designware in a header file | expand |
Tue, Apr 23, 2024 at 04:36:18PM -0700, Florian Fainelli kirjoitti: > This patch series depends upon the following two patches being applied: > > https://lore.kernel.org/all/20240422084109.3201-1-duanqiangwen@net-swift.com/ > https://lore.kernel.org/all/20240422084109.3201-2-duanqiangwen@net-swift.com/ > > There is no reason why each driver should have to repeat the > "i2c_designware" string all over the place, because when that happens we > see the reverts like the above being necessary. Isn't that a part of ABI between drivers, i.e. whenever ones want to request_module() or so they need to know what they are doing, no?
On 4/23/2024 4:56 PM, Andy Shevchenko wrote: > Tue, Apr 23, 2024 at 04:36:18PM -0700, Florian Fainelli kirjoitti: >> This patch series depends upon the following two patches being applied: >> >> https://lore.kernel.org/all/20240422084109.3201-1-duanqiangwen@net-swift.com/ >> https://lore.kernel.org/all/20240422084109.3201-2-duanqiangwen@net-swift.com/ >> >> There is no reason why each driver should have to repeat the >> "i2c_designware" string all over the place, because when that happens we >> see the reverts like the above being necessary. > > Isn't that a part of ABI between drivers, i.e. whenever ones want to > request_module() or so they need to know what they are doing, no? Yes, the drivers should know, but as evidenced by the two patches above, there was still room for error. If we have to abide by a certain contract, which is platform_driver::driver::name, then we might as well have a header defining it no?
On Tue, Apr 23, 2024 at 06:21:21PM -0700, Florian Fainelli wrote: > On 4/23/2024 4:56 PM, Andy Shevchenko wrote: > > Tue, Apr 23, 2024 at 04:36:18PM -0700, Florian Fainelli kirjoitti: > > > This patch series depends upon the following two patches being applied: > > > > > > https://lore.kernel.org/all/20240422084109.3201-1-duanqiangwen@net-swift.com/ > > > https://lore.kernel.org/all/20240422084109.3201-2-duanqiangwen@net-swift.com/ > > > > > > There is no reason why each driver should have to repeat the > > > "i2c_designware" string all over the place, because when that happens we > > > see the reverts like the above being necessary. > > > > Isn't that a part of ABI between drivers, i.e. whenever ones want to > > request_module() or so they need to know what they are doing, no? > > Yes, the drivers should know, but as evidenced by the two patches above, > there was still room for error. If we have to abide by a certain contract, > which is platform_driver::driver::name, then we might as well have a header > defining it no? Maybe, I simply don't like the manipulations with parts of the device instance names / driver IDs / driver name, which all become mixed after this series.
On 4/24/24 07:26, Andy Shevchenko wrote: > On Tue, Apr 23, 2024 at 06:21:21PM -0700, Florian Fainelli wrote: >> On 4/23/2024 4:56 PM, Andy Shevchenko wrote: >>> Tue, Apr 23, 2024 at 04:36:18PM -0700, Florian Fainelli kirjoitti: >>>> This patch series depends upon the following two patches being applied: >>>> >>>> https://lore.kernel.org/all/20240422084109.3201-1-duanqiangwen@net-swift.com/ >>>> https://lore.kernel.org/all/20240422084109.3201-2-duanqiangwen@net-swift.com/ >>>> >>>> There is no reason why each driver should have to repeat the >>>> "i2c_designware" string all over the place, because when that happens we >>>> see the reverts like the above being necessary. >>> >>> Isn't that a part of ABI between drivers, i.e. whenever ones want to >>> request_module() or so they need to know what they are doing, no? >> >> Yes, the drivers should know, but as evidenced by the two patches above, >> there was still room for error. If we have to abide by a certain contract, >> which is platform_driver::driver::name, then we might as well have a header >> defining it no? > > Maybe, I simply don't like the manipulations with parts of the device instance > names / driver IDs / driver name, which all become mixed after this series. > That is fair enough, although there is definitively an expectation that the clock name will match the dev_name() of the i2c bus, which is why it changing or shortening the names as attempted by Duanqiang ended up not working. This call in i2c-designware-platdrv.c is: dev->clk = devm_clk_get_optional(&pdev->dev, NULL); and because the name is NULL, we end-up searching for a clock named dev_name(), and if we have a mismatch, then we won't find it. So the i2c_designware name is really something we must be sticking with, or change *globally* for a) device(s) binding to the driver and b) a successful clock search.