[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34860faf-b4c5-45ff-bbed-370a12c88187@gmail.com>
Date: Wed, 18 Sep 2024 23:08:21 +0200
From: Philipp Hortmann <philipp.g.hortmann@...il.com>
To: Dominik Karol Piątkowski
<dominik.karol.piatkowski@...tonmail.com>, gregkh@...uxfoundation.org
Cc: linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/14] staging: vt6655: Tidy up s_uGetDataDuration
function
On 9/18/24 21:20, Dominik Karol Piątkowski wrote:
> This series tidies up s_uGetDataDuration function by renaming its parameters and
> variables from camel case (including Hungarian notation) to snake case, and
> fixing its declaration formatting.
>
> Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@...tonmail.com>
>
> Dominik Karol Piątkowski (14):
> staging: vt6655: s_uGetDataDuration: Rename pDevice parameter
> staging: vt6655: s_uGetDataDuration: Rename byDurType parameter
> staging: vt6655: s_uGetDataDuration: Rename cbFrameLength parameter
> staging: vt6655: s_uGetDataDuration: Rename byPktType parameter
> staging: vt6655: s_uGetDataDuration: Rename wRate parameter
> staging: vt6655: s_uGetDataDuration: Rename bNeedAck parameter
> staging: vt6655: s_uGetDataDuration: Rename uFragIdx parameter
> staging: vt6655: s_uGetDataDuration: Rename cbLastFragmentSize
> parameter
> staging: vt6655: s_uGetDataDuration: Rename uMACfragNum parameter
> staging: vt6655: s_uGetDataDuration: Rename byFBOption parameter
> staging: vt6655: s_uGetDataDuration: Rename bLastFrag variable
> staging: vt6655: s_uGetDataDuration: Rename uAckTime variable
> staging: vt6655: s_uGetDataDuration: Rename uNextPktTime variable
> staging: vt6655: s_uGetDataDuration: Fix declaration formatting
>
> drivers/staging/vt6655/rxtx.c | 110 ++++++++++++++++------------------
> 1 file changed, 53 insertions(+), 57 deletions(-)
>
Hi Dominik,
now you have put quit some afford into this patch series. Thank you.
If we change the camel case variables this way we need thousands of
patches to fix this driver. Therefore we typically change always one
variable for the entire driver and not for one function.
The following is just my personal opinion:
You can keep working on this driver and your patches will remain in the
git. But I think I will propose to delete this driver. Reason is that it
supports maximum 54MBit/s and the connection is always weak. Its form
factor is mini PCI that is really old. I use an adapter from mini PCI to
PCI to get it into my Desktop PC. It furthermore is not buyable anymore.
I like to focus on the hardware that is really well useable and on the
market available:
rtl8192e
150MBit/s -> 12,5MByte/s real steady transfer.
buyable for some bugs as miniPCIe Card.
rtl8723bs
150MBit/s -> >3MByte/s can be reached with the Notebook:
Odys Trendbook Next 14
(Fedora with xfce) (I would prefer the one with 4GB RAM but I have only 2GB)
buyable for not to much money.
We can catch this devices because they run on Windows 10 which will not
be supported after fall 2025
The Driver has 146 Files with 70000 Lines. I think we can remove a lot
because the bluetooth part is not used anymore...
There are more device drivers which need our attention...
Thanks
Bye Philipp
Powered by blists - more mailing lists