On Fri, 2023-02-10 at 19:12 +0000, Ajay.Kathat@xxxxxxxxxxxxx wrote:
> Hi Kalle,
>
> On 2/10/23 02:25, Kalle Valo wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > Heiko Thiery <heiko.thiery@xxxxxxxxx> writes:
> >
> > > HI,
> > >
> > > Am Do., 9. Feb. 2023 um 22:19 Uhr schrieb Michael Walle
> > > <michael@xxxxxxxx>:
> > > >
> > > > Am 2023-02-09 22:07, schrieb Jakub Kicinski:
> > > > > On Thu, 9 Feb 2023 18:51:58 +0000
> > > > > Ajay.Kathat@xxxxxxxxxxxxx wrote:
> > > > > > > netdev should be created with a valid lladdr, is there
> > > > > > > something
> > > > > > > wifi-specific here that'd prevalent that? The canonical
> > > > > > > flow is
> > > > > > > to this before registering the netdev:
> > > > > >
> > > > > > Here it's the timing in wilc1000 by when the MAC address is
> > > > > > available
> > > > > > to
> > > > > > read from NV. NV read is available in "mac_open"
> > > > > > net_device_ops
> > > > > > instead
> > > > > > of bus probe function. I think, mostly the operations on
> > > > > > netdev which
> > > > > > make use of mac address are performed after the "mac_open"
> > > > > > (I may be
> > > > > > missing something).
> > > > > >
> > > > > > Does it make sense to assign a random address in probe and
> > > > > > later read
> > > > > > back from NV in mac_open to make use of stored value?
> > > > >
> > > > > Hard to say, I'd suspect that may be even more confusing than
> > > > > starting with zeroes. There aren't any hard rules around the
> > > > > addresses AFAIK, but addrs are visible to user space. So user
> > > > > space will likely make assumptions based on the most commonly
> > > > > observed sequence (reading real addr at probe).
> > > >
> > > > Maybe we should also ask the NetworkManager guys. IMHO random
> > > > MAC address sounds bogus.
> > >
> > > Maybe it would be a "workaround" with loading the firmware while
> > > probing the device to set the real hw address.
> > >
> > > probe()
> > > load_fw()
> > > read_hw_addr_from_nv()
> > > eth_hw_addr_set(ndev, addr)
> > > unload_fw()
> > >
> > > mac_open()
> > > load_fw()
> > >
> > > mac_close()
> > > unload_fw()
> >
> > This is exactly what many wireless drivers already do and I
> > recommend
> > that wilc1000 would do the same.
> >
>
> In wilc1000, the bus interface is up in probe but we don't have
> access
> to mac address via register until the driver starts the wilc firmware
> because of design limitation. This information is only available
> after
> the MAC layer is initialized.
So... initialize the MAC layer and read the address, then stop the card
until dev open which reloads and reinits? That's what eg Atmel does
(though it has a special "read the MAC only" firmware to do that):
/* No stored firmware so load a small stub which just
tells us the MAC address */
int i;
priv->card_type = CARD_TYPE_EEPROM;
atmel_write16(dev, BSR, BSS_IRAM);
atmel_copy_to_card(dev, 0, mac_reader, sizeof(mac_reader));
atmel_set_gcr(dev, GCR_REMAP);
atmel_clear_gcr(priv->dev, 0x0040);
atmel_write16(dev, BSR, BSS_SRAM);
for (i = LOOP_RETRY_LIMIT; i; i--)
if (atmel_read16(dev, MR3) & MAC_BOOT_COMPLETE)
break;
if (i == 0) {
printk(KERN_ALERT "%s: MAC failed to boot MAC address reader.\n", dev->name);
} else {
atmel_copy_to_host(dev, addr, atmel_read16(dev, MR2), 6);
eth_hw_addr_set(dev, addr);
/* got address, now squash it again until the network
interface is opened */
if (priv->bus_type == BUS_TYPE_PCCARD)
atmel_write16(dev, GCR, 0x0060);
atmel_write16(dev, GCR, 0x0040);
rc = 1;
}
Dan
>
>
> Regards,
> Ajay
