* PCIe ASPM, PCI Bridges, e.g. PEX8311
From: Roman Fietze @ 2012-01-17 9:53 UTC (permalink / raw)
To: Kenji Kaneshige; +Cc: linux-pci
Hello Kenji, hello Linux PCI list members,
Using the current code it seems, that I cannot use ASPM on links
between any PCIe node and a PCI(e) bridge.
The current ASPM code in drivers/pci/pcie/aspm.c contains the
following statements inside pcie_aspm_cap_init(), as of the current
HEAD around line 402-410:
list_for_each_entry(child, &linkbus->devices, bus_list) {
if (child->pcie_type == PCI_EXP_TYPE_PCI_BRIDGE) {
link->aspm_disable = ASPM_STATE_ALL;
break;
}
}
I simply do not yet understand, why this is necessary. Is this
required by the PCI(e) specification (1), or would enabling ASPM cause
problems with the current code as it is right now (2)?
If (2), would it be a solution to check which kind of PCI- bridge the
device is, mainly checking if it is a PCIe-PCIe bridge or if it
connects only to one PCIe link?
Anything that could get me started, or stops me right here, would be
very helpful.
PCI layout of our board:
00:00.0 Host bridge: Intel Corporation System Controller Hub (SCH Poulsbo) (rev 07)
..
00:1c.1 PCI bridge: Intel Corporation System Controller Hub (SCH Poulsbo) PCI Express Port 2 (rev 07)
..
02:00.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
03:01.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
03:02.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
..
.. (8 -ports, downstream on on 03:0[1-7].0, see below)
..
03:07.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
05:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21)
06:04.0 Bridge: PLX Technology, Inc. Device 3456 (rev ba)
07:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21)
08:04.0 Bridge: PLX Technology, Inc. Device 3455 (rev ba)
..
-[0000:00]-+-00.0
+-02.0
+-1a.0
+-1c.0-[01]----00.0
+-1c.1-[02-0c]----00.0-[03-0c]--+-01.0-[04]----00.0
| +-02.0-[05-06]--*--00.0-[06]----04.0
| +-03.0-[07-08]--*--00.0-[08]----04.0
| +-04.0-[09]----00.0
| +-05.0-[0a]--
| +-06.0-[0b]--
| \-07.0-[0c]--
+-1d.0
+-1d.1
+-1d.2
+-1d.7
+-1f.0
\-1f.1
The two devices 05:00.0 and 07:00.0 are members of a PEX8311, which
internally contains a PEX8111 PCIe-PCI-X bridge and a PCI-X-Localbus
bridge, the EP 04.0). They both are marked as PCI_EXP_TYPE_PCI_BRIDGE,
and therefore I cannot enable ASPM on the PCIe links on the buses 05
and 07 (marked with a * in the lspci -t output above).
Test scenario:
- enable ASPM by setting the appropriate bits in the 8509 and the 8111
PECS of 03:03.0, 03:04.0, 05:00.0 and 07:00.0
- enable ASPM in the kernel using /sys/module/pcie_aspm/parameters/policy
Roman
--
Roman Fietze Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Xen 4.2 TODO List Update
From: Ian Campbell @ 2012-01-17 10:00 UTC (permalink / raw)
To: xen-devel
Cc: Olaf Hering, Keir Fraser, George Dunlap, Ian Jackson, Tim Deegan,
Roger Pau Monne, Stefano Stabellini, Andres Lagar-Cavilla,
Jan Beulich, Anthony Perard
An updated version of the list is below. Some items are marked "nice to
have" meaning that we don't think they should block the release. I'll
try and post an update on a semi-regular basis as and when things are
completed.
I think I have incorporated all the updates made in the last thread as
well as correctly reflected the status of each item. Please let me know
if something is out of date e.g. if progress has been made which I
haven't reflected below.
hypervisor, blockers:
* round-up of the closing of the security hole in MSI-X
passthrough (uniformly - i.e. even for Dom0 - disallowing write
access to MSI-X table pages). (Jan Beulich, after upstream qemu
patch series also incorporates the respective recent qemu-xen
change)
* domctls / sysctls set up to modify scheduler parameters, like
the credit1 timeslice (and schedule rate, if that ever makes it
in). (George Dunlap)
* get the interface changes for sharing/paging/mem-events done and
dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
Andres Lagar-Cavilla et al)
* mem event ring management posted, seems close to going
in.
* sharing patches posted
*
tools, blockers:
* libxl stable API -- we would like 4.2 to define a stable API
which downstream's can start to rely on not changing. Aspects of
this are:
* event handling (Ian Jackson, posted several rounds,
nearing completion?)
* drop libxl_device_model_info (move bits to build_info or
elsewhere as appropriate) (Ian Campbell, first RFC sent)
* add libxl_defbool and generally try and arrange that
memset(foo,0,...) requests the defaults (Ian Campbell,
first RFC sent)
* The topologyinfo datastructure should be a list of
tuples, not a tuple of lists. (nobody currently looking
at this, not 100% sure this makes sense, could possibly
defer and change after 4.2 in a compatible way)
* Block script support -- can be done post 4.2? should be
nice to have not blocker? Somewhere on IanJ's todo?
* xl to use json for machine readable output instead of sexp by
default (Ian Campbell to revisit existing patch)
* xl feature parity with xend wrt driver domain support (George
Dunlap)
* Integrate qemu+seabios upstream into the build (Stefano to
repost). No change in default qemu for 4.2.
* More formally deprecate xm/xend. Manpage patches already in
tree. Needs release noting and communication around -rc1 to
remind people to test xl.
hypervisor, nice to have:
* solid implementation of sharing/paging/mem-events (using work
queues) (Tim Deegan, Olaf Herring et al)
* A long standing issue is a fully synchronized p2m (locking
lookups) (Andres Lagar-Cavilla)
tools, nice to have:
* Hotplug script stuff -- internal to libxl (I think, therefore I
didn't put this under stable API above) but still good to have
for 4.2? Roger Pau Monet was looking at this but its looking
like a big can-o-worms. (discussion on-going)
* Upstream qemu feature patches:
* Upstream qemu PCI passthrough support (Anthony Perard)
* Upstream qemu save restore (Anthony Perard)
* Nested-virtualisation (currently should be marked experimental,
likely to release that way? Consider nested-svm separate to
nested-vmx. Nested-svm is in better shape)
^ permalink raw reply
* Re: Getting vom synch to asynch algorithms
From: Herbert Xu @ 2012-01-17 9:58 UTC (permalink / raw)
To: Markus Stockhausen; +Cc: linux-crypto
In-Reply-To: <CB38925E.3194%markus.stockhausen@gmx.de>
Markus Stockhausen <markus.stockhausen@gmx.de> wrote:
>
> Maybe someone can enlighten me. These days a pcrypt module was mentioned
> that could help, but my router has only on CPU so there is no load to
> distribute. What will be the best way to make the kernel stable with
> high encryption CPU load?
pcrypt might actually work although for your purpose cryptd
would be the better option.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/2] powerpc/dts: Add magic-packet properties for etsec
From: Xie Xiaobo @ 2012-01-17 9:59 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Xie Xiaobo
In-Reply-To: <1326794391-6105-1-git-send-email-X.Xie@freescale.com>
The properties indicates that the hardware supports waking up via magic packet.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi | 3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
index a1979ae..3b0650a 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x24000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@24000 {
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <29 2 0 0 30 2 0 0 34 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
index 4c4fdde..96693b4 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x25000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@25000 {
compatible = "gianfar";
reg = <0x25000 0x1000>;
ranges = <0x0 0x25000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <35 2 0 0 36 2 0 0 40 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
index 4b8ab43..6b3fab1 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x26000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@26000 {
compatible = "gianfar";
reg = <0x26000 0x1000>;
ranges = <0x0 0x26000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <31 2 0 0 32 2 0 0 33 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
index 40c9137..0da592d 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x27000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@27000 {
compatible = "gianfar";
reg = <0x27000 0x1000>;
ranges = <0x0 0x27000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <37 2 0 0 38 2 0 0 39 2 0 0>;
};
--
1.7.5.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/dts: Add some DTS nodes and attributes for mpc8536ds
From: Xie Xiaobo @ 2012-01-17 9:59 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Xie Xiaobo
1. Add partitions for NOR and NAND Flash.
2. Additional attributes for sdhc.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 5 ++
arch/powerpc/boot/dts/mpc8536ds.dts | 6 ++-
arch/powerpc/boot/dts/mpc8536ds.dtsi | 93 +++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 8 ++-
4 files changed, 109 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
index 89af626..3ebfda3 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
@@ -236,6 +236,11 @@
};
/include/ "pq3-esdhc-0.dtsi"
+
+ sdhc@2e000 {
+ compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
+ };
+
/include/ "pq3-sec3.0-0.dtsi"
/include/ "pq3-mpic.dtsi"
/include/ "pq3-mpic-timer-B.dtsi"
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts b/arch/powerpc/boot/dts/mpc8536ds.dts
index c158815..1973622 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -1,7 +1,7 @@
/*
* MPC8536 DS Device Tree Source
*
- * Copyright 2008 Freescale Semiconductor, Inc.
+ * Copyright 2008, 2011 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -34,6 +34,10 @@
lbc: localbus@ffe05000 {
reg = <0 0xffe05000 0 0x1000>;
+
+ ranges = <0x0 0x0 0x0 0xe8000000 0x08000000
+ 0x2 0x0 0x0 0xffa00000 0x00040000
+ 0x3 0x0 0x0 0xffdf0000 0x00008000>;
};
board_soc: soc: soc@ffe00000 {
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dtsi b/arch/powerpc/boot/dts/mpc8536ds.dtsi
index 1462e4c..cc46dbd 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8536ds.dtsi
@@ -32,6 +32,99 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+&lbc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ reg = <0x0 0x03000000>;
+ label = "ramdisk-nor";
+ };
+
+ partition@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ label = "diagnostic-nor";
+ read-only;
+ };
+
+ partition@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ label = "dink-nor";
+ read-only;
+ };
+
+ partition@4000000 {
+ reg = <0x04000000 0x00400000>;
+ label = "kernel-nor";
+ };
+
+ partition@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ label = "fs-nor";
+ };
+
+ partition@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ label = "dtb-nor";
+ };
+
+ partition@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ label = "u-boot-nor";
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8536-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ partition@0 {
+ reg = <0x0 0x02000000>;
+ label = "u-boot-nand";
+ read-only;
+ };
+
+ partition@2000000 {
+ reg = <0x02000000 0x10000000>;
+ label = "fs-nand";
+ };
+
+ partition@12000000 {
+ reg = <0x12000000 0x08000000>;
+ label = "ramdisk-nand";
+ };
+
+ partition@1a000000 {
+ reg = <0x1a000000 0x04000000>;
+ label = "kernel-nand";
+ };
+
+ partition@1e000000 {
+ reg = <0x1e000000 0x01000000>;
+ label = "dtb-nand";
+ };
+
+ partition@1f000000 {
+ reg = <0x1f000000 0x21000000>;
+ label = "empty-nand";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,mpc8536ds-fpga-pixis";
+ reg = <0x3 0x0 0x8000>;
+ };
+};
+
&board_soc {
i2c@3100 {
rtc@68 {
diff --git a/arch/powerpc/boot/dts/mpc8536ds_36b.dts b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
index 8f4b929..f8a3b34 100644
--- a/arch/powerpc/boot/dts/mpc8536ds_36b.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
@@ -1,7 +1,7 @@
/*
* MPC8536DS Device Tree Source (36-bit address map)
*
- * Copyright 2008-2009 Freescale Semiconductor, Inc.
+ * Copyright 2008-2009, 2011 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -33,7 +33,11 @@
};
lbc: localbus@ffe05000 {
- reg = <0 0xffe05000 0 0x1000>;
+ reg = <0xf 0xffe05000 0 0x1000>;
+
+ ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
+ 0x2 0x0 0xf 0xffa00000 0x00040000
+ 0x3 0x0 0xf 0xffdf0000 0x00008000>;
};
board_soc: soc: soc@fffe00000 {
--
1.7.5.1
^ permalink raw reply related
* Re: [patch v2, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP
From: Štefan Gula @ 2012-01-17 9:56 UTC (permalink / raw)
To: David Lamparter
Cc: Alexey Kuznetsov, David S. Miller, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20120117095049.GG1077372@jupiter.n2.diac24.net>
Dňa 17. januára 2012 10:50, David Lamparter <equinox@diac24.net> napísal/a:
> On Mon, Jan 16, 2012 at 11:52:25PM +0100, Štefan Gula wrote:
>> Dňa 16. januára 2012 21:29, David Lamparter <equinox@diac24.net> napísal/a:
>> > At the risk of repeating myself, Linux GRE support already has
>> > provisions for multipoint tunnels. And unlike your code, those reuse the
>> > existing neighbor table infrastructure, including all of its user
>> > interface and introspection capabilities.
>> >
>> > It's actually slightly visible in your patch:
>> >
>> > On Mon, Jan 16, 2012 at 08:45:14PM +0100, Štefan Gula wrote:
>> >> +++ linux-3.2.1-my/net/ipv4/ip_gre.c 2012-01-16 20:42:03.000000000 +0100
>> >> @@ -716,7 +942,19 @@ static netdev_tx_t ipgre_tunnel_xmit(str
>> > [...]
>> >> /* NBMA tunnel */
>> >>
>> >> if (skb_dst(skb) == NULL) {
>> >
>> >
>> > -David
>>
>> That code you are referring to is used only for routed traffic inside
>> GRE - L3 traffic over L3 routed infrastructure. My patch is dealing
>> with L2 traffic over L3 routed infrastructure - so the decision here
>> is based on destination MAC addresses and not based on IPv4/IPv6
>> addresses.
>
> Yes, it currently only does IPv4/IPv6 -> IPv4 through the neighbor
> table. That doesn't mean it can't be extended to handle ethernet
> addresses the same way.
>
>
> -David
Routing mechanisms and switching mechanisms works completely
different, in switching you simply don't have anything like next-hop
from routing, which can be resolved by utilizing modified ARP message
and there is also absolutely no hierarchy in MAC address (like you
have in routing table), so I seriously doubt that it can be done the
same way, but I am opened to ideas here. So how would you do like to
do that?
^ permalink raw reply
* [U-Boot] [PATCH 1/2] mmc: access mxcmmc from mx31 boards
From: Stefano Babic @ 2012-01-17 9:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326290363-4767-2-git-send-email-helmut.raiger@hale.at>
On 11/01/2012 14:59, Helmut Raiger wrote:
> This patch modifies mxcmmc.c to be used
> not only by i.MX27 but also by i.MX31 boards.
> Both use the same SD controller, but have different
> clock set-ups.
> The i.MX27 imx_get_XXXclock functions are made static to
> generic.c and a public mxc_get_clock() function
> is provided. Pins, base address and prototypes for
> an i.MX31 specific board_init_mmc() are provided.
> Some of the i.MX27 clock getters are unused and marked
> as such to avoid warnings (./MAKEALL -s mx27), but
> the code was left in for future use.
>
> Signed-off-by: Helmut Raiger <helmut.raiger@hale.at>
> ---
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH stable 3/4] block: fail SCSI passthrough ioctls on partition devices
From: Paolo Bonzini @ 2012-01-17 9:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: stable, Linus Torvalds, linux-kernel, Petr Matousek, linux-scsi,
Jens Axboe, James Bottomley
In-Reply-To: <1326773222.2819.172.camel@deadeye>
On 01/17/2012 05:07 AM, Ben Hutchings wrote:
> Signed-off-by: Linus Torvalds<torvalds@linux-foundation.org>
> [bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
> ENOTTY, so we must return ENOTTY directly]
> Signed-off-by: Ben Hutchings<ben@decadent.org.uk>
Have you tested 32-on-64? I already did this change in the version for
3.2 stable, but sd_compat_ioctl has to keep ENOIOCTLCMD:
> [ Cherry picked from 3ed4e7ba4be8c72051d87dcb2dec279d97a18d41
>
> Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
> and -ENOIOCTLCMD from sd_compat_ioctl. ]
Paolo
^ permalink raw reply
* Re: [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS params
From: Antti P Miettinen @ 2012-01-17 9:54 UTC (permalink / raw)
To: linux-pm; +Cc: cpufreq
In-Reply-To: <810586B7581CC8469141DADEBC37191204112D@BGSMSX102.gar.corp.intel.com>
"Mansoor, Illyas" <illyas.mansoor@intel.com> writes:
> How about a notion of platform agnostic freq metric that can then me
> normalized to The platform available freq's like for example a value
> 100 that denotes top freq, that Way PM QoS can then ajust the
> application requested number to platform available Freq.
That will not necessarily help the PM QoS client in choosing the
appropriate performance level. On one platform the appropriate level for
a given situation might be 5% of max, on another 75%. I think the hairy
issue is that there are so many application oriented performance metrics
(MIPS, FLOPS, FPS, milliseconds..).
--Antti
^ permalink raw reply
* Re: [PATCH][GIT PULL][v3.3] tracing: Add header wrappers event_headers_start.h and event_headers_end.h
From: Ingo Molnar @ 2012-01-17 9:54 UTC (permalink / raw)
To: Steven Rostedt; +Cc: LKML, Andrew Morton, Frederic Weisbecker
In-Reply-To: <1326754637.7642.177.camel@gandalf.stny.rr.com>
* Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Ingo,
>
> This is actually a special pull request. This patch adds two new files
> that are not used by anyone. The rational for this is, they will be
> required for v3.4 and I want to make the transition in linux-next as
> smooth as possible. Let me explain the situation.
>
> There has been more and more cases where trace/events/*.h headers have
> been showing up in normal header files. This is fine unless one of these
> normal header files ends up included in another trace/events/*.h file.
> What happens then, is when the CREATE_TRACE_POINTS is defined both
> headers get evaluated. This means the C functions to create the
> tracepoints are created for both the initial trace/events/*.h header, as
> well as the one that got included by the normal header file. This makes
> the build fail. We've already had to fix this up a few times to handle
> these cases.
>
> I added two header files:
>
> include/trace/event_headers_start.h
> include/trace/event_headers_end.h
>
> These headers add some macro magic to handle the nested tracepoint event
> headers that was described above.
>
> The way this works is that all tracepoint event headers must include
> these two headers around their other includes. For example trace/sched.h
> will now have:
>
> #include <trace/event_headers_start.h>
> #include <linux/sched.h>
> #include <linux/tracepoint.h>
> #include <trace/event_headers_end.h>
>
> I've already updated all the tracepoint headers inside the latest
> kernel. I searched all headers with "TRACE_EVENT" in them to catch
> headers outside of trace/events/ that define trace event headers.
>
> The issue I see, and why I want this patch into 3.3 is that I have a
> warning that will print if someone adds a new tracepoint event header
> and doesn't add these files. If this warning goes into linux-next, and
> someone adds a new tracepoint event header, they will start getting this
> warning. The only way for them to stop it, is to include the above
> wrappers. The problem is, the wrappers will not exist in the kernel that
> gets pulled into linux-next, unless we push them now into 3.3.
>
> Now if you feel this is too much and do not want to include files into
> 3.3 that are not being used, I can hold off the warning patch until 3.5,
> and then we may have a mixture of files with and without these header
> wrappers in 3.4.
>
> What's your thoughts on this?
Hm, i don't really like the extra complexity - this code
*really* does not need any more complexity ...
How about the low-tech solution of adding some text between
'/* */' markers to warns that these headers should not be
included in ordinary headers?
The build error will pinpoint the bug anyway, it's not like the
kernel can be broken in any dangerous way.
Thanks,
Ingo
^ permalink raw reply
* Re: x86/mce: machine check warning during poweroff
From: Srivatsa S. Bhat @ 2012-01-17 9:52 UTC (permalink / raw)
To: Suresh Siddha
Cc: Linus Torvalds, Ming Lei, Djalal Harouni, Borislav Petkov,
Tony Luck, Hidetoshi Seto, Ingo Molnar, Andi Kleen, linux-kernel,
Greg Kroah-Hartman, Kay Sievers, gouders, Marcos Souza,
Linux PM mailing list, Rafael J. Wysocki, tglx@linutronix.de,
prasad, justinmattock, Jeff Chua, Peter Zijlstra, Mel Gorman,
Gilad Ben-Yossef
In-Reply-To: <1326766892.16150.21.camel@sbsiddha-desk.sc.intel.com>
On 01/17/2012 07:51 AM, Suresh Siddha wrote:
> On Sat, 2012-01-14 at 08:11 +0530, Srivatsa S. Bhat wrote:
>> Of course, the warnings at drivers/base/core.c: device_release()
>> as well as the IPI to offline cpu warnings still appear but are rather
>> unrelated and harmless to the issue being discussed.
>
> As far the IPI offline cpu warnings are concerned, appended patch should
> fix it. Can you please give it a try? Peterz, can you please review and
> queue it after Srivatsa confirms that it works? Thanks.
Hi Suresh,
Thanks for the patch, but unfortunately it doesn't fix the problem!
Exactly the same stack traces are seen during a CPU Hotplug stress test.
(I didn't even have to stress it - it is so fragile that just a script
to offline all cpus except the boot cpu was good enough to reproduce the
problem easily.)
[ 562.269083] ------------[ cut here ]------------
[ 562.273079] WARNING: at arch/x86/kernel/smp.c:120 native_smp_send_reschedule+0x59/0x60()
[ 562.273079] Hardware name: IBM System x -[7870C4Q]-
[ 562.273079] Modules linked in: ipv6 cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode fuse loop dm_mod iTCO_wdt i7core_edac i2c_i801 ioatdma cdc_ether i2c_core tpm_tis bnx2 shpchp usbnet pcspkr mii iTCO_vendor_support edac_core serio_raw dca sg rtc_cmos tpm tpm_bios pci_hotplug button uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif edd ext3 mbcache jbd fan processor mptsas mptscsih mptbase scsi_transport_sas scsi_mod thermal thermal_sys hwmon
[ 562.273079] Pid: 6, comm: migration/0 Not tainted 3.2.0-sureshipi-0.0.0.28.36b5ec9-default #2
[ 562.273079] Call Trace:
[ 562.273079] <IRQ> [<ffffffff810213d9>] ? native_smp_send_reschedule+0x59/0x60
[ 562.273079] [<ffffffff8103cf4a>] warn_slowpath_common+0x7a/0xb0
[ 562.273079] [<ffffffff8103cf95>] warn_slowpath_null+0x15/0x20
[ 562.273079] [<ffffffff810213d9>] native_smp_send_reschedule+0x59/0x60
[ 562.273079] [<ffffffff81082d65>] trigger_load_balance+0x185/0x500
[ 562.273079] [<ffffffff81082d9b>] ? trigger_load_balance+0x1bb/0x500
[ 562.273079] [<ffffffff81073db7>] scheduler_tick+0x107/0x170
[ 562.273079] [<ffffffff8104e6f7>] update_process_times+0x67/0x80
[ 562.273079] [<ffffffff8109c64f>] tick_sched_timer+0x5f/0xc0
[ 562.273079] [<ffffffff8109c5f0>] ? tick_nohz_handler+0x100/0x100
[ 562.273079] [<ffffffff8106a85e>] __run_hrtimer+0x12e/0x330
[ 562.273079] [<ffffffff8106aca7>] hrtimer_interrupt+0xc7/0x1f0
[ 562.273079] [<ffffffff81022ff4>] smp_apic_timer_interrupt+0x64/0xa0
[ 562.273079] [<ffffffff814a2a33>] apic_timer_interrupt+0x73/0x80
[ 562.273079] <EOI> [<ffffffff810c563a>] ? stop_machine_cpu_stop+0xda/0x130
[ 562.273079] [<ffffffff810c5560>] ? stop_one_cpu_nowait+0x50/0x50
[ 562.273079] [<ffffffff810c5279>] cpu_stopper_thread+0xd9/0x1b0
[ 562.273079] [<ffffffff81498ddf>] ? _raw_spin_unlock_irqrestore+0x3f/0x80
[ 562.273079] [<ffffffff810c51a0>] ? res_counter_init+0x50/0x50
[ 562.273079] [<ffffffff810a2add>] ? trace_hardirqs_on_caller+0x12d/0x1b0
[ 562.273079] [<ffffffff810a2b6d>] ? trace_hardirqs_on+0xd/0x10
[ 562.273079] [<ffffffff810c51a0>] ? res_counter_init+0x50/0x50
[ 562.273079] [<ffffffff8106553e>] kthread+0x9e/0xb0
[ 562.273079] [<ffffffff814a3334>] kernel_thread_helper+0x4/0x10
[ 562.273079] [<ffffffff81499174>] ? retint_restore_args+0x13/0x13
[ 562.273079] [<ffffffff810654a0>] ? __init_kthread_worker+0x70/0x70
[ 562.273079] [<ffffffff814a3330>] ? gs_change+0x13/0x13
[ 562.273079] ---[ end trace 4efec5b2532b902d ]---
I have a few questions regarding the synchronization with CPU Hotplug.
What guarantees that the code which selects and IPIs the new ilb is totally
race-free with respect to CPU hotplug and we will never IPI an offline CPU?
(In 3.2-rc7 I hadn't hit the IPI to offline cpu issue (the above stack trace)
as far as I remember.)
While trying to figure out what changed in the 3.3 merge window, I added a
WARN_ON in the 3.2-rc7 kernel as shown below:
static void nohz_balancer_kick(int cpu)
{
....
if (!cpu_rq(ilb_cpu)->nohz_balance_kick) {
cpu_rq(ilb_cpu)->nohz_balance_kick = 1;
smp_mb();
/*
* Use smp_send_reschedule() instead of resched_cpu().
* This way we generate a sched IPI on the target cpu which
* is idle. And the softirq performing nohz idle load balance
* will be run before returning from the IPI.
*/
==========> if (!cpu_active(ilb_cpu))
==========> WARN_ON(1);
smp_send_reschedule(ilb_cpu);
}
return;
}
As expected, I hit this warning during my CPU hotplug stress tests. I am sure
this happens on latest kernel too (3.3 merge window), since there is
apparently no change in that part of code in that aspect.
So, while selecting the new ilb, why are we not careful enough to ensure we
don't select a cpu that is going offline? Is this by design (to avoid some
overhead) or is this a bug? (As demonstrated above, this issue is in 3.2-rc7
as well.)
And the only reason I can think why we did not hit the "IPI to offline CPU"
issue in 3.2-rc7 kernel is that the race window (with CPU offline) was
probably too small and _not_ because we explicitly synchronized with CPU
Hotplug.
Probably I am missing something obvious... I would be grateful if you could
kindly help me understand how this works..
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: [RFC] mmc: core: add the capability for broken voltage
From: Kyungmin Park @ 2012-01-17 9:53 UTC (permalink / raw)
To: Adrian Hunter; +Cc: Jaehoon Chung, linux-mmc, Chris Ball, Mark Brown
In-Reply-To: <4F15415C.6020205@intel.com>
On 1/17/12, Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 17/01/12 11:05, Kyungmin Park wrote:
>> On 1/17/12, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>> On 16/01/12 10:49, Jaehoon Chung wrote:
>>>> This patch is added the MMC_CAP2_BROKEN_VOLTAGE.
>>>>
>>>> if the voltage didn't satisfy between min_uV and max_uV,
>>>
>>> Why is the fixed voltage not in the acceptable range for the card?
>>> Doesn't that risk breaking the card?
>> Hi Adrian,
>>
>> I don't know, they uses the not supported voltage. but it's worked
>> properly for long time.
>
> I wonder if there is a generic problem here that this fix hides.
> It would be nice to have an explanation. Do you know:
> - what is the fixed voltage?
Now 2.8V is supplied by gpio so make it fixed regulator
> - is it supplying VCC or VCCQ?
VDD in our schematic.
> - what is the contents of the OCR register?
In sdhci_set_power(). it returns SDHCI_POWER_180, SDHCI_POWER_300, and
SDHCI_POWER_330.
In probe time, it return the SDHCI_POWER_330, and but fixed regulator
returns the 2.8V so it calls regulator_set_voltage. and return -EINVAL
since it's fixed regulator.
Of course we can make workaround, set fixed regulator voltage as 3.3V.
Even though actual voltage is 2.8V. so it's ambiguous.
that's reason introduces the new quirk.
Thank you,
Kyungmin Park
>
>> Galaxy S2 also uses the same voltage as ours.
>>
>> I also think the modify the regulator framework to support voltage
>> change at fixed regulator. but it's not good idea and doesn't match
>> the regulator concept. so modify the sdhci codes to support our
>> boards.
>>
>> Thank you,
>> Kyungmin Park
>>>
>>>> try to change the voltage in core.c.
>>>> When change the voltage, maybe use the regulator_set_voltage().
>>>>
>>>> In regulator_set_voltage(), check the below condition.
>>>>
>>>> /* sanity check */
>>>> if (!rdev->desc->ops->set_voltage &&
>>>> !rdev->desc->ops->set_voltage_sel) {
>>>> ret = -EINVAL;
>>>> goto out;
>>>> }
>>>>
>>>> If Some-board should use the fixed-regulator, always return -EINVAL.
>>>> Then, eMMC didn't initialize always.
>>>>
>>>> So if use the fixed-regulator or etc, we need to add the
>>>> MMC_CAP2_BROKEN_VOLTAGE.
>>>>
>>>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>>>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>> ---
>>>> drivers/mmc/core/core.c | 4 ++++
>>>> include/linux/mmc/host.h | 1 +
>>>> 2 files changed, 5 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>>> index bec0bf2..6848789 100644
>>>> --- a/drivers/mmc/core/core.c
>>>> +++ b/drivers/mmc/core/core.c
>>>> @@ -1121,6 +1121,10 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
>>>> * might not allow this operation
>>>> */
>>>> voltage = regulator_get_voltage(supply);
>>>> +
>>>> + if (mmc->caps2 & MMC_CAP2_BROKEN_VOLTAGE)
>>>> + min_uV = max_uV = voltage;
>>>> +
>>>> if (voltage < 0)
>>>> result = voltage;
>>>> else if (voltage < min_uV || voltage > max_uV)
>>>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>>>> index dd13e05..5659aee 100644
>>>> --- a/include/linux/mmc/host.h
>>>> +++ b/include/linux/mmc/host.h
>>>> @@ -257,6 +257,7 @@ struct mmc_host {
>>>> #define MMC_CAP2_HS200_1_2V_SDR (1 << 6) /* can support */
>>>> #define MMC_CAP2_HS200 (MMC_CAP2_HS200_1_8V_SDR | \
>>>> MMC_CAP2_HS200_1_2V_SDR)
>>>> +#define MMC_CAP2_BROKEN_VOLTAGE (1 << 7) /* Use the broken voltage */
>>>>
>>>> mmc_pm_flag_t pm_caps; /* supported pm features */
>>>> unsigned int power_notify_type;
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [U-Boot] [PATCH] net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back
From: Wolfgang Denk @ 2012-01-17 9:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4F149CCB.6070307@itwatchdogs.com>
Dear Zach Sadecki,
In message <4F149CCB.6070307@itwatchdogs.com> you wrote:
> This patch will also fix a problem with mx28 boards that are depending
> on the OCOTP bits to set the MAC address (like the Denx m28 board). Now
> it simply fails with a "Warning: failed to set MAC address" if there's
> no environment variable instead of using the OCOTP bits like it should.
> This patch will fix that.
But there _should_ always be a warning message if the environment
variable is missing.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Heavier than air flying machines are impossible.
-- Lord Kelvin, President, Royal Society, c. 1895
^ permalink raw reply
* Re: Driver domains and hotplug scripts, redux
From: Ian Campbell @ 2012-01-17 9:52 UTC (permalink / raw)
To: Roger Pau Monné
Cc: xen-devel@lists.xensource.com, Ian Jackson, Stefano Stabellini
In-Reply-To: <CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
On Tue, 2012-01-17 at 09:40 +0000, Roger Pau Monné wrote:
> 2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> > However xend should not be transition to this new scheme but should
> > continue to use its existing scripts in the current manner.
> >
> > There was a conversation last year[0] about how a toolstack could
> > opt-in/out of the use of the hotplug scripts. We decided that toolstacks
> > should have to opt into the use of these scripts, by touching a stamp
> > file.
> >
> > Although this wasn't implemented yet (unless I missed it) I guess the
> > same scheme would apply to this work if that sort of thing turns out to
> > be necessary.
>
> Sorry for replying so many times, this is a big maybe, and possibly
> it's too drastic, but after this changes xl and xend will not be
> compatible anymore, so why don't we disable xend by default, and only
> build xl?
I don't think they are compatible now, are they? I've certainly seen odd
behaviour when using xl with xend (accidentally) running, usually xend
reaps the domain I've just started...
I'm all for disabling the build of xend by default but I had assumed
that others would think 4.2 was rather an aggressive timeline for that.
> When the new configure script is in, it will be trivial to select if
> you want xl or xend, and only install one of those. Adding the option
> --enable-xend should disable xl and only build and install xend
> (printing a very big warning that xend is deprecated).
I don't think --enable-xend should ever disable xl (or vice versa). Many
folks (e.g. distros) will want to build both, perhaps to package them in
two different binary packages, but certainly to offer their users the
choice, at least for the time being.
>
> > Ian.
> >
> > [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH] Btrfs: hold enough space for global_rsv
From: Liu Bo @ 2012-01-17 9:51 UTC (permalink / raw)
To: linux-btrfs
I've kept hitting enospc warnings of global_rsv while running defragment on
files:
btrfs: block rsv returned -28
WARNING: at fs/btrfs/extent-tree.c:5984 btrfs_alloc_free_block+0x333/0x340 [btrfs]()
...
I used a fio jobs to create a file with lots of fragments:
$ filefrag /mnt/btrfs/foobar
/mnt/btrfs/foobar: 66964 extents found
and then "btrfs fi defrag /mnt/btrfs/foobar && sync" would pop the warnings.
I found that the global_rsv size is just not enough for defragment, and didn't
find any space leak in using global_rsv, so double it and go ahead.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
---
fs/btrfs/extent-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 8603ee4..77ea23c 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3979,7 +3979,7 @@ static u64 calc_global_metadata_size(struct btrfs_fs_info *fs_info)
num_bytes += div64_u64(data_used + meta_used, 50);
if (num_bytes * 3 > meta_used)
- num_bytes = div64_u64(meta_used, 3);
+ num_bytes = div64_u64(meta_used, 3) * 2;
return ALIGN(num_bytes, fs_info->extent_root->leafsize << 10);
}
--
1.6.5.2
^ permalink raw reply related
* Re: Updated btrfs/crypto snappy interface ready for merging
From: Andi Kleen @ 2012-01-17 9:51 UTC (permalink / raw)
To: Li Zefan; +Cc: Andi Kleen, Chris Mason, linux-kernel, linux-btrfs
In-Reply-To: <4F153EFA.4070404@cn.fujitsu.com>
> At first I saved emails and patched them in linux-btrfs git tree, and I
> got weired result. Then I pulled the snappy branch directly, and now
> nothing is wrong.. Sorry for the noise.
np. Thanks for testing.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 6/9] ACPI, Add RAM mapping support to ACPI atomic IO support
From: Len Brown @ 2012-01-17 9:51 UTC (permalink / raw)
To: Myron Stowe; +Cc: Huang Ying, linux-kernel, Tony Luck, linux-acpi
In-Reply-To: <CAL-B5D1z35ReG9dKVBLNkktrJ-c8OVspsCYTUAO16wCK1B_4dA@mail.gmail.com>
On 11/08/2011 04:38 PM, Myron Stowe wrote:
> On Mon, Nov 7, 2011 at 7:39 PM, Huang Ying <ying.huang@intel.com> wrote:
>> On one of our testing machine, the following EINJ command lines:
>>
>> # echo 0x10000000 > param1
>> # echo 0xfffffffffffff000 > param2
>> # echo 0x8 > error_type
>> # echo 1 > error_inject
>>
>> Will get:
>>
>> echo: write error: Input/output error
>>
>> The EIO comes from:
>>
>> rc = apei_exec_pre_map_gars(&trigger_ctx);
>>
>> The root cause is as follow. Normally, ACPI atomic IO support is used
>> to access IO memory. But in EINJ of that machine, it is used to
>> access RAM to trigger the injected error. And the ioremap() called by
>> apei_exec_pre_map_gars() can not map the RAM.
>>
>> This patch add RAM mapping support to ACPI atomic IO support to
>> satisfy EINJ requirement.
>>
>> Signed-off-by: Huang Ying <ying.huang@intel.com>
>> Tested-by: Tony Luck <tony.luck@intel.com>
>> ---
>> drivers/acpi/atomicio.c | 34 ++++++++++++++++++++++++++++++----
>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>
>
> Hi Huang:
>
> This patch collides with my series to remove atomicio.[ch]:
> https://mail.google.com/mail/?shva=1#label/linux-acpi+list/133805812264a542
> and I don't want such functionality to get lost if/when the removal series
> is accepted. I'm interested in working with you, not against you, so would
> you like me to do anything with respect to this patch within the osl.c based
> mapping routines so this capability would not become lost?
>
> The obvious choices would be for me to post a new patch, copying this
> functionality into osl.c's mapping routines, that would apply on top of the
> removal series. Another tact could be for me to do basically the same
> thing but within the removal series (by adding this into it, and reposting).
> The latter tactic seems like it could be a constant problem if more changes
> to atomicio occur during this interim period. Of course you may have other
> ideas here as how to progress.
>
> This type of occurrence, among many others, is a good example of why we
> need to get down to just one set of mapping routines as soon as possible.
> During this interim period I'll try and monitor the linux-acpi-list
> for future such
> occurrences but if you could, please try and cc me on any future atomicio
> modifications.
>
> Thanks,
> Myron
Hi Myron,
I've included your 1-3 of "ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch]"
on top of Ying's series "[PATCH 00/11] ACPI, APEI, Patches for 3.3"
Can you re-fresh your #4 so it applies on top?
Would be delightful to get rid of atomicio.
You can pull my branch from
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git next
thanks!
-Len
thanks,
-Len
^ permalink raw reply
* Re: [patch v2, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP
From: David Lamparter @ 2012-01-17 9:50 UTC (permalink / raw)
To: Štefan Gula
Cc: David Lamparter, Alexey Kuznetsov, David S. Miller, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CAGsizz+NuyPHtau3b2LjCqdAGyrPf1-08v2uD0xJBSJS9qs5Fg@mail.gmail.com>
On Mon, Jan 16, 2012 at 11:52:25PM +0100, Štefan Gula wrote:
> Dňa 16. januára 2012 21:29, David Lamparter <equinox@diac24.net> napísal/a:
> > At the risk of repeating myself, Linux GRE support already has
> > provisions for multipoint tunnels. And unlike your code, those reuse the
> > existing neighbor table infrastructure, including all of its user
> > interface and introspection capabilities.
> >
> > It's actually slightly visible in your patch:
> >
> > On Mon, Jan 16, 2012 at 08:45:14PM +0100, Štefan Gula wrote:
> >> +++ linux-3.2.1-my/net/ipv4/ip_gre.c 2012-01-16 20:42:03.000000000 +0100
> >> @@ -716,7 +942,19 @@ static netdev_tx_t ipgre_tunnel_xmit(str
> > [...]
> >> /* NBMA tunnel */
> >>
> >> if (skb_dst(skb) == NULL) {
> >
> >
> > -David
>
> That code you are referring to is used only for routed traffic inside
> GRE - L3 traffic over L3 routed infrastructure. My patch is dealing
> with L2 traffic over L3 routed infrastructure - so the decision here
> is based on destination MAC addresses and not based on IPv4/IPv6
> addresses.
Yes, it currently only does IPv4/IPv6 -> IPv4 through the neighbor
table. That doesn't mean it can't be extended to handle ethernet
addresses the same way.
-David
^ permalink raw reply
* Re: [PATCH] sched: Update scheduler stat documentation.
From: Ingo Molnar @ 2012-01-17 9:50 UTC (permalink / raw)
To: Rakib Mullick; +Cc: peterz, linux-kernel
In-Reply-To: <CADZ9YHh9rnTom8dRk5PBdY0Qu6WQVNpUr2jJDeyqg7fxTiu1gg@mail.gmail.com>
* Rakib Mullick <rakib.mullick@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 2:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> >
> > Yes - but we should also change it to export a value of zero.
> > The field is a legacy 'array expirations' field, and as such it
> > should be zero.
> >
>
> Ok, thanks for suggestions. Please, look at the following patch, it's
> been roughly created to address your suggestion. If it looks okay,
> then I can send formal patch (perhaps two separate patches?). In this
> way, I think we can also remove rq->sched_switch field (not done in
> this patch)?
>
> diff --git a/Documentation/scheduler/sched-stats.txt
> b/Documentation/scheduler/sched-stats.txt
> index 1cd5d51..cc2d107 100644
> --- a/Documentation/scheduler/sched-stats.txt
> +++ b/Documentation/scheduler/sched-stats.txt
> @@ -38,7 +38,8 @@ First field is a sched_yield() statistic:
> 1) # of times sched_yield() was called
>
> Next three are schedule() statistics:
> - 2) # of times we switched to the expired queue and reused it
> + 2) This field is a legacy array expiration field used in O(1) scheduler.
> + But still kept for ABI integrity.
I'd formulate it like this:
> + 2) This field is a legacy array expiration count field
> + used in the O(1) scheduler. We kept it for ABI
> + compatibility, but it is always set to zero.
> + int rq_sched_switch = 0;
> #ifdef CONFIG_SMP
> struct sched_domain *sd;
> int dcount = 0;
> @@ -34,7 +35,7 @@ static int show_schedstat(struct seq_file *seq, void *v)
> seq_printf(seq,
> "cpu%d %u %u %u %u %u %u %llu %llu %lu",
> cpu, rq->yld_count,
> - rq->sched_switch, rq->sched_count, rq->sched_goidle,
> + rq_sched_switch, rq->sched_count, rq->sched_goidle,
printf can print a 0 value just fine as part of the format
string ... :-)
But yeah, this logic is what i had in mind.
Thanks,
Ingo
^ permalink raw reply
* [U-Boot] [PATCH] i.mx6q: mx6qsabrelite: Add the ethernet function support
From: Stefano Babic @ 2012-01-17 9:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326444976-5492-1-git-send-email-dirk.behme@de.bosch.com>
On 13/01/2012 09:56, Dirk Behme wrote:
> From: Jason Liu <jason.hui@linaro.org>
>
> Signed-off-by: Jason Liu <jason.hui@linaro.org>
> Signed-off-by: Eric Miao <eric.miao@linaro.org>
> CC: Jason Liu <jason.hui@linaro.org>
> CC: Stefano Babic <sbabic@denx.de>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: linux-next: Tree for Jan 13 (lib/digsig.c)
From: Kasatkin, Dmitry @ 2012-01-17 9:48 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, Mimi Zohar
In-Reply-To: <4F10B2EC.1010906@xenotime.net>
On Sat, Jan 14, 2012 at 12:40 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On 01/12/2012 08:58 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20120112:
>
>
> ERROR: "crypto_alloc_shash" [lib/digsig.ko] undefined!
> ERROR: "crypto_shash_final" [lib/digsig.ko] undefined!
> ERROR: "crypto_shash_update" [lib/digsig.ko] undefined!
> ERROR: "crypto_destroy_tfm" [lib/digsig.ko] undefined!
>
Hi,
I have done a fix and sent it to linux-security-modules mailing list...
[PATCH 2/4] lib: digital signature dependency fix
Thanks,
Dmitry
>
> Full randconfig file is attached.
>
> --
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* RE: [PATCH] NFC: Add NCI data exchange timer
From: Elias, Ilan @ 2012-01-17 9:48 UTC (permalink / raw)
To: Samuel Ortiz, ilanelias78@gmail.com
Cc: aloisio.almeida@openbossa.org, lauro.venancio@openbossa.org,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1326746252.22824.15.camel@sortiz-mobl>
Hi Samuel,
> > - if (test_and_set_bit(NCI_DATA_EXCHANGE, &ndev->flags))
> > + if (test_and_set_bit(NCI_DATA_EXCHANGE, &ndev->flags)) {
> > + pr_err("unable to exchange data, already in
> progress\n");
> This is not really related to that patch.
>
> > @@ -473,6 +485,8 @@ static struct nfc_ops nci_nfc_ops = {
> > .dev_down = nci_dev_down,
> > .start_poll = nci_start_poll,
> > .stop_poll = nci_stop_poll,
> > + .dep_link_up = NULL,
> > + .dep_link_down = NULL,
> Ditto.
You're correct, I will remove those.
Thanks & BR,
Ilan
^ permalink raw reply
* Re: [PATCH 0/6] x86, UV2: BAU fixes for UV version 2
From: Ingo Molnar @ 2012-01-17 9:47 UTC (permalink / raw)
To: Cliff Wickman; +Cc: linux-kernel, x86
In-Reply-To: <20120116211617.GD5512@sgi.com>
* Cliff Wickman <cpw@sgi.com> wrote:
> Following are 6 patches for using SGI's Altix UV2's Broadcast
> Assist Unit for TLB shootdown.
>
> The first 3 patches are very necessary to using the BAU on
> this new hardware. Number 3 is a large one.
Note that when patches are fixing hardware support it's better
to name them accordingly. I changed all the commit titles to
reflect this fact.
I also added a Cc: stable backporting tag to the first three
commits, they only affect UV code and it's useful to have a
uniform hw platform driver across the stable kernels.
Thanks,
Ingo
^ permalink raw reply
* RE: Pinmux bindings proposal
From: Dong Aisheng-B29396 @ 2012-01-17 9:46 UTC (permalink / raw)
To: Shawn Guo
Cc: Stephen Warren, linus.walleij@stericsson.com,
s.hauer@pengutronix.de, rob.herring@calxeda.com,
kernel@pengutronix.de, cjb@laptop.org,
Simon Glass (sjg@chromium.org), Dong Aisheng,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20120117082334.GA31295@S2101-09.ap.freescale.net>
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo@linaro.org]
> Sent: Tuesday, January 17, 2012 4:24 PM
> To: Dong Aisheng-B29396
> Cc: Stephen Warren; linus.walleij@stericsson.com; s.hauer@pengutronix.de;
> rob.herring@calxeda.com; kernel@pengutronix.de; cjb@laptop.org; Simon Glass
> (sjg@chromium.org); Dong Aisheng; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> Subject: Re: Pinmux bindings proposal
> Importance: High
>
> On Mon, Jan 16, 2012 at 12:50:02PM +0000, Dong Aisheng-B29396 wrote:
> ...
> > > /*
> > > * The actual definition of the complete state of the
> > > * pinmux as required by some driver.
> > > *
> > > * These can be either directly in the device node, or
> > > * somewhere in tegra20.dtsi in order to provide pre-
> > > * selected/common configurations. Hence, they're referred
> > > * to by phandle above.
> > > */
> > > pmx_sdhci_active: {
> > > /*
> > > * Pin mux settings. Mandatory?
> > Mandatory for what?
> >
> > > * Not mandatory if the 1:1 mentioned above is
> > > * extended to 1:n.
> > > *
> > > * Format is <&pmx_controller_phandle
> muxable_entity_id
> > > * selected_function>.
> > > *
> > > * The pmx phandle is required since there may be
> more
> > > * than one pinmux controller in the system. Even if
> > > * this node is inside the pinmux controller itself,
> I
> > > * think it's simpler to just always have this field
> > > * present in the binding for consistency.
> > > *
> > > * Alternative: Format is <&pmx_controller_phandle
> > > * pmx_controller_specific_data>. In this case, the
> > > * pmx controller needs to define #pinmux-mux-cells,
> > > * and provide the pinctrl core with a mapping
> > > * function to handle the rest of the data in the
> > > * property. This is how GPIOs and interrupts work.
> > > * However, this will probably interact badly with
> > > * wanting to parse the entire pinmux map early in
> > > * boot, when perhaps the pinctrl core is
> initialized,
> > > * but the pinctrl driver itself is not.
> > > */
> > > mux =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>
> > > /* Syntax example */
> > > <&foo_pmx FOO_PMX_PG_X
> > > FOO_PMX_MUX_0>;
> > I'm still think how do we construct the pinmux map for such binding.
> > The format you're using is:
> > <&pmx_controller_phandle muxable_entity_id selected_function> For
> > contruct pinmux map, we need to know at least 3 things for a device:
> > a) pinctrl device b) function name c) group name.
> > For a, we can get it from this binding.
> > But for b and c, since they are constants, how to convert to name string?
> >
> I guess, for function name, it should be retrieved from the client device node,
> and for the group name, it should be retrieved from the node here.
>
I guess Stephen's idea is to retrieving the function name and group name
>From the pinctrl driver since Tagre prefers to define those things in driver
Rather than in board file or soc.dts file.
But it does not fit for IMX since we define it in soc.dts.
> For above example, the function name can be picked from sdhci device node
> pinctr-names property I proposed,
If I understand correctly, the pinctrl-names property you proposed represents
The pin group state.
> and the group name can just be
> 'pmx_sdhci_active', which is not a very nice name here and reminds me the
> following point.
>
No, I don't think it's suitable for group name since pmx_sdhci_active is not a
group node (actually it includes many groups).
> Considering the different pinctrl configurations for the same client device
> usually share the same pinmux and only pinconf varies.
I have the same doubts before.
Is there a real case that device has the different pinmux in different state?
Stephen?
> It may worth introducing
> another level phandle reference. Something like the following:
>
> pinmux_sdhci: pinmux-sdhci {
> mux =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>;
> };
>
> pinconf_sdhci_active: pinconf-sdhci-active {
> config =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };
>
> pinconf_sdhci_suspend: pinconf-sdhci-suspend {
> config =
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_TRISTATE 1>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_TRISTATE 1>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
> <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };
>
The config makes sense to me.
The only question is how to get group name to match with the predefined groups.
Besides per pin group configuration support, we may also want per pin configuration
Support as the latest patch sent by Linus.
http://www.spinics.net/lists/arm-kernel/msg155712.html
> pinctrl_sdhci_active: pinctrl-sdhci-active {
> pinmux = <&pinmux_sdhci>;
> pinconf = <&pinconf_sdhci_active>;
> };
>
> pinctrl_sdhci_suspend: pinctrl-sdhci-suspend {
> pinmux = <&pinmux_sdhci>;
> pinconf = <&pinconf_sdhci_suspend>;
> };
>
> sdhci@c8000200 {
> ...
> pinctrl = <&pinctrl_sdhci_active> <&pinctrl_sdhci_suspend>;
> pinctrl-names = "active", "suspend";
> };
>
> This will be pretty useful for imx6 usdhc case, which will have 3 pinctrl
> configuration for each usdhc device (imx6 has 4 usdhc devices), pinctrl-50mhz,
> pinctrl-100mhz and pinctrl-200mhz. All these 3 states have the exactly same
> pinmux settings, and only varies on pinconf.
>
> > > /*
> > > * Pin configuration settings. Optional.
> > > *
> > > * Format is <&pmx_controller_phandle
> muxable_entity_id
> > > * configuration_option configuration_value>.
> > > */
> > > config =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_SLEW_RATE 4>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_SLEW_RATE 8>;
> > > /*
> > > * Perhaps allow additional custom properties here
> to
> > > * express things we haven't thought of. The pinctrl
> > > * drivers would be responsible for parsing them.
> > > */
> > > };
> > > pmx_sdhci_standby: {
> > > mux =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> TEGRA_PMX_MUX_1>;
> > > config =
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_TRISTATE 1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_TRISTATE 1>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
> > > <&tegra_pmx TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_CONF_SLEW_RATE 4>
> > > <&tegra_pmx TEGRA_PMX_PG_DTD
> > > TEGRA_PMX_CONF_SLEW_RATE 8>;
> > > };
> > > };
> > > };
> > >
> > > Integer IDs for "muxable entities": Pins on IMX, pin groups on Tegra:
> > >
> > If "muxable entities" is pins on IMX, I'm wondering how we define the
> > predefined Functions and groups or if we still need to do that.
> >
> Let's put this in the example below.
>
> pinmux_usdhc1: pinmux-usdhc1 {
> mux = <IMX6Q_PAD_SD1_DAT1 0>
> <IMX6Q_PAD_SD1_DAT2 0>
> ...
> };
>
Yes, I agree.
And in this way we're still using virtual groups.
It has no big difference as we did before like:
pinmux-groups {
uart4grp: group@0 {
grp-name = "uart4grp";
grp-pins = <107 108>;
grp-mux = <4 4>;
};
sd4grp: group@1 {
grp-name = "sd4grp";
grp-pins = <170 171 180 181 182 183 184 185 186 187>;
grp-mux = <0 0 1 1 1 1 1 1 1 1>;
};
};
The real problem is do we need to support individual pin mux
Or still using virtual pin group?
For the way Stephen proposed, we can only support individual pin mux
Since IMX pins are not grouped together in HW.
> pinconf_usdhc1_50mhz: pinconf-usdhc1-50mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x834>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x834>
> ...
> };
>
> pinconf_usdhc1_100mhz: pinconf-usdhc1-100mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x330>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x330>
> ...
> };
>
> pinconf_usdhc1_200mhz: pinconf-usdhc1-200mhz {
> config = <IMX6Q_PAD_SD1_DAT1 IMX6Q_PAD_CONF_ALL 0x334>
> <IMX6Q_PAD_SD1_DAT2 IMX6Q_PAD_CONF_ALL 0x334>
> ...
> };
>
> pinctrl_usdhc1_50mhz: pinctrl-usdhc1-50mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_50mhz>;
> };
>
> pinctrl_usdhc1_100mhz: pinctrl-usdhc1-100mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_100mhz>;
> };
>
> pinctrl_usdhc1_200mhz: pinctrl-usdhc1-200mhz {
> pinmux = <&pinmux_usdhc1>;
> pinconf = <&pinconf_usdhc1_200mhz>;
> };
>
> usdhc@02190000 { /* uSDHC1 */
> ...
> pinctrl = <&usdhc1_50mhz>, <&usdhc1_100mhz>, <&usdhc1_200mhz>;
> pinctrl-names = "usdhc1-50mhz", "usdhc1-100mhz", "usdhc1-200mhz";
> };
>
> In this example, we have 3 functions/states for client device usdhc1, "usdhc1-
> 50mhz", "usdhc1-100mhz", and "usdhc1-200mhz". The group is being defined by
> enumerating the pins in property 'mux' of node pinmux_usdhc1.
>
Yes, It's still under development by Linus.
The last patch Linus sent still does not support state change for specific device.
But the method is ok to me.
> > > TEGRA_PMX_PG_DTA
> > > TEGRA_PMX_PG_DTD
> > >
> > > Each individual pinmux driver's bindings needs to define what each
> > > integer ID represents.
> > >
> > Does it mean both pinmux driver and soc.dtsi file need define those
> > macros if dtc Supports constants?
> >
> Yes, I think it does. But we should try to work out some way letting dts and
> linux driver include the same header file to avoid maintaining two copies of the
> same data.
>
I'm also care about the potential consistent issue.
Regards
Dong Aisheng
^ permalink raw reply
* Re: [PATCH] libxl_pci: check that host device is assignable before adding to the domain
From: Ian Campbell @ 2012-01-17 9:47 UTC (permalink / raw)
To: Doug Magee; +Cc: xen-devel@lists.xensource.com, Ian Jackson, Stefano Stabellini
In-Reply-To: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
>
> Signed-off-by: Doug Magee <djmagee@mageenet.net>
Thanks Doug. Would this be better done by adding a call to
libxl_device_pci_list_assignable and looking for the device in it? In
fact from the looks of things this could replace the existing call to
get_all_assigned_devices from .._pci_add since
libxl_device_pci_list_assignable already omits devices which are
assigned to another domain.
Ian.
>
> diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c Mon Jan 16 17:31:25 2012 -0500
> @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
> libxl_device_pci *assigned;
> int num_assigned, i, rc;
> int stubdomid = 0;
> + struct dirent *de;
> + DIR *dir;
> + int assignable = 0;
>
> rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
> if ( rc ) {
> @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
> goto out;
> }
>
> + dir = opendir(SYSFS_PCIBACK_DRIVER);
> + if ( NULL == dir ) {
> + if ( errno == ENOENT ) {
> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> + }else{
> + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> + }
> + rc = ERROR_FAIL;
> + goto out_closedir;
> + }
> +
> + while( (de = readdir(dir)) ) {
> + unsigned dom, bus, dev, func;
> + if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> + continue;
> + if ( dom == pcidev->domain && bus == pcidev->bus &&
> + dev == pcidev->dev && func == pcidev->func ) {
> + assignable = 1;
> + break;
> + }
> + }
> +
> + if ( !assignable ) {
> + rc = ERROR_FAIL;
> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> + goto out_closedir;
> + }
> +
> +
> libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
>
> stubdomid = libxl_get_stubdom_id(ctx, domid);
> @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
> /* stubdomain is always running by now, even at create time */
> rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
> if ( rc )
> - goto out;
> + goto out_closedir;
> }
>
> orig_vdev = pcidev->vdevfn & ~7U;
> @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
> if ( !(pcidev->vdevfn >> 3) ) {
> LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
> rc = ERROR_INVAL;
> - goto out;
> + goto out_closedir;
> }
> if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
> rc = ERROR_FAIL;
> - goto out;
> + goto out_closedir;
> }
> pcidev->vfunc_mask &= pfunc_mask;
> /* so now vfunc_mask == pfunc_mask */
> @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
> }
> }
>
> +out_closedir:
> + closedir(dir);
> out:
> return rc;
> }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.