From: Trent Piepho <tpiepho@impinj.com>
To: "stefan@agner.ch" <stefan@agner.ch>
Cc: "hongxing.zhu@nxp.com" <hongxing.zhu@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"gustavo.pimentel@synopsys.com" <gustavo.pimentel@synopsys.com>,
"andrew.smirnov@gmail.com" <andrew.smirnov@gmail.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"l.stach@pengutronix.de" <l.stach@pengutronix.de>,
"leonard.crestez@nxp.com" <leonard.crestez@nxp.com>,
"bhelgaas@google.com" <bhelgaas@google.com>
Subject: Re: [PATCH v3 2/2] PCI: imx6: limit DBI register length
Date: Tue, 20 Nov 2018 21:28:23 +0000 [thread overview]
Message-ID: <1542749302.30311.624.camel@impinj.com> (raw)
In-Reply-To: <268e109e1c6b309454bd5a313078894c@agner.ch>
On Tue, 2018-11-20 at 21:42 +0100, Stefan Agner wrote:
> On 20.11.2018 20:13, Trent Piepho wrote:
> >
> > On IMX7d, there are significant blocks of 00s in the config space, and
> > all 0xff at 0xb50 on up.
> >
> > I.e., significant portions are empty, in the middle of the config
> > space, not just at the end.
> >
> > But they can be read without problem.
> >
> > Perhaps imx6q aborts on a read of an unimplemented address instead of
> > returning zeros like imx7d. In that case it really needs something
> > more complex to prevent abort than just a length.
>
> Yeah it seems those SoCs behave differently.
>
> Describing a register set with holes will get complicated, I guess it
> would ask for a regmap...
>
> >
> > It also seems to me that this doesn't need to be in the internal pci
> > config access functions. The driver shouldn't be reading registers
> > that don't exist anyway. It's really about trying to fix sysfs access
> > to registers that don't exist. So maybe it should be done there.
>
> That was my first approach, see:
https://lkml.org/lkml/2018/11/14/716
Yes, but that just used the pci device id which applies to every IMX
design.
It's also not totally correct, as it seems real registers after 0x200
do work on imx6, and that would prevent access to them.
Like you say, it could use a regmap. Seems kinda overkill to me
though.
I wonder if regmap based caching of register to avoid RMW cycles would
be generally useful? I know the enable and mask registers are/were
cached in the driver (irq_state[]).
next prev parent reply other threads:[~2018-11-20 21:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 16:56 [PATCH v3 1/2] PCI: imx6: introduce drvdata Stefan Agner
2018-11-20 16:56 ` [PATCH v3 2/2] PCI: imx6: limit DBI register length Stefan Agner
2018-11-20 18:19 ` Leonard Crestez
2018-11-20 19:13 ` Trent Piepho
2018-11-20 20:42 ` Stefan Agner
2018-11-20 21:28 ` Trent Piepho [this message]
2018-11-21 13:47 ` Leonard Crestez
2018-11-21 14:17 ` Lorenzo Pieralisi
2018-11-28 12:19 ` Stefan Agner
2018-11-28 17:36 ` Stefan Agner
2018-11-28 17:50 ` Lucas Stach
2018-11-28 17:56 ` Stefan Agner
2018-11-28 18:01 ` Leonard Crestez
2018-11-26 10:16 ` Leonard Crestez
2018-11-26 16:34 ` Trent Piepho
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=1542749302.30311.624.camel@impinj.com \
--to=tpiepho@impinj.com \
--cc=andrew.smirnov@gmail.com \
--cc=bhelgaas@google.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=hongxing.zhu@nxp.com \
--cc=jingoohan1@gmail.com \
--cc=l.stach@pengutronix.de \
--cc=leonard.crestez@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=stefan@agner.ch \
/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