reg;
> + u32 ctl_reg;
> + u32 io_reg;
> + u32 intr_cfg_reg;
> + u32 intr_status_reg;
> + u32 intr_target_reg;
>
> unsigned mux_bit:5;
>
The patch itself looks good!
Regards,
Bjorn
--
To unsubscribe from this list: send the line &q
unfortunately my 8916 documentation is incomplete so I
can't review this part.
The rest is:
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ic0_data, NA, NA, NA,
> +NA, NA),
> + PINGROUP(2, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA),
[..]
> +};
> +
[..]
My documentation is lacking the pingroup table, the rest is:
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
--
To unsubscribe from this list
"pin_config_set op not supported\n");
> > And here.
>
> Actually it looks like we can just remove these two functions and the
> core does the right thing and prints errors. That would be a good patch.
>
Yeah, seems c420619d51 ("pinctrl: pinconf: remove checks on
gt; >>default:
> >>dev_err(pctrl->dev, "Unsupported config parameter:
> >> %x\n",
> >>param);
> >> @@ -372,6 +376,9 @@ static int msm_config_group_set(struct pinctrl_dev
> >>
On Tue 16 Dec 17:15 PST 2014, Stephen Boyd wrote:
> On 12/08/2014 04:22 PM, Bjorn Andersson wrote:
>
[..]
> > +- qcom,current-limit: mA; per-string current limit; value from 0 to 25
> > + default: 20mA
> > +- qcom,current-boost-limit: mA; boost current limit; one of:
&g
On Tue 16 Dec 16:54 PST 2014, Bryan Wu wrote:
> On Mon, Dec 8, 2014 at 4:22 PM, Bjorn Andersson
[..]
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
[..]
> > +config LEDS_PM8941_WLED
> > + tristate "LED support for the Qualcomm PM8941 WLED blo
On Tue 16 Dec 17:15 PST 2014, Stephen Boyd wrote:
> On 12/08/2014 04:22 PM, Bjorn Andersson wrote:
> > diff --git a/drivers/leds/leds-pm8941-wled.c
> > b/drivers/leds/leds-pm8941-wled.c
[..]
> > +#include
> > +#include
> > +#include
> > +#in
From: Werner Johansson
This adds support for the Panasonic panel found in some Xperia Z2
tablets.
Signed-off-by: Werner Johansson
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile | 1 +
.../gpu
From: Werner Johansson
The MIPI_DSI_TURN_ON_PERIPHERAL and MIPI_DSI_SHUTDOWN_PERIPHERAL
packets are required for some panels, one example being the
Panasonic VVX10F034N00 panel.
Signed-off-by: Werner Johansson
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/drm_mipi_dsi.c | 47
From: Werner Johansson
This patch adds bindings for the Panasonic VVX10F034N00
WUXGA panel.
Signed-off-by: Werner Johansson
Signed-off-by: Bjorn Andersson
---
.../bindings/panel/panasonic,vvx10f034n00.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
From: Bjorn Andersson
Update the SMEM items for the second set of SMD channels, as these where
incorrect.
Signed-off-by: Bjorn Andersson
---
Corrected .gitconfig mishap which gave wrong author.
drivers/soc/qcom/smd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
From: Bjorn Andersson
msb of the regmap_field was mistakenly given the value 32, to set all bits
in the regmap update mask; although incorrect this worked until 921cc294,
where the mask calculation was corrected.
Signed-off-by: Bjorn Andersson
---
drivers/hwspinlock/qcom_hwspinlock.c | 2
From: Bjorn Andersson
This second incarnation of the SMEM, SMD, RPM and pm8x41 regulator series fixes
the review comments received on v1 and adds the dts patches at the end.
Bjorn Andersson (11):
soc: qcom: Add device tree binding for SMEM
soc: qcom: Add Shared Memory Manager driver
soc
From: Bjorn Andersson
The Shared Memory Manager driver implements an interface for allocating
and accessing items in the memory area shared among all of the
processors in a Qualcomm platform.
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile
From: Bjorn Andersson
Add device tree binding documentation for the Qualcomm Shared Memory
Device, used for communication between the various CPUs in the Qualcomm
SoCs.
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/soc/qcom/qcom,smd.txt | 79 ++
1 file
From: Bjorn Andersson
This adds the Qualcomm Shared Memory Driver (SMD) providing
communication channels to remote processors, ontop of SMEM.
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/Kconfig |8 +
drivers/soc/qcom/Makefile|1 +
drivers/soc/qcom/smd.c | 1324
From: Bjorn Andersson
Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.
The binding currently describes the rpm itself and the regulator
subnodes.
Signed-off-by
From: Bjorn Andersson
Add device tree binding documentation for the Qualcom Shared Memory
Manager.
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/soc/qcom/qcom,smem.txt | 51 ++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree
From: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 74 +
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index d7c99b8..65f5496 100644
--- a
From: Bjorn Andersson
Driver for regulators exposed by the Resource Power Manager (RPM) found
in devices based on Qualcomm 8974 and newer platforms.
Reviewed-by: Mark Brown
Signed-off-by: Bjorn Andersson
---
drivers/regulator/Kconfig | 12 ++
drivers/regulator/Makefile
From: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 37b47b5..7c7b7dc 100644
--- a/arch/arm/boot/dts/qcom
From: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 7c7b7dc..d7c99b8 100644
--- a/arch/arm/boot
From: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
.../boot/dts/qcom-msm8974-sony-xperia-honami.dts | 199 +
1 file changed, 199 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia
From: Bjorn Andersson
Driver for the Resource Power Manager (RPM) found in Qualcomm 8974 based
devices.
The driver exposes resources that child drivers can operate on; to
implementing regulator, clock and bus frequency drivers.
Signed-off-by: Bjorn Andersson
---
drivers/mfd/Kconfig
From: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 3f6b8f2022c4..18c419ee9d48
From: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 18c419ee9d48..3a88228e4358 100644
--- a
[+cc Dan]
On Mon, Nov 26, 2012 at 2:42 PM, Bruno Prémont
wrote:
> Hi Justin,
>
> On Sat, 24 November 2012 "Justin Piszcz" wrote:
>> Is the following normal on an X9SRL-F board (bios 1.0a)?
>>
>> In the manual it states:
>>
>> Data Direct I/O
>> Select Enabled to enable Intel I/OAT (I/O Accelerati
[Try Dan's current email address; sorry Dan]
On Mon, Nov 26, 2012 at 5:56 PM, Bjorn Helgaas wrote:
> [+cc Dan]
>
> On Mon, Nov 26, 2012 at 2:42 PM, Bruno Prémont
> wrote:
>> Hi Justin,
>>
>> On Sat, 24 November 2012 "Justin Piszcz" wrote:
>>
On Mon, Nov 26, 2012 at 6:00 PM, Justin Piszcz wrote:
>
>
> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Monday, November 26, 2012 8:00 PM
> To: Bruno Prémont
> Cc: Justin Piszcz; supp...@supermicro.com; linux-kernel@vger.kerne
t;
>
> v3:
> - Fixed a checkpatch/build issue
>
> v2:
> - Made changes so that all devices in the subtree have the error
> state set correctly.
>
>
> Reviewed-by: Linas Vepstas gmail.com>
> Reviewed-by: Myron Stowe redhat.com>
> Reviewed-by: Bjorn Helga
On Tue, Nov 20, 2012 at 1:08 AM, Huang Ying wrote:
> For unbound PCI devices, what we need is:
>
> - Always in D0 state, because some devices does not work again after
>being put into D3 by the PCI bus.
>
> - In SUSPENDED state if allowed, so that the parent devices can still
>be put int
On Wed, Nov 21, 2012 at 1:39 AM, Daniel J Blueman
wrote:
> Add NumaChip-specific PCI access mechanism via MMCONFIG cycles, but
> preventing access to AMD Northbridges which shouldn't respond.
>
> v2: Use PCI_DEVFN in precomputed constant limit; drop unneeded includes
>
> Signed-off-by: Daniel J Bl
On Tue, Nov 27, 2012 at 6:49 AM, Justin Piszcz wrote:
>
>> It looks like maybe you don't have CONFIG_PCI_MMCONFIG turned on?
>
> ===> FOR I/OAT DMA
> Latest status, it _appears_ its working on the X9SRL-F now, thank you!
>
> 1) Supermicro X9SRL-F (GOOD)
> [0.738510] ioatdma: Intel(R) QuickData
On Tue, Nov 27, 2012 at 7:35 AM, Justin Piszcz wrote:
>
>
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Tuesday, November 27, 2012 8:56 AM
> To: 'Bjorn Helgaas'
> Cc: 'Bruno Prémont'; supp...@supermicro.
On Thu, Nov 29, 2012 at 1:55 AM, Justin Piszcz wrote:
>
>
> -Original Message-
> From: Robert Hancock [mailto:hancock...@gmail.com]
> Sent: Wednesday, November 28, 2012 7:55 PM
> To: Justin Piszcz
> Cc: Bjorn Helgaas; Bruno Prémont; supp...@supermicro.com;
> linu
[+cc Jeff, linux-ide, David, Joerg, iommu]
On Thu, Nov 29, 2012 at 7:39 PM, Robert Hancock wrote:
> On Thu, Nov 29, 2012 at 12:16 PM, Bjorn Helgaas wrote:
>> On Thu, Nov 29, 2012 at 1:55 AM, Justin Piszcz
>> wrote:
>>>
>>>
>>> -Orig
On Sun, Feb 3, 2013 at 1:18 PM, Rafael J. Wysocki wrote:
> On Monday, January 28, 2013 02:09:22 PM Bjorn Helgaas wrote:
>> On Sun, Jan 20, 2013 at 5:01 PM, Rafael J. Wysocki wrote:
>> > On Saturday, January 19, 2013 12:07:42 AM Jiang Liu wrote:
>> >> A
PI PCI IRQ
stuff, but as far as I can tell, it doesn't actually touch the PCI
device itself or even the IOAPIC to which it's connected, so I'm not
sure how this would help kexec.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Tue, Feb 5, 2013 at 8:28 AM, Khalid Aziz wrote:
> On Mon, 2013-02-04 at 16:13 -0700, Bjorn Helgaas wrote:
>> On Mon, Feb 4, 2013 at 3:20 PM, Khalid Aziz wrote:
>> > On Mon, 2013-02-04 at 15:55 +0400, Konstantin Khlebnikov wrote:
>> >> Matthew Garrett and Alan
on way too much architecture knowledge. It's
better if we can deduce correctness without knowing which arches
support hotplug and which CPUs support EDAC.
As soon as for_each_pci_host_bridge() is in the tree, those uses can
be copied to even more places. It's a macro, so it's usable b
On Wed, Feb 6, 2013 at 1:53 AM, Mauro Carvalho Chehab
wrote:
> Em Tue, 5 Feb 2013 16:47:10 -0800
> Yinghai Lu escreveu:
>
>> On Tue, Feb 5, 2013 at 4:19 PM, Bjorn Helgaas wrote:
>> >
>> > Maybe. I'd rather not introduce for_each_pci_host_bridge() at all,
On Tue, Feb 5, 2013 at 5:47 PM, Yinghai Lu wrote:
> On Tue, Feb 5, 2013 at 4:19 PM, Bjorn Helgaas wrote:
>>
>> Maybe. I'd rather not introduce for_each_pci_host_bridge() at all, if
>> we can avoid it. Every place it's used is a place we have to audit to
>&g
On Wed, Feb 6, 2013 at 11:59 AM, Yinghai Lu wrote:
> On Wed, Feb 6, 2013 at 9:54 AM, Bjorn Helgaas wrote:
>> I think you're missing the point.
>>
>> Search the tree for uses of "for_each_pci_dev()." Almost every
>> occurrence is a bug because that co
On Wed, Feb 6, 2013 at 3:05 PM, Rafael J. Wysocki wrote:
> On Wednesday, February 06, 2013 01:53:50 PM Yinghai Lu wrote:
>> On Wed, Feb 6, 2013 at 1:43 PM, Rafael J. Wysocki wrote:
>> > On Wednesday, February 06, 2013 01:28:27 PM Yinghai Lu wrote:
>> >> so you still did not answer you want 1 or 2
On Fri, Feb 8, 2013 at 12:28 PM, Yinghai Lu wrote:
> For physical hot plug should be ok, but for remove/rescan path will
> need us to disable that.
>
> otherwise rescan mmio resource for pci ioapic device will not be
> sized and allocated, aka skiped.
When we scan other PCI devices, we can size m
On Fri, Feb 8, 2013 at 12:28 PM, Yinghai Lu wrote:
> We need to have ioapic setup before normal pci drivers.
> otherwise other pci driver can not setup irq.
>
> Make ioapic built-in, so can call add/remove during host-bridge add/remove
> the same as the booting path.
>
> Also need to make it depen
On Fri, Feb 8, 2013 at 3:33 PM, Yinghai Lu wrote:
> On Fri, Feb 8, 2013 at 1:14 PM, Bjorn Helgaas wrote:
>> On Fri, Feb 8, 2013 at 12:28 PM, Yinghai Lu wrote:
>>> For physical hot plug should be ok, but for remove/rescan path will
>>> need us to disable that.
&g
[+cc Rafael, since you mentioned the ACPI tree]
On Mon, Feb 11, 2013 at 12:34 AM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/include/asm/processor.h: Assembler messages:
> arch/sparc/include/
ad+0x14e
>
> Anyway, it looks like the device being unplugged wasn't removed from
> pci_pme_list as pci_pme_active(dev, false) wasn't called.
>
> From a quick review, I wasn't able to find the right place in the
> call-chain which I only see releases the child busses a
[+cc linux-acpi, linux-pci]
On Mon, Feb 11, 2013 at 01:06:27PM -0800, Yinghai Lu wrote:
> On Mon, Feb 11, 2013 at 11:57 AM, Yinghai Lu wrote:
> >>
> >> Bjorn, Rafael,
> >>
> >> acpi_pci_irq_add_prt need to be called after pci bridge get scanned,
> &g
l patches except for [6/7].
I added Rafael's acks and applied patches
[2/7] PCI: don't touch enable_cnt in pci_device_shutdown()
[3/7] PCI: catch enable-counter underflows
to my pci/konstantin-runtime-pm branch for v3.9.
I assume the others will go through the e1000e maintainer.
Bjorn
On Mon, Feb 11, 2013 at 5:34 PM, Bjorn Helgaas wrote:
> On Mon, Feb 4, 2013 at 1:23 PM, Rafael J. Wysocki wrote:
>> On Monday, February 04, 2013 03:55:47 PM Konstantin Khlebnikov wrote:
>>> This patchset contains some fixes for e1000e diver (broken since v2.6.35)
>>>
ke[4]: *** [drivers/gpu/drm/drm_pci.o] Error 1
This one is my fault. I sent the following patch to Dave to fix it up.
commit ed0708e69f71fab656afc1c891f3c54c9b105664
Author: Bjorn Helgaas
Date: Fri Feb 8 15:18:35 2013 -0700
drm/pci: define drm_pcie_get_speed_cap_mask() only when CONFIG_PCI=
On Mon, Apr 1, 2013 at 6:03 PM, Yinghai Lu wrote:
> On Mon, Apr 1, 2013 at 4:52 PM, Bjorn Helgaas wrote:
>> On Fri, Mar 29, 2013 at 11:04:48AM -0700, Yinghai Lu wrote:
>>> attatched -v3 again
>>>
>>> > Please check attached -v3.
>>
>> It'
On Mon, Apr 1, 2013 at 11:47 AM, Matthew Garrett
wrote:
> On Mon, 2013-04-01 at 11:39 -0600, Bjorn Helgaas wrote:
>
>> Chris still has problems (see
>> https://bugzilla.redhat.com/show_bug.cgi?id=927451), but I don't know
>> whether they are related to these patches o
CI config space no longer available after that.
>>
>> Link: https://lkml.org/lkml/2013/3/12/529
>> Signed-off-by: Konstantin Khlebnikov
>> Reported-and-Tested-by: Vivek Goyal
>> Cc: Bjorn Helgaas
>> Cc: Rafael J. Wysocki
>> ---
>> drivers/pci/p
On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The runtime PM of PCIe ports turns out to be quite fragile, as in
> some cases things work while in some other cases they don't and we
> don't seem to have a good way to determine whether or not they are
> goi
On Thu, Mar 28, 2013 at 3:07 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
>
> It turns out that the _Lxx control methods provided by some BIOSes
> clear the PME Status bit of PCI devices they handle, which means t
[+cc Bob for spec typo question]
On Wed, Mar 27, 2013 at 10:28 PM, Yinghai Lu wrote:
> Found problem on system that firmware that could handle pci aer.
> Firmware get error reporting after pci injecting error, before os boots.
> But after os boots, firmware can not get report anymore, even pci=no
As such, it would be good to
> give them a reminder that their systems are vulnurable to this problem.
>
> Signed-off-by: Neil Horman
> CC: Prarit Bhargava
> CC: Don Zickus
> CC: Don Dutile
> CC: Bjorn Helgaas
> CC: Asit Mallick
> CC: linux-...@vger.kernel.org
>
>
On Thu, Apr 4, 2013 at 8:50 AM, Neil Horman wrote:
> On Thu, Apr 04, 2013 at 03:27:29PM +0100, David Woodhouse wrote:
>> On Wed, 2013-04-03 at 17:53 -0600, Bjorn Helgaas wrote:
>> > );
>> > > +
>> > > + if ((revision == 0x13) && irq_re
On Thu, Apr 4, 2013 at 9:39 AM, Neil Horman wrote:
> On Thu, Apr 04, 2013 at 08:57:06AM -0600, Bjorn Helgaas wrote:
>> On Thu, Apr 4, 2013 at 8:50 AM, Neil Horman wrote:
>> > On Thu, Apr 04, 2013 at 03:27:29PM +0100, David Woodhouse wrote:
>> >> On Wed, 2013-04-03
o the region, we
could easily support I/O port access that way.
Along that line, I'm concerned that we may have a hole in the MEM BAR
.mmap() path. What happens if we have BARs from two different devices
in the same page, and we mmap() one of them? Does the user also get
access to the seco
+-
> include/linux/pci.h |5 +++
> include/linux/pci_ids.h |1 +
> 4 files changed, 141 insertions(+), 1 deletions(-)
I'm OK with the pci/quirks.c part of this, but the bulk of the
interesting code is in intel-iommu.c, so I
On Mon, Jan 28, 2013 at 9:34 PM, Huang Ying wrote:
> [PATCH 1/4] PCI/ACPI: Add target state as parameter to
> pci_platform_pm_ops->run_wake
> [PATCH 2/4] PCI: Rename pci_dev->runtime_d3cold to pci_dev->set_d3cold
> [PATCH 3/4] PCI/PM: Set pci_dev->set_d3cold in pci_set_power_state
> [PATCH 4/4] P
king some functionality), and you have told the user a way to get
safe and unreliable operation if he's willing to accept that. At
least, that's what I think I would want if I were in RH's shoes.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
s://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/commit/?h=for-x86-early-quirk-usb&id=de38757e964cfee20e6da1977572a2191d7f4aa0
>>
>> You could add one entry in early_qrk[].
>>
>> Some one already try to use that path to disable x2apic on some thinkpad.
>>
>> So it should work
_config_word(dev, 0xE0, ®ion);
> - quirk_io_region(dev, region, 64, PCI_BRIDGE_RESOURCES, "ali7101
> ACPI");
> - pci_read_config_word(dev, 0xE2, ®ion);
> - quirk_io_region(dev, region, 32, PCI_BRIDGE_RESOURCES+1, "ali7101
> SMB");
> +
On Wed, Mar 13, 2013 at 5:27 PM, Yinghai Lu wrote:
> Use resource pointer to get index in pci resources array/list.
>
> -v2: export symbol for acpiphp compiling error, found by
>Steven Newbury
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/probe.c |9 +
> include/linux/pc
*pci_physfn(struct pci_dev *dev)
> {
> #ifdef CONFIG_PCI_IOV
I think this turned out to be a disaster, with all the bitmaps and
helper functions. Filtering in the bodies of the
for_each_pci_resource() users has *got* to be better. That probably
requires a wrapper struct around the s
On Wed, Mar 13, 2013 at 5:27 PM, Yinghai Lu wrote:
> According to resource pointer find out if the resource is some type resource
> like bridge, sriov, or std.
>
> Signed-off-by: Yinghai Lu
> ---
> include/linux/pci.h | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --
On Fri, Apr 5, 2013 at 2:31 PM, Chris Murphy wrote:
>
> On Apr 2, 2013, at 2:10 PM, Bjorn Helgaas wrote:
>
>> On Mon, Apr 1, 2013 at 11:47 AM, Matthew Garrett
>> wrote:
>>> On Mon, 2013-04-01 at 11:39 -0600, Bjorn Helgaas wrote:
>>>
>&g
On Fri, Apr 5, 2013 at 1:31 PM, Neil Horman wrote:
> A few years back intel published a spec update:
> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
>
> For the 5520 and 5500 chipsets which contained an errata (specificially errata
> 5
[+cc linux-kernel]
On Fri, Apr 5, 2013 at 7:31 PM, Bjorn Helgaas wrote:
> Hi Linus,
>
> Here are some fixes for v3.9. They include fixes for an ASPM problem
> that affects pre-1.1 PCIe devices, a kexec problem, the platform ROM
> image problem, a couple hotplug issues related t
On Mon, Jan 28, 2013 at 3:00 PM, Yinghai Lu wrote:
> On Mon, Jan 28, 2013 at 1:52 PM, Bjorn Helgaas wrote:
>> On Mon, Jan 28, 2013 at 2:29 PM, Yinghai Lu wrote:
> ...
>>> If bios have messed up slot name or idx, we will get strange 1-1
>>> other crazy name.
>
[+cc Rafael, author of patch you cited]
On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
wrote:
> Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
> ("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
>
> Signed-off-by: Konstantin Khlebnikov
> Cc: e
+ "Cannot re-enable PCI device after suspend.\n");
> + return err;
> + }
Reviewed-by: Bjorn Helgaas
Seems right to me, and the other users I looked at (igb, azx,
virtio_pci) call pci_disable_device() in .suspend() and call
pci_enable_de
used a regression on your
e1000e device? If so, I guess we should revert it unless you and Dave
can figure out a better patch that fixes both your e1000e device and
the Optimus issue.
> Signed-off-by: Konstantin Khlebnikov
> Cc: linux-...@vger.kernel.org
> Cc: Bjorn Helgaas
>
l.
>
> Seems like pci_clear_master() must be used here instead of
> pci_disable_device(),
> because it disables Bus Muster unconditionally and doesn't changes enable_cnt.
>
> Signed-off-by: Konstantin Khlebnikov
> Cc: linux-...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc:
[+cc Khalid new email addr]
On Mon, Jan 28, 2013 at 4:40 PM, Bjorn Helgaas wrote:
> On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
> wrote:
>> comment in commit b566a22c23327f18ce941ffad0ca907e50a53d41
>> ("PCI: disable Bus Master on PCI device shutdown"
[+cc Rafael @sisk.pl]
On Mon, Jan 28, 2013 at 4:09 PM, Bjorn Helgaas wrote:
> [+cc Rafael]
>
> On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
> wrote:
>> __e1000_shutdown() calls pci_disable_device() at the end, thus
>> __e1000_resume()
>> should call p
On Mon, Jan 28, 2013 at 7:45 PM, Jiang Liu wrote:
> On 2013-1-29 10:21, Yinghai Lu wrote:
>> On Mon, Jan 28, 2013 at 6:07 PM, Jiang Liu wrote:
>>> Could we use quirk to auto-disable PCIe native hotplug for
>>> problematic platforms?
>>
>> that is some kind of boot command line way?
> We c
On Tue, Jan 29, 2013 at 1:28 PM, Borislav Petkov wrote:
> Hi,
>
> this is rc5 + tip/master from 2 days ago, when resuming I get this fun
> message:
>
> ...
> [15117.684975] Restarting tasks ... done.
> [15117.687201] video LNXVIDEO:00: Restoring backlight state
> [15117.720469] ehci-pci :00:1d
Dimitri and Robin have taken over GRU maintenance.
Linux on Altix is no longer maintained except as part of ia64, and
there's already a separate IA64 maintainer entry.
Signed-off-by: Bjorn Helgaas
---
MAINTAINERS | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --
pci_bus_type, the bus_type exists but the list
does not, so mach_reboot_fixups() trips over a null pointer and panics
again:
mach_reboot_fixups
pci_get_device
..
bus_find_device(&pci_bus_type, ...)
bus->p is NULL
Signed-off-by: Bjorn Helgaas
---
drive
On Tue, Jan 29, 2013 at 4:44 PM, Bjorn Helgaas wrote:
> A bus_type has a list of devices (klist_devices), but the list and the
> subsys_private structure that contains it are not initialized until the
> bus_type is registered with bus_register().
>
> The panic/reboot path has fixu
On Wed, Jan 30, 2013 at 1:09 AM, Greg Kroah-Hartman
wrote:
> On Tue, Jan 29, 2013 at 04:47:13PM -0700, Bjorn Helgaas wrote:
>> On Tue, Jan 29, 2013 at 4:44 PM, Bjorn Helgaas wrote:
>> > A bus_type has a list of devices (klist_devices), but the list and the
>> > su
On Tue, Jan 29, 2013 at 8:42 PM, Borislav Petkov wrote:
> On Tue, Jan 29, 2013 at 02:32:56PM -0700, Bjorn Helgaas wrote:
>> Konstantin has some fixes for an e1000e power management issue related
>> to suspend/resume that he observed on an x220. He didn't see an NMI,
>>
On Fri, Jan 18, 2013 at 4:37 AM, Andrew Murray wrote:
> Continuing from discussion with Thierry (lkml.org/lkml/2013/1/18/107) perhaps
> this will be useful to fold into your patchset.
> ---
> This patch provides pci_bus_fixup_irqs which performs the same
> function as pci_fixup_irqs but only to de
On Fri, Jan 25, 2013 at 5:55 PM, Myron Stowe wrote:
> This series is a minor extension to Jiang Liu's recent efforts - [PATCH v3
> 00/32] provide interfaces to access PCIe capabilities registers - which
> adds an additional PCI Express accessor for obtaining a device's
> Capabilities Register.
>
>
[+cc Rafael]
On Mon, Jan 28, 2013 at 3:00 AM, Paul Bolle wrote:
> In each suspend and resume cycle my laptop prints these messages at
> KERN_INFO level:
> pciehp :00:1c.1:pcie04: pciehp_suspend ENTRY
> pciehp :00:1c.0:pcie04: pciehp_suspend ENTRY
>
> and
> pciehp :00:1c.0:
On Wed, Jan 23, 2013 at 5:29 AM, Yijing Wang wrote:
> Document pci hotplug resource reservation parameters hpiosize
> and hpmemsize into Documentation/kernel-parameters.txt.
> The two parameters can override default hotplug io size(256 bytes)
> and default mem size(2M).
>
> Signed-off-by: Yijing W
d add MPS and MRRS
> explanation suggested by Joe Lawrence and Randy Dunlap.
> v2->v3: Update some semantic problems and the description
> of pcie_bus_safe and pcie_bus_peer2peer suggested
> by Bjorn Helgaas.
> v3->v4: Update pcie_bus_safe description s
On Fri, Feb 1, 2013 at 12:55 PM, Joe Lawrence wrote:
> On Thu, 31 Jan 2013, Myron Stowe wrote:
>> PCI: ASPM exit link state code is skipping devices
>>
>> From: Myron Stowe
>>
>> On PCI bus hotplug removal, 'pcie_aspm_exit_link_state' can potentially
>> skip parent devices that have link_state a
On Fri, Feb 1, 2013 at 9:13 AM, Jiang Liu wrote:
> On 01/29/2013 10:04 AM, Jiang Liu wrote:
>> On 2013-1-29 8:34, Rafael J. Wysocki wrote:
>>> On Monday, January 28, 2013 01:56:33 PM Bjorn Helgaas wrote:
>>>> On Fri, Jan 18, 2013 at 9:07 AM, Jiang Liu wrote:
&g
p :00:1c.0:pcie04: pciehp_resume ENTRY
> pciehp :00:1c.1:pcie04: pciehp_resume ENTRY
>
> Drop these messages, that were probably used to debug the suspend and
> resume code, but now serve no purpose.
>
> Signed-off-by: Paul Bolle
I applied this to pci/misc for v3.9. Thanks
ak the ACPI
> PCI binding logic.
>
> Signed-off-by: Jiang Liu
> ---
> Hi Bjorn,
> This patch set applies to your pci/yinghai-root-bus branch.
> There are still other potential bugs in the acpiphp driver under
> investigation. So I will send out these two first to catch u
On Fri, Feb 1, 2013 at 4:06 PM, Bjorn Helgaas wrote:
> On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu wrote:
>> From: Jiang Liu
>>
>> With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as
>> early as possible", companion ACPI devices should be create
On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu wrote:
> From: Jiang Liu
>
> Commit 668192b678201d2fff27c "PCI: acpiphp: Move host bridge hotplug
> to pci_root.c" has moved PCI host bridge hotplug logic from acpiphp
> to pci_root, but there is still PCI host bridge hotplug related
> dead code left in
1 - 100 of 11599 matches
Mail list logo
