Thread (33 messages) 33 messages, 6 authors, 2025-06-25

Re: [PATCH v12 1/7] mfd: Add core driver for Nuvoton NCT6694

From: Ming Yu <hidden>
Date: 2025-06-05 07:50:07
Also in: linux-can, linux-gpio, linux-hwmon, linux-i2c, linux-rtc, linux-usb, linux-watchdog, lkml

Dear Guenter,

Thank you for reviewing,

Guenter Roeck [off-list ref] 於 2025年6月4日 週三 下午8:40寫道:
quoted
quoted
+static void usb_int_callback(struct urb *urb)
+{
+    struct nct6694 *nct6694 = urb->context;
+    unsigned int *int_status = urb->transfer_buffer;
+    int ret;
+
+    switch (urb->status) {
+    case 0:
+        break;
+    case -ECONNRESET:
+    case -ENOENT:
+    case -ESHUTDOWN:
+        return;
+    default:
+        goto resubmit;
+    }
+
+    while (*int_status) {
+        int irq = __ffs(*int_status);
+
+        generic_handle_irq_safe(irq_find_mapping(nct6694->domain, irq));
+        *int_status &= ~BIT(irq);
+    }
Does modifying the byte have any benefit?
Not sure if I understand the question, and assuming your question is regarding
*int_status: *int_status!=0 is the loop invariant, so, yes, modifying it does
have a benefit.

I'd be more concerned that transfer_buffer is the raw buffer, and that data
read from it is not endianness converted. That makes me wonder if and how the
code would work on a big endian system.
I will update the code in the next patch to use __le32 for the
variable to ensure proper endianness handling across architectures.


Best regards,
Ming
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help