All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sanjeev Sharma <sanjeev_sharma@mentor.com>
Cc: Richard.Zhu@freescale.com, l.stach@pengutronix.de,
	bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, David Mueller <dave.mueller@gmx.ch>
Subject: Re: [PATCH v2] PCI: imx6:don't sleep in atomic context
Date: Tue, 5 Jan 2016 20:13:09 -0600	[thread overview]
Message-ID: <20160106021309.GC23814@localhost> (raw)
In-Reply-To: <1449042196-25710-1-git-send-email-sanjeev_sharma@mentor.com>

On Wed, Dec 02, 2015 at 01:13:16PM +0530, Sanjeev Sharma wrote:
> From: David Mueller <dave.mueller@gmx.ch>
> 
> If additional PCIe switch get connected between the
> host and the NIC,the kernel crashes with "BUG:
> scheduling while atomic". To handle this we need to
> call mdelay() instead of usleep_range().
> 
> This is currently called from atomic context through
> pci_config_{read,write).
> 
> For more detail please refer bugzilla.kernel.org, Bug
> 100031

Bug reports have URLs; please use them.  I'll save you the trouble:

  Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031

In that bug report, I said: "My first question on the list will be:
Besides imx6, there are five other DesignWare-based drivers, and
imx6_pcie_link_up() looks nothing like the other
pcie_host_ops.link_up() methods.  We need to explain why imx6 is
special, and whether all the .link_up() methods can be made similar."

The only response was that i.MX6 is special because of a hardware bug,
so we need to start at Gen1, wait, try to change to Gen2, etc.  That
all sounds like work that should be done in
imx6_pcie_establish_link().

This patch doesn't seem to make anything *worse*, so I might take it
anyway, but I'm a little disappointed that we didn't make any progress
toward making imx6 more like the other drivers.  I know this sounds
pedantic, but it's a lot easier to let things slowly diverge than it
is to keep them uniform, and bugs hide in differences like this.

> Signed-off-by: David Mueller <dave.mueller@gmx.ch>
> Signed-off-by: Sanjeev Sharma <sanjeev_sharma@mentor.com>
> 
> Changes in v2:
> 	-order of signoff has been change
> 	-Author of patch has been change
> 	-A mdelay(1000) is different timescale than
> a usleep(1000).change it to correct scale i.e mdelay(1)
> 	-updated comment
> ---
>  drivers/pci/host/pci-imx6.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 233a196..c03527f 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
>  		 * Wait a little bit, then re-check if the link finished
>  		 * the training.
>  		 */
> -		usleep_range(1000, 2000);
> +		mdelay(1);
>  	}
>  	/*
>  	 * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> -- 
> 1.7.11.7
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] PCI: imx6:don't sleep in atomic context
Date: Tue, 5 Jan 2016 20:13:09 -0600	[thread overview]
Message-ID: <20160106021309.GC23814@localhost> (raw)
In-Reply-To: <1449042196-25710-1-git-send-email-sanjeev_sharma@mentor.com>

On Wed, Dec 02, 2015 at 01:13:16PM +0530, Sanjeev Sharma wrote:
> From: David Mueller <dave.mueller@gmx.ch>
> 
> If additional PCIe switch get connected between the
> host and the NIC,the kernel crashes with "BUG:
> scheduling while atomic". To handle this we need to
> call mdelay() instead of usleep_range().
> 
> This is currently called from atomic context through
> pci_config_{read,write).
> 
> For more detail please refer bugzilla.kernel.org, Bug
> 100031

Bug reports have URLs; please use them.  I'll save you the trouble:

  Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031

In that bug report, I said: "My first question on the list will be:
Besides imx6, there are five other DesignWare-based drivers, and
imx6_pcie_link_up() looks nothing like the other
pcie_host_ops.link_up() methods.  We need to explain why imx6 is
special, and whether all the .link_up() methods can be made similar."

The only response was that i.MX6 is special because of a hardware bug,
so we need to start at Gen1, wait, try to change to Gen2, etc.  That
all sounds like work that should be done in
imx6_pcie_establish_link().

This patch doesn't seem to make anything *worse*, so I might take it
anyway, but I'm a little disappointed that we didn't make any progress
toward making imx6 more like the other drivers.  I know this sounds
pedantic, but it's a lot easier to let things slowly diverge than it
is to keep them uniform, and bugs hide in differences like this.

> Signed-off-by: David Mueller <dave.mueller@gmx.ch>
> Signed-off-by: Sanjeev Sharma <sanjeev_sharma@mentor.com>
> 
> Changes in v2:
> 	-order of signoff has been change
> 	-Author of patch has been change
> 	-A mdelay(1000) is different timescale than
> a usleep(1000).change it to correct scale i.e mdelay(1)
> 	-updated comment
> ---
>  drivers/pci/host/pci-imx6.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 233a196..c03527f 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
>  		 * Wait a little bit, then re-check if the link finished
>  		 * the training.
>  		 */
> -		usleep_range(1000, 2000);
> +		mdelay(1);
>  	}
>  	/*
>  	 * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> -- 
> 1.7.11.7
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-01-06  2:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-09 10:48 [PATCH] PCI: imx6:don't sleep in atomic context Sanjeev Sharma
2015-11-10  8:41 ` Lucas Stach
2015-11-10  8:41   ` Lucas Stach
2015-11-10  9:28   ` Arnd Bergmann
2015-11-10  9:28     ` Arnd Bergmann
2015-11-10  9:35     ` Lucas Stach
2015-11-10  9:35       ` Lucas Stach
2015-11-10  9:45       ` Arnd Bergmann
2015-11-10  9:45         ` Arnd Bergmann
2015-11-16  9:36         ` Sharma, Sanjeev
2015-11-16  9:36           ` Sharma, Sanjeev
2015-11-24 13:57           ` Lucas Stach
2015-11-24 13:57             ` Lucas Stach
2015-12-02  7:43 ` [PATCH v2] " Sanjeev Sharma
2016-01-06  2:13   ` Bjorn Helgaas [this message]
2016-01-06  2:13     ` Bjorn Helgaas
2016-01-06 22:04 ` [PATCH] " Bjorn Helgaas
2016-01-06 22:04   ` Bjorn Helgaas
2016-02-18  7:17   ` Sharma, Sanjeev
2016-02-18  7:17     ` Sharma, Sanjeev
2016-02-18 15:08     ` Bjorn Helgaas
2016-02-18 15:08       ` Bjorn Helgaas
2016-02-19  9:18       ` Sharma, Sanjeev
2016-02-19  9:18         ` Sharma, Sanjeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160106021309.GC23814@localhost \
    --to=helgaas@kernel.org \
    --cc=Richard.Zhu@freescale.com \
    --cc=bhelgaas@google.com \
    --cc=dave.mueller@gmx.ch \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sanjeev_sharma@mentor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.