Re: [PATCH 5/5] MAINTAINERS: Add Lukas Wunner as co-maintainer of thunderbolt

[Andreas Noever]

On Thu, Sep 13, 2018 at 11:00 AM Mika Westerberg
 wrote:
>
> On Mon, Sep 10, 2018 at 12:33:33PM +0300, Mika Westerberg wrote:
> > Hi Lukas,
> >
> > I'm including Greg here in case I've done something wrong as a maintainer.
> > Since I've only maintained Thunderbolt quite short time, it may be that
> > I've done mistakes but certainly I did not deliberately try to make life of
> > people developing this for older Apple systems harder.
>
> Greg did not yell at me (yet) so I guess I'm doing OK :)
>
> > On Sun, Sep 09, 2018 at 11:42:01PM +0200, Lukas Wunner wrote:
> > > Andreas Noever has let it be known off-list already a while ago that he
> > > currently cannot spare as much time for Thunderbolt development as he'd
> > > like.  As a result the driver's development has become dominated by
> > > Intel.
> >
> > I was not aware of this. Althought Andreas has not commented much
> > lately, I thought he is still looking after our changes. I hope he still
> > is :)
> >
> > > I would like to step up as co-maintainer to provide additional checks
> > > and balances and prevent the driver from degenerating into an Intel-only
> > > show.  A number of things really irk me:
> >
> > I don't have anything against this but at the same time I'm afraid it
> > might lead to a situation where the Thunderbolt driver evolution gets
> > stopped into its tracks because of unnecessary fighting over each patch
> > and change which does not benefit Linux kernel in general.
>
> I think we have enough maintainers in this subsystem:
As mentioned by Lukas I'm currently quite preoccupied with other commitments
and have not done much more than skimming the incoming patches (especially
those touching the Intel part - as I trust you know what you are doing there :))
If there is concern over too many maintainers then please give my spot to Lukas.
Since I no longer use my MacBook regularly my ability to effectively
test stuff is
quite limited anyways.

Thanks,
Andreas


>   Andreas - Apple hardware
>   Michael and me - Intel
>   Yehezkel - Microsoft
>
> But I think we can make you a dedicated reviewer. This should make sure
> you get to review all the patches touching this subsystem.
>
> However, first I would like to get confirmation from Andreas that he
> approves this.
Signed-off-by: Andreas Noever 

>
> I also would like that anyone submitting patches to this subsystem do
> not get bad feelings during the review but instead possible issues and
> improvement suggestions are written in such way that the submitter feels
> his work is valued (even if not always correct).
>
> This is especially important when a random Intel (well, or Apple)
> engineer submits a patch, say fixing a typo in a comment of some data
> structure. There is no point starting to demand that the specific
> register meaning needs to be disclosed. I've said this before but I or
> any other Intel engineer do not have any power over when the spec is
> released or any other related matter (like disclosing registers) and I
> really don't want that every single patch review starts with demanding
> people to disclose something extra. After all they are just trying to
> improve the driver which is good for Linux.
>
> If Andreas approves this, please send a patch adding you as a reviewer
> and I'll apply it. Just please write the changelog in good will without
> any personal frustration as those will be recorded forever in the kernel
> history and you never know in future who you are working for.
>
> From my point of view, I welcome you on board as good reviewer :)

Re: [PATCH 5/5] MAINTAINERS: Add Lukas Wunner as co-maintainer of thunderbolt

[Andreas Noever]

On Thu, Sep 13, 2018 at 11:00 AM Mika Westerberg
 wrote:
>
> On Mon, Sep 10, 2018 at 12:33:33PM +0300, Mika Westerberg wrote:
> > Hi Lukas,
> >
> > I'm including Greg here in case I've done something wrong as a maintainer.
> > Since I've only maintained Thunderbolt quite short time, it may be that
> > I've done mistakes but certainly I did not deliberately try to make life of
> > people developing this for older Apple systems harder.
>
> Greg did not yell at me (yet) so I guess I'm doing OK :)
>
> > On Sun, Sep 09, 2018 at 11:42:01PM +0200, Lukas Wunner wrote:
> > > Andreas Noever has let it be known off-list already a while ago that he
> > > currently cannot spare as much time for Thunderbolt development as he'd
> > > like.  As a result the driver's development has become dominated by
> > > Intel.
> >
> > I was not aware of this. Althought Andreas has not commented much
> > lately, I thought he is still looking after our changes. I hope he still
> > is :)
> >
> > > I would like to step up as co-maintainer to provide additional checks
> > > and balances and prevent the driver from degenerating into an Intel-only
> > > show.  A number of things really irk me:
> >
> > I don't have anything against this but at the same time I'm afraid it
> > might lead to a situation where the Thunderbolt driver evolution gets
> > stopped into its tracks because of unnecessary fighting over each patch
> > and change which does not benefit Linux kernel in general.
>
> I think we have enough maintainers in this subsystem:
As mentioned by Lukas I'm currently quite preoccupied with other commitments
and have not done much more than skimming the incoming patches (especially
those touching the Intel part - as I trust you know what you are doing there :))
If there is concern over too many maintainers then please give my spot to Lukas.
Since I no longer use my MacBook regularly my ability to effectively
test stuff is
quite limited anyways.

Thanks,
Andreas


>   Andreas - Apple hardware
>   Michael and me - Intel
>   Yehezkel - Microsoft
>
> But I think we can make you a dedicated reviewer. This should make sure
> you get to review all the patches touching this subsystem.
>
> However, first I would like to get confirmation from Andreas that he
> approves this.
Signed-off-by: Andreas Noever 

>
> I also would like that anyone submitting patches to this subsystem do
> not get bad feelings during the review but instead possible issues and
> improvement suggestions are written in such way that the submitter feels
> his work is valued (even if not always correct).
>
> This is especially important when a random Intel (well, or Apple)
> engineer submits a patch, say fixing a typo in a comment of some data
> structure. There is no point starting to demand that the specific
> register meaning needs to be disclosed. I've said this before but I or
> any other Intel engineer do not have any power over when the spec is
> released or any other related matter (like disclosing registers) and I
> really don't want that every single patch review starts with demanding
> people to disclose something extra. After all they are just trying to
> improve the driver which is good for Linux.
>
> If Andreas approves this, please send a patch adding you as a reviewer
> and I'll apply it. Just please write the changelog in good will without
> any personal frustration as those will be recorded forever in the kernel
> history and you never know in future who you are working for.
>
> From my point of view, I welcome you on board as good reviewer :)

Re: Excessive logging in thunderbolt driver

[Andreas Noever]

On Wed, Nov 1, 2017 at 8:41 AM, Mika Westerberg
 wrote:
> 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 should log nothing in normal operation.
>> If you insist, the one message when device is found on discovery/probe
>> is allowed at INFO level.
>>
>> All the rest should just go away, or be turned into pr_debug().
>
> I agree and it is on my todo list for this driver.

Logging all the details was quite useful in the beginning to make the
driver work on hardware that was not available to me. But now that
thinks are mostly working I agree that we should turn the logging way
down.

Re: Excessive logging in thunderbolt driver

[Andreas Noever]

On Wed, Nov 1, 2017 at 8:41 AM, Mika Westerberg
 wrote:
> 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 should log nothing in normal operation.
>> If you insist, the one message when device is found on discovery/probe
>> is allowed at INFO level.
>>
>> All the rest should just go away, or be turned into pr_debug().
>
> I agree and it is on my todo list for this driver.

Logging all the details was quite useful in the beginning to make the
driver work on hardware that was not available to me. But now that
thinks are mostly working I agree that we should turn the logging way
down.

Re: [PATCH] MAINTAINERS: Add git tree for Thunderbolt development

[Andreas Noever]

On Mon, Nov 6, 2017 at 6:12 PM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> I will be gathering Thunderbolt related patches to this git tree with
> help of other Thunderbolt maintainers.
>
> Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
> ---
> 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 series (whichever is
> preferred)

Fine for me!

Acked-by: Andreas Noever <andreas.noe...@gmail.com>


>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9729ebe4eb12..0446aa288828 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13299,6 +13299,7 @@ M:  Andreas Noever <andreas.noe...@gmail.com>
>  M: Michael Jamet <michael.ja...@intel.com>
>  M: Mika Westerberg <mika.westerb...@linux.intel.com>
>  M: Yehezkel Bernat <yehezkel.ber...@intel.com>
> +T: git 
> git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git
>  S: Maintained
>  F: drivers/thunderbolt/
>  F: include/linux/thunderbolt.h
> --
> 2.14.2
>

Re: [PATCH] MAINTAINERS: Add git tree for Thunderbolt development

[Andreas Noever]

On Mon, Nov 6, 2017 at 6:12 PM, Mika Westerberg
 wrote:
> 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 series (whichever is
> preferred)

Fine for me!

Acked-by: Andreas Noever 


>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9729ebe4eb12..0446aa288828 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13299,6 +13299,7 @@ M:  Andreas Noever 
>  M: Michael Jamet 
>  M: Mika Westerberg 
>  M: Yehezkel Bernat 
> +T: git 
> git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git
>  S: Maintained
>  F: drivers/thunderbolt/
>  F: include/linux/thunderbolt.h
> --
> 2.14.2
>

Re: [PATCH] thunderbolt: Correct access permissions for active NVM contents

[Andreas Noever]

On Thu, Jun 29, 2017 at 9:19 PM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> Firmware upgrade tools that decide which NVM image should be uploaded to
> the Thunderbolt controller need to access active parts of the NVM even
> if they are not run as root. The information in active NVM is not
> considered security critical so we can use the default permissions set
> by the NVMem framework.
>
> Writing the NVM image is still left as root only operation.
>
> While there mark the active NVM as read-only in the filesystem.
>
> Reported-by: Yehezkel Bernat <yehezkel.ber...@intel.com>
> Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>

Sorry for the late reply (I'm on vacation :P).

Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>

> ---
> Hi,
>
> This applies on top of my Thunderbolt patches in Greg's char-misc-next
> branch.
>
> Thanks.
>
>  drivers/thunderbolt/switch.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index ab3e8f410444..40219a706309 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -281,9 +281,11 @@ static struct nvmem_device *register_nvmem(struct 
> tb_switch *sw, int id,
> if (active) {
> config.name = "nvm_active";
> config.reg_read = tb_switch_nvm_read;
> +   config.read_only = true;
> } else {
> config.name = "nvm_non_active";
> config.reg_write = tb_switch_nvm_write;
> +   config.root_only = true;
> }
>
> config.id = id;
> @@ -292,7 +294,6 @@ static struct nvmem_device *register_nvmem(struct 
> tb_switch *sw, int id,
> config.size = size;
> config.dev = >dev;
> config.owner = THIS_MODULE;
> -   config.root_only = true;
> config.priv = sw;
>
> return nvmem_register();
> --
> 2.11.0
>

Re: [PATCH] thunderbolt: Correct access permissions for active NVM contents

[Andreas Noever]

On Thu, Jun 29, 2017 at 9:19 PM, Mika Westerberg
 wrote:
> Firmware upgrade tools that decide which NVM image should be uploaded to
> the Thunderbolt controller need to access active parts of the NVM even
> if they are not run as root. The information in active NVM is not
> considered security critical so we can use the default permissions set
> by the NVMem framework.
>
> Writing the NVM image is still left as root only operation.
>
> While there mark the active NVM as read-only in the filesystem.
>
> Reported-by: Yehezkel Bernat 
> Signed-off-by: Mika Westerberg 

Sorry for the late reply (I'm on vacation :P).

Signed-off-by: Andreas Noever 

> ---
> Hi,
>
> This applies on top of my Thunderbolt patches in Greg's char-misc-next
> branch.
>
> Thanks.
>
>  drivers/thunderbolt/switch.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index ab3e8f410444..40219a706309 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -281,9 +281,11 @@ static struct nvmem_device *register_nvmem(struct 
> tb_switch *sw, int id,
> if (active) {
> config.name = "nvm_active";
> config.reg_read = tb_switch_nvm_read;
> +   config.read_only = true;
> } else {
> config.name = "nvm_non_active";
> config.reg_write = tb_switch_nvm_write;
> +   config.root_only = true;
> }
>
> config.id = id;
> @@ -292,7 +294,6 @@ static struct nvmem_device *register_nvmem(struct 
> tb_switch *sw, int id,
> config.size = size;
> config.dev = >dev;
> config.owner = THIS_MODULE;
> -   config.root_only = true;
> config.priv = sw;
>
> return nvmem_register();
> --
> 2.11.0
>

Re: [PATCH] thunderbolt: Fix reset response_type

[Andreas Noever]

On Wed, Jun 14, 2017 at 10:42 AM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> On Wed, Jun 14, 2017 at 10:47:21AM +0300, Dan Carpenter wrote:
>> There is a mistake here where we accidentally use sizeof(TB_CFG_PKG_RESET)
>> instead of just TB_CFG_PKG_RESET.  The size of an int is 4 so it's the
>> same as TB_CFG_PKG_NOTIFY_ACK.
>>
>> Fixes: d7f781bfdbf4 ("thunderbolt: Rework control channel to be more 
>> reliable")
>> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
>
> Good catch!
>
> Acked-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>

Re: [PATCH] thunderbolt: Fix reset response_type

[Andreas Noever]

On Wed, Jun 14, 2017 at 10:42 AM, Mika Westerberg
 wrote:
> On Wed, Jun 14, 2017 at 10:47:21AM +0300, Dan Carpenter wrote:
>> There is a mistake here where we accidentally use sizeof(TB_CFG_PKG_RESET)
>> instead of just TB_CFG_PKG_RESET.  The size of an int is 4 so it's the
>> same as TB_CFG_PKG_NOTIFY_ACK.
>>
>> Fixes: d7f781bfdbf4 ("thunderbolt: Rework control channel to be more 
>> reliable")
>> Signed-off-by: Dan Carpenter 
>
> Good catch!
>
> Acked-by: Mika Westerberg 
Signed-off-by: Andreas Noever 

Re: [PATCH] thunderbolt: fix spelling mistake: "missmatch" -> "mismatch"

[Andreas Noever]

On Thu, May 18, 2017 at 9:42 AM, Colin King <colin.k...@canonical.com> wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> Trivial fix to spelling mistake in tb_sw_warn warning message
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---
>  drivers/thunderbolt/eeprom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
> index 6392990c984d..1c3eb937a728 100644
> --- a/drivers/thunderbolt/eeprom.c
> +++ b/drivers/thunderbolt/eeprom.c
> @@ -283,7 +283,7 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid)
>
> crc = tb_crc8(data + 1, 8);
> if (crc != data[0]) {
> -   tb_sw_warn(sw, "uid crc8 missmatch (expected: %#x, got: 
> %#x)\n",
> +   tb_sw_warn(sw, "uid crc8 mismatch (expected: %#x, got: 
> %#x)\n",
>         data[0], crc);
> return -EIO;
> }
> --
> 2.11.0
>

Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>

Greg, I believe that this line survived Mika's series. Would you add it as well?

Thanks,
Andreas

Re: [PATCH] thunderbolt: fix spelling mistake: "missmatch" -> "mismatch"

[Andreas Noever]

On Thu, May 18, 2017 at 9:42 AM, Colin King  wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistake in tb_sw_warn warning message
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/thunderbolt/eeprom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
> index 6392990c984d..1c3eb937a728 100644
> --- a/drivers/thunderbolt/eeprom.c
> +++ b/drivers/thunderbolt/eeprom.c
> @@ -283,7 +283,7 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid)
>
> crc = tb_crc8(data + 1, 8);
> if (crc != data[0]) {
> -   tb_sw_warn(sw, "uid crc8 missmatch (expected: %#x, got: 
> %#x)\n",
> +   tb_sw_warn(sw, "uid crc8 mismatch (expected: %#x, got: 
> %#x)\n",
> data[0], crc);
> return -EIO;
> }
> --
> 2.11.0
>

Signed-off-by: Andreas Noever 

Greg, I believe that this line survived Mika's series. Would you add it as well?

Thanks,
Andreas

Re: [PATCH v3 00/27] Thunderbolt security levels and NVM firmware upgrade

[Andreas Noever]

On Mon, Jun 5, 2017 at 9:18 AM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> On Sat, Jun 03, 2017 at 06:17:04PM +0900, Greg Kroah-Hartman wrote:
>> On Fri, Jun 02, 2017 at 05:04:57PM +0300, Mika Westerberg wrote:
>> > Hi,
>> >
>> > This is a third version of the patch series adding support for Thunderbolt
>> > security levels and NVM firmware upgrade. PCs running Intel Falcon Ridge or
>> > newer need these in order to connect devices if the security level is set
>> > to "user(SL1) or secure(SL2)" from BIOS.
>>
>> All looks good to me, very nice work.
>
> Thanks!
>
>> I don't know what tree it should go in through, but if Andreas wants me
>> to take it, I will if I can get his signed-off-by.
>
> That would be perfect.
>
> Andreas, do you have any objections?
No, Thanks a lot.

Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>

Greg, can you take this through your tree?



Mika, I have a quick question regarding the pci side of things (your
"pci=hpbussize=10,hpmemsize=2M" workaround). Does that work for nested
hotplug or just on the first level? Back when I was having a look at
enabling chaining in the native driver I could not get pci to properly
assign bus numbers to nested bridges. It always ran out of bus number
after one level (irregardless of hpbussize). Has the pci behaviour
changed or does the ICM somehow preconfigure the bridges before
handing them of to linux?

Cheers
Andreas


> I will prepare another version where I've fixed the VSEC vs. VSE thing
> in the capability rework patch.

Re: [PATCH v3 00/27] Thunderbolt security levels and NVM firmware upgrade

[Andreas Noever]

On Mon, Jun 5, 2017 at 9:18 AM, Mika Westerberg
 wrote:
> On Sat, Jun 03, 2017 at 06:17:04PM +0900, Greg Kroah-Hartman wrote:
>> On Fri, Jun 02, 2017 at 05:04:57PM +0300, Mika Westerberg wrote:
>> > Hi,
>> >
>> > This is a third version of the patch series adding support for Thunderbolt
>> > security levels and NVM firmware upgrade. PCs running Intel Falcon Ridge or
>> > newer need these in order to connect devices if the security level is set
>> > to "user(SL1) or secure(SL2)" from BIOS.
>>
>> All looks good to me, very nice work.
>
> Thanks!
>
>> I don't know what tree it should go in through, but if Andreas wants me
>> to take it, I will if I can get his signed-off-by.
>
> That would be perfect.
>
> Andreas, do you have any objections?
No, Thanks a lot.

Signed-off-by: Andreas Noever 

Greg, can you take this through your tree?



Mika, I have a quick question regarding the pci side of things (your
"pci=hpbussize=10,hpmemsize=2M" workaround). Does that work for nested
hotplug or just on the first level? Back when I was having a look at
enabling chaining in the native driver I could not get pci to properly
assign bus numbers to nested bridges. It always ran out of bus number
after one level (irregardless of hpbussize). Has the pci behaviour
changed or does the ICM somehow preconfigure the bridges before
handing them of to linux?

Cheers
Andreas


> I will prepare another version where I've fixed the VSEC vs. VSE thing
> in the capability rework patch.

Re: [PATCH v3 08/27] thunderbolt: Introduce thunderbolt bus and connection manager

[Andreas Noever]

On Fri, Jun 2, 2017 at 4:05 PM, Mika Westerberg
 wrote:
> Thunderbolt fabric consists of one or more switches. This fabric is
> called domain and it is controlled by an entity called connection
> manager. The connection manager can be either internal (driven by a
> firmware running on the host controller) or external (software driver).
> This driver currently implements support for the latter.
>
> In order to manage switches and their properties more easily we model
> this domain structure as a Linux bus. Each host controller adds a domain
> device to this bus, and these devices are named as domainN where N
> stands for index or id of the current domain.
>
> We then abstract connection manager specific operations into a new
> structure tb_cm_ops and convert the existing tb.c to fill those
> accordingly. This makes it easier to add support for the internal
> connection manager in subsequent patches.
>
> Signed-off-by: Mika Westerberg 
> Reviewed-by: Yehezkel Bernat 
> Reviewed-by: Michael Jamet 
> Reviewed-by: Andy Shevchenko 
> ---
>  drivers/thunderbolt/Makefile |   2 +-
>  drivers/thunderbolt/domain.c | 229 
> +++
>  drivers/thunderbolt/nhi.c|  31 --
>  drivers/thunderbolt/tb.c | 156 --
>  drivers/thunderbolt/tb.h |  70 +---
>  drivers/thunderbolt/tunnel_pci.c |   9 +-
>  6 files changed, 376 insertions(+), 121 deletions(-)
>  create mode 100644 drivers/thunderbolt/domain.c
>
> diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
> index 5d1053cdfa54..e276a9a62261 100644
> --- a/drivers/thunderbolt/Makefile
> +++ b/drivers/thunderbolt/Makefile
> @@ -1,3 +1,3 @@
>  obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
>  thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o 
> eeprom.o
> -
> +thunderbolt-objs += domain.o
> diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c
> new file mode 100644
> index ..e2f3777edee6
> --- /dev/null
> +++ b/drivers/thunderbolt/domain.c
> @@ -0,0 +1,229 @@
> +/*
> + * Thunderbolt bus support
> + *
> + * Copyright (C) 2017, Intel Corporation
> + * Author:  Mika Westerberg 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "tb.h"
> +
> +static DEFINE_IDA(tb_domain_ida);
> +
> +struct bus_type tb_bus_type = {
> +   .name = "thunderbolt",
> +};
> +
> +static void tb_domain_release(struct device *dev)
> +{
> +   struct tb *tb = container_of(dev, struct tb, dev);
> +
> +   tb_ctl_free(tb->ctl);
> +   destroy_workqueue(tb->wq);
> +   ida_simple_remove(_domain_ida, tb->index);
> +   kfree(tb);
> +}
> +
> +struct device_type tb_domain_type = {
> +   .name = "thunderbolt_domain",
> +   .release = tb_domain_release,
> +};
> +
> +/**
> + * tb_domain_alloc() - Allocate a domain
> + * @nhi: Pointer to the host controller
> + * @privsize: Size of the connection manager private data
> + *
> + * Allocates and initializes a new Thunderbolt domain. Connection
> + * managers are expected to call this and then fill in @cm_ops
> + * accordingly.
> + *
> + * Call tb_domain_put() to release the domain before it has been added
> + * to the system.
> + *
> + * Return: allocated domain structure on %NULL in case of error
> + */
> +struct tb *tb_domain_alloc(struct tb_nhi *nhi, size_t privsize)
> +{
> +   struct tb *tb;
> +
> +   /*
> +* Make sure the structure sizes map with that the hardware
> +* expects because bit-fields are being used.
> +*/
> +   BUILD_BUG_ON(sizeof(struct tb_regs_switch_header) != 5 * 4);
> +   BUILD_BUG_ON(sizeof(struct tb_regs_port_header) != 8 * 4);
> +   BUILD_BUG_ON(sizeof(struct tb_regs_hop) != 2 * 4);
> +
> +   tb = kzalloc(sizeof(*tb) + privsize, GFP_KERNEL);
> +   if (!tb)
> +   return NULL;
> +
> +   tb->nhi = nhi;
> +   mutex_init(>lock);
> +
> +   tb->index = ida_simple_get(_domain_ida, 0, 0, GFP_KERNEL);
> +   if (tb->index < 0)
> +   goto err_free;
> +
> +   tb->wq = alloc_ordered_workqueue("thunderbolt%d", 0, tb->index);
> +   if (!tb->wq)
> +   goto err_remove_ida;
> +
> +   tb->dev.parent = >pdev->dev;
> +   tb->dev.bus = _bus_type;
> +   tb->dev.type = _domain_type;
> +   dev_set_name(>dev, "domain%d", tb->index);
> +   device_initialize(>dev);
> +
> +   return tb;
> +
> +err_remove_ida:
> +   ida_simple_remove(_domain_ida, tb->index);
> +err_free:
> +   kfree(tb);
> +
> +   return NULL;
> +}
> +
> +/**
> + * 

Re: [PATCH v3 08/27] thunderbolt: Introduce thunderbolt bus and connection manager

[Andreas Noever]

On Fri, Jun 2, 2017 at 4:05 PM, Mika Westerberg
 wrote:
> Thunderbolt fabric consists of one or more switches. This fabric is
> called domain and it is controlled by an entity called connection
> manager. The connection manager can be either internal (driven by a
> firmware running on the host controller) or external (software driver).
> This driver currently implements support for the latter.
>
> In order to manage switches and their properties more easily we model
> this domain structure as a Linux bus. Each host controller adds a domain
> device to this bus, and these devices are named as domainN where N
> stands for index or id of the current domain.
>
> We then abstract connection manager specific operations into a new
> structure tb_cm_ops and convert the existing tb.c to fill those
> accordingly. This makes it easier to add support for the internal
> connection manager in subsequent patches.
>
> Signed-off-by: Mika Westerberg 
> Reviewed-by: Yehezkel Bernat 
> Reviewed-by: Michael Jamet 
> Reviewed-by: Andy Shevchenko 
> ---
>  drivers/thunderbolt/Makefile |   2 +-
>  drivers/thunderbolt/domain.c | 229 
> +++
>  drivers/thunderbolt/nhi.c|  31 --
>  drivers/thunderbolt/tb.c | 156 --
>  drivers/thunderbolt/tb.h |  70 +---
>  drivers/thunderbolt/tunnel_pci.c |   9 +-
>  6 files changed, 376 insertions(+), 121 deletions(-)
>  create mode 100644 drivers/thunderbolt/domain.c
>
> diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
> index 5d1053cdfa54..e276a9a62261 100644
> --- a/drivers/thunderbolt/Makefile
> +++ b/drivers/thunderbolt/Makefile
> @@ -1,3 +1,3 @@
>  obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
>  thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o 
> eeprom.o
> -
> +thunderbolt-objs += domain.o
> diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c
> new file mode 100644
> index ..e2f3777edee6
> --- /dev/null
> +++ b/drivers/thunderbolt/domain.c
> @@ -0,0 +1,229 @@
> +/*
> + * Thunderbolt bus support
> + *
> + * Copyright (C) 2017, Intel Corporation
> + * Author:  Mika Westerberg 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "tb.h"
> +
> +static DEFINE_IDA(tb_domain_ida);
> +
> +struct bus_type tb_bus_type = {
> +   .name = "thunderbolt",
> +};
> +
> +static void tb_domain_release(struct device *dev)
> +{
> +   struct tb *tb = container_of(dev, struct tb, dev);
> +
> +   tb_ctl_free(tb->ctl);
> +   destroy_workqueue(tb->wq);
> +   ida_simple_remove(_domain_ida, tb->index);
> +   kfree(tb);
> +}
> +
> +struct device_type tb_domain_type = {
> +   .name = "thunderbolt_domain",
> +   .release = tb_domain_release,
> +};
> +
> +/**
> + * tb_domain_alloc() - Allocate a domain
> + * @nhi: Pointer to the host controller
> + * @privsize: Size of the connection manager private data
> + *
> + * Allocates and initializes a new Thunderbolt domain. Connection
> + * managers are expected to call this and then fill in @cm_ops
> + * accordingly.
> + *
> + * Call tb_domain_put() to release the domain before it has been added
> + * to the system.
> + *
> + * Return: allocated domain structure on %NULL in case of error
> + */
> +struct tb *tb_domain_alloc(struct tb_nhi *nhi, size_t privsize)
> +{
> +   struct tb *tb;
> +
> +   /*
> +* Make sure the structure sizes map with that the hardware
> +* expects because bit-fields are being used.
> +*/
> +   BUILD_BUG_ON(sizeof(struct tb_regs_switch_header) != 5 * 4);
> +   BUILD_BUG_ON(sizeof(struct tb_regs_port_header) != 8 * 4);
> +   BUILD_BUG_ON(sizeof(struct tb_regs_hop) != 2 * 4);
> +
> +   tb = kzalloc(sizeof(*tb) + privsize, GFP_KERNEL);
> +   if (!tb)
> +   return NULL;
> +
> +   tb->nhi = nhi;
> +   mutex_init(>lock);
> +
> +   tb->index = ida_simple_get(_domain_ida, 0, 0, GFP_KERNEL);
> +   if (tb->index < 0)
> +   goto err_free;
> +
> +   tb->wq = alloc_ordered_workqueue("thunderbolt%d", 0, tb->index);
> +   if (!tb->wq)
> +   goto err_remove_ida;
> +
> +   tb->dev.parent = >pdev->dev;
> +   tb->dev.bus = _bus_type;
> +   tb->dev.type = _domain_type;
> +   dev_set_name(>dev, "domain%d", tb->index);
> +   device_initialize(>dev);
> +
> +   return tb;
> +
> +err_remove_ida:
> +   ida_simple_remove(_domain_ida, tb->index);
> +err_free:
> +   kfree(tb);
> +
> +   return NULL;
> +}
> +
> +/**
> + * tb_domain_add() - Add domain to the system
> + * @tb: Domain to add
> + *
> + * Starts the domain and adds it to the system. Hotplugging devices will
> + * work after this has been 

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Andreas Noever]

On Mon, May 22, 2017 at 10:38 PM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> On Mon, May 22, 2017 at 08:41:22PM +0200, Andreas Noever wrote:
>> Yes there is a check for the root switch, but also one that checks the
>> return code of tb_drom_read_uid_only :)
>>
>> err = tb_drom_read_uid_only(sw, );
>> if (err) {
>> tb_sw_warn(sw, "uid read failed\n");
>> return err;
>> }
>> if (sw != sw->tb->root_switch && sw->uid != uid) {
>>
>>
>> The reason it works on the Mac is because drom_offset is not 0, so the
>> new branch in tb_drom_read_uid_only is not taken. Probably this is the
>> case for all Cactus Ridge models and Alpine Ridge doesn't go there
>> since it uses the ICM?
>
> Yes in case of ICM we don't call the function at all.
>
>> Still it wouldn't hurt to only read the uid if
>> sw != root_switch, the value is not used if sw == root_switch.
>
> I agree. I'll update the code so that it will only read and check UID
> when we are not dealing with the root switch.
Thanks,
Andreas

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Andreas Noever]

On Mon, May 22, 2017 at 10:38 PM, Mika Westerberg
 wrote:
> On Mon, May 22, 2017 at 08:41:22PM +0200, Andreas Noever wrote:
>> Yes there is a check for the root switch, but also one that checks the
>> return code of tb_drom_read_uid_only :)
>>
>> err = tb_drom_read_uid_only(sw, );
>> if (err) {
>> tb_sw_warn(sw, "uid read failed\n");
>> return err;
>> }
>> if (sw != sw->tb->root_switch && sw->uid != uid) {
>>
>>
>> The reason it works on the Mac is because drom_offset is not 0, so the
>> new branch in tb_drom_read_uid_only is not taken. Probably this is the
>> case for all Cactus Ridge models and Alpine Ridge doesn't go there
>> since it uses the ICM?
>
> Yes in case of ICM we don't call the function at all.
>
>> Still it wouldn't hurt to only read the uid if
>> sw != root_switch, the value is not used if sw == root_switch.
>
> I agree. I'll update the code so that it will only read and check UID
> when we are not dealing with the root switch.
Thanks,
Andreas

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Andreas Noever]

On Mon, May 22, 2017 at 10:40 AM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> On Sun, May 21, 2017 at 03:46:20PM +0200, Andreas Noever wrote:
>> On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
>> <mika.westerb...@linux.intel.com> wrote:
>> > At least Falcon Ridge when in host mode does not have any kind of DROM
>> > available and reading DROM offset returns 0 for these. Do not try to
>> > read DROM any further in that case.
>> >
>> > Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
>> > Reviewed-by: Yehezkel Bernat <yehezkel.ber...@intel.com>
>> > Reviewed-by: Michael Jamet <michael.ja...@intel.com>
>> > ---
>> >  drivers/thunderbolt/eeprom.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>>
>> Hi Mika,
>>
>> nice work, it is nice to see Intel contribute to the Thunderbolt
>> driver (I can second Lukas's 'jaw drop' comment)!
>>
>> I will try to read through everything today, but maybe the last few
>> patches will get pushed back to next weekend.
>
> Thanks :)
>
>> > diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
>> > index 6392990c984d..e4e64b130514 100644
>> > --- a/drivers/thunderbolt/eeprom.c
>> > +++ b/drivers/thunderbolt/eeprom.c
>> > @@ -276,6 +276,9 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 
>> > *uid)
>> > if (res)
>> > return res;
>> >
>> > +   if (drom_offset == 0)
>> > +   return -ENODEV;
>> > +
>> I think that this will make tb_switch_resume bail out on the root
>> switch, which is not good. Since the uid is only used to detect
>> whether a different device was plugged in while the system was
>> suspended I think that we can safely ignore the uid on the root
>> switch:
>>  - don't read it in tb_drom_read (route == 0 is already special cased 
>> anyways)
>>  - add a special case for the root switch to tb_switch_resume and
>> don't read the uid - just assume that it did not change (should be
>> impossible anyways)
>>
>> What do you think?
>
> I think there actually is such check already in tb_switch_resume() where
> we special case the root switch ignoring its UID. Unless I'm missing
> something.
>
> I'm testing this on a Mac with Cactus Ridge and the root switch resume
> does not fail :)

Yes there is a check for the root switch, but also one that checks the
return code of tb_drom_read_uid_only :)

err = tb_drom_read_uid_only(sw, );
if (err) {
tb_sw_warn(sw, "uid read failed\n");
return err;
}
if (sw != sw->tb->root_switch && sw->uid != uid) {


The reason it works on the Mac is because drom_offset is not 0, so the
new branch in tb_drom_read_uid_only is not taken. Probably this is the
case for all Cactus Ridge models and Alpine Ridge doesn't go there
since it uses the ICM? Still it wouldn't hurt to only read the uid if
sw != root_switch, the value is not used if sw == root_switch.

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Andreas Noever]

On Mon, May 22, 2017 at 10:40 AM, Mika Westerberg
 wrote:
> On Sun, May 21, 2017 at 03:46:20PM +0200, Andreas Noever wrote:
>> On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
>>  wrote:
>> > At least Falcon Ridge when in host mode does not have any kind of DROM
>> > available and reading DROM offset returns 0 for these. Do not try to
>> > read DROM any further in that case.
>> >
>> > Signed-off-by: Mika Westerberg 
>> > Reviewed-by: Yehezkel Bernat 
>> > Reviewed-by: Michael Jamet 
>> > ---
>> >  drivers/thunderbolt/eeprom.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>>
>> Hi Mika,
>>
>> nice work, it is nice to see Intel contribute to the Thunderbolt
>> driver (I can second Lukas's 'jaw drop' comment)!
>>
>> I will try to read through everything today, but maybe the last few
>> patches will get pushed back to next weekend.
>
> Thanks :)
>
>> > diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
>> > index 6392990c984d..e4e64b130514 100644
>> > --- a/drivers/thunderbolt/eeprom.c
>> > +++ b/drivers/thunderbolt/eeprom.c
>> > @@ -276,6 +276,9 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 
>> > *uid)
>> > if (res)
>> > return res;
>> >
>> > +   if (drom_offset == 0)
>> > +   return -ENODEV;
>> > +
>> I think that this will make tb_switch_resume bail out on the root
>> switch, which is not good. Since the uid is only used to detect
>> whether a different device was plugged in while the system was
>> suspended I think that we can safely ignore the uid on the root
>> switch:
>>  - don't read it in tb_drom_read (route == 0 is already special cased 
>> anyways)
>>  - add a special case for the root switch to tb_switch_resume and
>> don't read the uid - just assume that it did not change (should be
>> impossible anyways)
>>
>> What do you think?
>
> I think there actually is such check already in tb_switch_resume() where
> we special case the root switch ignoring its UID. Unless I'm missing
> something.
>
> I'm testing this on a Mac with Cactus Ridge and the root switch resume
> does not fail :)

Yes there is a check for the root switch, but also one that checks the
return code of tb_drom_read_uid_only :)

err = tb_drom_read_uid_only(sw, );
if (err) {
tb_sw_warn(sw, "uid read failed\n");
return err;
}
if (sw != sw->tb->root_switch && sw->uid != uid) {


The reason it works on the Mac is because drom_offset is not 0, so the
new branch in tb_drom_read_uid_only is not taken. Probably this is the
case for all Cactus Ridge models and Alpine Ridge doesn't go there
since it uses the ICM? Still it wouldn't hurt to only read the uid if
sw != root_switch, the value is not used if sw == root_switch.

Re: [PATCH 05/24] thunderbolt: Rework capability handling

[Andreas Noever]

On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
 wrote:
> Organization of the capabilities in switches and ports is not so random
> after all. Rework the capability handling functionality so that it
> follows how capabilities are organized and provide two new functions
> (tb_switch_find_vsec_cap() and tb_port_find_cap()) which can be used to
> extract capabilities for ports and switches. Then convert the current
> users over these.

Hm, could you explain the "official" logic a bit? What I could gather
from reading the code:
 - Port capabilities are always "basic" and the list is terminated
with next=0x00
 - Switch capabilities start "basic" then if cap==VSEC they turn into
"extendend_short" and after offset=0xff they turn into
"extended_long". The list is terminated by either next=0x00 or
next=0x.
 - There is always an extended cap whose offset is < 0xff  (otherwise
tb_switch_find_cap won't find the first vsec cap).
 - If there are "long" caps then there is always one at exactly 0xff
(because short caps have single byte next pointers).
Are these observations correct? I must say I found the old logic to
detect long capabilities (short.next == short.length == 0) more
elegant (and I'm quite sure that is the logic that the Mac driver
implemented at some point), but we can of course change it to match
the way it is written in the spec (and of course I have to request
this at least once: you should definitely release the spec - I highly
doubt that Intel's competitive advantage depends on keeping this
linked list technology secret ;) ).

Two more inline comments:
> Signed-off-by: Mika Westerberg 
> Reviewed-by: Yehezkel Bernat 
> Reviewed-by: Michael Jamet 
> ---
>  drivers/thunderbolt/cap.c| 169 
> +--
>  drivers/thunderbolt/switch.c |   6 +-
>  drivers/thunderbolt/tb.c |   8 +-
>  drivers/thunderbolt/tb.h |   3 +-
>  drivers/thunderbolt/tb_regs.h|  31 ---
>  drivers/thunderbolt/tunnel_pci.c |   8 +-
>  6 files changed, 124 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/thunderbolt/cap.c b/drivers/thunderbolt/cap.c
> index a7b47e7cddbd..0dd852c3df8d 100644
> --- a/drivers/thunderbolt/cap.c
> +++ b/drivers/thunderbolt/cap.c
> @@ -9,6 +9,8 @@
>
>  #include "tb.h"
>
> +#define CAP_OFFSET_MAX 0xff
> +#define VSEC_CAP_OFFSET_MAX0x
>
>  struct tb_cap_any {
> union {
> @@ -18,99 +20,110 @@ struct tb_cap_any {
> };
>  } __packed;
>
> -static bool tb_cap_is_basic(struct tb_cap_any *cap)
> -{
> -   /* basic.cap is u8. This checks only the lower 8 bit of cap. */
> -   return cap->basic.cap != 5;
> -}
> -
> -static bool tb_cap_is_long(struct tb_cap_any *cap)
> +/**
> + * tb_port_find_cap() - Find port capability
> + * @port: Port to find the capability for
> + * @cap: Capability to look
> + *
> + * Returns offset to start of capability or %-ENOENT if no such
> + * capability was found. Negative errno is returned if there was an
> + * error.
> + */
> +int tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
>  {
> -   return !tb_cap_is_basic(cap)
> -  && cap->extended_short.next == 0
> -  && cap->extended_short.length == 0;
> -}
> +   u32 offset;
>
> -static enum tb_cap tb_cap(struct tb_cap_any *cap)
> -{
> -   if (tb_cap_is_basic(cap))
> -   return cap->basic.cap;
> +   /*
> +* DP out adapters claim to implement TMU capability but in
> +* reality they do not so we hard code the adapter specific
> +* capability offset here.
> +*/
> +   if (port->config.type == TB_TYPE_DP_HDMI_OUT)
> +   offset = 0x39;
> else
> -   /* extended_short/long have cap at the same offset. */
> -   return cap->extended_short.cap;
> +   offset = 0x1;
When I was reverse engineering this the problem was not that some
capability was advertised (what does "TMU" stand for?), but that a
capabilities's next pointer (the one at 0xa) was pointing ..
*somewhere*. The fix was to redirect it to 0x39 (which looked like it
was the next valid capability). Your code makes the iteration start at
0x39. Which I guess is equivalent if the first capability is always
the faulty one?

Also can we make this quirk specific to some rom version or is it
expected that HDMI_OUT ports will forever have their first capability
at 0x39?

> +
> +   do {
> +   struct tb_cap_any header;
> +   int ret;
> +
> +   ret = tb_port_read(port, , TB_CFG_PORT, offset, 1);
> +   if (ret)
> +   return ret;
> +
> +   if (header.basic.cap == cap)
> +   return offset;
> +
> +   offset = header.basic.next;
> +   } while (offset);
> +
> +   return -ENOENT;
>  }
>
> -static u32 

Re: [PATCH 05/24] thunderbolt: Rework capability handling

[Andreas Noever]

On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
 wrote:
> Organization of the capabilities in switches and ports is not so random
> after all. Rework the capability handling functionality so that it
> follows how capabilities are organized and provide two new functions
> (tb_switch_find_vsec_cap() and tb_port_find_cap()) which can be used to
> extract capabilities for ports and switches. Then convert the current
> users over these.

Hm, could you explain the "official" logic a bit? What I could gather
from reading the code:
 - Port capabilities are always "basic" and the list is terminated
with next=0x00
 - Switch capabilities start "basic" then if cap==VSEC they turn into
"extendend_short" and after offset=0xff they turn into
"extended_long". The list is terminated by either next=0x00 or
next=0x.
 - There is always an extended cap whose offset is < 0xff  (otherwise
tb_switch_find_cap won't find the first vsec cap).
 - If there are "long" caps then there is always one at exactly 0xff
(because short caps have single byte next pointers).
Are these observations correct? I must say I found the old logic to
detect long capabilities (short.next == short.length == 0) more
elegant (and I'm quite sure that is the logic that the Mac driver
implemented at some point), but we can of course change it to match
the way it is written in the spec (and of course I have to request
this at least once: you should definitely release the spec - I highly
doubt that Intel's competitive advantage depends on keeping this
linked list technology secret ;) ).

Two more inline comments:
> Signed-off-by: Mika Westerberg 
> Reviewed-by: Yehezkel Bernat 
> Reviewed-by: Michael Jamet 
> ---
>  drivers/thunderbolt/cap.c| 169 
> +--
>  drivers/thunderbolt/switch.c |   6 +-
>  drivers/thunderbolt/tb.c |   8 +-
>  drivers/thunderbolt/tb.h |   3 +-
>  drivers/thunderbolt/tb_regs.h|  31 ---
>  drivers/thunderbolt/tunnel_pci.c |   8 +-
>  6 files changed, 124 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/thunderbolt/cap.c b/drivers/thunderbolt/cap.c
> index a7b47e7cddbd..0dd852c3df8d 100644
> --- a/drivers/thunderbolt/cap.c
> +++ b/drivers/thunderbolt/cap.c
> @@ -9,6 +9,8 @@
>
>  #include "tb.h"
>
> +#define CAP_OFFSET_MAX 0xff
> +#define VSEC_CAP_OFFSET_MAX0x
>
>  struct tb_cap_any {
> union {
> @@ -18,99 +20,110 @@ struct tb_cap_any {
> };
>  } __packed;
>
> -static bool tb_cap_is_basic(struct tb_cap_any *cap)
> -{
> -   /* basic.cap is u8. This checks only the lower 8 bit of cap. */
> -   return cap->basic.cap != 5;
> -}
> -
> -static bool tb_cap_is_long(struct tb_cap_any *cap)
> +/**
> + * tb_port_find_cap() - Find port capability
> + * @port: Port to find the capability for
> + * @cap: Capability to look
> + *
> + * Returns offset to start of capability or %-ENOENT if no such
> + * capability was found. Negative errno is returned if there was an
> + * error.
> + */
> +int tb_port_find_cap(struct tb_port *port, enum tb_port_cap cap)
>  {
> -   return !tb_cap_is_basic(cap)
> -  && cap->extended_short.next == 0
> -  && cap->extended_short.length == 0;
> -}
> +   u32 offset;
>
> -static enum tb_cap tb_cap(struct tb_cap_any *cap)
> -{
> -   if (tb_cap_is_basic(cap))
> -   return cap->basic.cap;
> +   /*
> +* DP out adapters claim to implement TMU capability but in
> +* reality they do not so we hard code the adapter specific
> +* capability offset here.
> +*/
> +   if (port->config.type == TB_TYPE_DP_HDMI_OUT)
> +   offset = 0x39;
> else
> -   /* extended_short/long have cap at the same offset. */
> -   return cap->extended_short.cap;
> +   offset = 0x1;
When I was reverse engineering this the problem was not that some
capability was advertised (what does "TMU" stand for?), but that a
capabilities's next pointer (the one at 0xa) was pointing ..
*somewhere*. The fix was to redirect it to 0x39 (which looked like it
was the next valid capability). Your code makes the iteration start at
0x39. Which I guess is equivalent if the first capability is always
the faulty one?

Also can we make this quirk specific to some rom version or is it
expected that HDMI_OUT ports will forever have their first capability
at 0x39?

> +
> +   do {
> +   struct tb_cap_any header;
> +   int ret;
> +
> +   ret = tb_port_read(port, , TB_CFG_PORT, offset, 1);
> +   if (ret)
> +   return ret;
> +
> +   if (header.basic.cap == cap)
> +   return offset;
> +
> +   offset = header.basic.next;
> +   } while (offset);
> +
> +   return -ENOENT;
>  }
>
> -static u32 tb_cap_next(struct tb_cap_any *cap, u32 offset)
> +static int tb_switch_find_cap(struct tb_switch *sw, enum tb_switch_cap cap)
>  {

Re: [PATCH 04/24] thunderbolt: Add MSI-X support

[Andreas Noever]

On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
 wrote:
> Intel Thunderbolt controllers support up to 16 MSI-X vectors. Using
Is that true for all generations? If so can we remove the legacy path?

> MSI-X is preferred over MSI or legacy interrupt and may bring additional
> performance because there is no need to check the status registers which
> interrupt was triggered.
>
> While there we convert comments in structs tb_ring and tb_nhi to follow
> kernel-doc format more closely.
>
> 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 
> ---
>  drivers/thunderbolt/ctl.c  |   4 +-
>  drivers/thunderbolt/nhi.c  | 159 
> -
>  drivers/thunderbolt/nhi.h  |  56 +++
>  drivers/thunderbolt/nhi_regs.h |   9 +++
>  4 files changed, 196 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
> index 1031d97407a8..889a32dd21e7 100644
> --- a/drivers/thunderbolt/ctl.c
> +++ b/drivers/thunderbolt/ctl.c
> @@ -488,11 +488,11 @@ struct tb_ctl *tb_ctl_alloc(struct tb_nhi *nhi, 
> hotplug_cb cb, void *cb_data)
> if (!ctl->frame_pool)
> goto err;
>
> -   ctl->tx = ring_alloc_tx(nhi, 0, 10);
> +   ctl->tx = ring_alloc_tx(nhi, 0, 10, RING_FLAG_NO_SUSPEND);
> if (!ctl->tx)
> goto err;
>
> -   ctl->rx = ring_alloc_rx(nhi, 0, 10);
> +   ctl->rx = ring_alloc_rx(nhi, 0, 10, RING_FLAG_NO_SUSPEND);
> if (!ctl->rx)
> goto err;
>
> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
> index a8c20413dbda..17f3b1bdb7da 100644
> --- a/drivers/thunderbolt/nhi.c
> +++ b/drivers/thunderbolt/nhi.c
> @@ -21,6 +21,12 @@
>
>  #define RING_TYPE(ring) ((ring)->is_tx ? "TX ring" : "RX ring")
>
> +/*
> + * Minimal number of vectors when we use MSI-X. Two for control channel
> + * Rx/Tx and the rest four are for cross domain DMA paths.
> + */
> +#define MSIX_MIN_VECS  6
> +#define MSIX_MAX_VECS  16
>
>  static int ring_interrupt_index(struct tb_ring *ring)
>  {
> @@ -239,8 +245,82 @@ int __ring_enqueue(struct tb_ring *ring, struct 
> ring_frame *frame)
> return ret;
>  }
>
> +static irqreturn_t ring_msix(int irq, void *data)
> +{
> +   struct tb_ring *ring = data;
> +
> +   schedule_work(>work);
> +   return IRQ_HANDLED;
> +}
> +
> +static void ring_map_unmap_msix(struct tb_ring *ring, bool map)
> +{
This function does the same as ring_interrupt_active just for msix,
right? Can we rename one (or both) to express that?
For example rename ring_interrput_active -> ring_map_unmap_msi. Or
just roll this one into ring_interrupt_active and do the right thing
internally.

> +   u32 step, shift, ivr, misc;
> +   int index;
> +
> +   if (ring->irq <= 0)
> +   return;
> +
> +   if (ring->is_tx)
> +   index = ring->hop;
> +   else
> +   index = ring->hop + ring->nhi->hop_count;
> +
> +   /*
> +* Ask the hardware to clear interrupt status bits automatically
> +* since we already know which interrupt was triggered.
> +*/
> +   misc = ioread32(ring->nhi->iobase + REG_DMA_MISC);
> +   if (!(misc & REG_DMA_MISC_INT_AUTO_CLEAR)) {
> +   misc |= REG_DMA_MISC_INT_AUTO_CLEAR;
> +   iowrite32(misc, ring->nhi->iobase + REG_DMA_MISC);
> +   }
> +
> +   step = index / REG_INT_VEC_ALLOC_REGS * REG_INT_VEC_ALLOC_BITS;
> +   shift = index % REG_INT_VEC_ALLOC_REGS * REG_INT_VEC_ALLOC_BITS;
> +   ivr = ioread32(ring->nhi->iobase + REG_INT_VEC_ALLOC_BASE + step);
> +   ivr &= ~(REG_INT_VEC_ALLOC_MASK << shift);
> +   if (map)
> +   ivr |= ring->vector << shift;
> +   iowrite32(ivr, ring->nhi->iobase + REG_INT_VEC_ALLOC_BASE + step);
> +}
> +
> +static int ring_request_msix(struct tb_ring *ring, bool no_suspend)
> +{
> +   struct tb_nhi *nhi = ring->nhi;
> +   unsigned long irqflags;
> +   int ret;
> +
> +   if (!nhi->pdev->msix_enabled)
> +   return 0;
> +
> +   ret = ida_simple_get(>msix_ida, 0, MSIX_MAX_VECS, GFP_KERNEL);
> +   if (ret < 0)
> +   return ret;
> +
> +   ring->vector = ret;
> +
> +   ring->irq = pci_irq_vector(ring->nhi->pdev, ring->vector);
> +   if (ring->irq < 0)
> +   return ring->irq;
> +
> +   irqflags = no_suspend ? IRQF_NO_SUSPEND : 0;
> +   return request_irq(ring->irq, ring_msix, irqflags, "thunderbolt", 
> ring);
> +}
> +
> +static void ring_release_msix(struct tb_ring *ring)
> +{
> +   if (ring->irq <= 0)
> +   return;
> +
> +   free_irq(ring->irq, ring);
> +   ida_simple_remove(>nhi->msix_ida, ring->vector);
> +   

Re: [PATCH 04/24] thunderbolt: Add MSI-X support

[Andreas Noever]

On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
 wrote:
> Intel Thunderbolt controllers support up to 16 MSI-X vectors. Using
Is that true for all generations? If so can we remove the legacy path?

> MSI-X is preferred over MSI or legacy interrupt and may bring additional
> performance because there is no need to check the status registers which
> interrupt was triggered.
>
> While there we convert comments in structs tb_ring and tb_nhi to follow
> kernel-doc format more closely.
>
> 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 
> ---
>  drivers/thunderbolt/ctl.c  |   4 +-
>  drivers/thunderbolt/nhi.c  | 159 
> -
>  drivers/thunderbolt/nhi.h  |  56 +++
>  drivers/thunderbolt/nhi_regs.h |   9 +++
>  4 files changed, 196 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
> index 1031d97407a8..889a32dd21e7 100644
> --- a/drivers/thunderbolt/ctl.c
> +++ b/drivers/thunderbolt/ctl.c
> @@ -488,11 +488,11 @@ struct tb_ctl *tb_ctl_alloc(struct tb_nhi *nhi, 
> hotplug_cb cb, void *cb_data)
> if (!ctl->frame_pool)
> goto err;
>
> -   ctl->tx = ring_alloc_tx(nhi, 0, 10);
> +   ctl->tx = ring_alloc_tx(nhi, 0, 10, RING_FLAG_NO_SUSPEND);
> if (!ctl->tx)
> goto err;
>
> -   ctl->rx = ring_alloc_rx(nhi, 0, 10);
> +   ctl->rx = ring_alloc_rx(nhi, 0, 10, RING_FLAG_NO_SUSPEND);
> if (!ctl->rx)
> goto err;
>
> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
> index a8c20413dbda..17f3b1bdb7da 100644
> --- a/drivers/thunderbolt/nhi.c
> +++ b/drivers/thunderbolt/nhi.c
> @@ -21,6 +21,12 @@
>
>  #define RING_TYPE(ring) ((ring)->is_tx ? "TX ring" : "RX ring")
>
> +/*
> + * Minimal number of vectors when we use MSI-X. Two for control channel
> + * Rx/Tx and the rest four are for cross domain DMA paths.
> + */
> +#define MSIX_MIN_VECS  6
> +#define MSIX_MAX_VECS  16
>
>  static int ring_interrupt_index(struct tb_ring *ring)
>  {
> @@ -239,8 +245,82 @@ int __ring_enqueue(struct tb_ring *ring, struct 
> ring_frame *frame)
> return ret;
>  }
>
> +static irqreturn_t ring_msix(int irq, void *data)
> +{
> +   struct tb_ring *ring = data;
> +
> +   schedule_work(>work);
> +   return IRQ_HANDLED;
> +}
> +
> +static void ring_map_unmap_msix(struct tb_ring *ring, bool map)
> +{
This function does the same as ring_interrupt_active just for msix,
right? Can we rename one (or both) to express that?
For example rename ring_interrput_active -> ring_map_unmap_msi. Or
just roll this one into ring_interrupt_active and do the right thing
internally.

> +   u32 step, shift, ivr, misc;
> +   int index;
> +
> +   if (ring->irq <= 0)
> +   return;
> +
> +   if (ring->is_tx)
> +   index = ring->hop;
> +   else
> +   index = ring->hop + ring->nhi->hop_count;
> +
> +   /*
> +* Ask the hardware to clear interrupt status bits automatically
> +* since we already know which interrupt was triggered.
> +*/
> +   misc = ioread32(ring->nhi->iobase + REG_DMA_MISC);
> +   if (!(misc & REG_DMA_MISC_INT_AUTO_CLEAR)) {
> +   misc |= REG_DMA_MISC_INT_AUTO_CLEAR;
> +   iowrite32(misc, ring->nhi->iobase + REG_DMA_MISC);
> +   }
> +
> +   step = index / REG_INT_VEC_ALLOC_REGS * REG_INT_VEC_ALLOC_BITS;
> +   shift = index % REG_INT_VEC_ALLOC_REGS * REG_INT_VEC_ALLOC_BITS;
> +   ivr = ioread32(ring->nhi->iobase + REG_INT_VEC_ALLOC_BASE + step);
> +   ivr &= ~(REG_INT_VEC_ALLOC_MASK << shift);
> +   if (map)
> +   ivr |= ring->vector << shift;
> +   iowrite32(ivr, ring->nhi->iobase + REG_INT_VEC_ALLOC_BASE + step);
> +}
> +
> +static int ring_request_msix(struct tb_ring *ring, bool no_suspend)
> +{
> +   struct tb_nhi *nhi = ring->nhi;
> +   unsigned long irqflags;
> +   int ret;
> +
> +   if (!nhi->pdev->msix_enabled)
> +   return 0;
> +
> +   ret = ida_simple_get(>msix_ida, 0, MSIX_MAX_VECS, GFP_KERNEL);
> +   if (ret < 0)
> +   return ret;
> +
> +   ring->vector = ret;
> +
> +   ring->irq = pci_irq_vector(ring->nhi->pdev, ring->vector);
> +   if (ring->irq < 0)
> +   return ring->irq;
> +
> +   irqflags = no_suspend ? IRQF_NO_SUSPEND : 0;
> +   return request_irq(ring->irq, ring_msix, irqflags, "thunderbolt", 
> ring);
> +}
> +
> +static void ring_release_msix(struct tb_ring *ring)
> +{
> +   if (ring->irq <= 0)
> +   return;
> +
> +   free_irq(ring->irq, ring);
> +   ida_simple_remove(>nhi->msix_ida, ring->vector);
> +   ring->vector = 0;
> +   ring->irq = 0;
> +}
> +
>  static struct tb_ring *ring_alloc(struct tb_nhi *nhi, u32 hop, int 

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Andreas Noever]

On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
 wrote:
> At least Falcon Ridge when in host mode does not have any kind of DROM
> available and reading DROM offset returns 0 for these. Do not try to
> read DROM any further in that case.
>
> Signed-off-by: Mika Westerberg 
> Reviewed-by: Yehezkel Bernat 
> Reviewed-by: Michael Jamet 
> ---
>  drivers/thunderbolt/eeprom.c | 3 +++
>  1 file changed, 3 insertions(+)
>

Hi Mika,

nice work, it is nice to see Intel contribute to the Thunderbolt
driver (I can second Lukas's 'jaw drop' comment)!

I will try to read through everything today, but maybe the last few
patches will get pushed back to next weekend.

> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
> index 6392990c984d..e4e64b130514 100644
> --- a/drivers/thunderbolt/eeprom.c
> +++ b/drivers/thunderbolt/eeprom.c
> @@ -276,6 +276,9 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid)
> if (res)
> return res;
>
> +   if (drom_offset == 0)
> +   return -ENODEV;
> +
I think that this will make tb_switch_resume bail out on the root
switch, which is not good. Since the uid is only used to detect
whether a different device was plugged in while the system was
suspended I think that we can safely ignore the uid on the root
switch:
 - don't read it in tb_drom_read (route == 0 is already special cased anyways)
 - add a special case for the root switch to tb_switch_resume and
don't read the uid - just assume that it did not change (should be
impossible anyways)

What do you think?

Andreas

> /* read uid */
> res = tb_eeprom_read_n(sw, drom_offset, data, 9);
> if (res)
> --
> 2.11.0
>

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Andreas Noever]

On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
 wrote:
> At least Falcon Ridge when in host mode does not have any kind of DROM
> available and reading DROM offset returns 0 for these. Do not try to
> read DROM any further in that case.
>
> Signed-off-by: Mika Westerberg 
> Reviewed-by: Yehezkel Bernat 
> Reviewed-by: Michael Jamet 
> ---
>  drivers/thunderbolt/eeprom.c | 3 +++
>  1 file changed, 3 insertions(+)
>

Hi Mika,

nice work, it is nice to see Intel contribute to the Thunderbolt
driver (I can second Lukas's 'jaw drop' comment)!

I will try to read through everything today, but maybe the last few
patches will get pushed back to next weekend.

> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
> index 6392990c984d..e4e64b130514 100644
> --- a/drivers/thunderbolt/eeprom.c
> +++ b/drivers/thunderbolt/eeprom.c
> @@ -276,6 +276,9 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid)
> if (res)
> return res;
>
> +   if (drom_offset == 0)
> +   return -ENODEV;
> +
I think that this will make tb_switch_resume bail out on the root
switch, which is not good. Since the uid is only used to detect
whether a different device was plugged in while the system was
suspended I think that we can safely ignore the uid on the root
switch:
 - don't read it in tb_drom_read (route == 0 is already special cased anyways)
 - add a special case for the root switch to tb_switch_resume and
don't read the uid - just assume that it did not change (should be
impossible anyways)

What do you think?

Andreas

> /* read uid */
> res = tb_eeprom_read_n(sw, drom_offset, data, 9);
> if (res)
> --
> 2.11.0
>

Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Andreas Noever]

rbolt/icm/net.h
>>
>> --
>> 2.7.4
>
> Hi Amir,
>
> I've tested your v8 series on Dell hardware with Thunderbolt
> Controllers again between a Linux and Windows box.
> Functionally it's working well.
>
> Tested-By: Mario Limonciello <mario.limoncie...@dell.com>
>
> Andreas,
>
> Following the history of this thread, I believe Greg was still looking for
> an ack from you that Amir is using the interface properly.
>
> Thanks,

That I don't know, but this driver does the inverse dmi_match of the
current apple driver (dmi_match(DMI_BOARD_VENDOR, "Apple Inc.")), and
therefore there should be no interaction between the two.

Acked-by: Andreas Noever <andreas.noe...@gmail.com>

Cheers,
Andreas

Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Andreas Noever]

On Fri, Oct 21, 2016 at 4:57 PM,   wrote:
>> -Original Message-
>> From: Amir Levy [mailto:amir.jer.l...@intel.com]
>> Sent: Wednesday, September 28, 2016 9:44 AM
>> To: gre...@linuxfoundation.org
>> Cc: andreas.noe...@gmail.com; bhelg...@google.com; cor...@lwn.net;
>> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
>> net...@vger.kernel.org; linux-...@vger.kernel.org; Limonciello, Mario
>> ; thunderbolt-li...@intel.com;
>> mika.westerb...@intel.com; tomas.wink...@intel.com;
>> xiong.y.zh...@intel.com; Amir Levy 
>> Subject: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM)
>> Networking
>>
>> This driver enables Thunderbolt Networking on non-Apple platforms
>> running Linux.
>>
>> Thunderbolt Networking provides peer-to-peer connections to transfer
>> files between computers, perform PC migrations, and/or set up small
>> workgroups with shared storage.
>>
>> This is a virtual connection that emulates an Ethernet adapter that
>> enables Ethernet networking with the benefit of Thunderbolt superfast
>> medium capability.
>>
>> Thunderbolt Networking enables two hosts and several devices that
>> have a Thunderbolt controller to be connected together in a linear
>> (Daisy chain) series from a single port.
>>
>> Thunderbolt Networking for Linux is compatible with Thunderbolt
>> Networking on systems running macOS or Windows and also supports
>> Thunderbolt generation 2 and 3 controllers.
>>
>> Note that all pre-existing Thunderbolt generation 3 features, such as
>> USB, Display and other Thunderbolt device connectivity will continue
>> to function exactly as they did prior to enabling Thunderbolt Networking.
>>
>> Code and Software Specifications:
>> This kernel code creates a virtual ethernet device for computer to
>> computer communication over a Thunderbolt cable.
>> The new driver is a separate driver to the existing Thunderbolt driver.
>> It is designed to work on systems running Linux that
>> interface with Intel Connection Manager (ICM) firmware based
>> Thunderbolt controllers that support Thunderbolt Networking.
>> The kernel code operates in coordination with the Thunderbolt user-
>> space daemon to implement full Thunderbolt networking functionality.
>>
>> Hardware Specifications:
>> Thunderbolt Hardware specs have not yet been published but are used
>> where necessary for register definitions.
>>
>> Changes since v7:
>>  - Removed debug prints
>>  - Edited error prints
>>  - Edited copyright notice
>>  - Changed the Kconfig patch to be after the code changes
>>
>> These patches were pushed to GitHub where they can be reviewed more
>> comfortably with green/red highlighting:
>>   https://github.com/01org/thunderbolt-software-kernel-tree
>>
>> Daemon code:
>>   https://github.com/01org/thunderbolt-software-daemon
>>
>> For reference, here's a link to version 6:
>> [v7]: https://lkml.org/lkml/2016/9/27/244
>>
>> Amir Levy (8):
>>   thunderbolt: Macro rename
>>   thunderbolt: Updating the register definitions
>>   thunderbolt: Communication with the ICM (firmware)
>>   thunderbolt: Networking state machine
>>   thunderbolt: Networking transmit and receive
>>   thunderbolt: Kconfig for Thunderbolt Networking
>>   thunderbolt: Networking doc
>>   thunderbolt: Adding maintainer entry
>>
>>  Documentation/00-INDEX   |2 +
>>  Documentation/thunderbolt/networking.txt |  132 ++
>>  MAINTAINERS  |8 +-
>>  drivers/thunderbolt/Kconfig  |   27 +-
>>  drivers/thunderbolt/Makefile |3 +-
>>  drivers/thunderbolt/icm/Makefile |2 +
>>  drivers/thunderbolt/icm/icm_nhi.c| 1514 
>>  drivers/thunderbolt/icm/icm_nhi.h|   82 ++
>>  drivers/thunderbolt/icm/net.c| 2254
>> ++
>>  drivers/thunderbolt/icm/net.h|  287 
>>  drivers/thunderbolt/nhi_regs.h   |  115 +-
>>  11 files changed, 4417 insertions(+), 9 deletions(-)
>>  create mode 100644 Documentation/thunderbolt/networking.txt
>>  create mode 100644 drivers/thunderbolt/icm/Makefile
>>  create mode 100644 drivers/thunderbolt/icm/icm_nhi.c
>>  create mode 100644 drivers/thunderbolt/icm/icm_nhi.h
>>  create mode 100644 drivers/thunderbolt/icm/net.c
>>  create mode 100644 drivers/thunderbolt/icm/net.h
>>
>> --
>> 2.7.4
>
> Hi Amir,
>
> I've tested your v8 series on Dell hardware with Thunderbolt
> Controllers again between a Linux and Windows box.
> Functionally it's working well.
>
> Tested-By: Mario Limonciello 
>
> Andreas,
>
> Following the history of this thread, I believe Greg was still looking for
> an ack from you that Amir is using the interface properly.
>
> Thanks,

That I don't know, but this driver does the inverse dmi_match of the
current apple driver (dmi_match(DMI_BOARD_VENDOR, "Apple Inc.")), and
therefore there should be no interaction between the two.

Acked-by: Andreas Noever 

Cheers,
Andreas

Re: [PATCH v6 2/8] thunderbolt: Updating the register definitions

[Andreas Noever]

On Mon, Aug 1, 2016 at 2:23 PM, Amir Levy  wrote:
> Adding more Thunderbolt(TM) register definitions
> and some helper macros.

Thinking about this again I would prefer it if you would put your
definitions into a separate file under icm/ (even if there is some
duplication). The style (bitfields vs. genmask) is different between
the drivers and for a reader it is difficult to find out what is
actually supposed to be used by the two drivers (ring_desc vs
tbt_buf_desc or the ring RING_INT_EN/DISABLE macros in the header file
vs. ring_interrupt_active in nhi.c).

This would also completely separate the two drivers.

Andreas


> Signed-off-by: Amir Levy 
> ---
>  drivers/thunderbolt/nhi_regs.h | 109 
> +
>  1 file changed, 109 insertions(+)
>
> diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
> index 75cf069..b8e961f 100644
> --- a/drivers/thunderbolt/nhi_regs.h
> +++ b/drivers/thunderbolt/nhi_regs.h
> @@ -9,6 +9,11 @@
>
>  #include 
>
> +#define NHI_MMIO_BAR 0
> +
> +#define TBT_RING_MIN_NUM_BUFFERS   2
> +#define TBT_RING_MAX_FRAME_SIZE(4 * 1024)
> +
>  enum ring_flags {
> RING_FLAG_ISOCH_ENABLE = 1 << 27, /* TX only? */
> RING_FLAG_E2E_FLOW_CONTROL = 1 << 28,
> @@ -39,6 +44,33 @@ struct ring_desc {
> u32 time; /* write zero */
>  } __packed;
>
> +/**
> + * struct tbt_buf_desc - TX/RX ring buffer descriptor.
> + * This is same as struct ring_desc, but without the use of bitfields and
> + * with explicit endianity.
> + */
> +struct tbt_buf_desc {
> +   __le64 phys;
> +   __le32 attributes;
> +   __le32 time;
> +};
> +
> +#define DESC_ATTR_LEN_SHIFT0
> +#define DESC_ATTR_LEN_MASK GENMASK(11, DESC_ATTR_LEN_SHIFT)
> +#define DESC_ATTR_EOF_SHIFT12
> +#define DESC_ATTR_EOF_MASK GENMASK(15, DESC_ATTR_EOF_SHIFT)
> +#define DESC_ATTR_SOF_SHIFT16
> +#define DESC_ATTR_SOF_MASK GENMASK(19, DESC_ATTR_SOF_SHIFT)
> +#define DESC_ATTR_TX_ISOCH_DMA_EN  BIT(20) /* TX */
> +#define DESC_ATTR_RX_CRC_ERR   BIT(20) /* RX after use */
> +#define DESC_ATTR_DESC_DONEBIT(21)
> +#define DESC_ATTR_REQ_STS  BIT(22) /* TX and RX before use */
> +#define DESC_ATTR_RX_BUF_OVRN_ERR  BIT(22) /* RX after use */
> +#define DESC_ATTR_INT_EN   BIT(23)
> +#define DESC_ATTR_OFFSET_SHIFT 24
> +#define DESC_ATTR_OFFSET_MASK  GENMASK(31, DESC_ATTR_OFFSET_SHIFT)
> +
> +
>  /* NHI registers in bar 0 */
>
>  /*
> @@ -60,6 +92,30 @@ struct ring_desc {
>   */
>  #define REG_RX_RING_BASE   0x08000
>
> +#define REG_RING_STEP  16
> +#define REG_RING_PHYS_LO_OFFSET0
> +#define REG_RING_PHYS_HI_OFFSET4
> +#define REG_RING_CONS_PROD_OFFSET  8   /* cons - RO, prod - RW */
> +#define REG_RING_CONS_SHIFT0
> +#define REG_RING_CONS_MASK GENMASK(15, REG_RING_CONS_SHIFT)
> +#define REG_RING_PROD_SHIFT16
> +#define REG_RING_PROD_MASK GENMASK(31, REG_RING_PROD_SHIFT)
> +#define REG_RING_SIZE_OFFSET   12
> +#define REG_RING_SIZE_SHIFT0
> +#define REG_RING_SIZE_MASK GENMASK(15, REG_RING_SIZE_SHIFT)
> +#define REG_RING_BUF_SIZE_SHIFT16
> +#define REG_RING_BUF_SIZE_MASK GENMASK(27, REG_RING_BUF_SIZE_SHIFT)
> +
> +#define TBT_RING_CONS_PROD_REG(iobase, ringbase, ringnumber) \
> + ((iobase) + (ringbase) + \
> + ((ringnumber) * REG_RING_STEP) + \
> + REG_RING_CONS_PROD_OFFSET)
> +
> +#define TBT_REG_RING_PROD_EXTRACT(val) (((val) & REG_RING_PROD_MASK) >> \
> +  REG_RING_PROD_SHIFT)
> +
> +#define TBT_REG_RING_CONS_EXTRACT(val) (((val) & REG_RING_CONS_MASK) >> \
> +  REG_RING_CONS_SHIFT)
>  /*
>   * 32 bytes per entry, one entry for every hop (REG_HOP_COUNT)
>   * 00: enum_ring_flags
> @@ -77,6 +133,19 @@ struct ring_desc {
>   * ..: unknown
>   */
>  #define REG_RX_OPTIONS_BASE0x29800
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT12
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_MASK \
> +   GENMASK(22, REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT)
> +#define REG_RX_OPTS_MASK_OFFSET4
> +#define REG_RX_OPTS_MASK_EOF_SHIFT 0
> +#define REG_RX_OPTS_MASK_EOF_MASK  GENMASK(15, 
> REG_RX_OPTS_MASK_EOF_SHIFT)
> +#define REG_RX_OPTS_MASK_SOF_SHIFT 16
> +#define REG_RX_OPTS_MASK_SOF_MASK  GENMASK(31, 
> REG_RX_OPTS_MASK_SOF_SHIFT)
> +
> +#define REG_OPTS_STEP  32
> +#define REG_OPTS_E2E_ENBIT(28)
> +#define REG_OPTS_RAW   BIT(30)
> +#define REG_OPTS_VALID BIT(31)
>
>  /*
>   * three bitfields: tx, rx, rx overflow
> @@ -86,6 +155,7 @@ struct 

Re: [PATCH v6 2/8] thunderbolt: Updating the register definitions

[Andreas Noever]

On Mon, Aug 1, 2016 at 2:23 PM, Amir Levy  wrote:
> Adding more Thunderbolt(TM) register definitions
> and some helper macros.

Thinking about this again I would prefer it if you would put your
definitions into a separate file under icm/ (even if there is some
duplication). The style (bitfields vs. genmask) is different between
the drivers and for a reader it is difficult to find out what is
actually supposed to be used by the two drivers (ring_desc vs
tbt_buf_desc or the ring RING_INT_EN/DISABLE macros in the header file
vs. ring_interrupt_active in nhi.c).

This would also completely separate the two drivers.

Andreas


> Signed-off-by: Amir Levy 
> ---
>  drivers/thunderbolt/nhi_regs.h | 109 
> +
>  1 file changed, 109 insertions(+)
>
> diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
> index 75cf069..b8e961f 100644
> --- a/drivers/thunderbolt/nhi_regs.h
> +++ b/drivers/thunderbolt/nhi_regs.h
> @@ -9,6 +9,11 @@
>
>  #include 
>
> +#define NHI_MMIO_BAR 0
> +
> +#define TBT_RING_MIN_NUM_BUFFERS   2
> +#define TBT_RING_MAX_FRAME_SIZE(4 * 1024)
> +
>  enum ring_flags {
> RING_FLAG_ISOCH_ENABLE = 1 << 27, /* TX only? */
> RING_FLAG_E2E_FLOW_CONTROL = 1 << 28,
> @@ -39,6 +44,33 @@ struct ring_desc {
> u32 time; /* write zero */
>  } __packed;
>
> +/**
> + * struct tbt_buf_desc - TX/RX ring buffer descriptor.
> + * This is same as struct ring_desc, but without the use of bitfields and
> + * with explicit endianity.
> + */
> +struct tbt_buf_desc {
> +   __le64 phys;
> +   __le32 attributes;
> +   __le32 time;
> +};
> +
> +#define DESC_ATTR_LEN_SHIFT0
> +#define DESC_ATTR_LEN_MASK GENMASK(11, DESC_ATTR_LEN_SHIFT)
> +#define DESC_ATTR_EOF_SHIFT12
> +#define DESC_ATTR_EOF_MASK GENMASK(15, DESC_ATTR_EOF_SHIFT)
> +#define DESC_ATTR_SOF_SHIFT16
> +#define DESC_ATTR_SOF_MASK GENMASK(19, DESC_ATTR_SOF_SHIFT)
> +#define DESC_ATTR_TX_ISOCH_DMA_EN  BIT(20) /* TX */
> +#define DESC_ATTR_RX_CRC_ERR   BIT(20) /* RX after use */
> +#define DESC_ATTR_DESC_DONEBIT(21)
> +#define DESC_ATTR_REQ_STS  BIT(22) /* TX and RX before use */
> +#define DESC_ATTR_RX_BUF_OVRN_ERR  BIT(22) /* RX after use */
> +#define DESC_ATTR_INT_EN   BIT(23)
> +#define DESC_ATTR_OFFSET_SHIFT 24
> +#define DESC_ATTR_OFFSET_MASK  GENMASK(31, DESC_ATTR_OFFSET_SHIFT)
> +
> +
>  /* NHI registers in bar 0 */
>
>  /*
> @@ -60,6 +92,30 @@ struct ring_desc {
>   */
>  #define REG_RX_RING_BASE   0x08000
>
> +#define REG_RING_STEP  16
> +#define REG_RING_PHYS_LO_OFFSET0
> +#define REG_RING_PHYS_HI_OFFSET4
> +#define REG_RING_CONS_PROD_OFFSET  8   /* cons - RO, prod - RW */
> +#define REG_RING_CONS_SHIFT0
> +#define REG_RING_CONS_MASK GENMASK(15, REG_RING_CONS_SHIFT)
> +#define REG_RING_PROD_SHIFT16
> +#define REG_RING_PROD_MASK GENMASK(31, REG_RING_PROD_SHIFT)
> +#define REG_RING_SIZE_OFFSET   12
> +#define REG_RING_SIZE_SHIFT0
> +#define REG_RING_SIZE_MASK GENMASK(15, REG_RING_SIZE_SHIFT)
> +#define REG_RING_BUF_SIZE_SHIFT16
> +#define REG_RING_BUF_SIZE_MASK GENMASK(27, REG_RING_BUF_SIZE_SHIFT)
> +
> +#define TBT_RING_CONS_PROD_REG(iobase, ringbase, ringnumber) \
> + ((iobase) + (ringbase) + \
> + ((ringnumber) * REG_RING_STEP) + \
> + REG_RING_CONS_PROD_OFFSET)
> +
> +#define TBT_REG_RING_PROD_EXTRACT(val) (((val) & REG_RING_PROD_MASK) >> \
> +  REG_RING_PROD_SHIFT)
> +
> +#define TBT_REG_RING_CONS_EXTRACT(val) (((val) & REG_RING_CONS_MASK) >> \
> +  REG_RING_CONS_SHIFT)
>  /*
>   * 32 bytes per entry, one entry for every hop (REG_HOP_COUNT)
>   * 00: enum_ring_flags
> @@ -77,6 +133,19 @@ struct ring_desc {
>   * ..: unknown
>   */
>  #define REG_RX_OPTIONS_BASE0x29800
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT12
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_MASK \
> +   GENMASK(22, REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT)
> +#define REG_RX_OPTS_MASK_OFFSET4
> +#define REG_RX_OPTS_MASK_EOF_SHIFT 0
> +#define REG_RX_OPTS_MASK_EOF_MASK  GENMASK(15, 
> REG_RX_OPTS_MASK_EOF_SHIFT)
> +#define REG_RX_OPTS_MASK_SOF_SHIFT 16
> +#define REG_RX_OPTS_MASK_SOF_MASK  GENMASK(31, 
> REG_RX_OPTS_MASK_SOF_SHIFT)
> +
> +#define REG_OPTS_STEP  32
> +#define REG_OPTS_E2E_ENBIT(28)
> +#define REG_OPTS_RAW   BIT(30)
> +#define REG_OPTS_VALID BIT(31)
>
>  /*
>   * three bitfields: tx, rx, rx overflow
> @@ -86,6 +155,7 @@ struct ring_desc {
>   */
>  #define REG_RING_NOTIFY_BASE   

Re: [PATCH v6 1/8] thunderbolt: Macro rename

[Andreas Noever]

On Mon, Aug 1, 2016 at 2:23 PM, Amir Levy <amir.jer.l...@intel.com> wrote:
> This first patch updates the registers file to
> reflect that it isn't only for Cactus Ridge.
> No functional change intended.
>
> Signed-off-by: Amir Levy <amir.jer.l...@intel.com>
> ---
>  drivers/thunderbolt/nhi_regs.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
> index 86b996c..75cf069 100644
> --- a/drivers/thunderbolt/nhi_regs.h
> +++ b/drivers/thunderbolt/nhi_regs.h
> @@ -1,11 +1,11 @@
>  /*
> - * Thunderbolt Cactus Ridge driver - NHI registers
> + * Thunderbolt driver - NHI registers
>   *
>   * Copyright (c) 2014 Andreas Noever <andreas.noe...@gmail.com>
>   */
>
> -#ifndef DSL3510_REGS_H_
> -#define DSL3510_REGS_H_
> +#ifndef NHI_REGS_H_
> +#define NHI_REGS_H_
>
>  #include 
>
> --
> 2.7.4
Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>

Re: [PATCH v6 1/8] thunderbolt: Macro rename

[Andreas Noever]

On Mon, Aug 1, 2016 at 2:23 PM, Amir Levy  wrote:
> This first patch updates the registers file to
> reflect that it isn't only for Cactus Ridge.
> No functional change intended.
>
> Signed-off-by: Amir Levy 
> ---
>  drivers/thunderbolt/nhi_regs.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
> index 86b996c..75cf069 100644
> --- a/drivers/thunderbolt/nhi_regs.h
> +++ b/drivers/thunderbolt/nhi_regs.h
> @@ -1,11 +1,11 @@
>  /*
> - * Thunderbolt Cactus Ridge driver - NHI registers
> + * Thunderbolt driver - NHI registers
>   *
>   * Copyright (c) 2014 Andreas Noever 
>   */
>
> -#ifndef DSL3510_REGS_H_
> -#define DSL3510_REGS_H_
> +#ifndef NHI_REGS_H_
> +#define NHI_REGS_H_
>
>  #include 
>
> --
> 2.7.4
Signed-off-by: Andreas Noever 

Re: [PATCH v6 0/8] thunderbolt: Introducing Thunderbolt(TM) networking

[Andreas Noever]

On Wed, Aug 31, 2016 at 1:28 PM, Greg KH  wrote:
> On Mon, Aug 01, 2016 at 03:23:45PM +0300, Amir Levy wrote:
>> This is version 6 of Thunderbolt(TM) driver for non-Apple hardware.
>>
>> Changes since v5:
>>  - Removed the padding of short packets in receive
>>  - Replaced RW semaphore with mutex
>>  - Cleanup
>>
>> These patches were pushed to GitHub where they can be reviewed more
>> comfortably with green/red highlighting:
>>   https://github.com/01org/thunderbolt-software-kernel-tree
>>
>> Daemon code:
>>   https://github.com/01org/thunderbolt-software-daemon
>>
>> For reference, here's a link to version 5:
>> [v5]: https://lkml.org/lkml/2016/7/28/85
>
> Without acks from the thunderbolt maintainer, or any network driver
> developers, I'm not going to take this series.  Please work to get that
> review.

Sorry for the late response. I was away for the last two weeks and
will be away again for the next week.

This driver is independent from mine. It uses an interface provided by
the firmware which is not present on Apple hardware and with which I
am not familiar (also it does networking, not pci with which I am also
not familiar). So I cannot comment on the driver itself. I don't mind
a second driver, if that is what you are asking.

Andreas

Re: [PATCH v6 0/8] thunderbolt: Introducing Thunderbolt(TM) networking

[Andreas Noever]

On Wed, Aug 31, 2016 at 1:28 PM, Greg KH  wrote:
> On Mon, Aug 01, 2016 at 03:23:45PM +0300, Amir Levy wrote:
>> This is version 6 of Thunderbolt(TM) driver for non-Apple hardware.
>>
>> Changes since v5:
>>  - Removed the padding of short packets in receive
>>  - Replaced RW semaphore with mutex
>>  - Cleanup
>>
>> These patches were pushed to GitHub where they can be reviewed more
>> comfortably with green/red highlighting:
>>   https://github.com/01org/thunderbolt-software-kernel-tree
>>
>> Daemon code:
>>   https://github.com/01org/thunderbolt-software-daemon
>>
>> For reference, here's a link to version 5:
>> [v5]: https://lkml.org/lkml/2016/7/28/85
>
> Without acks from the thunderbolt maintainer, or any network driver
> developers, I'm not going to take this series.  Please work to get that
> review.

Sorry for the late response. I was away for the last two weeks and
will be away again for the next week.

This driver is independent from mine. It uses an interface provided by
the firmware which is not present on Apple hardware and with which I
am not familiar (also it does networking, not pci with which I am also
not familiar). So I cannot comment on the driver itself. I don't mind
a second driver, if that is what you are asking.

Andreas

Re: [PATCH] thunderbolt: Don't declare Falcon Ridge unsupported

[Andreas Noever]

On Wed, Aug 3, 2016 at 10:44 AM, Lukas Wunner <lu...@wunner.de> wrote:
> Falcon Ridge 4C has been supported by the driver from the beginning,
> Falcon Ridge 2C support was just added. Don't irritate users with a
> warning declaring the opposite.
>
> Cc: Andreas Noever <andreas.noe...@gmail.com>
> Signed-off-by: Lukas Wunner <lu...@wunner.de>
Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>

> ---
>  drivers/thunderbolt/switch.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index 1e116f5..9840fde 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -372,7 +372,9 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, u64 
> route)
>
> if (sw->config.device_id != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
> sw->config.device_id != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
> -   sw->config.device_id != PCI_DEVICE_ID_INTEL_PORT_RIDGE)
> +   sw->config.device_id != PCI_DEVICE_ID_INTEL_PORT_RIDGE &&
> +   sw->config.device_id != 
> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE &&
> +   sw->config.device_id != 
> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE)
> tb_sw_warn(sw, "unsupported switch device id %#x\n",
>sw->config.device_id);
>
> --
> 2.8.1
>

Re: [PATCH] thunderbolt: Don't declare Falcon Ridge unsupported

[Andreas Noever]

On Wed, Aug 3, 2016 at 10:44 AM, Lukas Wunner  wrote:
> Falcon Ridge 4C has been supported by the driver from the beginning,
> Falcon Ridge 2C support was just added. Don't irritate users with a
> warning declaring the opposite.
>
> Cc: Andreas Noever 
> Signed-off-by: Lukas Wunner 
Signed-off-by: Andreas Noever 

> ---
>  drivers/thunderbolt/switch.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index 1e116f5..9840fde 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -372,7 +372,9 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, u64 
> route)
>
> if (sw->config.device_id != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
> sw->config.device_id != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
> -   sw->config.device_id != PCI_DEVICE_ID_INTEL_PORT_RIDGE)
> +   sw->config.device_id != PCI_DEVICE_ID_INTEL_PORT_RIDGE &&
> +   sw->config.device_id != 
> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE &&
> +   sw->config.device_id != 
> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE)
> tb_sw_warn(sw, "unsupported switch device id %#x\n",
>sw->config.device_id);
>
> --
> 2.8.1
>

Re: [PATCH 2/2] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.

[Andreas Noever]

On Wed, Jul 27, 2016 at 10:11 AM, Xavier Gnata <xavier.gn...@gmail.com> wrote:
>
>
> On 26/07/2016 18:40, Andreas Noever wrote:
>>
>> From: Xavier Gnata <xavier.gn...@gmail.com>
>>
>> From: Xavier Gnata <xavier.gn...@gmail.com>
>>
>> Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk
>> to support suspend/resume.
>> Tested against 4.7 master on a MacBook Air 11" 2015.
>>
>> Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
>> ---
>>  drivers/pci/quirks.c  | 4 
>>  drivers/thunderbolt/nhi.c | 6 ++
>>  2 files changed, 10 insertions(+)
>>
>> Rebased version of Xavier's patch.
>>
>> Xavier, could you verify that this still works on your system?
>>
> It does work on my system.
>
> Thanks,
> Xavier

Cool.

Greg, can we still get these into the current merge window?

Andreas

>
>> Thanks,
>> Andreas
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 75b2105..981f17d 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3325,6 +3325,7 @@ static void quirk_apple_wait_for_thunderbolt(struct
>> pci_dev *dev)
>> if (nhi->vendor != PCI_VENDOR_ID_INTEL
>> || (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
>> nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C
>> &&
>> +   nhi->device !=
>> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI &&
>> nhi->device !=
>> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
>> || nhi->class != PCI_CLASS_SYSTEM_OTHER << 8)
>> goto out;
>> @@ -3341,6 +3342,9 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
>>quirk_apple_wait_for_thunderbolt);
>>  DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>> +  PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE,
>> +  quirk_apple_wait_for_thunderbolt);
>> +DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE,
>>quirk_apple_wait_for_thunderbolt);
>>  #endif
>> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
>> index 9c15344..a8c2041 100644
>> --- a/drivers/thunderbolt/nhi.c
>> +++ b/drivers/thunderbolt/nhi.c
>> @@ -651,6 +651,12 @@ static struct pci_device_id nhi_ids[] = {
>> {
>> .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
>> .vendor = PCI_VENDOR_ID_INTEL,
>> +   .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI,
>> +   .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> +   },
>> +   {
>> +   .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
>> +   .vendor = PCI_VENDOR_ID_INTEL,
>> .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI,
>> .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> },
>>
>

Re: [PATCH 2/2] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.

[Andreas Noever]

On Wed, Jul 27, 2016 at 10:11 AM, Xavier Gnata  wrote:
>
>
> On 26/07/2016 18:40, Andreas Noever wrote:
>>
>> From: Xavier Gnata 
>>
>> From: Xavier Gnata 
>>
>> Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk
>> to support suspend/resume.
>> Tested against 4.7 master on a MacBook Air 11" 2015.
>>
>> Signed-off-by: Andreas Noever 
>> ---
>>  drivers/pci/quirks.c  | 4 
>>  drivers/thunderbolt/nhi.c | 6 ++
>>  2 files changed, 10 insertions(+)
>>
>> Rebased version of Xavier's patch.
>>
>> Xavier, could you verify that this still works on your system?
>>
> It does work on my system.
>
> Thanks,
> Xavier

Cool.

Greg, can we still get these into the current merge window?

Andreas

>
>> Thanks,
>> Andreas
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 75b2105..981f17d 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3325,6 +3325,7 @@ static void quirk_apple_wait_for_thunderbolt(struct
>> pci_dev *dev)
>> if (nhi->vendor != PCI_VENDOR_ID_INTEL
>> || (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
>> nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C
>> &&
>> +   nhi->device !=
>> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI &&
>> nhi->device !=
>> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
>> || nhi->class != PCI_CLASS_SYSTEM_OTHER << 8)
>> goto out;
>> @@ -3341,6 +3342,9 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
>>quirk_apple_wait_for_thunderbolt);
>>  DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>> +  PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE,
>> +  quirk_apple_wait_for_thunderbolt);
>> +DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE,
>>quirk_apple_wait_for_thunderbolt);
>>  #endif
>> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
>> index 9c15344..a8c2041 100644
>> --- a/drivers/thunderbolt/nhi.c
>> +++ b/drivers/thunderbolt/nhi.c
>> @@ -651,6 +651,12 @@ static struct pci_device_id nhi_ids[] = {
>> {
>> .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
>> .vendor = PCI_VENDOR_ID_INTEL,
>> +   .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI,
>> +   .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> +   },
>> +   {
>> +   .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
>> +   .vendor = PCI_VENDOR_ID_INTEL,
>> .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI,
>> .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> },
>>
>

[PATCH 1/2] thunderbolt: Fix resume quirk for Falcon Ridge 4C.

[Andreas Noever]

The quirk 'quirk_apple_wait_for_thunderbolt' did not fire on Falcon
Ridge 4C controllers with subdevice/subvendor set to zero. This lead
to lost pci devices on system resume.

Older thunderbolt controllers (pre Falcon Ridge) used the same device id
for bridges and for the controller. On Apple hardware the subvendor- &
subdevice-ids were set for the controller, but not for bridges. So that
is what was used to differentiate between the two. Starting with Falcon
Ridge bridges and controllers received different device ids.
Additionally on some MacBookPro models (but not all) the
subvendor/subdevice was zeroed.

Starting with a42fb351c (thunderbolt: Allow loading of module on recent
Apple MacBooks with thunderbolt 2 controller) the thunderbolt driver
binds to all Falcon Ridge 4C controllers (irregardless of
subvendor/subdevice). The corresponding quirk was not updated.

This commit changes the quirk to check the device class instead of its
subvendor-/subdeviceids. This works for all generations of Thunderbolt
controllers.

Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
---
 drivers/pci/quirks.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index ee72ebe..75b2105 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3326,8 +3326,7 @@ static void quirk_apple_wait_for_thunderbolt(struct 
pci_dev *dev)
|| (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
-   || nhi->subsystem_vendor != 0x
-   || nhi->subsystem_device != 0x)
+   || nhi->class != PCI_CLASS_SYSTEM_OTHER << 8)
goto out;
dev_info(>dev, "quirk: waiting for thunderbolt to reestablish PCI 
tunnels...\n");
device_pm_wait_for_dev(>dev, >dev);
-- 
2.9.0

[PATCH 2/2] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.

[Andreas Noever]

From: Xavier Gnata <xavier.gn...@gmail.com>

From: Xavier Gnata <xavier.gn...@gmail.com>

Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk
to support suspend/resume.
Tested against 4.7 master on a MacBook Air 11" 2015.

Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
---
 drivers/pci/quirks.c  | 4 
 drivers/thunderbolt/nhi.c | 6 ++
 2 files changed, 10 insertions(+)

Rebased version of Xavier's patch.

Xavier, could you verify that this still works on your system?

Thanks,
Andreas

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 75b2105..981f17d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3325,6 +3325,7 @@ static void quirk_apple_wait_for_thunderbolt(struct 
pci_dev *dev)
if (nhi->vendor != PCI_VENDOR_ID_INTEL
|| (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
+   nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI 
&&
nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
|| nhi->class != PCI_CLASS_SYSTEM_OTHER << 8)
goto out;
@@ -3341,6 +3342,9 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
   PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
   quirk_apple_wait_for_thunderbolt);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
+  PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE,
+  quirk_apple_wait_for_thunderbolt);
+DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
   PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE,
   quirk_apple_wait_for_thunderbolt);
 #endif
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 9c15344..a8c2041 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -651,6 +651,12 @@ static struct pci_device_id nhi_ids[] = {
{
.class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
.vendor = PCI_VENDOR_ID_INTEL,
+   .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI,
+   .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
+   },
+   {
+   .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
+   .vendor = PCI_VENDOR_ID_INTEL,
.device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI,
.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
},
-- 
2.9.0

[PATCH 1/2] thunderbolt: Fix resume quirk for Falcon Ridge 4C.

[Andreas Noever]

The quirk 'quirk_apple_wait_for_thunderbolt' did not fire on Falcon
Ridge 4C controllers with subdevice/subvendor set to zero. This lead
to lost pci devices on system resume.

Older thunderbolt controllers (pre Falcon Ridge) used the same device id
for bridges and for the controller. On Apple hardware the subvendor- &
subdevice-ids were set for the controller, but not for bridges. So that
is what was used to differentiate between the two. Starting with Falcon
Ridge bridges and controllers received different device ids.
Additionally on some MacBookPro models (but not all) the
subvendor/subdevice was zeroed.

Starting with a42fb351c (thunderbolt: Allow loading of module on recent
Apple MacBooks with thunderbolt 2 controller) the thunderbolt driver
binds to all Falcon Ridge 4C controllers (irregardless of
subvendor/subdevice). The corresponding quirk was not updated.

This commit changes the quirk to check the device class instead of its
subvendor-/subdeviceids. This works for all generations of Thunderbolt
controllers.

Signed-off-by: Andreas Noever 
---
 drivers/pci/quirks.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index ee72ebe..75b2105 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3326,8 +3326,7 @@ static void quirk_apple_wait_for_thunderbolt(struct 
pci_dev *dev)
|| (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
-   || nhi->subsystem_vendor != 0x
-   || nhi->subsystem_device != 0x)
+   || nhi->class != PCI_CLASS_SYSTEM_OTHER << 8)
goto out;
dev_info(>dev, "quirk: waiting for thunderbolt to reestablish PCI 
tunnels...\n");
device_pm_wait_for_dev(>dev, >dev);
-- 
2.9.0

[PATCH 2/2] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.

[Andreas Noever]

From: Xavier Gnata 

From: Xavier Gnata 

Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk
to support suspend/resume.
Tested against 4.7 master on a MacBook Air 11" 2015.

Signed-off-by: Andreas Noever 
---
 drivers/pci/quirks.c  | 4 
 drivers/thunderbolt/nhi.c | 6 ++
 2 files changed, 10 insertions(+)

Rebased version of Xavier's patch.

Xavier, could you verify that this still works on your system?

Thanks,
Andreas

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 75b2105..981f17d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3325,6 +3325,7 @@ static void quirk_apple_wait_for_thunderbolt(struct 
pci_dev *dev)
if (nhi->vendor != PCI_VENDOR_ID_INTEL
|| (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
+   nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI 
&&
nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
|| nhi->class != PCI_CLASS_SYSTEM_OTHER << 8)
goto out;
@@ -3341,6 +3342,9 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
   PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
   quirk_apple_wait_for_thunderbolt);
 DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
+  PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE,
+  quirk_apple_wait_for_thunderbolt);
+DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
   PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE,
   quirk_apple_wait_for_thunderbolt);
 #endif
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 9c15344..a8c2041 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -651,6 +651,12 @@ static struct pci_device_id nhi_ids[] = {
{
.class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
.vendor = PCI_VENDOR_ID_INTEL,
+   .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI,
+   .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
+   },
+   {
+   .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
+   .vendor = PCI_VENDOR_ID_INTEL,
.device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI,
.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
},
-- 
2.9.0

Re: [PATCH v4 2/7] thunderbolt: Updating the register definitions

[Andreas Noever]

On Mon, Jul 18, 2016 at 12:00 PM, Amir Levy  wrote:
> Adding more Thunderbolt(TM) register definitions
> and some helper macros.
>
> Signed-off-by: Amir Levy 
> ---
>  drivers/thunderbolt/nhi_regs.h | 109 
> +
>  1 file changed, 109 insertions(+)
>
> diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
> index 75cf069..b8e961f 100644
> --- a/drivers/thunderbolt/nhi_regs.h
> +++ b/drivers/thunderbolt/nhi_regs.h
> @@ -9,6 +9,11 @@
>
>  #include 
>
> +#define NHI_MMIO_BAR 0
> +
> +#define TBT_RING_MIN_NUM_BUFFERS   2
> +#define TBT_RING_MAX_FRAME_SIZE(4 * 1024)
> +
>  enum ring_flags {
> RING_FLAG_ISOCH_ENABLE = 1 << 27, /* TX only? */
> RING_FLAG_E2E_FLOW_CONTROL = 1 << 28,
> @@ -39,6 +44,33 @@ struct ring_desc {
> u32 time; /* write zero */
>  } __packed;
>
> +/**
> + * struct tbt_buf_desc - TX/RX ring buffer descriptor.
> + * This is same as struct ring_desc, but without the use of bitfields and
> + * with explicit endianity.
> + */
> +struct tbt_buf_desc {
> +   __le64 phys;
> +   __le32 attributes;
> +   __le32 time;
> +};
Does sharing this file make sense? The style seems to be quite
different (structs with bitfields vs explicit bit-access). I think I
would prefer separate register definitions, unless you are reusing a
substantial amount (I have not checked).

Andreas

> +
> +#define DESC_ATTR_LEN_SHIFT0
> +#define DESC_ATTR_LEN_MASK GENMASK(11, DESC_ATTR_LEN_SHIFT)
> +#define DESC_ATTR_EOF_SHIFT12
> +#define DESC_ATTR_EOF_MASK GENMASK(15, DESC_ATTR_EOF_SHIFT)
> +#define DESC_ATTR_SOF_SHIFT16
> +#define DESC_ATTR_SOF_MASK GENMASK(19, DESC_ATTR_SOF_SHIFT)
> +#define DESC_ATTR_TX_ISOCH_DMA_EN  BIT(20) /* TX */
> +#define DESC_ATTR_RX_CRC_ERR   BIT(20) /* RX after use */
> +#define DESC_ATTR_DESC_DONEBIT(21)
> +#define DESC_ATTR_REQ_STS  BIT(22) /* TX and RX before use */
> +#define DESC_ATTR_RX_BUF_OVRN_ERR  BIT(22) /* RX after use */
> +#define DESC_ATTR_INT_EN   BIT(23)
> +#define DESC_ATTR_OFFSET_SHIFT 24
> +#define DESC_ATTR_OFFSET_MASK  GENMASK(31, DESC_ATTR_OFFSET_SHIFT)
> +
> +
>  /* NHI registers in bar 0 */
>
>  /*
> @@ -60,6 +92,30 @@ struct ring_desc {
>   */
>  #define REG_RX_RING_BASE   0x08000
>
> +#define REG_RING_STEP  16
> +#define REG_RING_PHYS_LO_OFFSET0
> +#define REG_RING_PHYS_HI_OFFSET4
> +#define REG_RING_CONS_PROD_OFFSET  8   /* cons - RO, prod - RW */
> +#define REG_RING_CONS_SHIFT0
> +#define REG_RING_CONS_MASK GENMASK(15, REG_RING_CONS_SHIFT)
> +#define REG_RING_PROD_SHIFT16
> +#define REG_RING_PROD_MASK GENMASK(31, REG_RING_PROD_SHIFT)
> +#define REG_RING_SIZE_OFFSET   12
> +#define REG_RING_SIZE_SHIFT0
> +#define REG_RING_SIZE_MASK GENMASK(15, REG_RING_SIZE_SHIFT)
> +#define REG_RING_BUF_SIZE_SHIFT16
> +#define REG_RING_BUF_SIZE_MASK GENMASK(27, REG_RING_BUF_SIZE_SHIFT)
> +
> +#define TBT_RING_CONS_PROD_REG(iobase, ringbase, ringnumber) \
> + ((iobase) + (ringbase) + \
> + ((ringnumber) * REG_RING_STEP) + \
> + REG_RING_CONS_PROD_OFFSET)
> +
> +#define TBT_REG_RING_PROD_EXTRACT(val) (((val) & REG_RING_PROD_MASK) >> \
> +  REG_RING_PROD_SHIFT)
> +
> +#define TBT_REG_RING_CONS_EXTRACT(val) (((val) & REG_RING_CONS_MASK) >> \
> +  REG_RING_CONS_SHIFT)
>  /*
>   * 32 bytes per entry, one entry for every hop (REG_HOP_COUNT)
>   * 00: enum_ring_flags
> @@ -77,6 +133,19 @@ struct ring_desc {
>   * ..: unknown
>   */
>  #define REG_RX_OPTIONS_BASE0x29800
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT12
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_MASK \
> +   GENMASK(22, REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT)
> +#define REG_RX_OPTS_MASK_OFFSET4
> +#define REG_RX_OPTS_MASK_EOF_SHIFT 0
> +#define REG_RX_OPTS_MASK_EOF_MASK  GENMASK(15, 
> REG_RX_OPTS_MASK_EOF_SHIFT)
> +#define REG_RX_OPTS_MASK_SOF_SHIFT 16
> +#define REG_RX_OPTS_MASK_SOF_MASK  GENMASK(31, 
> REG_RX_OPTS_MASK_SOF_SHIFT)
> +
> +#define REG_OPTS_STEP  32
> +#define REG_OPTS_E2E_ENBIT(28)
> +#define REG_OPTS_RAW   BIT(30)
> +#define REG_OPTS_VALID BIT(31)
>
>  /*
>   * three bitfields: tx, rx, rx overflow
> @@ -86,6 +155,7 @@ struct ring_desc {
>   */
>  #define REG_RING_NOTIFY_BASE   0x37800
>  #define RING_NOTIFY_REG_COUNT(nhi) ((31 + 3 * nhi->hop_count) / 32)
> +#define REG_RING_NOTIFY_STEP   4
>
>  /*
>   * two bitfields: rx, tx
> @@ -94,8 +164,47 @@ struct ring_desc {
>   */
>  

Re: [PATCH v4 2/7] thunderbolt: Updating the register definitions

[Andreas Noever]

On Mon, Jul 18, 2016 at 12:00 PM, Amir Levy  wrote:
> Adding more Thunderbolt(TM) register definitions
> and some helper macros.
>
> Signed-off-by: Amir Levy 
> ---
>  drivers/thunderbolt/nhi_regs.h | 109 
> +
>  1 file changed, 109 insertions(+)
>
> diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
> index 75cf069..b8e961f 100644
> --- a/drivers/thunderbolt/nhi_regs.h
> +++ b/drivers/thunderbolt/nhi_regs.h
> @@ -9,6 +9,11 @@
>
>  #include 
>
> +#define NHI_MMIO_BAR 0
> +
> +#define TBT_RING_MIN_NUM_BUFFERS   2
> +#define TBT_RING_MAX_FRAME_SIZE(4 * 1024)
> +
>  enum ring_flags {
> RING_FLAG_ISOCH_ENABLE = 1 << 27, /* TX only? */
> RING_FLAG_E2E_FLOW_CONTROL = 1 << 28,
> @@ -39,6 +44,33 @@ struct ring_desc {
> u32 time; /* write zero */
>  } __packed;
>
> +/**
> + * struct tbt_buf_desc - TX/RX ring buffer descriptor.
> + * This is same as struct ring_desc, but without the use of bitfields and
> + * with explicit endianity.
> + */
> +struct tbt_buf_desc {
> +   __le64 phys;
> +   __le32 attributes;
> +   __le32 time;
> +};
Does sharing this file make sense? The style seems to be quite
different (structs with bitfields vs explicit bit-access). I think I
would prefer separate register definitions, unless you are reusing a
substantial amount (I have not checked).

Andreas

> +
> +#define DESC_ATTR_LEN_SHIFT0
> +#define DESC_ATTR_LEN_MASK GENMASK(11, DESC_ATTR_LEN_SHIFT)
> +#define DESC_ATTR_EOF_SHIFT12
> +#define DESC_ATTR_EOF_MASK GENMASK(15, DESC_ATTR_EOF_SHIFT)
> +#define DESC_ATTR_SOF_SHIFT16
> +#define DESC_ATTR_SOF_MASK GENMASK(19, DESC_ATTR_SOF_SHIFT)
> +#define DESC_ATTR_TX_ISOCH_DMA_EN  BIT(20) /* TX */
> +#define DESC_ATTR_RX_CRC_ERR   BIT(20) /* RX after use */
> +#define DESC_ATTR_DESC_DONEBIT(21)
> +#define DESC_ATTR_REQ_STS  BIT(22) /* TX and RX before use */
> +#define DESC_ATTR_RX_BUF_OVRN_ERR  BIT(22) /* RX after use */
> +#define DESC_ATTR_INT_EN   BIT(23)
> +#define DESC_ATTR_OFFSET_SHIFT 24
> +#define DESC_ATTR_OFFSET_MASK  GENMASK(31, DESC_ATTR_OFFSET_SHIFT)
> +
> +
>  /* NHI registers in bar 0 */
>
>  /*
> @@ -60,6 +92,30 @@ struct ring_desc {
>   */
>  #define REG_RX_RING_BASE   0x08000
>
> +#define REG_RING_STEP  16
> +#define REG_RING_PHYS_LO_OFFSET0
> +#define REG_RING_PHYS_HI_OFFSET4
> +#define REG_RING_CONS_PROD_OFFSET  8   /* cons - RO, prod - RW */
> +#define REG_RING_CONS_SHIFT0
> +#define REG_RING_CONS_MASK GENMASK(15, REG_RING_CONS_SHIFT)
> +#define REG_RING_PROD_SHIFT16
> +#define REG_RING_PROD_MASK GENMASK(31, REG_RING_PROD_SHIFT)
> +#define REG_RING_SIZE_OFFSET   12
> +#define REG_RING_SIZE_SHIFT0
> +#define REG_RING_SIZE_MASK GENMASK(15, REG_RING_SIZE_SHIFT)
> +#define REG_RING_BUF_SIZE_SHIFT16
> +#define REG_RING_BUF_SIZE_MASK GENMASK(27, REG_RING_BUF_SIZE_SHIFT)
> +
> +#define TBT_RING_CONS_PROD_REG(iobase, ringbase, ringnumber) \
> + ((iobase) + (ringbase) + \
> + ((ringnumber) * REG_RING_STEP) + \
> + REG_RING_CONS_PROD_OFFSET)
> +
> +#define TBT_REG_RING_PROD_EXTRACT(val) (((val) & REG_RING_PROD_MASK) >> \
> +  REG_RING_PROD_SHIFT)
> +
> +#define TBT_REG_RING_CONS_EXTRACT(val) (((val) & REG_RING_CONS_MASK) >> \
> +  REG_RING_CONS_SHIFT)
>  /*
>   * 32 bytes per entry, one entry for every hop (REG_HOP_COUNT)
>   * 00: enum_ring_flags
> @@ -77,6 +133,19 @@ struct ring_desc {
>   * ..: unknown
>   */
>  #define REG_RX_OPTIONS_BASE0x29800
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT12
> +#define REG_RX_OPTS_TX_E2E_HOP_ID_MASK \
> +   GENMASK(22, REG_RX_OPTS_TX_E2E_HOP_ID_SHIFT)
> +#define REG_RX_OPTS_MASK_OFFSET4
> +#define REG_RX_OPTS_MASK_EOF_SHIFT 0
> +#define REG_RX_OPTS_MASK_EOF_MASK  GENMASK(15, 
> REG_RX_OPTS_MASK_EOF_SHIFT)
> +#define REG_RX_OPTS_MASK_SOF_SHIFT 16
> +#define REG_RX_OPTS_MASK_SOF_MASK  GENMASK(31, 
> REG_RX_OPTS_MASK_SOF_SHIFT)
> +
> +#define REG_OPTS_STEP  32
> +#define REG_OPTS_E2E_ENBIT(28)
> +#define REG_OPTS_RAW   BIT(30)
> +#define REG_OPTS_VALID BIT(31)
>
>  /*
>   * three bitfields: tx, rx, rx overflow
> @@ -86,6 +155,7 @@ struct ring_desc {
>   */
>  #define REG_RING_NOTIFY_BASE   0x37800
>  #define RING_NOTIFY_REG_COUNT(nhi) ((31 + 3 * nhi->hop_count) / 32)
> +#define REG_RING_NOTIFY_STEP   4
>
>  /*
>   * two bitfields: rx, tx
> @@ -94,8 +164,47 @@ struct ring_desc {
>   */
>  #define REG_RING_INTERRUPT_BASE0x38200
>  

Re: [PATCH v4 0/7] thunderbolt: Introducing Thunderbolt(TM) networking

[Andreas Noever]

On Wed, Jul 20, 2016 at 12:02 AM, Bjorn Helgaas  wrote:
> On Mon, Jul 18, 2016 at 01:00:33PM +0300, Amir Levy wrote:
>> This is version 4 of Thunderbolt(TM) driver for non-Apple hardware.
>>
>> Changes since v3:
>>  - Moved new Thunderbolt device IDs from pci_ids.h to icm_nhi.h.
>>  - Cleanup and added some comments in code.
>>
>> These patches were pushed to GitHub where they can be reviewed more
>> comfortably with green/red highlighting:
>>   https://github.com/01org/thunderbolt-software-kernel-tree
>>
>> Daemon code:
>>   https://github.com/01org/thunderbolt-software-daemon
>>
>> For reference, here's a link to version 3:
>> [v3]: https://lkml.org/lkml/2016/7/14/311
>>
>> Amir Levy (7):
>>   thunderbolt: Macro rename
>>   thunderbolt: Updating the register definitions
>>   thunderbolt: Kconfig for Thunderbolt(TM) networking
>>   thunderbolt: Communication with the ICM (firmware)
>>   thunderbolt: Networking state machine
>>   thunderbolt: Networking transmit and receive
>>   thunderbolt: Networking doc
>>
>>  Documentation/00-INDEX   |2 +
>>  Documentation/thunderbolt-networking.txt |  135 ++
>>  drivers/thunderbolt/Kconfig  |   25 +-
>>  drivers/thunderbolt/Makefile |3 +-
>>  drivers/thunderbolt/icm/Makefile |   28 +
>>  drivers/thunderbolt/icm/icm_nhi.c| 1642 +
>>  drivers/thunderbolt/icm/icm_nhi.h|   93 ++
>>  drivers/thunderbolt/icm/net.c| 2276 
>> ++
>>  drivers/thunderbolt/icm/net.h|  274 
>>  drivers/thunderbolt/nhi_regs.h   |  115 +-
>>  10 files changed, 4585 insertions(+), 8 deletions(-)
>>  create mode 100644 Documentation/thunderbolt-networking.txt
>>  create mode 100644 drivers/thunderbolt/icm/Makefile
>>  create mode 100644 drivers/thunderbolt/icm/icm_nhi.c
>>  create mode 100644 drivers/thunderbolt/icm/icm_nhi.h
>>  create mode 100644 drivers/thunderbolt/icm/net.c
>>  create mode 100644 drivers/thunderbolt/icm/net.h
>
> Andreas, I assume you'll handle this.
No, this is a separate driver.

Re: [PATCH v4 0/7] thunderbolt: Introducing Thunderbolt(TM) networking

[Andreas Noever]

On Wed, Jul 20, 2016 at 12:02 AM, Bjorn Helgaas  wrote:
> On Mon, Jul 18, 2016 at 01:00:33PM +0300, Amir Levy wrote:
>> This is version 4 of Thunderbolt(TM) driver for non-Apple hardware.
>>
>> Changes since v3:
>>  - Moved new Thunderbolt device IDs from pci_ids.h to icm_nhi.h.
>>  - Cleanup and added some comments in code.
>>
>> These patches were pushed to GitHub where they can be reviewed more
>> comfortably with green/red highlighting:
>>   https://github.com/01org/thunderbolt-software-kernel-tree
>>
>> Daemon code:
>>   https://github.com/01org/thunderbolt-software-daemon
>>
>> For reference, here's a link to version 3:
>> [v3]: https://lkml.org/lkml/2016/7/14/311
>>
>> Amir Levy (7):
>>   thunderbolt: Macro rename
>>   thunderbolt: Updating the register definitions
>>   thunderbolt: Kconfig for Thunderbolt(TM) networking
>>   thunderbolt: Communication with the ICM (firmware)
>>   thunderbolt: Networking state machine
>>   thunderbolt: Networking transmit and receive
>>   thunderbolt: Networking doc
>>
>>  Documentation/00-INDEX   |2 +
>>  Documentation/thunderbolt-networking.txt |  135 ++
>>  drivers/thunderbolt/Kconfig  |   25 +-
>>  drivers/thunderbolt/Makefile |3 +-
>>  drivers/thunderbolt/icm/Makefile |   28 +
>>  drivers/thunderbolt/icm/icm_nhi.c| 1642 +
>>  drivers/thunderbolt/icm/icm_nhi.h|   93 ++
>>  drivers/thunderbolt/icm/net.c| 2276 
>> ++
>>  drivers/thunderbolt/icm/net.h|  274 
>>  drivers/thunderbolt/nhi_regs.h   |  115 +-
>>  10 files changed, 4585 insertions(+), 8 deletions(-)
>>  create mode 100644 Documentation/thunderbolt-networking.txt
>>  create mode 100644 drivers/thunderbolt/icm/Makefile
>>  create mode 100644 drivers/thunderbolt/icm/icm_nhi.c
>>  create mode 100644 drivers/thunderbolt/icm/icm_nhi.h
>>  create mode 100644 drivers/thunderbolt/icm/net.c
>>  create mode 100644 drivers/thunderbolt/icm/net.h
>
> Andreas, I assume you'll handle this.
No, this is a separate driver.

Re: [PATCH v2 0/8] thunderbolt: Introducing Thunderbolt(TM) networking

[Andreas Noever]

On Tue, Jul 12, 2016 at 12:50 PM, Levy, Amir (Jer)
 wrote:
> On Wed, Jun 29 2016, 11:35 AM, Levy, Amir (Jer) wrote:
>> This is version 2 of Thunderbolt(TM) driver for non-Apple hardware.
>>
>> Changes since v1:
>>  - Separation to 2 modules.
>>  - Moved ICM specific registers definition to ICM header file.
>>  - Added new Thunderbolt device IDs.
>>  - Renamed the Thunderbolt networking documentation.
>>  - General cleanups
>>
>> These patches were pushed to GitHub where they can be reviewed more
>> comfortably with green/red highlighting:
>>   https://github.com/01org/thunderbolt-software-kernel-tree
>>
>> Daemon code:
>>   https://github.com/01org/thunderbolt-software-daemon
>>
>> For reference, here's a link to version 1:
>> [v1]: http://www.spinics.net/lists/linux-pci/msg51287.html
>>
>> Amir Levy (8):
>>   thunderbolt: Macro rename
>>   thunderbolt: Updating device IDs
>>   thunderbolt: Updating the register definitions
>>   thunderbolt: Kconfig for Thunderbolt(TM) networking
>>   thunderbolt: Communication with the ICM (firmware)
>>   thunderbolt: Networking state machine
>>   thunderbolt: Networking transmit and receive
>>   thunderbolt: Networking doc
>>
>>  Documentation/00-INDEX   |2 +
>>  Documentation/thunderbolt-networking.txt |  135 ++
>>  drivers/thunderbolt/Kconfig  |   25 +-
>>  drivers/thunderbolt/Makefile |4 +-
>>  drivers/thunderbolt/icm_nhi.c| 1631 +
>>  drivers/thunderbolt/icm_nhi.h|   84 ++
>>  drivers/thunderbolt/net.c| 2277
>> ++
>>  drivers/thunderbolt/net.h|  274 
>>  drivers/thunderbolt/nhi_regs.h   |  115 +-
>>  include/linux/pci_ids.h  |   44 +-
>>  10 files changed, 4565 insertions(+), 26 deletions(-)  create mode 100644
>> Documentation/thunderbolt-networking.txt
>>  create mode 100644 drivers/thunderbolt/icm_nhi.c  create mode 100644
>> drivers/thunderbolt/icm_nhi.h  create mode 100644
>> drivers/thunderbolt/net.c  create mode 100644 drivers/thunderbolt/net.h
>>
>> --
>> 2.7.4
>
> Hi All,
> Do you have any comments or suggestions for this patch set?

Since this is now a separate driver I would prefer if it was in a
different (sub)directory (maybe thunderbolt/icm?).

> Regards,
> Amir

Re: [PATCH v2 0/8] thunderbolt: Introducing Thunderbolt(TM) networking

[Andreas Noever]

On Tue, Jul 12, 2016 at 12:50 PM, Levy, Amir (Jer)
 wrote:
> On Wed, Jun 29 2016, 11:35 AM, Levy, Amir (Jer) wrote:
>> This is version 2 of Thunderbolt(TM) driver for non-Apple hardware.
>>
>> Changes since v1:
>>  - Separation to 2 modules.
>>  - Moved ICM specific registers definition to ICM header file.
>>  - Added new Thunderbolt device IDs.
>>  - Renamed the Thunderbolt networking documentation.
>>  - General cleanups
>>
>> These patches were pushed to GitHub where they can be reviewed more
>> comfortably with green/red highlighting:
>>   https://github.com/01org/thunderbolt-software-kernel-tree
>>
>> Daemon code:
>>   https://github.com/01org/thunderbolt-software-daemon
>>
>> For reference, here's a link to version 1:
>> [v1]: http://www.spinics.net/lists/linux-pci/msg51287.html
>>
>> Amir Levy (8):
>>   thunderbolt: Macro rename
>>   thunderbolt: Updating device IDs
>>   thunderbolt: Updating the register definitions
>>   thunderbolt: Kconfig for Thunderbolt(TM) networking
>>   thunderbolt: Communication with the ICM (firmware)
>>   thunderbolt: Networking state machine
>>   thunderbolt: Networking transmit and receive
>>   thunderbolt: Networking doc
>>
>>  Documentation/00-INDEX   |2 +
>>  Documentation/thunderbolt-networking.txt |  135 ++
>>  drivers/thunderbolt/Kconfig  |   25 +-
>>  drivers/thunderbolt/Makefile |4 +-
>>  drivers/thunderbolt/icm_nhi.c| 1631 +
>>  drivers/thunderbolt/icm_nhi.h|   84 ++
>>  drivers/thunderbolt/net.c| 2277
>> ++
>>  drivers/thunderbolt/net.h|  274 
>>  drivers/thunderbolt/nhi_regs.h   |  115 +-
>>  include/linux/pci_ids.h  |   44 +-
>>  10 files changed, 4565 insertions(+), 26 deletions(-)  create mode 100644
>> Documentation/thunderbolt-networking.txt
>>  create mode 100644 drivers/thunderbolt/icm_nhi.c  create mode 100644
>> drivers/thunderbolt/icm_nhi.h  create mode 100644
>> drivers/thunderbolt/net.c  create mode 100644 drivers/thunderbolt/net.h
>>
>> --
>> 2.7.4
>
> Hi All,
> Do you have any comments or suggestions for this patch set?

Since this is now a separate driver I would prefer if it was in a
different (sub)directory (maybe thunderbolt/icm?).

> Regards,
> Amir

Re: [PATCH] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller

[Andreas Noever]

On Tue, Jul 12, 2016 at 11:13 PM, Lukas Wunner  wrote:
> On Tue, Jul 12, 2016 at 09:38:51PM +0200, Xavier Gnata wrote:
>> Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk to
>> support suspend/resume.
>> Tested against 4.7 master on a MacBook Air 11" 2015
>
> Nice, thanks for doing this. See below for some comments.
>
>
>>
>> ---
>> drivers/thunderbolt/nhi.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
>> index 9c15344..b3d55ec 100644
>> --- a/drivers/thunderbolt/nhi.c
>> +++ b/drivers/thunderbolt/nhi.c
>> @@ -654,6 +654,12 @@ static struct pci_device_id nhi_ids[] = {
>> .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI,
>> .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> },
>> + {
>> + .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
>> + .vendor = PCI_VENDOR_ID_INTEL,
>> + .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI,
>> + .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> + },
>> { 0,}
>> };
>>
>> --
>> 2.7.4
>>
>
> It looks like the indentation got mangled here, perhaps a Thunderbird
> issue or copy-pasta.
>
>
>>
>> ---
>>  drivers/pci/quirks.c | 23 +++
>>  1 file changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index ee72ebe..e280351 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3320,15 +3320,19 @@ static void quirk_apple_wait_for_thunderbolt(struct
>> pci_dev *dev)
>> if (!sibling || !sibling->subordinate)
>> goto out;
>> nhi = pci_get_slot(sibling->subordinate, 0x0);
>> -   if (!nhi)
>> -   goto out;
>> -   if (nhi->vendor != PCI_VENDOR_ID_INTEL
>> -   || (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
>> -   nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C
>> &&
>> -   nhi->device !=
>> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
>> -   || nhi->subsystem_vendor != 0x
>> -   || nhi->subsystem_device != 0x)
>> +   if (!nhi || nhi->vendor != PCI_VENDOR_ID_INTEL)
>> goto out;
>> +   if (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
>> +   nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
>> +   nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI &&
>> +   nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI)
>> +goto out;
>> +   if((nhi->device == PCI_DEVICE_ID_INTEL_LIGHT_RIDGE ||
>> +   nhi->device == PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C ||
>> +   nhi->device == PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
>> +   && (nhi->subsystem_vendor != 0x222
> ^
> You're missing a 2 here +
>
> The subsystem vendor/device should also not be checked on Falcon Ridge 4C,
> commit a42fb351ca1f ("thunderbolt: Allow loading of module on recent Apple
> MacBooks with thunderbolt 2 controller") removed that from the pci_device_id
> list but forgot to amend the quirk.

Yeah, we noticed that (off list). I was going to send a follow up
patch to fix that (just to keep the two things "Support FC_2C" and
"Fix suspend/resume for FC_4C" separate).

> Actually I'm wondering if we need to check the subsystem vendor/device id
> at all. If the motivation is to execute the quirk only for host controllers,
> this should probably be achieved by checking if the parent of the parent
> of the NHI has PCI_EXP_TYPE_ROOT_PORT set.
My idea was to check the device class - external thunderbolt devices
do not expose their controller through pci (even if they support
chaining). So all devices which match the device id and class should
be actual controllers.

Are thunderbolt controllers always installed directly below the root
port? In theory there could be more bridges in between (a candidate
for such a topology would be the mac pro which has 3 controllers).

Andreas
>
> Please also add PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI to tb_switch_alloc()
> so that the message "unsupported switch device id" is not printed for this
> controller.
>
> Thanks,
>
> Lukas
>
>> +   || nhi->subsystem_device != 0x))
>> +goto out;
>> dev_info(>dev, "quirk: waiting for thunderbolt to reestablish
>> PCI tunnels...\n");
>> device_pm_wait_for_dev(>dev, >dev);
>>  out:
>> @@ -3344,6 +3348,9 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>  DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE,
>>quirk_apple_wait_for_thunderbolt);
>> +DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>> +  PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE,
>> +  quirk_apple_wait_for_thunderbolt);
>>  #endif
>>

Re: [PATCH] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller

[Andreas Noever]

On Tue, Jul 12, 2016 at 11:13 PM, Lukas Wunner  wrote:
> On Tue, Jul 12, 2016 at 09:38:51PM +0200, Xavier Gnata wrote:
>> Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk to
>> support suspend/resume.
>> Tested against 4.7 master on a MacBook Air 11" 2015
>
> Nice, thanks for doing this. See below for some comments.
>
>
>>
>> ---
>> drivers/thunderbolt/nhi.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
>> index 9c15344..b3d55ec 100644
>> --- a/drivers/thunderbolt/nhi.c
>> +++ b/drivers/thunderbolt/nhi.c
>> @@ -654,6 +654,12 @@ static struct pci_device_id nhi_ids[] = {
>> .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI,
>> .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> },
>> + {
>> + .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
>> + .vendor = PCI_VENDOR_ID_INTEL,
>> + .device = PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI,
>> + .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
>> + },
>> { 0,}
>> };
>>
>> --
>> 2.7.4
>>
>
> It looks like the indentation got mangled here, perhaps a Thunderbird
> issue or copy-pasta.
>
>
>>
>> ---
>>  drivers/pci/quirks.c | 23 +++
>>  1 file changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index ee72ebe..e280351 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3320,15 +3320,19 @@ static void quirk_apple_wait_for_thunderbolt(struct
>> pci_dev *dev)
>> if (!sibling || !sibling->subordinate)
>> goto out;
>> nhi = pci_get_slot(sibling->subordinate, 0x0);
>> -   if (!nhi)
>> -   goto out;
>> -   if (nhi->vendor != PCI_VENDOR_ID_INTEL
>> -   || (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
>> -   nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C
>> &&
>> -   nhi->device !=
>> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
>> -   || nhi->subsystem_vendor != 0x
>> -   || nhi->subsystem_device != 0x)
>> +   if (!nhi || nhi->vendor != PCI_VENDOR_ID_INTEL)
>> goto out;
>> +   if (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
>> +   nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
>> +   nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI &&
>> +   nhi->device != PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI)
>> +goto out;
>> +   if((nhi->device == PCI_DEVICE_ID_INTEL_LIGHT_RIDGE ||
>> +   nhi->device == PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C ||
>> +   nhi->device == PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
>> +   && (nhi->subsystem_vendor != 0x222
> ^
> You're missing a 2 here +
>
> The subsystem vendor/device should also not be checked on Falcon Ridge 4C,
> commit a42fb351ca1f ("thunderbolt: Allow loading of module on recent Apple
> MacBooks with thunderbolt 2 controller") removed that from the pci_device_id
> list but forgot to amend the quirk.

Yeah, we noticed that (off list). I was going to send a follow up
patch to fix that (just to keep the two things "Support FC_2C" and
"Fix suspend/resume for FC_4C" separate).

> Actually I'm wondering if we need to check the subsystem vendor/device id
> at all. If the motivation is to execute the quirk only for host controllers,
> this should probably be achieved by checking if the parent of the parent
> of the NHI has PCI_EXP_TYPE_ROOT_PORT set.
My idea was to check the device class - external thunderbolt devices
do not expose their controller through pci (even if they support
chaining). So all devices which match the device id and class should
be actual controllers.

Are thunderbolt controllers always installed directly below the root
port? In theory there could be more bridges in between (a candidate
for such a topology would be the mac pro which has 3 controllers).

Andreas
>
> Please also add PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI to tb_switch_alloc()
> so that the message "unsupported switch device id" is not printed for this
> controller.
>
> Thanks,
>
> Lukas
>
>> +   || nhi->subsystem_device != 0x))
>> +goto out;
>> dev_info(>dev, "quirk: waiting for thunderbolt to reestablish
>> PCI tunnels...\n");
>> device_pm_wait_for_dev(>dev, >dev);
>>  out:
>> @@ -3344,6 +3348,9 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>  DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>>PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE,
>>quirk_apple_wait_for_thunderbolt);
>> +DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
>> +  PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE,
>> +  quirk_apple_wait_for_thunderbolt);
>>  #endif
>>
>>  static void 

Re: [PATCH] thunderbolt: fix spelling mistake: "missmatch" -> "mismatch"

[Andreas Noever]

On Tue, Jun 28, 2016 at 2:19 PM, Colin King <colin.k...@canonical.com> wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> trivial fix to spelling mistake in warning message
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---
>  drivers/thunderbolt/eeprom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
> index 2b9602c..029b6a5 100644
> --- a/drivers/thunderbolt/eeprom.c
> +++ b/drivers/thunderbolt/eeprom.c
> @@ -282,7 +282,7 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid)
>
> crc = tb_crc8(data + 1, 8);
> if (crc != data[0]) {
> -   tb_sw_warn(sw, "uid crc8 missmatch (expected: %#x, got: 
> %#x)\n",
> +   tb_sw_warn(sw, "uid crc8 mismatch (expected: %#x, got: 
> %#x)\n",
> data[0], crc);
>         return -EIO;
> }
> --
> 2.8.1
>

Thanks!

[+ Greg: for your queue]

Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>

Re: [PATCH] thunderbolt: fix spelling mistake: "missmatch" -> "mismatch"

[Andreas Noever]

On Tue, Jun 28, 2016 at 2:19 PM, Colin King  wrote:
> From: Colin Ian King 
>
> trivial fix to spelling mistake in warning message
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/thunderbolt/eeprom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
> index 2b9602c..029b6a5 100644
> --- a/drivers/thunderbolt/eeprom.c
> +++ b/drivers/thunderbolt/eeprom.c
> @@ -282,7 +282,7 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid)
>
> crc = tb_crc8(data + 1, 8);
> if (crc != data[0]) {
> -   tb_sw_warn(sw, "uid crc8 missmatch (expected: %#x, got: 
> %#x)\n",
> +   tb_sw_warn(sw, "uid crc8 mismatch (expected: %#x, got: 
> %#x)\n",
> data[0], crc);
> return -EIO;
> }
> --
> 2.8.1
>

Thanks!

[+ Greg: for your queue]

Signed-off-by: Andreas Noever 

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

[Andreas Noever]

On Sat, Jul 9, 2016 at 7:23 AM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Thu, Jul 07, 2016 at 07:39:12PM +0200, Andreas Noever wrote:
>> On Tue, Jun 14, 2016 at 10:22 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
>> > On Tue, Jun 14, 2016 at 09:14:27PM +0200, Andreas Noever wrote:
>> >> On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
>> >> > [+cc linux-kernel]
>> >> >
>> >> > On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
>> >> >>
>> >> >> Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
>> >> >>
>> >> >> Tested on MacBookPro10,1
>> >> >>
>> >> >> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner <lu...@wunner.de> wrote:
>> >> >> > This series powers Thunderbolt controllers on Macs down when nothing 
>> >> >> > is
>> >> >> > plugged in, saving 1.7 W on machines with a Light Ridge controller 
>> >> >> > and
>> >> >> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
>> >> >> >
>> >> >> > Briefly, a custom ACPI method provided by Apple is used to cut power 
>> >> >> > to
>> >> >> > the controller.  A GPE is enabled while the controller is powered 
>> >> >> > down
>> >> >> > which side-band signals a plug event, whereupon power is reinstated 
>> >> >> > using
>> >> >> > the ACPI method.  Note that even though this mechanism is ACPI-based,
>> >> >> > it does not use _PSx methods and is thus entirely nonstandard.
>> >> >
>> >> > I think the current arrangement was that Andreas would ack Thunderbolt
>> >> > patches and I would merge them via the PCI tree.  That makes some sense
>> >> > because Thunderbolt and PCIe are related, but the more I think about
>> >> > it, the less I'm happy with it.
>> >> >
>> >> > This series is a good example.  I'm sure it's good work and
>> >> > worthwhile.  But I can't really say anything about the content of it
>> >> > because most of it is Thunderbolt-specific and there's no public spec.
>> >> > It seems like this is basically a collection of reverse-engineered
>> >> > quirks that happen to work with the current state of Linux PM on
>> >> > certain Macs.  We don't know what might change on future Macs.  We
>> >> > don't know what might break when we make changes to Linux PM.
>> >> >
>> >> > I can't test this series, nor do I want to.  I can't test most of the
>> >> > patches I merge, but I can at least read the spec and see whether the
>> >> > patches make sense.  What I would *like* is to have public Thunderbolt
>> >> > specs and a kernel developer's guide so we know what to expect from
>> >> > the hardware and the firmware and we can write code that should work
>> >> > not just on current Macs, but also on non-Macs and future Macs.
>> >> >
>> >> > I don't think the current situation is really maintainable, and I'm
>> >> > not comfortable merging code that I can't maintain.
>> >> Most of the code is contained within the thunderbolt driver. I think
>> >> there is quite some precedence for reverse engineered drivers without
>> >> specs being part of the kernel. My understanding was that, since I am
>> >> listed in MAINTAINERS, I am responsible for the driver. Now our
>> >> changes often need improvements to the pci core, which is why I think
>> >> merging through your tree is a good idea (without transferring
>> >> responsibility). The changes to the drivers/pci should be supported by
>> >> the PCI-spec and make sense without knowing about thunderbolt (but it
>> >> might be the case that thunderbolt is the only user of these
>> >> features).
>> >>
>> >> Specifically for this series we want to:
>> >>  - whitelist thunderbolt bridges for PM. Detecting those bridges is
>> >> non-standard but I think this is acceptable, since this
>> >> blacklist/whitelist is basically a quirk.
>> >>  - Load our portdrv on tb bridges. PCI just sees another portdriver
>> >> and all the reverse engineered magic lives inside the driver.
>> >>  - Forward more PM callbacks to portdrivers (not 

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

[Andreas Noever]

On Sat, Jul 9, 2016 at 7:23 AM, Greg KH  wrote:
> On Thu, Jul 07, 2016 at 07:39:12PM +0200, Andreas Noever wrote:
>> On Tue, Jun 14, 2016 at 10:22 PM, Bjorn Helgaas  wrote:
>> > On Tue, Jun 14, 2016 at 09:14:27PM +0200, Andreas Noever wrote:
>> >> On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas  wrote:
>> >> > [+cc linux-kernel]
>> >> >
>> >> > On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
>> >> >>
>> >> >> Signed-off-by: Andreas Noever 
>> >> >>
>> >> >> Tested on MacBookPro10,1
>> >> >>
>> >> >> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner  wrote:
>> >> >> > This series powers Thunderbolt controllers on Macs down when nothing 
>> >> >> > is
>> >> >> > plugged in, saving 1.7 W on machines with a Light Ridge controller 
>> >> >> > and
>> >> >> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
>> >> >> >
>> >> >> > Briefly, a custom ACPI method provided by Apple is used to cut power 
>> >> >> > to
>> >> >> > the controller.  A GPE is enabled while the controller is powered 
>> >> >> > down
>> >> >> > which side-band signals a plug event, whereupon power is reinstated 
>> >> >> > using
>> >> >> > the ACPI method.  Note that even though this mechanism is ACPI-based,
>> >> >> > it does not use _PSx methods and is thus entirely nonstandard.
>> >> >
>> >> > I think the current arrangement was that Andreas would ack Thunderbolt
>> >> > patches and I would merge them via the PCI tree.  That makes some sense
>> >> > because Thunderbolt and PCIe are related, but the more I think about
>> >> > it, the less I'm happy with it.
>> >> >
>> >> > This series is a good example.  I'm sure it's good work and
>> >> > worthwhile.  But I can't really say anything about the content of it
>> >> > because most of it is Thunderbolt-specific and there's no public spec.
>> >> > It seems like this is basically a collection of reverse-engineered
>> >> > quirks that happen to work with the current state of Linux PM on
>> >> > certain Macs.  We don't know what might change on future Macs.  We
>> >> > don't know what might break when we make changes to Linux PM.
>> >> >
>> >> > I can't test this series, nor do I want to.  I can't test most of the
>> >> > patches I merge, but I can at least read the spec and see whether the
>> >> > patches make sense.  What I would *like* is to have public Thunderbolt
>> >> > specs and a kernel developer's guide so we know what to expect from
>> >> > the hardware and the firmware and we can write code that should work
>> >> > not just on current Macs, but also on non-Macs and future Macs.
>> >> >
>> >> > I don't think the current situation is really maintainable, and I'm
>> >> > not comfortable merging code that I can't maintain.
>> >> Most of the code is contained within the thunderbolt driver. I think
>> >> there is quite some precedence for reverse engineered drivers without
>> >> specs being part of the kernel. My understanding was that, since I am
>> >> listed in MAINTAINERS, I am responsible for the driver. Now our
>> >> changes often need improvements to the pci core, which is why I think
>> >> merging through your tree is a good idea (without transferring
>> >> responsibility). The changes to the drivers/pci should be supported by
>> >> the PCI-spec and make sense without knowing about thunderbolt (but it
>> >> might be the case that thunderbolt is the only user of these
>> >> features).
>> >>
>> >> Specifically for this series we want to:
>> >>  - whitelist thunderbolt bridges for PM. Detecting those bridges is
>> >> non-standard but I think this is acceptable, since this
>> >> blacklist/whitelist is basically a quirk.
>> >>  - Load our portdrv on tb bridges. PCI just sees another portdriver
>> >> and all the reverse engineered magic lives inside the driver.
>> >>  - Forward more PM callbacks to portdrivers (not tb specific)
>> >>  - hotplug D3cold fixes: resume around board_added/remove_board,
>> >> ignore interrupts in d3cold (n

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

[Andreas Noever]

On Tue, Jun 14, 2016 at 10:22 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
> On Tue, Jun 14, 2016 at 09:14:27PM +0200, Andreas Noever wrote:
>> On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
>> > [+cc linux-kernel]
>> >
>> > On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
>> >>
>> >> Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
>> >>
>> >> Tested on MacBookPro10,1
>> >>
>> >> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner <lu...@wunner.de> wrote:
>> >> > This series powers Thunderbolt controllers on Macs down when nothing is
>> >> > plugged in, saving 1.7 W on machines with a Light Ridge controller and
>> >> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
>> >> >
>> >> > Briefly, a custom ACPI method provided by Apple is used to cut power to
>> >> > the controller.  A GPE is enabled while the controller is powered down
>> >> > which side-band signals a plug event, whereupon power is reinstated 
>> >> > using
>> >> > the ACPI method.  Note that even though this mechanism is ACPI-based,
>> >> > it does not use _PSx methods and is thus entirely nonstandard.
>> >
>> > I think the current arrangement was that Andreas would ack Thunderbolt
>> > patches and I would merge them via the PCI tree.  That makes some sense
>> > because Thunderbolt and PCIe are related, but the more I think about
>> > it, the less I'm happy with it.
>> >
>> > This series is a good example.  I'm sure it's good work and
>> > worthwhile.  But I can't really say anything about the content of it
>> > because most of it is Thunderbolt-specific and there's no public spec.
>> > It seems like this is basically a collection of reverse-engineered
>> > quirks that happen to work with the current state of Linux PM on
>> > certain Macs.  We don't know what might change on future Macs.  We
>> > don't know what might break when we make changes to Linux PM.
>> >
>> > I can't test this series, nor do I want to.  I can't test most of the
>> > patches I merge, but I can at least read the spec and see whether the
>> > patches make sense.  What I would *like* is to have public Thunderbolt
>> > specs and a kernel developer's guide so we know what to expect from
>> > the hardware and the firmware and we can write code that should work
>> > not just on current Macs, but also on non-Macs and future Macs.
>> >
>> > I don't think the current situation is really maintainable, and I'm
>> > not comfortable merging code that I can't maintain.
>> Most of the code is contained within the thunderbolt driver. I think
>> there is quite some precedence for reverse engineered drivers without
>> specs being part of the kernel. My understanding was that, since I am
>> listed in MAINTAINERS, I am responsible for the driver. Now our
>> changes often need improvements to the pci core, which is why I think
>> merging through your tree is a good idea (without transferring
>> responsibility). The changes to the drivers/pci should be supported by
>> the PCI-spec and make sense without knowing about thunderbolt (but it
>> might be the case that thunderbolt is the only user of these
>> features).
>>
>> Specifically for this series we want to:
>>  - whitelist thunderbolt bridges for PM. Detecting those bridges is
>> non-standard but I think this is acceptable, since this
>> blacklist/whitelist is basically a quirk.
>>  - Load our portdrv on tb bridges. PCI just sees another portdriver
>> and all the reverse engineered magic lives inside the driver.
>>  - Forward more PM callbacks to portdrivers (not tb specific)
>>  - hotplug D3cold fixes: resume around board_added/remove_board,
>> ignore interrupts in d3cold (not tb specific and probably a general
>> bugfix)
>>  - Make pci not fail if bridges have been put into D3cold by some
>> external mechanism.
>>
>> So maybe you could review the pci changes as a solution to the problem
>> "we want to load a custom portdriver which can put bridges into d3cold
>> in a device specific way". We certainly to not expect you to take
>> responsibility for the thunderbolt driver.
>
> That's a fine solution as far as I'm personally concerned.  I think
> it's poor for Linux overall, because I think it's fragile, and it's
> disappointing that a technology as important as Thunderbolt is so
> poorly supported by the promulgators.  But if you're willing to work
> in that environment, that's great.
>
> You maintain the thunderbolt code and merge changes, and I'll review
> the pieces that touch drivers/pci.  I do have a couple comments on
> those pieces, but I don't think they'll be major.
>
> I just want to get out of the business of merging drivers/thunderbolt
> code that I can't maintain.

[+ Greg]

Hi Greg,

do you mind if we revert to the old scheme and merge TB changes
through your tree?

Regards,
Andreas


> Bjorn

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

[Andreas Noever]

On Tue, Jun 14, 2016 at 10:22 PM, Bjorn Helgaas  wrote:
> On Tue, Jun 14, 2016 at 09:14:27PM +0200, Andreas Noever wrote:
>> On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas  wrote:
>> > [+cc linux-kernel]
>> >
>> > On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
>> >>
>> >> Signed-off-by: Andreas Noever 
>> >>
>> >> Tested on MacBookPro10,1
>> >>
>> >> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner  wrote:
>> >> > This series powers Thunderbolt controllers on Macs down when nothing is
>> >> > plugged in, saving 1.7 W on machines with a Light Ridge controller and
>> >> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
>> >> >
>> >> > Briefly, a custom ACPI method provided by Apple is used to cut power to
>> >> > the controller.  A GPE is enabled while the controller is powered down
>> >> > which side-band signals a plug event, whereupon power is reinstated 
>> >> > using
>> >> > the ACPI method.  Note that even though this mechanism is ACPI-based,
>> >> > it does not use _PSx methods and is thus entirely nonstandard.
>> >
>> > I think the current arrangement was that Andreas would ack Thunderbolt
>> > patches and I would merge them via the PCI tree.  That makes some sense
>> > because Thunderbolt and PCIe are related, but the more I think about
>> > it, the less I'm happy with it.
>> >
>> > This series is a good example.  I'm sure it's good work and
>> > worthwhile.  But I can't really say anything about the content of it
>> > because most of it is Thunderbolt-specific and there's no public spec.
>> > It seems like this is basically a collection of reverse-engineered
>> > quirks that happen to work with the current state of Linux PM on
>> > certain Macs.  We don't know what might change on future Macs.  We
>> > don't know what might break when we make changes to Linux PM.
>> >
>> > I can't test this series, nor do I want to.  I can't test most of the
>> > patches I merge, but I can at least read the spec and see whether the
>> > patches make sense.  What I would *like* is to have public Thunderbolt
>> > specs and a kernel developer's guide so we know what to expect from
>> > the hardware and the firmware and we can write code that should work
>> > not just on current Macs, but also on non-Macs and future Macs.
>> >
>> > I don't think the current situation is really maintainable, and I'm
>> > not comfortable merging code that I can't maintain.
>> Most of the code is contained within the thunderbolt driver. I think
>> there is quite some precedence for reverse engineered drivers without
>> specs being part of the kernel. My understanding was that, since I am
>> listed in MAINTAINERS, I am responsible for the driver. Now our
>> changes often need improvements to the pci core, which is why I think
>> merging through your tree is a good idea (without transferring
>> responsibility). The changes to the drivers/pci should be supported by
>> the PCI-spec and make sense without knowing about thunderbolt (but it
>> might be the case that thunderbolt is the only user of these
>> features).
>>
>> Specifically for this series we want to:
>>  - whitelist thunderbolt bridges for PM. Detecting those bridges is
>> non-standard but I think this is acceptable, since this
>> blacklist/whitelist is basically a quirk.
>>  - Load our portdrv on tb bridges. PCI just sees another portdriver
>> and all the reverse engineered magic lives inside the driver.
>>  - Forward more PM callbacks to portdrivers (not tb specific)
>>  - hotplug D3cold fixes: resume around board_added/remove_board,
>> ignore interrupts in d3cold (not tb specific and probably a general
>> bugfix)
>>  - Make pci not fail if bridges have been put into D3cold by some
>> external mechanism.
>>
>> So maybe you could review the pci changes as a solution to the problem
>> "we want to load a custom portdriver which can put bridges into d3cold
>> in a device specific way". We certainly to not expect you to take
>> responsibility for the thunderbolt driver.
>
> That's a fine solution as far as I'm personally concerned.  I think
> it's poor for Linux overall, because I think it's fragile, and it's
> disappointing that a technology as important as Thunderbolt is so
> poorly supported by the promulgators.  But if you're willing to work
> in that environment, that's great.
>
> You maintain the thunderbolt code and merge changes, and I'll review
> the pieces that touch drivers/pci.  I do have a couple comments on
> those pieces, but I don't think they'll be major.
>
> I just want to get out of the business of merging drivers/thunderbolt
> code that I can't maintain.

[+ Greg]

Hi Greg,

do you mind if we revert to the old scheme and merge TB changes
through your tree?

Regards,
Andreas


> Bjorn

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

[Andreas Noever]

On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
> [+cc linux-kernel]
>
> On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
>>
>> Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
>>
>> Tested on MacBookPro10,1
>>
>> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner <lu...@wunner.de> wrote:
>> > This series powers Thunderbolt controllers on Macs down when nothing is
>> > plugged in, saving 1.7 W on machines with a Light Ridge controller and
>> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
>> >
>> > Briefly, a custom ACPI method provided by Apple is used to cut power to
>> > the controller.  A GPE is enabled while the controller is powered down
>> > which side-band signals a plug event, whereupon power is reinstated using
>> > the ACPI method.  Note that even though this mechanism is ACPI-based,
>> > it does not use _PSx methods and is thus entirely nonstandard.
>
> I think the current arrangement was that Andreas would ack Thunderbolt
> patches and I would merge them via the PCI tree.  That makes some sense
> because Thunderbolt and PCIe are related, but the more I think about
> it, the less I'm happy with it.
>
> This series is a good example.  I'm sure it's good work and
> worthwhile.  But I can't really say anything about the content of it
> because most of it is Thunderbolt-specific and there's no public spec.
> It seems like this is basically a collection of reverse-engineered
> quirks that happen to work with the current state of Linux PM on
> certain Macs.  We don't know what might change on future Macs.  We
> don't know what might break when we make changes to Linux PM.
>
> I can't test this series, nor do I want to.  I can't test most of the
> patches I merge, but I can at least read the spec and see whether the
> patches make sense.  What I would *like* is to have public Thunderbolt
> specs and a kernel developer's guide so we know what to expect from
> the hardware and the firmware and we can write code that should work
> not just on current Macs, but also on non-Macs and future Macs.
>
> I don't think the current situation is really maintainable, and I'm
> not comfortable merging code that I can't maintain.
Most of the code is contained within the thunderbolt driver. I think
there is quite some precedence for reverse engineered drivers without
specs being part of the kernel. My understanding was that, since I am
listed in MAINTAINERS, I am responsible for the driver. Now our
changes often need improvements to the pci core, which is why I think
merging through your tree is a good idea (without transferring
responsibility). The changes to the drivers/pci should be supported by
the PCI-spec and make sense without knowing about thunderbolt (but it
might be the case that thunderbolt is the only user of these
features).

Specifically for this series we want to:
 - whitelist thunderbolt bridges for PM. Detecting those bridges is
non-standard but I think this is acceptable, since this
blacklist/whitelist is basically a quirk.
 - Load our portdrv on tb bridges. PCI just sees another portdriver
and all the reverse engineered magic lives inside the driver.
 - Forward more PM callbacks to portdrivers (not tb specific)
 - hotplug D3cold fixes: resume around board_added/remove_board,
ignore interrupts in d3cold (not tb specific and probably a general
bugfix)
 - Make pci not fail if bridges have been put into D3cold by some
external mechanism.

So maybe you could review the pci changes as a solution to the problem
"we want to load a custom portdriver which can put bridges into d3cold
in a device specific way". We certainly to not expect you to take
responsibility for the thunderbolt driver.


> I know I don't understand the whole situation, so somebody please tell
> me why I'm being unreasonable here.
>
>> > A Thunderbolt controller appears to the OS as a set of PCI devices:  One
>> > NHI (Native Host Interface) and multiple bridges.  Power is cut to the
>> > entire set of devices:
>> >
>> >   (Root Port)  Upstream Bridge --+-- Downstream Bridge 0  NHI
>> >  +-- Downstream Bridge 1 --
>> >  +-- Downstream Bridge 2 --
>> >  ...
>> >
>> > v1 of this series shoehorned power control into the NHI driver.  This
>> > violated the Linux pm model which assumes that a child cannot resume
>> > before its parent. As seen above, the NHI is a child, so the child cut
>> > power to the bridges above it.
>> >
>> > v2 resolves this by positioning power control on the controller's
>> > topm

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

[Andreas Noever]

On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas  wrote:
> [+cc linux-kernel]
>
> On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
>>
>> Signed-off-by: Andreas Noever 
>>
>> Tested on MacBookPro10,1
>>
>> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner  wrote:
>> > This series powers Thunderbolt controllers on Macs down when nothing is
>> > plugged in, saving 1.7 W on machines with a Light Ridge controller and
>> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
>> >
>> > Briefly, a custom ACPI method provided by Apple is used to cut power to
>> > the controller.  A GPE is enabled while the controller is powered down
>> > which side-band signals a plug event, whereupon power is reinstated using
>> > the ACPI method.  Note that even though this mechanism is ACPI-based,
>> > it does not use _PSx methods and is thus entirely nonstandard.
>
> I think the current arrangement was that Andreas would ack Thunderbolt
> patches and I would merge them via the PCI tree.  That makes some sense
> because Thunderbolt and PCIe are related, but the more I think about
> it, the less I'm happy with it.
>
> This series is a good example.  I'm sure it's good work and
> worthwhile.  But I can't really say anything about the content of it
> because most of it is Thunderbolt-specific and there's no public spec.
> It seems like this is basically a collection of reverse-engineered
> quirks that happen to work with the current state of Linux PM on
> certain Macs.  We don't know what might change on future Macs.  We
> don't know what might break when we make changes to Linux PM.
>
> I can't test this series, nor do I want to.  I can't test most of the
> patches I merge, but I can at least read the spec and see whether the
> patches make sense.  What I would *like* is to have public Thunderbolt
> specs and a kernel developer's guide so we know what to expect from
> the hardware and the firmware and we can write code that should work
> not just on current Macs, but also on non-Macs and future Macs.
>
> I don't think the current situation is really maintainable, and I'm
> not comfortable merging code that I can't maintain.
Most of the code is contained within the thunderbolt driver. I think
there is quite some precedence for reverse engineered drivers without
specs being part of the kernel. My understanding was that, since I am
listed in MAINTAINERS, I am responsible for the driver. Now our
changes often need improvements to the pci core, which is why I think
merging through your tree is a good idea (without transferring
responsibility). The changes to the drivers/pci should be supported by
the PCI-spec and make sense without knowing about thunderbolt (but it
might be the case that thunderbolt is the only user of these
features).

Specifically for this series we want to:
 - whitelist thunderbolt bridges for PM. Detecting those bridges is
non-standard but I think this is acceptable, since this
blacklist/whitelist is basically a quirk.
 - Load our portdrv on tb bridges. PCI just sees another portdriver
and all the reverse engineered magic lives inside the driver.
 - Forward more PM callbacks to portdrivers (not tb specific)
 - hotplug D3cold fixes: resume around board_added/remove_board,
ignore interrupts in d3cold (not tb specific and probably a general
bugfix)
 - Make pci not fail if bridges have been put into D3cold by some
external mechanism.

So maybe you could review the pci changes as a solution to the problem
"we want to load a custom portdriver which can put bridges into d3cold
in a device specific way". We certainly to not expect you to take
responsibility for the thunderbolt driver.


> I know I don't understand the whole situation, so somebody please tell
> me why I'm being unreasonable here.
>
>> > A Thunderbolt controller appears to the OS as a set of PCI devices:  One
>> > NHI (Native Host Interface) and multiple bridges.  Power is cut to the
>> > entire set of devices:
>> >
>> >   (Root Port)  Upstream Bridge --+-- Downstream Bridge 0  NHI
>> >  +-- Downstream Bridge 1 --
>> >  +-- Downstream Bridge 2 --
>> >  ...
>> >
>> > v1 of this series shoehorned power control into the NHI driver.  This
>> > violated the Linux pm model which assumes that a child cannot resume
>> > before its parent. As seen above, the NHI is a child, so the child cut
>> > power to the bridges above it.
>> >
>> > v2 resolves this by positioning power control on the controller's
>> > topmost device, which is the upstream bridge.  That is achieved by
>>

Re: [PATCH] thunderbolt: Fix double free of drom buffer

[Andreas Noever]

On Mon, May 2, 2016 at 7:30 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
> On Sun, Apr 10, 2016 at 12:48:27PM +0200, Andreas Noever wrote:
>> If tb_drom_read fails sw->drom is freed but not set to NULL. sw->drom
>> is then freed again in the error path of sw_switch_alloc.
>
> s/sw_switch_alloc/tb_switch_alloc/ ?
>
>> The bug can be triggered by unplugging a thunderbolt device shortly
>> after it is detected by the thunderbolt driver.
>>
>> Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
>> Cc: Lukas Wunner <lu...@wunner.de>
>> Cc: sta...@vger.kernel.org
>
> How far back would this need to be applied?  What is the commit where
> the but was introduced?
>
> I applied this to pci/thunderbolt for v4.7 with the following
> changelog.  If I did it wrong, I'll gladly update it, especially if
> you have specific symptoms of a bug or oops that would help people
> find this fix.
>
> thunderbolt: Fix double free of drom buffer
>
> If tb_drom_read() fails, sw->drom is freed but not set to NULL.  sw->drom
> is then freed again in the error path of tb_switch_alloc().
>
> The bug can be triggered by unplugging a thunderbolt device shortly after
> it is detected by the thunderbolt driver.
>
> Clear sw->drom if tb_drom_read() fails.
The changelog is correct. The bug can be triggered starting from
343fcb8c ("thunderbolt: Fix nontrivial endpoint devices.") which is in
3.17-rc1. I observed crashes during subsequent hotplug operations (pci
core, sometimes in pciehp). But by nature of a double free bug these
were not very reliable (used kasan to track it down).

Thanks
Andreas


>     [bhelgaas: add Fixes:, stable versions of interest]
> Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.")
> Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
> Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
> CC: sta...@vger.kernel.org  # v3.17+
> CC: Lukas Wunner <lu...@wunner.de>
>
>> ---
>>  drivers/thunderbolt/eeprom.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
>> index 0dde34e..545c60c 100644
>> --- a/drivers/thunderbolt/eeprom.c
>> +++ b/drivers/thunderbolt/eeprom.c
>> @@ -444,6 +444,7 @@ int tb_drom_read(struct tb_switch *sw)
>>   return tb_drom_parse_entries(sw);
>>  err:
>>   kfree(sw->drom);
>> + sw->drom = NULL;
>>   return -EIO;
>>
>>  }
>> --
>> 2.8.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] thunderbolt: Fix double free of drom buffer

[Andreas Noever]

On Mon, May 2, 2016 at 7:30 PM, Bjorn Helgaas  wrote:
> On Sun, Apr 10, 2016 at 12:48:27PM +0200, Andreas Noever wrote:
>> If tb_drom_read fails sw->drom is freed but not set to NULL. sw->drom
>> is then freed again in the error path of sw_switch_alloc.
>
> s/sw_switch_alloc/tb_switch_alloc/ ?
>
>> The bug can be triggered by unplugging a thunderbolt device shortly
>> after it is detected by the thunderbolt driver.
>>
>> Signed-off-by: Andreas Noever 
>> Cc: Lukas Wunner 
>> Cc: sta...@vger.kernel.org
>
> How far back would this need to be applied?  What is the commit where
> the but was introduced?
>
> I applied this to pci/thunderbolt for v4.7 with the following
> changelog.  If I did it wrong, I'll gladly update it, especially if
> you have specific symptoms of a bug or oops that would help people
> find this fix.
>
> thunderbolt: Fix double free of drom buffer
>
> If tb_drom_read() fails, sw->drom is freed but not set to NULL.  sw->drom
> is then freed again in the error path of tb_switch_alloc().
>
> The bug can be triggered by unplugging a thunderbolt device shortly after
> it is detected by the thunderbolt driver.
>
> Clear sw->drom if tb_drom_read() fails.
The changelog is correct. The bug can be triggered starting from
343fcb8c ("thunderbolt: Fix nontrivial endpoint devices.") which is in
3.17-rc1. I observed crashes during subsequent hotplug operations (pci
core, sometimes in pciehp). But by nature of a double free bug these
were not very reliable (used kasan to track it down).

Thanks
Andreas


> [bhelgaas: add Fixes:, stable versions of interest]
> Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.")
> Signed-off-by: Andreas Noever 
> Signed-off-by: Bjorn Helgaas 
> CC: sta...@vger.kernel.org  # v3.17+
> CC: Lukas Wunner 
>
>> ---
>>  drivers/thunderbolt/eeprom.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
>> index 0dde34e..545c60c 100644
>> --- a/drivers/thunderbolt/eeprom.c
>> +++ b/drivers/thunderbolt/eeprom.c
>> @@ -444,6 +444,7 @@ int tb_drom_read(struct tb_switch *sw)
>>   return tb_drom_parse_entries(sw);
>>  err:
>>   kfree(sw->drom);
>> + sw->drom = NULL;
>>   return -EIO;
>>
>>  }
>> --
>> 2.8.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] thunderbolt: Fix double free of drom buffer

[Andreas Noever]

If tb_drom_read fails sw->drom is freed but not set to NULL. sw->drom
is then freed again in the error path of sw_switch_alloc.

The bug can be triggered by unplugging a thunderbolt device shortly
after it is detected by the thunderbolt driver.

Signed-off-by: Andreas Noever <andreas.noe...@gmail.com>
Cc: Lukas Wunner <lu...@wunner.de>
Cc: sta...@vger.kernel.org
---
 drivers/thunderbolt/eeprom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index 0dde34e..545c60c 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -444,6 +444,7 @@ int tb_drom_read(struct tb_switch *sw)
return tb_drom_parse_entries(sw);
 err:
kfree(sw->drom);
+   sw->drom = NULL;
return -EIO;
 
 }
-- 
2.8.0

[PATCH] thunderbolt: Fix double free of drom buffer

[Andreas Noever]

If tb_drom_read fails sw->drom is freed but not set to NULL. sw->drom
is then freed again in the error path of sw_switch_alloc.

The bug can be triggered by unplugging a thunderbolt device shortly
after it is detected by the thunderbolt driver.

Signed-off-by: Andreas Noever 
Cc: Lukas Wunner 
Cc: sta...@vger.kernel.org
---
 drivers/thunderbolt/eeprom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index 0dde34e..545c60c 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -444,6 +444,7 @@ int tb_drom_read(struct tb_switch *sw)
return tb_drom_parse_entries(sw);
 err:
kfree(sw->drom);
+   sw->drom = NULL;
return -EIO;
 
 }
-- 
2.8.0

Re: [PATCH 3/3] thunderbolt: Support 1st gen Light Ridge controller

[Andreas Noever]

On Sun, Mar 20, 2016 at 1:57 PM, Lukas Wunner <lu...@wunner.de> wrote:
> Built into:
> iMac12,1   2011  21.5"
> iMac12,2   2011  27"
> Macmini5,1 2011  i5 2.3 GHz
> Macmini5,2 2011  i5 2.5 GHz
> Macmini5,3 2011  i7 2.0 GHz
> MacBookPro8,1  2011  13"
> MacBookPro8,2  2011  15"
> MacBookPro8,3  2011  17"
> MacBookPro9,1  2012  15"
> MacBookPro9,2  2012  13"
>
> Light Ridge (CV82524) was the very first copper Thunderbolt controller,
> introduced 2010 alongside its fiber-optic cousin Light Peak (CVL2510).
> Consequently the chip suffers from some teething troubles:
>
> MSI is broken for hotplug signaling on the downstream bridges: The chip
> just never sends an interrupt. It requests 32 MSIs for each of its six
> bridges and the pcieport driver only allocates one per bridge. However
> I've verified that even if 32 MSIs are allocated there's no interrupt
> on hotplug. The only option is thus to disable MSI, which is also what
> OS X does. Apparently all Thunderbolt chips up to revision 1 of Cactus
> Ridge 4C are plagued by this issue so quirk those as well.
>
> The chip supports a maximum hop_count of 32, unlike its successors
> which support only 12. Fixup ring_interrupt_active() to cope with
> values >= 32.
>
> Another peculiarity is that the chip supports a maximum of 13 ports
> whereas its successors support 12. However the additional port (#5)
> seems to be unusable as reading its TB_CFG_PORT config space results
> in TB_CFG_ERROR_INVALID_CONFIG_SPACE. Add a quirk to mark the port
> disabled on the root switch, assuming that's necessary on all Macs
> using this chip.
>
> Cc: Andreas Noever <andreas.noe...@gmail.com>
> Tested-by: Lukas Wunner <lu...@wunner.de> [MacBookPro9,1]
> Tested-by: William Brown <will...@blackhats.net.au> [MacBookPro8,2]
> Signed-off-by: Lukas Wunner <lu...@wunner.de>
> ---
>  drivers/pci/quirks.c | 29 -
>  drivers/thunderbolt/eeprom.c |  5 +
>  drivers/thunderbolt/nhi.c| 11 +--
>  drivers/thunderbolt/switch.c |  3 ++-
>  4 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b584ddf..b1ff270 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3185,6 +3185,29 @@ static void quirk_no_pm_reset(struct pci_dev *dev)
>  DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
>PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset);
>
> +/*
> + * Thunderbolt controllers with broken MSI hotplug signaling:
> + * Entire 1st generation (Light Ridge, Eagle Ridge, Light Peak) and part
> + * of the 2nd generation (Cactus Ridge 4C up to revision 1, Port Ridge).
> + */
> +static void quirk_thunderbolt_hotplug_msi(struct pci_dev *pdev)
> +{
> +   if (pdev->is_hotplug_bridge &&
> +   (pdev->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C ||
> +pdev->revision <= 1))
> +   pdev->no_msi = 1;
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LIGHT_RIDGE,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EAGLE_RIDGE,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LIGHT_PEAK,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 
> PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
> +   quirk_thunderbolt_hotplug_msi);
> +
>  #ifdef CONFIG_ACPI
>  /*
>   * Apple: Shutdown Cactus Ridge Thunderbolt controller.
> @@ -3267,7 +3290,8 @@ static void quirk_apple_wait_for_thunderbolt(struct 
> pci_dev *dev)
> if (!nhi)
> goto out;
> if (nhi->vendor != PCI_VENDOR_ID_INTEL
> -   || (nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
> +   || (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
> +   nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
> nhi->device != 
> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
> || nhi->subsystem_vendor != 0x
> || nhi->subsystem_device != 0x)
> @@ -3279,6 +3303,9 @@ out:
> pci_dev_put(sibling);
>  }
>  DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
> +  PCI_DEVICE_ID_INTEL_LIGHT

Re: [PATCH 3/3] thunderbolt: Support 1st gen Light Ridge controller

[Andreas Noever]

On Sun, Mar 20, 2016 at 1:57 PM, Lukas Wunner  wrote:
> Built into:
> iMac12,1   2011  21.5"
> iMac12,2   2011  27"
> Macmini5,1 2011  i5 2.3 GHz
> Macmini5,2 2011  i5 2.5 GHz
> Macmini5,3 2011  i7 2.0 GHz
> MacBookPro8,1  2011  13"
> MacBookPro8,2  2011  15"
> MacBookPro8,3  2011  17"
> MacBookPro9,1  2012  15"
> MacBookPro9,2  2012  13"
>
> Light Ridge (CV82524) was the very first copper Thunderbolt controller,
> introduced 2010 alongside its fiber-optic cousin Light Peak (CVL2510).
> Consequently the chip suffers from some teething troubles:
>
> MSI is broken for hotplug signaling on the downstream bridges: The chip
> just never sends an interrupt. It requests 32 MSIs for each of its six
> bridges and the pcieport driver only allocates one per bridge. However
> I've verified that even if 32 MSIs are allocated there's no interrupt
> on hotplug. The only option is thus to disable MSI, which is also what
> OS X does. Apparently all Thunderbolt chips up to revision 1 of Cactus
> Ridge 4C are plagued by this issue so quirk those as well.
>
> The chip supports a maximum hop_count of 32, unlike its successors
> which support only 12. Fixup ring_interrupt_active() to cope with
> values >= 32.
>
> Another peculiarity is that the chip supports a maximum of 13 ports
> whereas its successors support 12. However the additional port (#5)
> seems to be unusable as reading its TB_CFG_PORT config space results
> in TB_CFG_ERROR_INVALID_CONFIG_SPACE. Add a quirk to mark the port
> disabled on the root switch, assuming that's necessary on all Macs
> using this chip.
>
> Cc: Andreas Noever 
> Tested-by: Lukas Wunner  [MacBookPro9,1]
> Tested-by: William Brown  [MacBookPro8,2]
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/pci/quirks.c | 29 -
>  drivers/thunderbolt/eeprom.c |  5 +
>  drivers/thunderbolt/nhi.c| 11 +--
>  drivers/thunderbolt/switch.c |  3 ++-
>  4 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b584ddf..b1ff270 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3185,6 +3185,29 @@ static void quirk_no_pm_reset(struct pci_dev *dev)
>  DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
>PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset);
>
> +/*
> + * Thunderbolt controllers with broken MSI hotplug signaling:
> + * Entire 1st generation (Light Ridge, Eagle Ridge, Light Peak) and part
> + * of the 2nd generation (Cactus Ridge 4C up to revision 1, Port Ridge).
> + */
> +static void quirk_thunderbolt_hotplug_msi(struct pci_dev *pdev)
> +{
> +   if (pdev->is_hotplug_bridge &&
> +   (pdev->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C ||
> +pdev->revision <= 1))
> +   pdev->no_msi = 1;
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LIGHT_RIDGE,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EAGLE_RIDGE,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LIGHT_PEAK,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 
> PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
> +   quirk_thunderbolt_hotplug_msi);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
> +   quirk_thunderbolt_hotplug_msi);
> +
>  #ifdef CONFIG_ACPI
>  /*
>   * Apple: Shutdown Cactus Ridge Thunderbolt controller.
> @@ -3267,7 +3290,8 @@ static void quirk_apple_wait_for_thunderbolt(struct 
> pci_dev *dev)
> if (!nhi)
> goto out;
> if (nhi->vendor != PCI_VENDOR_ID_INTEL
> -   || (nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
> +   || (nhi->device != PCI_DEVICE_ID_INTEL_LIGHT_RIDGE &&
> +   nhi->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C &&
> nhi->device != 
> PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI)
> || nhi->subsystem_vendor != 0x
> || nhi->subsystem_device != 0x)
> @@ -3279,6 +3303,9 @@ out:
> pci_dev_put(sibling);
>  }
>  DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL,
> +  PCI_DEVICE_ID_INTEL_LIGHT_RIDGE,
> +  quirk_apple_wait_for_thunderbolt);
> +DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_I

Re: Thunderbolt 3 (Skylake / Alpine Ridge) hotplug

[Andreas Noever]

Hi Jack,

On Fri, Feb 26, 2016 at 9:10 AM, Jack Coulter  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Andreas,
>
> I was asking around on #linux-pci on OFTC and it was mentioned that you
> were the maintainer for Linux Thunderbolt support, and that I should
> direct my query to you and the linux-pci & linux-kernel lists.
>
> I'm attempting to use the Thunderbolt 3 (which has a USB Type-C
> connector) port on my laptop, a Dell XPS 15 (9550). The external device
> I'm attempting to use is a gigabit ethernet + USB 3.0 hub, of an unknown
> / generic brand, but bears model number KY-688 if that's of any use.
>
> When the device is present at system startup, everything works
> correctly, and shows up in lspci as a USB controller, which lsusb shows
> having a hub and ethernet NIC attached, which the r8152 driver binds and
> uses without issue:
>
> lspci -v:
>> 0a:00.0 USB controller: Intel Corporation Device 15b5 (prog-if 30 [XHCI])
>> Subsystem: Device :
>> Flags: bus master, fast devsel, latency 0, IRQ 131
>> Memory at c420 (32-bit, non-prefetchable) [size=64K]
>> Capabilities: [80] Power Management version 3
>> Capabilities: [88] MSI: Enable+ Count=1/8 Maskable- 64bit+
>> Capabilities: [c0] Express Endpoint, MSI 00
>> Capabilities: [100] Device Serial Number a3-21-b5-60-a7-23-04-00
>> Capabilities: [200] Advanced Error Reporting
>> Capabilities: [300] Virtual Channel
>> Capabilities: [400] Power Budgeting 
>> Capabilities: [500] Vendor Specific Information: ID=1234 Rev=1
> Len=0d8 
>> Capabilities: [600] Latency Tolerance Reporting
>> Capabilities: [700] #19
>> Kernel driver in use: xhci_hcd
>
>
> lspci -tv (Thunderbolt device is 15b5)
>> -[:00]-+-00.0  Intel Corporation Sky Lake Host Bridge/DRAM Registers
>>+-01.0-[01]00.0  NVIDIA Corporation GM107M [GeForce GTX
> 960M]
>>+-02.0  Intel Corporation Device 191b
>>+-04.0  Intel Corporation Device 1903
>>+-14.0  Intel Corporation Sunrise Point-H USB 3.0 xHCI
> Controller
>>+-14.2  Intel Corporation Sunrise Point-H Thermal subsystem
>>+-15.0  Intel Corporation Sunrise Point-H LPSS I2C
> Controller #0
>>+-15.1  Intel Corporation Sunrise Point-H LPSS I2C
> Controller #1
>>+-16.0  Intel Corporation Sunrise Point-H CSME HECI #1
>>+-1c.0-[02]00.0  Broadcom Corporation BCM43602 802.11ac
> Wireless LAN SoC
>>+-1c.1-[03]00.0  Realtek Semiconductor Co., Ltd. Device
> 525a
>>+-1d.0-[04]00.0  Samsung Electronics Co Ltd Device a802
>>+-1d.4-[05]--
>>+-1d.6-[06-3e]00.0-[07-0a]--+-00.0-[08]--
>>|   +-01.0-[09]--
>>|   \-02.0-[0a]00.0  Intel
> Corporation Device 15b5
>>+-1f.0  Intel Corporation Sunrise Point-H LPC Controller
>>+-1f.2  Intel Corporation Sunrise Point-H PMC
>>+-1f.3  Intel Corporation Sunrise Point-H HD Audio
>>\-1f.4  Intel Corporation Sunrise Point-H SMBus
>
> lsusb -tv:
>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
>> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class,
> Driver=r8152, 5000M
>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>> |__ Port 3: Dev 3, If 0, Class=Human Interface Device,
> Driver=usbhid, 12M
>> |__ Port 3: Dev 3, If 1, Class=Human Interface Device,
> Driver=usbhid, 12M
>> |__ Port 3: Dev 3, If 2, Class=Human Interface Device,
> Driver=usbhid, 12M
>> |__ Port 3: Dev 3, If 3, Class=Human Interface Device,
> Driver=usbhid, 12M
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
>> |__ Port 4: Dev 2, If 0, Class=Vendor Specific Class,
> Driver=btusb, 12M
>> |__ Port 4: Dev 2, If 1, Class=Vendor Specific Class,
> Driver=btusb, 12M
>> |__ Port 4: Dev 2, If 2, Class=Vendor Specific Class,
> Driver=btusb, 12M
>> |__ Port 4: Dev 2, If 3, Class=Application Specific Interface,
> Driver=, 12M
>> |__ Port 12: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
>> |__ Port 12: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
>
>
> However, if the device is connected after the system boots (or
> disconnected and reconnected), it is not detected at all. No messages
> show up in dmesg upon connection and no additional devices show up in
> the output of lspci & lsusb. Strangely enough, USB devices connected to
> the external hub do still receive power.
>
> I also have the following options relating to PCI hotplug set in my
> kernel config:
>
>> CONFIG_HOTPLUG_PCI_PCIE=y
>> CONFIG_HOTPLUG_PCI=y
>> 

Re: Thunderbolt 3 (Skylake / Alpine Ridge) hotplug

[Andreas Noever]

Hi Jack,

On Fri, Feb 26, 2016 at 9:10 AM, Jack Coulter  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Andreas,
>
> I was asking around on #linux-pci on OFTC and it was mentioned that you
> were the maintainer for Linux Thunderbolt support, and that I should
> direct my query to you and the linux-pci & linux-kernel lists.
>
> I'm attempting to use the Thunderbolt 3 (which has a USB Type-C
> connector) port on my laptop, a Dell XPS 15 (9550). The external device
> I'm attempting to use is a gigabit ethernet + USB 3.0 hub, of an unknown
> / generic brand, but bears model number KY-688 if that's of any use.
>
> When the device is present at system startup, everything works
> correctly, and shows up in lspci as a USB controller, which lsusb shows
> having a hub and ethernet NIC attached, which the r8152 driver binds and
> uses without issue:
>
> lspci -v:
>> 0a:00.0 USB controller: Intel Corporation Device 15b5 (prog-if 30 [XHCI])
>> Subsystem: Device :
>> Flags: bus master, fast devsel, latency 0, IRQ 131
>> Memory at c420 (32-bit, non-prefetchable) [size=64K]
>> Capabilities: [80] Power Management version 3
>> Capabilities: [88] MSI: Enable+ Count=1/8 Maskable- 64bit+
>> Capabilities: [c0] Express Endpoint, MSI 00
>> Capabilities: [100] Device Serial Number a3-21-b5-60-a7-23-04-00
>> Capabilities: [200] Advanced Error Reporting
>> Capabilities: [300] Virtual Channel
>> Capabilities: [400] Power Budgeting 
>> Capabilities: [500] Vendor Specific Information: ID=1234 Rev=1
> Len=0d8 
>> Capabilities: [600] Latency Tolerance Reporting
>> Capabilities: [700] #19
>> Kernel driver in use: xhci_hcd
>
>
> lspci -tv (Thunderbolt device is 15b5)
>> -[:00]-+-00.0  Intel Corporation Sky Lake Host Bridge/DRAM Registers
>>+-01.0-[01]00.0  NVIDIA Corporation GM107M [GeForce GTX
> 960M]
>>+-02.0  Intel Corporation Device 191b
>>+-04.0  Intel Corporation Device 1903
>>+-14.0  Intel Corporation Sunrise Point-H USB 3.0 xHCI
> Controller
>>+-14.2  Intel Corporation Sunrise Point-H Thermal subsystem
>>+-15.0  Intel Corporation Sunrise Point-H LPSS I2C
> Controller #0
>>+-15.1  Intel Corporation Sunrise Point-H LPSS I2C
> Controller #1
>>+-16.0  Intel Corporation Sunrise Point-H CSME HECI #1
>>+-1c.0-[02]00.0  Broadcom Corporation BCM43602 802.11ac
> Wireless LAN SoC
>>+-1c.1-[03]00.0  Realtek Semiconductor Co., Ltd. Device
> 525a
>>+-1d.0-[04]00.0  Samsung Electronics Co Ltd Device a802
>>+-1d.4-[05]--
>>+-1d.6-[06-3e]00.0-[07-0a]--+-00.0-[08]--
>>|   +-01.0-[09]--
>>|   \-02.0-[0a]00.0  Intel
> Corporation Device 15b5
>>+-1f.0  Intel Corporation Sunrise Point-H LPC Controller
>>+-1f.2  Intel Corporation Sunrise Point-H PMC
>>+-1f.3  Intel Corporation Sunrise Point-H HD Audio
>>\-1f.4  Intel Corporation Sunrise Point-H SMBus
>
> lsusb -tv:
>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
>> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class,
> Driver=r8152, 5000M
>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>> |__ Port 3: Dev 3, If 0, Class=Human Interface Device,
> Driver=usbhid, 12M
>> |__ Port 3: Dev 3, If 1, Class=Human Interface Device,
> Driver=usbhid, 12M
>> |__ Port 3: Dev 3, If 2, Class=Human Interface Device,
> Driver=usbhid, 12M
>> |__ Port 3: Dev 3, If 3, Class=Human Interface Device,
> Driver=usbhid, 12M
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
>> |__ Port 4: Dev 2, If 0, Class=Vendor Specific Class,
> Driver=btusb, 12M
>> |__ Port 4: Dev 2, If 1, Class=Vendor Specific Class,
> Driver=btusb, 12M
>> |__ Port 4: Dev 2, If 2, Class=Vendor Specific Class,
> Driver=btusb, 12M
>> |__ Port 4: Dev 2, If 3, Class=Application Specific Interface,
> Driver=, 12M
>> |__ Port 12: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
>> |__ Port 12: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
>
>
> However, if the device is connected after the system boots (or
> disconnected and reconnected), it is not detected at all. No messages
> show up in dmesg upon connection and no additional devices show up in
> the output of lspci & lsusb. Strangely enough, USB devices connected to
> the external hub do still receive power.
>
> I also have the following options relating to PCI hotplug set in my
> kernel config:
>
>> CONFIG_HOTPLUG_PCI_PCIE=y
>> CONFIG_HOTPLUG_PCI=y
>> CONFIG_HOTPLUG_PCI_ACPI=y
>> 

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Mon, May 4, 2015 at 3:00 PM, Adam Goode  wrote:
> On Sat, Apr 25, 2015 at 11:00 PM, Adam Goode  wrote:
>> Here's the problem:
>>
>> [0.126595] ACPI Error: No handler for Region [CMS0]
>> (8802658a0438) [SystemCMOS] (20150410/evregion-163)
>> [0.126597] ACPI Error: Region SystemCMOS (ID=5) has no handler
>> (20150410/exfldio-297)
>> [0.126600] ACPI Error: Method parse/execution failed
>> [\_SB_.PCI0._INI] (Node 8802658ac500), AE_NOT_EXIST
>> (20150410/psparse-536)
>> [0.126605] ACPI Exception: AE_NOT_EXIST, during
>> \_SB_.PCI0._INI._INI execution (20150410/nsinit-588)
>>
>> ...
>>
>> [0.170603]   bus-0130 bus_get_status: Device [RTC]
>> status [000f]
>> [0.170605] evhandler-0446 ev_install_space_handl: Creating object
>> on Device 8802658a82a8 while installing handler
>> [0.170607] evhandler-0482 ev_install_space_handl: Installing
>> address handler for region SystemCMOS(5) on Device RTC_
>> 8802658a82a8(880264160090)
>> [0.170610]  evregion-0506 ev_attach_region  : Adding Region
>> [CMS0] 8802658a0438 to address handler 880264160480
>> [SystemCMOS]
>>
>>
>> Next step is to figure out how to install the address handler earlier.
>>
>>
>
> Current status:
>
> I have a patch out to fix the CMOS handler issue:
> http://marc.info/?l=linux-acpi=143052869625376=2
>
> The CMOS handler is called in the Darwin codepath as well, so it's a
> useful fix regardless.
>
> When I patched with this support, and booted in non-Darwin mode,
> hotplug worked without further Linux driver support (I disabled the
> thunderbolt module). Suspend/resume still does not work unless I don't
> activate any thunderbolt device at all. This happens regardless of
> which OSI mode.
>
> So there is a suspend/resume problem which seems more generic. I am
> not sure if I have time to debug this.
>
> One thing that would be useful would be to change the Darwin special
> case code to make it configurable on the kernel command line.
>
> Lastly, when ACPI fully initializes the thunderbolt controller, the
> Linux thunderbolt module hangs for several seconds upon loading, and
> then fails. Which is probably correct, but I don't know if it messes
> up any state in the mean time (plus it shouldn't hang). Is there a way
> to have the module detect BIOS support and disable itself? Or to
> properly do a handover?
I have no idea how to do a proper handoff. I guess the easiest way is
to refuse loading the thunderbolt module if the new "no_darwin" acpi
flag is set.
--
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/

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Mon, May 4, 2015 at 3:00 PM, Adam Goode a...@spicenitz.org wrote:
 On Sat, Apr 25, 2015 at 11:00 PM, Adam Goode a...@spicenitz.org wrote:
 Here's the problem:

 [0.126595] ACPI Error: No handler for Region [CMS0]
 (8802658a0438) [SystemCMOS] (20150410/evregion-163)
 [0.126597] ACPI Error: Region SystemCMOS (ID=5) has no handler
 (20150410/exfldio-297)
 [0.126600] ACPI Error: Method parse/execution failed
 [\_SB_.PCI0._INI] (Node 8802658ac500), AE_NOT_EXIST
 (20150410/psparse-536)
 [0.126605] ACPI Exception: AE_NOT_EXIST, during
 \_SB_.PCI0._INI._INI execution (20150410/nsinit-588)

 ...

 [0.170603]   bus-0130 bus_get_status: Device [RTC]
 status [000f]
 [0.170605] evhandler-0446 ev_install_space_handl: Creating object
 on Device 8802658a82a8 while installing handler
 [0.170607] evhandler-0482 ev_install_space_handl: Installing
 address handler for region SystemCMOS(5) on Device RTC_
 8802658a82a8(880264160090)
 [0.170610]  evregion-0506 ev_attach_region  : Adding Region
 [CMS0] 8802658a0438 to address handler 880264160480
 [SystemCMOS]


 Next step is to figure out how to install the address handler earlier.



 Current status:

 I have a patch out to fix the CMOS handler issue:
 http://marc.info/?l=linux-acpim=143052869625376w=2

 The CMOS handler is called in the Darwin codepath as well, so it's a
 useful fix regardless.

 When I patched with this support, and booted in non-Darwin mode,
 hotplug worked without further Linux driver support (I disabled the
 thunderbolt module). Suspend/resume still does not work unless I don't
 activate any thunderbolt device at all. This happens regardless of
 which OSI mode.

 So there is a suspend/resume problem which seems more generic. I am
 not sure if I have time to debug this.

 One thing that would be useful would be to change the Darwin special
 case code to make it configurable on the kernel command line.

 Lastly, when ACPI fully initializes the thunderbolt controller, the
 Linux thunderbolt module hangs for several seconds upon loading, and
 then fails. Which is probably correct, but I don't know if it messes
 up any state in the mean time (plus it shouldn't hang). Is there a way
 to have the module detect BIOS support and disable itself? Or to
 properly do a handover?
I have no idea how to do a proper handoff. I guess the easiest way is
to refuse loading the thunderbolt module if the new no_darwin acpi
flag is set.
--
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/

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Fri, Apr 24, 2015 at 6:50 AM, Adam Goode  wrote:
> On Thu, Apr 23, 2015 at 1:15 PM, Adam Goode  wrote:
>> On Thu, Apr 23, 2015 at 12:12 PM, Andreas Noever
>>  wrote:
>>> On Thu, Apr 23, 2015 at 5:10 PM, Adam Goode  wrote:
>>>> On Thu, Apr 23, 2015 at 9:28 AM, Adam Goode  wrote:
>>>>>
>>>>> On Thu, Apr 23, 2015 at 6:08 AM, Andreas Noever
>>>>>  wrote:
>>>>> > Hi Adam,
>>>>> >
>>>>> > On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
>>>>> > controller both use 0x1547 and are only differentiated by
>>>>> > subvendor/subdevice.
>>>>> >
>>>>> > 0x156c is the 4 channel TB2 controller and was originally added by
>>>>> > Matthew. Judging from his patch it looks like the subvendor/subdevice
>>>>> > is set on his system:
>>>>> > http://patchwork.ozlabs.org/patch/354626/
>>>>> >
>>>>> > But it also indicates that the bridges already use different ids. If
>>>>> > that is the case then we can drop the subvendor/subdevice for 0x156c.
>>>>> > Matthew can you confirm that on your system 0x156c is used only for
>>>>> > the controller?
>>>>> >
>>>>> > Adam, could you check that suspend/resume works properly? Also your
>>>>> > bugzilla report suggest that hotplug might now work without the
>>>>> > driver. Could you try to revert the _OSI check (and disable the
>>>>> > driver) and check whether everything "just works"?
>>>>> >
>>>>>
>>>>> In _OSI("Darwin") mode, suspend/resume doesn't work. It failed to come
>>>>> back from suspend.
>>>>>
>>>>> I have to rebuild the kernel and remove Darwin again, but I will test
>>>>> suspend/resume in "Windows 2012" mode later.
>>>>>
>>>>> From previous testing, hotplug doesn't automatically work in "Windows
>>>>> 2012" mode. It exhibits the standard no-driver behavior where devices
>>>>> are not detected after boot. But even in "Windows 2012" mode I still
>>>>> do get the 0x156c device, which I think used to be hidden if !Darwin.
>>>>>
>>>>> More testing coming...
>>>>>
>>>>
>>>> I've booted into _OSI(Windows 2012) mode. I am not physically at the
>>>> device right now, but here is the current dmesg with 1 thunderbolt
>>>> device plugged in:
>>>>
>>>> [   15.576766] thunderbolt :06:00.0: NHI initialized, starting 
>>>> thunderbolt
>>>> [   15.577868] thunderbolt :06:00.0: allocating TX ring 0 of size 10
>>>> [   15.578939] thunderbolt :06:00.0: allocating RX ring 0 of size 10
>>>> [   15.580008] thunderbolt :06:00.0: control channel created
>>>> [   15.581068] thunderbolt :06:00.0: control channel starting...
>>>> [   15.582122] thunderbolt :06:00.0: starting TX ring 0
>>>> [   15.583173] thunderbolt :06:00.0: enabling interrupt at
>>>> register 0x38200 bit 0 (0x0 -> 0x1)
>>>> [   15.584228] thunderbolt :06:00.0: starting RX ring 0
>>>> [   15.585281] thunderbolt :06:00.0: enabling interrupt at
>>>> register 0x38200 bit 12 (0x1 -> 0x1001)
>>>> [   15.586463] thunderbolt :06:00.0: initializing Switch at 0x0
>>>> (depth: 0, up port: 5)
>>>> [   15.587526] thunderbolt :06:00.0: old switch config:
>>>> [   15.588569] thunderbolt :06:00.0:  Switch: 8086:156d (Revision:
>>>> 0, TB Version: 2)
>>>> [   15.589581] thunderbolt :06:00.0:   Max Port Number: 12
>>>> [   15.590557] thunderbolt :06:00.0:   Config:
>>>> [   15.591532] thunderbolt :06:00.0:Upstream Port Number: 5
>>>> Depth: 0 Route String: 0x0 Enabled: 1, PlugEventsDelay: 255ms
>>>> [   15.592530] thunderbolt :06:00.0:unknown1: 0x0 unknown4: 0x0
>>>> [   15.593530] thunderbolt :06:00.0: 0: unsupported switch device id 
>>>> 0x156d
>>>> [   15.625612] thunderbolt :06:00.0: 0: uid: 0x1001500947a60
>>>> [   15.626919] thunderbolt :06:00.0:  Port 0: 8086:156d (Revision:
>>>> 0, TB Version: 1, Type: Port (0x1))
>>>> [   15.628028] thunderbolt :06:00.0:   Max hop id (in/out): 7/7
>>>> [   15.629050] thunderbolt :06:00.0

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Thu, Apr 23, 2015 at 8:12 PM, Matthew Garrett  wrote:
> On Thu, Apr 23, 2015 at 12:08:01PM +0200, Andreas Noever wrote:
>> Hi Adam,
>>
>> On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
>> controller both use 0x1547 and are only differentiated by
>> subvendor/subdevice.
>
> Do they have the same PCI class?
No, 0604 for the bridges and 0880 for the device.

It looks like the only reason that the bridges do not have a
subsystem/subvendor set is because there is no such field in the pci
bridge header. Instead they put : into the SSVID capability:

06:06.0 PCI bridge [0604]: Intel Corporation Unknown device
[8086:1547] (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=06, secondary=08, subordinate=08, sec-latency=0
Capabilities: [80] Power Management version 3
Capabilities: [88] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Capabilities: [ac] Subsystem: Unknown device [:]
Capabilities: [c0] Express Downstream Port (Slot+), MSI 00
Capabilities: [100] #8086

07:00.0 System peripheral [0880]: Intel Corporation Unknown device
[8086:1547] (rev 03)
Subsystem: Unknown device [:]
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at c1d0 (32-bit, non-prefetchable)
Memory at c1d4 (32-bit, non-prefetchable)
Capabilities: [80] Power Management version 3
Capabilities: [88] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Capabilities: [ac] Subsystem: Unknown device [:]
Capabilities: [c0] Express Endpoint, MSI 00
Capabilities: [a0] MSI-X: Enable- Mask- TabSize=16
Capabilities: [100] #8086

pci_setup_device actually reads this capability and puts it into
dev->subsystem_vendor/device. So we might actually get bound to the
bridges (if the pcieport driver is unavailable). I'll post a patch to
bind to the class code instead. Good idea!

Andreas
--
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/

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Fri, Apr 24, 2015 at 6:50 AM, Adam Goode a...@spicenitz.org wrote:
 On Thu, Apr 23, 2015 at 1:15 PM, Adam Goode a...@spicenitz.org wrote:
 On Thu, Apr 23, 2015 at 12:12 PM, Andreas Noever
 andreas.noe...@gmail.com wrote:
 On Thu, Apr 23, 2015 at 5:10 PM, Adam Goode a...@spicenitz.org wrote:
 On Thu, Apr 23, 2015 at 9:28 AM, Adam Goode a...@spicenitz.org wrote:

 On Thu, Apr 23, 2015 at 6:08 AM, Andreas Noever
 andreas.noe...@gmail.com wrote:
  Hi Adam,
 
  On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
  controller both use 0x1547 and are only differentiated by
  subvendor/subdevice.
 
  0x156c is the 4 channel TB2 controller and was originally added by
  Matthew. Judging from his patch it looks like the subvendor/subdevice
  is set on his system:
  http://patchwork.ozlabs.org/patch/354626/
 
  But it also indicates that the bridges already use different ids. If
  that is the case then we can drop the subvendor/subdevice for 0x156c.
  Matthew can you confirm that on your system 0x156c is used only for
  the controller?
 
  Adam, could you check that suspend/resume works properly? Also your
  bugzilla report suggest that hotplug might now work without the
  driver. Could you try to revert the _OSI check (and disable the
  driver) and check whether everything just works?
 

 In _OSI(Darwin) mode, suspend/resume doesn't work. It failed to come
 back from suspend.

 I have to rebuild the kernel and remove Darwin again, but I will test
 suspend/resume in Windows 2012 mode later.

 From previous testing, hotplug doesn't automatically work in Windows
 2012 mode. It exhibits the standard no-driver behavior where devices
 are not detected after boot. But even in Windows 2012 mode I still
 do get the 0x156c device, which I think used to be hidden if !Darwin.

 More testing coming...


 I've booted into _OSI(Windows 2012) mode. I am not physically at the
 device right now, but here is the current dmesg with 1 thunderbolt
 device plugged in:

 [   15.576766] thunderbolt :06:00.0: NHI initialized, starting 
 thunderbolt
 [   15.577868] thunderbolt :06:00.0: allocating TX ring 0 of size 10
 [   15.578939] thunderbolt :06:00.0: allocating RX ring 0 of size 10
 [   15.580008] thunderbolt :06:00.0: control channel created
 [   15.581068] thunderbolt :06:00.0: control channel starting...
 [   15.582122] thunderbolt :06:00.0: starting TX ring 0
 [   15.583173] thunderbolt :06:00.0: enabling interrupt at
 register 0x38200 bit 0 (0x0 - 0x1)
 [   15.584228] thunderbolt :06:00.0: starting RX ring 0
 [   15.585281] thunderbolt :06:00.0: enabling interrupt at
 register 0x38200 bit 12 (0x1 - 0x1001)
 [   15.586463] thunderbolt :06:00.0: initializing Switch at 0x0
 (depth: 0, up port: 5)
 [   15.587526] thunderbolt :06:00.0: old switch config:
 [   15.588569] thunderbolt :06:00.0:  Switch: 8086:156d (Revision:
 0, TB Version: 2)
 [   15.589581] thunderbolt :06:00.0:   Max Port Number: 12
 [   15.590557] thunderbolt :06:00.0:   Config:
 [   15.591532] thunderbolt :06:00.0:Upstream Port Number: 5
 Depth: 0 Route String: 0x0 Enabled: 1, PlugEventsDelay: 255ms
 [   15.592530] thunderbolt :06:00.0:unknown1: 0x0 unknown4: 0x0
 [   15.593530] thunderbolt :06:00.0: 0: unsupported switch device id 
 0x156d
 [   15.625612] thunderbolt :06:00.0: 0: uid: 0x1001500947a60
 [   15.626919] thunderbolt :06:00.0:  Port 0: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.628028] thunderbolt :06:00.0:   Max hop id (in/out): 7/7
 [   15.629050] thunderbolt :06:00.0:   Max counters: 8
 [   15.630156] thunderbolt :06:00.0:   NFC Credits: 0x70
 [   15.631685] thunderbolt :06:00.0:  Port 1: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.632896] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.634000] thunderbolt :06:00.0:   Max counters: 16
 [   15.635001] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.636582] thunderbolt :06:00.0:  Port 2: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.637737] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.638862] thunderbolt :06:00.0:   Max counters: 16
 [   15.639875] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.641452] thunderbolt :06:00.0:  Port 3: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.642572] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.643702] thunderbolt :06:00.0:   Max counters: 16
 [   15.644683] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.646250] thunderbolt :06:00.0:  Port 4: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.647285] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.648370] thunderbolt :06:00.0:   Max counters: 16
 [   15.649460] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.650539] thunderbolt :06:00.0:  Port 5: 8086:156d

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Thu, Apr 23, 2015 at 8:12 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
 On Thu, Apr 23, 2015 at 12:08:01PM +0200, Andreas Noever wrote:
 Hi Adam,

 On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
 controller both use 0x1547 and are only differentiated by
 subvendor/subdevice.

 Do they have the same PCI class?
No, 0604 for the bridges and 0880 for the device.

It looks like the only reason that the bridges do not have a
subsystem/subvendor set is because there is no such field in the pci
bridge header. Instead they put : into the SSVID capability:

06:06.0 PCI bridge [0604]: Intel Corporation Unknown device
[8086:1547] (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=06, secondary=08, subordinate=08, sec-latency=0
Capabilities: [80] Power Management version 3
Capabilities: [88] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Capabilities: [ac] Subsystem: Unknown device [:]
Capabilities: [c0] Express Downstream Port (Slot+), MSI 00
Capabilities: [100] #8086

07:00.0 System peripheral [0880]: Intel Corporation Unknown device
[8086:1547] (rev 03)
Subsystem: Unknown device [:]
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at c1d0 (32-bit, non-prefetchable)
Memory at c1d4 (32-bit, non-prefetchable)
Capabilities: [80] Power Management version 3
Capabilities: [88] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Capabilities: [ac] Subsystem: Unknown device [:]
Capabilities: [c0] Express Endpoint, MSI 00
Capabilities: [a0] MSI-X: Enable- Mask- TabSize=16
Capabilities: [100] #8086

pci_setup_device actually reads this capability and puts it into
dev-subsystem_vendor/device. So we might actually get bound to the
bridges (if the pcieport driver is unavailable). I'll post a patch to
bind to the class code instead. Good idea!

Andreas
--
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/

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Thu, Apr 23, 2015 at 5:10 PM, Adam Goode  wrote:
> On Thu, Apr 23, 2015 at 9:28 AM, Adam Goode  wrote:
>>
>> On Thu, Apr 23, 2015 at 6:08 AM, Andreas Noever
>>  wrote:
>> > Hi Adam,
>> >
>> > On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
>> > controller both use 0x1547 and are only differentiated by
>> > subvendor/subdevice.
>> >
>> > 0x156c is the 4 channel TB2 controller and was originally added by
>> > Matthew. Judging from his patch it looks like the subvendor/subdevice
>> > is set on his system:
>> > http://patchwork.ozlabs.org/patch/354626/
>> >
>> > But it also indicates that the bridges already use different ids. If
>> > that is the case then we can drop the subvendor/subdevice for 0x156c.
>> > Matthew can you confirm that on your system 0x156c is used only for
>> > the controller?
>> >
>> > Adam, could you check that suspend/resume works properly? Also your
>> > bugzilla report suggest that hotplug might now work without the
>> > driver. Could you try to revert the _OSI check (and disable the
>> > driver) and check whether everything "just works"?
>> >
>>
>> In _OSI("Darwin") mode, suspend/resume doesn't work. It failed to come
>> back from suspend.
>>
>> I have to rebuild the kernel and remove Darwin again, but I will test
>> suspend/resume in "Windows 2012" mode later.
>>
>> From previous testing, hotplug doesn't automatically work in "Windows
>> 2012" mode. It exhibits the standard no-driver behavior where devices
>> are not detected after boot. But even in "Windows 2012" mode I still
>> do get the 0x156c device, which I think used to be hidden if !Darwin.
>>
>> More testing coming...
>>
>
> I've booted into _OSI(Windows 2012) mode. I am not physically at the
> device right now, but here is the current dmesg with 1 thunderbolt
> device plugged in:
>
> [   15.576766] thunderbolt :06:00.0: NHI initialized, starting thunderbolt
> [   15.577868] thunderbolt :06:00.0: allocating TX ring 0 of size 10
> [   15.578939] thunderbolt :06:00.0: allocating RX ring 0 of size 10
> [   15.580008] thunderbolt :06:00.0: control channel created
> [   15.581068] thunderbolt :06:00.0: control channel starting...
> [   15.582122] thunderbolt :06:00.0: starting TX ring 0
> [   15.583173] thunderbolt :06:00.0: enabling interrupt at
> register 0x38200 bit 0 (0x0 -> 0x1)
> [   15.584228] thunderbolt :06:00.0: starting RX ring 0
> [   15.585281] thunderbolt :06:00.0: enabling interrupt at
> register 0x38200 bit 12 (0x1 -> 0x1001)
> [   15.586463] thunderbolt :06:00.0: initializing Switch at 0x0
> (depth: 0, up port: 5)
> [   15.587526] thunderbolt :06:00.0: old switch config:
> [   15.588569] thunderbolt :06:00.0:  Switch: 8086:156d (Revision:
> 0, TB Version: 2)
> [   15.589581] thunderbolt :06:00.0:   Max Port Number: 12
> [   15.590557] thunderbolt :06:00.0:   Config:
> [   15.591532] thunderbolt :06:00.0:Upstream Port Number: 5
> Depth: 0 Route String: 0x0 Enabled: 1, PlugEventsDelay: 255ms
> [   15.592530] thunderbolt :06:00.0:unknown1: 0x0 unknown4: 0x0
> [   15.593530] thunderbolt :06:00.0: 0: unsupported switch device id 
> 0x156d
> [   15.625612] thunderbolt :06:00.0: 0: uid: 0x1001500947a60
> [   15.626919] thunderbolt :06:00.0:  Port 0: 8086:156d (Revision:
> 0, TB Version: 1, Type: Port (0x1))
> [   15.628028] thunderbolt :06:00.0:   Max hop id (in/out): 7/7
> [   15.629050] thunderbolt :06:00.0:   Max counters: 8
> [   15.630156] thunderbolt :06:00.0:   NFC Credits: 0x70
> [   15.631685] thunderbolt :06:00.0:  Port 1: 8086:156d (Revision:
> 0, TB Version: 1, Type: Port (0x1))
> [   15.632896] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
> [   15.634000] thunderbolt :06:00.0:   Max counters: 16
> [   15.635001] thunderbolt :06:00.0:   NFC Credits: 0x3c0
> [   15.636582] thunderbolt :06:00.0:  Port 2: 8086:156d (Revision:
> 0, TB Version: 1, Type: Port (0x1))
> [   15.637737] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
> [   15.638862] thunderbolt :06:00.0:   Max counters: 16
> [   15.639875] thunderbolt :06:00.0:   NFC Credits: 0x3c0
> [   15.641452] thunderbolt :06:00.0:  Port 3: 8086:156d (Revision:
> 0, TB Version: 1, Type: Port (0x1))
> [   15.642572] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
> [   15.643702] thunderbolt :06:00.0:   Max counters: 16
> [   15.644683] thunderbolt :06:00.0:   NFC Credits: 0x3c000

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

Hi Adam,

On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
controller both use 0x1547 and are only differentiated by
subvendor/subdevice.

0x156c is the 4 channel TB2 controller and was originally added by
Matthew. Judging from his patch it looks like the subvendor/subdevice
is set on his system:
http://patchwork.ozlabs.org/patch/354626/

But it also indicates that the bridges already use different ids. If
that is the case then we can drop the subvendor/subdevice for 0x156c.
Matthew can you confirm that on your system 0x156c is used only for
the controller?

Adam, could you check that suspend/resume works properly? Also your
bugzilla report suggest that hotplug might now work without the
driver. Could you try to revert the _OSI check (and disable the
driver) and check whether everything "just works"?

Andreas

On Thu, Apr 23, 2015 at 4:56 AM, Adam Goode  wrote:
> On Wed, Apr 22, 2015 at 12:05 AM, Adam Goode  wrote:
>> (resending in plain text)
>> (please CC me on replies, I am not on LKML)
>>
>> Hi,
>>
>> I have a new Mac Mini (MacMini7,1). This model supports hotplugging of
>> Thunderbolt on Windows 8 and above. Unfortunately hotplug does not
>> seem to be working for me under Linux. I get the default behavior of
>> devices only working if plugged in during boot.
>>
>> Also, the changes made to support Darwin for _OSI seems to make it
>> impossible to override. This makes it hard to test if the ACPI support
>> for Windows 2012 will just work on Linux. I have not built a kernel
>> yet with Darwin _OSI patched out.
>>
>> Any ideas? I think there are 2 ways forward:
>>
>> 1. Fix the thunderbolt code to work with this new Mac.
>> 2. Limit the Darwin _OSI response to a whitelisted set of Mac
>> machines. It seems like new Macs going forward may work best with the
>> standard Windows 2012 response. I don't know if this method would have
>> advantages over #1. The obvious change might be chained hotplugging
>> support. I don't have a chained device to test.
>>
>
> I have fixed the issue on my machine. On the Mac Mini, the 0x156c
> device has no subvendor or subdevice. When I added the new id to
> nhi_ids, everything worked without changing anything else in the
> kernel. This is in the _OSI("Darwin").
>
> Perhaps the driver is overmatching on subvendor/subdevice. Is it
> necessary to do so on some models?
>
> Can PCI_ANY_ID just be used for subvendor/subdevice?
>
>
> Thanks,
>
> Adam
--
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/

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

On Thu, Apr 23, 2015 at 5:10 PM, Adam Goode a...@spicenitz.org wrote:
 On Thu, Apr 23, 2015 at 9:28 AM, Adam Goode a...@spicenitz.org wrote:

 On Thu, Apr 23, 2015 at 6:08 AM, Andreas Noever
 andreas.noe...@gmail.com wrote:
  Hi Adam,
 
  On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
  controller both use 0x1547 and are only differentiated by
  subvendor/subdevice.
 
  0x156c is the 4 channel TB2 controller and was originally added by
  Matthew. Judging from his patch it looks like the subvendor/subdevice
  is set on his system:
  http://patchwork.ozlabs.org/patch/354626/
 
  But it also indicates that the bridges already use different ids. If
  that is the case then we can drop the subvendor/subdevice for 0x156c.
  Matthew can you confirm that on your system 0x156c is used only for
  the controller?
 
  Adam, could you check that suspend/resume works properly? Also your
  bugzilla report suggest that hotplug might now work without the
  driver. Could you try to revert the _OSI check (and disable the
  driver) and check whether everything just works?
 

 In _OSI(Darwin) mode, suspend/resume doesn't work. It failed to come
 back from suspend.

 I have to rebuild the kernel and remove Darwin again, but I will test
 suspend/resume in Windows 2012 mode later.

 From previous testing, hotplug doesn't automatically work in Windows
 2012 mode. It exhibits the standard no-driver behavior where devices
 are not detected after boot. But even in Windows 2012 mode I still
 do get the 0x156c device, which I think used to be hidden if !Darwin.

 More testing coming...


 I've booted into _OSI(Windows 2012) mode. I am not physically at the
 device right now, but here is the current dmesg with 1 thunderbolt
 device plugged in:

 [   15.576766] thunderbolt :06:00.0: NHI initialized, starting thunderbolt
 [   15.577868] thunderbolt :06:00.0: allocating TX ring 0 of size 10
 [   15.578939] thunderbolt :06:00.0: allocating RX ring 0 of size 10
 [   15.580008] thunderbolt :06:00.0: control channel created
 [   15.581068] thunderbolt :06:00.0: control channel starting...
 [   15.582122] thunderbolt :06:00.0: starting TX ring 0
 [   15.583173] thunderbolt :06:00.0: enabling interrupt at
 register 0x38200 bit 0 (0x0 - 0x1)
 [   15.584228] thunderbolt :06:00.0: starting RX ring 0
 [   15.585281] thunderbolt :06:00.0: enabling interrupt at
 register 0x38200 bit 12 (0x1 - 0x1001)
 [   15.586463] thunderbolt :06:00.0: initializing Switch at 0x0
 (depth: 0, up port: 5)
 [   15.587526] thunderbolt :06:00.0: old switch config:
 [   15.588569] thunderbolt :06:00.0:  Switch: 8086:156d (Revision:
 0, TB Version: 2)
 [   15.589581] thunderbolt :06:00.0:   Max Port Number: 12
 [   15.590557] thunderbolt :06:00.0:   Config:
 [   15.591532] thunderbolt :06:00.0:Upstream Port Number: 5
 Depth: 0 Route String: 0x0 Enabled: 1, PlugEventsDelay: 255ms
 [   15.592530] thunderbolt :06:00.0:unknown1: 0x0 unknown4: 0x0
 [   15.593530] thunderbolt :06:00.0: 0: unsupported switch device id 
 0x156d
 [   15.625612] thunderbolt :06:00.0: 0: uid: 0x1001500947a60
 [   15.626919] thunderbolt :06:00.0:  Port 0: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.628028] thunderbolt :06:00.0:   Max hop id (in/out): 7/7
 [   15.629050] thunderbolt :06:00.0:   Max counters: 8
 [   15.630156] thunderbolt :06:00.0:   NFC Credits: 0x70
 [   15.631685] thunderbolt :06:00.0:  Port 1: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.632896] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.634000] thunderbolt :06:00.0:   Max counters: 16
 [   15.635001] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.636582] thunderbolt :06:00.0:  Port 2: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.637737] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.638862] thunderbolt :06:00.0:   Max counters: 16
 [   15.639875] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.641452] thunderbolt :06:00.0:  Port 3: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.642572] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.643702] thunderbolt :06:00.0:   Max counters: 16
 [   15.644683] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.646250] thunderbolt :06:00.0:  Port 4: 8086:156d (Revision:
 0, TB Version: 1, Type: Port (0x1))
 [   15.647285] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
 [   15.648370] thunderbolt :06:00.0:   Max counters: 16
 [   15.649460] thunderbolt :06:00.0:   NFC Credits: 0x3c0
 [   15.650539] thunderbolt :06:00.0:  Port 5: 8086:156d (Revision:
 0, TB Version: 1, Type: NHI (0x2))
 [   15.651517] thunderbolt :06:00.0:   Max hop id (in/out): 11/11
 [   15.652578] thunderbolt :06:00.0:   Max counters: 16
 [   15.653553] thunderbolt :06:00.0:   NFC Credits

Re: Thunderbolt hotplug not working on MacMini7,1

[Andreas Noever]

Hi Adam,

On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
controller both use 0x1547 and are only differentiated by
subvendor/subdevice.

0x156c is the 4 channel TB2 controller and was originally added by
Matthew. Judging from his patch it looks like the subvendor/subdevice
is set on his system:
http://patchwork.ozlabs.org/patch/354626/

But it also indicates that the bridges already use different ids. If
that is the case then we can drop the subvendor/subdevice for 0x156c.
Matthew can you confirm that on your system 0x156c is used only for
the controller?

Adam, could you check that suspend/resume works properly? Also your
bugzilla report suggest that hotplug might now work without the
driver. Could you try to revert the _OSI check (and disable the
driver) and check whether everything just works?

Andreas

On Thu, Apr 23, 2015 at 4:56 AM, Adam Goode a...@spicenitz.org wrote:
 On Wed, Apr 22, 2015 at 12:05 AM, Adam Goode a...@spicenitz.org wrote:
 (resending in plain text)
 (please CC me on replies, I am not on LKML)

 Hi,

 I have a new Mac Mini (MacMini7,1). This model supports hotplugging of
 Thunderbolt on Windows 8 and above. Unfortunately hotplug does not
 seem to be working for me under Linux. I get the default behavior of
 devices only working if plugged in during boot.

 Also, the changes made to support Darwin for _OSI seems to make it
 impossible to override. This makes it hard to test if the ACPI support
 for Windows 2012 will just work on Linux. I have not built a kernel
 yet with Darwin _OSI patched out.

 Any ideas? I think there are 2 ways forward:

 1. Fix the thunderbolt code to work with this new Mac.
 2. Limit the Darwin _OSI response to a whitelisted set of Mac
 machines. It seems like new Macs going forward may work best with the
 standard Windows 2012 response. I don't know if this method would have
 advantages over #1. The obvious change might be chained hotplugging
 support. I don't have a chained device to test.


 I have fixed the issue on my machine. On the Mac Mini, the 0x156c
 device has no subvendor or subdevice. When I added the new id to
 nhi_ids, everything worked without changing anything else in the
 kernel. This is in the _OSI(Darwin).

 Perhaps the driver is overmatching on subvendor/subdevice. Is it
 necessary to do so on some models?

 Can PCI_ANY_ID just be used for subvendor/subdevice?


 Thanks,

 Adam
--
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/

Re: Bisected regression from 3.17 still present in 3.19-rc1

[Andreas Noever]

On Mon, Dec 29, 2014 at 10:57 PM, Carlos R. Mafra  wrote:
> On Mon, 29 Dec 2014 at 22:49:37 +0100, Rafael J. Wysocki wrote:
>> On Sunday, December 28, 2014 06:54:09 PM Carlos R. Mafra wrote:
>> >
>> > The laptop is a 2-year-old macbook Pro with retina display.
>> >
>> > I use a dockapp called wmlaptop2 (http://repo.or.cz/w/wmlaptop2.git)
>> > which, among other things, displays battery information (% of charge
>> > remaining etc).
>> >
>> > With the kernel v3.17 the battery information stopped working and it
>> > still does not work in the latest v3.19-rc1.
>
> Correction: v3.18 is when it stopped working, not v3.17.
>
>> > Looking at what wmlaptop2 does I noticed that one entry inside
>> > /sys/class/power_supply is not present in a bad kernel.
>> >
>> > In a good kernel:
>> >
>> > [mafra@linux-g29b:~]$ ls /sys/class/power_supply/
>> > ADP1@  BAT0@
>> >
>> > but in v3.17 onwards there's no BAT0@ entry:
>> >
>> > [mafra@linux-g29b:~]$ ls /sys/class/power_supply/
>> > ADP1@
>> >
>> > I bisected the problem to this commit:
>>
>> Does it help if you revert this commit from 3.19-rc1 (or -rc2)?
>
> Yes, I just did that now (it reverts cleanly) and reverting the
> commit makes it work again.
Could you try to revert 9faf6136ff4647452580b019f4b16f8c5082e589 (ACPI
/ SBS: Disable smart battery manager on Apple) and possibly also
3031cddea633ea5328162d3d712a582e4205dbed (ACPI / SBS: Don't assume the
existence of an SBS charger) without reverting "ACPI: Support
_OSI("Darwin") correctly"?

As far as I understand these two were added because the third patch
breaks battery support on some Apple systems. Maybe the fix is only
needed for some models (and makes your model fail)?


>
>> > commit 7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334
>> > Author: Matthew Garrett 
>> > Date:   Sat Sep 20 13:19:47 2014 +0200
>> >
>> > ACPI: Support _OSI("Darwin") correctly
>> >
>> >
>> > Is there anything else I can do to help fixing this?
>> >
>> > PS: the bisect log:
>> >
>> > git bisect start
>> > # bad: [f114040e3ea6e07372334ade75d1ee0775c355e1] Linux 3.18-rc1
>> > git bisect bad f114040e3ea6e07372334ade75d1ee0775c355e1
>> > # good: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17
>> > git bisect good bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9
>> > # good: [35a9ad8af0bb0fa3525e6d0d20e32551d226f38e] Merge 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>> > git bisect good 35a9ad8af0bb0fa3525e6d0d20e32551d226f38e
>> > # bad: [d6dd50e07c5bec00db2005969b1a01f8ca3d25ef] Merge branch 
>> > 'core-rcu-for-linus' of 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> > git bisect bad d6dd50e07c5bec00db2005969b1a01f8ca3d25ef
>> > # bad: [bf65dea87e87c53ba4f97c6432761498bc977efd] Merge tag 
>> > 'edac/v3.18-rc1' of 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac
>> > git bisect bad bf65dea87e87c53ba4f97c6432761498bc977efd
>> > # bad: [b211e9d7c861bdb37b86d6384da9edfb80949ceb] Merge branch 'for-3.18' 
>> > of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
>> > git bisect bad b211e9d7c861bdb37b86d6384da9edfb80949ceb
>> > # good: [80213c03c4151d900cf293ef0fc51f8d88495e14] Merge tag 
>> > 'pci-v3.18-changes' of 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
>> > git bisect good 80213c03c4151d900cf293ef0fc51f8d88495e14
>> > # good: [7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0] nosave: consolidate 
>> > __nosave_{begin,end} in 
>> > git bisect good 7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0
>> > # bad: [49a09c9ab012017c4673b86dbb28c616cf8f2381] Merge branch 'pm-domains'
>> > git bisect bad 49a09c9ab012017c4673b86dbb28c616cf8f2381
>> > # bad: [88b42a4883a7783972c8fc607e60bd3f027e24de] Merge branch 'pm-genirq'
>> > git bisect bad 88b42a4883a7783972c8fc607e60bd3f027e24de
>> > # bad: [a13f453140d542f9d5a0ee15601531c72e5401d7] Merge branch 'acpi-lpss'
>> > git bisect bad a13f453140d542f9d5a0ee15601531c72e5401d7
>> > # bad: [939558f2a4b7851c11ce8d08387730914a1e1f5f] Merge branch 'acpi-apple'
>> > git bisect bad 939558f2a4b7851c11ce8d08387730914a1e1f5f
>> > # good: [5a0b8deeeb19906b24a48d0078aa6b64dc0b4dab] ACPICA: Clear all 
>> > non-wakeup GPEs in acpi_hw_enable_wakeup_gpe_block()
>> > git bisect good 5a0b8deeeb19906b24a48d0078aa6b64dc0b4dab
>> > # bad: [7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334] ACPI: Support 
>> > _OSI("Darwin") correctly
>> > git bisect bad 7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334
>> > # good: [9faf6136ff4647452580b019f4b16f8c5082e589] ACPI / SBS: Disable 
>> > smart battery manager on Apple
>> > git bisect good 9faf6136ff4647452580b019f4b16f8c5082e589
>> > # first bad commit: [7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334] ACPI: 
>> > Support _OSI("Darwin") correctly
>> > [mafra@linux-g29b:linux-2.6]$
>> > --
>> > 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  

Re: Bisected regression from 3.17 still present in 3.19-rc1

[Andreas Noever]

On Mon, Dec 29, 2014 at 10:57 PM, Carlos R. Mafra crma...@gmail.com wrote:
 On Mon, 29 Dec 2014 at 22:49:37 +0100, Rafael J. Wysocki wrote:
 On Sunday, December 28, 2014 06:54:09 PM Carlos R. Mafra wrote:
 
  The laptop is a 2-year-old macbook Pro with retina display.
 
  I use a dockapp called wmlaptop2 (http://repo.or.cz/w/wmlaptop2.git)
  which, among other things, displays battery information (% of charge
  remaining etc).
 
  With the kernel v3.17 the battery information stopped working and it
  still does not work in the latest v3.19-rc1.

 Correction: v3.18 is when it stopped working, not v3.17.

  Looking at what wmlaptop2 does I noticed that one entry inside
  /sys/class/power_supply is not present in a bad kernel.
 
  In a good kernel:
 
  [mafra@linux-g29b:~]$ ls /sys/class/power_supply/
  ADP1@  BAT0@
 
  but in v3.17 onwards there's no BAT0@ entry:
 
  [mafra@linux-g29b:~]$ ls /sys/class/power_supply/
  ADP1@
 
  I bisected the problem to this commit:

 Does it help if you revert this commit from 3.19-rc1 (or -rc2)?

 Yes, I just did that now (it reverts cleanly) and reverting the
 commit makes it work again.
Could you try to revert 9faf6136ff4647452580b019f4b16f8c5082e589 (ACPI
/ SBS: Disable smart battery manager on Apple) and possibly also
3031cddea633ea5328162d3d712a582e4205dbed (ACPI / SBS: Don't assume the
existence of an SBS charger) without reverting ACPI: Support
_OSI(Darwin) correctly?

As far as I understand these two were added because the third patch
breaks battery support on some Apple systems. Maybe the fix is only
needed for some models (and makes your model fail)?



  commit 7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334
  Author: Matthew Garrett matthew.garr...@nebula.com
  Date:   Sat Sep 20 13:19:47 2014 +0200
 
  ACPI: Support _OSI(Darwin) correctly
 
 
  Is there anything else I can do to help fixing this?
 
  PS: the bisect log:
 
  git bisect start
  # bad: [f114040e3ea6e07372334ade75d1ee0775c355e1] Linux 3.18-rc1
  git bisect bad f114040e3ea6e07372334ade75d1ee0775c355e1
  # good: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17
  git bisect good bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9
  # good: [35a9ad8af0bb0fa3525e6d0d20e32551d226f38e] Merge 
  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
  git bisect good 35a9ad8af0bb0fa3525e6d0d20e32551d226f38e
  # bad: [d6dd50e07c5bec00db2005969b1a01f8ca3d25ef] Merge branch 
  'core-rcu-for-linus' of 
  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
  git bisect bad d6dd50e07c5bec00db2005969b1a01f8ca3d25ef
  # bad: [bf65dea87e87c53ba4f97c6432761498bc977efd] Merge tag 
  'edac/v3.18-rc1' of 
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac
  git bisect bad bf65dea87e87c53ba4f97c6432761498bc977efd
  # bad: [b211e9d7c861bdb37b86d6384da9edfb80949ceb] Merge branch 'for-3.18' 
  of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
  git bisect bad b211e9d7c861bdb37b86d6384da9edfb80949ceb
  # good: [80213c03c4151d900cf293ef0fc51f8d88495e14] Merge tag 
  'pci-v3.18-changes' of 
  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
  git bisect good 80213c03c4151d900cf293ef0fc51f8d88495e14
  # good: [7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0] nosave: consolidate 
  __nosave_{begin,end} in asm/sections.h
  git bisect good 7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0
  # bad: [49a09c9ab012017c4673b86dbb28c616cf8f2381] Merge branch 'pm-domains'
  git bisect bad 49a09c9ab012017c4673b86dbb28c616cf8f2381
  # bad: [88b42a4883a7783972c8fc607e60bd3f027e24de] Merge branch 'pm-genirq'
  git bisect bad 88b42a4883a7783972c8fc607e60bd3f027e24de
  # bad: [a13f453140d542f9d5a0ee15601531c72e5401d7] Merge branch 'acpi-lpss'
  git bisect bad a13f453140d542f9d5a0ee15601531c72e5401d7
  # bad: [939558f2a4b7851c11ce8d08387730914a1e1f5f] Merge branch 'acpi-apple'
  git bisect bad 939558f2a4b7851c11ce8d08387730914a1e1f5f
  # good: [5a0b8deeeb19906b24a48d0078aa6b64dc0b4dab] ACPICA: Clear all 
  non-wakeup GPEs in acpi_hw_enable_wakeup_gpe_block()
  git bisect good 5a0b8deeeb19906b24a48d0078aa6b64dc0b4dab
  # bad: [7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334] ACPI: Support 
  _OSI(Darwin) correctly
  git bisect bad 7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334
  # good: [9faf6136ff4647452580b019f4b16f8c5082e589] ACPI / SBS: Disable 
  smart battery manager on Apple
  git bisect good 9faf6136ff4647452580b019f4b16f8c5082e589
  # first bad commit: [7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334] ACPI: 
  Support _OSI(Darwin) correctly
  [mafra@linux-g29b:linux-2.6]$
  --
  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/

 --
 I speak only for myself.
 Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More 

Re: thunderbolt: Deletion of unnecessary checks before the function call "ring_free"

[Andreas Noever]

On Sun, Nov 23, 2014 at 4:20 PM, Joe Perches  wrote:
> On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
>> >> 2. Are any additional prefixes appropriate so that further name space
>> >>conflicts can be better avoided?
>> >
>> > To avoid possible external naming conflicts, add tb_ prefix to
>> > various ring_ structs and functions.
>>
>> Do you imagine that any XEN software developers need also to reconsider
>> this implementation detail?
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/xen-tpmfront.c?id=fc14f9c1272f62c3e8d01300f52467c0d9af50f9#n268
>
> I think static functions can be named whatever
> the developer chooses.
Do symbols which are not exported (no EXPORT_SYMBOL_(GPL)) cause
conflicts? I was under the impression that those are module private.
If they are indeed private then I would prefer to not rename them.
--
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/

Re: thunderbolt: Deletion of unnecessary checks before the function call ring_free

[Andreas Noever]

On Sun, Nov 23, 2014 at 4:20 PM, Joe Perches j...@perches.com wrote:
 On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
  2. Are any additional prefixes appropriate so that further name space
 conflicts can be better avoided?
 
  To avoid possible external naming conflicts, add tb_ prefix to
  various ring_foo structs and functions.

 Do you imagine that any XEN software developers need also to reconsider
 this implementation detail?
 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/xen-tpmfront.c?id=fc14f9c1272f62c3e8d01300f52467c0d9af50f9#n268

 I think static functions can be named whatever
 the developer chooses.
Do symbols which are not exported (no EXPORT_SYMBOL_(GPL)) cause
conflicts? I was under the impression that those are module private.
If they are indeed private then I would prefer to not rename them.
--
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/

Re: [PATCH 1/1] thunderbolt: Deletion of unnecessary checks before the function call "ring_free"

[Andreas Noever]

Hi Markus,

ring_free does not check for null:
http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c#L398

Maybe your software confuses the method with:
http://lxr.free-electrons.com/source/drivers/char/tpm/xen-tpmfront.c#L268

Andreas

On Fri, Nov 21, 2014 at 11:40 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Fri, 21 Nov 2014 11:30:18 +0100
>
> The ring_free() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/thunderbolt/ctl.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
> index 799634b..55b9bdf 100644
> --- a/drivers/thunderbolt/ctl.c
> +++ b/drivers/thunderbolt/ctl.c
> @@ -520,10 +520,8 @@ err:
>  void tb_ctl_free(struct tb_ctl *ctl)
>  {
> int i;
> -   if (ctl->rx)
> -   ring_free(ctl->rx);
> -   if (ctl->tx)
> -   ring_free(ctl->tx);
> +   ring_free(ctl->rx);
> +   ring_free(ctl->tx);
>
> /* free RX packets */
> for (i = 0; i < TB_CTL_RX_PKG_COUNT; i++)
> --
> 2.1.3
>
--
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/

Re: [PATCH 1/1] thunderbolt: Deletion of unnecessary checks before the function call ring_free

[Andreas Noever]

Hi Markus,

ring_free does not check for null:
http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c#L398

Maybe your software confuses the method with:
http://lxr.free-electrons.com/source/drivers/char/tpm/xen-tpmfront.c#L268

Andreas

On Fri, Nov 21, 2014 at 11:40 AM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
 From: Markus Elfring elfr...@users.sourceforge.net
 Date: Fri, 21 Nov 2014 11:30:18 +0100

 The ring_free() function tests whether its argument is NULL and then
 returns immediately. Thus the test around the call is not needed.

 This issue was detected by using the Coccinelle software.

 Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
 ---
  drivers/thunderbolt/ctl.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

 diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
 index 799634b..55b9bdf 100644
 --- a/drivers/thunderbolt/ctl.c
 +++ b/drivers/thunderbolt/ctl.c
 @@ -520,10 +520,8 @@ err:
  void tb_ctl_free(struct tb_ctl *ctl)
  {
 int i;
 -   if (ctl-rx)
 -   ring_free(ctl-rx);
 -   if (ctl-tx)
 -   ring_free(ctl-tx);
 +   ring_free(ctl-rx);
 +   ring_free(ctl-tx);

 /* free RX packets */
 for (i = 0; i  TB_CTL_RX_PKG_COUNT; i++)
 --
 2.1.3

--
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/

Re: [PATCH] pci: support Thunderbolt requirements for I/O resources.

[Andreas Noever]

On Tue, Nov 18, 2014 at 9:20 AM, Jamet, Michael  wrote:
>> -Original Message-
>> From: Andreas Noever [mailto:andreas.noe...@gmail.com]
>> Sent: Wednesday, November 12, 2014 22:19
>> To: Andy Shevchenko
>> Cc: Bjorn Helgaas; Jamet, Michael; linux-...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; Levy, Amir (Jer); Alloun, Dan; Rafael Wysocki
>> Subject: Re: [PATCH] pci: support Thunderbolt requirements for I/O
>> resources.
>>
>> On Wed, Nov 12, 2014 at 7:30 PM, Andy Shevchenko
>>  wrote:
>> > On Wed, Nov 12, 2014 at 7:29 PM, Bjorn Helgaas 
>> wrote:
>> >
>> > []
>> >
>> >>> To prevent this, we detect a chain contains a Thunderbolt device by
>> >>> checking the Thunderbolt PCI device id.
>> >>
>> >> I'm really not happy about checking a list of device IDs to identify
>> >> Thunderbolt devices.  Surely there's a better way, because a list
>> >> like this has to be updated regularly.
>> >
>> > I recently proposed internally to use quirks (pci_fixup_early) for
>> > that, but apparently Michael didn't have time to answer. It might be
>> > he can just comment here since the patch already public.
>>
>> In any case: this will interfere with thunderbolt hotplug on Apple systems,
>> where we do not have BIOS support and have to handle hotplug events and
>> assign resources ourselves. So please add a DMI check for Apple (the reverse
>> of what we do in
>> http://lxr.free-
>> electrons.com/source/drivers/thunderbolt/nhi.c?v=3.17#L664
>> ).
>>
>> Thanks,
>> Andreas
>
> This is correct that the hotplug handling mechanism and interaction with BIOS 
> is different.
> However, this patch also applies for any case, since the I/O space is limited
> and need to be preserved, so we must prevent allocation of I/O resources
> from the devices and avoiding exhaustion while chaining them.

Now I am slightly confused. Does the BIOS (on non Apple hardware)
leave I/O resources always unassigned? Your first post seemed to imply
that it does assign some and that we should not interfere. In that
case we would have to assign them on Apple systems ourselves. On the
other hand if no TB device uses I/O resources and the BIOS never
assigns them, then why do devices fail if we exhaust them?

Andreas




> Michael
>
>
> -
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
--
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/

Re: [PATCH] pci: support Thunderbolt requirements for I/O resources.

[Andreas Noever]

On Tue, Nov 18, 2014 at 9:20 AM, Jamet, Michael michael.ja...@intel.com wrote:
 -Original Message-
 From: Andreas Noever [mailto:andreas.noe...@gmail.com]
 Sent: Wednesday, November 12, 2014 22:19
 To: Andy Shevchenko
 Cc: Bjorn Helgaas; Jamet, Michael; linux-...@vger.kernel.org; linux-
 ker...@vger.kernel.org; Levy, Amir (Jer); Alloun, Dan; Rafael Wysocki
 Subject: Re: [PATCH] pci: support Thunderbolt requirements for I/O
 resources.

 On Wed, Nov 12, 2014 at 7:30 PM, Andy Shevchenko
 andy.shevche...@gmail.com wrote:
  On Wed, Nov 12, 2014 at 7:29 PM, Bjorn Helgaas bhelg...@google.com
 wrote:
 
  []
 
  To prevent this, we detect a chain contains a Thunderbolt device by
  checking the Thunderbolt PCI device id.
 
  I'm really not happy about checking a list of device IDs to identify
  Thunderbolt devices.  Surely there's a better way, because a list
  like this has to be updated regularly.
 
  I recently proposed internally to use quirks (pci_fixup_early) for
  that, but apparently Michael didn't have time to answer. It might be
  he can just comment here since the patch already public.

 In any case: this will interfere with thunderbolt hotplug on Apple systems,
 where we do not have BIOS support and have to handle hotplug events and
 assign resources ourselves. So please add a DMI check for Apple (the reverse
 of what we do in
 http://lxr.free-
 electrons.com/source/drivers/thunderbolt/nhi.c?v=3.17#L664
 ).

 Thanks,
 Andreas

 This is correct that the hotplug handling mechanism and interaction with BIOS 
 is different.
 However, this patch also applies for any case, since the I/O space is limited
 and need to be preserved, so we must prevent allocation of I/O resources
 from the devices and avoiding exhaustion while chaining them.

Now I am slightly confused. Does the BIOS (on non Apple hardware)
leave I/O resources always unassigned? Your first post seemed to imply
that it does assign some and that we should not interfere. In that
case we would have to assign them on Apple systems ourselves. On the
other hand if no TB device uses I/O resources and the BIOS never
assigns them, then why do devices fail if we exhaust them?

Andreas




 Michael


 -
 Intel Israel (74) Limited

 This e-mail and any attachments may contain confidential material for
 the sole use of the intended recipient(s). Any review or distribution
 by others is strictly prohibited. If you are not the intended
 recipient, please contact the sender and delete all copies.
--
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/

Re: [PATCH] pci: support Thunderbolt requirements for I/O resources.

[Andreas Noever]

On Wed, Nov 12, 2014 at 7:30 PM, Andy Shevchenko
 wrote:
> On Wed, Nov 12, 2014 at 7:29 PM, Bjorn Helgaas  wrote:
>
> []
>
>>> To prevent this, we detect a chain contains a Thunderbolt
>>> device by checking the Thunderbolt PCI device id.
>>
>> I'm really not happy about checking a list of device IDs to identify
>> Thunderbolt devices.  Surely there's a better way, because a list like
>> this has to be updated regularly.
>
> I recently proposed internally to use quirks (pci_fixup_early) for
> that, but apparently Michael didn't have time to answer. It might be
> he can just comment here since the patch already public.

In any case: this will interfere with thunderbolt hotplug on Apple
systems, where we do not have BIOS support and have to handle hotplug
events and assign resources ourselves. So please add a DMI check for
Apple (the reverse of what we do in
http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c?v=3.17#L664
).

Thanks,
Andreas
--
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/

Re: [PATCH] pci: support Thunderbolt requirements for I/O resources.

[Andreas Noever]

On Wed, Nov 12, 2014 at 7:30 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
 On Wed, Nov 12, 2014 at 7:29 PM, Bjorn Helgaas bhelg...@google.com wrote:

 []

 To prevent this, we detect a chain contains a Thunderbolt
 device by checking the Thunderbolt PCI device id.

 I'm really not happy about checking a list of device IDs to identify
 Thunderbolt devices.  Surely there's a better way, because a list like
 this has to be updated regularly.

 I recently proposed internally to use quirks (pci_fixup_early) for
 that, but apparently Michael didn't have time to answer. It might be
 he can just comment here since the patch already public.

In any case: this will interfere with thunderbolt hotplug on Apple
systems, where we do not have BIOS support and have to handle hotplug
events and assign resources ourselves. So please add a DMI check for
Apple (the reverse of what we do in
http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c?v=3.17#L664
).

Thanks,
Andreas
--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Mon, Sep 22, 2014 at 4:25 PM, Bjorn Helgaas  wrote:
> On Sat, Sep 20, 2014 at 12:41 PM, Dirk Gouders  wrote:
>> Bjorn Helgaas  writes:
>>
>>> On Sat, Sep 13, 2014 at 09:41:34PM +0200, Dirk Gouders wrote:
 So, I did some tests on the VX50 which probably wasn't the worst idea,
 because it behaves different than the test machine.

 Summary:

 1) Bjorn's back pocket patch works on the VX50.

On the test machine it causes a trace, mount_root has to do with
it.  I tried to use netconsole but it complained the interface were
not ready.
>>>
>>> OK, that's good.  I put this revert patch in for-linus for v3.17.  I regard
>>> this as a temporary fix, not the real solution.  My guess is the test
>>> machine doesn't boot because you're missing a driver, so not related to the
>>> revert patch.
>>
>> I assumed my limit-host-bridge-aperture-and-ignore-bridges-patch on top
>> of your patch caused this, so I took a closer look.
>>
>> Your patch works fine with current rc5+ on the test machine -- with and
>> without my additional patch.
>
> Great, thanks for testing that!
>
>> Other various today's test results (VX50) will be appended to bugzilla
>> in a few moments.
>
> The Windows Server 2008 boot shows that Windows reconfigures the
> 00:0e.0 bridge so it fits inside the [bus 00-07] aperture reported by
> the host bridge _CRS, and the LSI FC adapter is not enumerated at all.
> That's basically the same behavior that prompted your bug report.
> This suggests that Windows does *not* reset the secondary bus when
> changing the bridge configuration.
>
> For v3.17, I reverted 1820ffdccb9b ("PCI: Make sure bus number
> resources stay within their parents bounds").  For the future, I think
> we should do a quirk to fix the _CRS, similar to what Andreas has
> posted, and apply 1820ffdccb9b again.
>
> But I think the quirk should be specific to this system and BIOS.  I
> don't want to add a workaround that silently covers up Linux and BIOS
> bugs.  The reason amd_bus.c exists is because Linux was not smart
> enough to pay attention to _CRS.  Linux is now pretty good at that, so
> the reason for amd_bus.c is mostly gone.  I don't want to add new
> dependencies on amd_bus.c that will prevent us from phasing it out.
Why not always trust amd_bus over _CRS? Is there a scenario in which
amd_bus is wrong?

Are these methods (like _CRS) meant to set limits for us, or are they
simply used to report the configuration decisions made by the BIOS? So
if _CRS says that the window is [00-07] would it be ok for us to
simply increase it (possibly after reprogramming the registers in
amd_bus)?
--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Mon, Sep 22, 2014 at 4:25 PM, Bjorn Helgaas bhelg...@google.com wrote:
 On Sat, Sep 20, 2014 at 12:41 PM, Dirk Gouders d...@gouders.net wrote:
 Bjorn Helgaas bhelg...@google.com writes:

 On Sat, Sep 13, 2014 at 09:41:34PM +0200, Dirk Gouders wrote:
 So, I did some tests on the VX50 which probably wasn't the worst idea,
 because it behaves different than the test machine.

 Summary:

 1) Bjorn's back pocket patch works on the VX50.

On the test machine it causes a trace, mount_root has to do with
it.  I tried to use netconsole but it complained the interface were
not ready.

 OK, that's good.  I put this revert patch in for-linus for v3.17.  I regard
 this as a temporary fix, not the real solution.  My guess is the test
 machine doesn't boot because you're missing a driver, so not related to the
 revert patch.

 I assumed my limit-host-bridge-aperture-and-ignore-bridges-patch on top
 of your patch caused this, so I took a closer look.

 Your patch works fine with current rc5+ on the test machine -- with and
 without my additional patch.

 Great, thanks for testing that!

 Other various today's test results (VX50) will be appended to bugzilla
 in a few moments.

 The Windows Server 2008 boot shows that Windows reconfigures the
 00:0e.0 bridge so it fits inside the [bus 00-07] aperture reported by
 the host bridge _CRS, and the LSI FC adapter is not enumerated at all.
 That's basically the same behavior that prompted your bug report.
 This suggests that Windows does *not* reset the secondary bus when
 changing the bridge configuration.

 For v3.17, I reverted 1820ffdccb9b (PCI: Make sure bus number
 resources stay within their parents bounds).  For the future, I think
 we should do a quirk to fix the _CRS, similar to what Andreas has
 posted, and apply 1820ffdccb9b again.

 But I think the quirk should be specific to this system and BIOS.  I
 don't want to add a workaround that silently covers up Linux and BIOS
 bugs.  The reason amd_bus.c exists is because Linux was not smart
 enough to pay attention to _CRS.  Linux is now pretty good at that, so
 the reason for amd_bus.c is mostly gone.  I don't want to add new
 dependencies on amd_bus.c that will prevent us from phasing it out.
Why not always trust amd_bus over _CRS? Is there a scenario in which
amd_bus is wrong?

Are these methods (like _CRS) meant to set limits for us, or are they
simply used to report the configuration decisions made by the BIOS? So
if _CRS says that the window is [00-07] would it be ok for us to
simply increase it (possibly after reprogramming the registers in
amd_bus)?
--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

Updated version with dmi strings. Dirk can you test this (without pci=nocrs) 
and look for
PCI: Ignoring host bridge windows from ACPI
If it does not show up then I have messed up the DMI_MATCH macros. In that case
please try to boot with pci=nocrs.

Bjorn, this would expand the meaning of nocrs to also ignore the bus window 
from crs. I can also add a separate flag (like pci_ignore_seg) and match the 
old behavior.

Thanks,
Andreas

---
 arch/x86/pci/acpi.c | 17 +
 arch/x86/pci/bus_numa.c | 12 +---
 2 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..c9ebc36 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -107,6 +107,16 @@ static const struct dmi_system_id pci_crs_quirks[] 
__initconst = {
DMI_MATCH(DMI_BIOS_VERSION, "6JET85WW (1.43 )"),
},
},
+   /* https://bugzilla.kernel.org/show_bug.cgi?id=84281 */
+   {
+   .callback = set_nouse_crs,
+   .ident = "TYAN Transport VX50 B4985",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "TYAN Computer 
Corporation"),
+   DMI_MATCH(DMI_BOARD_NAME, "Tyan Transport VX50-B4985"),
+   DMI_MATCH(DMI_BIOS_VERSION, "TYAN Transport VX50 B4985 
BIOS V3.01.B30"),
+   },
+   },
 
/* https://bugzilla.kernel.org/show_bug.cgi?id=15362 */
{
@@ -522,15 +532,14 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
} else {
probe_pci_root_info(info, device, busnum, domain);
 
-   /* insert busn res at first */
-   pci_add_resource(,  >secondary);
/*
 * _CRS with no apertures is normal, so only fall back to
 * defaults or native bridge info if we're ignoring _CRS.
 */
-   if (pci_use_crs)
+   if (pci_use_crs) {
+   pci_add_resource(,  >secondary);
add_resources(info, );
-   else {
+   } else {
free_pci_root_info_res(info);
x86_pci_root_bus_resources(busnum, );
}
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index f3a2cfc..b735d0e 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -31,8 +31,6 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
 {
struct pci_root_info *info = x86_find_pci_root_info(bus);
struct pci_root_res *root_res;
-   struct pci_host_bridge_window *window;
-   bool found = false;
 
if (!info)
goto default_resources;
@@ -40,15 +38,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
printk(KERN_DEBUG "PCI: root bus %02x: hardware-probed resources\n",
   bus);
 
-   /* already added by acpi ? */
-   list_for_each_entry(window, resources, list)
-   if (window->res->flags & IORESOURCE_BUS) {
-   found = true;
-   break;
-   }
-
-   if (!found)
-   pci_add_resource(resources, >busn);
+   pci_add_resource(resources, >busn);
 
list_for_each_entry(root_res, >resources, list) {
struct resource *res;
-- 
2.1.0

--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

This is an implementation of fix 1 (Add a quirk to fix the _CRS information
based on what amd_bus.c read from the hardware) which makes pci=nocrs ignore 
bus numbers from crs.

If this works then we can add the board to the crs blacklist (Dirk can you 
attach the output of dmidecode to the bugzilla report?).



---
 arch/x86/pci/acpi.c |  7 +++
 arch/x86/pci/bus_numa.c | 12 +---
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..b073948 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -522,15 +522,14 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
} else {
probe_pci_root_info(info, device, busnum, domain);
 
-   /* insert busn res at first */
-   pci_add_resource(,  >secondary);
/*
 * _CRS with no apertures is normal, so only fall back to
 * defaults or native bridge info if we're ignoring _CRS.
 */
-   if (pci_use_crs)
+   if (pci_use_crs) {
+   pci_add_resource(,  >secondary);
add_resources(info, );
-   else {
+   } else {
free_pci_root_info_res(info);
x86_pci_root_bus_resources(busnum, );
}
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index f3a2cfc..b735d0e 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -31,8 +31,6 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
 {
struct pci_root_info *info = x86_find_pci_root_info(bus);
struct pci_root_res *root_res;
-   struct pci_host_bridge_window *window;
-   bool found = false;
 
if (!info)
goto default_resources;
@@ -40,15 +38,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
printk(KERN_DEBUG "PCI: root bus %02x: hardware-probed resources\n",
   bus);
 
-   /* already added by acpi ? */
-   list_for_each_entry(window, resources, list)
-   if (window->res->flags & IORESOURCE_BUS) {
-   found = true;
-   break;
-   }
-
-   if (!found)
-   pci_add_resource(resources, >busn);
+   pci_add_resource(resources, >busn);
 
list_for_each_entry(root_res, >resources, list) {
struct resource *res;
-- 
2.1.0

--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

This is an implementation of fix 1 (Add a quirk to fix the _CRS information
based on what amd_bus.c read from the hardware) which makes pci=nocrs ignore 
bus numbers from crs.

If this works then we can add the board to the crs blacklist (Dirk can you 
attach the output of dmidecode to the bugzilla report?).



---
 arch/x86/pci/acpi.c |  7 +++
 arch/x86/pci/bus_numa.c | 12 +---
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..b073948 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -522,15 +522,14 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
} else {
probe_pci_root_info(info, device, busnum, domain);
 
-   /* insert busn res at first */
-   pci_add_resource(,  >secondary);
/*
 * _CRS with no apertures is normal, so only fall back to
 * defaults or native bridge info if we're ignoring _CRS.
 */
-   if (pci_use_crs)
+   if (pci_use_crs) {
+   pci_add_resource(,  >secondary);
add_resources(info, );
-   else {
+   } else {
free_pci_root_info_res(info);
x86_pci_root_bus_resources(busnum, );
}
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index f3a2cfc..b735d0e 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -31,8 +31,6 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
 {
struct pci_root_info *info = x86_find_pci_root_info(bus);
struct pci_root_res *root_res;
-   struct pci_host_bridge_window *window;
-   bool found = false;
 
if (!info)
goto default_resources;
@@ -40,15 +38,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
printk(KERN_DEBUG "PCI: root bus %02x: hardware-probed resources\n",
   bus);
 
-   /* already added by acpi ? */
-   list_for_each_entry(window, resources, list)
-   if (window->res->flags & IORESOURCE_BUS) {
-   found = true;
-   break;
-   }
-
-   if (!found)
-   pci_add_resource(resources, >busn);
+   pci_add_resource(resources, >busn);
 
list_for_each_entry(root_res, >resources, list) {
struct resource *res;
-- 
2.1.0

--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

This is an implementation of fix 1 (Add a quirk to fix the _CRS information
based on what amd_bus.c read from the hardware) which makes pci=nocrs ignore 
bus numbers from crs.

If this works then we can add the board to the crs blacklist (Dirk can you 
attach the output of dmidecode to the bugzilla report?).



---
 arch/x86/pci/acpi.c |  7 +++
 arch/x86/pci/bus_numa.c | 12 +---
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..b073948 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -522,15 +522,14 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
} else {
probe_pci_root_info(info, device, busnum, domain);
 
-   /* insert busn res at first */
-   pci_add_resource(resources,  root-secondary);
/*
 * _CRS with no apertures is normal, so only fall back to
 * defaults or native bridge info if we're ignoring _CRS.
 */
-   if (pci_use_crs)
+   if (pci_use_crs) {
+   pci_add_resource(resources,  root-secondary);
add_resources(info, resources);
-   else {
+   } else {
free_pci_root_info_res(info);
x86_pci_root_bus_resources(busnum, resources);
}
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index f3a2cfc..b735d0e 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -31,8 +31,6 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
 {
struct pci_root_info *info = x86_find_pci_root_info(bus);
struct pci_root_res *root_res;
-   struct pci_host_bridge_window *window;
-   bool found = false;
 
if (!info)
goto default_resources;
@@ -40,15 +38,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
printk(KERN_DEBUG PCI: root bus %02x: hardware-probed resources\n,
   bus);
 
-   /* already added by acpi ? */
-   list_for_each_entry(window, resources, list)
-   if (window-res-flags  IORESOURCE_BUS) {
-   found = true;
-   break;
-   }
-
-   if (!found)
-   pci_add_resource(resources, info-busn);
+   pci_add_resource(resources, info-busn);
 
list_for_each_entry(root_res, info-resources, list) {
struct resource *res;
-- 
2.1.0

--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

This is an implementation of fix 1 (Add a quirk to fix the _CRS information
based on what amd_bus.c read from the hardware) which makes pci=nocrs ignore 
bus numbers from crs.

If this works then we can add the board to the crs blacklist (Dirk can you 
attach the output of dmidecode to the bugzilla report?).



---
 arch/x86/pci/acpi.c |  7 +++
 arch/x86/pci/bus_numa.c | 12 +---
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..b073948 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -522,15 +522,14 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
} else {
probe_pci_root_info(info, device, busnum, domain);
 
-   /* insert busn res at first */
-   pci_add_resource(resources,  root-secondary);
/*
 * _CRS with no apertures is normal, so only fall back to
 * defaults or native bridge info if we're ignoring _CRS.
 */
-   if (pci_use_crs)
+   if (pci_use_crs) {
+   pci_add_resource(resources,  root-secondary);
add_resources(info, resources);
-   else {
+   } else {
free_pci_root_info_res(info);
x86_pci_root_bus_resources(busnum, resources);
}
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index f3a2cfc..b735d0e 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -31,8 +31,6 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
 {
struct pci_root_info *info = x86_find_pci_root_info(bus);
struct pci_root_res *root_res;
-   struct pci_host_bridge_window *window;
-   bool found = false;
 
if (!info)
goto default_resources;
@@ -40,15 +38,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
printk(KERN_DEBUG PCI: root bus %02x: hardware-probed resources\n,
   bus);
 
-   /* already added by acpi ? */
-   list_for_each_entry(window, resources, list)
-   if (window-res-flags  IORESOURCE_BUS) {
-   found = true;
-   break;
-   }
-
-   if (!found)
-   pci_add_resource(resources, info-busn);
+   pci_add_resource(resources, info-busn);
 
list_for_each_entry(root_res, info-resources, list) {
struct resource *res;
-- 
2.1.0

--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

Updated version with dmi strings. Dirk can you test this (without pci=nocrs) 
and look for
PCI: Ignoring host bridge windows from ACPI
If it does not show up then I have messed up the DMI_MATCH macros. In that case
please try to boot with pci=nocrs.

Bjorn, this would expand the meaning of nocrs to also ignore the bus window 
from crs. I can also add a separate flag (like pci_ignore_seg) and match the 
old behavior.

Thanks,
Andreas

---
 arch/x86/pci/acpi.c | 17 +
 arch/x86/pci/bus_numa.c | 12 +---
 2 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..c9ebc36 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -107,6 +107,16 @@ static const struct dmi_system_id pci_crs_quirks[] 
__initconst = {
DMI_MATCH(DMI_BIOS_VERSION, 6JET85WW (1.43 )),
},
},
+   /* https://bugzilla.kernel.org/show_bug.cgi?id=84281 */
+   {
+   .callback = set_nouse_crs,
+   .ident = TYAN Transport VX50 B4985,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, TYAN Computer 
Corporation),
+   DMI_MATCH(DMI_BOARD_NAME, Tyan Transport VX50-B4985),
+   DMI_MATCH(DMI_BIOS_VERSION, TYAN Transport VX50 B4985 
BIOS V3.01.B30),
+   },
+   },
 
/* https://bugzilla.kernel.org/show_bug.cgi?id=15362 */
{
@@ -522,15 +532,14 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
} else {
probe_pci_root_info(info, device, busnum, domain);
 
-   /* insert busn res at first */
-   pci_add_resource(resources,  root-secondary);
/*
 * _CRS with no apertures is normal, so only fall back to
 * defaults or native bridge info if we're ignoring _CRS.
 */
-   if (pci_use_crs)
+   if (pci_use_crs) {
+   pci_add_resource(resources,  root-secondary);
add_resources(info, resources);
-   else {
+   } else {
free_pci_root_info_res(info);
x86_pci_root_bus_resources(busnum, resources);
}
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index f3a2cfc..b735d0e 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -31,8 +31,6 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
 {
struct pci_root_info *info = x86_find_pci_root_info(bus);
struct pci_root_res *root_res;
-   struct pci_host_bridge_window *window;
-   bool found = false;
 
if (!info)
goto default_resources;
@@ -40,15 +38,7 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
printk(KERN_DEBUG PCI: root bus %02x: hardware-probed resources\n,
   bus);
 
-   /* already added by acpi ? */
-   list_for_each_entry(window, resources, list)
-   if (window-res-flags  IORESOURCE_BUS) {
-   found = true;
-   break;
-   }
-
-   if (!found)
-   pci_add_resource(resources, info-busn);
+   pci_add_resource(resources, info-busn);
 
list_for_each_entry(root_res, info-resources, list) {
struct resource *res;
-- 
2.1.0

--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Fri, Sep 12, 2014 at 10:05 PM, Dirk Gouders  wrote:
> Dirk Gouders  writes:
>
>> Dirk Gouders  writes:
>>
>>> Bjorn Helgaas  writes:
>>>
 On Thu, Sep 11, 2014 at 3:24 PM, Dirk Gouders  wrote:
> Bjorn Helgaas  writes:
>
>> On Thu, Sep 11, 2014 at 2:33 PM, Dirk Gouders  wrote:
>>> What I was currently trying was to construct a test-environment so that
>>> I do not need to do tests and diagnosis on a busy machine.
>>>
>>> I noticed that this problem seems to start with the narrow Root
>>> Bridge window (00-07) but every other machine that I had a look at,
>>> starts with (00-ff), so those will not trigger my problem.
>>>
>>> I thought I could perhaps try to shrink the window in
>>> acpi_pci_root_add() to trigger the problem and that kind of works: it
>>> triggers it but not exactly the same way, because it basically ends at
>>> this code in pci_scan_bridge():
>>>
>>> if (max >= bus->busn_res.end) {
>>> dev_warn(>dev, "can't allocate child bus %02x from 
>>> %pR (pass %d)\n",
>>>  max, >busn_res, pass);
>>> goto out;
>>> }
>>>
>>> If this could work but I am just missing a small detail, I would be
>>> glad to hear about it and do the first tests this way.  If it is
>>> complete nonsense, I will just use the machine that triggers the problem
>>> for the tests.
>>
>> I was about to suggest the same thing.  If the problem is related to
>> the bus number change, we should be able to force that to happen on a
>> different machine.  Your approach sounds good, so I'm guessing we just
>> need a tweak.
>>
>> I would first double-check that the PCI adapters are identical,
>> including the firmware on the card.  Can you also include your patch
>> and the resulting dmesg (with debug enabled as before)?
>
> Currently I am at home doing just tests for understanding and that I can
> hopefully use when I am back in the office.
>
> I already noticed the the backup FC Adapter on the test machine is not
> exactly the same: it is Rev. 1 whereas the one on the failing machine is
> Rev. 2.
>
> So, here at home my tests let a NIC disappear.  Different from the
> original problem but I was just trying to reconstruct the szenario of a
> misconfigured bridge causing a reconfiguration.
>
> What I was trying is:
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index e6ae603..fd146b3 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -556,6 +556,7 @@ static int acpi_pci_root_add(struct acpi_device 
> *device,
> strcpy(acpi_device_name(device), ACPI_PCI_ROOT_DEVICE_NAME);
> strcpy(acpi_device_class(device), ACPI_PCI_ROOT_CLASS);
> device->driver_data = root;
> +   root->secondary.end = 0x02;
>
> pr_info(PREFIX "%s [%s] (domain %04x %pR)\n",
>acpi_device_name(device), acpi_device_bid(device),
>
> The device that disappears is a NIC:
>
> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core 
> processor DRAM Controller (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd 
> Gen Core processor Graphics Controller (rev 09)
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
> Family USB xHCI Host Controller (rev 04)
> 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series 
> Chipset Family MEI Controller #1 (rev 04)
> 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
> Family USB Enhanced Host Controller #2 (rev 04)
> 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset 
> Family High Definition Audio Controller (rev 04)
> 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
> PCI Express Root Port 1 (rev c4)
> 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
> PCI Express Root Port 5 (rev c4)
> 00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
> PCI Express Root Port 6 (rev c4)
> 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
> Family USB Enhanced Host Controller #1 (rev 04)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
> 00:1f.0 ISA bridge: Intel Corporation B75 Express Chipset LPC Controller 
> (rev 04)
> 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset 
> Family 6-port SATA Controller [AHCI mode] (rev 04)
> 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family 
> SMBus Controller (rev 04)
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Fri, Sep 12, 2014 at 10:05 PM, Dirk Gouders d...@gouders.net wrote:
 Dirk Gouders d...@gouders.net writes:

 Dirk Gouders d...@gouders.net writes:

 Bjorn Helgaas bhelg...@google.com writes:

 On Thu, Sep 11, 2014 at 3:24 PM, Dirk Gouders d...@gouders.net wrote:
 Bjorn Helgaas bhelg...@google.com writes:

 On Thu, Sep 11, 2014 at 2:33 PM, Dirk Gouders d...@gouders.net wrote:
 What I was currently trying was to construct a test-environment so that
 I do not need to do tests and diagnosis on a busy machine.

 I noticed that this problem seems to start with the narrow Root
 Bridge window (00-07) but every other machine that I had a look at,
 starts with (00-ff), so those will not trigger my problem.

 I thought I could perhaps try to shrink the window in
 acpi_pci_root_add() to trigger the problem and that kind of works: it
 triggers it but not exactly the same way, because it basically ends at
 this code in pci_scan_bridge():

 if (max = bus-busn_res.end) {
 dev_warn(dev-dev, can't allocate child bus %02x from 
 %pR (pass %d)\n,
  max, bus-busn_res, pass);
 goto out;
 }

 If this could work but I am just missing a small detail, I would be
 glad to hear about it and do the first tests this way.  If it is
 complete nonsense, I will just use the machine that triggers the problem
 for the tests.

 I was about to suggest the same thing.  If the problem is related to
 the bus number change, we should be able to force that to happen on a
 different machine.  Your approach sounds good, so I'm guessing we just
 need a tweak.

 I would first double-check that the PCI adapters are identical,
 including the firmware on the card.  Can you also include your patch
 and the resulting dmesg (with debug enabled as before)?

 Currently I am at home doing just tests for understanding and that I can
 hopefully use when I am back in the office.

 I already noticed the the backup FC Adapter on the test machine is not
 exactly the same: it is Rev. 1 whereas the one on the failing machine is
 Rev. 2.

 So, here at home my tests let a NIC disappear.  Different from the
 original problem but I was just trying to reconstruct the szenario of a
 misconfigured bridge causing a reconfiguration.

 What I was trying is:

 diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
 index e6ae603..fd146b3 100644
 --- a/drivers/acpi/pci_root.c
 +++ b/drivers/acpi/pci_root.c
 @@ -556,6 +556,7 @@ static int acpi_pci_root_add(struct acpi_device 
 *device,
 strcpy(acpi_device_name(device), ACPI_PCI_ROOT_DEVICE_NAME);
 strcpy(acpi_device_class(device), ACPI_PCI_ROOT_CLASS);
 device-driver_data = root;
 +   root-secondary.end = 0x02;

 pr_info(PREFIX %s [%s] (domain %04x %pR)\n,
acpi_device_name(device), acpi_device_bid(device),

 The device that disappears is a NIC:

 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core 
 processor DRAM Controller (rev 09)
 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd 
 Gen Core processor Graphics Controller (rev 09)
 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
 Family USB xHCI Host Controller (rev 04)
 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series 
 Chipset Family MEI Controller #1 (rev 04)
 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
 Family USB Enhanced Host Controller #2 (rev 04)
 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset 
 Family High Definition Audio Controller (rev 04)
 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
 PCI Express Root Port 1 (rev c4)
 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
 PCI Express Root Port 5 (rev c4)
 00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
 PCI Express Root Port 6 (rev c4)
 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
 Family USB Enhanced Host Controller #1 (rev 04)
 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
 00:1f.0 ISA bridge: Intel Corporation B75 Express Chipset LPC Controller 
 (rev 04)
 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset 
 Family 6-port SATA Controller [AHCI mode] (rev 04)
 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family 
 SMBus Controller (rev 04)
 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
 RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

 This is the one that is missing with the above change:
 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
 RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

 This situation is a little different, so I don't think you're
 reproducing the situation we want to test.  On this box, you have:

 pci_bus :00: root bus resource [bus 00-02]
 pci :00:1c.0: PCI bridge to [bus 01]
 pci 

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Wed, Sep 3, 2014 at 2:47 PM, Dirk Gouders  wrote:
> Andreas Noever  writes:
>
>> On Wed, Sep 3, 2014 at 12:57 PM, Dirk Gouders  wrote:
>>> On a Tyan VX50 (B4985) I ran into problems when updating the kernel: the
>>> PCI FC Adapter is no longer recognized.
>>
>> Can you provide the output of lspci -vvv and the output of dmesg from
>> a working boot? Which card is the one that is not recognized?
>
> Sure, the card that disappeared is:
>
> 0a:00.0 Fibre Channel: LSI Logic / Symbios Logic FC949ES Fibre Channel 
> Adapter (rev 02)

As far as I can tell the following is happening:
The root bus resource window (advertised by the bios?) is to small:
pci_bus :00: root bus resource [bus 00-07]
Previously we didn't really care. There is a resource conflict but we
ignored it:
pci_bus :0a: busn_res: can not insert [bus 0a] under [bus 00-07]
(conflicts with (null) [bus 00-07])
With the patch we mark the bridge as broken and reassign the bus to 06:
pci :00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring
pci :00:0e.0: PCI bridge to [bus 06-07]
pci :00:0e.0:   bridge window [io  0x3000-0x3fff]
pci :00:0e.0:   bridge window [mem 0xd420-0xd42f]
pci_bus :06: busn_res: [bus 06-07] end is updated to 06

We still scan for children but nothing shows up ("PCI bridge to" is
from pci_scan_child_bus -> pcibios_fixup_bus -> pci_read_bridge_base,
after pci_scan_slot). I have no idea why the device does not respond.
--
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/

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Wed, Sep 3, 2014 at 12:57 PM, Dirk Gouders  wrote:
> On a Tyan VX50 (B4985) I ran into problems when updating the kernel: the
> PCI FC Adapter is no longer recognized.

Can you provide the output of lspci -vvv and the output of dmesg from
a working boot? Which card is the one that is not recognized?

> Actually, this machine caused more problems, because I was not able to
> get it run with fedora, debian or ubuntu but I am somewhat sure that has
> to do with grub2 and now I am (again) running Gentoo on it, booting with
> legacy grub.  So, I hope that has nothing to do with the PCI FC Adapter
> not being recognized.
>
> I bisected this PCI problem to commit 1820ffdccb9b4398 (PCI: Make sure
> bus number resources stay within their parents bounds).
>
> With this commit the "bridge configuration invalid..." message is
> triggered; I'll attach the dmesg output.
>
>
> Please note: unfortunately, I am in a hurry to get the VMs on that
> server back running this afternoon and then cannot easily test fixes
> that need reboots.  It would be nice if someone could reproduce this
> problem on a test machine, otherwise I have to test at night or on
> weekends...
>
> Dirk
>
> 
> [0.00] Linux version 3.14.0-rc1-5-g1820ffd (root@quad) (gcc 
> version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #18 SMP Wed Sep 3 12:33:21 
> CEST 2014
> [0.00] Command line: root=/dev/sda2
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x000997ff] usable
> [0.00] BIOS-e820: [mem 0x00099800-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000ca000-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x7ffd] usable
> [0.00] BIOS-e820: [mem 0x7ffe-0x7ffe9fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0x7ffea000-0x7fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x8000-0xcfbf] usable
> [0.00] BIOS-e820: [mem 0xcfc0-0xcfff] reserved
> [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xfff8-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x000a2fff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.4 present.
> [0.00] DMI: NVIDIA  CK8 /Tyan Transport VX50-B4985, BIOS TYAN 
> Transport VX50 B4985 BIOS V3.01.B30 11/27/2009
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] No AGP bridge found
> [0.00] e820: last_pfn = 0xa3 max_arch_pfn = 0x4
> [0.00] MTRR default type: uncachable
> [0.00] MTRR fixed ranges enabled:
> [0.00]   0-9 write-back
> [0.00]   A-B uncachable
> [0.00]   C-D3FFF write-protect
> [0.00]   D4000-E3FFF uncachable
> [0.00]   E4000-F write-protect
> [0.00] MTRR variable ranges enabled:
> [0.00]   0 base  mask 8000 write-back
> [0.00]   1 base 8000 mask C000 write-back
> [0.00]   2 base C000 mask F000 write-back
> [0.00]   3 disabled
> [0.00]   4 disabled
> [0.00]   5 disabled
> [0.00]   6 disabled
> [0.00]   7 disabled
> [0.00] TOM2: 000a3000 aka 41728M
> [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
> 0x7010600070106
> [0.00] e820: update [mem 0xd000-0x] usable ==> reserved
> [0.00] e820: last_pfn = 0xcfc00 max_arch_pfn = 0x4
> [0.00] found SMP MP-table at [mem 0x000f7770-0x000f777f] mapped at 
> [880f7770]
> [0.00] Base memory trampoline at [88093000] 93000 size 24576
> [0.00] Using GB pages for direct mapping
> [0.00] init_memory_mapping: [mem 0x-0x000f]
> [0.00]  [mem 0x-0x000f] page 4k
> [0.00] BRK [0x018f5000, 0x018f5fff] PGTABLE
> [0.00] BRK [0x018f6000, 0x018f6fff] PGTABLE
> [0.00] BRK [0x018f7000, 0x018f7fff] PGTABLE
> [0.00] init_memory_mapping: [mem 0xa2fe0-0xa2fff]
> [0.00]  [mem 0xa2fe0-0xa2fff] page 2M
> [0.00] BRK [0x018f8000, 0x018f8fff] PGTABLE
> [0.00] init_memory_mapping: [mem 0xa2c00-0xa2fdf]
> [0.00]  [mem 0xa2c00-0xa2fdf] page 2M
> [0.00] init_memory_mapping: [mem 0xa-0xa2bff]
> [0.00]  [mem 0xa-0xa2bff] page 2M
> [0.00] 

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Wed, Sep 3, 2014 at 12:57 PM, Dirk Gouders d...@gouders.net wrote:
 On a Tyan VX50 (B4985) I ran into problems when updating the kernel: the
 PCI FC Adapter is no longer recognized.

Can you provide the output of lspci -vvv and the output of dmesg from
a working boot? Which card is the one that is not recognized?

 Actually, this machine caused more problems, because I was not able to
 get it run with fedora, debian or ubuntu but I am somewhat sure that has
 to do with grub2 and now I am (again) running Gentoo on it, booting with
 legacy grub.  So, I hope that has nothing to do with the PCI FC Adapter
 not being recognized.

 I bisected this PCI problem to commit 1820ffdccb9b4398 (PCI: Make sure
 bus number resources stay within their parents bounds).

 With this commit the bridge configuration invalid... message is
 triggered; I'll attach the dmesg output.


 Please note: unfortunately, I am in a hurry to get the VMs on that
 server back running this afternoon and then cannot easily test fixes
 that need reboots.  It would be nice if someone could reproduce this
 problem on a test machine, otherwise I have to test at night or on
 weekends...

 Dirk

 
 [0.00] Linux version 3.14.0-rc1-5-g1820ffd (root@quad) (gcc 
 version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #18 SMP Wed Sep 3 12:33:21 
 CEST 2014
 [0.00] Command line: root=/dev/sda2
 [0.00] e820: BIOS-provided physical RAM map:
 [0.00] BIOS-e820: [mem 0x-0x000997ff] usable
 [0.00] BIOS-e820: [mem 0x00099800-0x0009] reserved
 [0.00] BIOS-e820: [mem 0x000ca000-0x000f] reserved
 [0.00] BIOS-e820: [mem 0x0010-0x7ffd] usable
 [0.00] BIOS-e820: [mem 0x7ffe-0x7ffe9fff] ACPI 
 data
 [0.00] BIOS-e820: [mem 0x7ffea000-0x7fff] ACPI NVS
 [0.00] BIOS-e820: [mem 0x8000-0xcfbf] usable
 [0.00] BIOS-e820: [mem 0xcfc0-0xcfff] reserved
 [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
 [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
 [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
 [0.00] BIOS-e820: [mem 0xfff8-0x] reserved
 [0.00] BIOS-e820: [mem 0x0001-0x000a2fff] usable
 [0.00] NX (Execute Disable) protection: active
 [0.00] SMBIOS 2.4 present.
 [0.00] DMI: NVIDIA  CK8 /Tyan Transport VX50-B4985, BIOS TYAN 
 Transport VX50 B4985 BIOS V3.01.B30 11/27/2009
 [0.00] e820: update [mem 0x-0x0fff] usable == reserved
 [0.00] e820: remove [mem 0x000a-0x000f] usable
 [0.00] No AGP bridge found
 [0.00] e820: last_pfn = 0xa3 max_arch_pfn = 0x4
 [0.00] MTRR default type: uncachable
 [0.00] MTRR fixed ranges enabled:
 [0.00]   0-9 write-back
 [0.00]   A-B uncachable
 [0.00]   C-D3FFF write-protect
 [0.00]   D4000-E3FFF uncachable
 [0.00]   E4000-F write-protect
 [0.00] MTRR variable ranges enabled:
 [0.00]   0 base  mask 8000 write-back
 [0.00]   1 base 8000 mask C000 write-back
 [0.00]   2 base C000 mask F000 write-back
 [0.00]   3 disabled
 [0.00]   4 disabled
 [0.00]   5 disabled
 [0.00]   6 disabled
 [0.00]   7 disabled
 [0.00] TOM2: 000a3000 aka 41728M
 [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
 0x7010600070106
 [0.00] e820: update [mem 0xd000-0x] usable == reserved
 [0.00] e820: last_pfn = 0xcfc00 max_arch_pfn = 0x4
 [0.00] found SMP MP-table at [mem 0x000f7770-0x000f777f] mapped at 
 [880f7770]
 [0.00] Base memory trampoline at [88093000] 93000 size 24576
 [0.00] Using GB pages for direct mapping
 [0.00] init_memory_mapping: [mem 0x-0x000f]
 [0.00]  [mem 0x-0x000f] page 4k
 [0.00] BRK [0x018f5000, 0x018f5fff] PGTABLE
 [0.00] BRK [0x018f6000, 0x018f6fff] PGTABLE
 [0.00] BRK [0x018f7000, 0x018f7fff] PGTABLE
 [0.00] init_memory_mapping: [mem 0xa2fe0-0xa2fff]
 [0.00]  [mem 0xa2fe0-0xa2fff] page 2M
 [0.00] BRK [0x018f8000, 0x018f8fff] PGTABLE
 [0.00] init_memory_mapping: [mem 0xa2c00-0xa2fdf]
 [0.00]  [mem 0xa2c00-0xa2fdf] page 2M
 [0.00] init_memory_mapping: [mem 0xa-0xa2bff]
 [0.00]  [mem 0xa-0xa2bff] page 2M
 [0.00] init_memory_mapping: [mem 0x0010-0x7ffd]
 [0.00]  [mem 

Re: [BUG] Bisected Problem with LSI PCI FC Adapter

[Andreas Noever]

On Wed, Sep 3, 2014 at 2:47 PM, Dirk Gouders d...@gouders.net wrote:
 Andreas Noever andreas.noe...@gmail.com writes:

 On Wed, Sep 3, 2014 at 12:57 PM, Dirk Gouders d...@gouders.net wrote:
 On a Tyan VX50 (B4985) I ran into problems when updating the kernel: the
 PCI FC Adapter is no longer recognized.

 Can you provide the output of lspci -vvv and the output of dmesg from
 a working boot? Which card is the one that is not recognized?

 Sure, the card that disappeared is:

 0a:00.0 Fibre Channel: LSI Logic / Symbios Logic FC949ES Fibre Channel 
 Adapter (rev 02)

As far as I can tell the following is happening:
The root bus resource window (advertised by the bios?) is to small:
pci_bus :00: root bus resource [bus 00-07]
Previously we didn't really care. There is a resource conflict but we
ignored it:
pci_bus :0a: busn_res: can not insert [bus 0a] under [bus 00-07]
(conflicts with (null) [bus 00-07])
With the patch we mark the bridge as broken and reassign the bus to 06:
pci :00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring
pci :00:0e.0: PCI bridge to [bus 06-07]
pci :00:0e.0:   bridge window [io  0x3000-0x3fff]
pci :00:0e.0:   bridge window [mem 0xd420-0xd42f]
pci_bus :06: busn_res: [bus 06-07] end is updated to 06

We still scan for children but nothing shows up (PCI bridge to is
from pci_scan_child_bus - pcibios_fixup_bus - pci_read_bridge_base,
after pci_scan_slot). I have no idea why the device does not respond.
--
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/