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: <CA+CmpXtMBEtyh77fcrhX2BU8esiit56CWfZmey6LYEHZVUxf8A@mail.gmail.com>
Date:   Fri, 5 Jul 2019 14:09:44 +0300
From:   Yehezkel Bernat <yehezkelshb@...il.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andreas Noever <andreas.noever@...il.com>,
        Michael Jamet <michael.jamet@...el.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>, Lukas Wunner <lukas@...ner.de>,
        Mario Limonciello <Mario.Limonciello@...l.com>,
        Anthony Wong <anthony.wong@...onical.com>,
        linux-acpi@...r.kernel.org
Subject: Re: [PATCH 3/8] thunderbolt: Use 32-bit writes when writing ring producer/consumer

On Fri, Jul 5, 2019 at 12:58 PM Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
>
> The register access should be using 32-bit reads/writes according to the
> datasheet. With the previous generation hardware 16-bit writes have been
> working but starting with ICL this is not the case anymore so fix
> producer/consumer register update to use correct width register address.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> ---
>  drivers/thunderbolt/nhi.c | 26 ++++++++++++++++++++++----
>  1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
> index 27fbe62c7ddd..09242653da67 100644
> --- a/drivers/thunderbolt/nhi.c
> +++ b/drivers/thunderbolt/nhi.c
> @@ -143,9 +143,24 @@ static void __iomem *ring_options_base(struct tb_ring *ring)
>         return io;
>  }
>
> -static void ring_iowrite16desc(struct tb_ring *ring, u32 value, u32 offset)
> +static void ring_iowrite_prod(struct tb_ring *ring, u16 prod)
>  {
> -       iowrite16(value, ring_desc_base(ring) + offset);
> +       u32 val;
> +
> +       val = ioread32(ring_desc_base(ring) + 8);
> +       val &= 0x0000ffff;
> +       val |= prod << 16;
> +       iowrite32(val, ring_desc_base(ring) + 8);
> +}
> +
> +static void ring_iowrite_cons(struct tb_ring *ring, u16 cons)
> +{
> +       u32 val;
> +
> +       val = ioread32(ring_desc_base(ring) + 8);
> +       val &= 0xffff0000;
> +       val |= cons;
> +       iowrite32(val, ring_desc_base(ring) + 8);
>  }
>
>  static void ring_iowrite32desc(struct tb_ring *ring, u32 value, u32 offset)
> @@ -197,7 +212,10 @@ static void ring_write_descriptors(struct tb_ring *ring)
>                         descriptor->sof = frame->sof;
>                 }
>                 ring->head = (ring->head + 1) % ring->size;
> -               ring_iowrite16desc(ring, ring->head, ring->is_tx ? 10 : 8);
> +               if (ring->is_tx)
> +                       ring_iowrite_prod(ring, ring->head);
> +               else
> +                       ring_iowrite_cons(ring, ring->head);

Really a matter of taste, but maybe you want to consider having a single
function, with a 3rd parameter, bool is_tx.
The calls here will be unified to:
        ring_iowrite(ring, ring->head, ring->is_tx);
(No condition is needed here).

The implementation uses the new parameter to decide which part of the register
to mask, reducing the code duplication (in my eyes):

        val = ioread32(ring_desc_base(ring) + 8);
        if (is_tx) {
                val &= 0x0000ffff;
                val |= value << 16;
        } else {
                val &= 0xffff0000;
                val |= value;
        }
        iowrite32(val, ring_desc_base(ring) + 8);

I'm not sure if it improves the readability or makes it worse. Your call.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ