On 15.01.2019 23:32, Florian Fainelli wrote:
> On 1/15/19 12:33 PM, Heiner Kallweit wrote:
>> When requesting the PHY driver module fails we'll bind the genphy
>> driver later. This isn't obvious to the user and may cause, depending
>> on the PHY, different types of issues. Therefore check the retu
> I explicitly check for ret < 0. If there's no PHY driver module for
> a specific PHY ID then the return code would be > 0.
> My understanding of request_module() is that a return code < 0
> is returned if something bad happens in modprobe() call as such.
Ah, O.K. I was expecting an ENODEV or sim
On 1/15/19 12:33 PM, Heiner Kallweit wrote:
> When requesting the PHY driver module fails we'll bind the genphy
> driver later. This isn't obvious to the user and may cause, depending
> on the PHY, different types of issues. Therefore check the return code
> of request_module() and inform the user
On 15.01.2019 22:52, Heiner Kallweit wrote:
> On 15.01.2019 22:43, Andrew Lunn wrote:
>> On Tue, Jan 15, 2019 at 09:33:52PM +0100, Heiner Kallweit wrote:
>>> When requesting the PHY driver module fails we'll bind the genphy
>>> driver later. This isn't obvious to the user and may cause, depending
>
On 15.01.2019 22:43, Andrew Lunn wrote:
> On Tue, Jan 15, 2019 at 09:33:52PM +0100, Heiner Kallweit wrote:
>> When requesting the PHY driver module fails we'll bind the genphy
>> driver later. This isn't obvious to the user and may cause, depending
>> on the PHY, different types of issues. Therefor
On Tue, Jan 15, 2019 at 09:33:52PM +0100, Heiner Kallweit wrote:
> When requesting the PHY driver module fails we'll bind the genphy
> driver later. This isn't obvious to the user and may cause, depending
> on the PHY, different types of issues. Therefore check the return code
> of request_module()
