From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Gregory CLEMENT <gregory.clement@free-electrons.com>,
Andrew Lunn <andrew@lunn.ch>
Cc: Tejun Heo <tj@kernel.org>, Jason Cooper <jason@lakedaemon.net>,
linux-ide@vger.kernel.org
Subject: Re: [PATCH] Revert "ata: sata_mv: Convert to devm_ioremap_resource()"
Date: Wed, 24 May 2017 16:36:12 +0300 [thread overview]
Message-ID: <1495632972.6967.104.camel@linux.intel.com> (raw)
In-Reply-To: <87d1aywgrj.fsf@free-electrons.com>
On Wed, 2017-05-24 at 15:01 +0200, Gregory CLEMENT wrote:
> Hi Andrew,
>
> On mer., mai 24 2017, Andrew Lunn <andrew@lunn.ch> wrote:
>
> > This reverts commit 368e5fbdfc60732643f34f538823ed4bc8829827.
> >
> > devm_ioremap_resource() enforces that there are no overlapping
> > resources, where as devm_ioremap() does not. The sata phy driver
> > needs
> > a subset of the sata IO address space, so maps some of the sata
> > address space. As a result, sata_mv now fails to probe, reporting it
> > cannot get its resources, and so we don't have any SATA disks.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> For this patch as it fixes a regresssion:
>
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> However, as the same set of register are accessed by two drivers, is
> there a risk for a race condition ?
>
> In this case we may consider to use a regmap.
>
> Or maybe they never aces the same register ?
I'm wondering where exactly first resource acquiring is happening.
For me seems that the initial patch unhides the issue.
>
> In this case it is safe to let the driver as is, but adding a comment
> could be useful.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2017-05-24 13:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 23:39 [PATCH] Revert "ata: sata_mv: Convert to devm_ioremap_resource()" Andrew Lunn
2017-05-24 13:01 ` Gregory CLEMENT
2017-05-24 13:12 ` Andrew Lunn
2017-05-24 13:36 ` Andy Shevchenko [this message]
2017-05-24 13:41 ` Andrew Lunn
2017-05-24 14:00 ` Andy Shevchenko
2017-05-24 14:11 ` Gregory CLEMENT
2017-05-24 14:29 ` Andrew Lunn
2017-05-25 12:53 ` Andy Shevchenko
2017-05-25 13:26 ` Andrew Lunn
2017-05-25 13:34 ` Andy Shevchenko
2017-05-24 15:07 ` Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2017-05-30 13:52 Linus Walleij
2017-05-30 13:55 ` Andy Shevchenko
2017-05-30 23:53 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1495632972.6967.104.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=andrew@lunn.ch \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-ide@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.