linux-kernel - Re: [PATCH 3/4] USB: serial: ftdi

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <X85IC5NvcWikXfZY@localhost>
Date:   Mon, 7 Dec 2020 16:19:39 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Johan Hovold <johan@...nel.org>, linux-usb@...r.kernel.org,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        kernel-team@...roid.com
Subject: Re: [PATCH 3/4] USB: serial: ftdi_sio: Log the CBUS GPIO validity

On Mon, Dec 07, 2020 at 03:00:37PM +0000, Marc Zyngier wrote:
> On 2020-12-07 14:29, Johan Hovold wrote:
> > On Fri, Dec 04, 2020 at 04:47:38PM +0000, Marc Zyngier wrote:

> >> +	if (!bitmap_full(valid_mask, ngpios))
> >> +		dev_warn_once(&port->dev, "Consider using a tool such as ftx-prog 
> >> to enable GPIOs if required\n");
> >> +
> > 
> > And again, this is not something that belongs in the logs of just about
> > every system with an attached ftdi device.
> 
> Fine by me, this patch can be dropped without issue. After all,
> I now know how to deal with these chips.
> 
> > While not possible to combine with the valid_mask approach, this is
> > something which we could otherwise add to the request() callback for 
> > the
> > first request that fails due to the mux configuration.
> 
> That was Linus' initial suggestion. But I think a consistent user
> API is more important than free advise in the kernel log.

I tend to agree. So since your valid-mask approach clearly has some
merit in that it marks the lines in use when using the new cdev
interface, perhaps we should stick with that.

Johan