* Paul Bolle [150304 14:58]:
> Nishanth Menon schreef op di 03-03-2015 om 18:00 [-0600]:
> > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> > index ee9f44ad7f02..8e463d75fbb2 100644
> > --- a/drivers/pinctrl/Kconfig
> > +++ b/drivers/pinctrl/Kconfig
> > @@ -160,6 +160,17 @@ confi
On Wed, 4 Mar 2015, Alex Dowad wrote:
> The 'stack_size' argument is never used to pass a stack size. It's only used
> when
> forking a kernel thread, in which case it is an argument which should be
> passed
> to the 'main' function which the kernel thread executes. Hence, rename it to
> 'kthrea
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/mtd/vf610-nfc.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
diff --git a/Documentation/devicetree/bindings
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf-colibri.dtsi | 31 +
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages).
Signed-off-by: Bill Pringlemeir
Signed-off-by:
This adds support for Freescale NAND flash controller (NFC) found on
various devices such as Vybrid (VF610), MPC5125, MCF54418 (ColdFire)
and Kinetis K70.
The patchset is based on the patchset by Bill Pringlemeir, see:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/295419
A variant of this
On Mon, Mar 02, 2015 at 04:21:06PM +0100, Valentin Rothberg wrote:
> Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
> bogus threaded irq requests") threaded IRQs without a primary handler
> need to be requested with IRQF_ONESHOT, otherwise the request will fail.
>
> Current
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.
Signed-off-by: Bill Pri
This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70.
Limitations:
- DMA and pipelining not used
- Pages larger than 2k are not supported
- No hardware ECC
The driver has only been tested on Vybrid (VF610).
Signed-off-by: Bill Prin
> - fixed AR and UC order in enum severity_level because UC is severer than AR
> by definition. Current code is not affected by this wrong order by chance.
AR and AO are both UC errors - that happen also to be recoverable. Are you
really sure
about this re-order not affecting existing code? Yo
Hi Florian,
On 15-03-02 03:50 PM, Florian Fainelli wrote:
Unless there is a re-spin, I will fix this myself while applying this
patch to devicetree/next.
Thanks
Yes, you can patch the formatting if the driver is being integrated.
But I have had no response or feedback on the sdhci driver. I
On Mon, Mar 2, 2015 at 6:58 AM, Baoquan He wrote:
> @@ -455,17 +455,16 @@ unsigned char *choose_kernel_location(struct
> boot_params *params,
>output_size);
you forgot to change
/* Record the various known unsafe memory ranges. */
mem_avoid_init((unsigne
On Wed, 2015-03-04 at 23:09 +0100, Ingo Molnar wrote:
> * Toshi Kani wrote:
:
> Hm, so I don't see where you set the proper x86 PAT table attributes
> for the pmds.
>
> MTRR's are basically a legacy mechanism, the proper way to set cache
> attribute is PAT and I don't see where this generic co
On 02/27/2015 02:50 AM, Ard Biesheuvel wrote:
Are you not seeing this on v4.0-rc1 without the patchset applied?
Could the crash be inside the subsequent call to
SetVirtualAddressMap() instead of inside ExitBootServices()?
If so, you have a firmware bug: Mark Rutland spotted a similar bug in
the
Alexandre Belloni schreef op wo 04-03-2015 om 15:47 [+0100]:
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -1,51 +1,22 @@
> -if ARCH_AT91
> -
> -config HAVE_AT91_UTMI
> - bool
> -
> -config HAVE_AT91_USB_CLK
> - bool
> -
> -config COMMON_CLK_AT91
> - bool
>
On 2015-03-02 16:53, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Mar 02, 2015 at 02:42:01PM +0100, Stefan Agner wrote:
>> On 2015-03-02 13:59, Uwe Kleine-König wrote:
>> > On Mon, Mar 02, 2015 at 07:45:17PM +0800, Shawn Guo wrote:
>> >> On Fri, Feb 06, 2015 at 05:30:56PM +0100, Stefan Agner wrote
This patch adds an additional feature to the firmware_class.c module.
To allow a unified method of specifying new firmware locations when
drivers request a firmware binary to update their devices with, we
have added the concept of a "fw override"
A fw override is a rule that matches firmware reque
Toshi Kani schreef op di 03-03-2015 om 16:48 [-0700]:
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -99,6 +99,7 @@ config X86
> select IRQ_FORCED_THREADING
> select HAVE_BPF_JIT if X86_64
> select HAVE_ARCH_TRANSPARENT_HUGEPAGE
> + select HAVE_ARCH_HUGE_VMAP if X86_64
* Dave Chinner wrote:
> > After going through the series again, I did not spot why there is
> > a difference. It's functionally similar and I would hate the
> > theory that this is somehow hardware related due to the use of
> > bits it takes action on.
>
> I doubt it's hardware related - I'm
On 05/03/2015 at 00:21:47 +0100, Paul Bolle wrote :
> > +config ARCH_AT91
> > + select ARCH_REQUIRE_GPIOLIB
> > select COMMON_CLK_AT91
> > - select CPU_V7
> > + select CLKDEV_LOOKUP
> > select GENERIC_CLOCKEVENTS
> > - select MEMORY
> > - select ATMEL_SDRAMC
> > - select PHYLIB
On Thu, 2015-03-05 at 00:31 +0100, Paul Bolle wrote:
> Toshi Kani schreef op di 03-03-2015 om 16:48 [-0700]:
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -99,6 +99,7 @@ config X86
> > select IRQ_FORCED_THREADING
> > select HAVE_BPF_JIT if X86_64
> > select HAVE_ARCH_TRAN
On 03/03/2015 11:06 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.71 release.
> There are 53 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.
>
> Responses s
On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.35 release.
> There are 73 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.
>
> Responses s
On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.9 release.
> There are 151 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.
>
> Responses s
On 03/04/15 at 03:16pm, Yinghai Lu wrote:
> On Mon, Mar 2, 2015 at 6:58 AM, Baoquan He wrote:
>
> > @@ -455,17 +455,16 @@ unsigned char *choose_kernel_location(struct
> > boot_params *params,
> >output_size);
>
> you forgot to change
>
> /* Record the various kn
On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.19.1 release.
> There are 175 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.
>
> Responses s
On 25 February 2015 at 02:16, Alex Williamson
wrote:
> vga_set_legacy_decoding() is defined in drivers/gpu/vga/vgaarb.c,
> which is only compiled with CONFIG_VGA_ARB. A caller would
> therefore get an undefined symbol if the VGA arbiter is not
> enabled.
Acked-by: Dave Airlie
> Signed-off-by:
On 03/04/15 at 01:28pm, Kees Cook wrote:
> On Mon, Mar 2, 2015 at 6:58 AM, Baoquan He wrote:
> > -static unsigned long find_random_addr(unsigned long minimum,
> > +static unsigned long find_random_phy_addr(unsigned long minimum,
> > unsigned long size)
> > {
Alexandre Belloni schreef op do 05-03-2015 om 00:35 [+0100]:
> On 05/03/2015 at 00:21:47 +0100, Paul Bolle wrote :
> > Utterly trivial, but anyhow. Could you please make this
> > bool
> >
> > line to be the line directly following the line reading
> > config ARCH_AT91
> >
> > above?
>
>
On Wed, 2015-03-04 at 09:06 -0700, Alex Williamson wrote:
> Hi,
>
> I'm getting a regression from this patch when using VFIO for device
> assignment to a QEMU VM. I have a device initially bound to the nouveau
> driver, which is unbound from that driver and bound to vfio-pci for use
> by userspac
On 2015/2/13 0:24, Rafael J. Wysocki wrote:
> On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
>>
>> Why bother with enter_freeze() for any but the deepest state (C6 in this
>> case)?
>
> User space may disable the deepest one (and any of them in general) via sysfs
> and there's no
On Thu, 2015-03-05 at 09:43 +1000, Dave Airlie wrote:
> On 25 February 2015 at 02:16, Alex Williamson
> wrote:
> > vga_set_legacy_decoding() is defined in drivers/gpu/vga/vgaarb.c,
> > which is only compiled with CONFIG_VGA_ARB. A caller would
> > therefore get an undefined symbol if the VGA arbi
On Thu, Mar 05, 2015 at 12:35:45AM +0100, Ingo Molnar wrote:
>
> * Dave Chinner wrote:
>
> > > After going through the series again, I did not spot why there is
> > > a difference. It's functionally similar and I would hate the
> > > theory that this is somehow hardware related due to the use
Commit-ID: 5eca7453d61003bf886992388f8cb407e6f0d051
Gitweb: http://git.kernel.org/tip/5eca7453d61003bf886992388f8cb407e6f0d051
Author: Wang Nan
AuthorDate: Fri, 27 Feb 2015 12:19:49 +0800
Committer: Ingo Molnar
CommitDate: Thu, 5 Mar 2015 00:47:29 +0100
x86/traps: Separate set_intr_gat
On Wed 04 Mar 11:35 PST 2015, Stephen Boyd wrote:
> On 03/02/15 20:25, Bjorn Andersson wrote:
> > + match = of_match_device(rpm_of_match, &pdev->dev);
> > + for (reg = match->data; reg->name; reg++) {
> > + vreg = devm_kmalloc(&pdev->dev, sizeof(*vreg), GFP_KERNEL);
> > + i
On Thursday, March 05, 2015 12:25:54 AM Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 10:49:25 PM G Gregory wrote:
> > On 4 March 2015 at 22:38, Rafael J. Wysocki wrote:
> > > On Wednesday, February 25, 2015 04:39:47 PM Hanjun Guo wrote:
> > >> From: Graeme Gregory
> > >>
> > >> ACPI 5.
On Thursday, March 05, 2015 07:50:26 AM Li, Aubrey wrote:
> On 2015/2/13 0:24, Rafael J. Wysocki wrote:
> > On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
> >>
> >> Why bother with enter_freeze() for any but the deepest state (C6 in this
> >> case)?
> >
> > User space may disable
On Sun, Mar 01, 2015 at 07:28:41PM +0100, AdrianRemonda wrote:
> I apologize for the wrong patch format.
> Should I contact the mantainer of the tool path and ask him where to add
> it? Or how should I proceed?
I am the relevant maintainer here. The main thing from my point of view
is to split t
On Wed, 2015-03-04 at 13:13 -0800, Kees Cook wrote:
>
> I had a question in the powerpc-specific change that may have gone unnoticed:
>
> Can mmap ASLR be safely enabled in the legacy mmap case here? Other archs
> use "mm->mmap_base = TASK_UNMAPPED_BASE + random_factor".
>
> Separate from this s
On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
> On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote:
>> From: Al Stone
>>
>> In preparation for later splitting out some of the arch-dependent code from
>> osl.c, clean up the errors reported by checkpatch.pl. They fell into these
On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
> This patch adds an additional feature to the firmware_class.c module.
> To allow a unified method of specifying new firmware locations when
> drivers request a firmware binary to update their devices with, we
> have added the concept
When performing an O_DIRECT write to a block device, a 'struct bio' is
allocated from a mempool.
There is only one mempool for all block devices so if a single block
device blocked indefinitely, the mempool could in theory be exhausted
and other block devices would be affected.
When mdmon needs to
Hi Al,
I wonder if you would consider these two patches.
They extend the functionality of mlockall(MCL_FUTURE) to apply
to memory allocations when performing O_DIRECT io.
i.e. The first read or write to an O_DIRECT file descriptor will,
if MCL_FUTURE is in effect, cache any allocated memory s
On Wed, Mar 04, 2015 at 04:41:51PM -0700, Shuah Khan wrote:
> On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.19.1 release.
> > There are 175 patches in this series, all will be posted as a response
> > to this one. If anyone has any iss
To be able to support RAID metadata operations in user-space, mdmon
(part of mdadm) sometimes needs to update the metadata on an array
before any future writes to the array are permitted. This is
particularly needed for recording a device failure.
If that array is being used for swap (and even to
If a machine-specific hook is not implemented for restart, poweroff,
or halt, fall back to halting secondary CPUs, disabling interrupts,
and spinning. In the case of restart, attempt to restart the system
via do_kernel_restart() (which will call any registered restart
handlers) before halting.
Si
On 19:23 Sun 08 Feb , Boris Brezillon wrote:
> The gpiochip_lock_as_irq call can fail and return an error, while the
> irq_startup is not expected to fail (returns an unsigned int which is not
> checked by irq core code).
>
> irq_request/release_resources functions have been created to address
On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote:
> On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
> > On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote:
> >> From: Al Stone
> >>
> >> In preparation for later splitting out some of the arch-dependent code from
> >> osl.c,
* Andrew Morton wrote:
> On Fri, 27 Feb 2015 17:01:32 -0500 Jason Baron wrote:
>
> >
> > >
> > > I don't really understand the need for rotation/round-robin. We can
> > > solve the thundering herd via exclusive wakeups, but what is the point
> > > in choosing to wake the task which has been
Hi there,
2015-03-04 14:52 GMT-07:00 Joseph Salisbury :
...
> + { KE_KEY, 0x140, { KEY_BRIGHTNESSDOWN } },
> + { KE_KEY, 0x141, { KEY_BRIGHTNESSUP } },
...
These two are not neccesary, as they may collide with "previous song"
and "playpause" in case Toshiba (or its manufacturers) deci
On Thu, Feb 26, 2015 at 03:40:20PM -0800, Bjorn Andersson wrote:
> As this is already being logged elsewhere we shouldn't spam the log
> unnecessarily upon EPROBE_DEFER.
Where exactly is this "elsewhere" you're thinking of? I suspect you
mean the core -EPROBE_DEFER logging but you don't say...
Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
introduced a regression in the handling of lease upgrade/downgrades.
In the event that we already have a lease on a file and are going to
either upgrade or downgrade it, we skip doing any list insertion or
deletion and skip t
On 03/04/2015 05:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote:
>> On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
>>> On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote:
From: Al Stone
In preparation for later splitting
On 2015/3/5 8:18, Rafael J. Wysocki wrote:
> On Thursday, March 05, 2015 07:50:26 AM Li, Aubrey wrote:
>> On 2015/2/13 0:24, Rafael J. Wysocki wrote:
>>> On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
Why bother with enter_freeze() for any but the deepest state (C6 in th
On (03/04/15 14:13), Andrew Morton wrote:
> > +static ssize_t zram_add_show(struct class *class,
> > + struct class_attribute *attr,
> > + char *buf)
> > +{
> > + int ret;
> > +
> > + mutex_lock(&zram_index_mutex);
> > + /* read operation on zram_add is - p
On Wed, Mar 4, 2015 at 1:35 PM, Yinghai Lu wrote:
> On Wed, Mar 4, 2015 at 7:39 AM, Baoquan He wrote:
>>
>> I got the reason and made a debug patch to fix it. Could you please
>> apply it on top of this patchset and try again? Then it will behave well
>> and just return 0x13c00 since no rando
Quoting Geert Uytterhoeven (2015-03-04 01:56:42)
> On Fri, Feb 27, 2015 at 6:42 PM, Stephen Boyd wrote:
> > The problem is the patch was written before struct clk_core moved into
> > the clk.c file and then applied after it moved. So before the move the
> > order of includes would cause the struct
Hello,
On (03/04/15 14:02), a...@linux-foundation.org wrote:
[..]
> +++ a/drivers/block/zram/zram_drv.c
> @@ -70,6 +70,27 @@ static inline struct zram *dev_to_zram(s
> return (struct zram *)dev_to_disk(dev)->private_data;
> }
>
> +static ssize_t compact_store(struct device *dev,
> +
Hello Sergey,
On Wed, Mar 04, 2015 at 11:16:39PM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> Make zram-contol/zram_add interface easier to use. Extend it to support
> read and write operations.
>
> Write operation remains the same:
>
> echo X > /sys/class/zram-control/zram_add
>
> will
* Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 08:26:33AM +0100, Ingo Molnar wrote:
> > Since most CPUs we care about have ERMS, wouldn't it be better to
> > patch in the actual memcpy_erms sequence into the primary memcpy()
> > function? It's just about 9 bytes AFAICT.
>
> Actually, most s
On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
> There's another problem with this of_parse_cb design. The regulator
> framework requires supplies to be registered before consumers of the
> supplies are registered. So when we register L23 we need to make sure
> it's supply is alread
On Wed, Mar 4, 2015 at 7:39 AM, Baoquan He wrote:
> Hi Yinghai,
>
> I got the reason and made a debug patch to fix it. Could you please
> apply it on top of this patchset and try again? Then it will behave well
> and just return 0x13c00 since no random is got.
>
the fix should be fold into yo
Hi,
On Wed, Feb 04, 2015 at 04:24:35PM -0800, Todd Brandt wrote:
> New power_supply driver at driver/power which interfaces with the
> axp20x mfd driver as a cell. Provides battery info, monitors for
> changes, and generates alerts on temperature and capacity issues
>
> Sebestian, please review t
Hello Sergey,
On Thu, Mar 05, 2015 at 09:18:45AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (03/04/15 14:02), a...@linux-foundation.org wrote:
> [..]
> > +++ a/drivers/block/zram/zram_drv.c
> > @@ -70,6 +70,27 @@ static inline struct zram *dev_to_zram(s
> > return (struct zram *)dev_to_
* Borislav Petkov wrote:
> > 2) in the future: we could actually do a (limited) re-link of the
> > kernel during bootup, and patch up the original copy_to_user call
> > sites directly to one of the three variants. Alternatives patching
> > done at the symbol level. Does current tool
Consolidate Broadcom pinctrl drivers into drivers/pinctrl/bcm/*
Signed-off-by: Ray Jui
---
drivers/pinctrl/Kconfig | 19 +--
drivers/pinctrl/Makefile |3 +--
drivers/pinctrl/bcm/Kconfig | 21 +
On Tue, Mar 03, 2015 at 08:02:51AM -0800, Bjorn Andersson wrote:
> rpm {
> compatible = "qcom,rpm-apq8960";
>
> regulators {
> compatible = "qcom,rpm-pm8921-regulators";
Oh, so what you're saying is that the pm8921 is not actually a MFD at
all? Why name it like a MFD c
This enables GPIO based phone hook detection for Broadcom BCM911360
phone factor board (bcm911360_entphn)
Signed-off-by: Ray Jui
---
arch/arm/boot/dts/bcm911360_entphn.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts
b/arch/arm/boot
This adds the initial support of the Broadcom Cygnus GPIO/PINCONF driver
that supports all 3 GPIO controllers on Cygnus including the ASIU GPIO
controller, the chipCommonG GPIO controller, and the always-on GPIO
controller. Basic PINCONF configurations such as bias pull up/down, and
drive strength
* Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 08:13:24AM +0100, Ingo Molnar wrote:
> > Btw., the x86 memset() variants are using this today, and I think this
> > is the most optimal jump-patching variant, even if it means a small
> > amount of code duplication between the copy_user varian
Document the GPIO/PINCONF device tree binding for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../bindings/pinctrl/brcm,cygnus-gpio.txt | 102
1 file changed, 102 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pi
This enables the IOMUX support for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Tested-by: Dmitry Torokhov
---
arch/arm/boot/dts/bcm-cygnus.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index ff5fb6a..1cbae
This enables all 3 GPIO controllers including the ASIU GPIO, the
chipcommonG GPIO, and the ALWAYS-ON GPIO, for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Tested-by: Dmitry Torokhov
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 33 +
1 file
This adds the initial driver support for the Broadcom Cygnus IOMUX
controller. The Cygnus IOMUX controller supports group based mux
configuration but allows certain pins to be muxed to GPIO individually
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Tested-by: Dmitry Torokhov
---
drivers/pi
Device tree binding documentation for Broadcom Cygnus IOMUX driver
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../bindings/pinctrl/brcm,cygnus-pinmux.txt| 132
1 file changed, 132 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinct
This patchset contains the pinmux (IOMUX) and GPIO/PINCONF support for
Broadcom Cygnus SoC.
The Cygnus IOMUX controller supports group based mux
configuration and allows certain pins to be muxed to GPIO function
individually. The IOMUX controller is supported by the pinctrl-cygnus-mux.c
driver.
C
Hi,
On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> Signed-off-by: Marek Belisko
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
> 1 file changed, 30 insertions(+)
DTS changes must go via omap-dt tree once the driver changes have been
merged.
--
On Tue, Mar 03, 2015 at 08:15:41AM -0800, Bjorn Andersson wrote:
> On Tue 03 Mar 04:50 PST 2015, Mark Brown wrote:
> > Why would the driver need to do that? I guess I'll see later on in the
> > series but the changelog should make that clear. Drivers aren't
> > supposed to ever need to look at t
Hello Andrew,
On Wed, Mar 04, 2015 at 02:02:02PM -0800, Andrew Morton wrote:
> On Wed, 4 Mar 2015 14:01:32 +0900 Minchan Kim wrote:
>
> > +static int zs_stats_size_show(struct seq_file *s, void *v)
> > +{
> > + int i;
> > + struct zs_pool *pool = s->private;
> > + struct size_class *class
On 03/05/2015 05:21 AM, Konrad Rzeszutek Wilk wrote:
>>> David assertion that better performance and scalbility can be gained
>>> with grant table locking and TLB flush avoidance is interesting - as
>>> 1). The grant locking is going in Xen 4.6 but not earlier - so when running
>>> on older hy
Hi,
On Wed, Feb 04, 2015 at 11:14:32PM +0100, Marek Belisko wrote:
> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
> + for charging calibration (see example)
> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
> + for discharging calibrati
On Wed, Mar 04, 2015 at 03:57:09PM -0800, Greg KH wrote:
> On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
> > This patch adds an additional feature to the firmware_class.c module.
> > To allow a unified method of specifying new firmware locations when
> > drivers request a firmware
* Jiri Slaby wrote:
> On 02/24/2015, 10:16 AM, Ingo Molnar wrote:
> >
> > and we don't design the Linux kernel for weird, extreme cases, we
> > design for the common, sane case that has the broadest appeal, and
> > we hope that the feature garners enough interest to be
> > maintainable.
>
>
(2015/03/04 22:17), Petr Mladek wrote:
> On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
>> It's possible for klp_register_patch() to see a module before the COMING
>> notifier is called, or after the GOING notifier is called.
>>
>> That can cause all kinds of ugly races. As Pter Mladek reported
* Daniel Thompson wrote:
> Much of the code sitting in arch/x86/kernel/apic/hw_nmi.c to support
> safe all-cpu backtracing from NMI has been copied to printk.c to
> make it accessible to other architectures.
>
> Port the x86 NMI backtrace to the generic code.
Is there any difference between
* Vince Weaver wrote:
> On Wed, 25 Feb 2015, tip-bot for Matt Fleming wrote:
>
> > diff --git a/include/uapi/linux/perf_event.h
> > b/include/uapi/linux/perf_event.h
> > index 1e3cd07..3c8b45d 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -32
Hi Heiko:
Thanks very much.
On 2015年03月05日 03:57, Heiko Stuebner wrote:
Hi Andy,
Am Sonntag, 1. März 2015, 17:25:14 schrieb Andy Yan:
PopMetal is a rockchip rk3288 based board made by ChipSpark,
which has many interface such as VGA,HDMI,usb,ir,sdcad and lots of
sensors such as gyroscope(L3G420
On Thu, 5 Mar 2015 09:43:31 +0900 Minchan Kim wrote:
> Hello Andrew,
>
> On Wed, Mar 04, 2015 at 02:02:02PM -0800, Andrew Morton wrote:
> > On Wed, 4 Mar 2015 14:01:32 +0900 Minchan Kim wrote:
> >
> > > +static int zs_stats_size_show(struct seq_file *s, void *v)
> > > +{
> > > + int i;
> > >
On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote:
> I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator,
> but as it's a mixture of internal and external dependencies (e.g.
> <&pm8921_s4> vs <&pm8921_mpp 7>) this became quite messy. I started
> looking at using the
Hello,
On (03/05/15 09:20), Minchan Kim wrote:
> I'm not against but I want to know why we should support
> user-defined device id. What usecase do you have in mind?
>
hm, you never know what people can come up with. that's probably the
strongest support argument I can provide. I wish there was
On Wed, Mar 04, 2015 at 04:49:13PM +0900, Sergey Senozhatsky wrote:
> On (03/04/15 16:06), Minchan Kim wrote:
> > So are you claiming using of idr is smaller memory footprint than zram
> > included
> > list_head?
> > I hope why you want to use idr for dynamic device management.
> >
>
> and idr h
The mm-of-the-moment snapshot 2015-03-04-16-59 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
On Wed, Mar 04, 2015 at 10:48:30PM +0100, Maciej S. Szmigiero wrote:
> of_property_read_u32_array returns 0 on success,
> so the return value shouldn't be inverted twice,
> first on assignment then in condition expression.
>
> Signed-off-by: Maciej Szmigiero
Applied, thanks.
signature.asc
Desc
On Thu, Feb 26, 2015 at 09:23:57PM -0300, Marcelo Tosatti wrote:
> On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
> > * Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
> >
> > >On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
> > >> I'm actually wondering i
On Thu, Mar 05, 2015 at 09:58:29AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (03/05/15 09:20), Minchan Kim wrote:
> > I'm not against but I want to know why we should support
> > user-defined device id. What usecase do you have in mind?
> >
>
> hm, you never know what people can come up w
On Wed, 2015-03-04 at 21:44 +0900, Namhyung Kim wrote:
>
> I think that there's no need to even call true or echo..
>
> From 0549544e8e982df6478f11e2b4fe419f94c22434 Mon Sep 17 00:00:00 2001
> From: Namhyung Kim
> Date: Wed, 4 Mar 2015 21:26:38 +0900
> Subject: [PATCH] ftracetest: Do not use usl
On (03/05/15 09:58), Sergey Senozhatsky wrote:
> /* yet "/dev/zram$(id -u)" thing looks interesting */
>
hm, I can think of a huge build server with tons of users. /dev/zram$(id -u)
created during user login and destroyed during logout. so users use theirs own
zram devices with predictable device
On Wed, Mar 04, 2015 at 11:12:33PM +, Luck, Tony wrote:
> > - fixed AR and UC order in enum severity_level because UC is severer than AR
> > by definition. Current code is not affected by this wrong order by chance.
>
> AR and AO are both UC errors - that happen also to be recoverable.
Maybe
From: "Luis R. Rodriguez"
While reviewing DIRECT_GBPAGES I noticed some inconsistancies
on when its cached "enable" variable is set and when in reality
its full feature is enabled. There's also some code simplification
possible by simply using Kconfig, so decided to take advantage of
that and the
From: "Luis R. Rodriguez"
Replace #ifdef eyesore with IS_ENABLED() use.
Cc: Greg Kroah-Hartman
Cc: Tony Lindgren
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Juergen Gross
Cc: Andy Lutomirski
Cc: Toshi Kani
Cc: Dave Han
1 - 100 of 1215 matches
Mail list logo
