staging: rtl8723bs: questions on TODO list

staging: rtl8723bs: questions on TODO list

[Fabio Aiuto]

Hello all,

I'd like to have some clarifications about rtl8723bs driver.
In order to make this driver ready for moving out of staging
I would like to know:

- find and remove remaining code valid only for 5 GHz. Most of the obvious
  ones have been removed, but things like channel > 14 still exist.

is it possible to remove all 5g code, even the one related to power
regulation when on band 5g? As far as I know about this card is that
it doesn't support 5g, so may I just delete all 5g code or there are some
constraints I'd take care of?

- find and remove any code for other chips that is left over

Ok this seems clear, are there some suggestion to do it safely?

- convert any remaining unusual variable types

Ok (but feel free to suggest anything)

- find codes that can use %pM and %Nph formatting

Ok (but feel free to suggest anything)

- checkpatch.pl fixes - most of the remaining ones are lines too long. Many
  of them will require refactoring

Ok

- merge Realtek's bugfixes and new features into the driver

Please, can you explain what one could do that?

- switch to use LIB80211
- switch to use MAC80211

I think I need a few details for these last points as well.

Do you think that one will need real hardware to complete
these tasks? I don't have rtl8723bs card at the moment, so
I think I will focus on those TODO activities which
don't need it.

thank you in advance,

fabio

Re: staging: rtl8723bs: questions on TODO list

[Greg KH]

On Fri, May 14, 2021 at 10:38:57AM +0200, Fabio Aiuto wrote:
> Hello all,
> 
> I'd like to have some clarifications about rtl8723bs driver.
> In order to make this driver ready for moving out of staging
> I would like to know:
> 
> - find and remove remaining code valid only for 5 GHz. Most of the obvious
>   ones have been removed, but things like channel > 14 still exist.
> 
> is it possible to remove all 5g code, even the one related to power
> regulation when on band 5g? As far as I know about this card is that
> it doesn't support 5g, so may I just delete all 5g code or there are some
> constraints I'd take care of?
> 
> - find and remove any code for other chips that is left over
> 
> Ok this seems clear, are there some suggestion to do it safely?
> 
> - convert any remaining unusual variable types
> 
> Ok (but feel free to suggest anything)
> 
> - find codes that can use %pM and %Nph formatting
> 
> Ok (but feel free to suggest anything)
> 
> - checkpatch.pl fixes - most of the remaining ones are lines too long. Many
>   of them will require refactoring
> 
> Ok
> 
> - merge Realtek's bugfixes and new features into the driver
> 
> Please, can you explain what one could do that?
> 
> - switch to use LIB80211
> - switch to use MAC80211
> 
> I think I need a few details for these last points as well.
> 
> Do you think that one will need real hardware to complete
> these tasks? I don't have rtl8723bs card at the moment, so
> I think I will focus on those TODO activities which
> don't need it.

I recommend getting one of these devices to do the more complex tasks as
described above.  Otherwise it's going to be hard to verify that your
changes are valid.

thanks,

greg k-h

Re: staging: rtl8723bs: questions on TODO list

[Fabio Aiuto]

On Fri, May 14, 2021 at 10:45:14AM +0200, Greg KH wrote:
> On Fri, May 14, 2021 at 10:38:57AM +0200, Fabio Aiuto wrote:
> > Hello all,
> > 
> > I'd like to have some clarifications about rtl8723bs driver.
> > In order to make this driver ready for moving out of staging
> > I would like to know:
> > 
> > - find and remove remaining code valid only for 5 GHz. Most of the obvious
> >   ones have been removed, but things like channel > 14 still exist.
> > 
> > is it possible to remove all 5g code, even the one related to power
> > regulation when on band 5g? As far as I know about this card is that
> > it doesn't support 5g, so may I just delete all 5g code or there are some
> > constraints I'd take care of?
> > 
> > - find and remove any code for other chips that is left over
> > 
> > Ok this seems clear, are there some suggestion to do it safely?
> > 
> > - convert any remaining unusual variable types
> > 
> > Ok (but feel free to suggest anything)
> > 
> > - find codes that can use %pM and %Nph formatting
> > 
> > Ok (but feel free to suggest anything)
> > 
> > - checkpatch.pl fixes - most of the remaining ones are lines too long. Many
> >   of them will require refactoring
> > 
> > Ok
> > 
> > - merge Realtek's bugfixes and new features into the driver
> > 
> > Please, can you explain what one could do that?
> > 
> > - switch to use LIB80211
> > - switch to use MAC80211
> > 
> > I think I need a few details for these last points as well.
> > 
> > Do you think that one will need real hardware to complete
> > these tasks? I don't have rtl8723bs card at the moment, so
> > I think I will focus on those TODO activities which
> > don't need it.
> 
> I recommend getting one of these devices to do the more complex tasks as
> described above.  Otherwise it's going to be hard to verify that your
> changes are valid.
> 
> thanks,
> 
> greg k-h

got it,

thank you,

fabio

Re: staging: rtl8723bs: questions on TODO list

[Hans de Goede]

Hi Fabio,

On 5/14/21 10:38 AM, Fabio Aiuto wrote:
> Hello all,
> 
> I'd like to have some clarifications about rtl8723bs driver.
> In order to make this driver ready for moving out of staging
> I would like to know:
> 
> - find and remove remaining code valid only for 5 GHz. Most of the obvious
>   ones have been removed, but things like channel > 14 still exist.
> 
> is it possible to remove all 5g code, even the one related to power
> regulation when on band 5g? As far as I know about this card is that
> it doesn't support 5g, so may I just delete all 5g code or there are some
> constraints I'd take care of?

These cards are 2.4G only so any code of which you are sure it is for
5G only can be removed.

> - find and remove any code for other chips that is left over
> 
> Ok this seems clear, are there some suggestion to do it safely?

Get some hardware and test that things still work, preferably
against multiple access-points.

> - convert any remaining unusual variable types
> 
> Ok (but feel free to suggest anything)
> 
> - find codes that can use %pM and %Nph formatting
> 
> Ok (but feel free to suggest anything)
> 
> - checkpatch.pl fixes - most of the remaining ones are lines too long. Many
>   of them will require refactoring
> 
> Ok
> 
> - merge Realtek's bugfixes and new features into the driver
> 
> Please, can you explain what one could do that?

I know that "youling 257 <youling257@gmail.com>" is using a different
version of the original (out-of-tree, non cleaned-up) Realtek driver
code for the Android-X86 kernels he works on. You should probably
ask youling why that version is being used and try to get a copy of
the original Realtek sources on which the staging driver is based
and do a "diff -ur" between them and see what is different.

> - switch to use LIB80211
> - switch to use MAC80211
> 
> I think I need a few details for these last points as well.

I'm afraid I cannot help there, you should ask for help with this
on the linux wireless email list.

> Do you think that one will need real hardware to complete
> these tasks? I don't have rtl8723bs card at the moment, so
> I think I will focus on those TODO activities which
> don't need it.

Yes you really do need hardware, even simple coding style
cleanups are known to (accidentally) break driver functionality,
so you really should ensure that you are capable of testing your
changes on real hardware.

Regards,

Hans

Re: staging: rtl8723bs: questions on TODO list

[Fabio Aiuto]

On Fri, May 14, 2021 at 11:15:42AM +0200, Hans de Goede wrote:
> Hi Fabio,
> 
> On 5/14/21 10:38 AM, Fabio Aiuto wrote:
> > Hello all,
> > 
> > I'd like to have some clarifications about rtl8723bs driver.
> > In order to make this driver ready for moving out of staging
> > I would like to know:
> > 
> > - find and remove remaining code valid only for 5 GHz. Most of the obvious
> >   ones have been removed, but things like channel > 14 still exist.
> > 
> > is it possible to remove all 5g code, even the one related to power
> > regulation when on band 5g? As far as I know about this card is that
> > it doesn't support 5g, so may I just delete all 5g code or there are some
> > constraints I'd take care of?
> 
> These cards are 2.4G only so any code of which you are sure it is for
> 5G only can be removed.
> 
> > - find and remove any code for other chips that is left over
> > 
> > Ok this seems clear, are there some suggestion to do it safely?
> 
> Get some hardware and test that things still work, preferably
> against multiple access-points.
> 
> > - convert any remaining unusual variable types
> > 
> > Ok (but feel free to suggest anything)
> > 
> > - find codes that can use %pM and %Nph formatting
> > 
> > Ok (but feel free to suggest anything)
> > 
> > - checkpatch.pl fixes - most of the remaining ones are lines too long. Many
> >   of them will require refactoring
> > 
> > Ok
> > 
> > - merge Realtek's bugfixes and new features into the driver
> > 
> > Please, can you explain what one could do that?
> 
> I know that "youling 257 <youling257@gmail.com>" is using a different
> version of the original (out-of-tree, non cleaned-up) Realtek driver
> code for the Android-X86 kernels he works on. You should probably
> ask youling why that version is being used and try to get a copy of
> the original Realtek sources on which the staging driver is based
> and do a "diff -ur" between them and see what is different.
> 
> > - switch to use LIB80211
> > - switch to use MAC80211
> > 
> > I think I need a few details for these last points as well.
> 
> I'm afraid I cannot help there, you should ask for help with this
> on the linux wireless email list.
> 
> > Do you think that one will need real hardware to complete
> > these tasks? I don't have rtl8723bs card at the moment, so
> > I think I will focus on those TODO activities which
> > don't need it.
> 
> Yes you really do need hardware, even simple coding style
> cleanups are known to (accidentally) break driver functionality,
> so you really should ensure that you are capable of testing your
> changes on real hardware.
> 
> Regards,
> 
> Hans
> 
> 

thank you for your answer Hans,

fabio