On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote:
> On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote:
> > On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote:
> > > On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner wrote:
> > > >
On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote:
> > On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote:
> > > &
On Thu, Jul 21, 2016 at 12:51:31AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 20, 2016 05:23:40 PM Lukas Wunner wrote:
> > On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote:
> > >
On Fri, Sep 16, 2016 at 02:33:55PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Currently, there is a problem with taking functional dependencies
> between into account.
^
devices
> What I mean by a "functional dependency" is when the driver of device
> B needs
Hi Matt, Hi Ard,
On Wed, Sep 21, 2016 at 04:09:12PM +0100, Matt Fleming wrote:
> I've asked, and Ard has agreed to step up and help me co-maintain the
> EFI subsystem.
>
> Given that there are now two maintainers, we're moving to a shared git
> repository on kernel.org, hosted at,
>
> git://gi
On Thu, Sep 22, 2016 at 09:34:02AM +0100, Matt Fleming wrote:
> On Wed, 21 Sep, at 07:59:51PM, Lukas Wunner wrote:
> > Just curious, are there any plans to integrate the new repo into
> > linux-next? It would be great to have testing as early as possible.
>
> Yes, the exis
On Tue, Sep 20, 2016 at 12:46:30AM +0200, Lukas Wunner wrote:
> On Fri, Sep 16, 2016 at 02:33:55PM +0200, Rafael J. Wysocki wrote:
> > +void device_links_unbind_consumers(struct device *dev)
> > +{
> > + struct device_link *link;
> > + int idx;
>
On Fri, Sep 23, 2016 at 02:49:20PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 20, 2016 10:51:13 AM Marek Szyprowski wrote:
> > On 2016-09-19 23:45, Tobias Jakobi wrote:
> > > I did some tests with the new version today. Sadly the reboot/shutdown
> > > issues are still present.
> >
> >
On Fri, Sep 23, 2016 at 03:42:31PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 20, 2016 12:46:30 AM Lukas Wunner wrote:
> > On Fri, Sep 16, 2016 at 02:33:55PM +0200, Rafael J. Wysocki wrote:
> > > +void device_links_no_driver(struct device *dev)
> > > +{
On Fri, Sep 16, 2016 at 02:33:55PM +0200, Rafael J. Wysocki wrote:
> +void device_links_unbind_consumers(struct device *dev)
> +{
> + struct device_link *link;
> + int idx;
> +
> + start:
> + idx = device_links_read_lock();
> +
> + list_for_each_entry_rcu(link, &dev->links_to_consum
PATCH] Documentation: device links: Add initial documentation
Signed-off-by: Lukas Wunner
---
Documentation/driver-model/device_link.rst | 95 ++
1 file changed, 95 insertions(+)
create mode 100644 Documentation/driver-model/device_link.rst
diff --git a/Documentation/
On Thu, Jul 28, 2016 at 11:15:18AM +0300, Amir Levy wrote:
> +static void nhi_handle_notification_msg(struct tbt_nhi_ctxt *nhi_ctxt,
> + const u8 *msg)
> +{
> + struct port_net_dev *port;
> + u8 port_num;
> +
> +#define INTER_DOMAIN_LINK_SHIFT 0
> +#defin
On Thu, Jul 28, 2016 at 02:30:31AM +0200, Rafael J. Wysocki wrote:
> On Monday, July 25, 2016 12:48:32 AM Lukas Wunner wrote:
> > On Thu, Jul 21, 2016 at 02:25:15AM +0200, Rafael J. Wysocki wrote:
> > > On Thursday, July 21, 2016 01:25:53 AM Lukas Wunner wrote:
> > &
eable on GitHub:
https://github.com/l1k/linux/commits/apple_properties_v2
Thanks,
Lukas
Lukas Wunner (4):
ACPI / bus: Make acpi_get_first_physical_node() public
efi: Add device path parser
x86/efi: Retrieve and assign Apple device properties
thunderbolt: Use Device ROM retrieved from EFI
i_get_first_physical_node() public.
Cc: Aleksey Makarov
Signed-off-by: Lukas Wunner
Acked-by: Rafael J. Wysocki
---
drivers/acpi/internal.h | 1 -
include/linux/acpi.h| 7 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal
(and get_device_by_efi_path() itself is
exported).
The dependency on CONFIG_ACPI is needed for acpi_match_device_ids().
It can be removed if an empty inline stub is added for that function.
Cc: Matt Fleming
Signed-off-by: Lukas Wunner
---
drivers/firmware/efi/Kconfig | 5 +
dr
pdate the
predecessor's ->next link because there's no locking for the list.
The payload is currently not passed on to kexec'ed kernels, same for PCI
ROMs retrieved by setup_efi_pci(). This can be added later if there is
demand by amending setup_efi_state(). The payload can the
ocol, copies it
into the DROM, calculates the CRC and submits the result as a device
property.
Cc: rever...@put.as
Cc: Andreas Noever
Tested-by: Lukas Wunner [MacBookPro9,1]
Tested-by: Pierre Moreau [MacBookPro11,3]
Signed-off-by: Lukas Wunner
---
drivers/thunderbolt/Kconfig | 1 +
driv
no regressions. I'll keep it on my branch and will shout if I do come
across issues over time.
Tested-by: Lukas Wunner
Thanks,
Lukas
On Sun, Sep 11, 2016 at 12:04:36AM +0200, Rafael J. Wysocki wrote:
> On Sat, Sep 10, 2016 at 1:39 PM, Lukas Wunner wrote:
> > On Thu, Sep 08, 2016 at 11:25:44PM +0200, Rafael J. Wysocki wrote:
> >> As discussed in the recent "On-demand device probing" thread and in
On Wed, Sep 14, 2016 at 03:21:27AM +0200, Rafael J. Wysocki wrote:
> On Sunday, September 11, 2016 10:43:36 PM Lukas Wunner wrote:
> > On Sun, Sep 11, 2016 at 03:40:58PM +0200, Lukas Wunner wrote:
> > > On Thu, Sep 08, 2016 at 11:27:45PM +0200, Rafae
On Thu, Aug 04, 2016 at 04:13:45PM +0100, Matt Fleming wrote:
> On Thu, 28 Jul, at 02:25:41AM, Lukas Wunner wrote:
> > diff --git a/arch/x86/boot/compressed/eboot.c
> > b/arch/x86/boot/compressed/eboot.c
> > index ff574da..7262ee4 100644
> > --- a/arch/x86/boot/compre
urce declared in _CRS which contain above
> memory aperture, and Mac OS does not use this pci bridge neither, we
> choose a simple workaround to clear the hotplug flag(suggested by
> Yinghai Lu), thus do not allocate any resource for this pci bridge,
> and thereby no conflict anymore.
>
On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> + :c:func:`dev_pm_set_driver_flags` helper function.] If the first of
> + tese flags is set, the PM core will not apply the direct-complete
^
these
> + proceudre described above to the given device an
u->flags);
> percpu_up_write(&hu->proto_lock);
>
> + cancel_work_sync(&hu->write_work);
> +
Now the work is only cancelled if HCI_UART_PROTO_READY is set,
but that seems fine, so
Reviewed-by: Lukas Wunner
It should be noted that this patch only applies cleanly if Ronald's
other patch is applied before.
t; the read-lock, the percpu variant of rw_semaphore is used.
The percpu_rw_semaphore is unusual (if fine I guess), it's only used
by cgroups, uprobes and ext4 so far and I was unaware of its existence.
I don't have the hardware to test this but the rationale and patch itself
LGTM, so:
Reviewed-by: Lukas Wunner
On Thu, Jun 21, 2018 at 10:21:44PM +0200, Thomas Gleixner wrote:
> On Thu, 24 May 2018, Lukas Wunner wrote:
> > static int irq_wait_for_interrupt(struct irqaction *action)
> > {
> > - set_current_state(TASK_INTERRUPTIBLE);
> > + for (;;) {
> > + set
inadvertantly so because the race is neither mentioned in the
commit message nor was the code comment updated. Make up for that.
Signed-off-by: Lukas Wunner
---
kernel/irq/manage.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/man
e+0xe/0x20
pciehp_unconfigure_device+0xb8/0x160
pciehp_disable_slot+0x84/0x130
pciehp_ist+0x158/0x190
irq_thread_fn+0x1b/0x50
irq_thread+0x143/0x1a0
kthread+0x111/0x130
Cc: Bjorn Helgaas
Cc: Mika Westerberg
Signed-off-by: Lukas Wunner
---
Changes v1 -> v2:
* Add code comment e
On Sun, Jun 24, 2018 at 11:49:10AM +0200, Thomas Gleixner wrote:
> On Sun, 24 Jun 2018, Lukas Wunner wrote:
> > When pciehp is converted to threaded IRQ handling, removal of unplugged
> > devices below a PCIe hotplug port happens synchronously in the IRQ
> > thread. Removal
On Mon, Aug 20, 2018 at 06:06:24PM -0500, Bjorn Helgaas wrote:
> mmyan...@gmail.com reported a problem [1]: on v4.17, a QCA9005 AR9462
> wifi device was present at boot, but disappeared after suspend/resume.
>
> He also tested a recent kernel (5c60a7389d79, from Thu Aug 16),
> where the suspend/re
On Tue, Aug 21, 2018 at 07:47:04AM +0200, Lukas Wunner wrote:
> On Mon, Aug 20, 2018 at 06:06:24PM -0500, Bjorn Helgaas wrote:
> > mmyan...@gmail.com reported a problem [1]: on v4.17, a QCA9005 AR9462
> > wifi device was present at boot, but disappeared after suspend/resume.
&
On Tue, Jul 03, 2018 at 07:30:28AM -0400, ok...@codeaurora.org wrote:
> On 2018-07-03 04:34, Lukas Wunner wrote:
> > On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> > > If a bridge supports hotplug and observes a PCIe fatal error, the
> > > following events
On Tue, Jul 03, 2018 at 06:41:33PM +0530, p...@codeaurora.org wrote:
> pciehp_unconfigure_device doing little more than enumeration to quiescence
> the bus.
>
> /*
>* Ensure that no new Requests will be generated from
>* the device.
>*/
On Fri, Jul 20, 2018 at 07:58:20PM -0700, Sinan Kaya wrote:
> My patch solves the problem if AER interrupt happens before the hotplug
> interrupt. We are masking the data link layer active interrupt. So,
> AER/DPC can perform their link operations without hotplug driver race.
>
> We need to figure
On Fri, Jul 27, 2018 at 03:26:19PM -0500, Bjorn Helgaas wrote:
> The question is where those sysfs files should be. Currently they are
> associated with the device at the *upstream* end of the link. In the
> example above, they're associated with the Root Port:
>
> /sys/devices/pci:00/
On Thu, Jul 12, 2018 at 10:59:46AM -0500, Bjorn Helgaas wrote:
> But on reflection, I think the overall value of this writeup is
> minimal. It's a lot of repetition of things already documented
> elsewhere and most of it boils down to "pay attention to existing
> practice and don't do things diffe
drm_modeset_backoff+0x8a/0x1b0 [drm]
> [ 246.770839] 1 lock held by dmesg/1038:
> [ 246.771739] 2 locks held by zsh/1172:
> [ 246.772650] #0: 836d0438 (&tty->ldisc_sem){}, at:
> ldsem_down_read+0x37/0x40
> [ 246.773680] #1: 1f4f4d48 (&ldata-&g
e for the duration of the connector probe.
Hm, a runtime PM ref is already acquired in nouveau_connector_detect().
I'm wondering why that's not sufficient?
Thanks,
Lukas
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Karol Herbst
> Cc: Lukas Wunner
> Cc: sta...@vger.ke
On Thu, Jul 12, 2018 at 05:21:09PM -0500, Bjorn Helgaas wrote:
> On Sat, Jun 16, 2018 at 09:25:00PM +0200, Lukas Wunner wrote:
> > When pciehp is converted to threaded IRQ handling, removal of unplugged
> > devices below a PCIe hotplug port happens synchronously in the IRQ
> >
On Wed, Jan 24, 2018 at 10:38:22AM +0800, Jia-Ju Bai wrote:
> The function apple_airport_reset is not called in atomic context.
> Thus mdelay can be replaced with usleep_range, to avoid busy wait.
>
> This is reported by a static analysis tool named DCNS written by myself.
No, usleep_range() is b
Dear Greg,
when you refill the patch queue for v4.15 stable one of these days,
please consider adding
commit d73e172816652772114827abaa2dbc053eecbbd7
Author: Lukas Wunner
Date: Fri Nov 17 00:54:53 2017 +0100
Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops
On Fri, Mar 09, 2018 at 05:30:15PM +0800, Kai Heng Feng wrote:
> >On Thursday 08 March 2018 17:10:23 Kai-Heng Feng wrote:
> >>Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option
> >>"Switchable Graphics" (SG).
> >>
> >>When SG is enabled, we have:
> >>00:02.0 VGA compatible contr
On Mon, Mar 12, 2018 at 09:03:16AM -0500, Bjorn Helgaas wrote:
> On Mon, Mar 12, 2018 at 01:04:02AM -0700, Christoph Hellwig wrote:
> > > + * We assume we can manage these PCIe features. Some systems may
> > > + * reserve these for use by the platform itself, e.g., an ACPI BIOS
> > > + * may im
On Mon, Mar 26, 2018 at 09:30:36AM +0200, Takashi Iwai wrote:
> On Mon, 26 Mar 2018 09:03:55 +0200, Subhransu S. Prusty wrote:
> > On Thu, Mar 15, 2018 at 09:02:30PM +0530, Anshuman Gupta wrote:
> > > On Thu, Mar 15, 2018 at 04:12:44PM +0530, Subhransu S. Prusty wrote:
> > > > This driver needs a
On Fri, Apr 06, 2018 at 02:08:32PM +, Luis R. Rodriguez wrote:
> How do you get the GUIDs for each driver BTW?
They're used as filenames when extracting a Firmware Volume with
UEFIExtract.
E.g. let's say I'm looking for the EFI driver containing the UCS-2
string "ThunderboltDROM" in the MacBo
bool raw, bool can_sleep,
Spurious newline. (In v3 this was the place where FASTPATH_NGPIO was
defined, this is a leftover from when you moved it further up.)
I've given this another quick test with gpio-hammer and it worked fine,
so this is still
Reviewed-and-tested-by: Lukas Wunner
Thanks a lot!
Lukas
On Mon, Mar 19, 2018 at 03:48:50PM +, Sasha Levin wrote:
> From: Lukas Wunner
>
> [ Upstream commit 3e81a4ca51a1172253078ca7abd6a91040b8fcf4 ]
>
Unfortunately this commit had to be fixed up with ab2f336cb7e6
("Bluetooth: hci_bcm: Make shutdown and device wake GPIO opt
On Wed, Mar 07, 2018 at 12:13:34AM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system
> resume") added a .resume_noirq() callback to the PCIe port driver to clear
> the PME Status bit during resume to work around a BIOS is
On Thu, Mar 08, 2018 at 05:10:23PM +0800, Kai-Heng Feng wrote:
> Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option
> "Switchable Graphics" (SG).
>
> When SG is enabled, we have:
> 00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
> 00:1f.3 Audio device:
On Thu, Mar 08, 2018 at 06:38:45PM +0800, Kai Heng Feng wrote:
> >On Mar 8, 2018, at 5:38 PM, Lukas Wunner wrote:
> >On Thu, Mar 08, 2018 at 05:10:23PM +0800, Kai-Heng Feng wrote:
> >>Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option
> >
On Fri, Mar 09, 2018 at 08:47:19AM +0100, Ingo Molnar wrote:
> * Ard Biesheuvel wrote:
> > From: Colin Ian King
> >
> > Don't populate the const read-only array 'buf' on the stack but instead
> > make it static. Makes the object code smaller by 64 bytes:
> >
> > Before:
> >textdata
On Wed, Mar 14, 2018 at 12:12:05PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote:
> > On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam
> > wrote:
> > > On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa wrote:
> > >> On Tue, Mar 13, 2018 at 5:55 PM, Vivek
On Wed, Mar 14, 2018 at 12:14:15PM +, Robin Murphy wrote:
> >>On Wed, Mar 14, 2018 at 8:12 PM, Rafael J. Wysocki
> >>wrote:
> >>>On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote:
> On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam
> wrote:
> >On Tue, Mar 13, 2018 at 3:45
On Wed, Sep 26, 2018 at 04:32:41PM -0500, Bjorn Helgaas wrote:
> On Wed, Sep 26, 2018 at 09:52:34AM +0530, Suganath Prabu S wrote:
> > @@ -6853,6 +6872,13 @@ mpt3sas_wait_for_commands_to_complete(struct
> > MPT3SAS_ADAPTER *ioc)
> >
> > ioc->pending_io_count = 0;
> >
> > + if (!mpt3sas_b
On Thu, Sep 27, 2018 at 01:47:46PM -0500, Bjorn Helgaas wrote:
> mpt3sas_wait_for_commands_to_complete(...)
> {
> ...
> + if (!mpt3sas_base_pci_device_is_available(ioc))
> +return;
>
> # In the definitive case, we returned above. If we get here, we
> # think the device *mig
On Thu, Nov 29, 2018 at 06:57:37PM +, alex_gagn...@dellteam.com wrote:
> On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> > On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> >> A warning is generated when a PCIe device is probed with a degraded
> >> link, but there was no simil
On Wed, Nov 14, 2018 at 11:52:25AM +0200, mika.westerb...@linux.intel.com wrote:
> On Tue, Nov 13, 2018 at 03:57:47PM +, Shameerali Kolothum Thodi wrote:
> > > The smb_mb() thing is not that clear (at least to me) because it is used
> > > in two places in the driver and both seem to be making w
On Fri, Jun 29, 2018 at 03:27:39PM -0500, Bjorn Helgaas wrote:
> + - Wrap changelogs to fit in 80 columns when shown by "git show", which
> +adds 4 spaces. I use "textwidth=75" in vim.
I guess the ideal width is subjective, I usually wrap at 72 chars because
then you've got 4 blanks on eithe
On Thu, Jun 28, 2018 at 03:31:05PM -0400, Sinan Kaya wrote:
> +static pci_ers_result_t pciehp_reset_link(struct pci_dev *pdev)
> +{
> + struct pcie_device *pciedev;
> + struct controller *ctrl;
> + struct device *devhp;
> + struct slot *slot;
> + int rc;
> +
> + devhp = pcie
On Fri, Jun 29, 2018 at 03:27:39PM -0500, Bjorn Helgaas wrote:
> --- /dev/null
> +++ b/Documentation/PCI/submitting-patches.txt
> @@ -0,0 +1,153 @@
> +Start with Documentation/process/submitting-patches.rst for general
> +guidance.
> +
> +These are things I look at when reviewing patches.
For an u
On Tue, Jul 03, 2018 at 02:50:40PM +0800, Pingfan Liu wrote:
> commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> places an assumption of supplier<-consumer order on the process of probe.
> But it turns out to break down the parent <- child order in some scene.
> E.g in pci, a b
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> If a bridge supports hotplug and observes a PCIe fatal error, the following
> events happen:
>
> 1. AER driver removes the devices from PCI tree on fatal error
> 2. AER driver brings down the link by issuing a secondary bus reset waits
On Tue, Jul 03, 2018 at 09:31:24AM -0400, Sinan Kaya wrote:
> Issue is observing hotplug link down event in the middle of AER recovery
> as in my previous reply.
>
> If we mask hotplug interrupts before secondary bus reset via my patch,
> then hotplug driver will not observe both link up and link
On Tue, Jul 03, 2018 at 07:30:28AM -0400, ok...@codeaurora.org wrote:
> On 2018-07-03 04:34, Lukas Wunner wrote:
> >On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> >>If a bridge supports hotplug and observes a PCIe fatal error, the
> >>following
> &g
On Tue, Jul 03, 2018 at 07:40:46PM +0530, p...@codeaurora.org wrote:
> On 2018-07-03 19:29, Lukas Wunner wrote:
> >On Tue, Jul 03, 2018 at 09:31:24AM -0400, Sinan Kaya wrote:
> >>Issue is observing hotplug link down event in the middle of AER recovery
> >>as in my pre
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> @@ -308,8 +310,17 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32
> service)
> pci_dev_put(pdev);
> }
>
> + hpsvc = pcie_port_find_service(udev, PCIE_PORT_SERVICE_HP);
> + hpdev = pcie_port_find_dev
On Tue, Jun 26, 2018 at 04:34:20PM -0700, nathan.d.ciob...@linux.intel.com
wrot> Fixes small variable name typo and the associated
> checkpatch spelling warning
>
> Signed-off-by: Nathan Ciobanu
> ---
> drivers/thunderbolt/tb_regs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On Mon, Jun 18, 2018 at 02:07:31PM +0300, Mika Westerberg wrote:
> --- a/drivers/thunderbolt/domain.c
> +++ b/drivers/thunderbolt/domain.c
> @@ -132,6 +133,8 @@ static ssize_t boot_acl_show(struct device *dev, struct
> device_attribute *attr,
> if (!uuids)
> return -ENOMEM;
>
On Sat, Jul 07, 2018 at 05:25:53PM +0300, Mika Westerberg wrote:
> On Sat, Jul 07, 2018 at 03:38:15PM +0200, Lukas Wunner wrote:
> > You're setting pm_runtime_no_callbacks() on the domain. A side effect of
> > setting this flag is that whenever the domain's device is
On Mon, Jun 18, 2018 at 02:07:31PM +0300, Mika Westerberg wrote:
> Implement this using standard Linux runtime PM APIs so that when all the
> children devices are runtime suspended, the Thunderbolt host controller
> PCI device is runtime suspended as well. The ICM firmware then starts
> powering do
On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:
> On 7/3/2018 10:34 AM, Lukas Wunner wrote:
> > We've already got the ->reset_slot callback in struct hotplug_slot_ops,
> > I'm wondering if we really need additional ones for this use case.
>
> A
On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:
> On 7/8/18, Lukas Wunner wrote:
> > On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:
> > > My solution doesn't help if link down interrupt is observed before the
> > > AER
> > > o
e+0xe/0x20
pciehp_unconfigure_device+0xb8/0x160
pciehp_disable_slot+0x84/0x130
pciehp_ist+0x158/0x190
irq_thread_fn+0x1b/0x50
irq_thread+0x143/0x1a0
kthread+0x111/0x130
Cc: Bjorn Helgaas
Cc: Mika Westerberg
Cc: Sebastian Andrzej Siewior
Cc: Thomas Gleixner
Signed-off-by: Lukas Wunner
-
On Fri, May 11, 2018 at 06:43:24AM -0400, Oza Pawandeep wrote:
> +void pcie_do_fatal_recovery(struct pci_dev *dev)
> +{
> + struct pci_dev *udev;
> + struct pci_bus *parent;
> + struct pci_dev *pdev, *temp;
> + pci_ers_result_t result = PCI_ERS_RESULT_RECOVERED;
> + struct aer_b
On Fri, May 11, 2018 at 09:04:36PM +0530, p...@codeaurora.org wrote:
> On 2018-05-11 18:28, Lukas Wunner wrote:
> >On Fri, May 11, 2018 at 06:43:24AM -0400, Oza Pawandeep wrote:
> >>+void pcie_do_fatal_recovery(struct pci_dev *dev)
> >>+{
> >>+ struct p
On Tue, May 08, 2018 at 04:15:47PM +0300, Andy Shevchenko wrote:
> --- a/drivers/firmware/efi/apple-properties.c
> +++ b/drivers/firmware/efi/apple-properties.c
> @@ -13,6 +13,9 @@
> *
> * You should have received a copy of the GNU General Public License
> * along with this program; if not, s
On Mon, May 14, 2018 at 03:48:09PM +0300, Andy Shevchenko wrote:
> On Mon, 2018-05-14 at 14:18 +0200, Lukas Wunner wrote:
> > On Tue, May 08, 2018 at 04:15:47PM +0300, Andy Shevchenko wrote:
> > > --- a/drivers/firmware/efi/apple-properties.c
> > > +++ b/drivers/firm
On Mon, May 14, 2018 at 07:13:24PM +0300, Andy Shevchenko wrote:
> On Mon, 2018-05-14 at 17:40 +0200, Lukas Wunner wrote:
> > On Mon, May 14, 2018 at 03:48:09PM +0300, Andy Shevchenko wrote:
> > > On Mon, 2018-05-14 at 14:18 +0200, Lukas Wunner wrote:
> > > > On T
On Wed, May 30, 2018 at 12:54:15PM -0500, Bjorn Helgaas wrote:
> void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
> {
> - pci_info(dev, "AER: %s%s error received: id=%04x\n",
> + u8 bus = info->id >> 8;
> + u8 devfn = info->id & 0xff;
> +
> + pci_info(dev,
On Fri, Aug 17, 2018 at 11:25:34AM -0500, Bjorn Helgaas wrote:
> The "bind driver, then set dev->added = 1" order seems to have been
> there since the beginning of dev->is_added:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8a1bc9013a03
>
> This patch seems reason
On Mon, Aug 20, 2018 at 12:10:59PM +1000, Benjamin Herrenschmidt wrote:
> I chose to create a new mutex which we should be able to address other
> similar races if we find them. The other solutions that I dismissed
> were:
>
> - Using the device_lock. A explained previously, this is tricky, I
> p
On Fri, Aug 17, 2018 at 11:51:10PM -0700, Sinan Kaya wrote:
> +static int pciehp_control_surprise_error(struct controller *ctrl, bool
> enable)
The return value isn't checked, so this could return void.
> @@ -280,6 +303,9 @@ static int pciehp_probe(struct pcie_device *dev)
>
> pciehp_ch
On Fri, Aug 17, 2018 at 11:51:09PM -0700, Sinan Kaya wrote:
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -222,9 +222,27 @@ void pciehp_handle_disable_request(struct slot *slot)
> void pciehp_handle_presence_or_link_change(struct slot *slot, u32 events)
>
On Mon, Aug 20, 2018 at 12:59:05PM -0400, Sinan Kaya wrote:
> On 8/20/2018 5:22 AM, Lukas Wunner wrote:
> > > +
> > This differs from v7 of the patch in that*any* fatal error, not just
> > a Surprise Link Down, results in pciehp waiting for the error to clear.
> >
On Wed, Dec 19, 2018 at 05:48:17PM +0100, Wolfram Sang wrote:
> +static inline void i2c_mark_adapter_suspended(struct i2c_adapter *adap)
> +{
> + i2c_lock_bus(adap, I2C_LOCK_ROOT_ADAPTER);
> + set_bit(I2C_ALF_IS_SUSPENDED, &adap->locked_flags);
> + i2c_unlock_bus(adap, I2C_LOCK_ROOT_ADA
On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
> This driver depends on the PCI infrastructure but the dependency has not
> been explicitly called out.
>
> Signed-off-by: Sinan Kaya
> Reviewed-by: Lukas Wunner
This series doesn't have a cover letter so it
On Sat, Dec 22, 2018 at 12:14:44AM +, Sinan Kaya wrote:
> This driver depends on the PCI infrastructure but the dependency has not
> been explicitly called out.
>
> Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
> ---
> drivers/gpu/vga/Kconfig | 1 +
> 1 file
On Sat, Dec 22, 2018 at 12:14:47AM +, Sinan Kaya wrote:
> Code is scanning PCI bus to find out if it is switchable or not. If
> CONFIG_PCI is not set, assume unswitchable.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/platform/x86/apple-gmux.c | 4
> 1 file changed, 4 insertions(+)
>
>
On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
> On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
> > On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
> > > This driver depends on the PCI infrastructure but the dependency has not
> > >
be
> specified directly. This driver depends on the PCI infrastructure but
> the dependency has not been explicitly called out.
>
> Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI
> set")
> Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunne
by: Sinan Kaya
Reviewed-by: Lukas Wunner
incrementation of the counter from irq_thread() to
irq_thread_fn() and irq_forced_thread_fn(), before the invocation of
irq_finalize_oneshot().
Fixes: 1e77d0a1ed74 ("genirq: Sanitize spurious interrupt detection of threaded
irqs")
Signed-off-by: Lukas Wunner
Cc: sta...@vger.ker
On Fri, Oct 19, 2018 at 04:31:30PM +0200, Thomas Gleixner wrote:
> On Thu, 18 Oct 2018, Lukas Wunner wrote:
> > Commit 1e77d0a1ed74 ("genirq: Sanitize spurious interrupt detection of
> > threaded irqs") made detection of spurious interrupts work for threaded
&g
Hi Sasha,
On Mon, Sep 17, 2018 at 03:03:19AM +, Sasha Levin wrote:
> From: Lukas Wunner
>
> [ Upstream commit 47a8e237ed443c174f8f73402755c458c56eb611 ]
>
> Thunderbolt controllers can be runtime suspended to D3cold to save ~1.5W.
> This requires that runtime D3 is a
On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote:
> The one change that stands out and merits mention is the code of
> conduct addition...
[...]
> +Scope
> +=
> +
> +This Code of Conduct applies both within project spaces and in public spaces
> +when an individual is representing
On Mon, Sep 17, 2018 at 02:24:30PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 17, 2018 at 01:48:52PM +0200, Lukas Wunner wrote:
> > On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote:
> > > +Scope
> > > +=
> > > +
> > > +This Code
On Mon, Jul 16, 2018 at 07:37:19AM -0500, Bjorn Helgaas wrote:
> On Fri, Jul 13, 2018 at 09:21:09AM +0200, Lukas Wunner wrote:
> > On Thu, Jul 12, 2018 at 05:21:09PM -0500, Bjorn Helgaas wrote:
> > > On Sat, Jun 16, 2018 at 09:25:00PM +0200, Lukas Wunner wrote:
> > > &g
Hi Jirka,
On Thu, Jun 18, 2015 at 09:29:32PM +0200, Jiri Olsa wrote:
> On Thu, Jun 18, 2015 at 01:00:32PM +0200, Lukas Wunner wrote:
> > Invoking Makefile.perf with prefix= breaks the build since Makefile.perf
> > hands that variable down to Makefile.build where it overrides
Hi David,
On Thu, Jun 18, 2015 at 02:26:25PM -0600, David Ahern wrote:
> It worked for me last week with OL6.
> I created a standalone perf rpm with 4.1-rc6; it builds just fine with
> _prefix (rpm variable) set to /usr:
[...]
> %global perf_make \
> make -s -C tools/perf V=1 WERROR=0 NO_LIBUNWI
1 - 100 of 603 matches
Mail list logo
