From: Robert Jarzmik <robert.jarzmik@free.fr> Date: 2016-08-25 18:02:59
Arnd Bergmann [off-list ref] writes:
On Thursday, August 25, 2016 4:43:04 PM CEST Arnd Bergmann wrote:
quoted
drivers/net/ethernet/smsc/smc91x.h | 50 +++++++++++++++++++++++---------------
1 file changed, 30 insertions(+), 20 deletions(-)
While this patch fixes one bug on Neponset, it probably doesn't address
the one that Russell ran into first, so this is for review only for now,
until the remaining problem(s) have been worked out.
The comment should have been on another patch, my mistake. please
see v2.
Arnd
Hi Arnd,
I didn't review the patch thoroughly, but I launched your 2 patches in my pxa
little farm.
The result is that lubbock and mainstone are all right, but zylonite is broken
(ie. networkless). I removed then these 2 patches and zylonite worked again.
I have also an error message on the console on a "broken" zylonite :
Changing smcs91x MAC address to 08:00:3e:26:0a:5b: ifconfig: SIOCSIFHWADDR:
Device or resource busy
I reran the test twice (2 times with your patches, 2 times without), the result
looks consistent, ie. zylonite doesn't really like them.
Cheers.
--
Robert
PS: even if zylonite defconfig is not in the tree, it uses this driver, with :
CONFIG_SMC91X=y
...and...
static struct smc91x_platdata zylonite_smc91x_info = {
.flags = SMC91X_USE_8BIT | SMC91X_USE_16BIT |
SMC91X_NOWAIT | SMC91X_USE_DMA,
};
From: Russell King - ARM Linux <linux@armlinux.org.uk> Date: 2016-08-25 22:38:13
On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote:
Arnd Bergmann [off-list ref] writes:
quoted
On Thursday, August 25, 2016 4:43:04 PM CEST Arnd Bergmann wrote:
quoted
drivers/net/ethernet/smsc/smc91x.h | 50 +++++++++++++++++++++++---------------
1 file changed, 30 insertions(+), 20 deletions(-)
While this patch fixes one bug on Neponset, it probably doesn't address
the one that Russell ran into first, so this is for review only for now,
until the remaining problem(s) have been worked out.
The comment should have been on another patch, my mistake. please
see v2.
Arnd
Hi Arnd,
I didn't review the patch thoroughly, but I launched your 2 patches in my pxa
little farm.
The result is that lubbock and mainstone are all right, but zylonite is broken
(ie. networkless). I removed then these 2 patches and zylonite worked again.
I have also an error message on the console on a "broken" zylonite :
Changing smcs91x MAC address to 08:00:3e:26:0a:5b: ifconfig: SIOCSIFHWADDR:
Device or resource busy
I reran the test twice (2 times with your patches, 2 times without), the result
looks consistent, ie. zylonite doesn't really like them.
Please try the patch below. I sent this to Will a few days ago, as
he said (on irc) that he was also seeing problems on a platform he
had, but I've yet to hear back. I've not posted it yet because I
haven't got around to writing a commit description for it.
It does require that at least one of 8-bit or 16-bit accesses are
supported, but I think that's already true.
8<========
From: Russell King <redacted>
Subject: [PATCH] net: smc91x: fix SMC accesses
Signed-off-by: Russell King <redacted>
---
drivers/net/ethernet/smsc/smc91x.h | 65 ++++++++++++++++++++++++++------------
1 file changed, 45 insertions(+), 20 deletions(-)
@@ -66,7 +107,7 @@#define SMC_IRQ_FLAGS (-1) /* from resource *//* We actually can't write halfwords properly if not word aligned */-staticinlinevoidSMC_outw(u16val,void__iomem*ioaddr,intreg)+staticinlinevoid__SMC_outw(u16val,void__iomem*ioaddr,intreg){if((machine_is_mainstone()||machine_is_stargate2()||machine_is_pxa_idp())&®&2){
--
2.1.0
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
On Thursday, August 25, 2016 11:37:43 PM CEST Russell King - ARM Linux wrote:
quoted hunk
On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote:
quoted
Arnd Bergmann [off-list ref] writes:
/*
+ * Any 16-bit access is performed with two 8-bit accesses if the hardware
+ * can't do it directly. Most registers are 16-bit so those are mandatory.
+ */
+#define SMC_outw_b(x, a, r) \
+ do { \
+ unsigned int __val16 = (x); \
+ unsigned int __reg = (r); \
+ SMC_outb(__val16, a, __reg); \
+ SMC_outb(__val16 >> 8, a, __reg + (1 << SMC_IO_SHIFT)); \
+ } while (0)
+
+#define SMC_inw_b(a, r) \
+ ({ \
+ unsigned int __val16; \
+ unsigned int __reg = r; \
+ __val16 = SMC_inb(a, __reg); \
+ __val16 |= SMC_inb(a, __reg + (1 << SMC_IO_SHIFT)) << 8; \
+ __val16; \
+ })
+
+/*
* Define your architecture specific bus configuration parameters here.
*/
I think this breaks machines that declare a device that just lists
SMC91X_USE_32BIT but not SMC91X_USE_16BIT. Right now, the way this
is interpreted is to use 32-bit accessors for most things, but
not avoiding 16-bit reads.
That is a bit fishy though, and we could instead change the platform
data to always set both SMC91X_USE_32BIT and SMC91X_USE_16BIT.
The affected platforms are DT based machines with 32-bit I/O and
these board files:
arch/arm/mach-pxa/idp.c: .flags = SMC91X_USE_32BIT | SMC91X_USE_DMA | SMC91X_NOWAIT,
arch/arm/mach-pxa/xcep.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT | SMC91X_USE_DMA,
arch/arm/mach-realview/core.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
arch/blackfin/mach-bf561/boards/cm_bf561.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
arch/blackfin/mach-bf561/boards/ezkit.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
Arnd
On Friday, August 26, 2016 11:41:21 AM CEST Arnd Bergmann wrote:
I think this breaks machines that declare a device that just lists
SMC91X_USE_32BIT but not SMC91X_USE_16BIT. Right now, the way this
is interpreted is to use 32-bit accessors for most things, but
not avoiding 16-bit reads.
I guess my patch has the same problem here, with the
if (SMC_CAN_USE_8BIT && !SMC_16BIT(lp))
check that is true when a platform device is declared with 32-bit
I/O only but all three are enabled at compile-time. The best check
I can think of here (aside from redefining how the flags work)
would be
#define SMC_8BIT_ONLY(p) \
(((p)->cfg.flags & (SMC91X_USE_8BIT |SMC91X_USE_16BIT | SMC91X_USE_32BIT)) == \
SMC91X_USE_8BIT)
Arnd
From: Russell King - ARM Linux <linux@armlinux.org.uk> Date: 2016-08-26 11:39:15
On Fri, Aug 26, 2016 at 11:41:21AM +0200, Arnd Bergmann wrote:
On Thursday, August 25, 2016 11:37:43 PM CEST Russell King - ARM Linux wrote:
quoted
On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote:
quoted
Arnd Bergmann [off-list ref] writes:
/*
+ * Any 16-bit access is performed with two 8-bit accesses if the hardware
+ * can't do it directly. Most registers are 16-bit so those are mandatory.
+ */
+#define SMC_outw_b(x, a, r) \
+ do { \
+ unsigned int __val16 = (x); \
+ unsigned int __reg = (r); \
+ SMC_outb(__val16, a, __reg); \
+ SMC_outb(__val16 >> 8, a, __reg + (1 << SMC_IO_SHIFT)); \
+ } while (0)
+
+#define SMC_inw_b(a, r) \
+ ({ \
+ unsigned int __val16; \
+ unsigned int __reg = r; \
+ __val16 = SMC_inb(a, __reg); \
+ __val16 |= SMC_inb(a, __reg + (1 << SMC_IO_SHIFT)) << 8; \
+ __val16; \
+ })
+
+/*
* Define your architecture specific bus configuration parameters here.
*/
I think this breaks machines that declare a device that just lists
SMC91X_USE_32BIT but not SMC91X_USE_16BIT. Right now, the way this
is interpreted is to use 32-bit accessors for most things, but
not avoiding 16-bit reads.
Your comment is wrong. It breaks machines that declare a device
with SMC91X_USE_32BIT but not _either_ of SMC91X_USE_16BIT _or_
SMC91X_USE_8BIT. As I already noted, but you obviously ignored.
In that note, I pointed out that this _was_ already the case with
the original driver before your patch:
#if ! SMC_CAN_USE_16BIT
... code implementing SMC_outw() and SMC_inw() in terms of SMC_outb()
and SMC_inb(), and defining SMC_insw() and SMC_outsw() as BUG()
#endif
#if !defined(SMC_insw) || !defined(SMC_outsw)
#define SMC_insw(a, r, p, l) BUG()
#define SMC_outsw(a, r, p, l) BUG()
#endif
#if ! SMC_CAN_USE_8BIT
#define SMC_inb(ioaddr, reg) ({ BUG(); 0; })
#define SMC_outb(x, ioaddr, reg) BUG()
#define SMC_insb(a, r, p, l) BUG()
#define SMC_outsb(a, r, p, l) BUG()
#endif
#if !defined(SMC_insb) || !defined(SMC_outsb)
#define SMC_insb(a, r, p, l) BUG()
#define SMC_outsb(a, r, p, l) BUG()
#endif
So, if _neither_ SMC_CAN_USE_16BIT nor SMC_CAN_USE_8BIT are defined,
trying to use the 16-bit accessors cause a BUG().
That is a bit fishy though, and we could instead change the platform
data to always set both SMC91X_USE_32BIT and SMC91X_USE_16BIT.
The affected platforms are DT based machines with 32-bit I/O and
these board files:
arch/arm/mach-pxa/idp.c: .flags = SMC91X_USE_32BIT | SMC91X_USE_DMA | SMC91X_NOWAIT,
arch/arm/mach-pxa/xcep.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT | SMC91X_USE_DMA,
arch/arm/mach-realview/core.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
arch/blackfin/mach-bf561/boards/cm_bf561.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
arch/blackfin/mach-bf561/boards/ezkit.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
Right, this looks like another one of your bugs in this conversion.
#elif defined(CONFIG_ARCH_INNOKOM) || \
defined(CONFIG_ARCH_PXA_IDP) || \
defined(CONFIG_ARCH_RAMSES) || \
defined(CONFIG_ARCH_PCM027)
#define SMC_CAN_USE_8BIT 1
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 1
So, IDP can use all of 32-bit, 16-bit and 8-bit accesses, meanwhile your
conversion is telling the driver that it can only use 32-bit => your
conversion of IDP is broken.
Before your conversion, realview depended on the default settings of
smc91x, which is again:
#define SMC_CAN_USE_8BIT 1
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 1
So realview follows IDP - it can do 32-bit, 16-bit and 8-bit accesses,
meanwhile your conversion tells the driver it can _only_ do 32-bit
accesses, which is again broken.
XCEP falls into the same category, as do the other two blackfin
cases from what I can see.
The point of the SMC_CAN_USE_xxx macros is to indicate to the SMC91x
driver which sizes of access can be used on the hardware concerned.
If SMC_CAN_USE_16BIT is set, then 16-bit accesses are possible. If
it's not set, then 8-bit accesses will be used if they're supported,
otherwise it's a buggy configuration.
SMC_CAN_USE_32BIT says that 32-bit accesses are possible, but these
are only used in a small number of cases as an optimisation.
It is a bug to configure the smc91x driver with both SMC_CAN_USE_16BIT
and SMC_CAN_USE_8BIT clear.
Hence, it's a bug to tell the driver (via the platform data) that only
32-bit accesses can be performed.
So, while my patch may be fixing some of the brokenness, the rest of
the brokenness also needs fixing by adjusting all the platform data
to properly reflect which access sizes are possible, rather than what
you seem to have done, which is to indicate what the largest possible
access size is.
This is especially important as there are platforms around where 16-bit
accesses to the SMC91x can be performed, but not 8-bit:
#elif defined(CONFIG_MACH_LOGICPD_PXA270) || \
defined(CONFIG_MACH_NOMADIK_8815NHK)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_SH_SH4202_MICRODEV)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_M32R)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_ARCH_MSM)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_COLDFIRE)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
... etc ...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Russell King - ARM Linux <linux@armlinux.org.uk> Date: 2016-08-26 12:30:39
On Fri, Aug 26, 2016 at 12:38:48PM +0100, Russell King - ARM Linux wrote:
On Fri, Aug 26, 2016 at 11:41:21AM +0200, Arnd Bergmann wrote:
quoted
On Thursday, August 25, 2016 11:37:43 PM CEST Russell King - ARM Linux wrote:
quoted
On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote:
quoted
Arnd Bergmann [off-list ref] writes:
/*
+ * Any 16-bit access is performed with two 8-bit accesses if the hardware
+ * can't do it directly. Most registers are 16-bit so those are mandatory.
+ */
+#define SMC_outw_b(x, a, r) \
+ do { \
+ unsigned int __val16 = (x); \
+ unsigned int __reg = (r); \
+ SMC_outb(__val16, a, __reg); \
+ SMC_outb(__val16 >> 8, a, __reg + (1 << SMC_IO_SHIFT)); \
+ } while (0)
+
+#define SMC_inw_b(a, r) \
+ ({ \
+ unsigned int __val16; \
+ unsigned int __reg = r; \
+ __val16 = SMC_inb(a, __reg); \
+ __val16 |= SMC_inb(a, __reg + (1 << SMC_IO_SHIFT)) << 8; \
+ __val16; \
+ })
+
+/*
* Define your architecture specific bus configuration parameters here.
*/
I think this breaks machines that declare a device that just lists
SMC91X_USE_32BIT but not SMC91X_USE_16BIT. Right now, the way this
is interpreted is to use 32-bit accessors for most things, but
not avoiding 16-bit reads.
Your comment is wrong. It breaks machines that declare a device
with SMC91X_USE_32BIT but not _either_ of SMC91X_USE_16BIT _or_
SMC91X_USE_8BIT. As I already noted, but you obviously ignored.
In that note, I pointed out that this _was_ already the case with
the original driver before your patch:
#if ! SMC_CAN_USE_16BIT
... code implementing SMC_outw() and SMC_inw() in terms of SMC_outb()
and SMC_inb(), and defining SMC_insw() and SMC_outsw() as BUG()
#endif
#if !defined(SMC_insw) || !defined(SMC_outsw)
#define SMC_insw(a, r, p, l) BUG()
#define SMC_outsw(a, r, p, l) BUG()
#endif
#if ! SMC_CAN_USE_8BIT
#define SMC_inb(ioaddr, reg) ({ BUG(); 0; })
#define SMC_outb(x, ioaddr, reg) BUG()
#define SMC_insb(a, r, p, l) BUG()
#define SMC_outsb(a, r, p, l) BUG()
#endif
#if !defined(SMC_insb) || !defined(SMC_outsb)
#define SMC_insb(a, r, p, l) BUG()
#define SMC_outsb(a, r, p, l) BUG()
#endif
So, if _neither_ SMC_CAN_USE_16BIT nor SMC_CAN_USE_8BIT are defined,
trying to use the 16-bit accessors cause a BUG().
quoted
That is a bit fishy though, and we could instead change the platform
data to always set both SMC91X_USE_32BIT and SMC91X_USE_16BIT.
The affected platforms are DT based machines with 32-bit I/O and
these board files:
arch/arm/mach-pxa/idp.c: .flags = SMC91X_USE_32BIT | SMC91X_USE_DMA | SMC91X_NOWAIT,
arch/arm/mach-pxa/xcep.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT | SMC91X_USE_DMA,
arch/arm/mach-realview/core.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
arch/blackfin/mach-bf561/boards/cm_bf561.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
arch/blackfin/mach-bf561/boards/ezkit.c: .flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
Right, this looks like another one of your bugs in this conversion.
#elif defined(CONFIG_ARCH_INNOKOM) || \
defined(CONFIG_ARCH_PXA_IDP) || \
defined(CONFIG_ARCH_RAMSES) || \
defined(CONFIG_ARCH_PCM027)
#define SMC_CAN_USE_8BIT 1
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 1
So, IDP can use all of 32-bit, 16-bit and 8-bit accesses, meanwhile your
conversion is telling the driver that it can only use 32-bit => your
conversion of IDP is broken.
Before your conversion, realview depended on the default settings of
smc91x, which is again:
#define SMC_CAN_USE_8BIT 1
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 1
So realview follows IDP - it can do 32-bit, 16-bit and 8-bit accesses,
meanwhile your conversion tells the driver it can _only_ do 32-bit
accesses, which is again broken.
XCEP falls into the same category, as do the other two blackfin
cases from what I can see.
The point of the SMC_CAN_USE_xxx macros is to indicate to the SMC91x
driver which sizes of access can be used on the hardware concerned.
If SMC_CAN_USE_16BIT is set, then 16-bit accesses are possible. If
it's not set, then 8-bit accesses will be used if they're supported,
otherwise it's a buggy configuration.
SMC_CAN_USE_32BIT says that 32-bit accesses are possible, but these
are only used in a small number of cases as an optimisation.
It is a bug to configure the smc91x driver with both SMC_CAN_USE_16BIT
and SMC_CAN_USE_8BIT clear.
Hence, it's a bug to tell the driver (via the platform data) that only
32-bit accesses can be performed.
So, while my patch may be fixing some of the brokenness, the rest of
the brokenness also needs fixing by adjusting all the platform data
to properly reflect which access sizes are possible, rather than what
you seem to have done, which is to indicate what the largest possible
access size is.
This is especially important as there are platforms around where 16-bit
accesses to the SMC91x can be performed, but not 8-bit:
#elif defined(CONFIG_MACH_LOGICPD_PXA270) || \
defined(CONFIG_MACH_NOMADIK_8815NHK)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_SH_SH4202_MICRODEV)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_M32R)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_ARCH_MSM)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
#elif defined(CONFIG_COLDFIRE)
#define SMC_CAN_USE_8BIT 0
#define SMC_CAN_USE_16BIT 1
#define SMC_CAN_USE_32BIT 0
... etc ...
So, based on your patch introducing the breakage, these changes are
necessary to restore the per-platform capabilities that were originally
configured into the driver. I've also checked over the tree, and added
the others that only set SMC91X_USE_32BIT.
Lastly, I've added a comment to linux/smc91x.h indicating how these
bits are supposed to be used.
There may be other platforms which need updating - setting these bits
incorrectly can lead to more complex IO accesses than are necessary,
which, in a SMP environment, would be racy.
For instance, a missing SMC91X_USE_8BIT results in the interrupt
acknowledgement being written using a read-modify-write sequence with
a 16-bit access under local_irq_save(). That's also another
illustration why supporting at least one of 8-bit or 16-bit access is
mandatory - there is no emulation of the 8 or 16-bit accesses in terms
of 32-bit accessors.
arch/arm/mach-pxa/idp.c | 3 ++-
arch/arm/mach-pxa/xcep.c | 3 ++-
arch/arm/mach-realview/core.c | 3 ++-
arch/arm/mach-sa1100/pleb.c | 2 +-
arch/blackfin/mach-bf561/boards/cm_bf561.c | 3 ++-
arch/blackfin/mach-bf561/boards/ezkit.c | 3 ++-
include/linux/smc91x.h | 10 ++++++++++
7 files changed, 21 insertions(+), 6 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
From: Robert Jarzmik <robert.jarzmik@free.fr> Date: 2016-08-27 15:39:22
Russell King - ARM Linux [off-list ref] writes:
On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote:
quoted
Arnd Bergmann [off-list ref] writes:
quoted
On Thursday, August 25, 2016 4:43:04 PM CEST Arnd Bergmann wrote:
quoted
drivers/net/ethernet/smsc/smc91x.h | 50 +++++++++++++++++++++++---------------
1 file changed, 30 insertions(+), 20 deletions(-)
While this patch fixes one bug on Neponset, it probably doesn't address
the one that Russell ran into first, so this is for review only for now,
until the remaining problem(s) have been worked out.
The comment should have been on another patch, my mistake. please
see v2.
Arnd
Hi Arnd,
I didn't review the patch thoroughly, but I launched your 2 patches in my pxa
little farm.
The result is that lubbock and mainstone are all right, but zylonite is broken
(ie. networkless). I removed then these 2 patches and zylonite worked again.
I have also an error message on the console on a "broken" zylonite :
Changing smcs91x MAC address to 08:00:3e:26:0a:5b: ifconfig: SIOCSIFHWADDR:
Device or resource busy
I reran the test twice (2 times with your patches, 2 times without), the result
looks consistent, ie. zylonite doesn't really like them.
Please try the patch below. I sent this to Will a few days ago, as
he said (on irc) that he was also seeing problems on a platform he
had, but I've yet to hear back. I've not posted it yet because I
haven't got around to writing a commit description for it.
It does require that at least one of 8-bit or 16-bit accesses are
supported, but I think that's already true.
Hi Russell,
With your patch :
- lubbock, mainstone and zylonite boards are working correctly
=> ie. all my boards are working correctly
- the message "ifconfig: SIOCSIFHWADDR: Device or resource busy" is still there
=> this message is here even without your patch, so it's rather not relevant
=> this message is triggered by an "/sbin/ifconfig eth0 hw ether
08:00:3e:26:0a:5b" command
So from a PXA testing point of view it's all good, ie.
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cheers.
--
Robert
From: Russell King - ARM Linux <linux@armlinux.org.uk> Date: 2016-08-27 15:39:20
On Sat, Aug 27, 2016 at 05:30:42PM +0200, Robert Jarzmik wrote:
Hi Russell,
With your patch :
- lubbock, mainstone and zylonite boards are working correctly
=> ie. all my boards are working correctly
- the message "ifconfig: SIOCSIFHWADDR: Device or resource busy" is still there
=> this message is here even without your patch, so it's rather not relevant
=> this message is triggered by an "/sbin/ifconfig eth0 hw ether
08:00:3e:26:0a:5b" command
So from a PXA testing point of view it's all good, ie.
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Thanks for testing, that's good news.
You'll get "SIOCSIFHWADDR: Device or resource busy" if the device is
already up and has no support for changing the address while the NIC
is "live" - we only program the MAC address when bringing the smc91x
device up (or resetting it after a timeout).
See net/ethernet/eth.c::eth_prepare_mac_addr_change() and smc_enable().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.