Re: [PATCH] can: usb: f81604: fix struct f81604_int_data size mismatch
"Dynetrex, Admin" <[email protected]>
| Newsgroups | org.kernel.vger.linux-kernel,org.kernel.vger.linux-can,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
Hey Greg, This issue was reported by me about a month and a half ago, however, I did not have an environment setup for kernel development in order to submit a patch. I appreciate Peter taking a look at this. Kind Regards, Alex > On Aug 24, 2026, at 2:08 AM, Greg KH <[email protected]> wrote: > > On Mon, Aug 24, 2026 at 04:27:58PM +0800, PS10 PETER HONG 洪繼澤 wrote: >> The struct f81604_int_data defines 9 bytes of interrupt data: >> - Byte 0: Status register (sr) >> - Byte 1: Interrupt register (isrc) >> - Byte 2: Interrupt enable register (ier) >> - Byte 3: Arbitration lost capture (alc) >> - Byte 4: Error code capture (ecc) >> - Byte 5: Error warning limit register (ewlr) >> - Byte 6: RX error counter (rxerr) >> - Byte 7: TX error counter (txerr) >> - Byte 8: Reserved (val) >> >> The hardware sends exactly 9 bytes for the interrupt endpoint. >> However, the struct was defined with __aligned(4) attribute which >> caused the compiler to pad the struct to 12 bytes. >> >> This causes a problem in f81604_read_int_callback() where the short >> URB check compares urb->actual_length against sizeof(*data). When >> sizeof(struct f81604_int_data) is 12 but the hardware only sends 9 >> bytes, the check fails and valid interrupt messages are discarded. >> >> This results in the driver only being able to transmit once because >> the TX complete interrupt is never processed. >> >> Fix this by removing the __aligned(4) attribute so the struct size >> matches the actual hardware data size of 9 bytes. >> >> Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support") >> Fixes: 7299b1b39a25 ("can: usb: f81604: handle short interrupt urb messages properly") >> Cc: [email protected] >> Signed-off-by: Ji-Ze Hong (Peter Hong) <[email protected]> > > Nit, doesn't match the From: line :( > > Also, the first Fixes: tag isn't correct, it's the second one that > matters. > > And wasn't this reported by someone already: > https://lore.kernel.org/r/[email protected] > ? > > And yes, this patch does look correct. > > thanks, > > greg k-h