All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Mathias Kresin <dev@kresin.me>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] rt2x00: add support for mac addr from device tree
Date: Thu, 25 Aug 2016 15:19:08 +0200	[thread overview]
Message-ID: <20160825131907.GA7834@redhat.com> (raw)
In-Reply-To: <CABwW5nkxpX_SsCorU0kuuOVDcNP5QARdyTbP=AWM5=QTZOW=eA@mail.gmail.com>

On Thu, Aug 25, 2016 at 01:12:22PM +0200, Mathias Kresin wrote:
> 2016-08-25 11:33 GMT+02:00 Stanislaw Gruszka <sgruszka@redhat.com>:
> >
> > On Thu, Aug 25, 2016 at 10:19:22AM +0200, Mathias Kresin wrote:
> > > The EEPROM used on some CPEs has for every device the same generic
> > > ralink mac in EEPROM and needs to be overridden.
> >
> > I don't know what is CPE, but even if I would know that, I most likely
> > sill will not understand that description.
> 
> Well, seams to me the commit message can be improved. If a v2 is
> required or a v2 is required because of the commit message, I'll take
> care of it.

Please do.

> CPE = Customer Premises Equipment or the small plastic box from your
> ISP at home. The whole point of the patch is that the MAC stored in
> the wifi EEPROM might not be unique and need to be overridden. I'm
> aware of three different "home router", where each model has the same
> generic ralink MAC address stored in the wifi EEPROM. This can cause
> nasty issues.

I think we still want MAC from EEPROM instead of random one on systems
without OF. Otherwise we could just use random MAC every time, but this
does not seems lika a good idea.

Can we check against that particular MAC that repeats on those CPEs and
if it match use random one ? Or use some other identification to find
out that EEPROM MAC is not good ?

> > Shouldn't use dev_of_node(&rt2x00dev->dev) and check against NULL ?
> 
> Not sure if dev_of_node() is meant to be used by every driver. Or at
> least the function is only used by base stuff and not by any driver.
> 
> The NULL check doesn't seam to me required. The of_node is finally
> passed to __of_find_property which does the NULL check before using
> of_node.

Ok.

Thanks
Stanislaw

  reply	other threads:[~2016-08-25 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25  8:19 [PATCH] rt2x00: add support for mac addr from device tree Mathias Kresin
2016-08-25  9:33 ` Stanislaw Gruszka
2016-08-25 11:12   ` Mathias Kresin
2016-08-25 13:19     ` Stanislaw Gruszka [this message]
2016-08-25 15:03       ` Mathias Kresin
2016-08-25 15:18         ` Stanislaw Gruszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160825131907.GA7834@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=dev@kresin.me \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.