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
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
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 +
* 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
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
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
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
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
* 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
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
>
>
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,
> +
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
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
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(_index_mutex);
> > + /* read operation on zram_add is - pick
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
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
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
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...
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)
* 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
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
> >>
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
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.
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
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
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
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
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
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
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
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
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
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
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, >dev);
> > + for (reg = match->data; reg->name; reg++) {
> > + vreg = devm_kmalloc(>dev, sizeof(*vreg), GFP_KERNEL);
> > + if (!vreg) {
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
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
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
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
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
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 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/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
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
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
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
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
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
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
* 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 -
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
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
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
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 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
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
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. */
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.
> - 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?
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
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
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.
>
>
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
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
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
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
>
* 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 @@
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.1 does not currently support S states for ARM64 hardware but
> >> ACPI code
On Wed, Mar 04, 2015 at 08:00:46PM +, Mel Gorman wrote:
> On Wed, Mar 04, 2015 at 08:33:53AM +1100, Dave Chinner wrote:
> > On Tue, Mar 03, 2015 at 01:43:46PM +, Mel Gorman wrote:
> > > On Tue, Mar 03, 2015 at 10:34:37PM +1100, Dave Chinner wrote:
> > > > On Mon, Mar 02, 2015 at 10:56:14PM
On Wed, 2015-03-04 at 17:32 -0500, Bandan Das wrote:
> Alex Williamson writes:
>
> > On Wed, 2015-03-04 at 15:49 -0500, Bandan Das wrote:
> >> Hi Alex,
> >>
> >> Alex Williamson writes:
> >> ...
> >> > +if (fields < 2) {
> >> > +pr_warn("vfio-pci:
On Wednesday 04 March 2015 14:53:40 Arun Ramamurthy wrote:
> On 15-03-04 02:50 PM, Arnd Bergmann wrote:
> > On Wednesday 04 March 2015 14:40:13 Arun Ramamurthy wrote:
> >> On 15-03-04 02:21 PM, Arnd Bergmann wrote:
> >>> On Thursday 12 February 2015 14:17:41 Arun Ramamurthy wrote:
> Hi Arnd
>
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 @@ config PINCTRL_TEGRA_XUSB
> select
Commit-ID: 49db46a67bec9ca9e29ece4729a876195877af50
Gitweb: http://git.kernel.org/tip/49db46a67bec9ca9e29ece4729a876195877af50
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:25 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:49 +0100
x86/asm: Introduce
Hey Michal-
I've got a few comments on this.
On Mon, Feb 23, 2015 at 12:37:26PM +0100, Michal Simek wrote:
> Xilinx Microblaze is placed in programmable logic on Xilinx
> Zynq architecture. Driver requires specific HW setting
> described in DT binding.
>
> Signed-off-by: Michal Simek
[..]
> +++
Commit-ID: 1e3fbb8a1d814f35e2e689cf87714d38d9f3564d
Gitweb: http://git.kernel.org/tip/1e3fbb8a1d814f35e2e689cf87714d38d9f3564d
Author: Andy Lutomirski
AuthorDate: Thu, 26 Feb 2015 14:40:39 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:53 +0100
x86/asm/entry/64: Remove
Commit-ID: d441c1f2b73ec742c2e55be804ebc6fee130c77f
Gitweb: http://git.kernel.org/tip/d441c1f2b73ec742c2e55be804ebc6fee130c77f
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:38 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:52 +0100
x86/asm/entry/64:
Commit-ID: 911d2bb5ccaab102abbab2bb58438c75bc342ca9
Gitweb: http://git.kernel.org/tip/911d2bb5ccaab102abbab2bb58438c75bc342ca9
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:36 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:52 +0100
x86/asm/entry/64: Use
Commit-ID: b3ab90b333e94659e7c351843ab41ec0004f73e8
Gitweb: http://git.kernel.org/tip/b3ab90b333e94659e7c351843ab41ec0004f73e8
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:37 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:52 +0100
x86/asm/entry/64/compat:
Commit-ID: 14f6e9532dda399a7b789f744dc045f8865a9e42
Gitweb: http://git.kernel.org/tip/14f6e9532dda399a7b789f744dc045f8865a9e42
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:35 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:52 +0100
x86/asm/entry/64/compat:
Commit-ID: f2db9382c1140914cfdef224ce907e443c9f9b81
Gitweb: http://git.kernel.org/tip/f2db9382c1140914cfdef224ce907e443c9f9b81
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:30 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:50 +0100
x86/asm/entry: Do mass
Commit-ID: b87cf63e2a5fbe3b368d5f5e5708e585b0fb3f84
Gitweb: http://git.kernel.org/tip/b87cf63e2a5fbe3b368d5f5e5708e585b0fb3f84
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:32 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:51 +0100
x86/asm/entry: Add
Commit-ID: 69e8544cd0056e02965ffb5e8414fb7501a2ee2e
Gitweb: http://git.kernel.org/tip/69e8544cd0056e02965ffb5e8414fb7501a2ee2e
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:24 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:48 +0100
x86/asm/64: Open-code
Commit-ID: 76f5df43cab5e765c0bd42289103e8f625813ae1
Gitweb: http://git.kernel.org/tip/76f5df43cab5e765c0bd42289103e8f625813ae1
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:27 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:49 +0100
x86/asm/entry/64: Always
On 15-03-04 02:50 PM, Arnd Bergmann wrote:
On Wednesday 04 March 2015 14:40:13 Arun Ramamurthy wrote:
On 15-03-04 02:21 PM, Arnd Bergmann wrote:
On Thursday 12 February 2015 14:17:41 Arun Ramamurthy wrote:
Hi Arnd
My apologies for the late reply, I was moved to other work items. I
wanted
Commit-ID: 1eeb207f870f746a863e5c59321d837d2d91c218
Gitweb: http://git.kernel.org/tip/1eeb207f870f746a863e5c59321d837d2d91c218
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:33 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:51 +0100
x86/asm/entry/64: Move
Commit-ID: 050273d19b94f2adf9d35979cee949d6b6a9df84
Gitweb: http://git.kernel.org/tip/050273d19b94f2adf9d35979cee949d6b6a9df84
Author: Andy Lutomirski
AuthorDate: Thu, 26 Feb 2015 14:40:31 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:50 +0100
x86/asm/entry/64: Remove
Commit-ID: 6e1327bd2b20ccb387fcddc0caa605cb253cc458
Gitweb: http://git.kernel.org/tip/6e1327bd2b20ccb387fcddc0caa605cb253cc458
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:26 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:49 +0100
x86/asm/entry/64: Fix
On Tuesday, February 24, 2015 05:36:24 PM al.st...@linaro.org wrote:
> From: Al Stone
>
> Now that all of the _OSI functionality has been separated out, we can
> provide arch-specific functionality for it. This also allows us to do
> the same for the acpi_blacklisted() function. We also make
Commit-ID: 0d55083698ed2f498e5682c5c252e6b7224890be
Gitweb: http://git.kernel.org/tip/0d55083698ed2f498e5682c5c252e6b7224890be
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:29 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:50 +0100
x86/asm/entry/64: Shrink
Commit-ID: ebfc453e27c676e104378366a0b027e5c6918631
Gitweb: http://git.kernel.org/tip/ebfc453e27c676e104378366a0b027e5c6918631
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:34 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:51 +0100
x86/asm/entry/64: Clean
Commit-ID: e90e147cbc0cbc8dcf48000e15190badf75250f4
Gitweb: http://git.kernel.org/tip/e90e147cbc0cbc8dcf48000e15190badf75250f4
Author: Denys Vlasenko
AuthorDate: Thu, 26 Feb 2015 14:40:28 -0800
Committer: Ingo Molnar
CommitDate: Wed, 4 Mar 2015 22:50:49 +0100
x86/asm/entry/64: Fix
On Tuesday, February 24, 2015 05:36:25 PM al.st...@linaro.org wrote:
> From: Al Stone
>
> ACPI_OS_NAME is globally defined as "Microsoft Windows NT" for now.
> That doesn't make much sense in the ARM context, so set it to "Linux"
> when CONFIG_ARM64.
>
> If it is necessary to change the return
On Monday, March 02, 2015 12:00:21 PM Al Stone wrote:
> On 03/02/2015 10:29 AM, Will Deacon wrote:
> > Hi Al,
> >
> > On Wed, Feb 25, 2015 at 12:36:24AM +, al.st...@linaro.org wrote:
> >> diff --git a/arch/arm64/kernel/acpi-blacklist.c
> >> b/arch/arm64/kernel/acpi-blacklist.c
> >> new file
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.1 does not currently support S states for ARM64 hardware but
>> ACPI code will call acpi_target_system_state() for device power
>> management,
On Wednesday 04 March 2015 14:40:13 Arun Ramamurthy wrote:
> On 15-03-04 02:21 PM, Arnd Bergmann wrote:
> > On Thursday 12 February 2015 14:17:41 Arun Ramamurthy wrote:
> >> Hi Arnd
> >>
> >> My apologies for the late reply, I was moved to other work items. I
> >> wanted to get more clarification
On Tuesday, February 24, 2015 05:36:22 PM al.st...@linaro.org wrote:
> From: Al Stone
>
> Having moved the _OSI callback function needed by ACPICA from
> drivers/acpi/osl.c to drivers/acpi/osi.c, we now move all the
> remaining _OSI support functions to osi.c.
>
> This patch is much larger than
On Tuesday, February 24, 2015 05:36:23 PM al.st...@linaro.org wrote:
> From: Al Stone
>
> Whether arch-specific functions are used or not now depends on the config
> option CONFIG_ARCH_SPECIFIC_ACPI_OSI. By default, this is set false which
> causes the x86/ia64 versions to be used, just as is
On Tue, Mar 03, 2015 at 10:35:33AM +0900, Jaewon Kim wrote:
> Hi Dmitry,
>
> On 03/03/2015 02:32, Dmitry Torokhov wrote:
> >On Mon, Mar 02, 2015 at 07:10:37PM +0900, Jaewon Kim wrote:
> >>This patch adds support for haptic driver on max77843
> >>MFD(Multi Function Device) with PMIC, MUIC, LED,
On Monday 09 February 2015 19:41:57 Daniel Tang wrote:
> Signed-off-by: Daniel Tang
> ---
> arch/arm/boot/dts/nspire-classic.dtsi | 5 +
> arch/arm/boot/dts/nspire-cx.dts | 4
> arch/arm/boot/dts/nspire.dtsi | 21 +
> 3 files changed, 30 insertions(+)
201 - 300 of 2430 matches
Mail list logo
