linux-kernel - Re: [PATCH v3 2/2] drivers/serial: Add driver for Aspeed virtual UART

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 11 Apr 2017 15:15:18 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Joel Stanley <joel@....id.au>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>, Jeremy Kerr <jk@...abs.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        openbmc@...ts.ozlabs.org
Subject: Re: [PATCH v3 2/2] drivers/serial: Add driver for Aspeed virtual UART

On Mon, Apr 10, 2017 at 7:04 AM, Joel Stanley <joel@....id.au> wrote:
> From: Jeremy Kerr <jk@...abs.org>
>
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.
>
> The VUART is two UART 'front ends' connected by their FIFO (no actual
> serial line in between). One is on the BMC side (management controller)
> and one is on the host CPU side.
>
> This driver is for the BMC side. The sysfs files allow the BMC
> userspace, which owns the system configuration policy, to specify at
> what IO port and interrupt number the host side will appear to the host
> on the Host <-> BMC LPC bus. It could be different on a different system
> (though most of them use 3f8/4).
>
> OpenPOWER host firmware doesn't like it when the host-side of the
> VUART's FIFO is not drained. This driver only disables host TX discard
> mode when the port is in use. We set the VUART enabled bit when we bind
> to the device, and clear it on unbind.
>
> We don't want to do this on open/release, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.

> +static void aspeed_vuart_set_enabled(struct aspeed_vuart *vuart, bool enabled)
> +{
> +       u8 reg;
> +
> +       reg = readb(vuart->regs + ASPEED_VUART_GCRA);

> +       reg &= ~ASPEED_VUART_GCRA_VUART_EN;
> +       if (enabled)
> +               reg |= ASPEED_VUART_GCRA_VUART_EN;

Usually the pattern is
if (something)
 set x bit;
else
 clear x bit;

It would make it one operation in any case and a bit more understandable.

> +       writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
> +}
> +
> +static void aspeed_vuart_set_host_tx_discard(struct aspeed_vuart *vuart,
> +                                            bool discard)
> +{
> +       u8 reg;
> +
> +       reg = readb(vuart->regs + ASPEED_VUART_GCRA);
> +
> +       /* If the DISABLE_HOST_TX_DISCARD bit is set, discard is disabled */

> +       reg &= ~ASPEED_VUART_GCRA_DISABLE_HOST_TX_DISCARD;
> +       if (!discard)
> +               reg |= ASPEED_VUART_GCRA_DISABLE_HOST_TX_DISCARD;

Ditto.

> +
> +       writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
> +}

> +       /* The 8510 core creates the mapping, which we grab a reference to
> +        * for VUART-specific registers */

Hmm... What about multi-line style?

> +       port.port.irq = irq_of_parse_and_map(np, 0);

The benefit of use platform_get_irq() is to get rid of some OF specific headers.

-- 
With Best Regards,
Andy Shevchenko