linux-kernel - Re: [PATCH] serial: 8250: Add support for using platform

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]

Date:   Mon, 6 May 2019 19:44:26 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Esben Haabendal <esben@...bendal.dk>
Cc:     Lee Jones <lee.jones@...aro.org>, linux-serial@...r.kernel.org,
        Enrico Weigelt <lkml@...ux.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Darwin Dingel <darwin.dingel@...iedtelesis.co.nz>,
        Jisheng Zhang <Jisheng.Zhang@...aptics.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        He Zhe <zhe.he@...driver.com>, Marek Vasut <marex@...x.de>,
        Douglas Anderson <dianders@...omium.org>,
        Paul Burton <paul.burton@...s.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] serial: 8250: Add support for using platform_device
 resources

On Mon, May 06, 2019 at 05:46:56PM +0200, Esben Haabendal wrote:
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> writes:
> >> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
> >> >> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> writes:

> As an example, the sm501.c driver, the only driver in drivers/mfd/ which
> uses serial8250 driver, does not use any code from mfd-core.
> Incidentally, it is 1 year older than mfd-core.c, and as never been
> refactored to use mfd-core functionality.

So, sm501.c should not request resources for its children. This as simple as
that.

What you are trying to do here is a hack workaround on the current behaviour in
the Linux device model (resource management) as I told you already.

> > Why not? Again, *slicing* resources is OK and that's what MFD for, *requesting*
> > them in the parent is not.
> 
> Why we cannot use request_mem_region() for those memory resources again?

Because it's how it was designed. "One device per one resource". If you would
like to fix this, it should be done obviously not in 8250 driver or any other
driver, but driver core.

Nevertheless there is one particular exception here, i.e. IORESOURCE_MUXED.

> It fails because the resources are now already owned the mfd driver, on
> behalf of the child.

Yes. Behaves in order how it's implementer. No issues here.

> > Nope, *requesting* resources as you mentioned lock them to the certain user.
> 
> I still think there is some confusion in relation to your use of the
> word "requesting".  There is no explicit request/lock action in
> kernel/resource.c.

You have to check IORESOURCE_BUSY. It seems that what you missed in your
picture.

I didn't comment the rest until we will figure out the IO resource management
in general.

-- 
With Best Regards,
Andy Shevchenko