On Wed, Nov 28, 2012 at 3:07 PM, Hauke Mehrtens wrote:
> struct spinlock does not exists on kernel version <= 2.6.32, use
> spinlock_t instead.
>
> Signed-off-by: Hauke Mehrtens
> ---
> patches/network/67-use_spinlock_t.patch | 11 +++
> 1 file changed, 11 insertions(+)
> create mode
From: "Luis R. Rodriguez"
Turns out a few drivers have strayed away from using the
spinlock_t typedef and decided to use struct spinlock
directly. This series converts these drivers to use
spinlock_t. Each change has been compile tested with
allmodconfig and sparse checked. Driver deve
From: "Luis R. Rodriguez"
spinlock_t should always be used.
I was unable to build test with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 M=drivers/crypto/ux500/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; mo
From: "Luis R. Rodriguez"
spinlock_t should always be used.
LD drivers/gpu/drm/i915/built-in.o
CHECK drivers/gpu/drm/i915/i915_drv.c
CC [M] drivers/gpu/drm/i915/i915_drv.o
CHECK drivers/gpu/drm/i915/i915_dma.c
CC [M] drivers/gpu/drm/i915/i915_dma.o
CHECK drive
From: "Luis R. Rodriguez"
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-fimc/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
From: "Luis R. Rodriguez"
spinlock_t should always be used.
LD drivers/net/wireless/brcm80211/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o
CHECK drivers/net/wireless/brcm8021
From: "Luis R. Rodriguez"
spinlock_t should always be used.
CHECK drivers/watchdog/ie6xx_wdt.c
CC [M] drivers/watchdog/ie6xx_wdt.o
Building modules, stage 2.
MODPOST 43 modules
LD [M] drivers/watchdog/ie6xx_wdt.ko
Cc: Alexander Stein
Reported-by: Hauke Mehrtens
Sig
From: "Luis R. Rodriguez"
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-jpeg
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
On Thu, Nov 29, 2012 at 11:47 AM, Luis R. Rodriguez
wrote:
> On Wed, Nov 28, 2012 at 3:07 PM, Hauke Mehrtens wrote:
>
> IMHO your patch should go upstream and a respective patch should be
> submitted as well as for these drivers:
>
> mcgrof@frijol ~/linux-next (git::master)
On Mon, Mar 18, 2013 at 03:13:41PM -0400, John W. Linville wrote:
> Any comments from the ath9k folks?
>
> On Sat, Mar 16, 2013 at 12:38:14PM -0400, Parag Warudkar wrote:
> > During suspend below warning is seen when ath9k is active. Attached
> > patch fixes the warning for me. Tested to work acr
From: "Luis R. Rodriguez"
This patch series deals with the project that aims at
backporting the Linux kernel [0]. If you don't care
for that, at least read this and patch #1, the rest
you can nuke.
Ben reports compat_ namespace is already taken by the
kernel, and while this is s
From: "Luis R. Rodriguez"
Ben Hutchings notes that "compat_" is already taken as a
prefix for symbols and while this is only slightly true
in practice its best we avoid any future issues.
Others in the past have noted issues with symbols exported
by backporting effort to
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
There is one change needed here to get compilation
working on v2.6.24, strict_strtoull is now being
redefined and because of a change that went into
v2.6.38.4 kstrtoul() was added there and the old
strict_strtoul was made a define from it. To help
aid the old
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
From: "Luis R. Rodriguez"
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31
On Wed, Mar 20, 2013 at 2:22 AM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> This patch series deals with the project that aims at
> backporting the Linux kernel [0]. If you don't care
> for that, at least read this and patch #1, the rest
> you
On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd wrote:
> Hi,
>
> Here's my first take on the version number policy:
>
> https://github.com/qca/open-ath9k-htc-firmware/wiki/VersionPolicy
>
> The summary:
>
> * major version number changes are for firmware API / behaviour
> changes that aren't backwar
On Sat, Feb 23, 2013 at 11:34 AM, Michal Kazior wrote:
> Dbii F52N-PRO mini pci device reports an invalid
> regdomain. This card has been reported to work on
> MikroTik's RouterOS but failed on Linux:
>
> [ 14.32] ath: EEPROM regdomain: 0x
> [ 14.32] ath: EEPROM indicates we should
On Tue, Feb 26, 2013 at 11:28 AM, Michał Kazior wrote:
> On 26 February 2013 19:29, Luis R. Rodriguez wrote:
>> NACK. This comes up every now and then and this is not a valid device
>> ID, this is an issue with the card, so what you can do is adjust the
>> device ID pos
On Sat, Dec 8, 2012 at 8:22 AM, W. Trevor King wrote:
> On Wed, Nov 21, 2012 at 12:10:43AM +, Alan Cox wrote:
>> > Not just a separate document but project / github / whatever given
>> > that other projects are referring to it now, and we stand to gain more
>> > in the community by streamlinin
On Tue, Feb 26, 2013 at 12:01 PM, Luis R. Rodriguez
wrote:
> Apologies again and then (unless I hear otherwise from David Quan):
>
> Acked-by: Luis R. Rodriguez
I did hear back from David and it seems that we would never support
this. John please do not apply this just yet.
L
esh patches
compat-drivers: move disable_drm
compat-drivers: refresh patches
Luis R. Rodriguez (69):
compat-drivers: fix sed for gen-release.sh
compat-drivers: add support for uploading stable releases
compat-drivers: add / to target stable release end dir
com
On Fri, Feb 15, 2008 at 2:57 PM, <[EMAIL PROTECTED]> wrote:
> The semaphore wpa_sem is used as mutex, convert it to the mutex API
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Acked-by: Luis R. Rodriguez <[EMAIL PROTECTED]>
Luis
--
To unsubscribe fr
On Fri, Feb 15, 2008 at 3:58 PM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> -static bool
> +static int
> ath5k_hw_setup_xr_tx_desc(struct ath5k_hw *ah, struct ath5k_desc *desc,
> unsigned int tx_rate1, u_int tx_tries1, u_int tx_rate2, u_int
> tx_tries2,
> unsigned int tx_rate3, u
On Fri, Feb 15, 2008 at 2:56 PM, <[EMAIL PROTECTED]> wrote:
> The semaphore acl->sem is used as mutex, convert it to the mutex API
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Acked-by: Luis R. Rodriguez <[EMAIL PROTECTED]>
Luis
--
To unsubscribe
On Fri, Feb 15, 2008 at 3:58 PM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> At least type check the ATH5K_TRACE paramter on !ATH5K_DEBUG configs.
That's pretty cool.
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> Cc: Nick Kossifidis <[EMAIL PROTECTED]>
On Fri, Feb 15, 2008 at 5:38 PM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
> You mean to consider 0 as supported, -ENODEV/-EOPNOTSUPP as
> unsupported and the rest as error?
>
Yeap, what do you think?
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, Feb 15, 2008 at 2:56 PM, <[EMAIL PROTECTED]> wrote:
> The semaphore stats_sem is used as mutex, convert it to the mutex API
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Acked-by: Luis R. Rodriguez <[EMAIL PROTECTED]>
Thanks, BTW, for the next set
On Fri, Sep 21, 2012 at 1:16 AM, Greg Kroah-Hartman
wrote:
> On Thu, Sep 20, 2012 at 03:45:46PM -0700, Luis R. Rodriguez wrote:
>> Greg, Stephen, Konstantin,
>>
>> so for the Linux backports project [0] we rely on a few git trees:
>>
>> * linux-next.git
>>
On Tue, Sep 18, 2012 at 6:31 PM, Gustavo Padovan wrote:
> Johan Hedberg (2):
> Bluetooth: mgmt: Implement support for passkey notification
Too late now... but why did we allow this a stable fix? I get its a
feature that is important and likely overlooked / someone had a brain
fart, but fro
Kicked out the first Linux kernel backports release under the new
project name, "backports" that hopefully clarifies this a generic
backport project now. Backported subsystems in this release:
* Ethernet
* Wireless
* Bluetooth
* NFC
* GPU
* Media
* Regulator
Go read the git tree for
On Fri, Jul 12, 2013 at 5:40 PM, Sven-Haegar Koch wrote:
> On Fri, 12 Jul 2013, Luis R. Rodriguez wrote:
>
>> Kicked out the first Linux kernel backports release under the new
>> project name, "backports" that hopefully clarifies this a generic
>> backport pro
On Thu, Oct 4, 2012 at 6:34 PM, wrote:
> From: xiong
>
> 1. support new device id (0x10A0/0x10A1).
> 2. add DEBUG_FS interface for diag/swoi functions.
>
> Signed-off-by: Ren Cloud
> Signed-off-by: xiong
Xiong,
-- Vladimir, just a heads up -- this applies to you as well for the
802.11ad wil
On Mon, Oct 8, 2012 at 5:42 PM, Greg Kroah-Hartman
wrote:
> On Mon, Oct 08, 2012 at 03:25:08PM -0700, Luis R. Rodriguez wrote:
>> On Thu, Oct 4, 2012 at 6:34 PM, wrote:
>> > From: xiong
>> >
>> > 1. support new device id (0x10A0/0x10A1).
>> > 2. a
On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel wrote:
> So what is the rationale here. During mainlining our drivers we had to
> remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle
> (chapter 5 Typedefs) is spending a number of lines explaining why.
>
> So is spinlock_t an ex
On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez
wrote:
> On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel wrote:
>> So what is the rationale here. During mainlining our drivers we had to
>> remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle
&
On Tue, Dec 04, 2012 at 11:28:26AM +0200, Vladimir Kondratiev wrote:
> Hi Jason,
>
> Do you have any update on the status for patches below?
> Where is it now? When do you expect it to merge? 3.8?
> I am waiting for this to merge before I can go on
> with my driver.
*poke*
Luis
--
To unsubscri
On Tue, Dec 11, 2012 at 12:24:04PM -0800, Joe Perches wrote:
> On Tue, 2012-12-11 at 12:12 -0800, Greg KH wrote:
> > On Tue, Dec 11, 2012 at 03:08:31PM -0500, Jason Baron wrote:
> > > On Tue, Dec 11, 2012 at 11:36:46AM -0800, Luis R. Rodriguez wrote:
> > > > On T
Thanks to arrangements by the Linux Foundation, HP, and SUSE we now
have a suitable server we can share to help do compilation testing of
our work for compat-drivers which aims at automatically backporting
the Linux kernel down to all supported known kernel releases. HP
donated a server to the proj
On Mon, Apr 22, 2013 at 6:11 AM, Mark Brown wrote:
> On Mon, Apr 15, 2013 at 06:33:52PM +0200, Johannes Berg wrote:
>> On Mon, 2013-04-15 at 17:26 +0100, Mark Brown wrote:
>
>> > Please let's at least discuss the issues here, I'm not sure what this is
>> > supposed to do but the analysis of the su
On Thu, Mar 21, 2013 at 12:42:20PM +0100, Stanislaw Gruszka wrote:
> On Mon, Mar 18, 2013 at 02:03:08PM -0700, Luis R. Rodriguez wrote:
> > > > --- a/drivers/net/wireless/ath/ath9k/link.c
> > > > +++ b/drivers/net/wireless/ath/ath9k/link.c
> > > > @@ -158,7
On Fri, Mar 22, 2013 at 10:13:42AM +0100, Stanislaw Gruszka wrote:
> On Thu, Mar 21, 2013 at 12:33:31PM -0700, Luis R. Rodriguez wrote:
> > OK how about this for stable for now:
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/link.c
> > b/drivers/net/wireless
On Tue, Jul 30, 2013 at 09:58:38AM +0200, Hector Palacios wrote:
> This brings an interesting question: shouldn't the firmware download
> part be isolated from the USB driver? After all, I want to
> communicate with a UART bluetooth chip.
There are a few BT firmware upload modules (last I checked
CC'ing linux-wireless as ROM patching is mentioned and in so far as
802.11 mobile is concerned this is a pretty frequent practice there
as well so figured we'd tie in the conversations.
On Tue, Jul 30, 2013 at 03:05:18PM -0700, Marcel Holtmann wrote:
> Hi Luis,
>
> >> This brings an interesting q
On Tue, Jul 30, 2013 at 04:55:08PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 30, 2013 at 03:48:09PM -0700, Luis R. Rodriguez wrote:
> > > We are planning to take one extra step and split this into a
> > > mini-driver approach similar to what has been done for usbnet,
On Tue, Jul 30, 2013 at 11:46 PM, Johannes Berg
wrote:
> On Tue, 2013-07-30 at 15:48 -0700, Luis R. Rodriguez wrote:
>
>> Neat. Perhaps we need something that we can share with 802.11 or other
>> hardare I highly doubt we're the only ones patching ROM. Don't we eve
From: "Luis R. Rodriguez"
The Linux kernel had tons of code which at times cleared the
drvdata upon probe failure or release. There are however a bunch
of drivers that didn't clear this.
Commit 0998d063 implmented clearing this upon device_release_driver()
and dealt with p
On Tue, May 22, 2012 at 3:09 PM, Hans de Goede wrote:
> 1) drvdata is for a driver to store a pointer to driver specific data
> 2) If no driver is bound, there is no driver specific data associated with
>the device
> 3) Thus logically drvdata should be NULL if no driver is bound.
>
> But many
On Fri, Jul 19, 2013 at 2:07 PM, Luis R. Rodriguez
wrote:
>> This is not a very good idea. Although setting drvdata to NULL allowed
>> a lot of code to be removed, it also exposed a bunch of hidden bugs --
>> drivers were using the drvdata value even after their remove fu
On Fri, Jul 19, 2013 at 7:17 AM, Alan Stern wrote:
> On Thu, 18 Jul 2013, Luis R. Rodriguez wrote:
>
>> From: "Luis R. Rodriguez"
>>
>> The Linux kernel had tons of code which at times cleared the
>> drvdata upon probe failure or release. There are however
On Fri, Jul 19, 2013 at 2:27 PM, Julia Lawall wrote:
> On Fri, 19 Jul 2013, Luis R. Rodriguez wrote:
>
>> On Fri, Jul 19, 2013 at 2:07 PM, Luis R. Rodriguez
>> wrote:
>> >> This is not a very good idea. Although setting drvdata to NULL allowed
>> >> a
From: "Luis R. Rodriguez"
The Linux kernel had tons of code which at times cleared the
drvdata upon probe failure or release. There are however a bunch
of drivers that didn't clear this.
Commit 0998d063 implmented clearing this upon device_release_driver()
and dealt with p
On Fri, Jul 19, 2013 at 8:36 PM, Alan Stern wrote:
> On Fri, 19 Jul 2013, Luis R. Rodriguez wrote:
>
>> Thanks Julia. In that case I'm going to just leave this in place given
>> that if there's a bug upstream we'll get it fixed as soon as a
>> respective p
On Mon, May 13, 2013 at 10:09 AM, Adrian Chadd wrote:
> On 13 May 2013 09:39, Jonathan Bither wrote:
>
>>> ... is anyone using this on openwrt?
>>>
>> I am.
>> I am also reworking AR2131X drivers and will submit a patch to linux-mips
>> shortly.
>
> Sweet. Someone say NACK then? :)
NACK, looking
From: "Luis R. Rodriguez"
It is questionable if we'd want to backport calls declared
through late_initcall() or core_initcall() on the kernel
but if this ends up being desired the current of copying
kernel code requires either patching or redefining these
symbols to make them b
From: "Luis R. Rodriguez"
This is enabled only for >= 3.2 and enables all regulator
drivers. This is required by some media subsystem drivers.
Signed-off-by: Luis R. Rodriguez
---
backport/Makefile.kernel |1 +
backport/c
From: "Luis R. Rodriguez"
This adds backport support for all media subsystem
drivers. This is enabled only for >= 3.2.
Signed-off-by: Luis R. Rodriguez
---
.blacklist.map |9 +
backport/Makefile.kernel |
From: "Luis R. Rodriguez"
This is just test work I've been doing on the side, that really
just started from scratching an itch to see what is possible.
In the compat-drivers trees I had actually gotten to run time
test the USB video camera driver and that worked fine. Under
th
On Sat, Apr 6, 2013 at 7:35 PM, Luis R. Rodriguez
wrote:
> Segmentation fault
> make[8]: *** [/home/mcgrof/tmp/build/compat/core.o] Error 139
And sorry, *this* set should have gone out as RFCs, not PATCH. The
other 9 should be fine if we just run ckmake to test them.
Luis
--
To unsub
On Sat, Apr 6, 2013 at 7:37 PM, Luis R. Rodriguez
wrote:
> On Sat, Apr 6, 2013 at 7:35 PM, Luis R. Rodriguez
> wrote:
>> Segmentation fault
>> make[8]: *** [/home/mcgrof/tmp/build/compat/core.o] Error 139
I've narrowed the segfault to a core.c file with just:
#include
#
Do we have a central place to centrally document ARM development
upstream? I'd like to start using a central place to start documenting
things for some stuff I'd like to work on and I don't want to use any
vendor specific stuff. Are we go happy with using elinux.org ? If so
can we add a reference t
On Wed, Apr 10, 2013 at 10:20 AM, Johannes Berg
wrote:
> On Wed, 2013-04-10 at 10:13 -0700, Luis R. Rodriguez wrote:
>> On Wed, Apr 10, 2013 at 6:22 AM, Johannes Berg
>> wrote:
>> > On Wed, 2013-04-10 at 04:35 -0700, Luis R. Rodriguez wrote:
>> >> From: "
Curious if anyone has worked on latency and jitter benchmarks in using
netlink, specifically with nl80211. Has anyone benchmarked this? Ben,
have you? If not for nl80211 perhaps this has been done before for
other netlink families?
Luis
--
To unsubscribe from this list: send the line "unsubscrib
On Wed, Apr 10, 2013 at 10:59 AM, Ben Greear wrote:
> On 04/10/2013 10:55 AM, Luis R. Rodriguez wrote:
>>
>> Curious if anyone has worked on latency and jitter benchmarks in using
>> netlink, specifically with nl80211. Has anyone benchmarked this? Ben,
>> have you? If n
On Wed, Apr 10, 2013 at 11:20 AM, Johannes Berg
wrote:
> On Wed, 2013-04-10 at 10:26 -0700, Luis R. Rodriguez wrote:
>
>> > I guess I'd have to review the async API,
>>
>> Yeap, reviewing the commit noted would help too.
>
> Yeah ... :)
>
>> &g
On Wed, Apr 10, 2013 at 12:27 PM, Johannes Berg
wrote:
> On Wed, 2013-04-10 at 12:19 -0700, Luis R. Rodriguez wrote:
>
>> > However, it seems entirely pointless to backport just a small part of
>> > the API?
>>
>> Oh I agree don't get me wrong, howev
On Wed, Apr 10, 2013 at 12:39 PM, Johannes Berg
wrote:
> On Wed, 2013-04-10 at 12:32 -0700, Luis R. Rodriguez wrote:
>
>> >> Oh I agree don't get me wrong, however porting kernel/async.c seems
>> >> like a rather separate effort worth considering. As-is though
Today the backports project provides support to backport down to
2.6.24 for some subsystems. While this is good for users in practice
for development and maintenance this is quite a bit of overhead. Apart
from older kernels there are also gaps in between stable releases that
are not supported. For
On Mon, Apr 8, 2013 at 2:04 PM, Luis R. Rodriguez
wrote:
> Do we have a central place to centrally document ARM development
> upstream? I'd like to start using a central place to start documenting
> things for some stuff I'd like to work on and I don't want to use any
>
From: "Luis R. Rodriguez"
This backports the latest regulator drivers for kernels >= 3.4.
We enable the regulator only on kernels >= 3.4 given that
it relies on the new probe deferral mechanism which would
otherwise mean having to support drivers that do not probe
correctly. Not
From: "Luis R. Rodriguez"
This adds backport support for all media subsystem
drivers. This is enabled only for >= 3.2. Some media
drivers rely on the new probe deferrral mechanism
(-EPROBE_DEFER see commit d1c3414c), those are only
enabled for kernels >= 3.4. Some media driver
At the 2013 San Francisco Linux Collaboration talk I gave a talk [0]
as a followup on the discussions I initiated a while ago on lkml [1]
on the possibility of taking the Linux kernel's Developer Certificate
of Origin and streamlining it by making it a stand alone project for
other projects to bene
Folks as you may already know compat-drivers was renamed to backports
to avoid any confusion with the in-kernel compat code that deals with
32/64 bit compat work and due to some huge amount of changes that went
into the project recently thanks mainly to Johannes. The new tree is
available here:
gi
As announced on the list the compat-drivers project was renamed to
backports [0] and uses now only one new tree for development [1]. Due
to the huge amount of changes we've been behind on linux-next daily
snapshots but we've now caught up with Linus so a release based on
v3.10-rc1 is due and is now
1 - 100 of 3151 matches
Mail list logo
