The structs phy_rx_agc_info and phy_status_rpt define parts of the
header data that the r8188eu chipset sends to this driver via usb.
Add a comment to clarify that we cannot modify the content of these
structures and remove seemingly unused fields.
Signed-off-by: Martin Kaiser <[email protected]>
---
Dear all,
I experimented with "cleaning up" these structures and related code before
discovering that their content comes from usb packets we receive from the
r8188eu chipset.
Would it make sense to add a word of warning to prevent others from
repeating this exercise?
Thanks,
Martin
drivers/staging/r8188eu/include/odm_HWConfig.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/staging/r8188eu/include/odm_HWConfig.h b/drivers/staging/r8188eu/include/odm_HWConfig.h
index b37962edb2ed..35a562372a1a 100644
--- a/drivers/staging/r8188eu/include/odm_HWConfig.h
+++ b/drivers/staging/r8188eu/include/odm_HWConfig.h
@@ -14,6 +14,13 @@
/* structure and define */
+/*
+ * Attention: struct phy_status_rpt and struct phy_rx_agc_info describe
+ * data structures that this driver receives from the r8188eu chip via usb.
+ * Do not change the content of these structures, do not remove seemingly
+ * unused entries.
+ */
+
struct phy_rx_agc_info {
#ifdef __LITTLE_ENDIAN
u8 gain:7, trsw:1;
--
2.30.2
On Fri, Feb 18, 2022 at 10:22:53AM +0100, Martin Kaiser wrote:
> The structs phy_rx_agc_info and phy_status_rpt define parts of the
> header data that the r8188eu chipset sends to this driver via usb.
>
> Add a comment to clarify that we cannot modify the content of these
> structures and remove seemingly unused fields.
>
> Signed-off-by: Martin Kaiser <[email protected]>
> ---
>
> Dear all,
>
> I experimented with "cleaning up" these structures and related code before
> discovering that their content comes from usb packets we receive from the
> r8188eu chipset.
>
> Would it make sense to add a word of warning to prevent others from
> repeating this exercise?
Just the fact that these structs are endian means they're from the
firmware or the network.
If a struct has a pointer in it, then it's rarely part of the UAPI but
if it has endian data then it probably is.
regards,
dan carpenter
Thus wrote Dan Carpenter ([email protected]):
> On Fri, Feb 18, 2022 at 10:22:53AM +0100, Martin Kaiser wrote:
> > Would it make sense to add a word of warning to prevent others from
> > repeating this exercise?
> Just the fact that these structs are endian means they're from the
> firmware or the network.
> If a struct has a pointer in it, then it's rarely part of the UAPI but
> if it has endian data then it probably is.
ah, these are useful criteria, thanks. I see that the comment isn't
really necessary...
On 2/18/22 04:22, Dan Carpenter wrote:
> On Fri, Feb 18, 2022 at 10:22:53AM +0100, Martin Kaiser wrote:
>> The structs phy_rx_agc_info and phy_status_rpt define parts of the
>> header data that the r8188eu chipset sends to this driver via usb.
>>
>> Add a comment to clarify that we cannot modify the content of these
>> structures and remove seemingly unused fields.
>>
>> Signed-off-by: Martin Kaiser <[email protected]>
>> ---
>>
>> Dear all,
>>
>> I experimented with "cleaning up" these structures and related code before
>> discovering that their content comes from usb packets we receive from the
>> r8188eu chipset.
>>
>> Would it make sense to add a word of warning to prevent others from
>> repeating this exercise?
>
> Just the fact that these structs are endian means they're from the
> firmware or the network.
>
> If a struct has a pointer in it, then it's rarely part of the UAPI but
> if it has endian data then it probably is.
Additionally, do not change any struct with the __packed attribute. Most will
have endian variables as well, but not all will.
Testing after modifying any struct is a necessity.
Larry