linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Sergey Shtylyov <s.shtylyov@omp.ru>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Mark Brown <broonie@kernel.org>,
	MTD Maling List <linux-mtd@lists.infradead.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/7] memory: renesas-rpc-if: Move resource acquisition to .probe()
Date: Wed, 29 Jun 2022 20:25:57 +0200	[thread overview]
Message-ID: <bab4d845-330e-c7f0-5dac-a96caa93a39e@linaro.org> (raw)
In-Reply-To: <CAMuHMdW=s42sfFwimizTsNjyKue+W9NasTOG0jgjkgkoKv3wfw@mail.gmail.com>

On 29/06/2022 19:55, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Wed, Jun 29, 2022 at 7:44 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> On 27/06/2022 17:31, Geert Uytterhoeven wrote:
>>> While the acquired resources are tied to the lifetime of the RPC-IF core
>>> device (through the use of managed resource functions), the actual
>>> resource acquisition is triggered from the HyperBus and SPI child
>>> drivers.  Due to this mismatch, unbinding and rebinding the child
>>> drivers manually fails with -EBUSY:
>>>
>>>     # echo rpc-if-hyperflash > /sys/bus/platform/drivers/rpc-if-hyperflash/unbind
>>>     # echo rpc-if-hyperflash > /sys/bus/platform/drivers/rpc-if-hyperflash/bind
>>>     rpc-if ee200000.spi: can't request region for resource [mem 0xee200000-0xee2001ff]
>>>     rpc-if-hyperflash: probe of rpc-if-hyperflash failed with error -16
>>>
>>> Fix this by moving all resource acquisition to the core driver's probe
>>> routine.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> This looks like a fix, so how about putting it as first in the series,
>> so backporting is easy/automatic?
> 
> Unfortunately that is not as simple as it sounds, as this really
> depends on patch 4.

You sure? Except rebasing I don't see that. rpcif_sw_init() received the
rpcif so it had access to all fields.


> I agree patches 1-3 could be moved later, if you think it is worthwhile.

This would not be enough, it has to be first patch to be backportable.

Best regards,
Krzysztof

  reply	other threads:[~2022-06-29 18:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 15:31 [PATCH 0/7] memory: renesas-rpc-if: Rebind and s2ram fixes Geert Uytterhoeven
2022-06-27 15:31 ` [PATCH 1/7] memory: renesas-rpc-if: Always use dev in rpcif_sw_init() Geert Uytterhoeven
2022-06-27 15:31 ` [PATCH 2/7] memory: renesas-rpc-if: Add dev helper to rpcif_probe() Geert Uytterhoeven
2022-06-27 15:31 ` [PATCH 3/7] memory: renesas-rpc-if: Improve Runtime PM handling Geert Uytterhoeven
2022-06-27 15:31 ` [PATCH 4/7] memory: renesas-rpc-if: Split-off private data from struct rpcif Geert Uytterhoeven
2022-06-27 15:31 ` [PATCH 5/7] memory: renesas-rpc-if: Move resource acquisition to .probe() Geert Uytterhoeven
2022-06-29 17:44   ` Krzysztof Kozlowski
2022-06-29 17:55     ` Geert Uytterhoeven
2022-06-29 18:25       ` Krzysztof Kozlowski [this message]
2022-06-29 18:48         ` Geert Uytterhoeven
2022-06-30  8:48           ` Krzysztof Kozlowski
2022-06-30  9:15             ` Geert Uytterhoeven
2022-06-27 15:31 ` [PATCH 6/7] memory: renesas-rpc-if: Pass device instead of rpcif to rpcif_*() Geert Uytterhoeven
2022-06-29 18:26   ` Krzysztof Kozlowski
2022-06-30  7:25   ` Miquel Raynal
2022-06-30  8:46     ` Krzysztof Kozlowski
2022-06-30  8:58       ` Miquel Raynal
2022-06-27 15:31 ` [PATCH 7/7] memory: renesas-rpc-if: Reinitialize registers during system resume Geert Uytterhoeven
2022-11-23 14:49   ` Geert Uytterhoeven

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=bab4d845-330e-c7f0-5dac-a96caa93a39e@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=broonie@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=richard@nod.at \
    --cc=s.shtylyov@omp.ru \
    --cc=vigneshr@ti.com \
    --cc=wsa+renesas@sang-engineering.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).