linux-kernel - Re: [patch v1 2/2] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

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: <CAK8P3a20dXeeNkRCgs8BNWOo1zvNpBLqkQNwpj8dS2bOq1cq+A@mail.gmail.com>
Date:   Wed, 2 Aug 2017 16:56:25 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Neil Armstrong <narmstrong@...libre.com>
Cc:     Oleksandr Shamray <oleksandrs@...lanox.com>,
        gregkh <gregkh@...uxfoundation.org>, devicetree@...r.kernel.org,
        Jiří Pírko <jiri@...nulli.us>,
        system-sw-low-level@...lanox.com,
        OpenBMC Maillist <openbmc@...ts.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        mec@...ut.net, Jiri Pirko <jiri@...lanox.com>,
        Joel Stanley <joel@....id.au>, linux-serial@...r.kernel.org,
        vadimp@...llanox.com, Tobias Klauser <tklauser@...tanz.ch>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [patch v1 2/2] drivers: jtag: Add Aspeed SoC 24xx and 25xx
 families JTAG master driver

On Wed, Aug 2, 2017 at 4:30 PM, Neil Armstrong <narmstrong@...libre.com> wrote:
> On 08/02/2017 03:18 PM, Oleksandr Shamray wrote:
>> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.

>> +static u32 aspeed_jtag_read(struct aspeed_jtag *aspeed_jtag, u32 reg)
>> +{
>> +     return readl(aspeed_jtag->reg_base + reg);
>> +}
>> +
>> +static void
>> +aspeed_jtag_write(struct aspeed_jtag *aspeed_jtag, u32 val, u32 reg)
>> +{
>> +     writel(val, aspeed_jtag->reg_base + reg);
>> +}
>
> Maybe readl_relaxed/writel_relaxed would be enough here.

I'd prefer keeping the regular accessors here, unless this is shown
to be a performance bottleneck, and there is a comment to explain
how the relaxed accessors are determined to be safe.

        Arnd