<div data-ntes="ntes_mail_body_root" style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div id="spnEditorContent"><p style="margin: 0;"><br></p><p style="margin: 0;">Hi, </p><p style="margin: 0;"><br></p><p style="margin: 0;">Thx !</p><p style="margin: 0px;"><br></p><p style="margin: 0px;">i conducted an experiment, and no matter whether i configured it as </p><p style="margin: 0px;">GPIO_ACTIVE_LOW or GPIO_ACTIVE_HIGH in the dts, the resulting</p><p style="margin: 0px;">GPIO pin state was 0, indicating a low level.</p><p style="margin: 0px;"><br></p><p style="margin: 0px;"><br></p><p style="margin: 0px;">if (delays[2])</p><p style="margin: 0px;">    msleep(DIV_ROUND_UP(DELAYS[2], 1000));</p><p style="margin: 0px;"><br></p><p style="margin: 0px;">+ gpio_state = gpiod_get_value_can_sleep(reset_gpio);</p><p style="margin: 0px;">+ pr_info("gpio_state: %d\n", gpio_state);</p><p style="margin: 0;"><br></p><p style="margin: 0;"><br></p><p style="margin: 0;"><br></p></div><div style="position:relative;zoom:1"></div><div id="divNeteaseMailCard"></div><p style="margin: 0;"><br></p><pre><br>At 2025-07-09 01:40:06, "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
>On Tue, Jul 08, 2025 at 09:50:44AM -0700, Lizhe wrote:
>> some devices only reset when the GPIO is at a high level, but the
>> current function lacks support for such devices. add high-level
>> reset functionality to the function to support devices that require
>> high-level triggering for reset
>> 
>> Signed-off-by: Lizhe <sensor1010@163.com>
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> index 836f2848dfeb..cb989e6d7eac 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> @@ -458,6 +458,7 @@ int stmmac_mdio_reset(struct mii_bus *bus)
>>  
>>  #ifdef CONFIG_OF
>>        if (priv->device->of_node) {
>> +              int active_low = 0;
>>                struct gpio_desc *reset_gpio;
>>                u32 delays[3] = { 0, 0, 0 };
>>  
>> @@ -467,6 +468,9 @@ int stmmac_mdio_reset(struct mii_bus *bus)
>>                if (IS_ERR(reset_gpio))
>>                        return PTR_ERR(reset_gpio);
>>  
>> +              if (reset_gpio)
>> +                      active_low = gpiod_is_active_low(reset_gpio);
>> +
>>                device_property_read_u32_array(priv->device,
>>                                               "snps,reset-delays-us",
>>                                               delays, ARRAY_SIZE(delays));
>> @@ -474,11 +478,11 @@ int stmmac_mdio_reset(struct mii_bus *bus)
>>                if (delays[0])
>>                        msleep(DIV_ROUND_UP(delays[0], 1000));
>>  
>> -              gpiod_set_value_cansleep(reset_gpio, 1);
>> +              gpiod_set_value_cansleep(reset_gpio, active_low ? 1 : 0);
>>                if (delays[1])
>>                        msleep(DIV_ROUND_UP(delays[1], 1000));
>>  
>> -              gpiod_set_value_cansleep(reset_gpio, 0);
>> +              gpiod_set_value_cansleep(reset_gpio, active_low ? 0 : 1);
>>                if (delays[2])
>>                        msleep(DIV_ROUND_UP(delays[2], 1000));
>>        }
>
>NAK. Not required. The GPIO layer can cope with active-high and
>active-low signals declared in firmware without needing driver
>modification. Use the right data in the firmware and you don't
>need to patch.
>
>/* Bit 0 express polarity */
>#define GPIO_ACTIVE_HIGH 0
>#define GPIO_ACTIVE_LOW 1
>
>-- 
>RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
>FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
</pre></div><img style="width:1px;height:1px" src="https://count.mail.163.com/beacon/webmail.gif?type=webmail_mailtrace&guid=pre_dfccea5436c155349f247dca93ac1a22">