linux-kernel - Re: [PATCH v3] USB: serial: usb_wwan: replace DTR/RTS magic numbers with macros

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Yt1bY74PirDyuYcu@hovoldconsulting.com>
Date:   Sun, 24 Jul 2022 16:46:59 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Yan Xinyu <sdlyyxy@...t.edu.cn>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] USB: serial: usb_wwan: replace DTR/RTS magic numbers
 with macros

On Sun, Jul 24, 2022 at 04:15:55PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Jul 24, 2022 at 04:07:17PM +0200, Johan Hovold wrote:
> > On Sun, Jul 24, 2022 at 03:50:52PM +0200, Greg Kroah-Hartman wrote:

> > > I think Yan should write a patch series to unify these and make it
> > > right, instead of just papering over it all.
> > 
> > Ok, I just fear it will be more work for us since that involves
> > decisions like whether it should be added to the uapi header, and then
> > we get into naming, etc. But we're in no rush.
> > 
> > > Also this "../" stuff in a
> > > #include directive is not ok, I wouldn't recommend this change be taken
> > > as-is.
> > 
> > That was never an option, but I'd be ok with taking the v2 which added
> > defines for the constants directly in the driver.
> 
> These are global defines, in a public spec, and they should all just be
> in one place in the kernel.  What's wrong with include/uapi/linux/cdc.h
> which is where the other ACM defined values are at?

Nothing. We'd just need to figure out how best to name them if they're
going to become UAPI, that's all (e.g. at least use a USB_CDC_ prefix to
match the other defines).

And the in-tree users would need to be updated to match.

And it's not just the control lines. We have the state notification bits
as well. Someone would need to dig out the spec.

So we go from accepting a small clean-up patch to some non-trivial
tree-wide work and review. But sure, bring it on.

Johan