Define the necessary bits in the CHANNEL, PAPEDELAY and GPIOCTL0
registers to can use them in the calls to vnt_mac_reg_bits_on and
vnt_mac_reg_bits_off functions. In this way, avoid the use of BIT()
macros and clarify the code.
Fixes: 3017e587e368 ("staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_* functions")
Suggested-by: Dan Carpenter <[email protected]>
Signed-off-by: Oscar Carter <[email protected]>
---
drivers/staging/vt6656/baseband.c | 6 ++++--
drivers/staging/vt6656/card.c | 3 +--
drivers/staging/vt6656/mac.h | 12 ++++++++++++
drivers/staging/vt6656/main_usb.c | 2 +-
4 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c
index a19a563d8bcc..dd3c3bf5e8b5 100644
--- a/drivers/staging/vt6656/baseband.c
+++ b/drivers/staging/vt6656/baseband.c
@@ -442,7 +442,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
if (ret)
goto end;
- ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
+ ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
+ PAPEDELAY_B0);
if (ret)
goto end;
} else if (priv->rf_type == RF_VT3226D0) {
@@ -451,7 +452,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
if (ret)
goto end;
- ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
+ ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
+ PAPEDELAY_B0);
if (ret)
goto end;
}
diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
index dc3ab10eb630..b88de0042b9d 100644
--- a/drivers/staging/vt6656/card.c
+++ b/drivers/staging/vt6656/card.c
@@ -64,8 +64,7 @@ void vnt_set_channel(struct vnt_private *priv, u32 connection_channel)
vnt_mac_reg_bits_on(priv, MAC_REG_MACCR, MACCR_CLRNAV);
/* Set Channel[7] = 0 to tell H/W channel is changing now. */
- vnt_mac_reg_bits_off(priv, MAC_REG_CHANNEL,
- (BIT(7) | BIT(5) | BIT(4)));
+ vnt_mac_reg_bits_off(priv, MAC_REG_CHANNEL, CHANNEL_B7_B5_B4);
vnt_control_out(priv, MESSAGE_TYPE_SELECT_CHANNEL,
connection_channel, 0, 0, NULL);
diff --git a/drivers/staging/vt6656/mac.h b/drivers/staging/vt6656/mac.h
index c532b27de37f..f61b6595defb 100644
--- a/drivers/staging/vt6656/mac.h
+++ b/drivers/staging/vt6656/mac.h
@@ -295,11 +295,20 @@
#define BBREGCTL_REGR BIT(1)
#define BBREGCTL_REGW BIT(0)
+/* Bits in the CHANNEL register */
+#define CHANNEL_B7 BIT(7)
+#define CHANNEL_B5 BIT(5)
+#define CHANNEL_B4 BIT(4)
+#define CHANNEL_B7_B5_B4 (CHANNEL_B7 | CHANNEL_B5 | CHANNEL_B4)
+
/* Bits in the IFREGCTL register */
#define IFREGCTL_DONE BIT(2)
#define IFREGCTL_IFRF BIT(1)
#define IFREGCTL_REGW BIT(0)
+/* Bits in the PAPEDELAY register */
+#define PAPEDELAY_B0 BIT(0)
+
/* Bits in the SOFTPWRCTL register */
#define SOFTPWRCTL_RFLEOPT BIT(3)
#define SOFTPWRCTL_TXPEINV BIT(1)
@@ -311,6 +320,9 @@
#define SOFTPWRCTL_SWPE1 BIT(1)
#define SOFTPWRCTL_SWPE3 BIT(0)
+/* Bits in the GPIOCTL0 register */
+#define GPIOCTL0_B0 BIT(0)
+
/* Bits in the GPIOCTL1 register */
#define GPIO3_MD BIT(5)
#define GPIO3_DATA BIT(6)
diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index 8e7269c87ea9..aa9c1fccc134 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -366,7 +366,7 @@ static int vnt_init_registers(struct vnt_private *priv)
if (ret)
goto end;
- ret = vnt_mac_reg_bits_on(priv, MAC_REG_GPIOCTL0, BIT(0));
+ ret = vnt_mac_reg_bits_on(priv, MAC_REG_GPIOCTL0, GPIOCTL0_B0);
if (ret)
goto end;
--
2.20.1
On Sat, Mar 28, 2020 at 10:54:33AM +0100, Oscar Carter wrote:
> Define the necessary bits in the CHANNEL, PAPEDELAY and GPIOCTL0
> registers to can use them in the calls to vnt_mac_reg_bits_on and
> vnt_mac_reg_bits_off functions. In this way, avoid the use of BIT()
> macros and clarify the code.
>
> Fixes: 3017e587e368 ("staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_* functions")
> Suggested-by: Dan Carpenter <[email protected]>
> Signed-off-by: Oscar Carter <[email protected]>
> ---
> drivers/staging/vt6656/baseband.c | 6 ++++--
> drivers/staging/vt6656/card.c | 3 +--
> drivers/staging/vt6656/mac.h | 12 ++++++++++++
> drivers/staging/vt6656/main_usb.c | 2 +-
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c
> index a19a563d8bcc..dd3c3bf5e8b5 100644
> --- a/drivers/staging/vt6656/baseband.c
> +++ b/drivers/staging/vt6656/baseband.c
> @@ -442,7 +442,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
> if (ret)
> goto end;
>
> - ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
> + ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
> + PAPEDELAY_B0);
This doesn't clarify anything. It makes it less clear because someone
would assume B0 means something but it's just hiding a magic number
behind a meaningless define. B0 means BIT(0) which means nothing. So
now we have to jump through two hoops to find out that we don't know
anything.
Just leave it as-is. Same for the rest.
There problem is a hardware spec which explains what this stuff is.
regards,
dan carpenter
On Tue, Mar 31, 2020 at 01:29:06PM +0300, Dan Carpenter wrote:
> On Sat, Mar 28, 2020 at 10:54:33AM +0100, Oscar Carter wrote:
> > Define the necessary bits in the CHANNEL, PAPEDELAY and GPIOCTL0
> > registers to can use them in the calls to vnt_mac_reg_bits_on and
> > vnt_mac_reg_bits_off functions. In this way, avoid the use of BIT()
> > macros and clarify the code.
> >
> > Fixes: 3017e587e368 ("staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_* functions")
> > Suggested-by: Dan Carpenter <[email protected]>
> > Signed-off-by: Oscar Carter <[email protected]>
> > ---
> > drivers/staging/vt6656/baseband.c | 6 ++++--
> > drivers/staging/vt6656/card.c | 3 +--
> > drivers/staging/vt6656/mac.h | 12 ++++++++++++
> > drivers/staging/vt6656/main_usb.c | 2 +-
> > 4 files changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c
> > index a19a563d8bcc..dd3c3bf5e8b5 100644
> > --- a/drivers/staging/vt6656/baseband.c
> > +++ b/drivers/staging/vt6656/baseband.c
> > @@ -442,7 +442,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
> > if (ret)
> > goto end;
> >
> > - ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
> > + ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
> > + PAPEDELAY_B0);
>
> This doesn't clarify anything. It makes it less clear because someone
> would assume B0 means something but it's just hiding a magic number
> behind a meaningless define. B0 means BIT(0) which means nothing. So
> now we have to jump through two hoops to find out that we don't know
> anything.
>
I created this names due to the lack of information about the hardware. I
searched but I did not find anything.
> Just leave it as-is. Same for the rest.
Ok.
>
> There problem is a hardware spec which explains what this stuff is.
>
It's possible to find a datasheet of this hardware to make this modification
accordingly to the correct bit names of registers ?
> regards,
> dan carpenter
>
Thanks,
oscar carter
On 04/01/20 18:55:38, Oscar Carter wrote:
> On Tue, Mar 31, 2020 at 01:29:06PM +0300, Dan Carpenter wrote:
> > On Sat, Mar 28, 2020 at 10:54:33AM +0100, Oscar Carter wrote:
> > > Define the necessary bits in the CHANNEL, PAPEDELAY and GPIOCTL0
> > > registers to can use them in the calls to vnt_mac_reg_bits_on and
> > > vnt_mac_reg_bits_off functions. In this way, avoid the use of BIT()
> > > macros and clarify the code.
> > >
> > > Fixes: 3017e587e368 ("staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_* functions")
> > > Suggested-by: Dan Carpenter <[email protected]>
> > > Signed-off-by: Oscar Carter <[email protected]>
> > > ---
> > > drivers/staging/vt6656/baseband.c | 6 ++++--
> > > drivers/staging/vt6656/card.c | 3 +--
> > > drivers/staging/vt6656/mac.h | 12 ++++++++++++
> > > drivers/staging/vt6656/main_usb.c | 2 +-
> > > 4 files changed, 18 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c
> > > index a19a563d8bcc..dd3c3bf5e8b5 100644
> > > --- a/drivers/staging/vt6656/baseband.c
> > > +++ b/drivers/staging/vt6656/baseband.c
> > > @@ -442,7 +442,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
> > > if (ret)
> > > goto end;
> > >
> > > - ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
> > > + ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
> > > + PAPEDELAY_B0);
> >
> > This doesn't clarify anything. It makes it less clear because someone
> > would assume B0 means something but it's just hiding a magic number
> > behind a meaningless define. B0 means BIT(0) which means nothing. So
> > now we have to jump through two hoops to find out that we don't know
> > anything.
> >
> I created this names due to the lack of information about the hardware. I
> searched but I did not find anything.
>
> > Just leave it as-is. Same for the rest.
> Ok.
>
> >
> > There problem is a hardware spec which explains what this stuff is.
> >
> It's possible to find a datasheet of this hardware to make this modification
> accordingly to the correct bit names of registers ?
I haven't found any so far, if your researches are luckier than mine, I
would be interested too. Even getting your hands on the actual device is
complicated.
Thanks,
Quentin
On 02/04/2020 10:19, Quentin Deslandes wrote:
> On 04/01/20 18:55:38, Oscar Carter wrote:
>> On Tue, Mar 31, 2020 at 01:29:06PM +0300, Dan Carpenter wrote:
>>> On Sat, Mar 28, 2020 at 10:54:33AM +0100, Oscar Carter wrote:
>>>> Define the necessary bits in the CHANNEL, PAPEDELAY and GPIOCTL0
>>>> registers to can use them in the calls to vnt_mac_reg_bits_on and
>>>> vnt_mac_reg_bits_off functions. In this way, avoid the use of BIT()
>>>> macros and clarify the code.
>>>>
>>>> Fixes: 3017e587e368 ("staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_* functions")
>>>> Suggested-by: Dan Carpenter <[email protected]>
>>>> Signed-off-by: Oscar Carter <[email protected]>
>>>> ---
>>>> drivers/staging/vt6656/baseband.c | 6 ++++--
>>>> drivers/staging/vt6656/card.c | 3 +--
>>>> drivers/staging/vt6656/mac.h | 12 ++++++++++++
>>>> drivers/staging/vt6656/main_usb.c | 2 +-
>>>> 4 files changed, 18 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c
>>>> index a19a563d8bcc..dd3c3bf5e8b5 100644
>>>> --- a/drivers/staging/vt6656/baseband.c
>>>> +++ b/drivers/staging/vt6656/baseband.c
>>>> @@ -442,7 +442,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
>>>> if (ret)
>>>> goto end;
>>>>
>>>> - ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
>>>> + ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
>>>> + PAPEDELAY_B0);
>>>
>>> This doesn't clarify anything. It makes it less clear because someone
>>> would assume B0 means something but it's just hiding a magic number
>>> behind a meaningless define. B0 means BIT(0) which means nothing. So
>>> now we have to jump through two hoops to find out that we don't know
>>> anything.
>>>
>> I created this names due to the lack of information about the hardware. I
>> searched but I did not find anything.
>>
>>> Just leave it as-is. Same for the rest.
>> Ok.
>>
>>>
>>> There problem is a hardware spec which explains what this stuff is.
>>>
>> It's possible to find a datasheet of this hardware to make this modification
>> accordingly to the correct bit names of registers ?
>
> I haven't found any so far, if your researches are luckier than mine, I
> would be interested too. Even getting your hands on the actual device is
> complicated.
All I can tell you is it related to command above it MAC_REG_ITRTMSET
without it the device will not associate with access point is probably
TX timing/power rated.
Other bits in MAC_REG_PAPEDELAY are related to LED function and defined
in LEDSTS_* in mac.h.
I think it is some kind of enable so something like ITRTMSET_ENABLE
would do.
Regards
Malcolm
On Thu, Apr 02, 2020 at 11:58:07AM +0100, Malcolm Priestley wrote:
>
>
> On 02/04/2020 10:19, Quentin Deslandes wrote:
> > On 04/01/20 18:55:38, Oscar Carter wrote:
> > > On Tue, Mar 31, 2020 at 01:29:06PM +0300, Dan Carpenter wrote:
> > > > On Sat, Mar 28, 2020 at 10:54:33AM +0100, Oscar Carter wrote:
> > > > > Define the necessary bits in the CHANNEL, PAPEDELAY and GPIOCTL0
> > > > > registers to can use them in the calls to vnt_mac_reg_bits_on and
> > > > > vnt_mac_reg_bits_off functions. In this way, avoid the use of BIT()
> > > > > macros and clarify the code.
> > > > >
> > > > > Fixes: 3017e587e368 ("staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_* functions")
> > > > > Suggested-by: Dan Carpenter <[email protected]>
> > > > > Signed-off-by: Oscar Carter <[email protected]>
> > > > > ---
> > > > > drivers/staging/vt6656/baseband.c | 6 ++++--
> > > > > drivers/staging/vt6656/card.c | 3 +--
> > > > > drivers/staging/vt6656/mac.h | 12 ++++++++++++
> > > > > drivers/staging/vt6656/main_usb.c | 2 +-
> > > > > 4 files changed, 18 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c
> > > > > index a19a563d8bcc..dd3c3bf5e8b5 100644
> > > > > --- a/drivers/staging/vt6656/baseband.c
> > > > > +++ b/drivers/staging/vt6656/baseband.c
> > > > > @@ -442,7 +442,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
> > > > > if (ret)
> > > > > goto end;
> > > > >
> > > > > - ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
> > > > > + ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
> > > > > + PAPEDELAY_B0);
> > > >
> > > > This doesn't clarify anything. It makes it less clear because someone
> > > > would assume B0 means something but it's just hiding a magic number
> > > > behind a meaningless define. B0 means BIT(0) which means nothing. So
> > > > now we have to jump through two hoops to find out that we don't know
> > > > anything.
> > > >
> > > I created this names due to the lack of information about the hardware. I
> > > searched but I did not find anything.
> > >
> > > > Just leave it as-is. Same for the rest.
> > > Ok.
> > >
> > > >
> > > > There problem is a hardware spec which explains what this stuff is.
> > > >
> > > It's possible to find a datasheet of this hardware to make this modification
> > > accordingly to the correct bit names of registers ?
> >
> > I haven't found any so far, if your researches are luckier than mine, I
> > would be interested too. Even getting your hands on the actual device is
> > complicated.
>
> All I can tell you is it related to command above it MAC_REG_ITRTMSET
> without it the device will not associate with access point is probably TX
> timing/power rated.
>
> Other bits in MAC_REG_PAPEDELAY are related to LED function and defined in
> LEDSTS_* in mac.h.
>
> I think it is some kind of enable so something like ITRTMSET_ENABLE would
> do.
>
I think the best for now is leave it as-is due to the lack of information about
bit names of registers.
> Regards
>
> Malcolm
Thanks,
Oscar carter