* Support on vendor id and device id @ 2018-02-27 10:16 Harsha Rao 2018-02-27 11:15 ` Arend van Spriel 0 siblings, 1 reply; 12+ messages in thread From: Harsha Rao @ 2018-02-27 10:16 UTC (permalink / raw) To: linux-wireless Hi folks, I am developing a new wifi driver for our sdio based wifi device. I see that SDIO_VENDOR_ID and SDIO_DEVICE_ID for our device (We had bought the SDIO IP from 3rd party) is already been used by some other vendor and its already into staging . Please suggest me how can I move forward to submit the driver for staging. Is there a way to reconfigure the values in the SDIO host for different value or does Linux allow two drivers with same values to survive mutual exclusively - Harsha ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 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 0 siblings, 1 reply; 12+ messages in thread From: Arend van Spriel @ 2018-02-27 11:15 UTC (permalink / raw) To: Harsha Rao, linux-wireless On 2/27/2018 11:16 AM, Harsha Rao wrote: > Hi folks, > I am developing a new wifi driver for our sdio based wifi device. > > I see that SDIO_VENDOR_ID and SDIO_DEVICE_ID for our device (We had > bought the SDIO IP from 3rd party) is already been used by some > other vendor and its already into staging . > > Please suggest me how can I move forward to submit the driver for staging. Can you be more specific about the conflicting vendor id and device id? > Is there a way to reconfigure the values in the SDIO host for > different value or does Linux allow two drivers with same values to > survive mutual exclusively First come first serve. When a device is detected, the driver core looks for drivers supporting it based on device table and the first that successfully returns from the .probe() callback is bound to the device. Regards, Arend ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 11:15 ` Arend van Spriel @ 2018-02-27 13:30 ` Harsha Rao 2018-02-27 15:14 ` Larry Finger 0 siblings, 1 reply; 12+ messages in thread From: Harsha Rao @ 2018-02-27 13:30 UTC (permalink / raw) To: Arend van Spriel; +Cc: linux-wireless On Tue, Feb 27, 2018 at 4:45 PM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote: > On 2/27/2018 11:16 AM, Harsha Rao wrote: >> >> Hi folks, >> I am developing a new wifi driver for our sdio based wifi device. >> >> I see that SDIO_VENDOR_ID and SDIO_DEVICE_ID for our device (We had >> bought the SDIO IP from 3rd party) is already been used by some >> other vendor and its already into staging . >> >> Please suggest me how can I move forward to submit the driver for staging. > > > Can you be more specific about the conflicting vendor id and device id? Hi, My driver kicks in with vendor id 0x296 and device id 0x5347. But when I grepped the the kernel source I could see an other driver wilc1000 using the same vendor ID and device ID ( We have a different hw than them !) >> Is there a way to reconfigure the values in the SDIO host for >> different value or does Linux allow two drivers with same values to >> survive mutual exclusively > > > First come first serve. When a device is detected, the driver core looks for > drivers supporting it based on device table and the first that successfully > returns from the .probe() callback is bound to the device. > > Regards, > Arend Does Linux allow two drivers with conflicting device and vendor IDs to stay on in kernel ? - Harsha ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 13:30 ` Harsha Rao @ 2018-02-27 15:14 ` Larry Finger 2018-02-27 15:29 ` Harsha Rao 0 siblings, 1 reply; 12+ messages in thread From: Larry Finger @ 2018-02-27 15:14 UTC (permalink / raw) To: Harsha Rao, Arend van Spriel; +Cc: linux-wireless On 02/27/2018 07:30 AM, Harsha Rao wrote: > On Tue, Feb 27, 2018 at 4:45 PM, Arend van Spriel > <arend.vanspriel@broadcom.com> wrote: >> On 2/27/2018 11:16 AM, Harsha Rao wrote: >>> >>> Hi folks, >>> I am developing a new wifi driver for our sdio based wifi device. >>> >>> I see that SDIO_VENDOR_ID and SDIO_DEVICE_ID for our device (We had >>> bought the SDIO IP from 3rd party) is already been used by some >>> other vendor and its already into staging . >>> >>> Please suggest me how can I move forward to submit the driver for staging. >> >> >> Can you be more specific about the conflicting vendor id and device id? > > Hi, > My driver kicks in with vendor id 0x296 and device id 0x5347. > But when I grepped the the kernel source I could see an other driver > wilc1000 using the same vendor ID and device ID > ( We have a different hw than them !) > >>> Is there a way to reconfigure the values in the SDIO host for >>> different value or does Linux allow two drivers with same values to >>> survive mutual exclusively >> >> >> First come first serve. When a device is detected, the driver core looks for >> drivers supporting it based on device table and the first that successfully >> returns from the .probe() callback is bound to the device. >> >> Regards, >> Arend > > Does Linux allow two drivers with conflicting device and vendor IDs to > stay on in kernel ? Yes. We have a similar situation with the rtl8192e driver in staging and the rtl8192se driver in the wireless tree, which share PCI ID 0bda:8192. Our solution was to insert code in the probe routine that tests some value in addition to the PCI ID. In our case, that was the PCI revision id. Line 2496 of file drivers/staging/rtl8192e/rtl8192e/rtl_core.c shows the test in the staging driver. The downsides of this unfortunate duplication are that if the wrong driver loads first, then it remains loaded, you will need to cooperate with the maintainer of the other driver to insert the extra detection code, and you may need to do quite a bit of processing to be able to determine whether you have the correct device. Larry ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 15:14 ` Larry Finger @ 2018-02-27 15:29 ` Harsha Rao 2018-02-27 17:15 ` Steve deRosier 0 siblings, 1 reply; 12+ messages in thread From: Harsha Rao @ 2018-02-27 15:29 UTC (permalink / raw) To: Larry Finger; +Cc: Arend van Spriel, linux-wireless On Tue, Feb 27, 2018 at 8:44 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote: > On 02/27/2018 07:30 AM, Harsha Rao wrote: >> >> On Tue, Feb 27, 2018 at 4:45 PM, Arend van Spriel >> <arend.vanspriel@broadcom.com> wrote: >>> >>> On 2/27/2018 11:16 AM, Harsha Rao wrote: >>>> >>>> >>>> Hi folks, >>>> I am developing a new wifi driver for our sdio based wifi device. >>>> >>>> I see that SDIO_VENDOR_ID and SDIO_DEVICE_ID for our device (We had >>>> bought the SDIO IP from 3rd party) is already been used by some >>>> other vendor and its already into staging . >>>> >>>> Please suggest me how can I move forward to submit the driver for >>>> staging. >>> >>> >>> >>> Can you be more specific about the conflicting vendor id and device id? >> >> >> Hi, >> My driver kicks in with vendor id 0x296 and device id 0x5347. >> But when I grepped the the kernel source I could see an other driver >> wilc1000 using the same vendor ID and device ID >> ( We have a different hw than them !) >> >>>> Is there a way to reconfigure the values in the SDIO host for >>>> different value or does Linux allow two drivers with same values to >>>> survive mutual exclusively >>> >>> >>> >>> First come first serve. When a device is detected, the driver core looks >>> for >>> drivers supporting it based on device table and the first that >>> successfully >>> returns from the .probe() callback is bound to the device. >>> >>> Regards, >>> Arend >> >> >> Does Linux allow two drivers with conflicting device and vendor IDs to >> stay on in kernel ? > > > Yes. We have a similar situation with the rtl8192e driver in staging and the > rtl8192se driver in the wireless tree, which share PCI ID 0bda:8192. Our > solution was to insert code in the probe routine that tests some value in > addition to the PCI ID. In our case, that was the PCI revision id. Line 2496 > of file drivers/staging/rtl8192e/rtl8192e/rtl_core.c shows the test in the > staging driver. > > The downsides of this unfortunate duplication are that if the wrong driver > loads first, then it remains loaded, you will need to cooperate with the > maintainer of the other driver to insert the extra detection code, and you > may need to do quite a bit of processing to be able to determine whether you > have the correct device. > > Larry > Thanks Larry and Arend for your valuable time in clarifying my doubts.. - Harsha ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 15:29 ` Harsha Rao @ 2018-02-27 17:15 ` Steve deRosier 2018-02-27 17:34 ` Steve deRosier 0 siblings, 1 reply; 12+ messages in thread From: Steve deRosier @ 2018-02-27 17:15 UTC (permalink / raw) To: Harsha Rao; +Cc: Larry Finger, Arend van Spriel, linux-wireless Hi Harsha, On Tue, Feb 27, 2018 at 7:29 AM, Harsha Rao <harshrao464@gmail.com> wrote: > On Tue, Feb 27, 2018 at 8:44 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote: >> On 02/27/2018 07:30 AM, Harsha Rao wrote: >>> >>> On Tue, Feb 27, 2018 at 4:45 PM, Arend van Spriel >>> <arend.vanspriel@broadcom.com> wrote: >>>> >>>> On 2/27/2018 11:16 AM, Harsha Rao wrote: >>>>> >>>>> >>>>> Hi folks, >>>>> I am developing a new wifi driver for our sdio based wifi device. >>>>> >>>>> I see that SDIO_VENDOR_ID and SDIO_DEVICE_ID for our device (We had >>>>> bought the SDIO IP from 3rd party) is already been used by some >>>>> other vendor and its already into staging . >>>>> >>>>> Please suggest me how can I move forward to submit the driver for >>>>> staging. >>>> >>>> >>>> >>>> Can you be more specific about the conflicting vendor id and device id? >>> >>> >>> Hi, >>> My driver kicks in with vendor id 0x296 and device id 0x5347. >>> But when I grepped the the kernel source I could see an other driver >>> wilc1000 using the same vendor ID and device ID >>> ( We have a different hw than them !) >>> >>>>> Is there a way to reconfigure the values in the SDIO host for >>>>> different value or does Linux allow two drivers with same values to >>>>> survive mutual exclusively >>>> >>>> >>>> >>>> First come first serve. When a device is detected, the driver core looks >>>> for >>>> drivers supporting it based on device table and the first that >>>> successfully >>>> returns from the .probe() callback is bound to the device. >>>> >>>> Regards, >>>> Arend >>> >>> >>> Does Linux allow two drivers with conflicting device and vendor IDs to >>> stay on in kernel ? >> >> >> Yes. We have a similar situation with the rtl8192e driver in staging and the >> rtl8192se driver in the wireless tree, which share PCI ID 0bda:8192. Our >> solution was to insert code in the probe routine that tests some value in >> addition to the PCI ID. In our case, that was the PCI revision id. Line 2496 >> of file drivers/staging/rtl8192e/rtl8192e/rtl_core.c shows the test in the >> staging driver. >> >> The downsides of this unfortunate duplication are that if the wrong driver >> loads first, then it remains loaded, you will need to cooperate with the >> maintainer of the other driver to insert the extra detection code, and you >> may need to do quite a bit of processing to be able to determine whether you >> have the correct device. >> >> Larry >> 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. 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 17:15 ` Steve deRosier @ 2018-02-27 17:34 ` Steve deRosier 2018-02-27 20:04 ` Arend van Spriel 0 siblings, 1 reply; 12+ messages in thread From: Steve deRosier @ 2018-02-27 17:34 UTC (permalink / raw) To: Harsha Rao; +Cc: Larry Finger, Arend van Spriel, linux-wireless 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. > > 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). 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 - Steve -- Steve deRosier Cal-Sierra Consulting LLC https://www.cal-sierra.com/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 17:34 ` Steve deRosier @ 2018-02-27 20:04 ` Arend van Spriel 2018-02-27 23:14 ` Harsha Rao 0 siblings, 1 reply; 12+ messages in thread From: Arend van Spriel @ 2018-02-27 20:04 UTC (permalink / raw) To: Steve deRosier, Harsha Rao; +Cc: Larry Finger, linux-wireless 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 20:04 ` Arend van Spriel @ 2018-02-27 23:14 ` Harsha Rao 2018-02-28 9:38 ` Arend van Spriel 0 siblings, 1 reply; 12+ messages in thread From: Harsha Rao @ 2018-02-27 23:14 UTC (permalink / raw) To: Arend van Spriel; +Cc: Steve deRosier, Larry Finger, linux-wireless On Wed, Feb 28, 2018 at 1:34 AM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote: > 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. > I would like to clarify that I am not building anything on top of microchip wifi device. We have a different HW . Its been just that 3rd party vendor providing SDIO IP has given same ID to different customers. > >> 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. >> Definitely I will have a look at it . >> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-27 23:14 ` Harsha Rao @ 2018-02-28 9:38 ` Arend van Spriel 2018-03-01 10:10 ` Harsha Rao 0 siblings, 1 reply; 12+ messages in thread From: Arend van Spriel @ 2018-02-28 9:38 UTC (permalink / raw) To: Harsha Rao; +Cc: Steve deRosier, Larry Finger, linux-wireless On 2/28/2018 12:14 AM, Harsha Rao wrote: >>>> 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. >> > > I would like to clarify that I am not building anything on top of > microchip wifi device. > We have a different HW . Its been just that 3rd party vendor providing > SDIO IP has given > same ID to different customers. So it is as I said, ie. you are using the 3rd party SDIO IP as is and add your own wifi IP to it? So what does the term "SDIO IP" mean here. Is it a piece of hardware that you hook up to your wifi hardware or is it VHDL/verilog in which the vendor id is defined. If it is VHDL you should really get your own vendor id from the SD Association and fix it. Otherwise, the 3rd party hardware should have means to change it. If not, you better find another party. Regards, Arend ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-02-28 9:38 ` Arend van Spriel @ 2018-03-01 10:10 ` Harsha Rao 2018-03-13 19:23 ` Arend van Spriel 0 siblings, 1 reply; 12+ messages in thread From: Harsha Rao @ 2018-03-01 10:10 UTC (permalink / raw) To: Arend van Spriel; +Cc: Steve deRosier, Larry Finger, linux-wireless On Wed, Feb 28, 2018 at 3:08 PM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote: > On 2/28/2018 12:14 AM, Harsha Rao wrote: >>>>> >>>>> 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. >>> > >> >> I would like to clarify that I am not building anything on top of >> microchip wifi device. >> We have a different HW . Its been just that 3rd party vendor providing >> SDIO IP has given >> same ID to different customers. > > > So it is as I said, ie. you are using the 3rd party SDIO IP as is and add > your own wifi IP to it? So what does the term "SDIO IP" mean here. Is it a > piece of hardware that you hook up to your wifi hardware or is it > VHDL/verilog in which the vendor id is defined. If it is VHDL you should > really get your own vendor id from the SD Association and fix it. Otherwise, > the 3rd party hardware should have means to change it. If not, you better > find another party. > > Regards, > Arend Thank you folks for your comments. The SDIO IP is VHDL IP core integrated on our SoC. And we figured out a way to update vendor ID at run-time during boot. We would get our own vendor ID from SD association and proceed . - Harsha ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support on vendor id and device id 2018-03-01 10:10 ` Harsha Rao @ 2018-03-13 19:23 ` Arend van Spriel 0 siblings, 0 replies; 12+ messages in thread From: Arend van Spriel @ 2018-03-13 19:23 UTC (permalink / raw) To: Harsha Rao Cc: Steve deRosier, Larry Finger, linux-wireless, Greg KH, Aditya Shankar, Ganesh Krishna + Greg, +wilc1000 maintainers On 3/1/2018 11:10 AM, Harsha Rao wrote: > On Wed, Feb 28, 2018 at 3:08 PM, Arend van Spriel > <arend.vanspriel@broadcom.com> wrote: >> On 2/28/2018 12:14 AM, Harsha Rao wrote: >>>>>> >>>>>> 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. >>>>> >>> >>> I would like to clarify that I am not building anything on top of >>> microchip wifi device. >>> We have a different HW . Its been just that 3rd party vendor providing >>> SDIO IP has given >>> same ID to different customers. >> >> >> So it is as I said, ie. you are using the 3rd party SDIO IP as is and add >> your own wifi IP to it? So what does the term "SDIO IP" mean here. Is it a >> piece of hardware that you hook up to your wifi hardware or is it >> VHDL/verilog in which the vendor id is defined. If it is VHDL you should >> really get your own vendor id from the SD Association and fix it. Otherwise, >> the 3rd party hardware should have means to change it. If not, you better >> find another party. >> >> Regards, >> Arend > > Thank you folks for your comments. > The SDIO IP is VHDL IP core integrated on our SoC. And we figured out > a way to update vendor ID at run-time during boot. > We would get our own vendor ID from SD association and proceed . Coming back to this thread as it seems that wilc1000 has exactly the same issue or blindly reusing the SDIO vendor id. Below excerpt from earlier email in this thread: """ >> 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 """ So claiming it for wilc1000 seems wrong unless GCT and Microchip are actually the same company, but I could not find any evidence for that. The bad news is probably that this device is already on the market :-( Regards, Arend ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-03-13 19:23 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.