We have only a few places where we actually want to charge kmem so
instead of intruding into the general page allocation path with
__GFP_KMEMCG it's better to explictly charge kmem there. All kmem
charges will be easier to follow that way.
This is a step toward removing __GFP_KMEMCG. It makes
We have only a few places where we actually want to charge kmem so
instead of intruding into the general page allocation path with
__GFP_KMEMCG it's better to explictly charge kmem there. All kmem
charges will be easier to follow that way.
This is a step towards removing __GFP_KMEMCG. It removes
Hi,
Currently we charge kmem to memcg in alloc_pages if __GFP_KMEMCG is
passed. However, since there are only a few places where we actually
want to charge kmem, we could call kmemcg charge function explicitly
instead. That would remove all kmemcg-related stuff from the general
allocation path
We don't track any random page allocation, so we shouldn't track kmalloc
that falls back to the page allocator.
Signed-off-by: Vladimir Davydov
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Glauber Costa
Cc: Christoph Lameter
Cc: Pekka Enberg
---
include/linux/slab.h |2 +-
mm/memcontrol.c
All kmem is now charged to memcg explicitly, and __GFP_KMEMCG is not
used anywhere, so just get rid of it.
Signed-off-by: Vladimir Davydov
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Glauber Costa
---
include/linux/gfp.h |5 -
include/linux/memcontrol.h |2 +-
>>> On 26.03.14 at 15:58, wrote:
>> +struct xenpf_efi_runtime_call {
>> +uint32_t function;
>> +/*
>> + * This field is generally used for per sub-function flags (defined
>> + * below), except for the XEN_EFI_get_next_high_monotonic_count case,
>> + * where it holds the single
Wednesday, March 26, 2014, 3:44:42 PM, you wrote:
>> -Original Message-
>> From: Sander Eikelenboom [mailto:li...@eikelenboom.it]
>> Sent: 26 March 2014 11:11
>> To: Paul Durrant
>> Cc: Wei Liu; annie li; Zoltan Kiss; xen-de...@lists.xen.org; Ian Campbell;
>> linux-
>> kernel;
On Wednesday 26 March 2014 08:15 PM, Rob Herring wrote:
> On Wed, Mar 26, 2014 at 8:57 AM, Kishon Vijay Abraham I wrote:
>> Added support for pcie controller in dra7xx. This driver re-uses
>> the designware core code that is already present in kernel.
>>
>> Signed-off-by: Kishon Vijay Abraham I
[+ imx6 maintainers ]
On Thu, Mar 20, 2014 at 8:52 PM, Mike Turquette wrote:
> Quoting Gregory CLEMENT (2014-02-28 02:46:12)
>> Hi Mike,
>>
>> On 24/02/2014 19:10, Gregory CLEMENT wrote:
>> > Until now the clock providers were initialized in the order found in
>> > the device tree. This led to
On Wed, 2014-03-26 at 00:42 -0700, Jimmy Li wrote:
> fix a sparse warning.
[]
> diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c
[]
> @@ -1843,7 +1843,7 @@ int iwctl_siwencodeext(struct net_device *dev,
[]
> blen = sizeof(*param);
> - buf = kmalloc((int)blen,
On 03/26/2014 01:51 AM, Geert Uytterhoeven wrote:
> (cc akpm, who still uses these scripts, while the rest of the world
> moved to git ;-)
no, some of us still use quilt.
>
> On Wed, Mar 26, 2014 at 12:49 AM, Mitchel Humpherys
> wrote:
>> The link to the tarball for Andrew Morton's patch
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following.
Out of curiosity, is there a reason not to do bad flag checks when actually
setting flag? Obviously it'll be slower but it'll be easier catching these
issues.
[
Em Wed, 26 Mar 2014 15:55:07 +0100
"Rafael J. Wysocki" escreveu:
> On Wednesday, March 26, 2014 01:08:10 PM Tomasz Nowicki wrote:
> > Hi,
>
> Hi,
>
> This is a question for Tony, Boris and Mauro (CCed now).
>
> > Currently APEI depends on x86 architecture. It is because of many x86
> >
On 03/07/2014 04:18 PM, Mike Looijmans wrote:
If vmmc or vqmmc regulators are controlled by an I2C device, the
request for the regulator is likely to fail because the I2C bus has
not been probed yet. The sdhci then incorrectly assumes that the user
never wanted to use a regulator anyway and
On 03/26/2014 01:53 AM, Dave Jones wrote:
On Tue, Mar 25, 2014 at 10:12:29PM +0100, Jan Kara wrote:
> This fixes an oops triggered by trinity when it tried mounting
> anon_inodefs which overwrote anon_inode_inode pointer while other CPU
> has been in anon_inode_getfile() between ihold()
On Wed, Mar 26, 2014 at 03:50:51PM +0100, Paolo Bonzini wrote:
> Il 26/03/2014 15:40, Fengguang Wu ha scritto:
> >Hi Paolo,
> >
> >We noticed the below kernel BUG on
> >
> >git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
> >commit 93c4adc7afedf9b0ec190066d45b6d67db5270da ("KVM: x86: handle
On Wed, Mar 26, 2014 at 03:33:37PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Make pata_arasan_cf host driver depend on ARCH_SPEAR13XX config
> option as ARASAN CompactFlash PATA support is specific to ST
> SPEAr13xx SoCs and the driver to work requires suitable device
> tree node (or platform
On Tue, 25 Mar 2014, Daniel Kiper wrote:
> Define EFI related stuff for Xen.
>
> This patch is based on Jan Beulich and Tang Liang work.
>
> Signed-off-by: Daniel Kiper
> Signed-off-by: Tang Liang
> Signed-off-by: Jan Beulich
> ---
> include/xen/interface/platform.h | 123
>
kvm_x86_ops is still NULL at this point. Since kvm_init_msr_list
cannot fail, it is safe to initialize it before the call.
Reported-by: Fengguang Wu
Cc: k...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/x86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Il 26/03/2014 15:40, Fengguang Wu ha scritto:
Hi Paolo,
We noticed the below kernel BUG on
git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
commit 93c4adc7afedf9b0ec190066d45b6d67db5270da ("KVM: x86: handle missing MPX in
nested virtualization")
Ouch. Out of curiosity is this on Skylake
On 03/26/2014 02:44 PM, Josh Boyer wrote:
> On Tue, Mar 25, 2014 at 5:24 PM, Greg KH wrote:
>> On Fri, Feb 28, 2014 at 10:13:29AM -0500, Josh Boyer wrote:
>>> cgroup-fixes.patch (rhbz 1045755)
>>> - Upstream commits 0ab02ca8f887908152d1a96db5130fc661d36a1e
>>> - There was a 3.12 version of this
Il 26/03/2014 15:40, Fengguang Wu ha scritto:
Hi Paolo,
We noticed the below kernel BUG on
git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
commit 93c4adc7afedf9b0ec190066d45b6d67db5270da ("KVM: x86: handle missing MPX in
nested virtualization")
Ouch. Out of curiosity is this on Skylake
On Thursday, March 27, 2014 01:08:58 AM Kieran Clancy wrote:
> On Wed, Mar 26, 2014 at 9:12 PM, Stefan Biereigel wrote:
> >
> > I don't know if it is a valid idea, but maybe it would be ok to process
> > events after resume in general, and only throw away events on those
> > platforms that
On Wed, Mar 26, 2014 at 8:57 AM, Kishon Vijay Abraham I wrote:
> Added support for pcie controller in dra7xx. This driver re-uses
> the designware core code that is already present in kernel.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt |
> -Original Message-
> From: Sander Eikelenboom [mailto:li...@eikelenboom.it]
> Sent: 26 March 2014 11:11
> To: Paul Durrant
> Cc: Wei Liu; annie li; Zoltan Kiss; xen-de...@lists.xen.org; Ian Campbell;
> linux-
> kernel; net...@vger.kernel.org
> Subject: Re: [Xen-devel] Xen-unstable Linux
On 03/26/2014 03:06 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 26-03-2014 13:28, Roger Quadros wrote:
>
>> It was impossible to enumerate on a SuperSpeed (XHCI) host
>> with alternate setting = 1 due to the wrongly set 'bMaxBurst'
>> field in the SuperSpeed Endpoint Companion descriptor.
>
>>
On Wednesday, March 26, 2014 01:08:10 PM Tomasz Nowicki wrote:
> Hi,
Hi,
This is a question for Tony, Boris and Mauro (CCed now).
> Currently APEI depends on x86 architecture. It is because of many x86
> specific features like "IA-32 Architecture Corrected Machine Check
> " error source or NMI
On Wed, Mar 26, 2014 at 9:12 PM, Stefan Biereigel wrote:
>
> I don't know if it is a valid idea, but maybe it would be ok to process
> events after resume in general, and only throw away events on those
> platforms that continue to log events while in standby (Samsung 5/7/9)?
We can give it a
worker_idr is always accessed in manager lock context currently.
worker_idr is highly related to managers, it will be unlikely
accessed in pool->lock only in future.
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c | 34 ++
1 files changed, 6 insertions(+),
On Tue, 2014-03-25 at 18:44 +0800, rogera...@realtek.com wrote:
> From: Roger Tseng
> +static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
> + unsigned int pipe, struct scatterlist *sg, int num_sg,
> + unsigned int length, unsigned int *act_len, int timeout)
>
Make pata_arasan_cf host driver depend on ARCH_SPEAR13XX config
option as ARASAN CompactFlash PATA support is specific to ST
SPEAr13xx SoCs and the driver to work requires suitable device
tree node (or platform device) to be defined. Additionally
allow the driver build if COMPILE_TEST config
On Wed, 26 Mar, at 03:02:17PM, Daniel Kiper wrote:
> On Wed, Mar 26, 2014 at 12:56:23PM +, Matt Fleming wrote:
> >
> > Please don't create another struct of EFI function pointers.
> >
> > After this we'll have 3 global efi structures defintions and 4 global
> > efi objects on x86,
> >
> > -
On Wed, Mar 19, 2014 at 6:12 PM, Tanmay Inamdar wrote:
> This patch adds the device tree nodes for APM X-Gene PCIe controller and
> PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts
> nodes are added.
[snip]
> + pcie0: pcie@1f2b {
> +
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/Kconfig | 12 +
drivers/platform/x86/Makefile| 2 +
drivers/platform/x86/alienware-wmi.c | 557 +++
3 files changed, 571 insertions(+)
create mode 100644
On 14-03-26 04:41 AM, Geert Uytterhoeven wrote:
> On Thu, Feb 13, 2014 at 10:15 PM, Paul Gortmaker
> wrote:
>> While copy_to/from_user_page() users are uncommon, there is one in
>> drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c which leads
>> to the following:
>>
>> ERROR:
Some code is hide inside #ifdef BP_PROC_SUPPORT and it never defined
anywhere. And, it made defined but not used function which calling
code was hide inside #ifdef BP_PROC_SUPPORT and caused following
build warning:
drivers/staging/silicom/bpctl_mod.c:6786:12: warning:
‘bp_proc_create’ defined
On Wed, Mar 26, 2014 at 03:19:23PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Make sata_rcar host driver depend on ARCH_SHMOBILE config option as
> Renesas R-Car SATA support is specific to Renesas SoCs and the driver
> to work requires suitable device tree node (or platform device) to be
>
Make sata_rcar host driver depend on ARCH_SHMOBILE config option as
Renesas R-Car SATA support is specific to Renesas SoCs and the driver
to work requires suitable device tree node (or platform device) to be
defined. Additionally allow the driver build if COMPILE_TEST config
option is set.
Cc:
On Wed, 26 Mar, at 03:08:00PM, Daniel Kiper wrote:
>
> Hmmm... I am not sure which approach is better. I saw that
> in many places declarations have annotations. Could you
> point me some docs which states (and explains) that this
> is wrong idea.
Note I've had the following patch from Joe
>>> On 26.03.14 at 15:08, wrote:
> On Wed, Mar 26, 2014 at 01:21:19PM +, Jan Beulich wrote:
>> >>> On 25.03.14 at 21:57, wrote:
>> > Export arch_tables variable. Xen init function calls efi_config_init()
>> > which takes it as an argument.
>> >
>> > Additionally, put __initdata in place
On 26 March 2014 18:10, Srivatsa S. Bhat
wrote:
> I don't think this is such a good idea. Open-coding a part of that callback
> in the init routine can lead to loop-holes down the road:
We think that we are open-coding part of that callback here because it is
implemented that way on the first
Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
for pcie1 phy and pcie2 phy.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/cm2_7xx.h |4 ++
On 26 March 2014 17:13, Srivatsa S. Bhat
wrote:
>> + new_base = _cpu_base->clock_base[base->index];
>
> Further down, timer->base can be altered (and set to NULL too).
> So if we jump back to 'again', we'll end up in trouble.
> So I think its important to cache the value in basenum and
> use
On Wed, Mar 26, 2014 at 01:21:19PM +, Jan Beulich wrote:
> >>> On 25.03.14 at 21:57, wrote:
> > Export arch_tables variable. Xen init function calls efi_config_init()
> > which takes it as an argument.
> >
> > Additionally, put __initdata in place suggested by include/linux/init.h.
>
> Which
This is a driver for the Alienware X51, X51 R2 and some future HW.
- For the X51 / X51 R2 it allows control of the color and brightness
of each zone via a sysfs interface for the color and a LED interface
for the brightness
- For the future HW it allows control of color and brightness as
On Wed, Mar 26, 2014 at 12:56:23PM +, Matt Fleming wrote:
> On Tue, 25 Mar, at 09:57:52PM, Daniel Kiper wrote:
> > Add efi_init_ops variable which allows us to replace
> > EFI init functions on Xen with its specific stuff.
> >
> > This patch is based on Jan Beulich and Tang Liang work.
> >
> >
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
Added support for pcie controller in dra7xx. This driver re-uses
the designware core code that is already present in kernel.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++
drivers/pci/host/Kconfig | 10 +
From: Keerthy
Add divider table to optfclk_pciephy_div clock.
Signed-off-by: Keerthy
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
When a module is built into the kernel, the modules's module_init()
function becomes an initcall. Debugging built in kernel modules is
typically done by changing the .config, recompiling, and booting the new
kernel in an effort to determine exactly which module caused a problem.
This is a
Added missing 32khz clock used by PCIe PHY.
The documention for this node can be found @ ../bindings/clock/ti/gate.txt.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |8
1 file changed, 8 insertions(+)
diff --git
PCIe PHY uses an external pll instead of the internal pll used by SATA
and USB3. So added support in pipe3 PHY to use external pll
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
drivers/phy/phy-ti-pipe3.c | 99
Added dt data for PCIe PHY as a child node of ocp2scp3.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 16
1 file changed, 16 insertions(+)
diff --git
Now that we have added PCIe driver for DRA7 SOCs, enable PCI on
DRA7 SOCs.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/Kconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 46f8c53..352f252 100644
---
Added dt data for PCIe controller. This node contains dt data for
both the DRA7 part of designware controller and for the designware core.
The documention for this node can be found @ ../bindings/pci/ti-pci.txt.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 24
Added dt data for PCIe PHY control module used by PCIe PHY.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi
This patch series adds support for PCIe in DRA7xx including drivers and dt
data. PCIe in DRA7xx uses desingware IP and hence this re-uses the
pcie desingware driver (pcie-designware.c) by Jingoo.
This patch series depends on a few patches that is already in -next.
Tested broadcom PCIe card and
In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit
address. So whenever the cpu issues a read/write request, the 4 most
significant bits are used by L3 to determine the target controller.
For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but
From: Keerthy
Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck
from dpll_pcie_ref_ck.
Signed-off-by: Keerthy
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, 26 Mar, at 02:48:45PM, Daniel Kiper wrote:
>
> On my machine this function crashes on Xen so that is why I have changed
> condition. However, if you say that this issue could be solved in
> another way I will investigate it further.
Daniel, could you paste the crash? Do you get a stack
On Wed, 26 Mar, at 01:46:17PM, Matt Fleming wrote:
> On Wed, 26 Mar, at 01:31:04PM, Jan Beulich wrote:
> > >>> On 26.03.14 at 14:12, wrote:
> > >
> > > Is there a reason that you can't just populate an efi_system_table_t
> > > object, which could be used by efi_init(), so that we can save you
From: Jon Ringle
The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
high performance UART. The SC16IS7xx’s internal register set is
backward-compatible with the widely used and widely popular 16C450.
The SC16IS7xx also provides additional advanced features such as
auto hardware
From: Jon Ringle
This patch adds the devicetree documentation for the NXP SC16IS7XX UARTs.
Signed-off-by: Jon Ringle
---
.../devicetree/bindings/serial/nxp,sc16is7xx.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
On Wed, Mar 26, 2014 at 01:39:42PM +, Jan Beulich wrote:
> >>> On 26.03.14 at 14:31, wrote:
> > On Wed, 26 Mar, at 01:22:49PM, Jan Beulich wrote:
> >> >>> On 26.03.14 at 14:00, wrote:
> >> >
> >> > This could do with a little bit more explanation. Why is it not
> >> > necessary to mark the
On Wed, 26 Mar, at 01:31:04PM, Jan Beulich wrote:
> >>> On 26.03.14 at 14:12, wrote:
> >
> > Is there a reason that you can't just populate an efi_system_table_t
> > object, which could be used by efi_init(), so that we can save you the
> > trouble of duplicating all of this code?
>
> Would the
On Tue, Mar 25, 2014 at 5:24 PM, Greg KH wrote:
> On Fri, Feb 28, 2014 at 10:13:29AM -0500, Josh Boyer wrote:
>> cgroup-fixes.patch (rhbz 1045755)
>> - Upstream commits 0ab02ca8f887908152d1a96db5130fc661d36a1e
>> - There was a 3.12 version of this patch sent to stable list from
>> Michal Hocko.
>>> On 26.03.14 at 14:31, wrote:
> On Wed, 26 Mar, at 01:22:49PM, Jan Beulich wrote:
>> >>> On 26.03.14 at 14:00, wrote:
>> >
>> > This could do with a little bit more explanation. Why is it not
>> > necessary to mark the EFI memory map that was passed to the kernel as
>> > reserved in
On Wed, Mar 26, 2014 at 12:49:59PM +, Jon Ringle wrote:
> On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland wrote:
> > On Tue, Mar 25, 2014 at 06:19:24PM +, j...@ringle.org wrote:
> >> +- interrupt-parent: The phandle for the interrupt controller that
> >> + services interrupts for this IC.
Hello,
This series is against 3.14.0-rc7.
It is amied to further improve 'percpu_ida' tags locality by taking
into account system's CPU topology when stealing tags. That is try
to steal from a CPU which is 'closest' to the stealing one.
I would not bother to post this, since on several system
We have for_each_cpu_mask() (and friends) macro which is used
to enumerate CPUs in a given cpumask. Such enumeration walks
CPUs in ascending order of their IDs and does not take into
account CPU topology of the system. That is, each next CPU
could belong to any level of the system topology with
Function steal_tags() iterates thru 'cpus_have_tags' cpumask
ignoring the system's CPU topology. That leads to situations
when a newly stolen tag and the data structure(s) associated
with it (i.e. struct request in the block layer) topology-
wise are more remote from the stealing CPU than it could
>>> On 26.03.14 at 14:12, wrote:
> On Tue, 25 Mar, at 09:57:56PM, Daniel Kiper wrote:
>> +static void __init efi_init_xen(void)
>> +{
>> +efi_char16_t vendor_c16[100];
>> +char vendor[ARRAY_SIZE(vendor_c16)];
>> +int ret, i;
>> +struct xen_platform_op op;
>> +union
On Wed, 26 Mar, at 01:22:49PM, Jan Beulich wrote:
> >>> On 26.03.14 at 14:00, wrote:
> >
> > This could do with a little bit more explanation. Why is it not
> > necessary to mark the EFI memory map that was passed to the kernel as
> > reserved in memblock?
>
> Because that's in memory Dom0
On Tue, Mar 25, 2014 at 11:32:09PM -0700, Andrew Morton wrote:
> Well, there are always alternatives. For example ext3 could
> preallocate a single transaction_t and a single IO page and fall back
> to synchronous page-at-a-time journal writes. But I can totally see
> that such things are
On 03/26/2014 04:51 PM, Srivatsa S. Bhat wrote:
> On 03/26/2014 09:26 AM, Preeti U Murthy wrote:
>> Its possible that the tick_broadcast_force_mask contains cpus which are not
>> in cpu_online_mask when a broadcast tick occurs. This could happen under the
>> following circumstance assuming CPU1 is
>>> On 25.03.14 at 21:57, wrote:
> Define EFI related stuff for Xen.
>
> This patch is based on Jan Beulich and Tang Liang work.
And with this, ...
> Signed-off-by: Daniel Kiper
> Signed-off-by: Tang Liang
> Signed-off-by: Jan Beulich
... these should be in the reverse order to reflect
>>> On 26.03.14 at 14:00, wrote:
> On Tue, 25 Mar, at 09:57:54PM, Daniel Kiper wrote:
>> Call efi_memblock_x86_reserve_range() on native EFI platform only.
>> This is not needed and even it should not be called on platforms
>> which wraps EFI infrastructure like Xen.
>>
>> Signed-off-by: Daniel
>>> On 25.03.14 at 21:57, wrote:
> Export arch_tables variable. Xen init function calls efi_config_init()
> which takes it as an argument.
>
> Additionally, put __initdata in place suggested by include/linux/init.h.
Which isn't necessarily the most appropriate place.
> ---
On Tue, Mar 25, 2014 at 09:03:51PM -0400, Alexandre Demers wrote:
> So, I tried RC8 and I'm still getting the error. It start too fast
> to be able to read whatever it is saying, but here is what I can
> read:
> ...
> cp: error writing /run/initramfs/new_root/...
> cp: failed to extend ...
> ...
On Tue, 25 Mar, at 09:57:56PM, Daniel Kiper wrote:
> Put EFI machinery for Xen in place.
>
> This patch is based on Jan Beulich and Tang Liang work.
>
> Signed-off-by: Daniel Kiper
> Signed-off-by: Tang Liang
> Signed-off-by: Jan Beulich
> ---
> arch/x86/xen/enlighten.c | 10 ++
>
The name_assign_type attribute gives hints where the interface name of a
given net-device comes from. Three different values are currently defined:
NET_NAME_ENUM:
This is the default. The ifname is provided by the kernel with an
enumerated suffix. Names may be reused and unstable.
Hello.
On 26-03-2014 13:28, Roger Quadros wrote:
It was impossible to enumerate on a SuperSpeed (XHCI) host
with alternate setting = 1 due to the wrongly set 'bMaxBurst'
field in the SuperSpeed Endpoint Companion descriptor.
Testcase:
modprobe -r usbtest; modprobe usbtest alt=1
modprobe
Hi
This is v5 of the netdev naming-policy series. You can find v4 here:
http://article.gmane.org/gmane.linux.kernel/1668161
Changes since v4:
- none
This series implements a new sysfs attribute for netdevs called
"name_assign_type". It provides an integer that describes where an interface
The nl80211 interface allows creating new netdevs from user-space. The
name is *always* provided by user-space, so we should set NET_NAME_USER to
provide that information via sysfs. But we must not set it for the default
wlan%d names as these are kernel-provided names.
This allows udev to not
Netdevs created via nl80211 (currently only P2P ifs) have names provided
by user-space. Therefore, set the naming-policy to NET_NAME_USER so it is
correctly shown in sysfs.
Signed-off-by: David Herrmann
Acked-by: Arend van Spriel
Acked-by: Tom Gundersen
---
P2P netdevs and other devices that are created via nl80211 from user-space
have a name provided by user-space. Therefore, set NET_NAME_USER so this
is correctly shown in sysfs.
Signed-off-by: David Herrmann
Acked-by: Kalle Valo
Acked-by: Tom Gundersen
---
On Tue, 25 Mar, at 09:57:54PM, Daniel Kiper wrote:
> Call efi_memblock_x86_reserve_range() on native EFI platform only.
> This is not needed and even it should not be called on platforms
> which wraps EFI infrastructure like Xen.
>
> Signed-off-by: Daniel Kiper
> ---
> arch/x86/kernel/setup.c |
Dear Sebastian Hesselbarth,
On Wed, 26 Mar 2014 13:04:55 +0100, Sebastian Hesselbarth wrote:
> On 03/25/2014 11:48 PM, Gregory CLEMENT wrote:
> > The initial binding for PMSU were wrong. It didn't take into account
> > all the registers from the PMSU and moreover it referred to registers
> >
On Tue, 25 Mar, at 09:57:52PM, Daniel Kiper wrote:
> Add efi_init_ops variable which allows us to replace
> EFI init functions on Xen with its specific stuff.
>
> This patch is based on Jan Beulich and Tang Liang work.
>
> Signed-off-by: Daniel Kiper
> Signed-off-by: Tang Liang
> ---
>
On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland wrote:
> On Tue, Mar 25, 2014 at 06:19:24PM +, j...@ringle.org wrote:
>> +- interrupt-parent: The phandle for the interrupt controller that
>> + services interrupts for this IC.
>> +- interrupts: Specifies the interrupt source of the parent
On 03/26/2014 04:51 PM, Viresh Kumar wrote:
> Currently we are returning notifier_from_errno() from CPU_UP_PREPARE notifier
> when we detect an error while calling init_timers_cpu(). notifier_from_errno()
> already has enough checks within to do something similar. And so we can call
> it
>
On 03/26/2014 04:51 PM, Viresh Kumar wrote:
> In init_timers() we need to call init_timers_cpu() for boot CPU. For this,
> currently we are emulating a call to hotplug notifier. Probably this was done
> initially to get rid of code redundancy. But this sequence always called a
> single routine,
On 03/26/2014 04:51 PM, Viresh Kumar wrote:
> In hrtimers_init() we need to call init_hrtimers_cpu() for boot CPU. For this,
> currently we are emulating a call to hotplug notifier. Probably this was done
> initially to get rid of code redundancy. But this sequence always called a
> single
On Wed, Mar 26, 2014 at 9:27 PM, Greg KH wrote:
> On Wed, Mar 26, 2014 at 02:58:50PM +0900, SeongJae Park wrote:
>> bp_proc_create() be called only when BP_PROC_SUPPORT defined but its
>> definition live outside of #ifdef BP_PROC_SUPPORT and cause following
>> trivial build warning:
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm announcing the release of the 3.12.15 kernel.
All users of the 3.12 kernel series must upgrade.
The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.12.y
and can be
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, March 25, 2014 11:50 PM
> To: Haiyang Zhang
> Cc: David Miller; o...@aepfle.de; net...@vger.kernel.org;
> jasow...@redhat.com; driverdev-de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
I apologize in advance if I'm posting this to the wrong list. Also, I've attempted to post in plain text; I hope
Thunderbird behaves.
I have set up a ipsec tunnel between Server-A and Server-B using public IP addresses and configured the ip xfrm state
and ip xfrm policy database to use
On Wed, Mar 26, 2014 at 02:58:50PM +0900, SeongJae Park wrote:
> bp_proc_create() be called only when BP_PROC_SUPPORT defined but its
> definition live outside of #ifdef BP_PROC_SUPPORT and cause following
> trivial build warning:
> drivers/staging/silicom/bpctl_mod.c:6786:12: warning:
>
Hi,
Currently APEI depends on x86 architecture. It is because of many x86
specific features like "IA-32 Architecture Corrected Machine Check
" error source or NMI hardware error notification. However, many other
features like "PCI Express Device AER Structure" or GHES via external
interrupt
On Wed, Mar 26, 2014 at 12:42:43AM -0700, Jimmy Li wrote:
> fix a sparse warning.
> drivers/staging/vt6655/iwctl.c:1846:35: warning: cast from restricted
> gfp_t
> drivers/staging/vt6655/iwctl.c:1846:35: warning: incorrect type in
> argument 2 (different base types)
>
301 - 400 of 1008 matches
Mail list logo
