Am Montag, den 06.03.2017, 12:27 +0100 schrieb Johan Hovold:
> On Mon, Mar 06, 2017 at 10:54:44AM +0100, Oliver Neukum wrote:
> >
> >
> > Yes, it would be wrong to see this as an attribute per driver.
> > It needs to apply when you match. AFAICS every serial subdriver
> > has a device table. Requirements need to go there.
>
> Every USB-serial-bus driver has a device table, but devices are
> matched
> against these tables by USB-serial core and not USB core. And then
Are you refering to
static struct usb_serial_driver * const serial_drivers[] = {
&whiteheat_fake_device, &whiteheat_device, NULL
};
versus
static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(CONNECT_TECH_VENDOR_ID,
CONNECT_TECH_WHITE_HEAT_ID) },
{ USB_DEVICE(CONNECT_TECH_VENDOR_ID,
CONNECT_TECH_FAKE_WHITE_HEAT_ID) },
{ } /* Terminating
entry */
};
I was taking about the latter. As far as I can tell it goes to usbcore.
> there's also a "combined" device table, for all USB-serial bus
> drivers
> implemented by the same USB interface driver.
>
> Are you suggesting the requirements should be specified per device,
> rather than per driver (device table)? That does not seem right to
> me,
> as it is really the driver which needs to verify the resources it
> needs
> for its implementation (e.g. before allocating a read urb). This
> means
> that all devices in a table would have the same (minimum) constraints
> anyway.
No. A driver may be fine with 2 input and 2 output bulk endpoints
or 4 of both kinds but nothing in between.
The core can do that match if you have matching entries for
both device types (and IDs).
> So I do think this should be a driver attribute, but in the USB-
> serial
> case, several classes of devices can be handled by the same USB
> driver,
> so the constraints then needs to be specified at the USB-serial-bus
> driver level instead.
And that driver would save even more logic if the core already told it
for which pattern it matches.
> > Yes, but could you explain how this is connected to filtering at
> > probe
> > time other than happening at probe time?
>
> Only in that this functionality will still be needed in USB-serial to
> implement the port-endpoint remap functionality even if USB core were
> to
> gain something similar.
But why do remap and filtering need to go to the same place?
> > True, but again not specific to serial drivers. DVB-T will face
> > the same issues.
>
> Certainly, and I should have elaborated a bit more on the differences
> here. For USB-serial endpoint-resources are allocated only after
> subdriver probe returns, while for most (all) other USB driver this
> would need to be done in the USB probe callback directly. In that
> case,
> checking before probe might be too soon (fw download, altsetting) and
> checking after would be too late (endpoint resources would already
> need
> to have been setup).
Now that argues for usbserial to trigger the check itself, but not for
the code doing the check living in usbserial. In other words put
struct usb_serial_endpoints and find_endpoints into usbcore and
call it from usbserial. Add a flag to tell usbcore to not check
this by itself and you are done. (With some generic name changes)
That way everybody can use it almost for free.
> I realise that it may look like a duplicated effort, but I really
> don't
> think it is for the reasons given in this thread.
IMHO the reasons are valid but they can be overcome resulting in more
code being shared.
Regards
Oliver
--
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
