gets rid of the dependencies and still allows for the reuse of
> code.
This patch fixes the modules_install issue I was seeing with module
dependency cycle.
You can add my:
Tested-by: Liviu Dudau
Thanks,
Liviu
>
> Reported-by: Liviu Dudau
> Signed-off-by: Jon Mason
> Fixe
On Fri, Jun 02, 2017 at 02:22:51PM -0400, David Miller wrote:
> From: Jon Mason
> Date: Wed, 31 May 2017 15:43:30 -0400
>
> > use of_mdio_parse_addr() in place of an OF read of reg and a bounds
> > check (which is litterally the exact same thing that
> > of_mdio_parse_addr() does)
> >
> > Signed
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
Signed-off-by: Stephen Hemminger
[Changed handcoded setup to use eth_hw_addr_random() and
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
Signed-off-by: Stephen Hemminger
[Changed handcoded setup to use eth_hw_addr_random() and
On Wed, Aug 12, 2015 at 04:28:23PM +0100, Stephen Hemminger wrote:
> On Wed, 12 Aug 2015 10:30:05 +0100
> Liviu Dudau wrote:
>
> > On Tue, Aug 11, 2015 at 06:01:32PM +0100, Stephen Hemminger wrote:
> > > On Tue, 11 Aug 2015 15:35:56 +0100
> > > Liviu Dudau wrote
On Tue, Aug 11, 2015 at 06:01:32PM +0100, Stephen Hemminger wrote:
> On Tue, 11 Aug 2015 15:35:56 +0100
> Liviu Dudau wrote:
>
> > 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 add
On Tue, Aug 11, 2015 at 07:56:06PM +0100, Sergei Shtylyov wrote:
> Hello.
>
> On 08/11/2015 05:35 PM, Liviu Dudau wrote:
>
> > 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
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
Signed-off-by: Stephen Hemminger
[Changed handcoded setup to use eth_hw_addr_random
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 pa
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.
> A
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 pa
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: L
12 matches
Mail list logo
