net: macb: fail when there's no PHY

Several years back (circa 2.6.33) I had to hack up macb.c to work on an at91 board that didn't have a PHY connected to the macb controller. Now I might need to get a recent kernel version running on that board. It looks like the macb driver still can't handle boards that don't have a PHY. Is that

Re: net: macb: fail when there's no PHY

On 09/21/2017 12:59 PM, Grant Edwards wrote: > Several years back (circa 2.6.33) I had to hack up macb.c to work on > an at91 board that didn't have a PHY connected to the macb controller. > Now I might need to get a recent kernel version running on that board. > > It looks like the macb driver st

Re: net: macb: fail when there's no PHY

On Thu, Sep 21, 2017 at 01:05:57PM -0700, Florian Fainelli wrote: >> It looks like the macb driver still can't handle boards that don't >> have a PHY. Is that correct? > > Not since: > > dacdbb4dfc1a1a1378df8ebc914d4fe82259ed46 ("net: macb: add fixed-link > node support") Yep, it's obvious now

Re: net: macb: fail when there's no PHY

> On Thu, Sep 21, 2017 at 01:05:57PM -0700, Florian Fainelli wrote: > >>> It looks like the macb driver still can't handle boards that don't >>> have a PHY. Is that correct? >> >> Not since: >> >> dacdbb4dfc1a1a1378df8ebc914d4fe82259ed46 ("net: macb: add fixed-link >> node support") > > Yep, it'

Re: net: macb: fail when there's no PHY

Hi Brandon, On Fri, Sep 22, 2017 at 3:05 AM, Brandon Streiff wrote: >> On Thu, Sep 21, 2017 at 01:05:57PM -0700, Florian Fainelli wrote: > > I have a board that's in a similar boat. My workaround was to undo > portions of dacdbb4dfc1a with the following patch; this lets me still > use fixed-link

Re: net: macb: fail when there's no PHY

+Andrew, On 12/2/2020 9:50 AM, Grant Edwards wrote: > On Thu, Sep 21, 2017 at 3:06 PM Florian Fainelli > wrote: > > On 09/21/2017 12:59 PM, Grant Edwards wrote: > > Several years back (circa 2.6.33) I had to hack up macb.c to work on > > an at91 board tha

Re: net: macb: fail when there's no PHY

On Thu, Sep 21, 2017 at 01:05:57PM -0700, Florian Fainelli wrote: > On 09/21/2017 12:59 PM, Grant Edwards wrote: > > Several years back (circa 2.6.33) I had to hack up macb.c to work on > > an at91 board that didn't have a PHY connected to the macb controller. > > [...] > > It looks like the macb d

Re: net: macb: fail when there's no PHY

[Sorry for sending my previous message twice, it was rejected by the list server the first time because it contained both plaintext and HTML alternatives]. On Wed, Dec 02, 2020 at 10:10:37AM -0800, Florian Fainelli wrote: > On 12/2/2020 9:50 AM, Grant Edwards wrote: > > > I know this thread is a c

Re: net: macb: fail when there's no PHY

> When using the SIOC[SG]MIIREG ioctl() call, how does one control > whether the fake fixed-link bus is accessed or the real macb-mdio bus > is accessed? As far as i remember, that ioctl is based on the interface name. So it will access the MDIO bus of the PHY that is attached to the MAC. I guess

Re: net: macb: fail when there's no PHY

On 2020-12-02, Andrew Lunn wrote: >> When using the SIOC[SG]MIIREG ioctl() call, how does one control >> whether the fake fixed-link bus is accessed or the real macb-mdio bus >> is accessed? > > As far as i remember, that ioctl is based on the interface name. Right. > So it will access the MDIO

Re: net: macb: fail when there's no PHY

> > So it will access the MDIO bus of the PHY that is attached to the > > MAC. > > If that's the case, wouldn't the ioctl() calls "just work" even when > only the fixed-phy mdio bus and fake PHY are declared in the device > tree? The fixed-link PHY is connected to the MAC. So the IOCTL calls will

Re: net: macb: fail when there's no PHY

On 2020-12-02, Andrew Lunn wrote: >> > So it will access the MDIO bus of the PHY that is attached to the >> > MAC. >> >> If that's the case, wouldn't the ioctl() calls "just work" even when >> only the fixed-phy mdio bus and fake PHY are declared in the device >> tree? > > The fixed-link PHY is c

Re: net: macb: fail when there's no PHY

On Wed, Dec 02, 2020 at 09:23:40PM -, Grant Edwards wrote: > On 2020-12-02, Andrew Lunn wrote: > >> > So it will access the MDIO bus of the PHY that is attached to the > >> > MAC. > >> > >> If that's the case, wouldn't the ioctl() calls "just work" even when > >> only the fixed-phy mdio bus a

Re: net: macb: fail when there's no PHY

On 2020-12-02, Andrew Lunn wrote: >>> So it will access the MDIO bus of the PHY that is attached to the >>> MAC. >> >> If that's the case, wouldn't the ioctl() calls "just work" even when >> only the fixed-phy mdio bus and fake PHY are declared in the device >> tree? > > The fixed-link PHY is con

Re: net: macb: fail when there's no PHY

On 12/2/2020 7:03 PM, Grant Edwards wrote: > On 2020-12-02, Andrew Lunn wrote: > So it will access the MDIO bus of the PHY that is attached to the MAC. >>> >>> If that's the case, wouldn't the ioctl() calls "just work" even when >>> only the fixed-phy mdio bus and fake PHY are declar

Re: net: macb: fail when there's no PHY

On 2020-12-03, Florian Fainelli wrote: > You would have to have a local hack that intercepts the macb_ioctl() > and instead of calling phylink_mii_ioctl() it would have to > implement a custom ioctl() that does what > drivers/net/phy/phy.c::phy_mii_ioctl does except the mdiobus should > be pointe

Re: net: macb: fail when there's no PHY

On Thu, Dec 03, 2020 at 03:03:30AM -, Grant Edwards wrote: > On 2020-12-02, Andrew Lunn wrote: > > >>> So it will access the MDIO bus of the PHY that is attached to the > >>> MAC. > >> > >> If that's the case, wouldn't the ioctl() calls "just work" even when > >> only the fixed-phy mdio bus a

Re: net: macb: fail when there's no PHY

> So I can avoid my local hack to macb_main.c by doing a doing a local > hack to macb_main.c? User space drivers were never supported in any meaningful way. The IOCTL call is basically there for mii-tool, and nothing much more. The way to avoid your local hack is to move your drivers into the ker

Re: net: macb: fail when there's no PHY

On 2020-12-03, Andrew Lunn wrote: >> So I can avoid my local hack to macb_main.c by doing a doing a local >> hack to macb_main.c? > > User space drivers were never supported in any meaningful way. The > IOCTL call is basically there for mii-tool, and nothing much more. I probably wouldn't call a

Re: net: macb: fail when there's no PHY

On Thu, Dec 03, 2020 at 03:07:58PM -, Grant Edwards wrote: > On 2020-12-03, Andrew Lunn wrote: > >> So I can avoid my local hack to macb_main.c by doing a doing a local > >> hack to macb_main.c? > > > > User space drivers were never supported in any meaningful way. The > > IOCTL call is basica

Re: net: macb: fail when there's no PHY

On 2020-12-03, Andrew Lunn wrote: > On Thu, Dec 03, 2020 at 03:07:58PM -, Grant Edwards wrote: > >> I don't think I can justify the additional effort to devlope and >> maintain a custom kern-space driver. > > Why custom? You should contribute it. I can't imagine that it would be useful to any

Re: net: macb: fail when there's no PHY

> I don't think there's any way I could justify using a kernel that > doesn't have long-term support. 5.10 is LTS. Well, it will be, once it is actually released! Andrew > [It looks like we're going to have to abandon the effort to use > 5.4. The performance is so bad compared to 2.6.33.7 t

Re: net: macb: fail when there's no PHY

On 2020-12-03, Andrew Lunn wrote: >> I don't think there's any way I could justify using a kernel that >> doesn't have long-term support. > > 5.10 is LTS. Well, it will be, once it is actually released! Convincing people to ship an unreleased kernel would be a whole 'nother bucket of worms. It's

Re: net: macb: fail when there's no PHY

Hello Grant, sorry if I just hijack your conversation, but I'm curious, because we are using the same SoC. Adding linux-arm-kernel to Cc for the general performance issues and linux-mtd for the ECC questions. O:-) Am Donnerstag, 3. Dezember 2020, 23:20:38 CET schrieb Grant Edwards: > On 2020-1

Re: net: macb: fail when there's no PHY

On 12/2/2020 7:54 PM, Grant Edwards wrote: > On 2020-12-03, Florian Fainelli wrote: > >> You would have to have a local hack that intercepts the macb_ioctl() >> and instead of calling phylink_mii_ioctl() it would have to >> implement a custom ioctl() that does what >> drivers/net/phy/phy.c::ph

Re: net: macb: fail when there's no PHY

> > > 5.10 is LTS. Well, it will be, once it is actually released! > > > > Convincing people to ship an unreleased kernel would be a whole > > 'nother bucket of worms. > > +1 > > Judging just from the release dates of the last LTS kernels, I would have > guessed v5.11 will get LTS. But there h

Re: net: macb: fail when there's no PHY

On 2020-12-04, Florian Fainelli wrote: > On 12/2/2020 7:54 PM, Grant Edwards wrote: >> On 2020-12-03, Florian Fainelli wrote: >> >>> You would have to have a local hack that intercepts the macb_ioctl() >>> and instead of calling phylink_mii_ioctl() it would have to >>> implement a custom ioctl()

Re: net: macb: fail when there's no PHY

On 12/4/2020 6:52 PM, Grant Edwards wrote: > On 2020-12-04, Florian Fainelli wrote: >> On 12/2/2020 7:54 PM, Grant Edwards wrote: >>> On 2020-12-03, Florian Fainelli wrote: >>> You would have to have a local hack that intercepts the macb_ioctl() and instead of calling phylink_mii_ioc