[RFC] net: stmmac: Problem with adding the native GPIOs support

[RFC] net: stmmac: Problem with adding the native GPIOs support

[Serge Semin]

Hello folks,

I've got a problem, which has been blowing by head up for more than three
weeks now, and I'm desperately need your help in that matter. See our
Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
has been synthesized with two GPIOs: one as GPI and another as GPO. There
are multiple Baikal-T1-based devices have been created so far with active
GMAC interface usage and each of them has been designed like this:

 +------------------------+
 | Baikal-T1 +------------+       +------------+
 |   SoC     | DW GMAC    |       |   Some PHY |
 |           |      Rx-clk+<------+Rx-clk      |
 |           |            |       |            |
 |           |         GPI+<------+#IRQ        |
 |           |            |       |            |
 |           |       RGMII+<----->+RGMII       |
 |           |        MDIO+<----->+MDIO        |
 |           |            |       |            |
 |           |         GPO+------>+#RST        |
 |           |            |       |            |
 |           |      Tx-clk+------>+Tx-clk      |
 |           |            |       |            |
 |           +------------+       +------------+
 +------------------------+

Each of such devices has got en external RGMII-PHY attached configured via the
MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
main peculiarity of such configuration is that the DW GMAC GPIOs have been used
to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't
been added to the STMMAC driver it's the very first setup for now, which has
been using them. Anyway the hardware setup depicted above doesn't seem
problematic at the first glance, but in fact it is. See, the DW *MAC driver
(STMMAC ethernet driver) is doing the MAC reset each time it performs the
device open or resume by means of the call-chain:

  stmmac_open()---+
                  +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
  stmmac_resume()-+

Such reset causes the whole interface reset: MAC, DMA and, what is more
important, GPIOs as being exposed as part of the MAC registers. That
in our case automatically causes the external PHY reset, what neither
the STTMAC driver nor the PHY subsystem expect at all.

Moreover the stmmac_reset() method polls the DMA_BUS_MODE.SFT_RESET flag
state to be sure the MAC is successfully completed. But since the external
PHY has got in reset state it doesn't generate the Rx-clk signal. Due to
that the MAC-DMA won't get out of the reset state so the stmmac_reset()
method will return timeout error. Of course I could manually restore the
GPIOs state in the stmmac_reset() before start to poll the SFT_RESET flag,
which may release the PHY reset. But that seems more like a workaround,
because the PHY still has been in reset and need to be reinitialized
anyway. Moreover some PHY may need to have more complicated reset cycle
with certain delays between RST assertion/de-assertion, so the workaround
won't work well for them.

To sum it up my question is what is the right way to resolve the problem
described above? My first idea was to just move the MAC reset from the
net-device open()/close() callbacks to the
stmmac_dvr_probe()/stmmac_dvr_remove() functions and don't reset the whole
interface on each device open. The problems we may have in that case is
due to the suspend/resume procedures, which for some reason require the
MAC reset too. That's why I need your help in this matter. Do you have any
idea how to gently add the GPIOs support and don't break the STMMAC
driver?

One more tiny question regarding the DW *MAC drivers available in kernel.
Aside of the DW GMAC Baikal-T1 SoC has also got DW xGMAC v2.11a embedded
with XPCS PHY attached. My question is what driver should we better use to
handle our xGMAC interface? AFAICS there are three DW *MAC-related drivers
the kernel currently provides:
1) drivers/net/ethernet/stmicro/stmmac
2) drivers/net/ethernet/amd/
3) drivers/net/ethernet/synopsys/
xGBE interface is supported by the drivers 1) and 2). In accordance with
https://www.spinics.net/lists/netdev/msg414148.html all xGMAC related
parts should have been added to 2), but recently the XGMAC support has
been added to 1). So I am confused what driver is now supposed to be used
for new xGMACs?

Regards,
-Sergey

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Alexandre Torgue]

Hi Serge,

Sorry I never used GPIO provided by DWMAC IP. Obviously, I think is to 
late for you to use GPIOs provided by your SoC directly. Unfortunately, 
it seems to be a "perfect" chicken and eggs problem :(.

Do you have possibilty to "play" with gpio setting. I mean change 
configuration of them (at least for reset one) before perform a DMA 
reset: If you have a pull-up on RST line and you could "disconnect" GPO 
inside GMAC then your PHY should remain on during DMA reset phase.

regards
Alex

On 12/14/20 10:25 AM, Serge Semin wrote:
> Hello folks,
> 
> I've got a problem, which has been blowing by head up for more than three
> weeks now, and I'm desperately need your help in that matter. See our
> Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
> has been synthesized with two GPIOs: one as GPI and another as GPO. There
> are multiple Baikal-T1-based devices have been created so far with active
> GMAC interface usage and each of them has been designed like this:
> 
>   +------------------------+
>   | Baikal-T1 +------------+       +------------+
>   |   SoC     | DW GMAC    |       |   Some PHY |
>   |           |      Rx-clk+<------+Rx-clk      |
>   |           |            |       |            |
>   |           |         GPI+<------+#IRQ        |
>   |           |            |       |            |
>   |           |       RGMII+<----->+RGMII       |
>   |           |        MDIO+<----->+MDIO        |
>   |           |            |       |            |
>   |           |         GPO+------>+#RST        |
>   |           |            |       |            |
>   |           |      Tx-clk+------>+Tx-clk      |
>   |           |            |       |            |
>   |           +------------+       +------------+
>   +------------------------+
> 
> Each of such devices has got en external RGMII-PHY attached configured via the
> MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
> main peculiarity of such configuration is that the DW GMAC GPIOs have been used
> to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't
> been added to the STMMAC driver it's the very first setup for now, which has
> been using them. Anyway the hardware setup depicted above doesn't seem
> problematic at the first glance, but in fact it is. See, the DW *MAC driver
> (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> device open or resume by means of the call-chain:
> 
>    stmmac_open()---+
>                    +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
>    stmmac_resume()-+
> 
> Such reset causes the whole interface reset: MAC, DMA and, what is more
> important, GPIOs as being exposed as part of the MAC registers. That
> in our case automatically causes the external PHY reset, what neither
> the STTMAC driver nor the PHY subsystem expect at all.
> 
> Moreover the stmmac_reset() method polls the DMA_BUS_MODE.SFT_RESET flag
> state to be sure the MAC is successfully completed. But since the external
> PHY has got in reset state it doesn't generate the Rx-clk signal. Due to
> that the MAC-DMA won't get out of the reset state so the stmmac_reset()
> method will return timeout error. Of course I could manually restore the
> GPIOs state in the stmmac_reset() before start to poll the SFT_RESET flag,
> which may release the PHY reset. But that seems more like a workaround,
> because the PHY still has been in reset and need to be reinitialized
> anyway. Moreover some PHY may need to have more complicated reset cycle
> with certain delays between RST assertion/de-assertion, so the workaround
> won't work well for them.
> 
> To sum it up my question is what is the right way to resolve the problem
> described above? My first idea was to just move the MAC reset from the
> net-device open()/close() callbacks to the
> stmmac_dvr_probe()/stmmac_dvr_remove() functions and don't reset the whole
> interface on each device open. The problems we may have in that case is
> due to the suspend/resume procedures, which for some reason require the
> MAC reset too. That's why I need your help in this matter. Do you have any
> idea how to gently add the GPIOs support and don't break the STMMAC
> driver?
> 
> One more tiny question regarding the DW *MAC drivers available in kernel.
> Aside of the DW GMAC Baikal-T1 SoC has also got DW xGMAC v2.11a embedded
> with XPCS PHY attached. My question is what driver should we better use to
> handle our xGMAC interface? AFAICS there are three DW *MAC-related drivers
> the kernel currently provides:
> 1) drivers/net/ethernet/stmicro/stmmac
> 2) drivers/net/ethernet/amd/
> 3) drivers/net/ethernet/synopsys/
> xGBE interface is supported by the drivers 1) and 2). In accordance with
> https://www.spinics.net/lists/netdev/msg414148.html all xGMAC related
> parts should have been added to 2), but recently the XGMAC support has
> been added to 1). So I am confused what driver is now supposed to be used
> for new xGMACs?
> 
> Regards,
> -Sergey
> 

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Serge Semin]

Hello Alexandre,

Thanks for the response. My comments are below.

On Mon, Dec 14, 2020 at 11:52:14AM +0100, Alexandre Torgue wrote:
> Hi Serge,
> 

> Sorry I never used GPIO provided by DWMAC IP. Obviously, I think is to late
> for you to use GPIOs provided by your SoC directly. Unfortunately, it seems
> to be a "perfect" chicken and eggs problem :(.

If you meant the problem that the PHY is getting reset together with
the MAC reset, then at some extent it's indeed the chicken-eggs
problem, but it affects the STMMAC driver only due to the
stmmac_reset() procedure implementation (it waits for the SWR flag
being cleared right in the same method, but the flag won't be cleared
until all the clocks are ready, which isn't possible until PHY reset
isn't cleared, so it causes the DMA-reset timeout). The solution of
that is simple. If we first performed the reset procedure, then
initialized/attached the PHY and after that would have made sure the
DMA_BUS_MODE.SFT_RESET flag was cleared, then the problem wouldn't be
even noticeable. But still that would have solved just a part of the
problem. The driver would still perform the MAC reset in the PM
resume() callback, which in my case will automatically reset the PHY,
while the PHY subsystem doesn't expect that.

So in order to make the driver properly working for any situation we
either need to take the possible PHY reset into account in both open()
and PM-resume() callbacks, or get rid of the reset completely there.

The perfect solution would be not to reset the MAC all the time on the
network device open and resume procedures. In that case we could have
reset the controller in the stmmac_dvr_probe() just once, then
register the GPIO interface and use it for the MDIO-bus, whatever with
no problems. What do you think of that? Is that even possible seeing,
for example, AMD xGBE driver doesn't reset the MAC on network dev
open?  Yeah, the GMAC manual states, that the DMA initialization needs
to start with the GMAC reset, but in fact do we really need to do that
all the time on the device open/resume? Wouldn't that be enough to
reset the device just on probe?

> 
> Do you have possibilty to "play" with gpio setting. I mean change
> configuration of them (at least for reset one) before perform a DMA reset:
> If you have a pull-up on RST line and you could "disconnect" GPO inside GMAC
> then your PHY should remain on during DMA reset phase.

Alas no. It is impossible to do anything with hardware now. We need to
deal with what we currently have. The GPO lane is externally
pulled-down to GND on all the Baikal-T1 SoC-based hardware and these
are not a single type of device, but multiple of them, which have been
produced for more than three years now. We also can't somehow
detach/disconnect GPO inside the GMAC or somehow else, because the SoC
has already been synthesized with no such feature. So when the GPIO
register is reset or the GPIO.GPO field is cleared PHY gets to be in
reset state, and it concerns all the devices.(

-Sergey

> 
> regards
> Alex
> 
> On 12/14/20 10:25 AM, Serge Semin wrote:
> > Hello folks,
> > 
> > I've got a problem, which has been blowing by head up for more than three
> > weeks now, and I'm desperately need your help in that matter. See our
> > Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
> > has been synthesized with two GPIOs: one as GPI and another as GPO. There
> > are multiple Baikal-T1-based devices have been created so far with active
> > GMAC interface usage and each of them has been designed like this:
> > 
> >   +------------------------+
> >   | Baikal-T1 +------------+       +------------+
> >   |   SoC     | DW GMAC    |       |   Some PHY |
> >   |           |      Rx-clk+<------+Rx-clk      |
> >   |           |            |       |            |
> >   |           |         GPI+<------+#IRQ        |
> >   |           |            |       |            |
> >   |           |       RGMII+<----->+RGMII       |
> >   |           |        MDIO+<----->+MDIO        |
> >   |           |            |       |            |
> >   |           |         GPO+------>+#RST        |
> >   |           |            |       |            |
> >   |           |      Tx-clk+------>+Tx-clk      |
> >   |           |            |       |            |
> >   |           +------------+       +------------+
> >   +------------------------+
> > 
> > Each of such devices has got en external RGMII-PHY attached configured via the
> > MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
> > main peculiarity of such configuration is that the DW GMAC GPIOs have been used
> > to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't
> > been added to the STMMAC driver it's the very first setup for now, which has
> > been using them. Anyway the hardware setup depicted above doesn't seem
> > problematic at the first glance, but in fact it is. See, the DW *MAC driver
> > (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> > device open or resume by means of the call-chain:
> > 
> >    stmmac_open()---+
> >                    +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
> >    stmmac_resume()-+
> > 
> > Such reset causes the whole interface reset: MAC, DMA and, what is more
> > important, GPIOs as being exposed as part of the MAC registers. That
> > in our case automatically causes the external PHY reset, what neither
> > the STTMAC driver nor the PHY subsystem expect at all.
> > 
> > Moreover the stmmac_reset() method polls the DMA_BUS_MODE.SFT_RESET flag
> > state to be sure the MAC is successfully completed. But since the external
> > PHY has got in reset state it doesn't generate the Rx-clk signal. Due to
> > that the MAC-DMA won't get out of the reset state so the stmmac_reset()
> > method will return timeout error. Of course I could manually restore the
> > GPIOs state in the stmmac_reset() before start to poll the SFT_RESET flag,
> > which may release the PHY reset. But that seems more like a workaround,
> > because the PHY still has been in reset and need to be reinitialized
> > anyway. Moreover some PHY may need to have more complicated reset cycle
> > with certain delays between RST assertion/de-assertion, so the workaround
> > won't work well for them.
> > 
> > To sum it up my question is what is the right way to resolve the problem
> > described above? My first idea was to just move the MAC reset from the
> > net-device open()/close() callbacks to the
> > stmmac_dvr_probe()/stmmac_dvr_remove() functions and don't reset the whole
> > interface on each device open. The problems we may have in that case is
> > due to the suspend/resume procedures, which for some reason require the
> > MAC reset too. That's why I need your help in this matter. Do you have any
> > idea how to gently add the GPIOs support and don't break the STMMAC
> > driver?
> > 
> > One more tiny question regarding the DW *MAC drivers available in kernel.
> > Aside of the DW GMAC Baikal-T1 SoC has also got DW xGMAC v2.11a embedded
> > with XPCS PHY attached. My question is what driver should we better use to
> > handle our xGMAC interface? AFAICS there are three DW *MAC-related drivers
> > the kernel currently provides:
> > 1) drivers/net/ethernet/stmicro/stmmac
> > 2) drivers/net/ethernet/amd/
> > 3) drivers/net/ethernet/synopsys/
> > xGBE interface is supported by the drivers 1) and 2). In accordance with
> > https://www.spinics.net/lists/netdev/msg414148.html all xGMAC related
> > parts should have been added to 2), but recently the XGMAC support has
> > been added to 1). So I am confused what driver is now supposed to be used
> > for new xGMACs?
> > 
> > Regards,
> > -Sergey
> > 

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Andrew Lunn]

On Mon, Dec 14, 2020 at 12:25:16PM +0300, Serge Semin wrote:
> Hello folks,
> 
> I've got a problem, which has been blowing by head up for more than three
> weeks now, and I'm desperately need your help in that matter. See our
> Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
> has been synthesized with two GPIOs: one as GPI and another as GPO. There
> are multiple Baikal-T1-based devices have been created so far with active
> GMAC interface usage and each of them has been designed like this:
> 
>  +------------------------+
>  | Baikal-T1 +------------+       +------------+
>  |   SoC     | DW GMAC    |       |   Some PHY |
>  |           |      Rx-clk+<------+Rx-clk      |
>  |           |            |       |            |
>  |           |         GPI+<------+#IRQ        |
>  |           |            |       |            |
>  |           |       RGMII+<----->+RGMII       |
>  |           |        MDIO+<----->+MDIO        |
>  |           |            |       |            |
>  |           |         GPO+------>+#RST        |
>  |           |            |       |            |
>  |           |      Tx-clk+------>+Tx-clk      |
>  |           |            |       |            |
>  |           +------------+       +------------+
>  +------------------------+
> 
> Each of such devices has got en external RGMII-PHY attached configured via the
> MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
> main peculiarity of such configuration is that the DW GMAC GPIOs have been used
> to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't
> been added to the STMMAC driver it's the very first setup for now, which has
> been using them.

It sounds like you need to cleanly implement a GPIO controller within
the stmmac driver. But you probably want to make it conditional on a
DT property. For example, look to see if there is the
'gpio-controller;'

> Anyway the hardware setup depicted above doesn't seem
> problematic at the first glance, but in fact it is. See, the DW *MAC driver
> (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> device open or resume by means of the call-chain:
> 
>   stmmac_open()---+
>                   +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
>   stmmac_resume()-+
> 
> Such reset causes the whole interface reset: MAC, DMA and, what is more
> important, GPIOs as being exposed as part of the MAC registers. That
> in our case automatically causes the external PHY reset, what neither
> the STTMAC driver nor the PHY subsystem expect at all.

Is the reset of the GPIO sub block under software control? When you
have a GPIO controller implemented, you would want to disable this.

Once you have a GPIO controller, you can make use of the standard PHY
DT properties to allow the PHY driver to make use of the interrupt,
and to control the reset of the PHY.

     Andrew

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Serge Semin]

Hello Andrew,

On Mon, Dec 14, 2020 at 04:31:43PM +0100, Andrew Lunn wrote:
> On Mon, Dec 14, 2020 at 12:25:16PM +0300, Serge Semin wrote:
> > Hello folks,
> > 
> > I've got a problem, which has been blowing by head up for more than three
> > weeks now, and I'm desperately need your help in that matter. See our
> > Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
> > has been synthesized with two GPIOs: one as GPI and another as GPO. There
> > are multiple Baikal-T1-based devices have been created so far with active
> > GMAC interface usage and each of them has been designed like this:
> > 
> >  +------------------------+
> >  | Baikal-T1 +------------+       +------------+
> >  |   SoC     | DW GMAC    |       |   Some PHY |
> >  |           |      Rx-clk+<------+Rx-clk      |
> >  |           |            |       |            |
> >  |           |         GPI+<------+#IRQ        |
> >  |           |            |       |            |
> >  |           |       RGMII+<----->+RGMII       |
> >  |           |        MDIO+<----->+MDIO        |
> >  |           |            |       |            |
> >  |           |         GPO+------>+#RST        |
> >  |           |            |       |            |
> >  |           |      Tx-clk+------>+Tx-clk      |
> >  |           |            |       |            |
> >  |           +------------+       +------------+
> >  +------------------------+
> > 
> > Each of such devices has got en external RGMII-PHY attached configured via the
> > MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The
> > main peculiarity of such configuration is that the DW GMAC GPIOs have been used
> > to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't
> > been added to the STMMAC driver it's the very first setup for now, which has
> > been using them.
> 

> It sounds like you need to cleanly implement a GPIO controller within
> the stmmac driver. But you probably want to make it conditional on a
> DT property. For example, look to see if there is the
> 'gpio-controller;'

Yeap, that's what I have already done. The problem is that the
GPOs state is getting reset together with the MAC reset. So we don't
have a full control over the GPOs state when the MAC gets reset.

> 
> > Anyway the hardware setup depicted above doesn't seem
> > problematic at the first glance, but in fact it is. See, the DW *MAC driver
> > (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> > device open or resume by means of the call-chain:
> > 
> >   stmmac_open()---+
> >                   +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
> >   stmmac_resume()-+
> > 
> > Such reset causes the whole interface reset: MAC, DMA and, what is more
> > important, GPIOs as being exposed as part of the MAC registers. That
> > in our case automatically causes the external PHY reset, what neither
> > the STTMAC driver nor the PHY subsystem expect at all.
> 

> Is the reset of the GPIO sub block under software control? When you
> have a GPIO controller implemented, you would want to disable this.

Not sure I've fully understood your question. The GPIO sub-block of
the MAC is getting reset together with the MAC. So when we reset the
MAC, the GPOs state will get reset too. Seeing the STMMAC driver
performs the reset on open() and resume() callbacks the GPIOs gets to
reset synchronously there too. That's the main problem. We can't
somehow change the MAC reset behavior. So it's either to get rid of
the reset or somehow take the results of the reset into account in
software (like reinitialize the PHY too after it).

> 
> Once you have a GPIO controller, you can make use of the standard PHY
> DT properties to allow the PHY driver to make use of the interrupt,
> and to control the reset of the PHY.

Yeah, that's what I initially intended to implement. If only the
GPIO-control register wasn't reset on the MAC reset, I wouldn't even
asked the question.

-Sergey

> 
>      Andrew

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Andrew Lunn]

> > > Anyway the hardware setup depicted above doesn't seem
> > > problematic at the first glance, but in fact it is. See, the DW *MAC driver
> > > (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> > > device open or resume by means of the call-chain:
> > > 
> > >   stmmac_open()---+
> > >                   +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
> > >   stmmac_resume()-+
> > > 
> > > Such reset causes the whole interface reset: MAC, DMA and, what is more
> > > important, GPIOs as being exposed as part of the MAC registers. That
> > > in our case automatically causes the external PHY reset, what neither
> > > the STTMAC driver nor the PHY subsystem expect at all.
> > 
> 
> > Is the reset of the GPIO sub block under software control? When you
> > have a GPIO controller implemented, you would want to disable this.
> 
> Not sure I've fully understood your question. The GPIO sub-block of
> the MAC is getting reset together with the MAC.

And my question is, is that under software control, or is the hardware
synthesised so that the GPIO controller is reset as part of the MAC
reset?

From what you are saying, it sounds like from software you cannot
independently control the GPIO controller reset?

This is something i would be asking the hardware people. Look at the
VHDL, etc.

      Andrew

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Serge Semin]

On Tue, Dec 15, 2020 at 02:58:37PM +0100, Andrew Lunn wrote:
> > > > Anyway the hardware setup depicted above doesn't seem
> > > > problematic at the first glance, but in fact it is. See, the DW *MAC driver
> > > > (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> > > > device open or resume by means of the call-chain:
> > > > 
> > > >   stmmac_open()---+
> > > >                   +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset().
> > > >   stmmac_resume()-+
> > > > 
> > > > Such reset causes the whole interface reset: MAC, DMA and, what is more
> > > > important, GPIOs as being exposed as part of the MAC registers. That
> > > > in our case automatically causes the external PHY reset, what neither
> > > > the STTMAC driver nor the PHY subsystem expect at all.
> > > 
> > 
> > > Is the reset of the GPIO sub block under software control? When you
> > > have a GPIO controller implemented, you would want to disable this.
> > 
> > Not sure I've fully understood your question. The GPIO sub-block of
> > the MAC is getting reset together with the MAC.
> 

> And my question is, is that under software control, or is the hardware
> synthesised so that the GPIO controller is reset as part of the MAC
> reset?

Alas the SoC has already been synthesized and multiple devices have
already been produced as I described in the initial message. So we can't
change the way the MAC reset works.

> 
> From what you are saying, it sounds like from software you cannot
> independently control the GPIO controller reset?

No. The hardware implements the default MAC reset behavior. So the
GPIO controller gets reset synchronously with the MAC reset and that
can't be changed.

> 
> This is something i would be asking the hardware people. Look at the
> VHDL, etc.

Alas it's too late. I have to fix it in software somehow. As I see it
the only possible ways to bypass the problem are either to re-init the
PHY each time the reset happens or somehow to get rid of the MAC
reset. That's why I have sent this RFC to ask the driver maintainers
whether my suggestions are correct or of a better idea to work around
the problem.

-Sergey

> 
>       Andrew

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Andrew Lunn]

> > From what you are saying, it sounds like from software you cannot
> > independently control the GPIO controller reset?
> 
> No. The hardware implements the default MAC reset behavior. So the
> GPIO controller gets reset synchronously with the MAC reset and that
> can't be changed.

Is there pinmux support for these pins?  Can you disconnect them from
the MAC? Often pins can be connected to different internal IP
blocks. Maybe you can flip the pin mux, perform the MAC reset, and
then put the pinmux back to connect the pins to the MAC IP again?

     Andrew

Re: [RFC] net: stmmac: Problem with adding the native GPIOs support

[Serge Semin]

On Wed, Dec 16, 2020 at 03:03:55AM +0100, Andrew Lunn wrote:
> > > From what you are saying, it sounds like from software you cannot
> > > independently control the GPIO controller reset?
> > 
> > No. The hardware implements the default MAC reset behavior. So the
> > GPIO controller gets reset synchronously with the MAC reset and that
> > can't be changed.
> 

> Is there pinmux support for these pins?  Can you disconnect them from
> the MAC? Often pins can be connected to different internal IP
> blocks. Maybe you can flip the pin mux, perform the MAC reset, and
> then put the pinmux back to connect the pins to the MAC IP again?

Alas no. Pins multiplexing isn't implemented in the Baikal-T1 SoC at all.
Each pin has been assigned with a single function. In this case DW GMAC
GPO/GPI pins always serve as GPO/GPI and nothing else.

-Sergey

> 
>      Andrew