On Thursday 12 February 2009 02:33:46 Wolfgang Denk wrote:
> net: new utility functions for working with enetaddr's:
>
> Please ditch str_enetaddr() and rename str_enetaddr_r() into
> str_enetaddr(); using a static buffer for the return value is
> nothing I'd like to see in the co
Dear Mike,
In message <200902112029.30937.vap...@gentoo.org> you wrote:
>
> please checkout the macaddr branch of the blackfin repo ... there's about 60
> changes cookin in there that touch every arch and common/boards/drivers. i'd
> like to get you to eye em over first before i spam the list
On Thursday 12 February 2009 01:24:03 Ben Warren wrote:
> > > > ok, i'll start up a branch to do this conversion in my repo. i'm
> > > > guessing Ben wont have a problem with someone doing the grunt work
> > > > ;).
> > >
> > > Uh, yeah. Not a problem. Thanks!
> >
> > please checkout the macaddr
Hi Mike,
>
> > >
> > > ok, i'll start up a branch to do this conversion in my repo. i'm
> > > guessing Ben wont have a problem with someone doing the grunt work ;).
> > > -mike
> >
> > Uh, yeah. Not a problem. Thanks!
>
> please checkout the macaddr branch of the blackfin repo ... there's abou
On Wednesday 11 February 2009 15:15:22 Ben Warren wrote:
> Mike Frysinger wrote:
> > On Wednesday 11 February 2009 07:17:39 Wolfgang Denk wrote:
> >> Dear Ben Warren,
> >>
> >> In message <499265e1.4050...@gmail.com> you wrote:
> >>> Thanks for tackling this cluste...@#. I'm not crazy about the
>
Mike Frysinger wrote:
> On Wednesday 11 February 2009 07:17:39 Wolfgang Denk wrote:
>
>> Dear Ben Warren,
>>
>> In message <499265e1.4050...@gmail.com> you wrote:
>>
>>> Thanks for tackling this cluste...@#. I'm not crazy about the
>>> CONFIG_NET_MULTI_MAX, but then I'm not really sure why
On Wednesday 11 February 2009 07:17:39 Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message <499265e1.4050...@gmail.com> you wrote:
> > Thanks for tackling this cluste...@#. I'm not crazy about the
> > CONFIG_NET_MULTI_MAX, but then I'm not really sure why the ethernet
> > addresses exist in glo
Dear Ben Warren,
In message <499265e1.4050...@gmail.com> you wrote:
>
> Thanks for tackling this cluste...@#. I'm not crazy about the
> CONFIG_NET_MULTI_MAX, but then I'm not really sure why the ethernet
> addresses exist in global data on boards with CONFIG_NET_MULTI. The net
Good point.
L
On Wednesday 11 February 2009 00:45:05 Ben Warren wrote:
> Mike Frysinger wrote:
> > On Tuesday 03 February 2009 14:40:00 Mike Frysinger wrote:
> >> i think we can agree that this does not scale at all. if, however, we
> >> change the global data to something like:
> >> typedef struct bd_info {
>
Mike Frysinger wrote:
> On Tuesday 03 February 2009 14:40:00 Mike Frysinger wrote:
>
>> i think we can agree that this does not scale at all. if, however, we
>> change the global data to something like:
>> typedef struct bd_info {
>> ...
>> #ifdef CONFIG_NET_MULTI
>> uchar bi_enetXadd
On Tuesday 03 February 2009 14:40:00 Mike Frysinger wrote:
> i think we can agree that this does not scale at all. if, however, we
> change the global data to something like:
> typedef struct bd_info {
> ...
> #ifdef CONFIG_NET_MULTI
> uchar bi_enetXaddr[CONFIG_NET_MULTI_MAX][6];
> # d
On Tuesday 03 February 2009 03:16:27 Wolfgang Denk wrote:
> Dear Mike Frysinger,
>
> In message <200902021937.26246.vap...@gentoo.org> you wrote:
> > > Please change:
> > >
> > > If the hardware design mandates that the MAC address is stored
> > > in some special place, like EEPROM etc., then t
Dear Mike Frysinger,
In message <200902021937.26246.vap...@gentoo.org> you wrote:
>
> > Please change:
> >
> > If the hardware design mandates that the MAC address is stored
> > in some special place, like EEPROM etc., then the board
> > specific init code (like the board-specific misc
On Monday 02 February 2009 16:04:34 Wolfgang Denk wrote:
> In message Mike Frysinger you wrote:
> > ---
> > Usage
> > ---
> >
> > During board init (like the board-specific misc_init_r() function),
> > boards should take care of locating the MAC address, initializing the
> > environment, a
Dear Mike Frysinger,
In message <200902021505.17476.vap...@gentoo.org> you wrote:
>
> how about this document at doc/README.enetaddr ...
Thanks!
> -
> Ethernet Address (MAC) Handling
> -
>
> There are a variety of places in U-Boot
On Thursday 29 January 2009 20:23:06 Mike Frysinger wrote:
> at any rate, i'm fine with having the driver assume bi_enetaddr is sane.
> so the series of patches i just posted starts unifying the things i whined
> about earlier and does what you suggested.
>
> unfortunately, with this small review
On Thursday 29 January 2009 17:18:00 Wolfgang Denk wrote:
> In message <200901291648.02480.vap...@gentoo.org> you wrote:
> > > > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt
> > > > > set already and sets bi_enetaddr in global data
> > > > > - board_eth_init(
Dear Mike Frysinger,
In message <200901291648.02480.vap...@gentoo.org> you wrote:
>
> > > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt
> > > > set already and sets bi_enetaddr in global data
> > > > - board_eth_init() calls the driver init
> > > >
On Thursday 29 January 2009 16:17:09 Wolfgang Denk wrote:
> In message <200901291605.09474.vap...@gentoo.org> you wrote:
> > > Rather:
> > >
> > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt
> > > set already and sets bi_enetaddr in global data
> > > - board_eth_init() ca
Dear Mike Frysinger,
In message <200901291605.09474.vap...@gentoo.org> you wrote:
>
> > Rather:
> >
> > - misc_init_r() [or similar] sets up ethaddr in env if it isnt
> > set already and sets bi_enetaddr in global data
> > - board_eth_init() calls the driver init
> > (bfin_EMAC
On Thursday 29 January 2009 15:41:31 Wolfgang Denk wrote:
> In message <200901291525.03553.vap...@gentoo.org> you wrote:
> > so how exactly are $ethaddr in the env and bi_enetaddr in the global data
> > supposed to interact ? this is a mess in the current tree and i dont see
> > any notes that ind
Dear Mike Frysinger,
In message <200901291525.03553.vap...@gentoo.org> you wrote:
>
> so how exactly are $ethaddr in the env and bi_enetaddr in the global data
> supposed to interact ? this is a mess in the current tree and i dont see any
> notes that indicate how things are supposed to be hand
On Thursday 29 January 2009 14:03:36 Wolfgang Denk wrote:
> In message <200901291135.32632.vap...@gentoo.org> you wrote:
> > the driver isnt really generic. it's specific to the hardware that
> > exists inside of Blackfin chips. the hardware has no support at all for
> > storing the
>
> Well, the
Dear Mike Frysinger,
In message <200901291135.32632.vap...@gentoo.org> you wrote:
>
> the driver isnt really generic. it's specific to the hardware that exists
> inside of Blackfin chips. the hardware has no support at all for storing the
Well, the same applies for many other Ethernet drivers
On Thursday 29 January 2009 05:45:23 Wolfgang Denk wrote:
> In message <1233212358-27956-1-git-send-email-vap...@gentoo.org> you wrote:
> > Since the on-chip MAC does not have an eeprom or similar interface, force
> > all Blackfin boards that use this to define their own
> > board_get_enetaddr() fu
Dear Mike Frysinger,
In message <1233212358-27956-1-git-send-email-vap...@gentoo.org> you wrote:
> Since the on-chip MAC does not have an eeprom or similar interface, force
> all Blackfin boards that use this to define their own board_get_enetaddr()
> function.
I still think this belongs into boa
Mike Frysinger wrote:
> Since the on-chip MAC does not have an eeprom or similar interface, force
> all Blackfin boards that use this to define their own board_get_enetaddr()
> function.
>
> Signed-off-by: Mike Frysinger
> CC: Ben Warren
>
Acked-by: Ben Warren
> ---
> v2
> - drop CONFIG
Since the on-chip MAC does not have an eeprom or similar interface, force
all Blackfin boards that use this to define their own board_get_enetaddr()
function.
Signed-off-by: Mike Frysinger
CC: Ben Warren
---
v2
- drop CONFIG_ETHADDR handling
drivers/net/bfin_mac.c | 21 ++
28 matches
Mail list logo
