Macro names were derived from the Windows driver, as that was the best
available source.
Signed-off-by: Brian O'Keefe <[email protected]>
---
include/linux/mmc/sdio_ids.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 12036619346c..97ccb0ac5e43 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -42,6 +42,20 @@
#define SDIO_VENDOR_ID_TI 0x0097
#define SDIO_DEVICE_ID_TI_WL1271 0x4076
+#define SDIO_VENDOR_ID_REALTEK 0x024c
+#define SDIO_DEVICE_ID_REALTEK_BESTBUY_0 0x0240
+#define SDIO_DEVICE_ID_REALTEK_BESTBUY_1 0x0241
+#define SDIO_DEVICE_ID_REALTEK_HP 0x0523
+#define SDIO_DEVICE_ID_REALTEK_ECS 0x0524
+#define SDIO_DEVICE_ID_REALTEK_TCL 0x0525
+#define SDIO_DEVICE_ID_REALTEK_ACER 0x0623
+#define SDIO_DEVICE_ID_REALTEK_RSVD 0x0624
+#define SDIO_DEVICE_ID_REALTEK_ROCKCHIP 0x0625
+#define SDIO_DEVICE_ID_REALTEK_BRASWELL 0x0626
+#define SDIO_DEVICE_ID_REALTEK_ACER_PWR_LIMIT 0x0627
+#define SDIO_DEVICE_ID_REALTEK_COMMON_01 0x8753
+#define SDIO_DEVICE_ID_REALTEK_COMMON_02 0xb723
+
#define SDIO_VENDOR_ID_ATHEROS 0x0271
#define SDIO_DEVICE_ID_ATHEROS_AR6003_00 0x0300
#define SDIO_DEVICE_ID_ATHEROS_AR6003_01 0x0301
--
2.25.1
Macro names were derived from the Windows driver, as that was the best
available source.
Signed-off-by: Brian O'Keefe <[email protected]>
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index b2208e5f190a..8dd3763d1a33 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -10,18 +10,19 @@
#include <rtw_debug.h>
#include <hal_btcoex.h>
#include <linux/jiffies.h>
+#include <linux/mmc/sdio_ids.h>
#ifndef dev_to_sdio_func
#define dev_to_sdio_func(d) container_of(d, struct sdio_func, dev)
#endif
static const struct sdio_device_id sdio_ids[] = {
- { SDIO_DEVICE(0x024c, 0x0523), },
- { SDIO_DEVICE(0x024c, 0x0525), },
- { SDIO_DEVICE(0x024c, 0x0623), },
- { SDIO_DEVICE(0x024c, 0x0626), },
- { SDIO_DEVICE(0x024c, 0x0627), },
- { SDIO_DEVICE(0x024c, 0xb723), },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_REALTEK, SDIO_DEVICE_ID_REALTEK_HP), },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_REALTEK, SDIO_DEVICE_ID_REALTEK_TCL), },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_REALTEK, SDIO_DEVICE_ID_REALTEK_ACER), },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_REALTEK, SDIO_DEVICE_ID_REALTEK_BRASWELL), },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_REALTEK,
SDIO_DEVICE_ID_REALTEK_ACER_PWR_LIMIT), },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_REALTEK,
SDIO_DEVICE_ID_REALTEK_COMMON_02), },
{ /* end: all zeroes */ },
};
MODULE_DEVICE_TABLE(sdio, sdio_ids);
--
2.25.1
Macro names were derived from the Windows driver, as that was the best
available source.
Signed-off-by: Brian O'Keefe <[email protected]>
---
With apologies; something I did mangled spacing in the previous
version of the first patch.
---
include/linux/mmc/sdio_ids.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 12036619346c..97ccb0ac5e43 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -42,6 +42,20 @@
#define SDIO_VENDOR_ID_TI 0x0097
#define SDIO_DEVICE_ID_TI_WL1271 0x4076
+#define SDIO_VENDOR_ID_REALTEK 0x024c
+#define SDIO_DEVICE_ID_REALTEK_BESTBUY_0 0x0240
+#define SDIO_DEVICE_ID_REALTEK_BESTBUY_1 0x0241
+#define SDIO_DEVICE_ID_REALTEK_HP 0x0523
+#define SDIO_DEVICE_ID_REALTEK_ECS 0x0524
+#define SDIO_DEVICE_ID_REALTEK_TCL 0x0525
+#define SDIO_DEVICE_ID_REALTEK_ACER 0x0623
+#define SDIO_DEVICE_ID_REALTEK_RSVD 0x0624
+#define SDIO_DEVICE_ID_REALTEK_ROCKCHIP 0x0625
+#define SDIO_DEVICE_ID_REALTEK_BRASWELL 0x0626
+#define SDIO_DEVICE_ID_REALTEK_ACER_PWR_LIMIT 0x0627
+#define SDIO_DEVICE_ID_REALTEK_COMMON_01 0x8753
+#define SDIO_DEVICE_ID_REALTEK_COMMON_02 0xb723
+
#define SDIO_VENDOR_ID_ATHEROS 0x0271
#define SDIO_DEVICE_ID_ATHEROS_AR6003_00 0x0300
#define SDIO_DEVICE_ID_ATHEROS_AR6003_01 0x0301
--
2.25.1
On Wed, Nov 25, 2020 at 01:33:00PM -0500, Brian O'Keefe wrote:
> Macro names were derived from the Windows driver, as that was the best
> available source.
Why move these? What does this help with?
On November 25, 2020 8:13:07 PM Greg Kroah-Hartman
<[email protected]> wrote:
> On Wed, Nov 25, 2020 at 01:33:00PM -0500, Brian O'Keefe wrote:
>> Macro names were derived from the Windows driver, as that was the best
>> available source.
>
> Why move these? What does this help with?
Hi Greg,
Most if not all SDIO-based (wifi) drivers in mainline have their venid and
devid definitions in that header file. So seems like a good idea to me, but
maybe not so for a staging driver?
Regards,
Arend
On Thu, Nov 26, 2020 at 07:57:23AM +0100, Arend Van Spriel wrote:
> On November 25, 2020 8:13:07 PM Greg Kroah-Hartman
> <[email protected]> wrote:
>
> > On Wed, Nov 25, 2020 at 01:33:00PM -0500, Brian O'Keefe wrote:
> > > Macro names were derived from the Windows driver, as that was the best
> > > available source.
> >
> > Why move these? What does this help with?
>
> Hi Greg,
>
> Most if not all SDIO-based (wifi) drivers in mainline have their venid and
> devid definitions in that header file. So seems like a good idea to me, but
> maybe not so for a staging driver?
If the driver ever gets moved out, maybe do it then as part of that
effort. I haven't seen that happening, so I would recommend just
leaving this alone for now.
thanks,
greg k-h
On Thu, 26 Nov 2020 at 08:27, Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Thu, Nov 26, 2020 at 07:57:23AM +0100, Arend Van Spriel wrote:
> > On November 25, 2020 8:13:07 PM Greg Kroah-Hartman
> > <[email protected]> wrote:
> >
> > > On Wed, Nov 25, 2020 at 01:33:00PM -0500, Brian O'Keefe wrote:
> > > > Macro names were derived from the Windows driver, as that was the best
> > > > available source.
> > >
> > > Why move these? What does this help with?
> >
> > Hi Greg,
> >
> > Most if not all SDIO-based (wifi) drivers in mainline have their venid and
> > devid definitions in that header file. So seems like a good idea to me, but
> > maybe not so for a staging driver?
>
> If the driver ever gets moved out, maybe do it then as part of that
> effort. I haven't seen that happening, so I would recommend just
> leaving this alone for now.
+1
Kind regards
Uffe