On Thu, Jan 18, 2018 at 12:20:32PM +0200, Mika Westerberg wrote:
> On Wed, Jan 17, 2018 at 12:53:41PM +0100, Takashi Iwai wrote:
> > Unfortunately we couldn't get approval yet, since it's a prototype
> > machine.
>
> In that case, I think the system itself and its A
On Wed, Jan 17, 2018 at 12:53:41PM +0100, Takashi Iwai wrote:
> Unfortunately we couldn't get approval yet, since it's a prototype
> machine.
In that case, I think the system itself and its ACPI tables should be
fixed if possible. Windows relies on that table as well so unless there
is something t
Signed-off-by: Hans de Goede
Seems like a good way to fix it IMHO,
Acked-by: Mika Westerberg
Hi,
On Fri, Jan 12, 2018 at 04:07:44PM +0100, Sebastian Reichel wrote:
> Hi,
>
> I have an ARM/DT based system [0], that no longer finds its ethernet cards
> behind a PCIe switch. I bisected the problem and ended up on
> a20c7f36bd3d. I tried providing some space using the suggested
> "pci=hpbus
On Wed, Jan 10, 2018 at 04:13:51PM +0100, Takashi Iwai wrote:
> Hi,
>
> on the recent kernels, i2c-i801 skips the creation of iTCO wdt when
> ACPI WDAT is present. It's fine when ACPI really creates the watchdog
> device. But, we've got a report showing that the watchdog is missing
> on some mac
Just to be on the safe side, don't touch the bit. If write access to the
flash chip is needed, the BIOS needs to enable it explicitly.
Signed-off-by: Mika Westerberg
---
drivers/mfd/lpc_ich.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_
On Fri, Dec 22, 2017 at 10:37:32AM +1000, Andrew Cooks wrote:
>
>
> On 21/12/17 22:12, Mika Westerberg wrote:
> > On Thu, Dec 21, 2017 at 11:11:18AM +0100, Linus Walleij wrote:
> >>> In contrast, the pinctrl-amd driver only mentions the newer KERNCZ
> >>>
27;t understand anything of what you just wrote.
> I am basically ignorant when it comes to ACPI details.
>
> So let's CC the GPIO ACPI maintainer, Mika Westerberg.
If the hardware is not the same that is already supported by the
pinctrl-amd, then you definitely should allocate a new s
On Tue, Dec 05, 2017 at 09:52:50AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 05, 2017 at 10:49:13AM +0200, Mika Westerberg wrote:
> > On Fri, Dec 01, 2017 at 03:08:02PM +0300, Mika Westerberg wrote:
> > > Hi Greg,
> > >
> > > Here are two Thunderbolt fixe
M / runtime: Fix handling of suppliers with disabled
> runtime PM".
>
> Signed-off-by: Adrian Hunter
Acked-by: Mika Westerberg
andle(chip->of_node) or dev_fwnode(chip->parent)
> to that function.
>
> Fixes: 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names() to use device
> property accessors")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christophe Leroy
Acked-by: Mika Westerberg
On Fri, Dec 15, 2017 at 09:09:15AM +0100, Christophe Leroy wrote:
> Following commit 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names()
> to use device property accessors"), "gpio-line-names" DT property is
> not retrieved anymore when chip->parent is not set by the driver.
Thanks for taking car
On Tue, Dec 05, 2017 at 11:27:38AM +, Jonathan Cameron wrote:
> Why does it not make sense to just create them all from the ACPI/I2C core?
How do you know in ACPI/I2C core what is the right thing to do? Is it a
single device, like EEPROM with multiple addresses, or is it multiple
completely se
On Thu, Nov 09, 2017 at 02:15:08PM +0300, Mika Westerberg wrote:
> During PCIe surprise hot-unplug the device is not accessible anymore and
> register reads return 0x. When that happens
> pciehp_unconfigure_device()
> may inadvertently think the device below the bridge may
On Fri, Dec 01, 2017 at 03:08:02PM +0300, Mika Westerberg wrote:
> Hi Greg,
>
> Here are two Thunderbolt fixes and one related MAINTAINERS update for the
> next -rc:
>
> - Use shorter path for force_power attribute in thunderbolt.rst
> - Ring interrupts were not masked pro
el: Allow custom GPIO base for pad groups")
> Signed-off-by: Colin Ian King
Acked-by: Mika Westerberg
On Mon, Dec 04, 2017 at 11:29:31AM +0100, Hans de Goede wrote:
> i2c_new_secondary_device() is for a different purpose, this is for when
> a single i2c device listens on multiple addresses and the driver wants
> separate i2c_client-s to use to talk to each address.
>
> In this case there are 2 sep
On Sat, Dec 02, 2017 at 12:19:27PM +, Jonathan Cameron wrote:
> On Wed, 29 Nov 2017 22:31:12 +
> Jeremy Cline wrote:
>
> > Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI
> > device. Check for a companion device and handle a second i2c_client
> > if it is present.
From: Andy Shevchenko
WMI is the bus inside kernel, so, we may access the GUID via
/sys/bus/wmi instead of doing this through /sys/devices path.
Signed-off-by: Andy Shevchenko
Acked-by: Mario Limonciello
Signed-off-by: Mika Westerberg
---
Documentation/admin-guide/thunderbolt.rst | 2 +-
1
rings")
Signed-off-by: Mika Westerberg
Acked-by: Yehezkel Bernat
---
drivers/thunderbolt/nhi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 419a7a90bce0..f45bcbc63738 100644
--- a/drivers/thunderbolt/nhi.c
+++
Make sure Thunderbolt maintainers get to see patches that touch
documentation of the Thunderbolt driver as well.
Signed-off-by: Mika Westerberg
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..478e4d342c2a 100644
--- a/MAINTAINERS
!
Andy Shevchenko (1):
thunderbolt: Make pathname to force_power shorter
Mika Westerberg (2):
MAINTAINERS: Add thunderbolt.rst to the Thunderbolt driver entry
thunderbolt: Mask ring interrupt properly when polling starts
Documentation/admin-guide/thunderbolt.rst | 2 +-
MAINTAINERS
On Mon, Nov 27, 2017 at 02:48:57PM +0300, Mika Westerberg wrote:
> Make sure Thunderbolt maintainers get to see patches that touch
> documentation of the Thunderbolt driver as well.
>
> Signed-off-by: Mika Westerberg
Applied.
pport")
Reported-by: Daniel Drake
Reported-and-tested-by: Chris Chiu
Signed-off-by: Mika Westerberg
Cc: sta...@vger.kernel.org
---
Changes from v1:
* Renamed __intel_gpio_init_gpio() to intel_gpio_set_gpio_mode()
* Added Fixes: and Cc sta...@vger.kernel.org
* Added Tested-by from Chris Chiu
On Wed, Nov 29, 2017 at 01:39:00PM +0100, Linus Walleij wrote:
> On Mon, Nov 20, 2017 at 4:19 PM, Mika Westerberg
> wrote:
>
> > When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
> > switches the pin to GPIO mode and makes sure interrupts are r
On Wed, Nov 29, 2017 at 01:49:01PM +0100, Linus Walleij wrote:
> On Mon, Nov 27, 2017 at 2:54 PM, Mika Westerberg
> wrote:
>
> > It turns out that the Cannon Lake GPIO driver in Windows uses different
> > GPIO numbering scheme than what Linux uses. Instead of hardware numb
f-by: Arvind Yadav
Acked-by: Mika Westerberg
Let's limit the DMI quirks that try to preserve virtual IRQ
> numbers on Strago boards to those that still carry BIOSes 1.0.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197953
> Signed-off-by: Dmitry Torokhov
Acked-by: Mika Westerberg
Assuming there is no versio
f-by: Arvind Yadav
Acked-by: Mika Westerberg
f-by: Arvind Yadav
You may want to change the title to mention the PMIC driver in question
like: "ACPI / PMIC / bxtwc: ..." or so.
The patch itself is fine,
Acked-by: Mika Westerberg
mbering to follow the Windows GPIO
driver numbering taking advantage of the gpio_base field introduced in
the previous patch.
Signed-off-by: Mika Westerberg
---
drivers/pinctrl/intel/pinctrl-cannonlake.c | 65 --
1 file changed, 34 insertions(+), 31 deletions(-)
di
a new field (gpio_base) to the pad group structure
and update the core Intel pinctrl driver to handle this accordingly.
Passing 0 as gpio_base will use direct mapping so the existing drivers
do not need to be modified. Passing -1 excludes the whole pad group from
having GPIO mapping.
Signed-off-by:
he Windows GPIO driver numbering scheme.
Mika Westerberg (3):
gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation
pinctrl: intel: Allow custom GPIO base for pad groups
pinctrl: cannonlake: Align GPIO number space with Windows
drivers/gpio/gpiolib-acpi.c
s exactly same than the hardware pin 81 (SDMMC3_CD_B).
As an added bonus this simplifies both the ACPI GPIO core code and the
Cherryview pinctrl driver.
Signed-off-by: Mika Westerberg
---
drivers/gpio/gpiolib-acpi.c| 75 +-
drivers/pinctrl/intel/pinctrl-
Make sure Thunderbolt maintainers get to see patches that touch
documentation of the Thunderbolt driver as well.
Signed-off-by: Mika Westerberg
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..478e4d342c2a 100644
--- a/MAINTAINERS
rings")
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/nhi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 419a7a90bce0..f45bcbc63738 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
On Sat, Nov 25, 2017 at 02:00:34PM +, Jonathan Cameron wrote:
> > There does not seem to be any way in ACPI to tell which "connection" is
> > used to describe ARA so that part currently is something each driver
> > needs to handle as they know the device the best. I don't think we have
> > any
ially allocated
and unmap them when the interface is brought down. In between we just
DMA sync the buffers for the CPU or device as needed.
Signed-off-by: Mika Westerberg
---
drivers/net/thunderbolt.c | 57 ---
1 file changed, 24 insertions(+), 33 del
On Thu, Nov 23, 2017 at 08:24:05PM +0800, Chris Chiu wrote:
> Thanks for your confirmation. I've pushed this back to ASUS. They told me
> there's a new official BIOS released, of course they don't know
> whether if it helps
> or not. I then upgraded it and the problem is gone. So it's truly a
> BIO
On Tue, Nov 21, 2017 at 07:54:26PM +0800, Chris Chiu wrote:
> Yup, I checked the value of the corresponded pin. It shows following before
> suspend
> pin 18 (GPIO_18) GPIO 0x40800102 0x00024075
>
> Then after resume
> pin 18 (GPIO_18) GPIO 0x40800102 0x00024075 [ACPI]
OK, so ownership is changed
On Fri, Nov 17, 2017 at 04:11:31PM +0800, Chris Chiu wrote:
> On Fri, Nov 17, 2017 at 2:49 PM, Mika Westerberg
> wrote:
> > On Thu, Nov 16, 2017 at 09:27:51PM +0800, Chris Chiu wrote:
> >> On Thu, Nov 16, 2017 at 8:44 PM, Mika Westerberg
> >> wrote:
> >&g
like interrupts suddenly stop firing completely and the touchpad stops
responding to user input.
Fix this by properly initializing the pin to GPIO mode also when it is
used directly through irqchip.
Reported-by: Daniel Drake
Reported-by: Chris Chiu
Signed-off-by: Mika Westerberg
---
Chris
+Jarkko
On Sun, Nov 19, 2017 at 04:35:51PM +, Jonathan Cameron wrote:
> On Thu, 2 Nov 2017 16:04:07 +0100
> Wolfram Sang wrote:
>
> > On Thu, Nov 02, 2017 at 02:35:50PM +, Jonathan Cameron wrote:
> > > On Fri, 27 Oct 2017 18:27:02 +0200
> > > Marc CAPDEVILLE wrote:
> > >
> > > > On a
On Mon, Nov 20, 2017 at 01:18:51PM +0800, Chris Chiu wrote:
> On Fri, Nov 17, 2017 at 9:52 PM, Mika Westerberg
> wrote:
> > On Fri, Nov 17, 2017 at 03:35:18PM +0200, Mika Westerberg wrote:
> >> > pin 18 (GPIO_18) GPIO 0x40900100 0x00024075
> >
> > Hmm,
>
On Fri, Nov 17, 2017 at 03:35:18PM +0200, Mika Westerberg wrote:
> > pin 18 (GPIO_18) GPIO 0x40900100 0x00024075
Hmm,
If I decode 0x40900100 correctly PADCFG0_GPIROUTIOXAPIC (BIT 20) flag is
set for the pin. This means the interrupt is routed to IO-APIC instead.
Now, we do clear that flag
On Fri, Nov 17, 2017 at 09:21:48PM +0800, Chris Chiu wrote:
> On Fri, Nov 17, 2017 at 7:00 PM, Mika Westerberg
> wrote:
> > On Fri, Nov 17, 2017 at 06:01:27PM +0800, Chris Chiu wrote:
> >> Hi Mika,
> >> Here's the full dmesg log you need. The touchpad sto
On Fri, Nov 17, 2017 at 06:01:27PM +0800, Chris Chiu wrote:
> Hi Mika,
> Here's the full dmesg log you need. The touchpad stop reporting at
> the last of the log.
> https://gist.github.com/mschiu77/a0b8d24a586a228c55eca30c87c71d41
Thanks!
I did not spot anything suspicious in the i2c-hid init
On Fri, Nov 17, 2017 at 04:27:39PM +0800, Chris Chiu wrote:
> On Thu, Nov 16, 2017 at 9:07 PM, Mika Westerberg
> wrote:
> > On Thu, Nov 16, 2017 at 12:01:24PM +, Daniel Drake wrote:
> >> On Thu, Nov 16, 2017 at 11:52 AM, Mika Westerberg
> >> wrote:
> >&g
On Thu, Nov 16, 2017 at 09:27:51PM +0800, Chris Chiu wrote:
> On Thu, Nov 16, 2017 at 8:44 PM, Mika Westerberg
> wrote:
> > On Wed, Nov 15, 2017 at 06:19:56PM +0800, Chris Chiu wrote:
> >> Hi Mika,
> >> I've confirmed with Asus and they said it's the la
On Wed, Nov 15, 2017 at 04:08:32PM +0800, Chris Chiu wrote:
> Yes, that’s the most weird part.
Sounds pretty much like a BIOS issue. Do you know if there is a newer
BIOS and have you tried that already?
On Thu, Nov 16, 2017 at 12:01:24PM +, Daniel Drake wrote:
> On Thu, Nov 16, 2017 at 11:52 AM, Mika Westerberg
> wrote:
> > Please first check the signal with some analyzator if it works as
> > expected and let's then figure out what needs to be fixed and where ;-)
&
On Wed, Nov 15, 2017 at 06:19:56PM +0800, Chris Chiu wrote:
> Hi Mika,
> I've confirmed with Asus and they said it's the latest BIOS for
> shipment and verified OK on Windows. So their BIOS team will not do
> anything for this.
I'll ask around if our Windows people know anything about this. My
On Thu, Nov 16, 2017 at 11:38:33AM +, Daniel Drake wrote:
> Hi,
>
> We have 2 new laptop samples which use ACPI GpioInt for the I2C-HID
> touchpad interrupt (via intel-gpio) and both models face different
> issues related to this interrupt, which is level-triggered active low
> (as defined by
think it makes sense to drop
the whole PCI_BRIDGE_CONTROL check from pciehp_unconfigure_device().
While there do the same for shpchp_configure_device() based on the same
reasoning and the fact that the same bug might trigger in standard PCI
hotplug as well.
Signed-off-by: Mika Westerberg
---
The
On Mon, Nov 06, 2017 at 05:14:09PM -0600, Bjorn Helgaas wrote:
> As you mention, shpchp_unconfigure_device() contains the same code; is
> there any reason not to remove it from there as well?
I don't see why we cannot remove that as well. But I have to admit that
I don't know much about convention
On Fri, Nov 03, 2017 at 04:03:48PM +0100, Bhumika Goyal wrote:
> Make these structures as const as they are only passed to the function
> intel_pmic_install_opregion_handler having the argument as const.
>
> Signed-off-by: Bhumika Goyal
Acked-by: Mika Westerberg
On Fri, Nov 03, 2017 at 04:03:47PM +0100, Bhumika Goyal wrote:
> Make some pointers of type intel_pmic_opregion_data as const as they
> do not modify the fields of the structure they point too.
> After this change, make the data field of intel_pmic_opregion
> structure const as this data field is u
I will be gathering Thunderbolt related patches to this git tree with
help of other Thunderbolt maintainers.
Signed-off-by: Mika Westerberg
---
Hi Andreas and Greg,
If you are fine, I can pick up Thunderbolt related patches to this tree and
then forward them to Greg via pull requests or patch
and connection
> manager")
> Signed-off-by: Gustavo A. R. Silva
Good catch!
Acked-by: Mika Westerberg
Greg, can you pick this to your char-misc tree? Thanks.
> ---
> drivers/thunderbolt/tb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/thunderb
On Tue, Oct 31, 2017 at 10:45:46PM +0100, Stephen Hemminger wrote:
> The thunderbolt driver needs to stop logging.
> All these debug messages and the laptop is on battery with no devices
> connected.
> (I did use a USB key, but that is not a thunderbolt device).
>
> IMHO a production driver shoul
On Mon, Oct 30, 2017 at 03:28:46PM -0700, sathyanarayanan kuppuswamy wrote:
> Hi,
>
>
> On 10/30/2017 03:58 AM, Cyrille Pitchen wrote:
> > Applied to the spi-nor/next branch of l2-mtd
> >
> > Just for info, this patch didn't apply directly, it misses a line in the
> > list of
> > PCI IDS:
> >
On Sun, Oct 29, 2017 at 03:17:35PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> This patch adds Intel Lewisburg PCH SPI serial flash controller super
> SKU PCI ID.
>
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
Acked-by: Mika Westerberg
On Sun, Oct 29, 2017 at 12:18:28PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> Mika, Shall I re-base this patch to add super SKU ID?
Yes, please.
On Sun, Oct 29, 2017 at 11:09:50AM +0100, Marek Vasut wrote:
> On 10/29/2017 10:57 AM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > From: Kuppuswamy Sathyanarayanan
> >
> >
> > This patch adds PCI IDs for Intel Lewisburg PCH SPI serial flash controller.
> >
> > Signed-off-by: Kuppuswam
is what this patch does.
Signed-off-by: Mika Westerberg
---
The previous version of the patch can be found here:
https://patchwork.kernel.org/patch/10024145/
Changes from the previous version:
* Drop the whole PCI_BRIDGE_CONTROL check
* Update patch subject to reflect that
drivers/pci
k to macOS again, fix this so that we drop the
whole sequence number check. This effectively works exactly the same
than it worked before the aforementioned commit. This also follows the
logic the original P2P networking code used.
Signed-off-by: Mika Westerberg
---
This applies on top of net-next.
read bctl value against 0x
(device is not present anymore) before determining whether the device is
a display or not.
Signed-off-by: Mika Westerberg
---
Hi Bjorn,
This is an updated version of the patch 8/8 in my "PCI: Improvements for
native PCIe hotplug" patch series and applies
superfluous hence remove it.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Bin Meng
Acked-by: Mika Westerberg
On Mon, Oct 23, 2017 at 11:59:39PM -0700, Bin Meng wrote:
> The Intel SPI-NOR driver is dependent on LPC_ICH to get the platform
> data. Select it in the Kconfig.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - Enforce dependency on PCI
>
> drivers/mtd/spi-nor/Kconfig | 3 ++-
> 1
Intel Cedar Fork PCH is the successor of Intel Denverton PCH but it is
based on the newer GPIO/pinctrl hardware block. Add a new pinctrl/GPIO
driver to support it.
Signed-off-by: Mika Westerberg
---
drivers/pinctrl/intel/Kconfig | 8 +
drivers/pinctrl/intel/Makefile
Some GPIO blocks have the interrupt status (GPI_IS) offset different
than it normally is, so make it configurable. If no offset is specified
we use the default.
While there remove two unused constants from the core driver.
Signed-off-by: Mika Westerberg
---
drivers/pinctrl/intel/pinctrl
On Sun, Oct 15, 2017 at 09:38:57PM +0800, Bin Meng wrote:
> > Also, the 'depends on EXPERT' statement looks misplaced,
> > enabling EXPERT should only be there to allow you to turn
> > extra things *off*, not to hide device drivers.
> >
>
> I will leave this to Mika to comment the "EXPERT" usage.
On Fri, Oct 20, 2017 at 04:15:02PM -0500, Bjorn Helgaas wrote:
> > +
> > + /* Check if the device is really there anymore */
> > + present = presence ? pci_device_is_present(dev) : false;
> > +
> > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE && present) {
> >
igned-off-by: Joakim Tjernlund
> > ---
> > drivers/mfd/lpc_ich.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> Looks perfectly reasonable to me. Would be good to receive a nod from
> one of the Intel or Extreme Engineering guys though.
Acked-by: Mika Westerberg
* Add another separate loop to count number of hotplug and normal bridges
* Reword comment about two scans
* Generalize patches 4 and 5 so that they could work also on conventional
PCI by dropping tests for PCIe.
Mika Westerberg (8):
PCI: Move pci_hp_add_bridge() to drivers/pci/prob
There is not much point of having a file with a single function in it.
Instead we can just move pci_hp_add_bridge() to drivers/pci/probe.c and
make it available always when PCI core is enabled.
Signed-off-by: Mika Westerberg
---
drivers/pci/Makefile | 3 ---
drivers/pci/hotplug-pci.c | 29
later on.
While there update kernel docs of the affected functions.
Signed-off-by: Mika Westerberg
---
drivers/pci/probe.c | 156 ++--
1 file changed, 138 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index
ned-off-by: Mika Westerberg
---
drivers/pci/probe.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 7302cef51d3f..107052f1dad9 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2398,7 +239
ports are too small.
Here we follow what we already did for bus number and assign all
available extra resources to hotplug capable bridges. This makes it
possible to extend the hierarchy later.
Signed-off-by: Mika Westerberg
---
drivers/pci/setup-bus.c | 177
calling pci_device_is_present()
for it before we touch it any further.
Signed-off-by: Mika Westerberg
---
drivers/pci/hotplug/pciehp_pci.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index
untouched during initialization. Then once the event is unmasked we get
an interrupt and handle the hotplug event properly.
Signed-off-by: Mika Westerberg
---
drivers/pci/hotplug/pciehp_hpc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/hotplug
max=40
pci_bus :08: busn_res: [bus 08-ff] end is updated to 40
Instead of allowing this we limit the subordinate number to be less than
or equal the maximum subordinate number allocated for the parent bus (if
it has any).
Signed-off-by: Mika Westerberg
---
drivers/pci/probe.c | 7 ++-
1
instead to avoid scaring users.
This is based on the original work by Ashok Raj.
Link: https://patchwork.kernel.org/patch/9469023
Suggested-by: Bjorn Helgaas
Signed-off-by: Mika Westerberg
---
drivers/pci/hotplug/pciehp_ctrl.c | 7 ---
drivers/pci/hotplug/pciehp_hpc.c | 2 +-
drivers/pci
On Fri, Oct 13, 2017 at 02:29:59PM +0300, Dan Carpenter wrote:
> The problematic code looks like this:
>
> res_seq = res_hdr->xd_hdr.length_sn & TB_XDOMAIN_SN_MASK;
> res_seq >>= TB_XDOMAIN_SN_SHIFT;
>
> TB_XDOMAIN_SN_SHIFT is 27, and right shifting a u8 27 bits is always
> going to r
On Thu, Oct 12, 2017 at 01:32:23PM -0500, Bjorn Helgaas wrote:
> On Thu, Oct 12, 2017 at 03:47:03PM +0300, Mika Westerberg wrote:
> > On Wed, Oct 11, 2017 at 06:32:43PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Sep 26, 2017 at 05:17:16PM +0300, Mika Westerberg wrote:
> > &
end if they can
> generate wakeup signals, so drop it.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
On Wed, Oct 11, 2017 at 06:32:43PM -0500, Bjorn Helgaas wrote:
> On Tue, Sep 26, 2017 at 05:17:16PM +0300, Mika Westerberg wrote:
> > System BIOS sometimes allocates extra bus space for hotplug capable PCIe
> > root/downstream ports. This space is needed if the device plugged to th
On Mon, Oct 09, 2017 at 04:18:10PM -0700, Darren Hart wrote:
> I'm not sure how we would deal with it in the trees. Best to note this during
> the merge window - whichever goes in second. Test merge will identify the
> merge
> conflict, and we can include a note to Linus on the preference.
That
On Mon, Oct 09, 2017 at 06:56:33PM +0100, Mark Brown wrote:
> +Networking over Thunderbolt cable
> +-
> +Thunderbolt technology allows software communication across two hosts
> +connected by a Thunderbolt cable.
> +
> +It is possible to tunnel any kind of traff
safe side also add a check for
properly initialized xdomain_property_dir to tb_register_property_dir().
Reported-by: kernel test robot
Signed-off-by: Mika Westerberg
---
Hi David,
This fixes a crash introduced in the Thunderbolt networking patches, so I'm
wondering could you take this to
On Tue, Sep 26, 2017 at 05:17:13PM +0300, Mika Westerberg wrote:
> Hi,
>
> Currently when plugging PCIe device using native PCIe hotplug Linux PCI
> core tries to allocate bus space and resources so that the newly enumerated
> topology barely fits there. Now, if the PCIe topolog
On Wed, Oct 04, 2017 at 09:42:49AM +0300, Mika Westerberg wrote:
> On Tue, Oct 03, 2017 at 12:00:49PM -0500, Grygorii Strashko wrote:
> > New GPIO IRQs are allocated and mapped dynamically by default when
> > GPIO IRQ infrastructure is used by cherryview-pinctrl driver.
> >
On Wed, Oct 04, 2017 at 12:07:34PM -0400, Chris Gorman wrote:
> Tested-by: Chris Gorman
I guess you sent this because of the "Tested-by", right? It is enough if
you reply to the original thread (the one posted by Grygorii yesterday)
and say something like:
Works for me,
Tested-by: ...
Then
ml/2017/9/28/153
> Cc: Andy Shevchenko
> Cc: Chris Gorman
> Cc: Mika Westerberg
> Cc: Heikki Krogerus
> Signed-off-by: Grygorii Strashko
> Reported-by: Chris Gorman
> Reported-by: Mika Westerberg
Looks reasonable to me. Thanks for taking care of this!
Chris, can you try if this fixes the issue and provide your Tested-by?
On Tue, Oct 03, 2017 at 08:54:30PM +0300, Andy Shevchenko wrote:
> I'm not sure about this approach. It might be some other broken BIOS
> discovered with some other driver (like pinctrl-baytrail.c as an
> hypothetical example).
Let's deal that separately if it ever happens.
> Alternative is to de
This makes it possible to enqueue frames also from atomic context which
is needed for example, when networking packets are sent over a
Thunderbolt cable.
Signed-off-by: Mika Westerberg
Reviewed-by: Michael Jamet
Reviewed-by: Yehezkel Bernat
Reviewed-by: Andy Shevchenko
---
drivers
These messages are all 32-byte aligned and they should be packed without
the __packed attribute just fine. It also allows compiler to generate
better code on some architectures.
Signed-off-by: Mika Westerberg
Reviewed-by: Michael Jamet
Reviewed-by: Yehezkel Bernat
---
drivers/thunderbolt
have
the networking service enabled by default). For Linux to Linux connection
one host needs to load the networking driver first (so that the other side
can locate the networking service and load the corresponding driver).
Amir Levy (1):
net: Add support for networking over Thunderbolt cable
Mika
This will keep the interrupt delivery rate reasonable. The value used
here (128 us) is a recommendation from the hardware people.
This code is based on the work done by Amir Levy and Michael Jamet.
Signed-off-by: Michael Jamet
Signed-off-by: Mika Westerberg
Reviewed-by: Yehezkel Bernat
used for
this purpose.
This code is based on the work done by Amir Levy and Michael Jamet.
Signed-off-by: Michael Jamet
Signed-off-by: Mika Westerberg
Reviewed-by: Yehezkel Bernat
Reviewed-by: Andy Shevchenko
---
drivers/thunderbolt/ctl.c | 3 +-
drivers/thunderbolt/nhi.c | 76
801 - 900 of 2791 matches
Mail list logo
