Hi Paul, > If RXFLVL is a host+device mode interrupt, doesn't it make sense to > enable it in both enable_host_interrupts and (the future) > enable_device_interrupts instead of in enable_common_interrupts? Hmm, I just realized the underlying thing here is that I'm distinguishing "common" interrupts from "host+device" interrupts, while I think you might be lumping them together? In my interpretation, common interrupts are those that are really separate from either host or device mode (connection status, otg protocols, suspend/wakeup, etc.), while device+mode interrupts are interrupts that both the gadget and hcd driver parts use during their operation. I'm not entirely sure if this distinction is meaningful, though. In any case, I do think that having a correspondence between enable_host_interrupts and disable_host_interrupts is useful, so we should either: - Make the distinction, add the host+device interrupts to GINTMSK_HOST, remoenable them in enable_host_interrupts (except the ones that are enabled on-demand, so effectively the only host+device interrupt to enable here is RXFLVL) and disable them in disable_host_interrupts. - Do not make the distinction, add the host+device interrupts to GINTMSK_COMMON and not GINTMSK_HOST, enable them in enable_common_interrupts (again, except the ones that are enabled on-demand) disable them in disable_common_interrupts. I suspect they'll also need to be disabled in disable_host_interrupts (since this happens now already), so they'll be explicitely listed in addition to GINTMSK_HOST there. For now, I'll assume option 1 is the most sensible and I'll adapt my patches for that. Gr. Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
