On Tue, Jun 9, 2020 at 8:20 PM Tom Zanussi wrote:
>
> Hi Ramon,
>
> On Tue, 2020-06-09 at 20:14 +0300, Ramon Fried wrote:
> >
> > On June 9, 2020 8:10:43 PM GMT+03:00, Sebastian Andrzej Siewior <
> > bige...@linutronix.de> wrote:
> > > On 2
On June 9, 2020 8:10:43 PM GMT+03:00, Sebastian Andrzej Siewior
wrote:
>On 2020-06-09 20:07:06 [+0300], Ramon Fried wrote:
>> Indeed
>> I'm truly sorry, I thought our crash kernel is configured as RT as
>well.
>> so, as I understand, if I build the RT kernel withou
On June 9, 2020 7:42:13 PM GMT+03:00, Sebastian Andrzej Siewior
wrote:
>On 2020-06-09 19:40:03 [+0300], Ramon Fried wrote:
>> Correction. normal kernel is running with RT enabled, crash kernel
>without.
>
>no RT and no SMP in your crash kernel? So this information in your
&
On June 9, 2020 7:37:31 PM GMT+03:00, Ramon Fried wrote:
>
>
>On June 9, 2020 7:34:46 PM GMT+03:00, Sebastian Andrzej Siewior
> wrote:
>>On 2020-06-09 11:17:53 [-0500], Tom Zanussi wrote:
>>> Hi Sebastian,
>>Hi Tom,
>>
>>> I did find a prob
On June 9, 2020 7:34:46 PM GMT+03:00, Sebastian Andrzej Siewior
wrote:
>On 2020-06-09 11:17:53 [-0500], Tom Zanussi wrote:
>> Hi Sebastian,
>Hi Tom,
>
>> I did find a problem with the patch when configured as !SMP since in
>> that case the RUN flag is never set (will send a patch for that
>>
On Thu, Apr 23, 2020 at 11:55 PM wrote:
>
> From: Zhang Xiao
>
> v4.19.115-rt49-rc1 stable review patch.
> If anyone has any objections, please let me know.
>
> ---
>
>
> The kernel bugzilla has the following race condition reported:
>
> CPU0CPU1CPU2
>
GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-by: Ramon Fried
Signed-off-by: Ramon Fried
---
v3:
* Remove the debug message and replace with comment in code.
v2: Address review from linus:
* ** Please notive logic was reversed **
* renamed pinctrl_gpio_is_in_use
On Tue, 2019-08-13 at 18:32 +0200, Stefan Wahren wrote:
> Am 13.08.19 um 08:10 schrieb Fried, Ramon:
> > On 8/13/2019 08:38, Stefan Wahren wrote:
> > > Hi Ramon,
> > >
> > > On 13.08.19 03:42, Ramon Fried wrote:
> > > > From: Stefan Wahren
> &
GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-by: Ramon Fried
Signed-off-by: Ramon Fried
---
v2: Address review from linus:
* ** Please notive logic was reversed **
* renamed pinctrl_gpio_is_in_use() to pinctrl_gpio_can_use_line()
* renamed pinmux_is_in_use
On August 6, 2019 4:11:27 PM GMT+03:00, Linus Walleij
wrote:
>On Tue, Aug 6, 2019 at 3:04 PM Linus Walleij
>wrote:
>> On Sat, Aug 3, 2019 at 3:34 PM Ramon Fried
>wrote:
>>
>> > From: Stefan Wahren
>> >
>> > The user space like gpioinfo on
GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-By: Ramon Fried
Signed-off-by: Ramon Fried
---
Sending Stefan's RFC as patch, as I tested it and it seems to work,
additionally, an accompanying fix was made by me to gpiolibd to fix a
display error of the actual result:
https
Returning -EAGAIN is no longer supported by pin_config_group_set()
since ad42fc6c8479 ("pinctrl: rip out the direct pinconf API")
Remove the relevant section from the documentation.
Signed-off-by: Ramon Fried
---
Documentation/driver-api/pinctl.rst | 9 -
1 file changed, 9
On 1/21/19 4:26 PM, Linus Walleij wrote:
On Mon, Jan 21, 2019 at 2:28 PM Ramon Fried wrote:
Stated in Documentation/driver-api/pinctl.rst:
Since some controllers have special logic for handling entire groups of pins
they can exploit the special whole-group pin control function
Hi Linus,
Stated in Documentation/driver-api/pinctl.rst:
Since some controllers have special logic for handling entire groups of pins
they can exploit the special whole-group pin control function. The
pin_config_group_set() callback is allowed to return the error code -EAGAIN,
for groups it
On Mon, Nov 19, 2018 at 5:50 PM Robin Murphy wrote:
>
> On 19/11/2018 14:18, Ramon Fried wrote:
> > On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
> > wrote:
> >>
> >> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> >>>> -
On Mon, Nov 19, 2018 at 5:50 PM Robin Murphy wrote:
>
> On 19/11/2018 14:18, Ramon Fried wrote:
> > On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
> > wrote:
> >>
> >> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> >>>> -
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
wrote:
>
> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> > > -* Because 32-bit DMA masks are so common we expect every
> > > architecture
> > > -* to be able to satisfy them - either by not supporting more
> > >
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
wrote:
>
> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> > > -* Because 32-bit DMA masks are so common we expect every
> > > architecture
> > > -* to be able to satisfy them - either by not supporting more
> > >
Hi.
If what I'm suggesting makes no sense please tell me. :)
In a char driver I'm writing I'm using completion to wait for transmit
operation to complete.
The drivers also exposes poll() functionality to wait for transmission
to complete.
poll_wait() requires a wait queue, is there a reason why
Hi.
If what I'm suggesting makes no sense please tell me. :)
In a char driver I'm writing I'm using completion to wait for transmit
operation to complete.
The drivers also exposes poll() functionality to wait for transmission
to complete.
poll_wait() requires a wait queue, is there a reason why
On Tue, Aug 14, 2018 at 2:04 PM Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On Tuesday 14 August 2018 06:25 PM, Ramon Fried wrote:
> > On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I
> > wrote:
> >>
> >> Hi,
> >>
> >> On Tuesday 1
On Tue, Aug 14, 2018 at 2:04 PM Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On Tuesday 14 August 2018 06:25 PM, Ramon Fried wrote:
> > On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I
> > wrote:
> >>
> >> Hi,
> >>
> >> On Tuesday 1
On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On Tuesday 14 August 2018 06:19 PM, Ramon Fried wrote:
> > Hi.
> > I recently saw that the PCI endpoint API only supports outbound memory
> > mapping: (AXI -> PCI) through the map_addr op.
&
On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On Tuesday 14 August 2018 06:19 PM, Ramon Fried wrote:
> > Hi.
> > I recently saw that the PCI endpoint API only supports outbound memory
> > mapping: (AXI -> PCI) through the map_addr op.
&
Hi.
I recently saw that the PCI endpoint API only supports outbound memory
mapping: (AXI -> PCI) through the map_addr op.
Why inbound mapping is missing (PCI->AXI) is missing ?
In almost all of the PCI EP controllers I've worked with there was a
need to map complete BARS or part of BARS to
Hi.
I recently saw that the PCI endpoint API only supports outbound memory
mapping: (AXI -> PCI) through the map_addr op.
Why inbound mapping is missing (PCI->AXI) is missing ?
In almost all of the PCI EP controllers I've worked with there was a
need to map complete BARS or part of BARS to
-off-by: Ramon Fried
---
drivers/soc/qcom/smem.c | 41 +++
include/linux/soc/qcom/smem.h | 6 ++---
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 0b94d62fad2b..e5ef6611ed73 10
-off-by: Ramon Fried
---
drivers/soc/qcom/smem.c | 41 +++
include/linux/soc/qcom/smem.h | 6 ++---
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 0b94d62fad2b..e5ef6611ed73 10
On Tue, May 29, 2018 at 7:20 AM, Bjorn Andersson
wrote:
> On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote:
>
>> Sometimes that rmtfs userspace module is not brought
>> up fast enough and the modem crashes.
>> disabling automated boot in the driver and triggering
>> t
On Tue, May 29, 2018 at 7:20 AM, Bjorn Andersson
wrote:
> On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote:
>
>> Sometimes that rmtfs userspace module is not brought
>> up fast enough and the modem crashes.
>> disabling automated boot in the driver and triggering
>> t
On Thu, May 24, 2018 at 10:34 PM, Baruch Siach <bar...@tkos.co.il> wrote:
> Hi Ramon,
>
> On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote:
>> I've noticed that it's not supported.
>> Is it on purpose ?
>
> Yes. The 32bit load address in the uIm
On Thu, May 24, 2018 at 10:34 PM, Baruch Siach wrote:
> Hi Ramon,
>
> On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote:
>> I've noticed that it's not supported.
>> Is it on purpose ?
>
> Yes. The 32bit load address in the uImage header in pretty limited wh
Sometimes that rmtfs userspace module is not brought
up fast enough and the modem crashes.
disabling automated boot in the driver and triggering
the boot from user-space sovles the problem.
Signed-off-by: Ramon Fried <ramon.fr...@gmail.com>
---
drivers/remoteproc/qcom_q6v5_pil.c | 2 ++
Sometimes that rmtfs userspace module is not brought
up fast enough and the modem crashes.
disabling automated boot in the driver and triggering
the boot from user-space sovles the problem.
Signed-off-by: Ramon Fried
---
drivers/remoteproc/qcom_q6v5_pil.c | 2 ++
1 file changed, 2 insertions
Hi.
I've noticed that it's not supported.
Is it on purpose ?
If not I'll be happy to add support for: make uImage
for arm64 targets.
Warm regards,
Ramon.
Hi.
I've noticed that it's not supported.
Is it on purpose ?
If not I'll be happy to add support for: make uImage
for arm64 targets.
Warm regards,
Ramon.
ed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>
---
v3:
* fixed kbuild warning
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless
-off-by: Ramon Fried
---
v3:
* fixed kbuild warning
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3
ed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>
---
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
dr
-off-by: Ramon Fried
---
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx
On 17 May 2018 at 21:37, Jeff Johnson <jjohn...@codeaurora.org> wrote:
> On 2018-05-17 04:32, Ramon Fried wrote:
>>
>> From: Eyal Ilsar <eil...@codeaurora.org>
>
> ...
>>
>> +int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
>> +
On 17 May 2018 at 21:37, Jeff Johnson wrote:
> On 2018-05-17 04:32, Ramon Fried wrote:
>>
>> From: Eyal Ilsar
>
> ...
>>
>> +int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
>> + struct ieee80211_vif *vif, void *ptt_msg,
ed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless
-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c| 74 +
drivers/net/wireless/ath/wcn36xx/smd.h
(adding Bjorn Andersson)
On 3/29/2018 10:15 AM, Kalle Valo wrote:
> (adding devicetree list)
>
> Ramon Fried <rfr...@codeaurora.org> writes:
>
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an extern
(adding Bjorn Andersson)
On 3/29/2018 10:15 AM, Kalle Valo wrote:
> (adding devicetree list)
>
> Ramon Fried writes:
>
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, re
On 3/29/2018 9:58 AM, Rafał Miłecki wrote:
> On 03/29/2018 08:20 AM, Ramon Fried wrote:
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, retrieve the id and disable 5GHz band in
On 3/29/2018 9:58 AM, Rafał Miłecki wrote:
> On 03/29/2018 08:20 AM, Ramon Fried wrote:
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, retrieve the id and disable 5GHz band in
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
v2: fixed wrong assignment, which is log
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried
---
v2: fixed wrong assignment, which is logically introduces
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
drivers/net/wireless/ath/wcn36xx/main.c
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
drivers/net
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
V2: Corrected subject line, this is not a part of a patchset.
V3: Placed the changelog under the ---.
net/qrtr/smd
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried
---
V2: Corrected subject line, this is not a part of a patchset.
V3: Placed the changelog under the ---.
net/qrtr/smd.c | 1 +
1 file changed, 1
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
V2: Corrected subject line, this is not a part of a patchset.
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried
V2: Corrected subject line, this is not a part of a patchset.
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efa
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
---
having a too high value for WLAN means that BLE
performance degrades.
The "sweet" point of roughly half of the maximal values was empirically found
to achieve
a balance between BLE and Wi-Fi coexistence performance.
Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-of
means that BLE
performance degrades.
The "sweet" point of roughly half of the maximal values was empirically found
to achieve
a balance between BLE and Wi-Fi coexistence performance.
Signed-off-by: Eyal Ilsar
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/smd.c |
From: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
drivers/net/wireless/ath/wcn36xx/main.c | 2 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +++-
2 files changed, 4 insertio
From: Eyal Ilsar
Signed-off-by: Eyal Ilsar
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/main.c | 2 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net
Wow. Thanks a lot !
-Original Message-
From: Kedareswara rao Appana [mailto:appana.durga@xilinx.com]
Sent: Monday, April 25, 2016 11:48 AM
To: vinod.k...@intel.com; dan.j.willi...@intel.com; Ramon Fried
<ramon.fr...@tandemg.com>
Cc: dmaeng...@vger.kernel.org; linux-
Wow. Thanks a lot !
-Original Message-
From: Kedareswara rao Appana [mailto:appana.durga@xilinx.com]
Sent: Monday, April 25, 2016 11:48 AM
To: vinod.k...@intel.com; dan.j.willi...@intel.com; Ramon Fried
Cc: dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; Kedareswara rao
I'm looking of a way to validate a DMA engine driver I've written.
I came across dmatest module and while reading the code I've noticed that
scatter-gather DMA mode is not implemented.
I wonder if anyone one knows the reason, and if such enhancement will be
welcome as a patch.
Thanks.
Ramon
I'm looking of a way to validate a DMA engine driver I've written.
I came across dmatest module and while reading the code I've noticed that
scatter-gather DMA mode is not implemented.
I wonder if anyone one knows the reason, and if such enhancement will be
welcome as a patch.
Thanks.
Ramon
This fixes the following sparse warning:
llite_lib.c:1240:5: warning: symbol 'll_md_setattr' was not declared. Should it
be static?
Signed-off-by: Ramon Fried
---
drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
This fixes the following sparse warning:
llite_lib.c:1240:5: warning: symbol 'll_md_setattr' was not declared. Should it
be static?
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
---
drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This patch fixes the following checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
#116: FILE: ./xlr_net.c:116:
+ if (!skb) {
+ pr_err("SKB allocation failed\n");
Signed-off-by: Ramon Fried
---
drivers/staging/netlogic/xlr_net.c | 4 +-
, 2014 at 3:32 AM, Greg Kroah-Hartman
wrote:
> On Sun, Aug 31, 2014 at 03:16:48AM +0300, Ramon Fried wrote:
>> This patch fixes the following checkpatch.pl warnings:
>>
>> WARNING: Possible unnecessary 'out of memory' message
>> #146: FILE: ./xlr_net
, 2014 at 3:32 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sun, Aug 31, 2014 at 03:16:48AM +0300, Ramon Fried wrote:
This patch fixes the following checkpatch.pl warnings:
WARNING: Possible unnecessary 'out of memory' message
#146: FILE: ./xlr_net.c:146:
+ if (!skb
This patch fixes the following checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
#116: FILE: ./xlr_net.c:116:
+ if (!skb) {
+ pr_err(SKB allocation failed\n);
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
---
drivers/staging/netlogic/xlr_net.c
net.c:1107:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv->ndev);
Signed-off-by: Ramon Fried
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/sta
net.c:1107:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv->ndev);
>From 27b58d9b1d39ab99bf6022b82ac9e602621b2822 Mon Sep 17 00:00:00 2001
From: Ramon Fried
Date: Sat, 30 Aug 2014 22:26:11 +0300
Subject: [PATCH] staging: netlogic: fixed checkpatch.pl
:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv-ndev);
From 27b58d9b1d39ab99bf6022b82ac9e602621b2822 Mon Sep 17 00:00:00 2001
From: Ramon Fried ramon.fr...@gmail.com
Date: Sat, 30 Aug 2014 22:26:11 +0300
Subject: [PATCH] staging: netlogic: fixed checkpatch.pl
:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv-ndev);
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b
76 matches
Mail list logo