| Message ID | 20191026002630.25865-2-michael@walle.cc |
|---|---|
| State | Superseded |
| Delegated to: | Joe Hershberger |
| Headers | show |
| Series | phy: atheros: cleanup and device tree bindings | expand |
On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: > > Provide functions to read and write the Atheros debug registers. > > Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Hi Michael, On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: > > Provide functions to read and write the Atheros debug registers. > > Signed-off-by: Michael Walle <michael@walle.cc> This series is adding too much size to several of the boards' SPL it seems. https://travis-ci.org/jhershbe/u-boot/builds/620804934 Please address this and resend. Thanks, -Joe
Am 2019-11-30 02:11, schrieb Joe Hershberger: > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: >> >> Provide functions to read and write the Atheros debug registers. >> >> Signed-off-by: Michael Walle <michael@walle.cc> > > Acked-by: Joe Hershberger <joe.hershberger@ni.com> Sorry this was superseeded by https://patchwork.ozlabs.org/project/uboot/list/?series=146771 Unfortunately, I've forgot to add the mailinglist to the original series. So it never ended up in the patchwork system :( -michael
Am 2019-11-30 02:11, schrieb Joe Hershberger: > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: >> >> Provide functions to read and write the Atheros debug registers. >> >> Signed-off-by: Michael Walle <michael@walle.cc> > > Acked-by: Joe Hershberger <joe.hershberger@ni.com> Sorry this series superseeded by https://patchwork.ozlabs.org/project/uboot/list/?series=146771 Unfortunately, I've forgot to add the mailinglist to the original series. So it never ended up in the patchwork system :( -michael
Hi Joe, Hi Tom, Am 2019-12-05 16:55, schrieb Joe Hershberger: > Hi Michael, > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: >> >> Provide functions to read and write the Atheros debug registers. >> >> Signed-off-by: Michael Walle <michael@walle.cc> > > This series is adding too much size to several of the boards' SPL it > seems. > > https://travis-ci.org/jhershbe/u-boot/builds/620804934 > > Please address this and resend. So first of all, this was the old series. There was a v2 series, but unfortunately, I've forgot to add the mailing to the recipients, so it never ended up in the patchwork system. sorry :( I've resend the v2 series here: https://patchwork.ozlabs.org/project/uboot/list/?series=146771 Now coming to the real problem here. The sizes, or like some boards handle the SPL stuff. Btw. I could not reproduce it on the am335x_boneblack_vboot board with a gcc-8. I've seen the travis ci job uses the gcc-7 so this also depends on the gcc. gcc-8 seems to produce smaller code, because on the am335x_evm the overflow was only by some 100 bytes. So taking the am335x_evm board for example. It has the following options set: CONFIG_DM_ETH=y CONFIG_SPL_NET_SUPPORT=y CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) So adding a new binding for the phy obviously increases the code size. But the hard question is, how could that be fixed. IMHO the board has wrong settings. I really don't know how that could be "fixed" other than not applying this series. Well, we could make the additions conditional and introduce a new Kconfig setting, but that is a relly ugly hack and won't last long, would it? Doh! -michael
On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: > Hi Joe, Hi Tom, > > Am 2019-12-05 16:55, schrieb Joe Hershberger: > > Hi Michael, > > > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: > > > > > > Provide functions to read and write the Atheros debug registers. > > > > > > Signed-off-by: Michael Walle <michael@walle.cc> > > > > This series is adding too much size to several of the boards' SPL it > > seems. > > > > https://travis-ci.org/jhershbe/u-boot/builds/620804934 > > > > Please address this and resend. > > So first of all, this was the old series. There was a v2 series, but > unfortunately, I've forgot to add the mailing to the recipients, so it > never ended up in the patchwork system. sorry :( > > I've resend the v2 series here: > https://patchwork.ozlabs.org/project/uboot/list/?series=146771 > > Now coming to the real problem here. The sizes, or like some boards handle > the SPL stuff. Btw. I could not reproduce it on the am335x_boneblack_vboot > board with a gcc-8. I've seen the travis ci job uses the gcc-7 so this also > depends on the gcc. gcc-8 seems to produce smaller code, because on the > am335x_evm the overflow was only by some 100 bytes. > > So taking the am335x_evm board for example. It has the following options > set: > CONFIG_DM_ETH=y > CONFIG_SPL_NET_SUPPORT=y > CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) > > So adding a new binding for the phy obviously increases the code size. But > the hard question is, how could that be fixed. IMHO the board has wrong > settings. I really don't know how that could be "fixed" other than not > applying this series. Well, we could make the additions conditional and > introduce a new Kconfig setting, but that is a relly ugly hack and won't > last long, would it? Doh! So, the gcc-7 from kernel.org is the min required and must work toolchain. Maybe once gcc-9 is mature enough for people to have made stand-alone toolchains for it we'll move up to that but gcc-8 for everyone ends up being too hard. For the boneblack_vboot config, we could just drop SPL networking, it's not super critical to that particular example. But am335x_evm is the kitchen-sink EVM and it is used and supported there. That said, looking over the u-boot-spl.map, it looks like nfs stuff doesn't get discarded for some reason, I'm going to look in to that.
Hi Tom, Am 2019-12-06 00:58, schrieb Tom Rini: > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: >> Hi Joe, Hi Tom, >> >> Am 2019-12-05 16:55, schrieb Joe Hershberger: >> > Hi Michael, >> > >> > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: >> > > >> > > Provide functions to read and write the Atheros debug registers. >> > > >> > > Signed-off-by: Michael Walle <michael@walle.cc> >> > >> > This series is adding too much size to several of the boards' SPL it >> > seems. >> > >> > https://travis-ci.org/jhershbe/u-boot/builds/620804934 >> > >> > Please address this and resend. >> >> So first of all, this was the old series. There was a v2 series, but >> unfortunately, I've forgot to add the mailing to the recipients, so it >> never ended up in the patchwork system. sorry :( >> >> I've resend the v2 series here: >> https://patchwork.ozlabs.org/project/uboot/list/?series=146771 >> >> Now coming to the real problem here. The sizes, or like some boards >> handle >> the SPL stuff. Btw. I could not reproduce it on the >> am335x_boneblack_vboot >> board with a gcc-8. I've seen the travis ci job uses the gcc-7 so this >> also >> depends on the gcc. gcc-8 seems to produce smaller code, because on >> the >> am335x_evm the overflow was only by some 100 bytes. >> >> So taking the am335x_evm board for example. It has the following >> options >> set: >> CONFIG_DM_ETH=y >> CONFIG_SPL_NET_SUPPORT=y >> CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) >> >> So adding a new binding for the phy obviously increases the code size. >> But >> the hard question is, how could that be fixed. IMHO the board has >> wrong >> settings. I really don't know how that could be "fixed" other than not >> applying this series. Well, we could make the additions conditional >> and >> introduce a new Kconfig setting, but that is a relly ugly hack and >> won't >> last long, would it? Doh! > > So, the gcc-7 from kernel.org is the min required and must work > toolchain. Ok. > Maybe once gcc-9 is mature enough for people to have made > stand-alone toolchains for it we'll move up to that but gcc-8 for > everyone ends up being too hard. For the boneblack_vboot config, we > could just drop SPL networking, it's not super critical to that > particular example. But am335x_evm is the kitchen-sink EVM and it is > used and supported there. > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > doesn't get discarded for some reason, I'm going to look in to that. Well but that is just some kind of band aid. These two boards were just an example. There were also other boards which failed. I doubt the DM stuff is getting smaller (I know there is some discussion how to improve the situation). But there seems to be no way to disable the ethernet device model for the SPL, correct? And unfortunately, this also pulls the PHY library (with potential DM bindings). -michael
Am 2019-12-06 00:58, schrieb Tom Rini: > That said, looking over the u-boot-spl.map, it looks like nfs stuff > doesn't get discarded for some reason, I'm going to look in to that. CONFIG_CMD_NFS will pull that. There are also other network related cmds whose code is pulled into the SPL through net/net.c. -michael
On Fri, Dec 06, 2019 at 01:39:29AM +0100, Michael Walle wrote: > Hi Tom, > > Am 2019-12-06 00:58, schrieb Tom Rini: > > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: > > > Hi Joe, Hi Tom, > > > > > > Am 2019-12-05 16:55, schrieb Joe Hershberger: > > > > Hi Michael, > > > > > > > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: > > > > > > > > > > Provide functions to read and write the Atheros debug registers. > > > > > > > > > > Signed-off-by: Michael Walle <michael@walle.cc> > > > > > > > > This series is adding too much size to several of the boards' SPL it > > > > seems. > > > > > > > > https://travis-ci.org/jhershbe/u-boot/builds/620804934 > > > > > > > > Please address this and resend. > > > > > > So first of all, this was the old series. There was a v2 series, but > > > unfortunately, I've forgot to add the mailing to the recipients, so it > > > never ended up in the patchwork system. sorry :( > > > > > > I've resend the v2 series here: > > > https://patchwork.ozlabs.org/project/uboot/list/?series=146771 > > > > > > Now coming to the real problem here. The sizes, or like some boards > > > handle > > > the SPL stuff. Btw. I could not reproduce it on the > > > am335x_boneblack_vboot > > > board with a gcc-8. I've seen the travis ci job uses the gcc-7 so > > > this also > > > depends on the gcc. gcc-8 seems to produce smaller code, because on > > > the > > > am335x_evm the overflow was only by some 100 bytes. > > > > > > So taking the am335x_evm board for example. It has the following > > > options > > > set: > > > CONFIG_DM_ETH=y > > > CONFIG_SPL_NET_SUPPORT=y > > > CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) > > > > > > So adding a new binding for the phy obviously increases the code > > > size. But > > > the hard question is, how could that be fixed. IMHO the board has > > > wrong > > > settings. I really don't know how that could be "fixed" other than not > > > applying this series. Well, we could make the additions conditional > > > and > > > introduce a new Kconfig setting, but that is a relly ugly hack and > > > won't > > > last long, would it? Doh! > > > > So, the gcc-7 from kernel.org is the min required and must work > > toolchain. > > Ok. > > > Maybe once gcc-9 is mature enough for people to have made > > stand-alone toolchains for it we'll move up to that but gcc-8 for > > everyone ends up being too hard. For the boneblack_vboot config, we > > could just drop SPL networking, it's not super critical to that > > particular example. But am335x_evm is the kitchen-sink EVM and it is > > used and supported there. > > > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > > doesn't get discarded for some reason, I'm going to look in to that. > > Well but that is just some kind of band aid. These two boards were just > an example. There were also other boards which failed. I doubt the DM > stuff is getting smaller (I know there is some discussion how to > improve the situation). But there seems to be no way to disable the > ethernet device model for the SPL, correct? And unfortunately, this > also pulls the PHY library (with potential DM bindings). So, yes, keeping in mind that SPL matters for networking and we need to keep that in mind when adding features. Thanks!
On Fri, Dec 06, 2019 at 01:53:57AM +0100, Michael Walle wrote: > Am 2019-12-06 00:58, schrieb Tom Rini: > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > > doesn't get discarded for some reason, I'm going to look in to that. > > CONFIG_CMD_NFS will pull that. There are also other network related > cmds whose code is pulled into the SPL through net/net.c. Right. The way the networking stack behaves today I bet we have other functionality being pulled in to SPL that we would rather be able to discard as it's functionally unused. What I sent to keep NFS out is a little hacky looking but is the best we can do with the current structure. There might be a few other options we can drop out from the loop.
Hi Tom, Hi Joe, Am 2019-12-06 00:58, schrieb Tom Rini: > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: >> Hi Joe, Hi Tom, >> >> Am 2019-12-05 16:55, schrieb Joe Hershberger: >> > Hi Michael, >> > >> > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: >> > > >> > > Provide functions to read and write the Atheros debug registers. >> > > >> > > Signed-off-by: Michael Walle <michael@walle.cc> >> > >> > This series is adding too much size to several of the boards' SPL it >> > seems. >> > >> > https://travis-ci.org/jhershbe/u-boot/builds/620804934 >> > >> > Please address this and resend. >> >> So first of all, this was the old series. There was a v2 series, but >> unfortunately, I've forgot to add the mailing to the recipients, so it >> never ended up in the patchwork system. sorry :( >> >> I've resend the v2 series here: >> https://patchwork.ozlabs.org/project/uboot/list/?series=146771 >> >> Now coming to the real problem here. The sizes, or like some boards >> handle >> the SPL stuff. Btw. I could not reproduce it on the >> am335x_boneblack_vboot >> board with a gcc-8. I've seen the travis ci job uses the gcc-7 so this >> also >> depends on the gcc. gcc-8 seems to produce smaller code, because on >> the >> am335x_evm the overflow was only by some 100 bytes. >> >> So taking the am335x_evm board for example. It has the following >> options >> set: >> CONFIG_DM_ETH=y >> CONFIG_SPL_NET_SUPPORT=y >> CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) >> >> So adding a new binding for the phy obviously increases the code size. >> But >> the hard question is, how could that be fixed. IMHO the board has >> wrong >> settings. I really don't know how that could be "fixed" other than not >> applying this series. Well, we could make the additions conditional >> and >> introduce a new Kconfig setting, but that is a relly ugly hack and >> won't >> last long, would it? Doh! > > So, the gcc-7 from kernel.org is the min required and must work > toolchain. Maybe once gcc-9 is mature enough for people to have made > stand-alone toolchains for it we'll move up to that but gcc-8 for > everyone ends up being too hard. For the boneblack_vboot config, we > could just drop SPL networking, it's not super critical to that > particular example. But am335x_evm is the kitchen-sink EVM and it is > used and supported there. > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > doesn't get discarded for some reason, I'm going to look in to that. So do I need to do something now? I guess removing the NFS stuff will make enough room to fit this. But how do we make sure, it will be applied with this series? -michael
On Mon, Dec 09, 2019 at 07:42:00PM +0100, Michael Walle wrote: > Hi Tom, Hi Joe, > > Am 2019-12-06 00:58, schrieb Tom Rini: > > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: > > > Hi Joe, Hi Tom, > > > > > > Am 2019-12-05 16:55, schrieb Joe Hershberger: > > > > Hi Michael, > > > > > > > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: > > > > > > > > > > Provide functions to read and write the Atheros debug registers. > > > > > > > > > > Signed-off-by: Michael Walle <michael@walle.cc> > > > > > > > > This series is adding too much size to several of the boards' SPL it > > > > seems. > > > > > > > > https://travis-ci.org/jhershbe/u-boot/builds/620804934 > > > > > > > > Please address this and resend. > > > > > > So first of all, this was the old series. There was a v2 series, but > > > unfortunately, I've forgot to add the mailing to the recipients, so it > > > never ended up in the patchwork system. sorry :( > > > > > > I've resend the v2 series here: > > > https://patchwork.ozlabs.org/project/uboot/list/?series=146771 > > > > > > Now coming to the real problem here. The sizes, or like some boards > > > handle > > > the SPL stuff. Btw. I could not reproduce it on the > > > am335x_boneblack_vboot > > > board with a gcc-8. I've seen the travis ci job uses the gcc-7 so > > > this also > > > depends on the gcc. gcc-8 seems to produce smaller code, because on > > > the > > > am335x_evm the overflow was only by some 100 bytes. > > > > > > So taking the am335x_evm board for example. It has the following > > > options > > > set: > > > CONFIG_DM_ETH=y > > > CONFIG_SPL_NET_SUPPORT=y > > > CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) > > > > > > So adding a new binding for the phy obviously increases the code > > > size. But > > > the hard question is, how could that be fixed. IMHO the board has > > > wrong > > > settings. I really don't know how that could be "fixed" other than not > > > applying this series. Well, we could make the additions conditional > > > and > > > introduce a new Kconfig setting, but that is a relly ugly hack and > > > won't > > > last long, would it? Doh! > > > > So, the gcc-7 from kernel.org is the min required and must work > > toolchain. Maybe once gcc-9 is mature enough for people to have made > > stand-alone toolchains for it we'll move up to that but gcc-8 for > > everyone ends up being too hard. For the boneblack_vboot config, we > > could just drop SPL networking, it's not super critical to that > > particular example. But am335x_evm is the kitchen-sink EVM and it is > > used and supported there. > > > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > > doesn't get discarded for some reason, I'm going to look in to that. > > So do I need to do something now? I guess removing the NFS stuff will > make enough room to fit this. But how do we make sure, it will be applied > with this series? In this case, Joe has it in the -net PR right now. Thanks!
Hi Tom, On Mon, Dec 9, 2019 at 12:47 PM Tom Rini <trini@konsulko.com> wrote: > > On Mon, Dec 09, 2019 at 07:42:00PM +0100, Michael Walle wrote: > > Hi Tom, Hi Joe, > > > > Am 2019-12-06 00:58, schrieb Tom Rini: > > > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: > > > > Hi Joe, Hi Tom, > > > > > > > > Am 2019-12-05 16:55, schrieb Joe Hershberger: > > > > > Hi Michael, > > > > > > > > > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: > > > > > > > > > > > > Provide functions to read and write the Atheros debug registers. > > > > > > > > > > > > Signed-off-by: Michael Walle <michael@walle.cc> > > > > > > > > > > This series is adding too much size to several of the boards' SPL it > > > > > seems. > > > > > > > > > > https://travis-ci.org/jhershbe/u-boot/builds/620804934 > > > > > > > > > > Please address this and resend. > > > > > > > > So first of all, this was the old series. There was a v2 series, but > > > > unfortunately, I've forgot to add the mailing to the recipients, so it > > > > never ended up in the patchwork system. sorry :( > > > > > > > > I've resend the v2 series here: > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=146771 > > > > > > > > Now coming to the real problem here. The sizes, or like some boards > > > > handle > > > > the SPL stuff. Btw. I could not reproduce it on the > > > > am335x_boneblack_vboot > > > > board with a gcc-8. I've seen the travis ci job uses the gcc-7 so > > > > this also > > > > depends on the gcc. gcc-8 seems to produce smaller code, because on > > > > the > > > > am335x_evm the overflow was only by some 100 bytes. > > > > > > > > So taking the am335x_evm board for example. It has the following > > > > options > > > > set: > > > > CONFIG_DM_ETH=y > > > > CONFIG_SPL_NET_SUPPORT=y > > > > CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) > > > > > > > > So adding a new binding for the phy obviously increases the code > > > > size. But > > > > the hard question is, how could that be fixed. IMHO the board has > > > > wrong > > > > settings. I really don't know how that could be "fixed" other than not > > > > applying this series. Well, we could make the additions conditional > > > > and > > > > introduce a new Kconfig setting, but that is a relly ugly hack and > > > > won't > > > > last long, would it? Doh! > > > > > > So, the gcc-7 from kernel.org is the min required and must work > > > toolchain. Maybe once gcc-9 is mature enough for people to have made > > > stand-alone toolchains for it we'll move up to that but gcc-8 for > > > everyone ends up being too hard. For the boneblack_vboot config, we > > > could just drop SPL networking, it's not super critical to that > > > particular example. But am335x_evm is the kitchen-sink EVM and it is > > > used and supported there. > > > > > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > > > doesn't get discarded for some reason, I'm going to look in to that. > > > > So do I need to do something now? I guess removing the NFS stuff will > > make enough room to fit this. But how do we make sure, it will be applied > > with this series? > > In this case, Joe has it in the -net PR right now. Thanks! It's actually excluded from the PR. I need to go back and review the rest of the v2 series. Cheers, -Joe
On Mon, Dec 09, 2019 at 01:46:32PM -0600, Joe Hershberger wrote: > Hi Tom, > > On Mon, Dec 9, 2019 at 12:47 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Mon, Dec 09, 2019 at 07:42:00PM +0100, Michael Walle wrote: > > > Hi Tom, Hi Joe, > > > > > > Am 2019-12-06 00:58, schrieb Tom Rini: > > > > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: > > > > > Hi Joe, Hi Tom, > > > > > > > > > > Am 2019-12-05 16:55, schrieb Joe Hershberger: > > > > > > Hi Michael, > > > > > > > > > > > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle <michael@walle.cc> wrote: > > > > > > > > > > > > > > Provide functions to read and write the Atheros debug registers. > > > > > > > > > > > > > > Signed-off-by: Michael Walle <michael@walle.cc> > > > > > > > > > > > > This series is adding too much size to several of the boards' SPL it > > > > > > seems. > > > > > > > > > > > > https://travis-ci.org/jhershbe/u-boot/builds/620804934 > > > > > > > > > > > > Please address this and resend. > > > > > > > > > > So first of all, this was the old series. There was a v2 series, but > > > > > unfortunately, I've forgot to add the mailing to the recipients, so it > > > > > never ended up in the patchwork system. sorry :( > > > > > > > > > > I've resend the v2 series here: > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=146771 > > > > > > > > > > Now coming to the real problem here. The sizes, or like some boards > > > > > handle > > > > > the SPL stuff. Btw. I could not reproduce it on the > > > > > am335x_boneblack_vboot > > > > > board with a gcc-8. I've seen the travis ci job uses the gcc-7 so > > > > > this also > > > > > depends on the gcc. gcc-8 seems to produce smaller code, because on > > > > > the > > > > > am335x_evm the overflow was only by some 100 bytes. > > > > > > > > > > So taking the am335x_evm board for example. It has the following > > > > > options > > > > > set: > > > > > CONFIG_DM_ETH=y > > > > > CONFIG_SPL_NET_SUPPORT=y > > > > > CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) > > > > > > > > > > So adding a new binding for the phy obviously increases the code > > > > > size. But > > > > > the hard question is, how could that be fixed. IMHO the board has > > > > > wrong > > > > > settings. I really don't know how that could be "fixed" other than not > > > > > applying this series. Well, we could make the additions conditional > > > > > and > > > > > introduce a new Kconfig setting, but that is a relly ugly hack and > > > > > won't > > > > > last long, would it? Doh! > > > > > > > > So, the gcc-7 from kernel.org is the min required and must work > > > > toolchain. Maybe once gcc-9 is mature enough for people to have made > > > > stand-alone toolchains for it we'll move up to that but gcc-8 for > > > > everyone ends up being too hard. For the boneblack_vboot config, we > > > > could just drop SPL networking, it's not super critical to that > > > > particular example. But am335x_evm is the kitchen-sink EVM and it is > > > > used and supported there. > > > > > > > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > > > > doesn't get discarded for some reason, I'm going to look in to that. > > > > > > So do I need to do something now? I guess removing the NFS stuff will > > > make enough room to fit this. But how do we make sure, it will be applied > > > with this series? > > > > In this case, Joe has it in the -net PR right now. Thanks! > > It's actually excluded from the PR. I need to go back and review the > rest of the v2 series. Sorry I meant the NFS patch to reduce size.
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index 3783d155e7..b25aa02108 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -17,11 +17,52 @@ #define AR803x_DEBUG_REG_0 0x0 #define AR803x_RGMII_RX_CLK_DLY 0x8000 +static int ar803x_debug_reg_read(struct phy_device *phydev, u16 reg) +{ + int ret; + + ret = phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG, + reg); + if (ret < 0) + return ret; + + return phy_read(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG); +} + +static int ar803x_debug_reg_write(struct phy_device *phydev, u16 reg, u16 val) +{ + int ret; + + ret = phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG, + reg); + if (ret < 0) + return ret; + + return phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, + val); +} + +static int ar803x_debug_reg_mask(struct phy_device *phydev, u16 reg, + u16 clear, u16 set) +{ + int val; + + val = ar803x_debug_reg_read(phydev, reg); + if (val < 0) + return val; + + val &= 0xffff; + val &= ~clear; + val |= set; + + return phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, + val); +} + static int ar8021_config(struct phy_device *phydev) { phy_write(phydev, MDIO_DEVAD_NONE, 0x00, 0x1200); - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05); - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x3D47); + ar803x_debug_reg_write(phydev, AR803x_DEBUG_REG_5, 0x3D47); phydev->supported = phydev->drv->features; return 0; @@ -31,18 +72,14 @@ static int ar8031_config(struct phy_device *phydev) { if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID || phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) { - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG, - AR803x_DEBUG_REG_5); - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, - AR803x_RGMII_TX_CLK_DLY); + ar803x_debug_reg_write(phydev, AR803x_DEBUG_REG_5, + AR803x_RGMII_TX_CLK_DLY); } if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID || phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) { - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG, - AR803x_DEBUG_REG_0); - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, - AR803x_RGMII_RX_CLK_DLY); + ar803x_debug_reg_write(phydev, AR803x_DEBUG_REG_0, + AR803x_RGMII_RX_CLK_DLY); } phydev->supported = phydev->drv->features; @@ -63,24 +100,21 @@ static int ar8035_config(struct phy_device *phydev) regval = phy_read(phydev, MDIO_DEVAD_NONE, 0xe); phy_write(phydev, MDIO_DEVAD_NONE, 0xe, (regval|0x0018)); - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05); - regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e); - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100)); + ar803x_debug_reg_mask(phydev, AR803x_DEBUG_REG_5, + 0, AR803x_RGMII_TX_CLK_DLY); if ((phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) || (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) { - /* select debug reg 5 */ - phy_write(phydev, MDIO_DEVAD_NONE, 0x1D, 0x5); /* enable tx delay */ - phy_write(phydev, MDIO_DEVAD_NONE, 0x1E, 0x0100); + ar803x_debug_reg_write(phydev, AR803x_DEBUG_REG_5, + AR803x_RGMII_TX_CLK_DLY); } if ((phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) || (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)) { - /* select debug reg 0 */ - phy_write(phydev, MDIO_DEVAD_NONE, 0x1D, 0x0); /* enable rx delay */ - phy_write(phydev, MDIO_DEVAD_NONE, 0x1E, 0x8000); + ar803x_debug_reg_write(phydev, AR803x_DEBUG_REG_0, + AR803x_RGMII_RX_CLK_DLY); } phydev->supported = phydev->drv->features;
Provide functions to read and write the Atheros debug registers. Signed-off-by: Michael Walle <michael@walle.cc> --- drivers/net/phy/atheros.c | 72 ++++++++++++++++++++++++++++----------- 1 file changed, 53 insertions(+), 19 deletions(-)