On 7 February 2013 12:54, Amit Kale wrote:
>> -Original Message-
>> From: Kent Overstreet [mailto:koverstr...@google.com]
>> Sent: Wednesday, February 06, 2013 4:01 PM
>> To: Amit Kale
>> Cc: Michel Lespinasse; Darrick J. Wong; linux-bcache; device-mapper
>> development; Kent Overstreet; M
On Saturday 09 February 2013, Vineet Gupta wrote:
> On Saturday 09 February 2013 04:31 AM, Grant Likely wrote:
> > On Fri, 11 Jan 2013 11:50:23 +0530, Vineet Gupta
> > wrote:
> >> +- clock-frequency : the input clock frequency for the UART
> >> +- baud : baud rate for UART
On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote:
> Also, _reading_ MSRs from userspace arguably has utility that doesn't
> compromise ring-0.
And to come back to the original question: what is that utility, who
would need it on a secure boot system and why?
--
Regards/Gruss,
Boris.
On Fri, Feb 08, 2013 at 12:28:13PM -0800, Dave Hansen wrote:
>
> Boris, could you check that this series also fixes the /dev/mem
> problem you were seeing?
>
> --
>
> We have a new debugging check on x86 that has caught a number
> of long-standing bugs. However, there is a _bit_ of collateral
>
On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
wrote:
> Quite frankly, that's just optimizing for the wrong case.
I obviously don't agree. I'm fairly sure there wouldn't be a kvmtool
that supports x86, PPC64, ARM, and all the virtio drivers had we not
optimized for making development for kernel f
On Wed, 6 Feb 2013 13:48:19 +0900, Alex Courbot wrote:
> On 02/06/2013 02:21 AM, Linus Walleij wrote:
> > This looks like it is preserving this userspace-sensitive semantic
> > so that dynamically added chips will still get the same assigned
> > numbers.
>
> It does (it should, at least), the ass
On Tue, 5 Feb 2013 18:00:56 +0100, Linus Walleij
wrote:
> On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
>
> > Add a list member to gpio_chip that allows all chips to be parsed
> > quickly. The current method requires parsing the entire GPIO integer
> > space, which is painfully slow.
On Wed, 9 Jan 2013 01:19:39 -0800, Dmitry Torokhov
wrote:
> On Wed, Jan 09, 2013 at 08:07:45AM +0100, Thierry Reding wrote:
> > On Sun, Jan 06, 2013 at 11:57:48AM -0800, Dmitry Torokhov wrote:
> > > On Sun, Jan 06, 2013 at 08:27:39PM +0100, Thierry Reding wrote:
> > > > On Sat, Jan 05, 2013 at 12
On Tue, 5 Feb 2013 18:15:54 +0100, Linus Walleij
wrote:
> On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
>
> > This makes the code both simpler and faster compared to parsing the GPIO
> > number space.
> >
> > Signed-off-by: Alexandre Courbot
>
> Reviewed-by: Linus Walleij
Applied
On Tue, 5 Feb 2013 18:04:43 +0100, Linus Walleij
wrote:
> On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
>
> > Use the small list of GPIO chips instead of parsing the whole GPIO
> > number space.
> >
> > Signed-off-by: Alexandre Courbot
>
> Reviewed-by: Linus Walleij
>
Applied, t
On Sun, 3 Feb 2013 01:29:31 +0900, Alexandre Courbot
wrote:
> Parse the list of chips to find the descriptor corresponding to a GPIO
> number instead of directly picking the entry of the global gpio_desc[]
> array, which is due to be removed.
>
> This turns the complexity of converting a GPIO n
On Thu, 7 Feb 2013 15:57:32 +0900, Alexandre Courbot
wrote:
> On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij
> wrote:
> > On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot
> > wrote:
> >> +/**
> >> + * Convert a GPIO number to its descriptor
> >> + */
> >> +static struct gpio_desc *gpio_to_des
On Tue, 5 Feb 2013 18:05:32 +0100, Linus Walleij
wrote:
> On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
>
> > Using the GPIO chips list is much faster than parsing the entire GPIO
> > number space.
> >
> > Signed-off-by: Alexandre Courbot
>
> You don't say :-)
> Reviewed-by: Linus
On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
> +static int elm_suspend(struct device *dev)
> +{
> + struct elm_info *info = dev_get_drvdata(dev);
> + wait_queue_head_t wq;
> + DECLARE_WAITQUEUE(wait, current);
> +
> + init_waitqueue_head(&wq);
> + while (1) {
The debugfs files really need to hold the gpiolib spinlock before
accessing the list. Otherwise chip addition/removal will cause an oops.
Cc: Alexandre Courbot
Cc: Linus Walleij
Signed-off-by: Grant Likely
---
drivers/gpio/gpiolib.c | 12 +---
1 file changed, 9 insertions(+), 3 delet
On Fri, Feb 08, 2013 at 11:08:52AM -0800, H. Peter Anvin wrote:
> Yes, or anything else getting a pointer in memory from user space.
Here are some more from a 32-bit build here:
fs/exec.c: In function ‘get_user_arg_ptr’:
fs/exec.c:414:6: warning: cast to pointer from integer of different size
[-
On Sat, Feb 09, 2013 at 10:41:21AM +0100, Borislav Petkov wrote:
> > +static inline bool phys_addr_is_highmem(phys_addr_t addr)
> > +{
> > + return addr > last_lowmem_paddr();
>
> I think you mean last_lowmem_phys_addr() here:
>
> include/linux/mm.h: In function ‘phys_addr_is_highmem’:
> includ
On 02/05/2013 02:07 PM, Grant Likely wrote:
> On Sun, 27 Jan 2013 03:33:59 +, Mark Brown
> wrote:
>> On Wed, Jan 09, 2013 at 06:31:09PM +0100, Lars-Peter Clausen wrote:
>>
>>> The second function spi_sync_transfer() takes a SPI device and an array of
>>> spi_transfers. It will allocate a new
On Sat, Feb 09, 2013 at 11:41:42AM +0100, Borislav Petkov wrote:
> On Fri, Feb 08, 2013 at 11:08:52AM -0800, H. Peter Anvin wrote:
> > Yes, or anything else getting a pointer in memory from user space.
>
> Here are some more from a 32-bit build here:
>
> fs/exec.c: In function ‘get_user_arg_ptr’:
On Saturday 09 February 2013 02:57:18 Anton Vorontsov wrote:
>
> Hm. The documentation says tenth (1/10) degrees, and you even
> restate it in the commit message. But the subject, and your
> example seem to prove that you still report it in 1/100 of
> Celsius.
>
> Unless your phone was on fire du
On 02/06/2013 07:20 PM, Jonathan Cameron wrote:
> On 02/05/2013 02:07 PM, Grant Likely wrote:
>> On Sun, 27 Jan 2013 03:33:59 +, Mark Brown
>> wrote:
>>> On Wed, Jan 09, 2013 at 06:31:09PM +0100, Lars-Peter Clausen wrote:
>>>
The second function spi_sync_transfer() takes a SPI device and
Rolland, All,
On Saturday 09 February 2013 Roland Eggner wrote:
> On 2013-02-09 Saturday at 01:30 +0100 Yann E. MORIN wrote:
[--SNIP--]
> > > +"Text Box (Help Window)\n"
> > > +"--\n"
> > > +"Use movement keys as
> > > listed in\n"
> > > +"table above.\n"
> >
> > ... ke
Rolland, All,
On Saturday 09 February 2013 Roland Eggner wrote:
> On 2013-02-09 Saturday at 02:03 +0100 Yann E. MORIN wrote:
> > On Friday 01 February 2013 Roland Eggner wrote:
> > > Add vi-style navigation keys, based on initial work by Dmitry Voytik.
> >
> > As much I am a unconditional vim use
On Saturday, February 09, 2013 07:40:26 AM Viresh Kumar wrote:
> On 9 February 2013 05:38, Dirk Brandewie wrote:
> > On 02/08/2013 03:56 PM, Rafael J. Wysocki wrote:
> >>
> >> On Friday, February 08, 2013 09:02:37 PM Rafael J. Wysocki wrote:
> >>>
> >>> On Friday, February 08, 2013 08:06:52 PM Vir
Martin Sustrik wrote:
> On 09/02/13 04:54, Eric Wong wrote:
> >>>Using one eventfd per userspace socket still seems a bit wasteful.
> >>
> >>Wasteful in what sense? Occupying a slot in file descriptor table?
> >>That's the price for having the socket uniquely identified by the
> >>fd.
> >
> >Yes.
On 2013-02-09 12:51, Eric Wong wrote:
Yes, your eventfd change is probably the best way if you want/need
to only watch a subset of your sockets, especially if you want
poll/select to be an option.
Yes, the poll/select thing is the important point.
I wouldn't care if the only problem was that
At Thu, 7 Feb 2013 16:56:56 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.7.7 release.
> There are 34 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
At Thu, 7 Feb 2013 16:57:59 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.0.63 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
At Thu, 7 Feb 2013 16:57:28 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.30 release.
> There are 26 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
On Friday 08 February 2013, Hiroshi Doyu wrote:
> > > +#if defined(CONFIG_ARCH_TEGRA_3x_SOC)
> >
> > how about using:
> >
> > #if IS_BUILTIN(CONFIG_ARCH_TEGRA_3x_SOC)
> >
> > instead ?
>
> Why is IS_BUILTIN() prefered?
>
Inside of a function, if(IS_ENABLED(CONFIG_FOO)) or the respective IS_BUILT
This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock
On Sat, Feb 9, 2013 at 3:42 PM, Michel Lespinasse wrote:
> On Fri, Feb 8, 2013 at 11:30 PM, Hillf Danton wrote:
>> On Sat, Feb 9, 2013 at 10:45 AM, Michel Lespinasse wrote:
>>> + if (waiter->type != RWSEM_WAITING_FOR_WRITE) {
>>> + list_del(&waiter->list);
>>>
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot
wrote:
> Make sure gpiolib works internally with descriptors and (chip, offset)
> pairs instead of using the global integer namespace. This prepares the
> ground for the removal of the global gpio_desc[] array and the
> introduction of the des
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot
wrote:
> Make sure gpiolib works internally with descriptors and (chip, offset)
> pairs instead of using the global integer namespace. This prepares the
> ground for the removal of the global gpio_desc[] array and the
> introduction of the des
On Tue, 5 Feb 2013 19:00:09 +0100, Linus Walleij
wrote:
> On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
>
> > Add a pointer to the gpio_chip structure that references the array of
> > GPIO descriptors belonging to the chip, and update gpiolib code to use
> > this pointer instead of t
On Fri, 18 Jan 2013 17:58:22 +1300, Tony Prisk wrote:
> This driver is missing a .remove callback, and the fail path on
> probe is incomplete.
>
> If an error occurs in vt8500_add_chips, gpio_base is not unmapped.
> The driver is also ignoring the return value from this function so
> if a chip fa
Em Sat, 09 Feb 2013 01:45:42 +0100
Sebastian Hesselbarth escreveu:
> On 02/09/2013 01:03 AM, Mauro Carvalho Chehab wrote:
> > Em Fri, 8 Feb 2013 21:38:07 +0100
> > Sebastian Hesselbarth escreveu:
> >
> >> This patch adds device tree parsing for gpio_ir_recv platform_data and
> >> the mandatory
On Mon, 21 Jan 2013 16:22:21 +0530, Viresh Kumar
wrote:
> On Mon, Jan 21, 2013 at 3:39 PM, Thierry Reding
> wrote:
> > diff --git a/drivers/gpio/gpio-spear-spics.c
> > b/drivers/gpio/gpio-spear-spics.c
> > index 5f45fc4..7a4bf7c 100644
> > --- a/drivers/gpio/gpio-spear-spics.c
> > +++ b/drivers
On Sat, Feb 9, 2013 at 6:37 PM, Grant Likely wrote:
> However, this code is incorrect (it was incorrect before you touched it,
> so not your fault). Moving it to a list makes it a lot worse though
> because it introduces the possibility of dereferencing an invalid
> pointer. The hooks need to grab
On Mon, 21 Jan 2013 11:08:53 +0100, Thierry Reding
wrote:
> Recent discussions about the lack of a meaningful error code returned by
> devm_request_and_ioremap() have triggered this patch series. One common
> issue is that the function returns NULL in all failure cases, making it
> impossible to
On Tue, 15 Jan 2013 10:42:55 +0100, Linus Walleij
wrote:
> From: Linus Walleij
>
> The AB8500 GPIO driver has been marked BROKEN for ages, and we
> have something better in store: a shiny new pinctrl driver. So
> let use delete this old driver as the first step.
>
> Signed-off-by: Linus Wallei
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, February 06, 2013 2:13 PM
> To: KY Srinivasan
> Cc: x...@kernel.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com;
> t...
On Thu, 20 Dec 2012 10:23:28 +0100, Linus Walleij
wrote:
> On Thu, Dec 20, 2012 at 9:57 AM, Jean-Nicolas Graux
> wrote:
>
> > Provides support for 1801 variant of stmpe gpio port expanders.
> > This chip has 18 gpios configurable as GPI, GPO, keypad matrix,
> > special key or dedicated key func
On Thu, 10 Jan 2013 14:09:35 +0100, Peter Ujfalusi
wrote:
> Hi Linus,
>
> On 01/10/2013 11:41 AM, Linus Walleij wrote:
> > On Thu, Dec 20, 2012 at 10:44 AM, Peter Ujfalusi
> > wrote:
> >
> >> Use more coherent locking in the driver. Use bitfield to store the GPIO
> >> direction and if the pin
On Sat, Feb 9, 2013 at 10:11 PM, Grant Likely wrote:
> I've been thinking about the adding of a new API to supplant the old,
> and I'm wondering if we're going about this the wrong way around; at
> least for the public api. We've moved to a model where device drivers
> are really supposed to tread
On Sat, Feb 9, 2013 at 10:24 PM, Grant Likely wrote:
> On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot
> wrote:
>> Make sure gpiolib works internally with descriptors and (chip, offset)
>> pairs instead of using the global integer namespace. This prepares the
>> ground for the removal of t
On Thu, 31 Jan 2013 01:48:01 +1100, Stephen Rothwell
wrote:
> Hi Kukjin,
>
> Today's linux-next merge of the samsung tree got a conflict in
> drivers/gpio/gpio-samsung.c between commits f69254328793 ("ARM: dts: Fix
> compatible value of pinctrl module on EXYNOS5440") and b533c8685b16
> ("ARM: dt
On Sat, Feb 9, 2013 at 6:58 PM, Grant Likely wrote:
> I'm actually going to NAK this one. This is a hot path. Having a O(1)
> lookup from gpio number to gpio desc is important. I know you want to be
> rid of the gpio_desc table entirely, but in this case I think it is
> warranted. However, you can
On Wed, 6 Feb 2013 10:31:04 +0100, Lars Poeschel wrote:
> On Tuesday 05 February 2013 at 15:29:09, Grant Likely wrote:
> > On Thu, 31 Jan 2013 21:51:36 +0100, Linus Walleij
> wrote:
> > > On Thu, Jan 31, 2013 at 4:58 PM, Lars Poeschel
> wrote:
> > > > --- /dev/null
> > > > +++ b/Documentation/
From: Rafael J. Wysocki
In order to drop reference counts of all power resources used by an
ACPI device node being removed, acpi_device_unregister() calls
acpi_power_transition(device, ACPI_STATE_D3_COLD), which effectively
transitions the device node into D3cold if it uses any power
resources.
From: Rafael J. Wysocki
The ACPI scan lock has been introduced to prevent acpi_bus_scan()
and acpi_bus_trim() from running in parallel with each other for
overlapping ACPI namespace scopes. However, it is not sufficient
to do that, because if acpi_bus_scan() is run (for an overlapping
namespace
Hi,
The following two patches fix issues I've found revently in the ACPI device
hot-removal code.
Patch [1/2] makes acpi_bus_hot_remove_device() hold acpi_scan_lock around the
whole removal procedure to prevent potential race condition between
acpi_bus_scan() and a conflicting evaluation of _EJ0
On Wed, 6 Feb 2013 18:01:57 +0100, Lars Poeschel
wrote:
> From: Lars Poeschel
>
> Explicitly allow -1 as a legal value for the
> mcp23s08_platform_data->base. This is the special value lets the
> kernel choose a valid global gpio base number.
>
> Signed-off-by: Lars Poeschel
> ---
> drivers
On Wed, 6 Feb 2013 18:01:58 +0100, Lars Poeschel
wrote:
> From: Lars Poeschel
>
> This converts the mcp23s08 driver to be able to be used with device
> tree.
> There is a special "mcp,chips" property, that correspond to the chips
> member of the struct mcp23s08_platform_data. It can be used fo
On Sat, Feb 9, 2013 at 2:21 PM, Alexandre Courbot wrote:
> On Sat, Feb 9, 2013 at 6:58 PM, Grant Likely
> wrote:
>> I'm actually going to NAK this one. This is a hot path. Having a O(1)
>> lookup from gpio number to gpio desc is important. I know you want to be
>> rid of the gpio_desc table enti
On Wed, 30 Jan 2013 13:28:41 +0100, Andreas Larsson wrote:
> This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP core
> library.
>
> Signed-off-by: Andreas Larsson
Have you looked at drivers/gpio/gpio-generic.c? This looks to me like
yet another memory mapped gpio controller t
On Sat, 2013-02-09 at 20:39 +0800, Fengguang Wu wrote:
> Greetings,
>
> I got the below oops in linux-next and the first bad commit is
>
> commit 455e987c0c2eb2c9045dc854559474cf41509965
> Merge: 7c17e48 fd6da69
> Author: Linus Torvalds
> Date: Sat Dec 1 13:07:48 2012 -0800
>
> Merge bran
On Tue, 5 Feb 2013 11:33:02 +0100, Andreas Larsson wrote:
> The swap to convert LE to BE in bgpio_pin2mask_be should be on byte level, not
> on bit level.
>
> Signed-off-by: Andreas Larsson
> ---
> drivers/gpio/gpio-generic.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
From: Namjae Jeon
This patch set eliminates the client side ESTALE errors when a FAT partition
exported over NFS has it's dentries evicted from the cache. The idea is to
find the on-disk location_'i_pos' of the dirent of the inode that has been
evicted and use it to rebuild the inode.
Change log
From: Namjae Jeon
Provide two possible values 'stale_rw' and 'nostale_ro' for
the -o nfs mount option.The first one allows all file operations but
does not reduce ESTALE errors on memory constrained systems. The second
one eliminates ESTALE errors but mounts the filesystem as
read-only. Not speci
From: Namjae Jeon
Move fat_i_pos_read to fat.h so that it can be called from nfs.c in the
subsequent patches to encode the file handle.
Signed-off-by: Namjae Jeon
Signed-off-by: Ravishankar N
Signed-off-by: Amit Sahrawat
---
fs/fat/fat.h | 14 ++
fs/fat/inode.c | 14 ---
From: Namjae Jeon
Introduce helper function to get the block number and offset for a given
i_pos value. Use it in __fat_write_inode() now and later on in nfs.c
Signed-off-by: Namjae Jeon
Signed-off-by: Ravishankar N
Signed-off-by: Amit Sahrawat
---
fs/fat/fat.h |7 +++
fs/fat/inode
From: Namjae Jeon
Define two nfs export_operation structures,one for 'stale_rw' mounts and
the other for 'nostale_ro'.The latter uses i_pos as a basis for encoding
and decoding file handles.
Also, assign i_pos to kstat->ino.The logic for rebuilding the inode is
added in the subsequent patches.
From: Namjae Jeon
If the cache lookups fail,use the i_pos value to find the
directory entry of the inode and rebuild the inode.Since this
involves accessing the FAT media, do this only if the nostale_ro nfs
mount option is specified.
Signed-off-by: Namjae Jeon
Signed-off-by: Ravishankar N
Sign
From: Namjae Jeon
This patch enables rebuilding of directory inodes which are not present
in the cache.This is done by traversing the disk clusters to find the
directory entry of the parent directory and using its i_pos to build the
inode.
The traversal is done by fat_scan_logstart() which is si
From: Namjae Jeon
Add descriptions about 'stale_rw' and 'nostale_ro' nfs options in
filesystem/vfat.txt
Signed-off-by: Namjae Jeon
Signed-off-by: Ravishankar N
Signed-off-by: Amit Sahrawat
---
Documentation/filesystems/vfat.txt | 26 +-
1 file changed, 21 insertions
On Sat, 2013-02-09 at 18:10 +0400, Alexey Vlasov wrote:
> Hello.
>
> I used 2.6.2x kernel for a long time on my shared hosting and I didn't
> have any problems. Kernels worked well and server uptime was about 2-3
> years.
>
> But investigating some strange hangings of my clients' sites I came to
On Sat, Feb 9, 2013 at 1:29 AM, Borislav Petkov wrote:
> On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote:
>> Also, _reading_ MSRs from userspace arguably has utility that doesn't
>> compromise ring-0.
>
> And to come back to the original question: what is that utility, who
> would need i
On Sat, 2013-02-09 at 10:29 +0100, Borislav Petkov wrote:
> On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote:
> > Also, _reading_ MSRs from userspace arguably has utility that doesn't
> > compromise ring-0.
>
> And to come back to the original question: what is that utility, who
> would n
On Sat, Feb 09, 2013 at 07:07:53AM -0800, Eric Dumazet wrote:
> Did you compile the kernel yourself, or is it a standard kernel (distro
> provided) ?
>
> Your traces dont contain symbols, its quite hard to guess the issue.
I compile the kernel myself. Should I add CONFIG_DEBUG_INFO ? ok then
I'll
Hi Matt,
This version introduces build/bisect issues.
On 2/1/2013 11:52 PM, Matt Porter wrote:
> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx) as well.
>
> Signed-off-by: Matt Porter
> Acked-by: Sekhar Nori
> diff --git a/arch/arm/mach-davinci/dma.
Alex, this is broken when the sysfs interface isn't enabled. Can you
send a fixup patch?
g.
On Sat, Feb 9, 2013 at 3:41 PM, kbuild test robot
wrote:
> tree: git://git.secretlab.ca/git/linux-2.6.git gpio/next
> head: 8a307b35962e42de0f998c6029e8851c61eadb4e
> commit: 5bb47609e8167d733786cb781
Am 08.02.2013 16:48, schrieb Will Deacon:
> On Wed, Feb 06, 2013 at 11:01:23PM +, André Hentschel wrote:
>> Am 06.02.2013 23:51, schrieb Russell King - ARM Linux:
>>> On Wed, Feb 06, 2013 at 11:43:10PM +0100, André Hentschel wrote:
There are more and more applications coming to WinRT, Wine
do_initcalls() could call all driver initialization code in kernel_init
thread. It means that probe() function will be also called from that
time. After this, kernel could access console & release __init section
in the same thread.
But if device probe fails and moves into deferred probe list, a ne
To allow both of protocol-specific data and device-specific data
attached with neighbour entry, and to eliminate size calculation
cost when allocating entry, sizeof protocol-speicic data must be
multiple of NEIGH_PRIV_ALIGN. On 64bit archs,
sizeof(struct dn_neigh) is multiple of NEIGH_PRIV_ALIGN,
Eric Dumazet wrote:
> On Sat, 2013-02-09 at 20:39 +0800, Fengguang Wu wrote:
>> Greetings,
>>
>> I got the below oops in linux-next and the first bad commit is
>>
>> commit 455e987c0c2eb2c9045dc854559474cf41509965
>> Merge: 7c17e48 fd6da69
>> Author: Linus Torvalds
>> Date: Sat Dec 1 13:07:48 20
On 02/09/2013 01:45 AM, Sebastian Hesselbarth wrote:
new file mode 100644
index 000..8589f30
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible = "gpio-ir-receiver"
On 02/08/2013 03:20 PM, Darren Hart wrote:
> The current probe aborts if any of the 3 base address registers are
> disabled. On a TunnelCreek system I am working on, this resulted in the
> SMBIOS and GPIO devices being removed when it couldn't read the base
> address for the watchdog timer.
>
> Th
Hi Benson,
> This patch adds support for the Cypress APA Smbus Trackpad type,
> which uses a modified register map that fits within the
> limitations of the smbus protocol.
>
> Devices that use this protocol include:
> CYTRA-116001-00 - Samsung Series 5 550 Chromebook trackpad
> CYTRA-103002-00 -
On 2/8/2013 8:34 AM, Kumar, Anil wrote:
> On Thu, Feb 07, 2013 at 23:45:53, Nori, Sekhar wrote:
>> On 2/6/2013 9:30 AM, Kumar, Anil wrote:
>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
>>> b/arch/arm/mach-davinci/devices-da8xx.c
>>> index 2d5502d..1df68fd 100644
>>> --- a/arch/arm/mach
Hi Daniel,
> A recent patch refactored i2c error handling in the register read/write
> path. This adds similar handling to the other i2c paths used in fw_update
> and bootloader state detection.
>
> The generic i2c layer can return values indicating a partial transaction.
> From the atmel_mxt dr
On Sat, 9 Feb 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.8-rc7 to v3.8-rc6[3], the summaries are:
> - build errors: +7/-8
> [1] http://kisskb.ellerman.id.au/kisskb/head/5870/ (all 117 configs)
Ignoring the ppc truncated relocations:
+ error: tpm_ibmvtpm.c: undefined reference t
Hi!
> > The only way to *reliably* freeze fuse filesystems is to let it freeze
> > even if there are outstanding requests. But that's the hardest to
> > implement, because then it needs to allow freezing of tasks waiting on
> > i_mutex, for example, which is currently not possible. But this is
>
s390 allmodconfig:
drivers/gpu/drm/udl/udl_fb.c:237:52: error: 'PAGE_SHARED' undeclared (first use
in this function)
drivers/media/pci/zoran/zoran_driver.c:2955:14: error: 'PAGE_SHARED' undeclared
(first use in this function)
drivers/media/usb/cpia2/cpia2_core.c:2405:66: error: 'PAGE_SHARED' und
On Fri, Feb 08, 2013 at 11:04:54PM +0100, Stephan Mueller wrote:
> * an array of statistical test suites pass the output of the entropy
> collector
> (again, the output is not mangled with cryptography)
You're not mangling the output with cryptography, but you are doing
some mangling in jitteren
You do realize that none of your arguments touched the "why should
Linus merge the tree" question at all?
Everything you said was about how it's more convenient for you and
Ingo, not at all about why it should be better for anybody else. You
haven't bothered to even try making it an external proje
CCing containers list
On Fri, 08 February 2013 miny...@acm.org wrote:
> From: Corey Minyard
>
> The console redirect - ioctl(fd, TIOCCONS) - is not in a namespace,
> thus a container can do a redirect and grab all the I/O on the host
> and all container consoles.
>
> This change puts the redire
On 02/08, Michael Kerrisk (man-pages) wrote:
>
> On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov wrote:
> >
> > Well. I do not know. Up to you and Michael.
> >
> > But honestly, I can't say this all looks really nice. And why do we
> > need SIGNALFD_PEEK then?
>
> It surely is no beauty. The hope is
Hi Imre!
On Sat, Feb 09, 2013 at 05:27:33PM +0200, Imre Deak wrote:
> Add a helper to walk through a scatter list a page at a time. Needed by
> upcoming patches fixing the scatter list walking logic in the i915 driver.
Nice patch, but I think this would make a rather nice addition to the
common s
Hi James,
On Fri, 8 Feb 2013 17:32:15 -0800, James Ralston wrote:
> This patch adds the SMBus Device IDs for the Intel Wellsburg PCH
>
> Signed-off-by: James Ralston
> ---
> Documentation/i2c/busses/i2c-i801 |1 +
> drivers/i2c/busses/Kconfig|1 +
> drivers/i2c/busses/i2c-i801.
Hello,
On Fri, Feb 08, 2013 at 10:09:13PM +, Hefty, Sean wrote:
> > Used to wrap cyclic @start. Can be replaced with max(next, 0).
> > Note that this type of cyclic allocation using idr is buggy. These
> > are prone to spurious -ENOSPC failure after the first wraparound.
>
> The repla
Hello, Hillf.
On Fri, Feb 08, 2013 at 11:39:56AM +0800, Hillf Danton wrote:
> The comment just above cpu_stop_signal_done() says it is uncertain that
> the input @done is valid, and the works enqueued through the function
> stop_one_cpu_nowait() do carry no done, thus we have to check if it is
> v
Hello, again.
On Fri, Feb 08, 2013 at 11:42:43AM +0800, Hillf Danton wrote:
> As checked with BUG_ON in the case of CPU_UP_PREPARE, we have to dequeue
> work first for further actions, then stopper reaches sane and clear state.
When a CPU is finally put down in either CPU_UP_CANCELLED or
CPU_POST
On Mon, Jan 28, 2013 at 12:02:27AM +0300, Stanislav Yakovlev wrote:
> Hello, Tejun,
>
> On 22 December 2012 04:56, Tejun Heo wrote:
> > * Drop unnesssary delayd_work_pending() tests.
> >
> > * Unify scan_event_{now|later} by using mod_delayed_work() w/ 0 delay
> > for scan_event_now.
> >
> > *
On Tue, Jan 29, 2013 at 08:53:18PM +0900, Masami Hiramatsu wrote:
> >> Acked-by: Masami Hiramatsu
> >
> > Can I take it through workqueue branch w/ other patches?
>
> Yes, of course. I think it is not a critical bug, so I can
> wait for other patches.
Applied to wq/for-3.9-cleanups.
Thanks!
-
On Fri, Jan 04, 2013 at 03:19:55PM -0600, Dan Williams wrote:
> On Fri, 2012-12-21 at 17:57 -0800, Tejun Heo wrote:
> > i2400m_net_wake_tx() sets ->wake_tx_skb with the given skb if
> > ->wake_tx_ws is not pending; however, i2400m_wake_tx_work() could have
> > just started execution and haven't fet
On Sat, Feb 9, 2013 at 8:07 PM, Linus Torvalds
wrote:
> Everything you said was about how it's more convenient for you and
> Ingo, not at all about why it should be better for anybody else. You
> haven't bothered to even try making it an external project, so it
> doesn't compile that way. You're t
From: Borislav Petkov
Ok,
here's the next version with new_cpu_data left put and two minor fixlets
added at the end. The patchset was boot-tested on a bunch of baremetal
boxes and all QEMU cpu models - no issues.
Boot tests:
* baremetal:
- P4
- Atom n270
- 32-bit kernel on an AMD64 (F10h Phen
From: Borislav Petkov
We do that once earlier now and cache it into new_cpu_data.cpuid_level
so no need for the EFLAGS.ID toggling dance anymore.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/
From: Borislav Petkov
Jumping here we are about to enable paging so rename the label
accordingly.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/head_32.S | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
1 - 100 of 174 matches
Mail list logo
