lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 Sep 2020 11:15:02 +0900 From: Vincent Mailhol <mailhol.vincent@...adoo.fr> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Cc: Vincent Mailhol <mailhol.vincent@...adoo.fr>, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, linux-can@...r.kernel.org, Wolfgang Grandegger <wg@...ndegger.com>, Marc Kleine-Budde <mkl@...gutronix.de>, "David S . Miller" <davem@...emloft.net>, Oliver Neukum <oneukum@...e.com>, linux-usb@...r.kernel.org, Arunachalam Santhanam <arunachalam.santhanam@...bosch.com> Subject: Re: [PATCH 6/6] USB: cdc-acm: blacklist ETAS ES58X device > > Did you mean to send this twice? Sorry for that, I screwed things up a first time when sending the patches: only included the CAN mailing list (linux-can@...r.kernel.org) but ommitted linux-kernel@...r.kernel.org in the cover letter. As a result, it broke the chain reply on lkml.org so I preferred to resend it. > > And where are the 5 other patches in this series? I used the --cc-cmd="scripts/get_maintainer.pl -i" option in git send-email to send the series. The five other patches are not related to USB core but to CAN core, so you were not included in CC by the script. Now, I understand this is confusing, I will take care to CC you on the full series when sending V2. One more time, sorry for that. For your information, the full patch series is available here: https://lkml.org/lkml/2020/9/26/319 > > And finally, it's a good idea to include the output of 'lsusb -v' for > > devices that need quirks so we can figure things out later on, can you > > fix up your changelog to include that information? Noted, will be included in v2 of the patch series. > Also, why is the device saying it is a cdc-acm compliant device when it > is not? Why lie to the operating system like that? This is a leftover debug feature used during development. Future firmware version will have it remove but users with older revision will still face this issue which can be confusing. I will also amend the changelog to better reflect above reason.
Powered by blists - more mailing lists