linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Steve deRosier <derosier@gmail.com>, Harsha Rao <harshrao464@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: Support on vendor id and device id
Date: Tue, 27 Feb 2018 21:04:02 +0100	[thread overview]
Message-ID: <5A95B9B2.4040403@broadcom.com> (raw)
In-Reply-To: <CALLGbRKrnnmsNtzpkABn+xOTjDaFKZz0jNxGkyJXMT1=XLa_3g@mail.gmail.com>

On 2/27/2018 6:34 PM, Steve deRosier wrote:
> Hi Harsha,
>
> Part 2 - the darn cmd-enter shortcut in gmail got me again. Sorry for
> the premature send.
>
>>
>> As both Larry and Arend mention, while it's possible to have multiple
>> drivers with the same IDs, for obvious reasons it's not desirable.
>>
>> In theory the vendor IDs shouldn't be duplicated on fundamentally
>> different devices, assuming that the manufacturers are doing things
>> "right". The VID is paid for by buying it from the SD Association.

Indeed. And this is fun already. If the sdio.ids file in systemd has any 
value the vendor id 0x296 is assigned to:

0296  GCT Semiconductor, Inc.
	5347  GDM72xx WiMAX

>> My suspicion is that your device, is fundamentally a wilc1000 and that
>> the existing wilc1000 driver will likely largely work for it and all
>> you really need to do is modify the existing driver to handle the
>> quirks of your particular implementation of the wilc1000 chip. And,
>> often WiFi chips will let you change the VID/PID somewhere within
>> whatever non-volatile storage it has (like where it stores the MAC
>> address).

So it seems the wilc1000 devices from Microchip/Atmel are also using a 
vendor id they did not buy. Could be that the mentioned 3rd party 
providing the SDIO IP actually owns that vendor id, but if you are 
building your wifi chip on that you should better buy you own vendor id 
from the SD Association. Now if Harsha is actually working for Microchip 
(unclear to me) there is basically one party that should go shopping.

> What I was going to mention is this is how it's worked for me many
> times on several chips from QCA, Broadcom and Marvell included. The
> use-case in this case would be building a custom WiFi module using a
> vendor's chip. Very common - Silex, Laird and others do this all the
> time: buy a chip from QCA (or Broadcom or Marvell or...), put it on a
> board with lna, pa, passives, antennas, etc...  And you package it and
> sell that often with value-add software.  Sometimes it's fine if it
> represents like the original chip (for example on the ath6kl chips
> Laird sells, it just uses the QCA IDs), but sometimes you want it to
> represent as "my chip" (again, as Laird has to do on the chips they
> sell to the Windows market to avoid the kind of driver conflicts
> you're encountering). All of these chips usually have a way to store a
> MAC address and at least all that I've worked on will also allow you
> to change the SDIO VID in the same one-time-programable memory.
> Obviously the method changes depending on the chip.
>
> However, in nearly every case, the chip is still fundamentally
> whatever it was and we still use the upstream driver, though often
> with tweaks and customizations based on our implementation. In the
> cases where we've added a custom VID, we've also had to add the new
> VID to the original driver and then key our quirks off that.
>
> I'm not saying this is definitely applicable in your case, but it is
> common and maybe it will help.
>
> Also thanks for bringing this issue up. Something I haven't thought
> about in a long time but I'm adding it to my talk at ELC on WiFi
> module interfacing. http://sched.co/DXn3

Hah. Keep plugging that talk and seats may become scarce :-p

Regards,
Arend

  reply	other threads:[~2018-02-27 20:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27 10:16 Support on vendor id and device id Harsha Rao
2018-02-27 11:15 ` Arend van Spriel
2018-02-27 13:30   ` Harsha Rao
2018-02-27 15:14     ` Larry Finger
2018-02-27 15:29       ` Harsha Rao
2018-02-27 17:15         ` Steve deRosier
2018-02-27 17:34           ` Steve deRosier
2018-02-27 20:04             ` Arend van Spriel [this message]
2018-02-27 23:14               ` Harsha Rao
2018-02-28  9:38                 ` Arend van Spriel
2018-03-01 10:10                   ` Harsha Rao
2018-03-13 19:23                     ` Arend van Spriel

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=5A95B9B2.4040403@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=derosier@gmail.com \
    --cc=harshrao464@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).