From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: "Pali Rohár" <pali@kernel.org>, linus.walleij@linaro.org, kishon@ti.com
Cc: Luca Ceresoli <luca@lucaceresoli.net>,
linux-pci@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring <robh@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v2] PCI: dra7xx: Fix reset behaviour
Date: Tue, 22 Jun 2021 12:56:04 +0100 [thread overview]
Message-ID: <20210622115604.GA25503@lpieralisi> (raw)
In-Reply-To: <20210622110627.aqzxxtf2j3uxfeyl@pali>
[Adding Linus for GPIO discussion, thread:
https://lore.kernel.org/linux-pci/20210531090540.2663171-1-luca@lucaceresoli.net]
On Tue, Jun 22, 2021 at 01:06:27PM +0200, Pali Rohár wrote:
> Hello!
>
> On Tuesday 22 June 2021 12:57:22 Luca Ceresoli wrote:
> > Nothing happened after a few weeks... I understand that knowing the
> > correct reset timings is relevant, but unfortunately I cannot help much
> > in finding out the correct values.
> >
> > However I'm wondering what should happen to this patch. It *does* fix a
> > real bug, but potentially with an incorrect or non-optimal usleep range.
> > Do we really want to ignore a bugfix because we are not sure about how
> > long this delay should be?
>
> As there is no better solution right now, I'm fine with your patch. But
> patch needs to be approved by Lorenzo, so please wait for his final
> answer.
I am not a GPIO expert and I have a feeling this is platform specific
beyond what the PCI specification can actually define architecturally.
There are two things I'd like to see:
1) If Linus can have a look at the GPIO bits in this thread that would
definitely help clarify any pending controversy
2) Kishon to test on *existing* platforms and confirm there are no
regressions triggered
> I would suggest to add a comment for call "usleep_range(1000, 2000);"
> that you have chosen some "random" values which worked fine on your
> setup and that they fix mentioned bug. Comment just to mark this sleep
> code that is suboptimal / not-so-correct and to prevent other people to
> copy+paste this code into other (new) drivers...
Yes a comment would help but as I say above I am afraid this is
a platform specific set-up, ie that delay is somewhat tied to
a platform, not sure there is anything we can do.
If Linus and Kishon are happy with the approach we can merge this
patch.
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: "Pali Rohár" <pali@kernel.org>, linus.walleij@linaro.org, kishon@ti.com
Cc: Luca Ceresoli <luca@lucaceresoli.net>,
linux-pci@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring <robh@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v2] PCI: dra7xx: Fix reset behaviour
Date: Tue, 22 Jun 2021 12:56:04 +0100 [thread overview]
Message-ID: <20210622115604.GA25503@lpieralisi> (raw)
In-Reply-To: <20210622110627.aqzxxtf2j3uxfeyl@pali>
[Adding Linus for GPIO discussion, thread:
https://lore.kernel.org/linux-pci/20210531090540.2663171-1-luca@lucaceresoli.net]
On Tue, Jun 22, 2021 at 01:06:27PM +0200, Pali Rohár wrote:
> Hello!
>
> On Tuesday 22 June 2021 12:57:22 Luca Ceresoli wrote:
> > Nothing happened after a few weeks... I understand that knowing the
> > correct reset timings is relevant, but unfortunately I cannot help much
> > in finding out the correct values.
> >
> > However I'm wondering what should happen to this patch. It *does* fix a
> > real bug, but potentially with an incorrect or non-optimal usleep range.
> > Do we really want to ignore a bugfix because we are not sure about how
> > long this delay should be?
>
> As there is no better solution right now, I'm fine with your patch. But
> patch needs to be approved by Lorenzo, so please wait for his final
> answer.
I am not a GPIO expert and I have a feeling this is platform specific
beyond what the PCI specification can actually define architecturally.
There are two things I'd like to see:
1) If Linus can have a look at the GPIO bits in this thread that would
definitely help clarify any pending controversy
2) Kishon to test on *existing* platforms and confirm there are no
regressions triggered
> I would suggest to add a comment for call "usleep_range(1000, 2000);"
> that you have chosen some "random" values which worked fine on your
> setup and that they fix mentioned bug. Comment just to mark this sleep
> code that is suboptimal / not-so-correct and to prevent other people to
> copy+paste this code into other (new) drivers...
Yes a comment would help but as I say above I am afraid this is
a platform specific set-up, ie that delay is somewhat tied to
a platform, not sure there is anything we can do.
If Linus and Kishon are happy with the approach we can merge this
patch.
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-22 11:56 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-31 9:05 [PATCH v2] PCI: dra7xx: Fix reset behaviour Luca Ceresoli
2021-05-31 9:05 ` Luca Ceresoli
2021-05-31 13:32 ` Pali Rohár
2021-05-31 13:32 ` Pali Rohár
2021-05-31 13:54 ` Luca Ceresoli
2021-05-31 13:54 ` Luca Ceresoli
2021-05-31 16:00 ` Kishon Vijay Abraham I
2021-05-31 16:00 ` Kishon Vijay Abraham I
2021-05-31 16:22 ` Pali Rohár
2021-05-31 16:22 ` Pali Rohár
2021-06-22 10:57 ` Luca Ceresoli
2021-06-22 10:57 ` Luca Ceresoli
2021-06-22 11:06 ` Pali Rohár
2021-06-22 11:06 ` Pali Rohár
2021-06-22 11:56 ` Lorenzo Pieralisi [this message]
2021-06-22 11:56 ` Lorenzo Pieralisi
2021-06-22 12:16 ` Pali Rohár
2021-06-22 12:16 ` Pali Rohár
2021-06-22 13:31 ` Luca Ceresoli
2021-06-22 13:31 ` Luca Ceresoli
2021-06-22 13:57 ` Kishon Vijay Abraham I
2021-06-22 13:57 ` Kishon Vijay Abraham I
2021-06-22 20:52 ` Pali Rohár
2021-06-22 20:52 ` Pali Rohár
2021-06-22 21:08 ` Luca Ceresoli
2021-06-22 21:08 ` Luca Ceresoli
2021-06-22 21:19 ` Pali Rohár
2021-06-22 21:19 ` Pali Rohár
2021-06-22 21:36 ` Luca Ceresoli
2021-06-22 21:36 ` Luca Ceresoli
2021-06-22 22:23 ` Pali Rohár
2021-06-22 22:23 ` Pali Rohár
2021-06-24 21:31 ` Luca Ceresoli
2021-06-24 21:31 ` Luca Ceresoli
2021-06-24 21:42 ` Pali Rohár
2021-06-24 21:42 ` Pali Rohár
2021-06-24 23:18 ` Linus Walleij
2021-06-24 23:18 ` Linus Walleij
2021-06-24 23:34 ` Pali Rohár
2021-06-24 23:34 ` Pali Rohár
2021-06-25 0:09 ` Linus Walleij
2021-06-25 0:09 ` Linus Walleij
2021-06-25 8:05 ` Luca Ceresoli
2021-06-25 8:05 ` Luca Ceresoli
2021-06-22 21:04 ` Luca Ceresoli
2021-06-22 21:04 ` Luca Ceresoli
2021-06-24 23:11 ` Linus Walleij
2021-06-24 23:11 ` Linus Walleij
2021-06-25 8:10 ` Luca Ceresoli
2021-06-25 8:10 ` Luca Ceresoli
2021-06-22 14:23 ` Lorenzo Pieralisi
2021-06-22 14:23 ` Lorenzo Pieralisi
2021-06-22 20:48 ` Pali Rohár
2021-06-22 20:48 ` Pali Rohár
2021-06-22 20:55 ` Pali Rohár
2021-06-22 20:55 ` Pali Rohár
2021-06-22 21:13 ` Luca Ceresoli
2021-06-22 21:13 ` Luca Ceresoli
2021-06-01 9:03 ` Luca Ceresoli
2021-06-01 9:03 ` Luca Ceresoli
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=20210622115604.GA25503@lpieralisi \
--to=lorenzo.pieralisi@arm.com \
--cc=bhelgaas@google.com \
--cc=kishon@ti.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=pali@kernel.org \
--cc=robh@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.