[PATCH] net: stmmac: Use mutex instead of spinlock

From: Thierry Reding <tred...@nvidia.com> Some drivers, such as DWC EQOS on Tegra, need to perform operations that can sleep under this lock (clk_set_rate() in tegra_eqos_fix_speed()) for proper operation. Since there is no need for this lock to be a spinlock, convert it to a mutex i

[PATCH] wireless: Always rewrite generated files from scratch

From: Thierry Reding <tred...@nvidia.com> Currently the certs C code generation appends to the generated files, which is most likely a leftover from commit 715a12334764 ("wireless: don't write C files on failures"). This causes duplicate code in the generated files if the c

Re: [PATCH net] PCI: fix the return value for the pci_find_pcie_root_port()

On Thu, Aug 17, 2017 at 08:40:16PM +0800, Ding Tianhong wrote: > > > On 2017/8/17 18:51, Thierry Reding wrote: > > On Thu, Aug 17, 2017 at 10:25:30AM +0800, Ding Tianhong wrote: > >> The pci_find_pcie_root_port() would return NULL if the given > >> dev is a

[PATCH] PCI: Allow PCI express root ports to find themselves

From: Thierry Reding <tred...@nvidia.com> If the pci_find_pcie_root_port() function is called on a root port itself, return the root port rather than NULL. This effectively reverts commit 0e405232871d6 ("PCI: fix oops when try to find Root Port for a PCI device") which adde

Re: [PATCH net] PCI: fix the return value for the pci_find_pcie_root_port()

en dev under this circumstances. > > Fixes: 0e405232871d6 ("PCI: fix oops when try to find Root Port for a PCI > device") > Suggested-by: Thierry Reding <thierry.red...@gmail.com> > Suggested-by: Bjorn Helgaas <helg...@kernel.org> > Signed-off-by: Thierry Reding <t

Re: [PATCH net RESEND] PCI: fix oops when try to find Root Port for a PCI device

On Tue, Aug 15, 2017 at 12:03:31PM -0500, Bjorn Helgaas wrote: > On Tue, Aug 15, 2017 at 11:24:48PM +0800, Ding Tianhong wrote: > > Eric report a oops when booting the system after applying > > the commit a99b646afa8a ("PCI: Disable PCIe Relaxed..."): > > ... > > > It looks like the

Re: [PATCH 01/44] firmware/ivc: use dma_mapping_error

On Thu, Jun 08, 2017 at 03:25:26PM +0200, Christoph Hellwig wrote: > DMA_ERROR_CODE is not supposed to be used by drivers. > > Signed-off-by: Christoph Hellwig <h...@lst.de> > --- > drivers/firmware/tegra/ivc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH 2/4 v3 net-next] net: stmmac: adding multiple buffers for rx

On Thu, Apr 06, 2017 at 09:49:09AM +0100, Joao Pinto wrote: [...] > err_init_rx_buffers: > - while (--i >= 0) > - stmmac_free_rx_buffer(priv, i); > + while (queue >= 0) { I /think/ this could simply be: while (queue--) { ... } That evaluates

Re: [PATCH 4/4] net: stmmac: adding multiple napi mechanism

uct stmmac_rx_queue *rx_q = >rx_queue[queue]; > + > + netif_napi_add(ndev, _q->napi, stmmac_poll, > + (8 * priv->plat->rx_queues_to_use)); > + } Why is this moving to ->probe() now? This works on Tegra186, so: Reviewed-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCH 2/4] net: stmmac: adding multiple buffers for rx

On Tue, Apr 04, 2017 at 06:54:25PM +0100, Joao Pinto wrote: [...] > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c [...] > @@ -3402,6 +3474,9 @@ static irqreturn_t stmmac_interrupt(int irq, void > *dev_id) > >

Re: [PATCH 3/4] net: stmmac: adding multiple buffers for TX

letions(-) Looks good to me: Reviewed-by: Thierry Reding <tred...@nvidia.com> And works fine on Tegra186, so: Tested-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCH 2/4] net: stmmac: adding multiple buffers for rx

One more nit: subject should say "... for RX" for consistency with patch 3/4. Thierry signature.asc Description: PGP signature

Re: [PATCH 2/4] net: stmmac: adding multiple buffers for rx

to ~0 and probably crash stmmac_free_rx_buffers(). Other than that, this looks fine, so with the above fixed: Reviewed-by: Thierry Reding <tred...@nvidia.com> Also works on Tegra186, so: Tested-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCH 1/4] net: stmmac: break some functions into RX and TX scopes

provide any useful information, so might as well drop it. > + if (ret) > + return ret; > + > + /* TX INITIALIZATION */ > + ret = init_dma_tx_desc_rings(dev); Same here. [...] > -static void free_dma_desc_resources(struct stmmac_priv *priv) > +/** > + * alloc_dma_desc_resources - alloc TX/RX resources. > + * @priv: private structure > + * Description: according to which descriptor can be used (extend or basic) > + * this function allocates the resources for TX and RX paths. In case of > + * reception, for example, it pre-allocated the RX socket buffer in order to > + * allow zero-copy mechanism. > + */ > +static int alloc_dma_desc_resources(struct stmmac_priv *priv) > +{ > + /* RX Allocation */ > + int ret = alloc_dma_rx_desc_resources(priv); And here. > + > + if (ret) > + return ret; > + > + /* TX Allocation */ > + ret = alloc_dma_tx_desc_resources(priv); And here. None of the above comments are critical and this could be cleaned up in follow-up patches, so: Reviewed-by: Thierry Reding <tred...@nvidia.com> It also doesn't break on Tegra186, so Tested-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote: > On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote: > > From: Arnd Bergmann > > Date: Tue, 28 Mar 2017 11:48:21 +0200 > > > > > A driver must not access the two fields directly but should instead use > > >

Re: [PATCH 2/3] net: stmmac: Always use the number of configured TX queues

On Tue, Mar 28, 2017 at 04:10:43PM +0200, Niklas Cassel wrote: > > > On 03/28/2017 03:57 PM, Thierry Reding wrote: > > From: Thierry Reding <tred...@nvidia.com> > > > > Even if hardware supports multiple queues, software can choose to only > > use a

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

On Tue, Mar 28, 2017 at 03:34:58PM +0200, Niklas Cassel wrote: > > > On 03/27/2017 07:44 PM, Joao Pinto wrote: > > Às 6:28 PM de 3/27/2017, David Miller escreveu: > >> From: Corentin Labbe > >> Date: Mon, 27 Mar 2017 19:00:58 +0200 > >> > >>> On Mon, Mar 27, 2017 at

[PATCH 2/3] net: stmmac: Always use the number of configured TX queues

From: Thierry Reding <tred...@nvidia.com> Even if hardware supports multiple queues, software can choose to only use a subset of them. Make sure we never try to access uninitialized queues. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethernet/stmicro/stmmac/s

[PATCH 3/3] net: stmmac: Prefer kcalloc() over kmalloc_array()

From: Thierry Reding <tred...@nvidia.com> Some of the data in the new queue structures seems to not be properly initialized, causing undefined behaviour (networking will work about 2 out of 10 tries). kcalloc() will zero the allocated memory and results in 10 out of 10 successful boots.

[PATCH 1/3] net: stmmac: Remove unneeded checks for NULL pointer

From: Thierry Reding <tred...@nvidia.com> Taking the address of an element within a non-NULL array will never be zero. This condition isn't checked anywhere else, so drop it in these two instances as well. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethe

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

On Thu, Mar 23, 2017 at 05:27:08PM +, Joao Pinto wrote: > Hi Thierry, > > Às 5:17 PM de 3/23/2017, Thierry Reding escreveu: > > On Fri, Mar 17, 2017 at 04:11:05PM +, Joao Pinto wrote: > >> This patch creates 2 new structures (stmmac_tx_queue and stmmac_rx_queu

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

On Fri, Mar 17, 2017 at 04:11:05PM +, Joao Pinto wrote: > This patch creates 2 new structures (stmmac_tx_queue and stmmac_rx_queue) > in include/linux/stmmac.h, enabling that each RX and TX queue has its > own buffers and data. > > Signed-off-by: Joao Pinto > --- >

Re: [PATCH v2 net-next] net: fix dma operation mode config for older versions

et/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) With Florian's comments addressed, this is: Reviewed-by: Thierry Reding <thierry.red...@gmail.com> signature.asc Description: PGP signature

Re: [PATCH v2 net-next] net: fix dma operation mode config for older versions

.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) With Florian's comments addressed, this is: Reviewed-by: Thierry Reding <thierry.red...@gmail.com> signature.asc Description: PGP signature

Re: [PATCH 3/3] net: stmmac: Use AVB mode by default

On Tue, Mar 21, 2017 at 03:23:00PM +, Joao Pinto wrote: > Às 3:12 PM de 3/21/2017, Thierry Reding escreveu: > > From: Thierry Reding <tred...@nvidia.com> > > > > Prior to the recent multi-queue changes the driver would configure the > > queues to use th

Re: [PATCH 1/3] net: stmmac: Always enable MAC RX queues

On Tue, Mar 21, 2017 at 03:18:20PM +, Joao Pinto wrote: > Às 3:12 PM de 3/21/2017, Thierry Reding escreveu: > > From: Thierry Reding <tred...@nvidia.com> > > > > The MAC RX queues always need to be enabled in order to receive network > > packets. Remove t

[PATCH 2/3] net: stmmac: Restore DT backwards-compatibility

From: Thierry Reding <tred...@nvidia.com> Recent changes to support multiple queues in the device tree bindings resulted in the number of RX and TX queues to be initialized to zero for device trees not adhering to the new bindings. Restore backwards-compatibility with those device

[PATCH 1/3] net: stmmac: Always enable MAC RX queues

From: Thierry Reding <tred...@nvidia.com> The MAC RX queues always need to be enabled in order to receive network packets. Remove the condition that this only needs to be done for multi- queue configurations. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethe

[PATCH 3/3] net: stmmac: Use AVB mode by default

From: Thierry Reding <tred...@nvidia.com> Prior to the recent multi-queue changes the driver would configure the queues to use the AVB mode, but the mode then got switched to DCB. The hardware still works fine in DCB mode, but my testing capabilities are limited, so it's safer to

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

On Tue, Mar 21, 2017 at 02:25:15PM +, Joao Pinto wrote: > Às 2:23 PM de 3/21/2017, Corentin Labbe escreveu: > > On Tue, Mar 21, 2017 at 02:10:47PM +, Joao Pinto wrote: > >> ++Adding Corentin > >> > >> Às 2:08 PM de 3/21/2017, Thierry Reding escreveu:

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

On Tue, Mar 21, 2017 at 02:18:59PM +, Joao Pinto wrote: > Às 2:08 PM de 3/21/2017, Thierry Reding escreveu: > > On Tue, Mar 21, 2017 at 01:58:36PM +, Joao Pinto wrote: > >> Às 12:24 PM de 3/21/2017, Thierry Reding escreveu: > >>> On Tue, Mar 21, 2017 at 12:0

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

On Tue, Mar 21, 2017 at 01:58:36PM +, Joao Pinto wrote: > Às 12:24 PM de 3/21/2017, Thierry Reding escreveu: > > On Tue, Mar 21, 2017 at 12:02:03PM +, Joao Pinto wrote: > >> Às 11:58 AM de 3/21/2017, Thierry Reding escreveu: > >>> On Fri, Mar 10, 2017 at 06:2

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

On Tue, Mar 21, 2017 at 12:02:03PM +, Joao Pinto wrote: > Às 11:58 AM de 3/21/2017, Thierry Reding escreveu: > > On Fri, Mar 10, 2017 at 06:24:52PM +, Joao Pinto wrote: > >> This patch adds the RX and TX scheduling algorithms programming. > >> It int

Re: [v5,net-next,1/9] net: stmmac: multiple queues dt configuration

On Tue, Mar 21, 2017 at 11:39:24AM +, Joao Pinto wrote: > > Hi Thierry, > > Às 11:32 AM de 3/21/2017, Thierry Reding escreveu: > > On Fri, Mar 10, 2017 at 06:24:51PM +, Joao Pinto wrote: > >> This patch adds the multiple queues configuration in the Device Tre

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

On Fri, Mar 10, 2017 at 06:24:52PM +, Joao Pinto wrote: > This patch adds the RX and TX scheduling algorithms programming. > It introduces the multiple queues configuration function > (stmmac_mtl_configuration) in stmmac_main. > > Signed-off-by: Joao Pinto > --- >

Re: [v5,net-next,1/9] net: stmmac: multiple queues dt configuration

On Fri, Mar 10, 2017 at 06:24:51PM +, Joao Pinto wrote: > This patch adds the multiple queues configuration in the Device Tree. > It was also created a set of structures to keep the RX and TX queues > configurations to be used in the driver. > > Signed-off-by: Joao Pinto

Re: [PATCH net-next] net: ethoc: Use ether_addr_copy()

1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Thierry Reding <thierry.red...@gmail.com> signature.asc Description: PGP signature

[PATCH v2 6/9] net: stmmac: Parse FIFO sizes from feature registers

From: Thierry Reding <tred...@nvidia.com> New version of this core encode the FIFO sizes in one of the feature registers. Use these sizes as default, but still allow device tree to override them for backwards compatibility. Reviewed-by: Mikko Perttunen <mperttu...@nvidia.com>

[PATCH v2 9/9] net: stmmac: dwc-qos: Add Tegra186 support

From: Thierry Reding <tred...@nvidia.com> The NVIDIA Tegra186 SoC contains an instance of the Synopsys DWC ethernet QOS IP core. The binding that it uses is slightly different from existing ones because of the integration (clocks, resets, ...). Signed-off-by: Thierry Reding <tred...@n

[PATCH v2 1/9] net: stmmac: Rename clk_ptp_ref clock to ptp_ref

From: Thierry Reding <tred...@nvidia.com> There aren't currently any users of the "clk_ptp_ref", but there are other references to "ptp_ref", so I'm leaning towards considering that a typo. Fix it. Cc: Mark Rutland <mark.rutl...@arm.com> Cc: Rob Herring

[PATCH v2 7/9] net: stmmac: Program RX queue size and flow control

From: Thierry Reding <tred...@nvidia.com> Program the receive queue size based on the RX FIFO size and enable hardware flow control for large FIFOs. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- Changes in v2: - add comments to clarify flow control threshold programming

[PATCH v2 8/9] net: stmmac: dwc-qos: Split out ->probe() and ->remove()

From: Thierry Reding <tred...@nvidia.com> Split out the binding specific parts of ->probe() and ->remove() to enable the driver to support variants of the binding. This is useful in order to keep backwards-compatibility while making it easy for a sub- driver to deal only with the upda

[PATCH v2 3/9] net: stmmac: Disable PTP reference clock on error

From: Thierry Reding <tred...@nvidia.com> If an error occurs while opening the device, make sure to disable the PTP reference clock. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 1 file changed, 8 insertions(+)

[PATCH v2 0/9] net: stmmac: Fixes and Tegra186 support

From: Thierry Reding <tred...@nvidia.com> Hi everyone, This series of patches start with a few cleanups that I ran across while adding Tegra186 support to the stmmac driver. It then adds code for FIFO size parsing from feature registers and finally enables support for the incar

[PATCH v2 4/9] net: stmmac: Balance PTP reference clock enable/disable

From: Thierry Reding <tred...@nvidia.com> clk_prepare_enable() and clk_disable_unprepare() for this clock aren't properly balanced, which can trigger a WARN_ON() in the common clock framework. Reviewed-By: Joao Pinto <jpi...@synopsys.com> Signed-off-by: Thierry Reding <tre

[PATCH v2 5/9] net: stmmac: Check for DMA mapping errors

From: Thierry Reding <tred...@nvidia.com> When DMA mapping an SKB fragment, the mapping must be checked for errors, otherwise the DMA debug code will complain upon unmap. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |

[PATCH v2 2/9] net: stmmac: Stop PHY and remove TX timer on error

From: Thierry Reding <tred...@nvidia.com> If an error occurs while opening the device, make sure that both the TX timer and the PHY are properly cleaned up. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +- 1 fil

Re: [PATCH 5/7] net: stmmac: Program RX queue size and flow control

On Thu, Mar 09, 2017 at 01:18:11PM -0700, Stephen Warren wrote: > On 03/09/2017 12:42 PM, Thierry Reding wrote: > > On Mon, Feb 27, 2017 at 12:09:02PM +0200, Mikko Perttunen wrote: > > > On 23.02.2017 19:24, Thierry Reding wrote: > > > > From: Thie

Re: [PATCH 7/7] net: stmmac: dwc-qos: Add Tegra186 support

On Mon, Feb 27, 2017 at 01:46:01PM +0200, Mikko Perttunen wrote: > On 23.02.2017 19:24, Thierry Reding wrote: > > From: Thierry Reding <tred...@nvidia.com> > > > > The NVIDIA Tegra186 SoC contains an instance of the Synopsys DWC > > ethernet QOS IP core. The

Re: [PATCH 5/7] net: stmmac: Program RX queue size and flow control

On Thu, Mar 02, 2017 at 03:15:12PM +, Joao Pinto wrote: > Às 5:24 PM de 2/23/2017, Thierry Reding escreveu: > > From: Thierry Reding <tred...@nvidia.com> > > > > Program the receive queue size based on the RX FIFO size and enable > > hardware flow control for

Re: [PATCH 4/7] net: stmmac: Parse FIFO sizes from feature registers

On Thu, Mar 02, 2017 at 03:09:11PM +, Joao Pinto wrote: > Hi Thierry, > > Às 5:24 PM de 2/23/2017, Thierry Reding escreveu: > > From: Thierry Reding <tred...@nvidia.com> > > > > New version of this core encode the FIFO sizes in one of the feature > >

Re: [PATCH 5/7] net: stmmac: Program RX queue size and flow control

On Mon, Feb 27, 2017 at 12:09:02PM +0200, Mikko Perttunen wrote: > On 23.02.2017 19:24, Thierry Reding wrote: > > From: Thierry Reding <tred...@nvidia.com> > > > > Program the receive queue size based on the RX FIFO size and enable > > hardware flow control for

Re: [PATCH 2/7] net: stmmac: Balance PTP reference clock enable/disable

On Mon, Feb 27, 2017 at 11:31:39AM +0200, Mikko Perttunen wrote: > On 23.02.2017 19:24, Thierry Reding wrote: > > From: Thierry Reding <tred...@nvidia.com> > > > > clk_prepare_enable() and clk_disable_unprepare() for this clock aren't > > properly bala

Re: [PATCH 3/7] net: stmmac: Check for DMA mapping errors

On Mon, Feb 27, 2017 at 11:37:24AM +0200, Mikko Perttunen wrote: > On 23.02.2017 19:24, Thierry Reding wrote: > > From: Thierry Reding <tred...@nvidia.com> > > > > When DMA mapping an SKB fragment, the mapping must be checked for > > errors, otherwise the DMA de

Re: [PATCH 0/7] net: stmmac: Fixes and Tegra186 support

On Thu, Feb 23, 2017 at 12:57:05PM -0500, David Miller wrote: > > The net-next tree is closed, therefore it is not appropriate to submit > feature patches or cleanups at this time. > > Please wait for the merge window to be finished and the net-next tree > to open back up before resubmitting

[PATCH 7/7] net: stmmac: dwc-qos: Add Tegra186 support

From: Thierry Reding <tred...@nvidia.com> The NVIDIA Tegra186 SoC contains an instance of the Synopsys DWC ethernet QOS IP core. The binding that it uses is slightly different from existing ones because of the integration (clocks, resets, ...). Signed-off-by: Thierry Reding <tred...@n

[PATCH 1/7] net: stmmac: Rename clk_ptp_ref clock to ptp_ref

From: Thierry Reding <tred...@nvidia.com> There aren't currently any users of the "clk_ptp_ref", but there are other references to "ptp_ref", so I'm leaning towards considering that a typo. Fix it. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- Docum

[PATCH 2/7] net: stmmac: Balance PTP reference clock enable/disable

From: Thierry Reding <tred...@nvidia.com> clk_prepare_enable() and clk_disable_unprepare() for this clock aren't properly balanced, which can trigger a WARN_ON() in the common clock framework. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethernet/st

[PATCH 3/7] net: stmmac: Check for DMA mapping errors

From: Thierry Reding <tred...@nvidia.com> When DMA mapping an SKB fragment, the mapping must be checked for errors, otherwise the DMA debug code will complain upon unmap. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |

[PATCH 4/7] net: stmmac: Parse FIFO sizes from feature registers

From: Thierry Reding <tred...@nvidia.com> New version of this core encode the FIFO sizes in one of the feature registers. Use these sizes as default, but still allow device tree to override them for backwards compatibility. Signed-off-by: Thierry Reding <tred...@nvidia.com> ---

[PATCH 6/7] net: stmmac: dwc-qos: Split out ->probe() and ->remove()

From: Thierry Reding <tred...@nvidia.com> Split out the binding specific parts of ->probe() and ->remove() to enable the driver to support variants of the binding. This is useful in order to keep backwards-compatibility while making it easy for a sub- driver to deal only with the upda

[PATCH 5/7] net: stmmac: Program RX queue size and flow control

From: Thierry Reding <tred...@nvidia.com> Program the receive queue size based on the RX FIFO size and enable hardware flow control for large FIFOs. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +++ drivers/net/ethe

[PATCH 0/7] net: stmmac: Fixes and Tegra186 support

From: Thierry Reding <tred...@nvidia.com> Hi everyone, This series of patches start with a few cleanups that I ran across while adding Tegra186 support to the stmmac driver. It then adds code for FIFO size parsing from feature registers and finally enables support for the incar

Re: [PATCH net-next 2/3] net: ethoc: Utilize of_get_mac_address()

t; Signed-off-by: Florian Fainelli <f.faine...@gmail.com> > --- > drivers/net/ethernet/ethoc.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) Acked-by: Thierry Reding <thierry.red...@gmail.com> signature.asc Description: PGP signature

Re: [PATCH net-next 3/3] net: ethoc: Demote packet dropped error message to debug

faine...@gmail.com> > --- > drivers/net/ethernet/ethoc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Thierry Reding <thierry.red...@gmail.com> signature.asc Description: PGP signature

Re: [PATCH net-next 1/3] net: ethoc: Account for duplex changes

ore seems > to be reacting okay without us telling it. > > Signed-off-by: Florian Fainelli <f.faine...@gmail.com> > --- > drivers/net/ethernet/ethoc.c | 35 +++ > 1 file changed, 35 insertions(+) Acked-by: Thierry Reding <thierry.red...@gmail.c

[PATCH] net: ipconfig: Fix more use after free

From: Thierry Reding <tred...@nvidia.com> While commit 9c706a49d660 ("net: ipconfig: fix use after free") avoids the use after free, the resulting code still ends up calling both the ic_setup_if() and ic_setup_routes() after calling ic_close_devs(), and access to the device i

Re: [net-next,2/2] rxrpc: do not pull udp headers on receive

; net/rxrpc/ar-input.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) To be explicit: Tested-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [net-next,1/2] sunrpc: do not pull udp headers on receive

or fixes) on top of next-20160408 fixes booting from NFS root for me on Jetson TK1. Thanks for fixing this. Tested-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

On Thu, Feb 18, 2016 at 09:04:49PM +0100, Johannes Berg wrote: > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > > >   > > > Johannes, I assume that you'll want to take this through your tree >

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

h/572642/ Johannes, I assume that you'll want to take this through your tree because of the dependency? In that case: Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

[PATCH 4/4] net: mv643xx: Use platform_register/unregister_drivers()

From: Thierry Reding <tred...@nvidia.com> These new helpers simplify implementing multi-driver modules and properly handle failure to register one driver by unregistering all previously registered drivers. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- Applies on top of n

[PATCH 3/4] net: mpc52xx: Use platform_register/unregister_drivers()

From: Thierry Reding <tred...@nvidia.com> These new helpers simplify implementing multi-driver modules and properly handle failure to register one driver by unregistering all previously registered drivers. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- Applies on top of n

[PATCH 1/4] net: bfin_mac: Use platform_register/unregister_drivers()

From: Thierry Reding <tred...@nvidia.com> These new helpers simplify implementing multi-driver modules and properly handle failure to register one driver by unregistering all previously registered drivers. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- Applies on top of n

[PATCH 2/4] net: bcm63xx: Use platform_register/unregister_drivers()

From: Thierry Reding <tred...@nvidia.com> These new helpers simplify implementing multi-driver modules and properly handle failure to register one driver by unregistering all previously registered drivers. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- Applies on top of n

[PATCH] mac80211: Remove kerneldoc for beacon_loss_count

From: Thierry Reding <tred...@nvidia.com> The beacon_loss_count field was removed from the structure in commit 976bd9efdae6 ("mac80211: move beacon_loss_count into ifmgd"). This updates the kerneldoc comment to match the structure definition. Signed-off-by: Thierry Reding <

Re: [linux-next] oops in ip_route_input_noref

; res.type = RTN_UNREACHABLE; > res.fi = NULL; > + res.table = NULL; > goto local_input; > > /* I was seeing the same oops as Fabio (except that the faulting address was 0xb instead of 0x7) and after applying this patch I no longer see it: Tested-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

[PATCH] mac80211: Do not use sizeof() on pointer type

From: Thierry Reding tred...@nvidia.com The rate_control_cap_mask() function takes a parameter mcs_mask, which GCC will take to be u8 * even though it was declared with a fixed size. This causes the following warning: net/mac80211/rate.c: In function 'rate_control_cap_mask': net

[PATCH][RESEND] PHY: Add the phy_device_release device method.

In cases where more than a single PHY is found on the MDIO bus, the kernel will print a warning that this method is missing for each PHY device that is not attached to a networking device. Signed-off-by: Thierry Reding [EMAIL PROTECTED] --- drivers/net/phy/mdio_bus.c | 19

Re: [PATCH][RESEND] PHY: Add the phy_device_release device method.

* Andrew Morton wrote: On Mon, 3 Dec 2007 09:35:11 +0100 Thierry Reding [EMAIL PROTECTED] wrote: In cases where more than a single PHY is found on the MDIO bus, the kernel will print a warning that this method is missing for each PHY device that is not attached to a networking device

[PATCH] Add the phy_device_release device method.

In cases where more than a single PHY is found on the MDIO bus, the kernel will print a warning that this method is missing for each PHY device that has not been attached to a networking device. --- drivers/net/phy/mdio_bus.c | 19 ++- 1 files changed, 18 insertions(+), 1