* [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Stephen Boyd @ 2017-12-19 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b92fd3bd-c61a-ae58-49ef-8727af065ec1@gmail.com>
On 12/14, Matthias Brugger wrote:
> Hi Stephen, Michael,
>
> On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> > The ethsys registers a reset controller, so we need to specify a
> > reset cell. This patch fixes the documentation.
> >
> > Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> > ---
> > Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > index 7aa3fa167668..6cc7840ff37a 100644
> > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > @@ -20,4 +20,5 @@ ethsys: clock-controller at 1b000000 {
> > compatible = "mediatek,mt2701-ethsys", "syscon";
> > reg = <0 0x1b000000 0 0x1000>;
> > #clock-cells = <1>;
> > + #reset-cells = <1>;
> > };
> >
>
> Will you take this patch through the clk tree, or shall I take it through my SoC
> tree?
>
It's resets, we are clk maintainers. I'm clkfused.
You can take it, along with my
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
if you like/expect conflicts.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V4] ACPI / GED: unregister interrupts during shutdown
From: Rafael J. Wysocki @ 2017-12-19 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513125448-6509-1-git-send-email-okaya@codeaurora.org>
On Wed, Dec 13, 2017 at 1:37 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Some GED interrupts could be pending by the time we are doing a reboot.
>
> Even though GED driver uses devm_request_irq() to register the interrupt
> handler, the handler is not being freed on time during a shutdown since
> the driver is missing a shutdown callback.
>
> If the ACPI handler is no longer available, this causes an interrupt
> storm and delays shutdown.
>
> 1. Don't use devm family of functions for IRQ registration/free
> 2. Keep track of the events since free_irq() requires the dev_id parameter
> passed into the request_irq() function.
> 3. Call free_irq() on both remove and shutdown explicitly.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Applied, thanks!
^ permalink raw reply
* [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Wenyou.Yang at microchip.com @ 2017-12-19 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1641aa67-b05e-47e2-600c-70b77571b450@iki.fi>
Hi Sakari,
> -----Original Message-----
> From: Sakari Ailus [mailto:sakari.ailus at iki.fi]
> Sent: 2017?12?14? 4:06
> To: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Mauro Carvalho
> Chehab <mchehab@s-opensource.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>
> Cc: linux-kernel at vger.kernel.org; Nicolas Ferre - M43238
> <Nicolas.Ferre@microchip.com>; devicetree at vger.kernel.org; Jonathan Corbet
> <corbet@lwn.net>; Hans Verkuil <hverkuil@xs4all.nl>; linux-arm-
> kernel at lists.infradead.org; Linux Media Mailing List <linux-
> media at vger.kernel.org>; Songjun Wu <songjun.wu@microchip.com>
> Subject: Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
>
> Hi Wenyou,
>
> Wenyou Yang wrote:
> ...
> > +static int ov7740_start_streaming(struct ov7740 *ov7740) {
> > + int ret;
> > +
> > + if (ov7740->fmt) {
> > + ret = regmap_multi_reg_write(ov7740->regmap,
> > + ov7740->fmt->regs,
> > + ov7740->fmt->reg_num);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (ov7740->frmsize) {
> > + ret = regmap_multi_reg_write(ov7740->regmap,
> > + ov7740->frmsize->regs,
> > + ov7740->frmsize->reg_num);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return __v4l2_ctrl_handler_setup(ov7740->subdev.ctrl_handler);
>
> I believe you're still setting the controls after starting streaming.
Yes, it sees it does so.
The OV7740 sensor generates the stream pixel data at the constant frame rate, no such start or stop control.
>
> --
> Sakari Ailus
> sakari.ailus at iki.fi
Wenyou Yang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx7d-sdb.dtb
Type: application/octet-stream
Size: 46918 bytes
Desc: imx7d-sdb.dtb
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171219/361b8cf3/attachment-0001.obj>
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-19 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <615426d4-7c46-9671-87ef-790fb5733385@codeaurora.org>
On 12/18, Timur Tabi wrote:
> Stephen, any follow-up to this? I'd like to get these patches into
> 4.16 if at all possible. Thanks.
>
Ah I missed that the u16 array can't be iterated through. Any
chance the ACPI tables can be changed to list pin ranges, like
<33 3>, <90 2>, to indicate that pins 33, 34, 35 and pins 90, 91
are available? That would allow us to put that into the core
pinctrl-msm.c file a little better and then only expose pins on
the gpiochip when call gpiochip_add_pin_range(). If we want to
support this in DT, I think we would have a DT property like
available-gpios = <33 3>, <90 2>, <100 34> that we can then
iterate through and add only these pins to the gpiochip. That's
better than a bitmap in DT and is still compressed somewhat.
Without going all the way down into that path, here's my patch to
make your patch smaller, but perhaps we can just look for the
ACPI property or the DT property in the pinctrl-msm.c core and
then add pin ranges directly. Then this ACPI driver doesn't
really need to change besides for the ID update. We can expose
all the pins and offsets, etc. from the hardware driver but cut
out gpios in the core layer in a generic way.
---8<---
From: Timur Tabi <timur@codeaurora.org>
Newer versions of the firmware for the Qualcomm Datacenter Technologies
QDF2400 restricts access to a subset of the GPIOs on the TLMM. To
prevent older kernels from accidentally accessing the restricted GPIOs,
we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002,
and introduce a new property "gpios". This property is an array of
specific GPIOs that are accessible. When an older kernel boots on
newer (restricted) firmware, it will fail to probe.
To implement the sparse GPIO map, we register all of the GPIOs, but set
the pin count for the unavailable GPIOs to zero. The pinctrl-msm
driver will block those unavailable GPIOs from being accessed.
To allow newer kernels to support older firmware, the driver retains
support for QCOM8001.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 89 +++++++++++++++++++++++++++++-----
1 file changed, 77 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
index bb3ce5c3e18b..2ca2f40719b3 100644
--- a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
+++ b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
@@ -38,45 +38,107 @@ static struct msm_pinctrl_soc_data qdf2xxx_pinctrl;
/* maximum size of each gpio name (enough room for "gpioXXX" + null) */
#define NAME_SIZE 8
+enum {
+ QDF2XXX_V1,
+ QDF2XXX_V2,
+};
+
static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
{
+ const struct acpi_device_id *id;
struct pinctrl_pin_desc *pins;
struct msm_pingroup *groups;
char (*names)[NAME_SIZE];
- unsigned int i;
+ unsigned int i, j;
u32 num_gpios;
+ unsigned int avail_gpios; /* The number of GPIOs we support */
+ u16 *gpios = NULL; /* An array of supported GPIOs */
int ret;
/* Query the number of GPIOs from ACPI */
ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
if (ret < 0) {
- dev_warn(&pdev->dev, "missing num-gpios property\n");
+ dev_err(&pdev->dev, "missing 'num-gpios' property\n");
return ret;
}
-
if (!num_gpios || num_gpios > MAX_GPIOS) {
- dev_warn(&pdev->dev, "invalid num-gpios property\n");
+ dev_err(&pdev->dev, "invalid 'num-gpios' property\n");
return -ENODEV;
}
+ /*
+ * The QCOM8001 HID contains only the number of GPIOs, and assumes
+ * that all of them are available. avail_gpios is the same as num_gpios.
+ *
+ * The QCOM8002 HID introduces the 'gpios' DSD, which lists
+ * specific GPIOs that the driver is allowed to access.
+ *
+ * The make the common code simpler, in both cases we create an
+ * array of GPIOs that are accessible. So for QCOM8001, that would
+ * be all of the GPIOs.
+ */
+ id = acpi_match_device(pdev->dev.driver->acpi_match_table, &pdev->dev);
+
+ if (id->driver_data == QDF2XXX_V1) {
+ avail_gpios = num_gpios;
+ } else {
+ /* The number of GPIOs in the approved list */
+ ret = device_property_read_u16_array(&pdev->dev, "gpios",
+ NULL, 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "missing 'gpios' property\n");
+ return ret;
+ }
+ /*
+ * The number of available GPIOs should be non-zero, and no
+ * more than the total number of GPIOS.
+ */
+ if (!ret || ret > num_gpios) {
+ dev_err(&pdev->dev, "invalid 'gpios' property\n");
+ return -ENODEV;
+ }
+ avail_gpios = ret;
+
+ gpios = devm_kmalloc_array(&pdev->dev, avail_gpios,
+ sizeof(gpios[0]), GFP_KERNEL);
+ if (!gpios)
+ return -ENOMEM;
+
+ /* Assume the array of available GPIOs is sorted */
+ ret = device_property_read_u16_array(&pdev->dev, "gpios", gpios,
+ avail_gpios);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not read list of GPIOs\n");
+ return ret;
+ }
+ }
+
pins = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct pinctrl_pin_desc), GFP_KERNEL);
groups = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct msm_pingroup), GFP_KERNEL);
- names = devm_kcalloc(&pdev->dev, num_gpios, NAME_SIZE, GFP_KERNEL);
+ names = devm_kcalloc(&pdev->dev, avail_gpios, NAME_SIZE, GFP_KERNEL);
if (!pins || !groups || !names)
return -ENOMEM;
- for (i = 0; i < num_gpios; i++) {
- snprintf(names[i], NAME_SIZE, "gpio%u", i);
-
+ /*
+ * Initialize the array. GPIOs not listed in the 'gpios' bitmap
+ * still need a number, but nothing else.
+ */
+ for (i = 0, j = 0; i < num_gpios; i++) {
pins[i].number = i;
- pins[i].name = names[i];
+ groups[i].pins = &pins[i].number;
+
+ /* Only expose GPIOs that are available */
+ if (gpios && gpios[j] != i)
+ continue;
groups[i].npins = 1;
- groups[i].name = names[i];
- groups[i].pins = &pins[i].number;
+ snprintf(names[j], NAME_SIZE, "gpio%u", i);
+ pins[i].name = names[j];
+ groups[i].name = names[j];
+ j++;
groups[i].ctl_reg = 0x10000 * i;
groups[i].io_reg = 0x04 + 0x10000 * i;
@@ -100,6 +162,8 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
groups[i].intr_detection_width = 2;
}
+ devm_kfree(&pdev->dev, gpios);
+
qdf2xxx_pinctrl.pins = pins;
qdf2xxx_pinctrl.groups = groups;
qdf2xxx_pinctrl.npins = num_gpios;
@@ -110,7 +174,8 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
}
static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
- {"QCOM8001"},
+ {"QCOM8001", QDF2XXX_V1},
+ {"QCOM8002", QDF2XXX_V2},
{},
};
MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* PROBLEM: Hard lockup on Armada-385 with mvebu-mbus driver
From: Joshua Scott @ 2017-12-19 4:07 UTC (permalink / raw)
To: linux-arm-kernel
Hard lockup on Armada-385 with mvebu-mbus driver.
Hi,
We've come across an issue where we get a hard lockup (no more console output, JTAG debugger unable to connect) after receiving CPU traffic from a Marvell switch-chip (connected via PCI). The issue usually occurs within a minute of beginning the traffic stream. The issue only occurs when both cores of the processor are enabled, switching to single-core, the issue is unreproducible.
Comparing the kernel we are using (4.4.6) to the one supplied by Marvell (where the issue does not occur), we were able to narrow the minimal change to fix the issue to the following:
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c43c3d2baf..9e6b94cdef 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -349,8 +349,6 @@ static int mvebu_mbus_setup_window(struct mvebu_mbus_state *mbus,
(attr << WIN_CTRL_ATTR_SHIFT) |
(target << WIN_CTRL_TGT_SHIFT) |
WIN_CTRL_ENABLE;
- if (mbus->hw_io_coherency)
- ctrl |= WIN_CTRL_SYNCBARRIER;
writel(base & WIN_BASE_LOW, addr + WIN_BASE_OFF);
writel(ctrl, addr + WIN_CTRL_OFF);
@@ -1082,10 +1080,6 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
mbus->soc->setup_cpu_target(mbus);
mvebu_mbus_setup_cpu_target_nooverlap(mbus);
- if (is_coherent)
- writel(UNIT_SYNC_BARRIER_ALL,
- mbus->mbuswins_base + UNIT_SYNC_BARRIER_OFF);
-
register_syscore_ops(&mvebu_mbus_syscore_ops);
return 0;
While we're not currently running the latest upstream kernel, it does appear that the offending lines above are still present in the latest upstream kernel. We're not yet sure exactly why this fixes the issue, but on our platform at least it does resolve the issue we were seeing.
The main purpose of this email is to get the ball rolling on having this fix upstreamed, and perhaps to hear back from anyone involved with this code.
Cheers,
Joshua Scott
Environment:
[root at awplus flash]# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 50.00
Features : half thumb fastmult vfp edsp vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1
processor : 1
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 50.00
Features : half thumb fastmult vfp edsp vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1
Hardware : Marvell Armada 380/385 (Device Tree)
Revision : 0000
Serial : 0000000000000000
[root at awplus flash]# cat /proc/modules
tipc 115327 248 - Live 0x7f0c3000
ip6_udp_tunnel 1679 1 tipc, Live 0x7f0bf000
udp_tunnel 2053 1 tipc, Live 0x7f0bb000
br_netfilter 12045 0 - Live 0x7f0b5000
sha256_generic 8941 0 - Live 0x7f0af000
jitterentropy_rng 5909 0 - Live 0x7f0aa000
echainiv 2007 0 - Live 0x7f0a6000
drbg 13108 0 - Live 0x7f09f000
platform_driver 98540 1 - Live 0x7f048000 (O)
ipifwd 239474 18 platform_driver,[permanent], Live 0x7f000000 (PO)
[root at awplus flash]# cat /proc/ioports
00001000-000fffff : PCI I/O
[root at awplus flash]# cat /proc/iomem
00000000-3fffffff : System RAM
00008000-00628aab : Kernel code
00666000-006b3087 : Kernel data
a0000000-dfffffff : PCI MEM
a0000000-a5ffffff : PCI Bus 0000:01
a0000000-a3ffffff : 0000:01:00.0
a0000000-a3ffffff : prestera
a4000000-a47fffff : 0000:01:00.0
a4000000-a47fffff : prestera
a4800000-a48fffff : 0000:01:00.0
a4800000-a48fffff : prestera
f1010410-f1010417 : /soc/devbus-cs1
f1010680-f10106cf : /soc/internal-regs/spi at 10680
f1011000-f101101f : /soc/internal-regs/i2c at 11000
f1012000-f101201f : serial
f1018000-f101801f : /soc/internal-regs/pinctrl at 18000
f1018100-f101813f : /soc/internal-regs/gpio at 18100
f1018140-f101817f : /soc/internal-regs/gpio at 18140
f1020704-f1020707 : /soc/internal-regs/watchdog at 20300
f1020800-f102080f : /soc/internal-regs/cpurst at 20800
f1020a00-f1020ccf : /soc/internal-regs/interrupt-controller at 20a00
f1021070-f10210c7 : /soc/internal-regs/interrupt-controller at 20a00
f1022000-f1022fff : /soc/internal-regs/pmsu at 22000
f1058000-f10584ff : /soc/internal-regs/usb at 58000
f1080000-f1081fff : /soc/pcie-controller/pcie at 1,0
f10d0000-f10d0053 : /soc/internal-regs/flash at d0000
f4800000-f487ffff : f4800000.nvs
[root at awplus flash]# lspci -vvv
00:01.0 Class 0604: Device 11ab:6820 (rev 04)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff [empty]
Memory behind bridge: a0000000-a5ffffff [size=96M]
Prefetchable memory behind bridge: 00000000-000fffff [size=1M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 0.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported ARIFwd-
AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
AtomicOpsCtl: ReqEn- EgressBlck-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
01:00.0 Class 0200: Device 11ab:c804
Subsystem: Device 11ab:11ab
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 101
Region 0: Memory at a4800000 (64-bit, prefetchable) [size=1M]
Region 2: Memory at a0000000 (64-bit, prefetchable) [size=64M]
Region 4: Memory@a4000000 (64-bit, prefetchable) [size=8M]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [60] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Kernel driver in use: ATL Marvell CPSS PCI
^ permalink raw reply related
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219023935.GA17456@codeaurora.org>
On 12/18/17 8:39 PM, Stephen Boyd wrote:
> Ah I missed that the u16 array can't be iterated through. Any
> chance the ACPI tables can be changed to list pin ranges, like
> <33 3>, <90 2>, to indicate that pins 33, 34, 35 and pins 90, 91
> are available?
It's too late. Firmware is already shipping with the current layout.
Unfortunately, there's no good peer review process for DSDs that don't
have a DT equivalent.
> That would allow us to put that into the core
> pinctrl-msm.c file a little better and then only expose pins on
> the gpiochip when call gpiochip_add_pin_range(). If we want to
> support this in DT, I think we would have a DT property like
> available-gpios = <33 3>, <90 2>, <100 34> that we can then
> iterate through and add only these pins to the gpiochip. That's
> better than a bitmap in DT and is still compressed somewhat.
Keep in mind that all this ACPI junk is localized to pinctrl-qdf2xxx.
pinctrl-msm does not define any new data structures, it just reuses the
existing one. You can still define your DT properties any way you want
in your client drivers. pinctrl-qdf2xxx is specific to the Centriq chips.
> Without going all the way down into that path, here's my patch to
> make your patch smaller, but perhaps we can just look for the
> ACPI property or the DT property in the pinctrl-msm.c core and
> then add pin ranges directly. Then this ACPI driver doesn't
> really need to change besides for the ID update. We can expose
> all the pins and offsets, etc. from the hardware driver but cut
> out gpios in the core layer in a generic way.
Ok, let me review this. I don't think there's any gain in moving the
ACPI processing to pinctrl-msm, however.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] drivers: gpio: remove duplicate includes
From: Gregory Fong @ 2017-12-19 4:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513429012-8327-1-git-send-email-pravin.shedge4linux@gmail.com>
On Sat, Dec 16, 2017 at 4:56 AM, Pravin Shedge
<pravin.shedge4linux@gmail.com> wrote:
> These duplicate includes have been found with scripts/checkincludes.pl
> but they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
^ permalink raw reply
* [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Keerthy @ 2017-12-19 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e215a5e3-f729-1de4-2837-24c4a0120114@ti.com>
On Monday 18 December 2017 06:25 PM, Keerthy wrote:
>
>
> On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:
>> Keerthy,
>>
>> On Tue, Dec 12, 2017 at 11:42:16AM +0530, Keerthy wrote:
>>> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
>>>
>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>> ---
>>>
>>> Changes in v4:
>>>
>>> * Switched to dev_get_platdata.
>>
>> Where do you expect dev.platform_data to be set? PWM driver is failing
>> with:
>> omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
>> omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>>
>> Which I fixed with patch bellow, to be able to test your patchset.
>
> Thanks! I will make the below patch part of my series.
>
>>
>> Also I'm running a bit out of time, so I'll send few clean up
>> patches and event capture code to get some feedback early.
>>
>> Regards,
>> ladis
>>
>> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
>> index 39be39e6a8dd..d3d8a49cae0d 100644
>> --- a/drivers/clocksource/timer-dm.c
>> +++ b/drivers/clocksource/timer-dm.c
>> @@ -773,6 +773,7 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
>> dev_err(dev, "%s: no platform data.\n", __func__);
>> return -ENODEV;
>> }
>> + dev->platform_data = pdata;
drivers/clocksource/timer-dm.c: In function 'omap_dm_timer_probe':
drivers/clocksource/timer-dm.c:744:21: warning: assignment discards
'const' qualifier from pointer target type
This cannot be done as we are assigning a const pointer to a non-const
pointer.
I will figure out a different way for this fix.
>>
>> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> if (unlikely(!irq)) {
>>
>>>
>>> Changes in v3:
>>>
>>> * Used of_find_platdata_by_node function to fetch platform
>>> data for timer node.
>>>
>>> drivers/pwm/pwm-omap-dmtimer.c | 39 ++++++++++++++++++++++-----------------
>>> 1 file changed, 22 insertions(+), 17 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-19 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFTCetQ55zUKe25jSku0DHp8uVZA4hB32d5W6MSCNsTVpxu7Gw@mail.gmail.com>
On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>
> [snip..]
>
> [ 0.000000] linux,usable-memory-range base e800000, size 20000000
> [ 0.000000] - e800000 , 20000000
> [ 0.000000] linux,usable-memory-range base 396c0000, size a0000
> [ 0.000000] - 396c0000 , a0000
> [ 0.000000] linux,usable-memory-range base 39770000, size 40000
> [ 0.000000] - 39770000 , 40000
> [ 0.000000] linux,usable-memory-range base 398a0000, size 20000
> [ 0.000000] - 398a0000 , 20000
> [ 0.000000] initrd not fully accessible via the linear mapping --
> please check your bootloader ...
This is an odd message coming from:
|void __init arm64_memblock_init(void)
|...
|
| if (WARN(base < memblock_start_of_DRAM() ||
| base + size > memblock_start_of_DRAM() +
| linear_region_size,
| "initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) {
Can you confirm how the condition breaks here?
I suppose
base: 0xfe70000
size: 0x13c0000
memblock_start_of_DRAM(): 0xe800000
according to the information you gave me.
Thanks,
-Takahiro AKASHI
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:597
> arm64_memblock_init+0x210/0x484
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0+ #7
> [ 0.000000] task: ffff000008d05580 task.stack: ffff000008cc0000
> [ 0.000000] PC is at arm64_memblock_init+0x210/0x484
> [ 0.000000] LR is at arm64_memblock_init+0x210/0x484
> [ 0.000000] pc : [<ffff000008b76984>] lr : [<ffff000008b76984>]
> pstate: 600000c5
> [ 0.000000] sp : ffff000008ccfe80
> [ 0.000000] x29: ffff000008ccfe80 x28: 000000000f370018
> [ 0.000000] x27: 0000000011230000 x26: 00000000013b0000
> [ 0.000000] x25: 000000000fe80000 x24: ffff000008cf3000
> [ 0.000000] x23: ffff000008ec0000 x22: ffff000009680000
> [ 0.000000] x21: ffff000008afa000 x20: ffff000008080000
> [ 0.000000] x19: ffff000008afa000 x18: 000000000c283806
> [ 0.000000] x17: 0000000000000000 x16: ffff000008d05580
> [ 0.000000] x15: 000000002be00842 x14: 79206b6365686320
> [ 0.000000] x13: 657361656c70202d x12: 2d20676e69707061
> [ 0.000000] x11: 6d207261656e696c x10: 2065687420616976
> [ 0.000000] x9 : 00000000000000f4 x8 : ffff000008517414
> [ 0.000000] x7 : 746f6f622072756f x6 : 000000000000000d
> [ 0.000000] x5 : ffff000008c96360 x4 : 0000000000000001
> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
> [ 0.000000] Call trace:
> [ 0.000000] Exception stack(0xffff000008ccfd40 to 0xffff000008ccfe80)
> [ 0.000000] fd40: 0000000000000056 0000000000000000
> 0000000000000000 0000000000000000
> [ 0.000000] fd60: 0000000000000001 ffff000008c96360
> 000000000000000d 746f6f622072756f
> [ 0.000000] fd80: ffff000008517414 00000000000000f4
> 2065687420616976 6d207261656e696c
> [ 0.000000] fda0: 2d20676e69707061 657361656c70202d
> 79206b6365686320 000000002be00842
> [ 0.000000] fdc0: ffff000008d05580 0000000000000000
> 000000000c283806 ffff000008afa000
> [ 0.000000] fde0: ffff000008080000 ffff000008afa000
> ffff000009680000 ffff000008ec0000
> [ 0.000000] fe00: ffff000008cf3000 000000000fe80000
> 00000000013b0000 0000000011230000
> [ 0.000000] fe20: 000000000f370018 ffff000008ccfe80
> ffff000008b76984 ffff000008ccfe80
> [ 0.000000] fe40: ffff000008b76984 00000000600000c5
> ffff00000959b7a8 ffff000008ec0000
> [ 0.000000] fe60: ffffffffffffffff 0000000000000005
> ffff000008ccfe80 ffff000008b76984
> [ 0.000000] [<ffff000008b76984>] arm64_memblock_init+0x210/0x484
> [ 0.000000] [<ffff000008b7398c>] setup_arch+0x1b8/0x5f4
> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
> [ 0.000000] random: get_random_bytes called from
> print_oops_end_marker+0x50/0x6c with crng_init=0
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Reserving 4KB of memory at 0x2e7f0000 for elfcorehdr
> [ 0.000000] cma: Failed to reserve 512 MiB
> [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
> 0x0000000000010000 bytes below 0x0000000000000000.
> [ 0.000000]
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W
> ------------ 4.14.0+ #7
> [ 0.000000] Call trace:
> [ 0.000000] [<ffff000008088da8>] dump_backtrace+0x0/0x23c
> [ 0.000000] [<ffff000008089008>] show_stack+0x24/0x2c
> [ 0.000000] [<ffff0000087f647c>] dump_stack+0x84/0xa8
> [ 0.000000] [<ffff0000080cfd44>] panic+0x138/0x2a0
> [ 0.000000] [<ffff000008b95c88>] memblock_alloc_base+0x44/0x4c
> [ 0.000000] [<ffff000008b95cbc>] memblock_alloc+0x2c/0x38
> [ 0.000000] [<ffff000008b772dc>] early_pgtable_alloc+0x20/0x74
> [ 0.000000] [<ffff000008b7755c>] paging_init+0x28/0x544
> [ 0.000000] [<ffff000008b73990>] setup_arch+0x1bc/0x5f4
> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
> [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
> allocate 0x0000000000010000 bytes below 0x0000000000000000.
> [ 0.000000]
>
> I guess it is because of the 1G alignment requirement between the
> kernel image and the initrd and how we populate the holes between the
> kernel image, segments (including dtb) and the initrd from the
> kexec-tools.
>
> Akashi, any pointers on this will be helpful as well.
>
> Regards,
> Bhupesh
>
>
> >> >
> >> > Regards,
> >> > Bhupesh
> >> >
> >> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> > >> via a kernel command line parameter, "memmap=".
> >> > >>
> >> > _______________________________________________
> >> > kexec mailing list -- kexec at lists.fedoraproject.org
> >> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-19 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpOmeEMuoCkTC7MrBDaA1J5a4vZ_7bh3HSC0G5GoAMUCjw@mail.gmail.com>
On Tue, Dec 19, 2017 at 02:58:20AM +0530, Bhupesh Sharma wrote:
> Hi Dave,
>
> On Mon, Dec 18, 2017 at 10:46 AM, Dave Young <dyoung@redhat.com> wrote:
> > kexec at fedoraproject... is for Fedora kexec scripts discussion, changed it
> > to kexec at lists.infradead.org
> >
> > Also add linux-acpi list
> > On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
> >> On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
> >> <ard.biesheuvel@linaro.org> wrote:
> >> > On 15 December 2017 at 09:59, AKASHI Takahiro
> >> > <takahiro.akashi@linaro.org> wrote:
> >> >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> >> >>> On 13 December 2017 at 12:16, AKASHI Takahiro
> >> >>> <takahiro.akashi@linaro.org> wrote:
> >> >>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >> >>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >> >>> >> <takahiro.akashi@linaro.org> wrote:
> >> >>> >> > Bhupesh, Ard,
> >> >>> >> >
> >> >>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >> >>> >> >> Hi Ard, Akashi
> >> >>> >> >>
> >> >>> >> > (snip)
> >> >>> >> >
> >> >>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >> >>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >> >>> >> >> identify its own usable memory and exclude, at its boot time, any
> >> >>> >> >> other memory areas that are part of the panicked kernel's memory.
> >> >>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >> >>> >> >> , for details)
> >> >>> >> >
> >> >>> >> > Right.
> >> >>> >> >
> >> >>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >> >>> >> >> with the crashkernel memory range:
> >> >>> >> >>
> >> >>> >> >> /* add linux,usable-memory-range */
> >> >>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >> >>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >> >>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >> >>> >> >> address_cells, size_cells);
> >> >>> >> >>
> >> >>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >> >>> >> >> , for details)
> >> >>> >> >>
> >> >>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >> >>> >> >> they are marked as System RAM or as RESERVED. As,
> >> >>> >> >> 'linux,usable-memory-range' dt node is patched up only with
> >> >>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >> >>> >> >>
> >> >>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >> >>> >> >> ACPI memory and crashes while trying to access the same:
> >> >>> >> >>
> >> >>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >> >>> >> >> -r`.img --reuse-cmdline -d
> >> >>> >> >>
> >> >>> >> >> [snip..]
> >> >>> >> >>
> >> >>> >> >> Reserved memory range
> >> >>> >> >> 000000000e800000-000000002e7fffff (0)
> >> >>> >> >>
> >> >>> >> >> Coredump memory ranges
> >> >>> >> >> 0000000000000000-000000000e7fffff (0)
> >> >>> >> >> 000000002e800000-000000003961ffff (0)
> >> >>> >> >> 0000000039d40000-000000003ed2ffff (0)
> >> >>> >> >> 000000003ed60000-000000003fbfffff (0)
> >> >>> >> >> 0000001040000000-0000001ffbffffff (0)
> >> >>> >> >> 0000002000000000-0000002ffbffffff (0)
> >> >>> >> >> 0000009000000000-0000009ffbffffff (0)
> >> >>> >> >> 000000a000000000-000000affbffffff (0)
> >> >>> >> >>
> >> >>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >> >>> >> >> memory cap'ing passed to the crash kernel inside
> >> >>> >> >> 'arch/arm64/mm/init.c' (see below):
> >> >>> >> >>
> >> >>> >> >> static void __init fdt_enforce_memory_region(void)
> >> >>> >> >> {
> >> >>> >> >> struct memblock_region reg = {
> >> >>> >> >> .size = 0,
> >> >>> >> >> };
> >> >>> >> >>
> >> >>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> >>> >> >>
> >> >>> >> >> if (reg.size)
> >> >>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >> >>> >> >> comment this out */
> >> >>> >> >> }
> >> >>> >> >
> >> >>> >> > Please just don't do that. It can cause a fatal damage on
> >> >>> >> > memory contents of the *crashed* kernel.
> >> >>> >> >
> >> >>> >> >> 5). Both the above temporary solutions fix the problem.
> >> >>> >> >>
> >> >>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >> >>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >> >>> >> >> fail.
> >> >>> >> >>
> >> >>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >> >>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >> >>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >> >>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >> >>> >> >> dt node 'linux,usable-memory-range'
> >> >>> >> >
> >> >>> >> > I still don't understand why we need to carry over the information
> >> >>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >> >>> >> > such regions are free to be reused by the kernel after some point of
> >> >>> >> > initialization. Why does crash dump kernel need to know about them?
> >> >>> >> >
> >> >>> >>
> >> >>> >> Not really. According to the UEFI spec, they can be reclaimed after
> >> >>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >> >>> >> no longer needs them. Of course, in order to be able to boot a kexec
> >> >>> >> kernel, those regions needs to be preserved, which is why they are
> >> >>> >> memblock_reserve()'d now.
> >> >>> >
> >> >>> > For my better understandings, who is actually accessing such regions
> >> >>> > during boot time, uefi itself or efistub?
> >> >>> >
> >> >>>
> >> >>> No, only the kernel. This is where the ACPI tables are stored. For
> >> >>> instance, on QEMU we have
> >> >>>
> >> >>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> >> >>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> >> >>> 01000013)
> >> >>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> >> >>> BXPC 00000001)
> >> >>>
> >> >>> covered by
> >> >>>
> >> >>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> >> >>> ...
> >> >>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >> >>
> >> >> OK. I mistakenly understood those regions could be freed after exiting
> >> >> UEFI boot services.
> >> >>
> >> >>>
> >> >>> >> So it seems that kexec does not honour the memblock_reserve() table
> >> >>> >> when booting the next kernel.
> >> >>> >
> >> >>> > not really.
> >> >>> >
> >> >>> >> > (In other words, can or should we skip some part of ACPI-related init code
> >> >>> >> > on crash dump kernel?)
> >> >>> >> >
> >> >>> >>
> >> >>> >> I don't think so. And the change to the handling of ACPI reclaim
> >> >>> >> regions only revealed the bug, not created it (given that other
> >> >>> >> memblock_reserve regions may be affected as well)
> >> >>> >
> >> >>> > As whether we should honor such reserved regions over kexec'ing
> >> >>> > depends on each one's specific nature, we will have to take care one-by-one.
> >> >>> > As a matter of fact, no information about "reserved" memblocks is
> >> >>> > exposed to user space (via proc/iomem).
> >> >>> >
> >> >>>
> >> >>> That is why I suggested (somewhere in this thread?) to not expose them
> >> >>> as 'System RAM'. Do you think that could solve this?
> >> >>
> >> >> Memblock-reserv'ing them is necessary to prevent their corruption and
> >> >> marking them under another name in /proc/iomem would also be good in order
> >> >> not to allocate them as part of crash kernel's memory.
> >> >>
> >> >
> >> > I agree. However, this may not be entirely trivial, since iterating
> >> > over the memblock_reserved table and creating iomem entries may result
> >> > in collisions.
> >>
> >> I found a method (using the patch I shared earlier in this thread) to mark these
> >> entries as 'ACPI reclaim memory' ranges rather than System RAM or
> >> reserved regions.
> >>
> >> >> But I'm not still convinced that we should export them in useable-
> >> >> memory-range to crash dump kernel. They will be accessed through
> >> >> acpi_os_map_memory() and so won't be required to be part of system ram
> >> >> (or memblocks), I guess.
> >> >
> >> > Agreed. They will be covered by the linear mapping in the boot kernel,
> >> > and be mapped explicitly via ioremap_cache() in the kexec kernel,
> >> > which is exactly what we want in this case.
> >>
> >> Now this is what is confusing me. I don't see the above happening.
> >>
> >> I see that the primary kernel boots up and adds the ACPI regions via:
> >> acpi_os_ioremap
> >> -> ioremap_cache
> >>
> >> But during the crashkernel boot, ''acpi_os_ioremap' calls
> >> 'ioremap' for the ACPI Reclaim Memory regions and not the _cache
> >> variant.
> >>
> >> And it fails while accessing the ACPI tables:
> >>
> >> [ 0.039205] ACPI: Core revision 20170728
> >> pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> >> [ 0.095098] Internal error: Oops: 96000021 [#1] SMP
> >> [ 0.100022] Modules linked in:
> >> [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> >> [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
> >> [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
> >> [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
> >> [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
> >> pstate: 60000045
> >> [ 0.132647] sp : ffff000008ccfb40
> >> [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
> >> [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
> >> [ 0.146718] x25: 000000000000001b x24: 0000000000000001
> >> [ 0.152083] x23: 0000000000000001 x22: ffff000009710027
> >> [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
> >> [ 0.162812] x19: 000000000000001b x18: 0000000000000005
> >> [ 0.168176] x17: 0000000000000000 x16: 0000000000000000
> >> [ 0.173541] x15: 0000000000000000 x14: 000000000000038e
> >> [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
> >> [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
> >> [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
> >> [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
> >> [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
> >> [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
> >> [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
> >> [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> >> [ 0.223224] Call trace:
> >> [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
> >> [ 0.232194] fa00: 0000000000000000 ffff000009710027
> >> ffff0000095e3980 ffff000008ccfbe0
> >> [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
> >> ffff000008ccfc50 0000000000000000
> >> [ 0.248018] fa40: ffff8000126d0140 000000000000005f
> >> 00000000ffffff76 0000000000000006
> >> [ 0.255931] fa60: ffffffffffffffff ffffffff00000000
> >> 000000000000038e 0000000000000000
> >> [ 0.263843] fa80: 0000000000000000 0000000000000000
> >> 0000000000000005 000000000000001b
> >> [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
> >> ffff000009710027 0000000000000001
> >> [ 0.279667] fac0: 0000000000000001 000000000000001b
> >> 0000000000000000 ffff0000088be820
> >> [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
> >> ffff00000849b4f8 ffff000008ccfb40
> >> [ 0.295491] fb00: ffff0000084a6764 0000000060000045
> >> ffff000008ccfb40 ffff000008260a18
> >> [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
> >> ffff000008ccfb40 ffff0000084a6764
> >> [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> >> [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> >> [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> >> [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> >> [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> >> [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> >> [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> >> [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> >> [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> >> [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> >> [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> >> [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> >> [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> >> [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> >> [ 0.394500] ---[ end trace c46ed37f9651c58e ]---
> >> [ 0.399160] Kernel panic - not syncing: Fatal exception
> >> [ 0.404437] Rebooting in 10 seconds.
> >>
> >> So, I think the linear mapping done by the primary kernel does not
> >> make these accessible in the crash kernel directly.
> >>
> >> Any pointers?
> >
> > Can you get the code line number for acpi_ns_lookup+0x25c?
>
> gdb points to the following code line number:
>
> (gdb) list *(acpi_ns_lookup+0x25c)
> 0xffff0000084aa250 is in acpi_ns_lookup (drivers/acpi/acpica/nsaccess.c:577).
> 572 }
> 573 }
> 574
> 575 /* Extract one ACPI name from the front of the pathname */
> 576
> 577 ACPI_MOVE_32_TO_32(&simple_name, path);
> 578
> 579 /* Try to find the single (4 character) ACPI name */
> 580
> 581 status =
> (gdb)
>
> i.e. ACPI_MOVE_32_TO_32(&simple_name, path);
This macro can be defined in two ways depending on
ACPI_MISALIGNMENT_NOT_SUPPORTED in drivers/acpi/acpica/acmarcos.h.
So, in principle, any use of ioremap() in acpi_os_ioremap() may be
in conflict with those definitions here.
This suggests that, under the current code base, we must expose
ACPI reclaim regions as memblocks (i.e. via usable-memory-range)
in order to avoid the reported issue.
Thanks,
-Takahiro AKASHI
> addr2line also confirms the same:
>
> # addr2line -e vmlinux ffff0000084aa250
> /root/git/kernel-alt/drivers/acpi/acpica/nsaccess.c:577
>
>
> Regards,
> Bhupesh
>
>
> >>
> >> Regards,
> >> Bhupesh
> >>
> >> >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> >> via a kernel command line parameter, "memmap=".
> >> >>
> >> _______________________________________________
> >> kexec mailing list -- kexec at lists.fedoraproject.org
> >> To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-19 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219011315.2fa0f9d1@xps13>
On Tue, Dec 19, 2017 at 01:13:15AM +0100, Miquel RAYNAL wrote:
> Boris' fix wouldn't apply anyway as it was written for pxa3xx_nand.c
> and here you are using marvell_nand.c and the code is really different.
yep I noticed already during the first problem, I couldn't even find
where the equivalent part of the code was located.
> Thanks again for your help, reviews or tested-by's are welcome for this
> driver ;)
do not hesitate to add my tested-by on your current patchset if that helps.
Willy
^ permalink raw reply
* [PATCH V4 00/26] PCI: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
Deprecate pci_get_bus_and_slot() in favor of pci_get_domain_bus_and_slot()
in order to remove domain 0 assumptions in the kernel.
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.
Changes from v3:
* rebase to linux-next
* drop drm i915 as it is going through the drm tip
* commit summary cleanups
Sinan Kaya (26):
alpha/PCI: deprecate pci_get_bus_and_slot()
powerpc/PCI: deprecate pci_get_bus_and_slot()
x86/PCI: deprecate pci_get_bus_and_slot()
ata: deprecate pci_get_bus_and_slot()
agp: nvidia: deprecate pci_get_bus_and_slot()
edd: deprecate pci_get_bus_and_slot()
ibft: deprecate pci_get_bus_and_slot()
drm/gma500: deprecate pci_get_bus_and_slot()
drm/nouveau: deprecate pci_get_bus_and_slot()
Drivers: ide: deprecate pci_get_bus_and_slot()
iommu/amd: deprecate pci_get_bus_and_slot()
powerpc/powermac: deprecate pci_get_bus_and_slot()
bnx2x: deprecate pci_get_bus_and_slot()
pch_gbe: deprecate pci_get_bus_and_slot()
PCI: cpqhp: deprecate pci_get_bus_and_slot()
PCI: ibmphp: deprecate pci_get_bus_and_slot()
PCI/quirks: deprecate pci_get_bus_and_slot()
PCI/syscall: deprecate pci_get_bus_and_slot()
xen: deprecate pci_get_bus_and_slot()
openprom: deprecate pci_get_bus_and_slot()
backlight: deprecate pci_get_bus_and_slot()
video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
video: fbdev: riva: deprecate pci_get_bus_and_slot()
i7300_idle: remove unused file
PCI: Remove pci_get_bus_and_slot() function
arch/alpha/kernel/pci.c | 2 +-
arch/alpha/kernel/sys_nautilus.c | 2 +-
arch/powerpc/kernel/pci_32.c | 3 +-
arch/powerpc/platforms/powermac/feature.c | 2 +-
arch/powerpc/sysdev/mv64x60_pci.c | 4 +-
arch/x86/pci/irq.c | 3 +-
drivers/ata/pata_ali.c | 3 +-
drivers/char/agp/nvidia-agp.c | 12 +++-
drivers/char/agp/sworks-agp.c | 3 +-
drivers/firmware/edd.c | 8 +--
drivers/firmware/iscsi_ibft.c | 5 +-
drivers/gpu/drm/gma500/cdv_device.c | 16 +++--
drivers/gpu/drm/gma500/gma_device.c | 4 +-
drivers/gpu/drm/gma500/mid_bios.c | 12 +++-
drivers/gpu/drm/gma500/psb_drv.c | 10 ++-
drivers/gpu/drm/gma500/psb_drv.h | 18 ++---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +-
drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 ++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 ++-
drivers/ide/sl82c105.c | 5 +-
drivers/iommu/amd_iommu.c | 3 +-
drivers/iommu/amd_iommu_init.c | 9 +--
drivers/iommu/amd_iommu_v2.c | 3 +-
drivers/macintosh/via-pmu.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 10 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h | 1 +
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 6 +-
drivers/pci/hotplug/cpqphp_pci.c | 18 +++--
drivers/pci/hotplug/ibmphp_core.c | 7 +-
drivers/pci/quirks.c | 3 +-
drivers/pci/syscall.c | 4 +-
drivers/pci/xen-pcifront.c | 3 +-
drivers/sbus/char/openprom.c | 5 +-
drivers/video/backlight/apple_bl.c | 2 +-
drivers/video/fbdev/intelfb/intelfbhw.c | 4 +-
drivers/video/fbdev/nvidia/nv_hw.c | 11 +--
drivers/video/fbdev/nvidia/nv_setup.c | 3 +-
drivers/video/fbdev/riva/fbdev.c | 2 +-
drivers/video/fbdev/riva/nv_driver.c | 7 +-
drivers/video/fbdev/riva/riva_hw.c | 20 ++++--
drivers/video/fbdev/riva/riva_hw.h | 3 +-
include/linux/i7300_idle.h | 84 ----------------------
include/linux/pci.h | 8 ---
44 files changed, 175 insertions(+), 182 deletions(-)
delete mode 100644 include/linux/i7300_idle.h
--
1.9.1
^ permalink raw reply
* [PATCH V4 01/26] alpha/PCI: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
arch/alpha/kernel/pci.c | 2 +-
arch/alpha/kernel/sys_nautilus.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 87da005..2e86ebb 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -425,7 +425,7 @@ struct resource * __init
if (bus == 0 && dfn == 0) {
hose = pci_isa_hose;
} else {
- dev = pci_get_bus_and_slot(bus, dfn);
+ dev = pci_get_domain_bus_and_slot(0, bus, dfn);
if (!dev)
return -ENODEV;
hose = dev->sysdata;
diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index 239dc0e..ff4f54b 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -237,7 +237,7 @@
bus = hose->bus = bridge->bus;
pcibios_claim_one_bus(bus);
- irongate = pci_get_bus_and_slot(0, 0);
+ irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
bus->self = irongate;
bus->resource[0] = &irongate_io;
bus->resource[1] = &irongate_mem;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 02/26] powerpc/PCI: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Use pci_get_domain_bus_and_slot() with a domain number of 0 as the code
is not ready to consume multiple domains and existing code used domain
number 0.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
arch/powerpc/kernel/pci_32.c | 3 ++-
arch/powerpc/platforms/powermac/feature.c | 2 +-
arch/powerpc/sysdev/mv64x60_pci.c | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 1d817f4..85ad2f7 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -96,7 +96,8 @@
reg = of_get_property(node, "reg", NULL);
if (!reg)
continue;
- dev = pci_get_bus_and_slot(pci_bus, ((reg[0] >> 8) & 0xff));
+ dev = pci_get_domain_bus_and_slot(0, pci_bus,
+ ((reg[0] >> 8) & 0xff));
if (!dev || !dev->subordinate) {
pci_dev_put(dev);
continue;
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index 466b842..3f82cb2 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -829,7 +829,7 @@ static long core99_scc_enable(struct device_node *node, long param, long value)
if (value) {
if (pci_device_from_OF_node(node, &pbus, &pid) == 0)
- pdev = pci_get_bus_and_slot(pbus, pid);
+ pdev = pci_get_domain_bus_and_slot(0, pbus, pid);
if (pdev == NULL)
return 0;
rc = pci_enable_device(pdev);
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c b/arch/powerpc/sysdev/mv64x60_pci.c
index d52b3b8..6fe9104 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -37,7 +37,7 @@ static ssize_t mv64x60_hs_reg_read(struct file *filp, struct kobject *kobj,
if (count < MV64X60_VAL_LEN_MAX)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ phb = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
if (!phb)
return -ENODEV;
pci_read_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, &v);
@@ -61,7 +61,7 @@ static ssize_t mv64x60_hs_reg_write(struct file *filp, struct kobject *kobj,
if (sscanf(buf, "%i", &v) != 1)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ phb = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
if (!phb)
return -ENODEV;
pci_write_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, v);
--
1.9.1
^ permalink raw reply related
* [PATCH V4 03/26] x86/PCI: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Use domain number of 0 as the domain number is not available in struct
irq_routing_table.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/pci/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 04526291..52e5510 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -839,7 +839,8 @@ static void __init pirq_find_router(struct irq_router *r)
DBG(KERN_DEBUG "PCI: Attempting to find IRQ router for [%04x:%04x]\n",
rt->rtr_vendor, rt->rtr_device);
- pirq_router_dev = pci_get_bus_and_slot(rt->rtr_bus, rt->rtr_devfn);
+ pirq_router_dev = pci_get_domain_bus_and_slot(0, rt->rtr_bus,
+ rt->rtr_devfn);
if (!pirq_router_dev) {
DBG(KERN_DEBUG "PCI: Interrupt router not found at "
"%02x:%02x\n", rt->rtr_bus, rt->rtr_devfn);
--
1.9.1
^ permalink raw reply related
* [PATCH V4 04/26] ata: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Use pci_get_domain_bus_and_slot() and extract the actual domain number
from the pdev passed in.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Tejun Heo <tj@kernel.org>
---
drivers/ata/pata_ali.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/pata_ali.c b/drivers/ata/pata_ali.c
index d19cd88..0b122f9 100644
--- a/drivers/ata/pata_ali.c
+++ b/drivers/ata/pata_ali.c
@@ -466,7 +466,8 @@ static void ali_init_chipset(struct pci_dev *pdev)
tmp |= 0x01; /* CD_ROM enable for DMA */
pci_write_config_byte(pdev, 0x53, tmp);
}
- north = pci_get_bus_and_slot(0, PCI_DEVFN(0,0));
+ north = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus), 0,
+ PCI_DEVFN(0, 0));
if (north && north->vendor == PCI_VENDOR_ID_AL && ali_isa_bridge) {
/* Configure the ALi bridge logic. For non ALi rely on BIOS.
Set the south bridge enable bit */
--
1.9.1
^ permalink raw reply related
* [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from struct pci_dev.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/char/agp/nvidia-agp.c | 12 +++++++++---
drivers/char/agp/sworks-agp.c | 3 ++-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c
index 828b344..623205b 100644
--- a/drivers/char/agp/nvidia-agp.c
+++ b/drivers/char/agp/nvidia-agp.c
@@ -340,11 +340,17 @@ static int agp_nvidia_probe(struct pci_dev *pdev,
u8 cap_ptr;
nvidia_private.dev_1 =
- pci_get_bus_and_slot((unsigned int)pdev->bus->number, PCI_DEVFN(0, 1));
+ pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
+ PCI_DEVFN(0, 1));
nvidia_private.dev_2 =
- pci_get_bus_and_slot((unsigned int)pdev->bus->number, PCI_DEVFN(0, 2));
+ pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
+ PCI_DEVFN(0, 2));
nvidia_private.dev_3 =
- pci_get_bus_and_slot((unsigned int)pdev->bus->number, PCI_DEVFN(30, 0));
+ pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
+ PCI_DEVFN(30, 0));
if (!nvidia_private.dev_1 || !nvidia_private.dev_2 || !nvidia_private.dev_3) {
printk(KERN_INFO PFX "Detected an NVIDIA nForce/nForce2 "
diff --git a/drivers/char/agp/sworks-agp.c b/drivers/char/agp/sworks-agp.c
index 03be4ac..4dbdd3b 100644
--- a/drivers/char/agp/sworks-agp.c
+++ b/drivers/char/agp/sworks-agp.c
@@ -474,7 +474,8 @@ static int agp_serverworks_probe(struct pci_dev *pdev,
}
/* Everything is on func 1 here so we are hardcoding function one */
- bridge_dev = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+ bridge_dev = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
PCI_DEVFN(0, 1));
if (!bridge_dev) {
dev_info(&pdev->dev, "can't find secondary device\n");
--
1.9.1
^ permalink raw reply related
* [PATCH V4 06/26] edd: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Domain number is not available in struct edd_info. Hard-coding the domain
number as 0.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/firmware/edd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/edd.c b/drivers/firmware/edd.c
index e229576..60a8f13 100644
--- a/drivers/firmware/edd.c
+++ b/drivers/firmware/edd.c
@@ -669,10 +669,10 @@ static void edd_release(struct kobject * kobj)
struct edd_info *info = edd_dev_get_info(edev);
if (edd_dev_is_type(edev, "PCI") || edd_dev_is_type(edev, "XPRS")) {
- return pci_get_bus_and_slot(info->params.interface_path.pci.bus,
- PCI_DEVFN(info->params.interface_path.pci.slot,
- info->params.interface_path.pci.
- function));
+ return pci_get_domain_bus_and_slot(0,
+ info->params.interface_path.pci.bus,
+ PCI_DEVFN(info->params.interface_path.pci.slot,
+ info->params.interface_path.pci.function));
}
return NULL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V4 07/26] ibft: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
We don't search for the device in other domains than zero. This is because
on x86 platforms the BIOS executes only devices which are in domain 0.
Furthermore, the iBFT spec doesn't have a domain id field.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
---
drivers/firmware/iscsi_ibft.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/iscsi_ibft.c b/drivers/firmware/iscsi_ibft.c
index 14042a6..6bc8e66 100644
--- a/drivers/firmware/iscsi_ibft.c
+++ b/drivers/firmware/iscsi_ibft.c
@@ -719,8 +719,9 @@ static int __init ibft_create_kobject(struct acpi_table_ibft *header,
* executes only devices which are in domain 0. Furthermore, the
* iBFT spec doesn't have a domain id field :-(
*/
- pci_dev = pci_get_bus_and_slot((nic->pci_bdf & 0xff00) >> 8,
- (nic->pci_bdf & 0xff));
+ pci_dev = pci_get_domain_bus_and_slot(0,
+ (nic->pci_bdf & 0xff00) >> 8,
+ (nic->pci_bdf & 0xff));
if (pci_dev) {
rc = sysfs_create_link(&boot_kobj->kobj,
&pci_dev->dev.kobj, "device");
--
1.9.1
^ permalink raw reply related
* [PATCH V4 08/26] drm/gma500: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Add domain parameter to CDV_MSG_READ32, CDV_MSG_WRITE32, MRST_MSG_READ32,
MRST_MSG_WRITE32, MDFLD_MSG_READ32, MDFLD_MSG_WRITE32.
Extract pci_dev from struct drm_device and use pdev to find the domain
number while calling pci_get_domain_bus_and_slot().
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/gpu/drm/gma500/cdv_device.c | 16 +++++++++-------
drivers/gpu/drm/gma500/gma_device.c | 4 +++-
drivers/gpu/drm/gma500/mid_bios.c | 12 +++++++++---
drivers/gpu/drm/gma500/psb_drv.c | 10 ++++++++--
drivers/gpu/drm/gma500/psb_drv.h | 18 ++++++++++--------
5 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c b/drivers/gpu/drm/gma500/cdv_device.c
index 8745971..3a3bf75 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -185,21 +185,22 @@ static int cdv_backlight_init(struct drm_device *dev)
* for this and the MID devices.
*/
-static inline u32 CDV_MSG_READ32(uint port, uint offset)
+static inline u32 CDV_MSG_READ32(int domain, uint port, uint offset)
{
int mcr = (0x10<<24) | (port << 16) | (offset << 8);
uint32_t ret_val = 0;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
pci_write_config_dword(pci_root, 0xD0, mcr);
pci_read_config_dword(pci_root, 0xD4, &ret_val);
pci_dev_put(pci_root);
return ret_val;
}
-static inline void CDV_MSG_WRITE32(uint port, uint offset, u32 value)
+static inline void CDV_MSG_WRITE32(int domain, uint port, uint offset,
+ u32 value)
{
int mcr = (0x11<<24) | (port << 16) | (offset << 8) | 0xF0;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
pci_write_config_dword(pci_root, 0xD4, value);
pci_write_config_dword(pci_root, 0xD0, mcr);
pci_dev_put(pci_root);
@@ -216,11 +217,12 @@ static void cdv_init_pm(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
u32 pwr_cnt;
+ int domain = pci_domain_nr(dev->pdev->bus);
int i;
- dev_priv->apm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
+ dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
PSB_APMBA) & 0xFFFF;
- dev_priv->ospm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
+ dev_priv->ospm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
PSB_OSPMBA) & 0xFFFF;
/* Power status */
@@ -251,7 +253,7 @@ static void cdv_errata(struct drm_device *dev)
* Bonus Launch to work around the issue, by degrading
* performance.
*/
- CDV_MSG_WRITE32(3, 0x30, 0x08027108);
+ CDV_MSG_WRITE32(pci_domain_nr(dev->pdev->bus), 3, 0x30, 0x08027108);
}
/**
diff --git a/drivers/gpu/drm/gma500/gma_device.c b/drivers/gpu/drm/gma500/gma_device.c
index 4a295f9..a7fb6de 100644
--- a/drivers/gpu/drm/gma500/gma_device.c
+++ b/drivers/gpu/drm/gma500/gma_device.c
@@ -19,7 +19,9 @@
void gma_get_core_freq(struct drm_device *dev)
{
uint32_t clock;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root =
+ pci_get_domain_bus_and_slot(pci_domain_nr(dev->pdev->bus),
+ 0, 0);
struct drm_psb_private *dev_priv = dev->dev_private;
/*pci_write_config_dword(pci_root, 0xD4, 0x00C32004);*/
diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c
index 1fa1633..7171b74 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -32,7 +32,9 @@
static void mid_get_fuse_settings(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root =
+ pci_get_domain_bus_and_slot(pci_domain_nr(dev->pdev->bus),
+ 0, 0);
uint32_t fuse_value = 0;
uint32_t fuse_value_tmp = 0;
@@ -104,7 +106,9 @@ static void mid_get_fuse_settings(struct drm_device *dev)
static void mid_get_pci_revID(struct drm_psb_private *dev_priv)
{
uint32_t platform_rev_id = 0;
- struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0));
+ int domain = pci_domain_nr(dev_priv->dev->pdev->bus);
+ struct pci_dev *pci_gfx_root =
+ pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(2, 0));
if (pci_gfx_root == NULL) {
WARN_ON(1);
@@ -281,7 +285,9 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv)
u32 addr;
u8 __iomem *vbt_virtual;
struct mid_vbt_header vbt_header;
- struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0));
+ struct pci_dev *pci_gfx_root =
+ pci_get_domain_bus_and_slot(pci_domain_nr(dev->pdev->bus),
+ 0, PCI_DEVFN(2, 0));
int ret = -1;
/* Get the address of the platform config vbt */
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 38d09d4..ac32ab5 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -248,7 +248,11 @@ static int psb_driver_load(struct drm_device *dev, unsigned long flags)
goto out_err;
if (IS_MRST(dev)) {
- dev_priv->aux_pdev = pci_get_bus_and_slot(0, PCI_DEVFN(3, 0));
+ int domain = pci_domain_nr(dev->pdev->bus);
+
+ dev_priv->aux_pdev =
+ pci_get_domain_bus_and_slot(domain, 0,
+ PCI_DEVFN(3, 0));
if (dev_priv->aux_pdev) {
resource_start = pci_resource_start(dev_priv->aux_pdev,
@@ -268,7 +272,9 @@ static int psb_driver_load(struct drm_device *dev, unsigned long flags)
}
dev_priv->gmbus_reg = dev_priv->aux_reg;
- dev_priv->lpc_pdev = pci_get_bus_and_slot(0, PCI_DEVFN(31, 0));
+ dev_priv->lpc_pdev =
+ pci_get_domain_bus_and_slot(domain, 0,
+ PCI_DEVFN(31, 0));
if (dev_priv->lpc_pdev) {
pci_read_config_word(dev_priv->lpc_pdev, PSB_LPC_GBA,
&dev_priv->lpc_gpio_base);
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 4918efc..e8300f5 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -780,38 +780,40 @@ extern int psb_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
extern int drm_idle_check_interval;
/* Utilities */
-static inline u32 MRST_MSG_READ32(uint port, uint offset)
+static inline u32 MRST_MSG_READ32(int domain, uint port, uint offset)
{
int mcr = (0xD0<<24) | (port << 16) | (offset << 8);
uint32_t ret_val = 0;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
pci_write_config_dword(pci_root, 0xD0, mcr);
pci_read_config_dword(pci_root, 0xD4, &ret_val);
pci_dev_put(pci_root);
return ret_val;
}
-static inline void MRST_MSG_WRITE32(uint port, uint offset, u32 value)
+static inline void MRST_MSG_WRITE32(int domain, uint port, uint offset,
+ u32 value)
{
int mcr = (0xE0<<24) | (port << 16) | (offset << 8) | 0xF0;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
pci_write_config_dword(pci_root, 0xD4, value);
pci_write_config_dword(pci_root, 0xD0, mcr);
pci_dev_put(pci_root);
}
-static inline u32 MDFLD_MSG_READ32(uint port, uint offset)
+static inline u32 MDFLD_MSG_READ32(int domain, uint port, uint offset)
{
int mcr = (0x10<<24) | (port << 16) | (offset << 8);
uint32_t ret_val = 0;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
pci_write_config_dword(pci_root, 0xD0, mcr);
pci_read_config_dword(pci_root, 0xD4, &ret_val);
pci_dev_put(pci_root);
return ret_val;
}
-static inline void MDFLD_MSG_WRITE32(uint port, uint offset, u32 value)
+static inline void MDFLD_MSG_WRITE32(int domain, uint port, uint offset,
+ u32 value)
{
int mcr = (0x11<<24) | (port << 16) | (offset << 8) | 0xF0;
- struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
+ struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
pci_write_config_dword(pci_root, 0xD4, value);
pci_write_config_dword(pci_root, 0xD0, mcr);
pci_dev_put(pci_root);
--
1.9.1
^ permalink raw reply related
* [PATCH V4 09/26] drm/nouveau: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from
1. struct pci_dev
2. struct pci_dev through drm_device->pdev
3. struct pci_dev through fb->subdev->drm_device->pdev
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 +++++++---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +++++++++-
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..c79160c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -213,8 +213,10 @@ struct nv_sim_state {
if ((dev->pdev->device & 0xffff) == 0x01a0 /*CHIPSET_NFORCE*/ ||
(dev->pdev->device & 0xffff) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
+ int domain = pci_domain_nr(dev->pdev->bus);
- pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, &type);
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
+ 0x7c, &type);
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..0c9bdf0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -216,12 +216,15 @@
{
struct nvkm_pll_vals pllvals;
int ret;
+ int domain;
+
+ domain = pci_domain_nr(dev->pdev->bus);
if (plltype == PLL_MEMORY &&
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
-
- pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, &mpllP);
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
+ 0x6c, &mpllP);
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +235,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
- pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, &clock);
+ pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
+ 0x4c, &clock);
return clock / 1000;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 8d4a5be..33b6139 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -524,7 +524,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
/* subfunction one is a hdmi audio device? */
- drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+ drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ (unsigned int)pdev->bus->number,
PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 4c07d10..18241c6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -28,8 +28,16 @@
{
struct pci_dev *bridge;
u32 mem, mib;
+ int domain = 0;
+ struct pci_dev *pdev = NULL;
- bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+ if (dev_is_pci(fb->subdev.device->dev))
+ pdev = to_pci_dev(fb->subdev.device->dev);
+
+ if (pdev)
+ domain = pci_domain_nr(pdev->bus);
+
+ bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(&fb->subdev, "no bridge device\n");
return -ENODEV;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 10/26] Drivers: ide: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from struct pci_dev.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/ide/sl82c105.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ide/sl82c105.c b/drivers/ide/sl82c105.c
index 8755df3..3300dac 100644
--- a/drivers/ide/sl82c105.c
+++ b/drivers/ide/sl82c105.c
@@ -239,8 +239,9 @@ static u8 sl82c105_bridge_revision(struct pci_dev *dev)
/*
* The bridge should be part of the same device, but function 0.
*/
- bridge = pci_get_bus_and_slot(dev->bus->number,
- PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
+ bridge = pci_get_domain_bus_and_slot(pci_domain_nr(dev->bus),
+ dev->bus->number,
+ PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
if (!bridge)
return -1;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-code the domain number as 0 for the AMD IOMMU driver.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/iommu/amd_iommu.c | 3 ++-
drivers/iommu/amd_iommu_init.c | 9 +++++----
drivers/iommu/amd_iommu_v2.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 7d5eb00..821547b 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -527,7 +527,8 @@ static void amd_iommu_report_page_fault(u16 devid, u16 domain_id,
struct iommu_dev_data *dev_data = NULL;
struct pci_dev *pdev;
- pdev = pci_get_bus_and_slot(PCI_BUS_NUM(devid), devid & 0xff);
+ pdev = pci_get_domain_bus_and_slot(0, PCI_BUS_NUM(devid),
+ devid & 0xff);
if (pdev)
dev_data = get_dev_data(&pdev->dev);
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 6fe2d03..4e4a615 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1697,8 +1697,8 @@ static int iommu_init_pci(struct amd_iommu *iommu)
u32 range, misc, low, high;
int ret;
- iommu->dev = pci_get_bus_and_slot(PCI_BUS_NUM(iommu->devid),
- iommu->devid & 0xff);
+ iommu->dev = pci_get_domain_bus_and_slot(0, PCI_BUS_NUM(iommu->devid),
+ iommu->devid & 0xff);
if (!iommu->dev)
return -ENODEV;
@@ -1764,8 +1764,9 @@ static int iommu_init_pci(struct amd_iommu *iommu)
if (is_rd890_iommu(iommu->dev)) {
int i, j;
- iommu->root_pdev = pci_get_bus_and_slot(iommu->dev->bus->number,
- PCI_DEVFN(0, 0));
+ iommu->root_pdev =
+ pci_get_domain_bus_and_slot(0, iommu->dev->bus->number,
+ PCI_DEVFN(0, 0));
/*
* Some rd890 systems may not be fully reconfigured by the
diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
index 7d94e1d..8696382 100644
--- a/drivers/iommu/amd_iommu_v2.c
+++ b/drivers/iommu/amd_iommu_v2.c
@@ -564,7 +564,8 @@ static int ppr_notifier(struct notifier_block *nb, unsigned long e, void *data)
finish = (iommu_fault->tag >> 9) & 1;
devid = iommu_fault->device_id;
- pdev = pci_get_bus_and_slot(PCI_BUS_NUM(devid), devid & 0xff);
+ pdev = pci_get_domain_bus_and_slot(0, PCI_BUS_NUM(devid),
+ devid & 0xff);
if (!pdev)
return -ENODEV;
dev_data = get_dev_data(&pdev->dev);
--
1.9.1
^ permalink raw reply related
* [PATCH V4 12/26] powerpc/powermac: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-code the domain number as 0 to match the previous behavior.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index e8b29fc..08849e3 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1799,7 +1799,7 @@ static int powerbook_sleep_grackle(void)
struct adb_request req;
struct pci_dev *grackle;
- grackle = pci_get_bus_and_slot(0, 0);
+ grackle = pci_get_domain_bus_and_slot(0, 0, 0);
if (!grackle)
return -ENODEV;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 13/26] bnx2x: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Introduce bnx2x_vf_domain() function to extract the domain information
and save it to VF specific data structure.
Use the saved domain value while calling pci_get_domain_bus_and_slot().
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 10 +++++++++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 3591077..ffa7959 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -812,7 +812,7 @@ static u8 bnx2x_vf_is_pcie_pending(struct bnx2x *bp, u8 abs_vfid)
if (!vf)
return false;
- dev = pci_get_bus_and_slot(vf->bus, vf->devfn);
+ dev = pci_get_domain_bus_and_slot(vf->domain, vf->bus, vf->devfn);
if (dev)
return bnx2x_is_pcie_pending(dev);
return false;
@@ -1041,6 +1041,13 @@ void bnx2x_iov_init_dmae(struct bnx2x *bp)
REG_WR(bp, DMAE_REG_BACKWARD_COMP_EN, 0);
}
+static int bnx2x_vf_domain(struct bnx2x *bp, int vfid)
+{
+ struct pci_dev *dev = bp->pdev;
+
+ return pci_domain_nr(dev->bus);
+}
+
static int bnx2x_vf_bus(struct bnx2x *bp, int vfid)
{
struct pci_dev *dev = bp->pdev;
@@ -1606,6 +1613,7 @@ int bnx2x_iov_nic_init(struct bnx2x *bp)
struct bnx2x_virtf *vf = BP_VF(bp, vfid);
/* fill in the BDF and bars */
+ vf->domain = bnx2x_vf_domain(bp, vfid);
vf->bus = bnx2x_vf_bus(bp, vfid);
vf->devfn = bnx2x_vf_devfn(bp, vfid);
bnx2x_vf_set_bars(bp, vf);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
index 53466f6..eb814c6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
@@ -182,6 +182,7 @@ struct bnx2x_virtf {
u32 error; /* 0 means all's-well */
/* BDF */
+ unsigned int domain;
unsigned int bus;
unsigned int devfn;
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox