[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR04MB553386A3F452E13BFCF79688EED90@VI1PR04MB5533.eurprd04.prod.outlook.com>
Date: Tue, 20 Nov 2018 13:03:38 +0000
From: Leonard Crestez <leonard.crestez@....com>
To: Stefan Agner <stefan@...er.ch>, Richard Zhu <hongxing.zhu@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jingoohan1@...il.com" <jingoohan1@...il.com>,
"gustavo.pimentel@...opsys.com" <gustavo.pimentel@...opsys.com>,
"tpiepho@...inj.com" <tpiepho@...inj.com>,
"andrew.smirnov@...il.com" <andrew.smirnov@...il.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"l.stach@...gutronix.de" <l.stach@...gutronix.de>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>
Subject: RE: [PATCH 2/2] PCI: imx6: limit DBI register length
From: Stefan Agner <stefan@...er.ch>
> On 20.11.2018 11:22, Leonard Crestez wrote:
> > On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote:
> >> Define the length of the DBI registers. This makes sure that
> >> the kernel does not access registers beyond that point, avoiding
> >> the following abort on a i.MX 6Quad:
> >> # cat
> /sys/devices/soc0/soc/1ffc000.pcie/pci0000\:00/0000\:00\:00.0/config
> >> [ 100.021433] Unhandled fault: imprecise external abort (0x1406) at
> 0xb6ea7000
> >> ...
> >> [ 100.056423] PC is at dw_pcie_read+0x50/0x84
> >> [ 100.060790] LR is at dw_pcie_rd_own_conf+0x44/0x48
> >> ...
> >>
> >> Signed-off-by: Stefan Agner <stefan@...er.ch>
> >>
> >> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> >
> >> +struct imx6_pcie_drvdata {
> >> + enum imx6_pcie_variants variant;
> >> + int dbi_length;
> >> +};
> >
> > Turning imx6_pcie drvdata into a struct is very nice, maybe in the
> > future some of the long case statements in this driver could be split
> > into per-soc functions called via drvdata.
>
> Yeah I thought that too. At a quick glance I did not saw an obvious
> contender. Should certainly help for similar cases in the future.
Yes, there are other cases in which it would be useful.
But I think it makes more sense to split introducing drvdata to a separate patch.
It's nice to separate functional and code cleanup changes.
For example maybe dbi_length causes issues and has to be reverted?
--
Regards,
Leonard
Powered by blists - more mailing lists