Le 22/03/2016 22:33, Sergei Shtylyov a écrit :
> On 03/22/2016 11:07 PM, David Miller wrote:
>
>>> On 03/22/2016 10:27 PM, Sergei Shtylyov wrote:
>>>
The driver calls gpiod_set_value() with GPIOD_OUT_* instead of 0 and
1, as
a result the PHY isn't really put back into reset state in
On 03/22/2016 11:07 PM, David Miller wrote:
On 03/22/2016 10:27 PM, Sergei Shtylyov wrote:
The driver calls gpiod_set_value() with GPIOD_OUT_* instead of 0 and
1, as
a result the PHY isn't really put back into reset state in
macb_remove().
Moreover, the driver assumes that something else has s
On 03/22/2016 11:07 PM, David Miller wrote:
The driver calls gpiod_set_value() with GPIOD_OUT_* instead of 0 and
1, as
a result the PHY isn't really put back into reset state in
macb_remove().
Moreover, the driver assumes that something else has set the GPIO
direction
to output, so if it has not
From: Sergei Shtylyov
Date: Tue, 22 Mar 2016 22:34:05 +0300
> On 03/22/2016 10:27 PM, Sergei Shtylyov wrote:
>
>> The driver calls gpiod_set_value() with GPIOD_OUT_* instead of 0 and
>> 1, as
>> a result the PHY isn't really put back into reset state in
>> macb_remove().
>> Moreover, the driver
On 03/22/2016 10:27 PM, Sergei Shtylyov wrote:
The driver calls gpiod_set_value() with GPIOD_OUT_* instead of 0 and 1, as
a result the PHY isn't really put back into reset state in macb_remove().
Moreover, the driver assumes that something else has set the GPIO direction
to output, so if it ha
The driver calls gpiod_set_value() with GPIOD_OUT_* instead of 0 and 1, as
a result the PHY isn't really put back into reset state in macb_remove().
Moreover, the driver assumes that something else has set the GPIO direction
to output, so if it has not, the PHY wouldn't be taken out of reset in
m
