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: <CAHp75VeomHb32NxgBbg1W51_FqyjjU-6DEM4KOFZY_pu0mrwbQ@mail.gmail.com>
Date:   Fri, 31 Mar 2017 17:44:26 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Olliver Schinagl <o.schinagl@...imaker.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Stephen Warren <swarren@...dotorg.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Alexandre Courbot <gnurou@...il.com>,
        "David S . Miller" <davem@...emloft.net>, dev@...ux-sunxi.org,
        Ed Blake <ed.blake@...tec.com>,
        Alexander Sverdlin <alexander.sverdlin@...ia.com>,
        Yegor Yefremov <yegorslists@...glemail.com>,
        Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@...el.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Jason Uy <jason.uy@...adcom.com>,
        Douglas Anderson <dianders@...omium.org>,
        Peter Hurley <peter@...leysoftware.com>,
        Tony Lindgren <tony@...mide.com>, Vignesh R <vigneshr@...com>,
        Thor Thayer <tthayer@...nsource.altera.com>,
        David Lechner <david@...hnology.com>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        sparclinux@...r.kernel.org
Subject: Re: [PATCH] serial: Do not treat the IIR register as a bitfield

On Fri, Mar 31, 2017 at 4:54 PM, Olliver Schinagl
<o.schinagl@...imaker.com> wrote:
> On 30-03-17 11:56, Andy Shevchenko wrote:
>> On Wed, 2017-03-29 at 20:44 +0200, Olliver Schinagl wrote:

>> Looking to implementation I would rather go with some helper like
>>
>> int serial_in_IIR(port, [additional mask])
>> {
>>  return port->serial_in(port, UART_IIR) & (_IIR_MASK [| additional
>> mask]);
>> }

> As I just wrote a simply static inline helper function in serial_core.h, I
> just figured that the helper will only work for some of the calls. All
> interrupt checks in xxx_serial_in() obviously can't rely on this. So do you
> still want this helper function added for the other cases? Or have all
> implementations do the masking manually?

You have still few places (3+ IIRC) where it makes sense.

> And then, is iir = serial_port_in(up, UART_IIR) & UART_IIR_MASK; preferred
> over splitting it over two lines, like I did?

With given indentation it might be long enough to uglify the code.

So, I would still go with one / two helpers (do your own choice), but
if you insist that is not beneficial I would not object in-place
masking.

static inline int serial_in_IIR_mask(port, mask)
{
 return ... & mask;
}

static inline int serial_in_IIR(port)
{
return serial_in_IIR_mask(port, ..._IIR_MASK);
}

> Finally, why rename it to _IIR_MASK, I assume a typo here?

I usually do such to minimize characters to type (notice leading _
which means I referred to a suffix) and that's why the work "like" is
used above implying you need to modify to function correctly.

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ