[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250722065143.1272366-1-yicongsrfy@163.com>
Date: Tue, 22 Jul 2025 14:51:43 +0800
From: yicongsrfy@....com
To: greg@...ah.com
Cc: andrew+netdev@...n.ch,
davem@...emloft.net,
linux-usb@...r.kernel.org,
netdev@...r.kernel.org,
oneukum@...e.com,
yicong@...inos.cn
Subject: Re: [PATCH] net: cdc_ncm: Fix spelling mistakes
On Tue, 22 Jul 2025 07:46:34 +0200 [thread overview] Greg <greg@...ah.com> wrote:
>
> On Tue, Jul 22, 2025 at 10:32:59AM +0800, yicongsrfy@....com wrote:
> > From: Yi Cong <yicong@...inos.cn>
> >
> > According to the Universal Serial Bus Class Definitions for
> > Communications Devices v1.2, in chapter 6.3.3 table-21:
> > DLBitRate(downlink bit rate) seems like spelling error.
> >
> > Signed-off-by: Yi Cong <yicong@...inos.cn>
> > ---
> > drivers/net/usb/cdc_ncm.c | 2 +-
> > include/uapi/linux/usb/cdc.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> > index 34e82f1e37d9..057ad1cf0820 100644
> > --- a/drivers/net/usb/cdc_ncm.c
> > +++ b/drivers/net/usb/cdc_ncm.c
> > @@ -1847,7 +1847,7 @@ cdc_ncm_speed_change(struct usbnet *dev,
> > struct usb_cdc_speed_change *data)
> > {
> > /* RTL8156 shipped before 2021 sends notification about every 32ms. */
> > - dev->rx_speed = le32_to_cpu(data->DLBitRRate);
> > + dev->rx_speed = le32_to_cpu(data->DLBitRate);
> > dev->tx_speed = le32_to_cpu(data->ULBitRate);
> > }
> >
> > diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
> > index 1924cf665448..f528c8e0a04e 100644
> > --- a/include/uapi/linux/usb/cdc.h
> > +++ b/include/uapi/linux/usb/cdc.h
> > @@ -316,7 +316,7 @@ struct usb_cdc_notification {
> > #define USB_CDC_SERIAL_STATE_OVERRUN (1 << 6)
> >
> > struct usb_cdc_speed_change {
> > - __le32 DLBitRRate; /* contains the downlink bit rate (IN pipe) */
> > + __le32 DLBitRate; /* contains the downlink bit rate (IN pipe) */
> > __le32 ULBitRate; /* contains the uplink bit rate (OUT pipe) */
> > } __attribute__ ((packed));
>
> You are changing a structure that userspace sees. How did you verify
> that this is not going to break any existing code out there?
Your question is very valid. I can only guarantee that the devices
in my possession do not involve references to the relevant structures,
but I'm not sure the behavior of other vendors' implementations,
which may vary.
So, perhaps it would be better to keep things as they are?
Powered by blists - more mailing lists