On Thu, Aug 06, 2015 at 01:32:33AM +0100, David Miller wrote:
> From: Liviu Dudau
> Date: Wed, 5 Aug 2015 16:50:54 +0100
>
> > For designs where EEPROMs are not connected to PCI Yukon2
> > chips we need to get the MAC address from the firmware.
> > Add a module parameter called 'mac_address'
On Thu, Aug 06, 2015 at 01:32:33AM +0100, David Miller wrote:
From: Liviu Dudau liviu.du...@arm.com
Date: Wed, 5 Aug 2015 16:50:54 +0100
For designs where EEPROMs are not connected to PCI Yukon2
chips we need to get the MAC address from the firmware.
Add a module parameter called
On 05/08/15 16:16, Stephen Hemminger wrote:
> Something like this:
>
> Subject: [PATCH net-next] sky2: use random address if EEPROM is bad
>
> On some embedded systems the EEPROM does not contain a valid MAC address.
> In that case it is better to fallback to a generated mac address and
> let
From: Liviu Dudau
Date: Wed, 5 Aug 2015 16:50:54 +0100
> For designs where EEPROMs are not connected to PCI Yukon2
> chips we need to get the MAC address from the firmware.
> Add a module parameter called 'mac_address' for this. It
> will be used if no DT node can be found and the B2_MAC
>
Something like this:
Subject: [PATCH net-next] sky2: use random address if EEPROM is bad
On some embedded systems the EEPROM does not contain a valid MAC address.
In that case it is better to fallback to a generated mac address and
let init scripts fix the value later.
Reported-by: Liviu Dudau
Liviu Dudau :
> On Wed, Aug 05, 2015 at 05:40:57PM +0100, Stephen Hemminger wrote:
[...]
> > Yes, I can see that this can be a real problem, and other drivers
> > solve the problem. The standard method is to assign a random mac address
> > (and then let scripts overwrite) rather than introducing
On Wed, Aug 05, 2015 at 06:15:37PM +0100, Ryan Harkin wrote:
>On 5 August 2015 at 16:50, Liviu Dudau <[1]liviu.du...@arm.com> wrote:
>
> For designs where EEPROMs are not connected to PCI Yukon2
> chips we need to get the MAC address from the firmware.
> Add a module parameter
On Wed, Aug 05, 2015 at 05:40:57PM +0100, Stephen Hemminger wrote:
> On Wed, 5 Aug 2015 16:50:54 +0100
> Liviu Dudau wrote:
>
> > For designs where EEPROMs are not connected to PCI Yukon2
> > chips we need to get the MAC address from the firmware.
> > Add a module parameter called 'mac_address'
On Wed, 5 Aug 2015 16:50:54 +0100
Liviu Dudau wrote:
> For designs where EEPROMs are not connected to PCI Yukon2
> chips we need to get the MAC address from the firmware.
> Add a module parameter called 'mac_address' for this. It
> will be used if no DT node can be found and the B2_MAC
>
For designs where EEPROMs are not connected to PCI Yukon2
chips we need to get the MAC address from the firmware.
Add a module parameter called 'mac_address' for this. It
will be used if no DT node can be found and the B2_MAC
register holds an invalid value.
Signed-off-by: Liviu Dudau
---
For designs where EEPROMs are not connected to PCI Yukon2
chips we need to get the MAC address from the firmware.
Add a module parameter called 'mac_address' for this. It
will be used if no DT node can be found and the B2_MAC
register holds an invalid value.
Signed-off-by: Liviu Dudau
On Wed, 5 Aug 2015 16:50:54 +0100
Liviu Dudau liviu.du...@arm.com wrote:
For designs where EEPROMs are not connected to PCI Yukon2
chips we need to get the MAC address from the firmware.
Add a module parameter called 'mac_address' for this. It
will be used if no DT node can be found and the
On Wed, Aug 05, 2015 at 05:40:57PM +0100, Stephen Hemminger wrote:
On Wed, 5 Aug 2015 16:50:54 +0100
Liviu Dudau liviu.du...@arm.com wrote:
For designs where EEPROMs are not connected to PCI Yukon2
chips we need to get the MAC address from the firmware.
Add a module parameter called
On Wed, Aug 05, 2015 at 06:15:37PM +0100, Ryan Harkin wrote:
On 5 August 2015 at 16:50, Liviu Dudau [1]liviu.du...@arm.com wrote:
For designs where EEPROMs are not connected to PCI Yukon2
chips we need to get the MAC address from the firmware.
Add a module parameter called
Liviu Dudau liviu.du...@arm.com :
On Wed, Aug 05, 2015 at 05:40:57PM +0100, Stephen Hemminger wrote:
[...]
Yes, I can see that this can be a real problem, and other drivers
solve the problem. The standard method is to assign a random mac address
(and then let scripts overwrite) rather than
Something like this:
Subject: [PATCH net-next] sky2: use random address if EEPROM is bad
On some embedded systems the EEPROM does not contain a valid MAC address.
In that case it is better to fallback to a generated mac address and
let init scripts fix the value later.
Reported-by: Liviu Dudau
From: Liviu Dudau liviu.du...@arm.com
Date: Wed, 5 Aug 2015 16:50:54 +0100
For designs where EEPROMs are not connected to PCI Yukon2
chips we need to get the MAC address from the firmware.
Add a module parameter called 'mac_address' for this. It
will be used if no DT node can be found and
On 05/08/15 16:16, Stephen Hemminger wrote:
Something like this:
Subject: [PATCH net-next] sky2: use random address if EEPROM is bad
On some embedded systems the EEPROM does not contain a valid MAC address.
In that case it is better to fallback to a generated mac address and
let init
18 matches
Mail list logo
