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/[email protected]/
> https://lore.kernel.org/all/[email protected]/
>
> 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?
--
With Best Regards,
Andy Shevchenko
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/[email protected]/
>> https://lore.kernel.org/all/[email protected]/
>>
>> 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?
--
Florian
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/[email protected]/
> > > https://lore.kernel.org/all/[email protected]/
> > >
> > > 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.
--
With Best Regards,
Andy Shevchenko
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/[email protected]/
>>>> https://lore.kernel.org/all/[email protected]/
>>>>
>>>> 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.
--
Florian