Hi Mario,
> > What the action you want to take at removal? You can set
> > ENV{REMOVE_CMD}= and it will be passed to RUN+= for that exact device
> > when it goes away.
> >
> > You can also just store any other custom property in the udev
> > database, and it will be there on remove.
> >
> Thanks for the recommendation on ENV{REMOVE_CMD}. With some minor
> modifications to my old patch, I've got it working using ENV{REMOVE_CMD}
> now reliably post suspend.
>
> Although rewalking the child devices to find the right one to prod might
> seem tedious, it should be more future-proof in case later hardware ends
> up changing.
>
> Would you mind reviewing the attached patch for submission to udev then?
+ for (bus = usb_get_busses(); bus; bus = bus->next)
+ for (dev = bus->devices; dev; dev = dev->next)
+ if (dev->descriptor.idVendor == base_vendor &&
+ dev->descriptor.idProduct == base_product)
+ for (i = 0; i < dev->num_children; i++)
+ for (j = 0; j < dev->children[i]->descriptor.bNumConfigurations; j++)
+ for (k = 0; k < dev->children[i]->config[j].bNumInterfaces; k++)
+ for (l = 0; l < dev->children[i]->config[j].interface[k].num_altsetting; l++)
+ if (dev->children[i]->config[j].interface[k].altsetting[l].bInterfaceProtocol == bInterfaceProtocol)
+ return dev->children[i];
+ return NULL;
+}
welcome to the land of fully unreadable code. You need to fix this and
split it up if needed. Nobody has ever a chance to understand what this
code does if it goes wrong.
Regards
Marcel
--
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
