Re: [git pull] vfs.git part 2
On Thu, Jul 11, 2013 at 02:42:54PM -0700, Linus Torvalds wrote:
> On Wed, Jul 3, 2013 at 5:29 AM, Al Viro wrote:
> > Assorted f_pos race fixes, making do_splice_direct() safe to
> > call with i_mutex on parent, O_TMPFILE support, Jeff's locks.c series,
> > ->d_hash/->d_compare calling conventions changes from Linus, misc stuff
> > all over the place. Please, pull from
> > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
>
> Btw, the new O_TMPFILE support seems to have a fundamental interface
> problem: old kernels ignore that flag, and happily implement totally
> different semantics than the intended new ones.
>
> So with a *new* kernel, if the filesystem doesn't support O_TMPFILE,
> you get an ENOTSUPP error, and you can fall back on whatever old
> tmpfile logic you had.
>
> But with an *old* kernel, O_TMPFILE will just silently be ignored as
> an unrecognized flag, and things won't work. If you do
>
> fd = open("dirname", O_CREAT | O_TMPFILE | O_RDWR, 0666);
>
> it may be that it ends up acting as a "create file at specified
> directory path" instead of what the user *meant* for it to do, which
> was "create unnamed temporary file in the specified directory".
>
> This seems to make the feature actively dangerous. You can't just try
> to use it and have a fallback, because that "try to use it" phase may
> incorrectly succeed.
>
> Yes, you can force things to not work on old systems by having a slash
> at the end of the directory name, but if you ever forget that, you'll
> end up with the above problem.
>
> Am I missing something?
It's slightly less painful than that - if dirname exists, the old kernels
will fail; O_CREAT for existing directory means an error. So in practice
you can use it safely. I'm not too happy about that situation, but I
hadn't been able to come up with anything better, short of a new syscall
that would duplicate openat(2), but reject unknown values in flags argument
from the very beginning ;-/ Which is what we probably should've done with
openat(2) itself, but it's too late for that now...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v3] x86: make jump_label use int3-based patching
(2013/07/12 5:26), Jiri Kosina wrote: > Make jump labels use text_poke_bp() for text patching instead of > text_poke_smp(), avoiding the need for stop_machine(). > > Signed-off-by: Jiri Kosina > --- > Changes: > > - unchanged since v1, patch 1/2 is the one being updated > > arch/x86/kernel/jump_label.c | 16 ++-- > 1 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c > index 2889b3d..460f5d9 100644 > --- a/arch/x86/kernel/jump_label.c > +++ b/arch/x86/kernel/jump_label.c > @@ -37,7 +37,19 @@ static void __jump_label_transform(struct jump_entry > *entry, > } else > memcpy(, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE); > > - (*poker)((void *)entry->code, , JUMP_LABEL_NOP_SIZE); > + /* > + * Make text_poke_bp() a default fallback poker. > + * > + * At the time the change is being done, just ignore whether we > + * are doing nop -> jump or jump -> nop transition, and assume > + * always nop being the 'currently valid' instruction > + * > + */ > + if (poker) > + (*poker)((void *)entry->code, , JUMP_LABEL_NOP_SIZE); > + else > + text_poke_bp((void *)entry->code, , JUMP_LABEL_NOP_SIZE, > + (void *)entry->code + JUMP_LABEL_NOP_SIZE); BTW, if the poker is NULL or text_poke_early, I think it doesn't need to pass it to __jump_label_transform, does it? Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] [GIT PULL] 9p changes for 3.11 merge window (part 2)
Eric Van Hensbergen writes: > The following changes since commit 2315cb14010c4cb0eb7c1d19fcf90475e4688207: > > 9p: Add rest of 9p files to MAINTAINERS entry (2013-05-28 13:47:58 -0500) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.gittags/for-linus-3.11-merge-window-part-2 > > for you to fetch changes up to f2692ea8d5b535277bc06b315eabd32ef4e7a11c: > > fs/9p: Remove the unused variable "err" in v9fs_vfs_getattr() (2013-07-07 > 22:18:31 -0500) > > > Second round of 9p patches for the 3.11 merge window. > > Several of these patches were rebased in order to correct style issues. > Only stylistic changes were made versus the patches which were in linux-next > for two weeks. The rebases have been in linux-next for 3 days and have > passed my regressions. > > The bulk of these are RDMA fixes and improvements. There's also some > additions on the extended attributes front to support some additional > namespaces and a new option for TCP to force allocation of mount requests > from a priviledged port. > Noticed that we have 6390460af8a672754dd6743f326515e98f52b2a7 and 42fe6484c639e8f79e09f81cb89f4f69db224997 Both are the same fix. net/9p: Handle error in zero copy request correctly for 9p2000.u Any idea what happened ? -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 07/10/2013 12:48 AM, Scott Wood wrote: On 07/05/2013 01:27:05 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add the device tree nodes for them. Signed-off-by: Hongbo Zhang --- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 90 +++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 90 +++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +- 3 files changed, 182 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi Please update Documentation/devicetree/bindings/powerpc/fsl/dma.txt for the new compatible and dgsr1. OK, thanks. What's more, some text string in the driver and Kconfig files should be updated too, e.g. "Elo / Elo Plus DMA" may be changed to "Elo series DMA", will send out v3 patches soon. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Friday 12 July 2013 05:30 AM, Jingoo Han wrote: > On Thursday, July 11, 2013 5:55 PM, Kishon Vijay Abraham I wrote: >> On Thursday 11 July 2013 11:19 AM, Jingoo Han wrote: >>> Exynos PCIe IP consists of Synopsys specific part and Exynos >>> specific part. Only core block is a Synopsys designware part; >>> other parts are Exynos specific. >>> Also, the Synopsys designware part can be shared with other >>> platforms; thus, it can be split two parts such as Synopsys >>> designware part and Exynos specific part. >>> >>> Signed-off-by: Jingoo Han >>> Cc: Pratyush Anand >>> Cc: Mohit KUMAR >>> --- >> . >> . >> >> . >> . >>> + >>> +/* Exynos PCIe driver does not allow module unload */ >> >> Just curious, why is this restriction? > > CC'ed Thierry Reding, > > Hi Kishon, > > That's a good question. > > Now, we don't have the solution to "be able to load and unload > the PCI host driver in a loop definitely without crashing or exposing > any races or leaks", as Arnd Bergmann said. > Please refer to the following thread in mailing-list. > (http://archive.arm.linux.org.uk/lurker/message/20130614.123849.4ff363c5.pl.html) That explains. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: When to push bug fixes to mainline
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote: > On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote: > > > > I'm sitting on top of over 170 more patches that have been marked for > > the stable releases right now that are not included in this set of > > releases. The fact that there are this many patches for stable stuff > > that are waiting to be merged through the main -rc1 merge window cycle > > is worrying to me. > > > > Why are subsystem maintainers holding on to fixes that are > > _supposedly_ affecting all users? I mean, 21 powerpc core changes > > that I don't see until a -rc1 merge? It's as if developers don't > > expect people to use a .0 release and are relying on me to get the > > fixes they have burried in their trees out to users. That's not that > > nice. 6 "core" iscsi-target fixes? That's the sign of either a > > broken subsystem maintainer, or a lack of understanding what the > > normal -rc kernel releases are supposed to be for. > > At least at one point in the past, the rule that Linus had laid down > after discussing things at Kernel Summits was after -rc2, or maybe > -rc3 at the latest, the ***only*** fixes that should be sent to Linus > would be for regression fixes or for really serious data integrity > issues. The concern was that people were pushing bug fixes in -rc5 or > -rc6 that were in some cases causing regressions. And maybe in the end, having 1/10 patch cause a regression is not *that* dramatic, and probably less than not fixing the 9 other bugs. In one case we rely on -stable to merge the 10 fixes, and on the other case we'd rely on -stable to just revert one of them. Also there has never been any promise of very stable mainline kernels, and at the same time the rules for getting patches in -stable are strict. So this means that most fixes should probably be pushed to mainline anyway otherwise we risk never to get them, which means lower overall quality. Just my two cents, Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.10-rc1: commit ccdfcc398594 broke uClibc build.
On 07/09/2013 05:25:53 AM, David Howells wrote: Geert Uytterhoeven wrote: > The #include added to include/uapi/linux/netlink.h causes > the uClibc build to go: > > In file included from include/linux/kernel.h:4, > from include/linux/netlink.h:4, > from include/linux/rtnetlink.h:5, > from libc/inet/netlinkaccess.h:27, > from libc/inet/if_index.c:37: > > include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before > > '__kernel_long_t' > > make: *** [libc/inet/if_index.o] Error 1 > > > > If I comment out that line, it builds fine. The kernel builds (for my > > config) either way. Comment out which line? Line 8 of include/linux/sysinfo.h or the new #include line? http://landley.net/hg/aboriginal/file/1616/sources/patches/linux-fixuClibc.patch Also, what arch are you compiling for? My Aboriginal Linux project does arm, mips, powerpc, sparc, sh4, x86, x86_64, m68k, and I'm poking at adding alpha. I believe the uClibc build breaks in a target-independent manner. I just rebuilt armv5l without the patch to confirm: CC libc/inet/if_index.os In file included from /home/landley/aboriginal/aboriginal/build/simple-cross-compiler-armv5l/include/linux/kernel.h:4, from /home/landley/aboriginal/aboriginal/build/simple-cross-compiler-armv5l/include/linux/netlink.h:4, from /home/landley/aboriginal/aboriginal/build/simple-cross-compiler-armv5l/include/linux/rtnetlink.h:5, from libc/inet/netlinkaccess.h:27, from libc/inet/if_index.c:37: /home/landley/aboriginal/aboriginal/build/simple-cross-compiler-armv5l/include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before '__kernel_long_t' make: *** [libc/inet/if_index.os] Error 1 make: *** Waiting for unfinished jobs Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] PM / AVS: SmartReflex: remove redundant dev_err call in omap_sr_probe()
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
Acked-by: Nishanth Menon
---
cc to linux-pm with Nishanth Menon's ACK
---
drivers/power/avs/smartreflex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index db9973b..c26acfc 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -871,10 +871,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sr_info->base = devm_ioremap_resource(>dev, mem);
- if (IS_ERR(sr_info->base)) {
- dev_err(>dev, "%s: ioremap fail\n", __func__);
+ if (IS_ERR(sr_info->base))
return PTR_ERR(sr_info->base);
- }
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
Add pfuze100 regulator driver.
Signed-off-by: Robin Gong
---
.../devicetree/bindings/regulator/pfuze100.txt | 113 +
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/pfuze100-regulator.c | 489
include/linux/regulator/pfuze.h| 49 ++
5 files changed, 659 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/pfuze100.txt
create mode 100644 drivers/regulator/pfuze100-regulator.c
create mode 100644 include/linux/regulator/pfuze.h
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt
b/Documentation/devicetree/bindings/regulator/pfuze100.txt
new file mode 100644
index 000..d9fc752
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -0,0 +1,113 @@
+PFUZE100 family of regulators
+
+Required properties:
+- compatible: "fsl,pfuze100"
+- reg: I2C slave address
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Please refer to below doc
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+ The valid names for regulators are:
+ sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ pmic: pfuze100@08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <11>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <40>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <40>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <330>;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <515>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <300>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <155>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <155>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vgen5_reg:
Re: [PATCH v2 2/2] media: i2c: tvp7002: add OF support
On Fri, Jul 12, 2013 at 3:34 AM, Sylwester Nawrocki wrote: > On 07/11/2013 07:09 PM, Prabhakar Lad wrote: > [...] > diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode 100644 index 000..9daebe1 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt @@ -0,0 +1,43 @@ +* Texas Instruments TV7002 video decoder + > > [...] > + +- ti,tvp7002-fid-polarity: Active-high Field ID polarity of the endpoint. >>> >>> >>> I thought it was agreed 'field-even-active' would be used instead of >>> this device specific property. Did you run into any issues with that ? >>> >>> >> Argh I some how missed it out, sorry this should be 'field-even-active' > > > OK. > > >>> And include/media/tvp70002.h: >>> >>> * fid_polarity: >>> * 0 -> the field ID output is set to logic 1 for >>> an >>> odd >>> * field (field 1) and set to logic 0 for an >>> even >>> * field (field 0). >>> * 1 -> operation with polarity inverted. >>> >>> >>> Do you know if the chip automatically selects video sync source >>> (sync-on-green >>> vs. VSYNC/HSYNC) and there is no need to configure this on the analogue >>> input >>> side ? At least the driver seems to always select the default SOGIN_1 >>> input >>> (TVP7002_IN_MUX_SEL_1 register is set only at initialization time). >>> >> Yes the driver is selecting the default SOGIN_1 input. >> >>> Or perhaps it just outputs on SOGOUT, VSOUT, HSOUT lines whatever is fed >>> to >>> its analogue inputs, and any further processing unit need to determine >>> what >>> synchronization signal is present and should be used ? >>> >> >> Yes that correct, there is a register (Sync Detect Status) which >> detects the sync for you. >> >>> I suspect that we don't need, e.g. another endpoint node to specify the >>> configuration of the TVP7002 analogue input interface, that would contain >>> a property like video-sync. >>> >>> >> If I understand correctly you mean if there are two tvp7002 devices >> connected >> we don’t need to specify video-sync property, but my question how do we >> specify this property in common then ? > > > No, I thought about two port sub-nodes of a single device node, one for the > TVP7002 video input and one for the output. But it seems there is no need > for that, i.e. to specify the input configuration statically in the > firmware. > The chip detects the signals automatically, i.e. it uses whatever is > available, > and it allows querying the selection status at run time. What would really > need to be configured statically in DT in that case then ? Some initial > video > sync configuration ? I guess it could be well hard coded in the driver, > since > the hardware does run time detection anyway. > Yes the chip detects the signal automatically, What I want to configure in the DT case is say if SOG signal is detected, I want to invert the polarity of it this is what I am trying to set in DT case whether to invert or not. 0 = Normal operation (default) 1 = SOG output polarity inverted Something similar to fid_polarity. Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression
I'm attempting to jump into the thread from here: http://markmail.org/message/zqbhcuc2gnxji3s7 I'm experiencing the same issue as described in the thread. I'm currently running kernel 3.9.6, but have had the issue for some time. I attempted to go through the debugging requested by Takashi Iwai on Jan 13. Immediately after issuing the "hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0" command, here is the trace output: # tracer: nop # # entries-in-buffer/entries-written: 8/8 #P:4 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | hda-verb-14066 [001] 90509.001737: hda_power_count: [0:0] power_count=2, power_on=1, power_transition=0 hda-verb-14066 [001] 90509.001740: hda_send_cmd: [0:0] val=1f70500 hda-verb-14066 [001] 90509.001814: hda_get_response: [0:0] val=0 hda-verb-14066 [001] 90509.001814: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 hda-verb-14122 [003] 90712.799801: hda_power_count: [0:0] power_count=2, power_on=1, power_transition=0 hda-verb-14122 [003] 90712.799804: hda_send_cmd: [0:0] val=1f70500 hda-verb-14122 [003] 90712.799880: hda_get_response: [0:0] val=0 hda-verb-14122 [003] 90712.799881: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 When the speakers stop, here is the output: # tracer: nop # # entries-in-buffer/entries- written: 8/8 #P:4 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | hda-verb-14066 [001] 90509.001737: hda_power_count: [0:0] power_count=2, power_on=1, power_transition=0 hda-verb-14066 [001] 90509.001740: hda_send_cmd: [0:0] val=1f70500 hda-verb-14066 [001] 90509.001814: hda_get_response: [0:0] val=0 hda-verb-14066 [001] 90509.001814: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 hda-verb-14122 [003] 90712.799801: hda_power_count: [0:0] power_count=2, power_on=1, power_transition=0 hda-verb-14122 [003] 90712.799804: hda_send_cmd: [0:0] val=1f70500 hda-verb-14122 [003] 90712.799880: hda_get_response: [0:0] val=0 hda-verb-14122 [003] 90712.799881: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 I'm a bit out of my element here, if I've missed a crucial step, please let me know. Thanks! -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ath10k: ATH10K should depend on HAS_DMA
Geert Uytterhoeven writes: > If NO_DMA=y: > > drivers/built-in.o: In function `ath10k_skb_unmap': > drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to > `dma_unmap_single' > drivers/built-in.o: In function `ath10k_skb_map': > drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to > `dma_map_single' > drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to > `dma_mapping_error' > drivers/built-in.o: In function `ath10k_htt_rx_ring_free': > drivers/net/wireless/ath/ath10k/htt_rx.c:113: undefined reference to > `dma_unmap_single' > drivers/built-in.o: In function `ath10k_htt_rx_amsdu_pop': > drivers/net/wireless/ath/ath10k/htt_rx.c:296: undefined reference to > `dma_unmap_single' > drivers/net/wireless/ath/ath10k/htt_rx.c:389: undefined reference to > `dma_unmap_single' > drivers/built-in.o: In function `__ath10k_htt_rx_ring_fill_n': > drivers/net/wireless/ath/ath10k/htt_rx.c:146: undefined reference to > `dma_map_single' > drivers/net/wireless/ath/ath10k/htt_rx.c:150: undefined reference to > `dma_mapping_error' > drivers/built-in.o: In function `ath10k_htt_rx_attach': > drivers/net/wireless/ath/ath10k/htt_rx.c:474: undefined reference to > `dma_alloc_coherent' > drivers/net/wireless/ath/ath10k/htt_rx.c:509: undefined reference to > `dma_free_coherent' > drivers/net/wireless/ath/ath10k/htt_rx.c:514: undefined reference to > `dma_free_coherent' > drivers/built-in.o: In function `ath10k_htt_rx_detach': > drivers/net/wireless/ath/ath10k/htt_rx.c:220: undefined reference to > `dma_unmap_single' > drivers/net/wireless/ath/ath10k/htt_rx.c:228: undefined reference to > `dma_free_coherent' > drivers/built-in.o: In function `ath10k_skb_map': > drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to > `dma_map_single' > drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to > `dma_mapping_error' > drivers/built-in.o: In function `ath10k_skb_unmap': > drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to > `dma_unmap_single' > drivers/built-in.o: In function `ath10k_skb_map': > drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to > `dma_map_single' > drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to > `dma_mapping_error' > drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to > `dma_map_single' > drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to > `dma_mapping_error' > drivers/built-in.o: In function `ath10k_skb_unmap': > drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to > `dma_unmap_single' > drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to > `dma_unmap_single' > drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to > `dma_unmap_single' > drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to > `dma_unmap_single' > > Signed-off-by: Geert Uytterhoeven > Cc: linux-wirel...@vger.kernel.org Thanks, I'll take this and send forward. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
Add pfuze100 regulator driver.
Signed-off-by: Robin Gong
---
.../devicetree/bindings/regulator/pfuze100.txt | 113 +
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/pfuze100-regulator.c | 489
include/linux/regulator/pfuze.h| 49 ++
5 files changed, 659 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/pfuze100.txt
create mode 100644 drivers/regulator/pfuze100-regulator.c
create mode 100644 include/linux/regulator/pfuze.h
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt
b/Documentation/devicetree/bindings/regulator/pfuze100.txt
new file mode 100644
index 000..d9fc752
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -0,0 +1,113 @@
+PFUZE100 family of regulators
+
+Required properties:
+- compatible: "fsl,pfuze100"
+- reg: I2C slave address
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Please refer to below doc
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+ The valid names for regulators are:
+ sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ pmic: pfuze100@08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <11>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <40>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <40>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <330>;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <515>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <300>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <155>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <155>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vgen5_reg:
Re: [PATCH RFC v3] media: OF: add video sync endpoint property
Hi Sylwester,
On Fri, Jul 12, 2013 at 2:45 AM, Sylwester Nawrocki
wrote:
> On 07/11/2013 01:41 PM, Prabhakar Lad wrote:
> [...]
>
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..1a54530 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -100,6 +100,26 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
if (!of_property_read_u32(node, "data-shift",))
bus->data_shift = v;
+ if (!of_property_read_u32(node, "video-sync",)) {
+ switch (v) {
+ case V4L2_MBUS_VIDEO_SEPARATE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_SEPARATE_SYNC;
>>>
>>>
>>>
>>> I'm not convinced all those video sync types is something that really
>>> belongs
>>> to the flags field. In my understanding this field is supposed to hold
>>> only
>>> the _signal polarity_ information.
>>>
>>>
>> Ok, so there should be a function say v4l2_of_parse_signal_polarity()
>> to get the polarity alone then.
>
>
> I don't think this is required, I would just extend
> v4l2_of_parse_parallel_bus()
> function to also handle sync-on-green-active property.
>
If that is the case than I have to add a member say 'signal_polarity'
in struct v4l2_of_bus_parallel and assign the polarity to it.
Let me know if you are OK with it.
Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 12
Hi all, Changes since 20130711: The arm-current tree gained a conflict against Linus' tree. The akpm tree lost some patches that turned up elsewhere and gained a conflict against the xfs tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 230 trees (counting Linus' and 33 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (9903883 Merge tag 'dm-3.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm) Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n) Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arc-current/for-curr (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging arm-current/fixes (cbbe6f8 ARM: 7778/1: smp_twd: twd_update_frequency need be run on all online CPUs) CONFLICT (content): Merge conflict in arch/arm/mm/init.c Merging m68k-current/for-linus (767bcb4 Merge branch 'exotic-arch-fixes' into for-next) Merging metag-fixes/fixes (d903bca metag: checksum.h: fix carry in csum_tcpudp_nofold) Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for single-dev-PE) Merging sparc/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging net/master (7ad031e qlcnic: Adding Maintainers.) Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling) Merging sound-current/for-linus (42d4ab8 ALSA: usb-audio: fix regression for fixed stream quirk) Merging pci-current/for-linus (65694c5 x86/PCI: Map PCI setup data with ioremap() so it can be in highmem) Merging wireless/master (57bf744 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) Merging driver-core.current/driver-core-linus (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging tty.current/tty-linus (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging usb.current/usb-linus (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging staging.current/staging-linus (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging char-misc.current/char-misc-linus (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging input-current/for-linus (62f548d Input: cyttsp4 - use 16bit address for I2C/SPI communication) Merging md-current/for-linus (1376512 md/raid10: fix bug which causes all RAID10 reshapes to move no data.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9c23b7d crypto: caam - Fixed the memory out of bound overwrite issue) Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (d94ea3f irqchip: Return -EPERM for reserved IRQs) Merging devicetree-current/devicetr
Re: [PATCH] x86: ce4100: add head file for reboot type
2013/7/9 Xiong Zhou : > From: Xiong Zhou > > Add head file for reboot type stuff to fix this: > error: ‘reboot_type’ undeclared (first use in this function) > error: ‘BOOT_KBD’ undeclared (first use in this function) > > Signed-off-by: Xiong Zhou > --- > arch/x86/platform/ce4100/ce4100.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/platform/ce4100/ce4100.c > b/arch/x86/platform/ce4100/ce4100.c > index baec704..643b8b5e 100644 > --- a/arch/x86/platform/ce4100/ce4100.c > +++ b/arch/x86/platform/ce4100/ce4100.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > #include > #include cc Jiri Kosina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]amilo-rfkill: add depends on i8042 in Kconfig
2013/6/28 Randy Dunlap : > On 06/18/13 18:09, Xiong Zhou wrote: >> 2013/6/18 Randy Dunlap : >>> On 06/18/13 06:04, Ben Hutchings wrote: On Tue, 2013-06-18 at 17:21 +0800, Xiong Zhou wrote: > From: Xiong Zhou > > Fix randconfig build failure for Amilo x86 platform driver. > AMILO_RFKILL requires SERIO_I8042 being available. > > amilo-rfkill.c:(.text+0x108b5b): undefined reference to `i8042_lock_chip' > amilo-rfkill.c:(.text+0x108b69): undefined reference to `i8042_command' > amilo-rfkill.c:(.text+0x108b71): undefined reference to > `i8042_unlock_chip' > > Reported-by: Jim Davis > Signed-off-by: Xiong Zhou Acked-by: Ben Hutchings But I thought somehow sent this same fix a while back... >>> >>> Yes, I reported it and sent a patch for it that you acked... >>> I guess my patch was never picked up. >>> >> >> ... Better someone pick this up. >> > > This build error is still occurring in linux-next (20130627). > I first reported it and posted a patch for it on May-15 2013. > > Please merge either patch... > > Is anybody out there? > > >> Ben. > --- > drivers/platform/x86/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > index 8577261..37645b9 100644 > --- a/drivers/platform/x86/Kconfig > +++ b/drivers/platform/x86/Kconfig > @@ -176,6 +176,7 @@ config FUJITSU_TABLET > config AMILO_RFKILL > tristate "Fujitsu-Siemens Amilo rfkill support" > depends on RFKILL > +depends on SERIO_I8042 > ---help--- >This is a driver for enabling wifi on some Fujitsu-Siemens Amilo >laptops. >>> >>> >>> -- >>> ~Randy >> -- > > > -- > ~Randy cc Jiri Kosina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 6/8] MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information
On Fri, Jul 12, 2013 at 04:36:00AM +0100, Ben Hutchings wrote: > On Thu, 2013-07-11 at 15:20 -0700, Greg Kroah-Hartman wrote: > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Greg Kroah-Hartman > > > > commit 7b175c46720f8e6b92801bb634c93d1016f80c62 upstream. > > > > This hopefully will help point developers to the proper way that patches > > should be submitted for inclusion in the stable kernel releases. > > > > Reported-by: David Howells > > Acked-by: David Howells > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > MAINTAINERS |1 + > > 1 file changed, 1 insertion(+) > > > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5725,6 +5725,7 @@ P:Vincent Sanders > > M: Simtec Linux Team > > W: http://www.simtec.co.uk/products/EB110ATX/ > > S: Supported > > +F: Documentation/stable_kernel_rules.txt > > You've applied this in the wrong place for some reason. Ick, patch did something odd there, thanks, I'll go fix it up and see if 3.4 is ok too. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/12] drivers/mmc/host: don't use devm_pinctrl_get_select_default() in probe
2013/7/10 Wolfram Sang : > Since commit ab78029 (drivers/pinctrl: grab default handles from device core), > we can rely on device core for setting the default pins. Compile tested only. > > Acked-by: Linus Walleij (personally at LCE13) > Signed-off-by: Wolfram Sang > --- > drivers/mmc/host/mvsdio.c |6 -- > drivers/mmc/host/mxs-mmc.c |8 > drivers/mmc/host/omap_hsmmc.c |7 --- > drivers/mmc/host/sdhci-esdhc-imx.c |8 > drivers/mmc/host/sdhci-sirf.c |8 Wolfram, this has been done for sirf, which version are you based on? > 5 files changed, 37 deletions(-) -barry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 1/3] PCI: introduce PCIe Device Serial Number Capability support
On Thu, Jul 11, 2013 at 12:18 PM, Don Dutile wrote:
> On 07/11/2013 04:09 PM, Bjorn Helgaas wrote:
>>
>> On Thu, Jul 11, 2013 at 3:51 AM, Don Dutile wrote:
>>>
>>> On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device serial number to identify
the physical device. During system suspend, if the PCIe
device was removed and inserted a new same device, after
system resume there is no good way to identify it, maybe
Device Serial Number is a good choice if device support.
Signed-off-by: Yijing Wang
---
drivers/pci/pci.c | 27 +++
drivers/pci/probe.c |2 ++
include/linux/pci.h |3 +++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e37fea6..2e855b5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2048,6 +2048,33 @@ void pci_free_cap_save_buffers(struct pci_dev
*dev)
}
/**
+ * pci_device_serial_number - get device serial number
+ * @dev: the PCI device
+ *
+ * return the device serial number if device support,
+ * otherwise return 0.
+ */
+u64 pci_device_serial_number(struct pci_dev *dev)
>>>
>>>
>>> See comment below:
>>> void pci_device_serial_number(struct pci_dev *dev)
>>>
>>>
+{
+ int pos;
+ u64 sn;
+ u32 lo, hi;
+
+ if (!pci_is_pcie(dev))
+ return 0;
+
>>>
>>>
>>> See comment below:
>>> if (!pci_is_pcie(dev)) {
>>> dev->sn = 0;
>>> return;
>>>
>>> }
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
+ if (!pos)
+ return 0;
+
+ pci_read_config_dword(dev, pos + 4,);
+ pci_read_config_dword(dev, pos + 8,);
+ sn = ((u64)hi<< 32) | lo;
>>>
>>>
>>> See comment below:
>>> dev->sn = ((u64)hi<< 32) | lo;
>>> return;
>>>
+ return sn;
+}
+EXPORT_SYMBOL(pci_device_serial_number);
+
+/**
* pci_configure_ari - enable or disable ARI forwarding
* @dev: the PCI device
*
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 46ada5c..c4c1a2b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1322,6 +1322,8 @@ static void pci_init_capabilities(struct pci_dev
*dev)
/* Power Management */
pci_pm_init(dev);
+ dev->sn = pci_device_serial_number(dev);
+
>>>
>>>
>>> Finally, 'the comment below':
>>> I know you were following Bjorn's suggestion, which I thought
>>> was an improvement, but why not do above assignment in
>>> pci_device_serial_number() ?
>>> See above
>>
>>
>> pci_device_serial_number() would then have the side-effect of saving
>> the result somewhere, and callers would have to know where to look.
>
> Ah, like so many other features of a PCI device? -- what are all those
> flags/status bits in pdev for ??? ;-)
>
>
>> Personally, I think it's simpler to return the serial number directly
>> and avoid the side-effect, but maybe this is just bike-shedding.
>>
> What struck me about rtning a value is in pci_init_capabilities(),
> it was the only function with a rtn value that had to be put into a pci_dev
> struct element,
> while all the others stored their related capabilities in the pdev, or other
> struct
> related to it.
Good point, BTW. I hadn't thought about it from that angle.
> So, maybe there should be a "pci_device_serial_number_init()" function
> which does the storage in the pdev struct, and another (wrapper,
> dare I shoot myself, inline) that is "pci_device_serial_number()" that
> returns
> the value of the pdev's sn element, if another module or other core
> component
> want to get it. and do that in a future patch... :-/
Of course, for Yijing's use, it's important that we're able to get the
*non-cached* serial number, because the cached one belongs to the old,
pre-suspend device, and we want to look at the post-suspend device to
see if it's the same.
Sigh. I dunno, I'll have to finish sorting through this in a week or
so... (I'll be on vacation for the next few days.)
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 6/8] MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information
On Thu, 2013-07-11 at 15:20 -0700, Greg Kroah-Hartman wrote: > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Greg Kroah-Hartman > > commit 7b175c46720f8e6b92801bb634c93d1016f80c62 upstream. > > This hopefully will help point developers to the proper way that patches > should be submitted for inclusion in the stable kernel releases. > > Reported-by: David Howells > Acked-by: David Howells > Signed-off-by: Greg Kroah-Hartman > > --- > MAINTAINERS |1 + > 1 file changed, 1 insertion(+) > > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5725,6 +5725,7 @@ P: Vincent Sanders > M: Simtec Linux Team > W: http://www.simtec.co.uk/products/EB110ATX/ > S: Supported > +F: Documentation/stable_kernel_rules.txt You've applied this in the wrong place for some reason. Ben. > > SIMTEC EB2410ITX (BAST) > P: Ben Dooks -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote: > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote: > > > In any case, I've been very conservative in _not_ pushing bug fixes to > > Linus after -rc3 (unless they are fixing a regression or the bug fix > > is super-serious); I'd much rather have them cook in the ext4 tree > > where they can get a lot more testing (a full regression test run for > > ext4 takes over 24 hours), and for people trying out linux-next. > > > > Maybe the pendulum has swung too far in the direction of holding back > > changes and trying to avoid the risk of introducing regressions; > > perhaps this would be a good topic to discuss at the Kernel Summit. > > Yes, there does seem to be a certain ebb and flow as to how strict > the rules are about what should go into stable, what fixes are "good > enough" for a given -rc, how tight those rule are in -rc2 vs in -rc6, > etc. If nothing else, a good repetitive flogging and a restatement of > the One True Way to handle these things might be worthwhile once again... The rules are documented in stable_kernel_rules.txt for what I will accept. I have been beating on maintainers for 8 years now to actually mark patches for stable, and only this past year have I finally seen people do it (we FINALLY got SCSI patches marked for stable in this merge window!!!) So now that maintainers are finally realizing that they need to mark patches, I'll be pushing back harder on the patches that they do submit, because the distros are rightfully pushing back on me for accepting things that are outside of the stable_kernel_rules.txt guidelines. If you look on the stable@vger list, I've already rejected 3 today and asked about the huge 21 powerpc patches. Sure, it's not a lot, when staring down 174 more to go, but it's a start... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] pinctrl: msm: Add support for MSM TLMM pinmux
Add a new device tree enabled pinctrl driver for Qualcomm MSM SoC's. This driver provides an extensible framework to interface all MSM's that use a TLMM pinmux, with the pinctrl subsytem. This driver is split into two parts: the pinctrl interface and the TLMM version specific implementation. The pinctrl interface parses the device tree and registers with the pinctrl subsytem. The TLMM version specific implementation supports pin configuration/register programming for the different pin types present on a given TLMM pinmux version. Add support only for TLMM version 3 pinmux right now, as well as, only two of the different pin types present on the TLMM v3 pinmux. Pintype 1: General purpose pins. Pintype 2: SDC pins. Signed-off-by: Hanumant Singh --- .../devicetree/bindings/pinctrl/msm-pinctrl.txt| 181 + drivers/pinctrl/Kconfig| 10 + drivers/pinctrl/Makefile | 2 + drivers/pinctrl/pinctrl-msm-tlmm-v3.c | 330 + drivers/pinctrl/pinctrl-msm.c | 751 + drivers/pinctrl/pinctrl-msm.h | 97 +++ 6 files changed, 1371 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-msm-tlmm-v3.c create mode 100644 drivers/pinctrl/pinctrl-msm.c create mode 100644 drivers/pinctrl/pinctrl-msm.h diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt new file mode 100644 index 000..d63d72b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt @@ -0,0 +1,181 @@ +MSM TLMM pinmux controller + +Qualcomm MSM integrates a GPIO and Pin mux/config hardware, (TOP Level Mode +Multiplexper in short TLMM). It controls the input/output settings on the +available pads/pins and also provides ability to multiplex and configure the +output of various on-chip controllers onto these pads. The pins are also of +different types, encapsulating different functions and having differing register +semantics. + +Required Properties: +- compatible: should be one of the following. + - "qcom,msm-tlmm-v3": for MSM with TLMM version 3. + +- reg: Base address of the pin controller hardware module and length of + the address space it occupies. + +- Pin types as child nodes: Pin types supported by a particular controller + instance are represented as child nodes of the controller node. Each + pin type node must contain following properties: + +Required Properties + - qcom,pin-type-*: identifies the pin type. Pin types supported are + qcom,pin-type-gp (General purpose) + qcom,pin-type-sdc (SDC) + - qcom,pin-cells: number of cells in the pin type specifier. + - qcom,num-pins: number of pins of given type present on the MSM. + +- Pin groups as child nodes: The pin mux (selecting pin function + mode) and pin config (pull up/down, driver strength, direction) settings are + represented as child nodes of the pin-controller node. There is no limit on + the count of these child nodes. + + Required Properties +-qcom,pins: phandle specifying pin type and a pin number. +-qcom,num-grp-pins: number of pins in the group. + + Optional Properties +-qcom,pin-func: function setting for the pin group. + + The child node should contain a list of pin(s) on which a particular pin + function selection or pin configuration (or both) have to applied. This + list of pins is specified using the property name "qcom,pins". There + should be atleast one pin specfied for this property and there is no upper + limit on the count of pins that can be specified. The pins are specified + using the pintype phandle and the pin number within that pintype. + + The pin function selection that should be applied on the pins listed in the + child node is specified using the "qcom,pin-func" property. The value + of this property that should be applied to each of the pins listed in the + "qcom,pins" property, should be picked from the hardware manual of the SoC. + This property is optional in the child node if no specific function + selection is desired for the pins listed in the child node or if the pin is + to be used for bit bang. + + The pin group node must additionally have a pin configuration node as its own + child node. There can be more then one such configuration node for a pin group + node. There can be one or more configurations within the configuration + node. These configurations are applied to all pins mentoned above using the + "qcom,pins" property. These configurations are specific to the pintype of the + pins. + For the pin configuration properties supported by general purpose pins as well + as SDC pins lookup Documentation/devicetree/bindings/pinctrl-bindings.txt + + The values specified by these config properties should be derived from the + hardware manual and
Re: When to push bug fixes to mainline
On 2013/7/12 8:50, Theodore Ts'o wrote: > On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote: >> >> I'm sitting on top of over 170 more patches that have been marked for >> the stable releases right now that are not included in this set of >> releases. The fact that there are this many patches for stable stuff >> that are waiting to be merged through the main -rc1 merge window cycle >> is worrying to me. >> >> Why are subsystem maintainers holding on to fixes that are >> _supposedly_ affecting all users? I mean, 21 powerpc core changes >> that I don't see until a -rc1 merge? It's as if developers don't >> expect people to use a .0 release and are relying on me to get the >> fixes they have burried in their trees out to users. That's not that >> nice. 6 "core" iscsi-target fixes? That's the sign of either a >> broken subsystem maintainer, or a lack of understanding what the >> normal -rc kernel releases are supposed to be for. > > At least at one point in the past, the rule that Linus had laid down > after discussing things at Kernel Summits was after -rc2, or maybe > -rc3 at the latest, the ***only*** fixes that should be sent to Linus > would be for regression fixes or for really serious data integrity > issues. The concern was that people were pushing bug fixes in -rc5 or > -rc6 that were in some cases causing regressions. > > (As I recall, Linus laid down the law regarding this policy in his own > inimitable and colorful style; which today would result in all sorts > of tsk, tsking on Hacker News regarding his language. :-) > > In any case, I've been very conservative in _not_ pushing bug fixes to > Linus after -rc3 (unless they are fixing a regression or the bug fix > is super-serious); I'd much rather have them cook in the ext4 tree > where they can get a lot more testing (a full regression test run for > ext4 takes over 24 hours), and for people trying out linux-next. > > Maybe the pendulum has swung too far in the direction of holding back > changes and trying to avoid the risk of introducing regressions; > perhaps this would be a good topic to discuss at the Kernel Summit. > Looks like each maintainer may have his rule which may differ from the rule laid down by Linus. I have 2 network patches which went into 3.10-rc6, though these two bugs are not regressions but has been there even before the git history. On the other hand, 2 of my cgroup bug fixes were queued for 3.11 with stable tag added. And what about Documentation fixes and updates? Should those patches also follow Linus' rule? I guess people have different opinions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the xfs tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
fs/xfs/xfs_qm.h between commit 92f8ff73f186 ("xfs: Add pquota fields
where gquota is used") from the xfs tree and commit "xfs: convert dquot
cache lru to list_lru" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/xfs/xfs_qm.h
index 579d6a0,cf2ad1f..000
--- a/fs/xfs/xfs_qm.h
+++ b/fs/xfs/xfs_qm.h
@@@ -44,14 -44,10 +44,12 @@@ extern struct kmem_zone*xfs_qm_dqtrxzo
typedef struct xfs_quotainfo {
struct radix_tree_root qi_uquota_tree;
struct radix_tree_root qi_gquota_tree;
+ struct radix_tree_root qi_pquota_tree;
struct mutex qi_tree_lock;
- xfs_inode_t *qi_uquotaip;/* user quota inode */
- xfs_inode_t *qi_gquotaip;/* group quota inode */
+ struct xfs_inode*qi_uquotaip; /* user quota inode */
+ struct xfs_inode*qi_gquotaip; /* group quota inode */
+ struct xfs_inode*qi_pquotaip; /* project quota inode */
- struct list_head qi_lru_list;
- struct mutex qi_lru_lock;
- int qi_lru_count;
+ struct list_lru qi_lru;
int qi_dquots;
time_t qi_btimelimit; /* limit for blks timer */
time_t qi_itimelimit; /* limit for inodes timer */
pgpPYxnSjVRiI.pgp
Description: PGP signature
[PATCH] asymmetric keys: explicitly add the leading zero byte to encoded message
From: Chun-Yi Lee Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in its first 2 bytes. The leading zero byte is suppressed by MPI so we pass a pointer to the _preceding_ byte to RSA_verify() in original code, but it has risk for the byte is not zero because it's not in EM buffer's scope, neither RSA_verify() nor mpi_get_buffer() didn't take care the leading byte. To avoid the risk, that's better we explicitly add the leading zero byte to EM for pass to RSA_verify(). This patch allocate a _EM buffer to capture the result from RSA_I2OSP(), then set the first byte to zero in EM and copy the remaining bytes from _EM. Cc: Rusty Russell Cc: Josh Boyer Cc: Randy Dunlap Cc: Herbert Xu Cc: "David S. Miller" Cc: David Howells Signed-off-by: Chun-Yi Lee --- crypto/asymmetric_keys/rsa.c | 14 ++ 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c index ca1a4f3..7bc99d2 100644 --- a/crypto/asymmetric_keys/rsa.c +++ b/crypto/asymmetric_keys/rsa.c @@ -303,6 +303,7 @@ static int RSA_verify_signature(const struct public_key *key, /* Variables as per RFC3447 sec 8.2.2 */ const u8 *H = sig->digest; u8 *EM = NULL; + u8 *_EM = NULL; MPI m = NULL; size_t k; @@ -337,14 +338,19 @@ static int RSA_verify_signature(const struct public_key *key, /* (2c) Convert the message representative (m) to an encoded message * (EM) of length k octets. * -* NOTE! The leading zero byte is suppressed by MPI, so we pass a -* pointer to the _preceding_ byte to RSA_verify()! +* NOTE! The leading zero byte is suppressed by MPI, so we add it +* back to EM before input to RSA_verify()! */ - ret = RSA_I2OSP(m, k, ); + ret = RSA_I2OSP(m, k, &_EM); if (ret < 0) goto error; - ret = RSA_verify(H, EM - 1, k, sig->digest_size, + EM = kmalloc(k, GFP_KERNEL); + memset(EM, 0, 1); + memcpy(EM + 1, _EM, k-1); + kfree(_EM); + + ret = RSA_verify(H, EM, k, sig->digest_size, RSA_ASN1_templates[sig->pkey_hash_algo].data, RSA_ASN1_templates[sig->pkey_hash_algo].size); -- 1.6.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
On 07/12/2013 10:38 AM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
>> On 07/12/2013 09:41 AM, Steven Rostedt wrote:
>>> On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
>>>
> Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
> use '__init', so not waste memory keeping them around ?
>>> Yeah, they should all be set to __init, but that's pretty low on the
>>> totem poll, as distros don't enable selftests in their main kernels.
>>
>> Excuse me, my English is not quite well, I guess your meaning is:
>>
>> they should all be set to '__init', although it is minor in real world.
>>
>> Is it correct ?
>
> Correct.
>
>>
>>
>> For me, I recommend to let all *selftest* as the same: "all add '
>> __init' or none add '__init'" (if choose add, all report warnings).
>>
>> Is it suitable to still send new related patch for it ? If so, could
>> you provide your suggesting choice (all add, or none add) ?
>
> Does this patch fix your warning?
>
> -- Steve
>
I guess it can (although I do not give a compiling test), it seems a
better fixing.
And is it suitable to let all *selftest* as the same ? (all add, or none
add '__init').
Thanks.
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index a4ed382..5e794d1 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -680,6 +680,15 @@ extern int trace_selftest_startup_sched_switch(struct
> tracer *trace,
> struct trace_array *tr);
> extern int trace_selftest_startup_branch(struct tracer *trace,
>struct trace_array *tr);
> +/*
> + * Tracer data references selftest functions that only occur
> + * on boot up. These can be __init functions. Thus, when selftests
> + * are enabled, then the tracers need to reference __init functions.
> + */
> +#define __tracer_data__refdata
> +#else
> +/* Tracers are seldom changed. Optimize when selftests are disabled. */
> +#define __tracer_data__read_mostly
> #endif /* CONFIG_FTRACE_STARTUP_TEST */
>
> extern void *head_page(struct trace_array_cpu *data);
> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> index b863f93..38fe148 100644
> --- a/kernel/trace/trace_functions.c
> +++ b/kernel/trace/trace_functions.c
> @@ -199,7 +199,7 @@ static int func_set_flag(u32 old_flags, u32 bit, int set)
> return 0;
> }
>
> -static struct tracer function_trace __read_mostly =
> +static struct tracer function_trace __tracer_data =
> {
> .name = "function",
> .init = function_trace_init,
>
>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote: > In any case, I've been very conservative in _not_ pushing bug fixes to > Linus after -rc3 (unless they are fixing a regression or the bug fix > is super-serious); I'd much rather have them cook in the ext4 tree > where they can get a lot more testing (a full regression test run for > ext4 takes over 24 hours), and for people trying out linux-next. > > Maybe the pendulum has swung too far in the direction of holding back > changes and trying to avoid the risk of introducing regressions; > perhaps this would be a good topic to discuss at the Kernel Summit. Yes, there does seem to be a certain ebb and flow as to how strict the rules are about what should go into stable, what fixes are "good enough" for a given -rc, how tight those rule are in -rc2 vs in -rc6, etc. If nothing else, a good repetitive flogging and a restatement of the One True Way to handle these things might be worthwhile once again... John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCIE resetting graphic card
Hi, Takao On 07/12/2013 10:39 AM, Takao Indoh wrote: > Hi Dave, > > (2013/07/12 11:04), Dave Young wrote: >> Hi, Takao >> >> I know you are working on the PCIE resetting patches for the iommu kdump >> issue. >> >> You explicitly excluded the graphic card in your patch. I have some >> questions about this. Why can't we reset the graphic card like other >> pcie devices? > > As far as I tested, the monitor blacks out after video controller is > reset, and we cannot know what's going on. So, for now display device is > not reset in my patch. > > I'm not sure what we need to do to recover graphic card after its reset, > but my colleague said that we need to run BIOS code to get back legacy > VGA mode after reset. It seems not to be easy:-( > > Maybe this document is helpful to do this. > http://www.coreboot.org/images/2/2b/Vgabios.pdf Thanks for quick response and the info about vgabios. It's awkward that we can not switch back to VGA mode. -- Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 1/3] PCI: introduce PCIe Device Serial Number Capability support
On 2013/7/12 2:18, Don Dutile wrote:
> On 07/11/2013 04:09 PM, Bjorn Helgaas wrote:
>> On Thu, Jul 11, 2013 at 3:51 AM, Don Dutile wrote:
>>> On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device serial number to identify
the physical device. During system suspend, if the PCIe
device was removed and inserted a new same device, after
system resume there is no good way to identify it, maybe
Device Serial Number is a good choice if device support.
Signed-off-by: Yijing Wang
---
drivers/pci/pci.c | 27 +++
drivers/pci/probe.c |2 ++
include/linux/pci.h |3 +++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e37fea6..2e855b5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2048,6 +2048,33 @@ void pci_free_cap_save_buffers(struct pci_dev *dev)
}
/**
+ * pci_device_serial_number - get device serial number
+ * @dev: the PCI device
+ *
+ * return the device serial number if device support,
+ * otherwise return 0.
+ */
+u64 pci_device_serial_number(struct pci_dev *dev)
>>>
>>> See comment below:
>>> void pci_device_serial_number(struct pci_dev *dev)
>>>
>>>
+{
+ int pos;
+ u64 sn;
+ u32 lo, hi;
+
+ if (!pci_is_pcie(dev))
+ return 0;
+
>>>
>>> See comment below:
>>> if (!pci_is_pcie(dev)) {
>>> dev->sn = 0;
>>> return;
>>>
>>> }
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
+ if (!pos)
+ return 0;
+
+ pci_read_config_dword(dev, pos + 4,);
+ pci_read_config_dword(dev, pos + 8,);
+ sn = ((u64)hi<< 32) | lo;
>>>
>>> See comment below:
>>> dev->sn = ((u64)hi<< 32) | lo;
>>> return;
>>>
+ return sn;
+}
+EXPORT_SYMBOL(pci_device_serial_number);
+
+/**
* pci_configure_ari - enable or disable ARI forwarding
* @dev: the PCI device
*
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 46ada5c..c4c1a2b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1322,6 +1322,8 @@ static void pci_init_capabilities(struct pci_dev
*dev)
/* Power Management */
pci_pm_init(dev);
+ dev->sn = pci_device_serial_number(dev);
+
>>>
>>> Finally, 'the comment below':
>>> I know you were following Bjorn's suggestion, which I thought
>>> was an improvement, but why not do above assignment in
>>> pci_device_serial_number() ?
>>> See above
>>
>> pci_device_serial_number() would then have the side-effect of saving
>> the result somewhere, and callers would have to know where to look.
> Ah, like so many other features of a PCI device? -- what are all those
> flags/status bits in pdev for ??? ;-)
>
>> Personally, I think it's simpler to return the serial number directly
>> and avoid the side-effect, but maybe this is just bike-shedding.
>>
> What struck me about rtning a value is in pci_init_capabilities(),
> it was the only function with a rtn value that had to be put into a pci_dev
> struct element,
> while all the others stored their related capabilities in the pdev, or other
> struct
> related to it.
>
> So, maybe there should be a "pci_device_serial_number_init()" function
> which does the storage in the pdev struct, and another (wrapper,
> dare I shoot myself, inline) that is "pci_device_serial_number()" that
> returns
add an wrapper function may be ok, as I mentioned in pre-reply, what about,
static void pci_init_capabilities(struct pci_dev *dev)
...
pci_dsn_init(dev);
.
void pci_dsn_init(dev)
{
dev->sn = pci_device_serial_number(dev);
}
> the value of the pdev's sn element, if another module or other core component
> want to get it. and do that in a future patch... :-/
>
>> As long as we are bike-shedding, I'd just drop "sn" and do:
>>
>> return ((u64)hi<< 32) | lo;
>>
>> And of course, you need spaces before "" and "" in the
>> pci_read_config_dword() calls.
>
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v3] x86: introduce int3-based instruction patching
(2013/07/12 5:26), Jiri Kosina wrote:
> Introduce a method for run-time instrucntion patching on a live SMP kernel
> based on int3 breakpoint, completely avoiding the need for stop_machine().
>
> The way this is achieved:
>
> - add a int3 trap to the address that will be patched
> - sync cores
> - update all but the first byte of the patched range
> - sync cores
> - replace the first byte (int3) by the first byte of
> replacing opcode
> - sync cores
>
> According to
>
> http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/01530.html
>
> synchronization after replacing "all but first" instructions should not
> be necessary (on Intel hardware), as the syncing after the subsequent
> patching of the first byte provides enough safety.
> But there's not only Intel HW out there, and we'd rather be on a safe
> side.
>
> If any CPU instruction execution would collide with the patching,
> it'd be trapped by the int3 breakpoint and redirected to the provided
> "handler" (which would typically mean just skipping over the patched
> region, acting as "nop" has been there, in case we are doing nop -> jump
> and jump -> nop transitions).
>
> Ftrace has been using this very technique since 08d636b ("ftrace/x86:
> Have arch x86_64 use breakpoints instead of stop machine") for ages
> already, and jump labels are another obvious potential user of this.
>
> Based on activities of Masami Hiramatsu
> a few years ago.
>
> Signed-off-by: Jiri Kosina
Looks good for me. I'd like to use this for optprobe too :)
Reviewed-by: Masami Hiramatsu
Thank you!
> ---
> Changes:
>
> v1 -> v2:
> + fixed kerneldoc
> + fixed checkpatch errors (reported by Borislav)
>
> v2 -> v3:
> + fixed few typos (Joe Perches)
> + extended changelog with pointer to Intel's statement regarding minimal
> necessary synchronization points to achieve correctness
> + added even the synchronization that might not be needed according to
> Intel, to be on a safe side (and do what has been proven to work by
> ftrace implementation already) (Steven Rostedt)
> + Fix formatting of comments (Steven Rostedt, Borislav Petkov, Joe
> Perches)
>
> arch/x86/include/asm/alternative.h |1 +
> arch/x86/kernel/alternative.c | 107
>
> kernel/kprobes.c |2 +-
> 3 files changed, 109 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/include/asm/alternative.h
> b/arch/x86/include/asm/alternative.h
> index 58ed6d9..3abf8dd 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -233,6 +233,7 @@ struct text_poke_param {
> };
>
> extern void *text_poke(void *addr, const void *opcode, size_t len);
> +extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void
> *handler);
> extern void *text_poke_smp(void *addr, const void *opcode, size_t len);
> extern void text_poke_smp_batch(struct text_poke_param *params, int n);
>
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index c15cf9a..ed2377d 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -596,6 +597,112 @@ void *__kprobes text_poke(void *addr, const void
> *opcode, size_t len)
> return addr;
> }
>
> +static void do_sync_core(void *info)
> +{
> + sync_core();
> +}
> +
> +static bool bp_patching_in_progress;
> +static void *bp_int3_handler, *bp_int3_addr;
> +
> +static int int3_notify(struct notifier_block *self, unsigned long val, void
> *data)
> +{
> + struct die_args *args = data;
> +
> + /* bp_patching_in_progress */
> + smp_rmb();
> +
> + if (likely(!bp_patching_in_progress))
> + return NOTIFY_DONE;
> +
> + /* we are not interested in non-int3 faults and ring > 0 faults */
> + if (val != DIE_INT3 || !args->regs || user_mode_vm(args->regs)
> + || (unsigned long) bp_int3_addr != args->regs->ip)
> + return NOTIFY_DONE;
> +
> + /* set up the specified breakpoint handler */
> + args->regs->ip = (unsigned long) bp_int3_handler;
> +
> + return NOTIFY_STOP;
> +}
> +/*
> + * text_poke_bp() -- update instructions on live kernel on SMP
> + * @addr:address to patch
> + * @opcode: opcode of new instruction
> + * @len: length to copy
> + * @handler: address to jump to when the temporary breakpoint is hit
> + *
> +
> + * Modify multi-byte instruction by using int3 breakpoint on SMP.
> + * In contrary to text_poke_smp(), we completely avoid stop_machine() here,
> + * and achieve the synchronization using int3 breakpoint.
> + *
> + * The way it is done:
> + * - add a int3 trap to the address that will be patched
> + * - sync cores
> + * - update all but the first byte of the patched range
> + * - sync cores
> + * -
XFS: Assertion failed: xfs_dir2_sf_lookup(args) == ENOENT, file: fs/xfs/xfs_dir2_sf.c, line: 358
Just saw this during boot after an unclean shutdown. It hung afterwards. [ 97.162665] XFS: Assertion failed: xfs_dir2_sf_lookup(args) == ENOENT, file: fs/xfs/xfs_dir2_sf.c, line: 358 [ 97.164646] [ cut here ] [ 97.165312] kernel BUG at fs/xfs/xfs_message.c:108! [ 97.165986] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 97.166947] Modules linked in: snd_hda_codec_realtek pcspkr usb_debug snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e ptp snd_page_alloc pps_core snd_timer snd soundcore xfs libcrc32c [ 97.170782] CPU: 3 PID: 341 Comm: rpcbind Not tainted 3.10.0+ #49 [ 97.173684] task: 880235d14a40 ti: 880235dae000 task.ti: 880235dae000 [ 97.173701] RIP: 0010:[] [] assfail+0x22/0x30 [xfs] [ 97.173702] RSP: 0018:880235dafa98 EFLAGS: 00010296 [ 97.173703] RAX: 0060 RBX: 880235dafb20 RCX: 0006 [ 97.173703] RDX: 31e0 RSI: 880235d152a0 RDI: 880235d14a40 [ 97.173704] RBP: 880235dafa98 R08: 0002 R09: [ 97.173704] R10: 0001 R11: 0001 R12: 880235e54000 [ 97.173705] R13: 00035e92 R14: 880235dafc88 R15: 880235dafc28 [ 97.173706] FS: 7fa6aac79840() GS:880244e0() knlGS: [ 97.173706] CS: 0010 DS: ES: CR0: 80050033 [ 97.173707] CR2: 7fffb1905f18 CR3: 000235ce5000 CR4: 001407e0 [ 97.173707] DR0: DR1: DR2: [ 97.173708] DR3: DR6: fffe0ff0 DR7: 0400 [ 97.173708] Stack: [ 97.173712] 880235dafb00 a0076953 e8c066a0 880240e04ca8 [ 97.173713] 0250 0020 88023d05af40 880235dafb20 [ 97.173715] 880235a14a40 880235e54000 00035e92 880235dafc88 [ 97.173715] Call Trace: [ 97.173730] [] xfs_dir2_sf_addname+0x43/0x760 [xfs] [ 97.173743] [] xfs_dir_createname+0x15c/0x1b0 [xfs] [ 97.173754] [] xfs_create+0x4cc/0x710 [xfs] [ 97.173764] [] xfs_vn_mknod+0x9a/0x1c0 [xfs] [ 97.173773] [] xfs_vn_create+0x13/0x20 [xfs] [ 97.173776] [] vfs_create+0x9d/0x100 [ 97.173778] [] do_last+0x925/0xe00 [ 97.173780] [] path_openat+0xbe/0x6f0 [ 97.173783] [] ? local_clock+0x3f/0x50 [ 97.173785] [] ? __alloc_fd+0xaf/0x200 [ 97.173787] [] do_filp_open+0x3a/0x90 [ 97.173789] [] ? __alloc_fd+0xaf/0x200 [ 97.173790] [] do_sys_open+0x10b/0x200 [ 97.173792] [] ? syscall_trace_enter+0x18/0x290 [ 97.173794] [] SyS_open+0x1e/0x20 [ 97.173796] [] tracesys+0xdd/0xe2 [ 97.173813] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 f1 41 89 d0 48 89 e5 48 89 fa 48 c7 c6 a8 98 0b a0 31 ff 31 c0 e8 ce fb ff ff <0f> 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 This trace repeated a few times, then the same assertion was triggered from sys_renameat. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCIE resetting graphic card
Hi Dave, (2013/07/12 11:04), Dave Young wrote: > Hi, Takao > > I know you are working on the PCIE resetting patches for the iommu kdump > issue. > > You explicitly excluded the graphic card in your patch. I have some > questions about this. Why can't we reset the graphic card like other > pcie devices? As far as I tested, the monitor blacks out after video controller is reset, and we cannot know what's going on. So, for now display device is not reset in my patch. I'm not sure what we need to do to recover graphic card after its reset, but my colleague said that we need to run BIOS code to get back legacy VGA mode after reset. It seems not to be easy:-( Maybe this document is helpful to do this. http://www.coreboot.org/images/2/2b/Vgabios.pdf Thanks, Takao Indoh > > We have problems, if 1st kernel is in kms mode kdump kernel will have no > chance to switch back to VGA console. There's no serial port on most of > recent laptops thus it's difficult to debug kdump issue. > > So if we can reset graphic card as well, and if it works I wonder if the > 2nd kdump kernel can use vga console with nomodeset? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
> On 07/12/2013 09:41 AM, Steven Rostedt wrote:
> > On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
> >
> >> > Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
> >> > use '__init', so not waste memory keeping them around ?
> > Yeah, they should all be set to __init, but that's pretty low on the
> > totem poll, as distros don't enable selftests in their main kernels.
>
> Excuse me, my English is not quite well, I guess your meaning is:
>
> they should all be set to '__init', although it is minor in real world.
>
> Is it correct ?
Correct.
>
>
> For me, I recommend to let all *selftest* as the same: "all add '
> __init' or none add '__init'" (if choose add, all report warnings).
>
> Is it suitable to still send new related patch for it ? If so, could
> you provide your suggesting choice (all add, or none add) ?
Does this patch fix your warning?
-- Steve
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index a4ed382..5e794d1 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -680,6 +680,15 @@ extern int trace_selftest_startup_sched_switch(struct
tracer *trace,
struct trace_array *tr);
extern int trace_selftest_startup_branch(struct tracer *trace,
struct trace_array *tr);
+/*
+ * Tracer data references selftest functions that only occur
+ * on boot up. These can be __init functions. Thus, when selftests
+ * are enabled, then the tracers need to reference __init functions.
+ */
+#define __tracer_data __refdata
+#else
+/* Tracers are seldom changed. Optimize when selftests are disabled. */
+#define __tracer_data __read_mostly
#endif /* CONFIG_FTRACE_STARTUP_TEST */
extern void *head_page(struct trace_array_cpu *data);
diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index b863f93..38fe148 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -199,7 +199,7 @@ static int func_set_flag(u32 old_flags, u32 bit, int set)
return 0;
}
-static struct tracer function_trace __read_mostly =
+static struct tracer function_trace __tracer_data =
{
.name = "function",
.init = function_trace_init,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 1/3] PCI: introduce PCIe Device Serial Number Capability support
>> } >>> >>> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN); >>> + if (!pos) >>> + return 0; >>> + >>> + pci_read_config_dword(dev, pos + 4,); >>> + pci_read_config_dword(dev, pos + 8,); >>> + sn = ((u64)hi<< 32) | lo; >> >> See comment below: >> dev->sn = ((u64)hi<< 32) | lo; >> return; >> >>> + return sn; >>> +} >>> +EXPORT_SYMBOL(pci_device_serial_number); >>> + >>> +/** >>>* pci_configure_ari - enable or disable ARI forwarding >>>* @dev: the PCI device >>>* >>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c >>> index 46ada5c..c4c1a2b 100644 >>> --- a/drivers/pci/probe.c >>> +++ b/drivers/pci/probe.c >>> @@ -1322,6 +1322,8 @@ static void pci_init_capabilities(struct pci_dev >>> *dev) >>> /* Power Management */ >>> pci_pm_init(dev); >>> >>> + dev->sn = pci_device_serial_number(dev); >>> + >> >> Finally, 'the comment below': >> I know you were following Bjorn's suggestion, which I thought >> was an improvement, but why not do above assignment in >> pci_device_serial_number() ? >> See above > > pci_device_serial_number() would then have the side-effect of saving > the result somewhere, and callers would have to know where to look. > Personally, I think it's simpler to return the serial number directly > and avoid the side-effect, but maybe this is just bike-shedding. > > As long as we are bike-shedding, I'd just drop "sn" and do: > > return ((u64)hi << 32) | lo; > > And of course, you need spaces before "" and "" in the > pci_read_config_dword() calls. OK, will drop "sn", strangely my original patch has spaces before "" and "", but in reply the spaces disappeared. Thanks! Yijing. > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ia64/pci: set mmio decoding on for some host bridge
Hi Bjorn, Thanks for your suggestions. I will try to find more information. ZhenHua On 07/11/2013 12:12 AM, Bjorn Helgaas wrote: On Wed, Jul 10, 2013 at 12:23 AM, ZhenHua wrote: Hi Bjorn, On the system that this bug happens, an MCA event is generated while kernel crashed: Transaction Address: memory write to address 0x0ae041428 (LMMIO - SBL Blade 1 SFW DDR Memory) I guess the there is some module trying to visit the address 0x0ae041428 right after this line is run: pci_write_config_word(dev, PCI_COMMAND, orig_cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO)); Well, you need to figure out what is accessing 0x0ae041428 and why. Presumably that address belongs to some device below the 40:01.0 root port, and knowing which device that is would be a good clue, but you didn't include that in your lspci. I'm trying to give you hints about how *you* can figure out what's going on here. Obviously I don't have the system and I'm not proposing a change, so that's about all I can do. The output of lspci -vvv is followed. 40:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 22) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Subsystem: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 Capabilities: [60] Message Signalled Interrupts: Mask+ 64bit- Count=1/2 Enable+ Address: fee0 Data: 4046 Masking: 0002 Pending: Capabilities: [90] Express (v2) Root Port (Slot-), MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag+ RBE+ FLReset- DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM L0s L1, Latency L0 <512ns, L1 <64us ClockPM- Suprise+ LLActRep+ BwNot+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Range BCD, TimeoutDis+ ARIFwd+ DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- ARIFwd- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -3.5dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB Capabilities: [e0] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP+ FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq+ ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [150] Access Control Services ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans- ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans- Capabilities: [160] Vendor Specific Information Kernel driver in use: pcieport Kernel modules: shpchp On 07/10/2013 12:49 AM, Bjorn Helgaas wrote: On Mon, Jul 8, 2013 at 11:42 PM, Li, Zhen-Hua wrote: On some IA64 platforms with intel PCI bridge, for example, HP BL890c i2 with Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port, when kernel tries to disable the mmio decoding on the PCI bridge devices, kernel may crash. And in the comment of
Re: [PATCH -v2 3/3] PCI,pciehp: use PCIe DSN to identify device change during suspend
On 2013/7/11 22:33, Paul Bolle wrote:
> On Thu, 2013-07-11 at 17:43 +0800, Yijing Wang wrote:
> [...]
>> diff --git a/drivers/pci/hotplug/pciehp_core.c
>> b/drivers/pci/hotplug/pciehp_core.c
>> index 1542735..f2eb214 100644
>> --- a/drivers/pci/hotplug/pciehp_core.c
>> +++ b/drivers/pci/hotplug/pciehp_core.c
> [...]
>> @@ -315,6 +342,24 @@ static int pciehp_resume (struct pcie_device *dev)
>> if (status) {
>> if (list_empty(>devices))
>> pciehp_enable_slot(slot);
>> +
>> +if (device_serial_number_changed(pbus)) {
>> +/*
>> + * first power off slot, avoid the old driver
>> + * .remove() method touch the new hardware
>> + */
>> +if (POWER_CTRL(ctrl)) {
>> +retval = pciehp_power_off_slot(slot);
>> +if (retval) {
>> +ctrl_err(ctrl,
>> +"Issue of Slot Disable command
>> failed\n");
>> +return 0;
>> +}
>> +msleep(1000);
>> +pciehp_unconfigure_device(slot);
>> +pciehp_enable_slot(slot);
>> +}
>> +}
>> } else if (!list_empty(>devices))
>> pciehp_disable_slot(slot);
>>
>
> It was surprisingly hard to see why the patch wouldn't apply to v3.10.
> It turns out the very last line of context is a line consisting of just
> a single tab. And in v3.10 it is an empty line.
>
> Is that lone tab perhaps an editing mistake on your side?
I will check this, thanks!
>
>
> Paul Bolle
>
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LOCKDEP] cpufreq: possible circular locking dependency detected
On 07/11/2013 07:47 PM, Bartlomiej Zolnierkiewicz wrote:
[snip]
>
> Michael's patch also works for me. Thanks to everyone involved!
> (My only nitpick for the patch is that ->queue_stop can be made bool.)
>
> Reported-and-Tested-by: Bartlomiej Zolnierkiewicz
>
> I think that it would also be helpful if Jiri or Borislav could test
> the patch and see if it really works for them and fixes the original
> warning they were experiencing on x86.
Thanks for the testing :)
I plan to send out the formal patch next week, so Jiri and Borislav
would have chance to join the discussion.
Regards,
Michael Wang
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
>>> And we should also thanks Srivatsa for catching the root issue ;-)
>>>
>>> Regards,
>>> Michael Wang
>>>
-ss
> Regards,
> Michael Wang
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index dc9b72e..a64b544 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -178,13 +178,14 @@ void gov_queue_work(struct dbs_data *dbs_data,
> struct cpufreq_policy *policy,
> {
> int i;
>
> + if (dbs_data->queue_stop)
> + return;
> +
> if (!all_cpus) {
> __gov_queue_work(smp_processor_id(), dbs_data, delay);
> } else {
> - get_online_cpus();
> for_each_cpu(i, policy->cpus)
> __gov_queue_work(i, dbs_data, delay);
> - put_online_cpus();
> }
> }
> EXPORT_SYMBOL_GPL(gov_queue_work);
> @@ -193,12 +194,27 @@ static inline void gov_cancel_work(struct dbs_data
> *dbs_data,
> struct cpufreq_policy *policy)
> {
> struct cpu_dbs_common_info *cdbs;
> - int i;
> + int i, round = 2;
>
> + dbs_data->queue_stop = 1;
> +redo:
> + round--;
> for_each_cpu(i, policy->cpus) {
> cdbs = dbs_data->cdata->get_cpu_cdbs(i);
> cancel_delayed_work_sync(>work);
> }
> +
> + /*
> + * Since there is no lock to prvent re-queue the
> + * cancelled work, some early cancelled work might
> + * have been queued again by later cancelled work.
> + *
> + * Flush the work again with dbs_data->queue_stop
> + * enabled, this time there will be no survivors.
> + */
> + if (round)
> + goto redo;
> + dbs_data->queue_stop = 0;
> }
>
> /* Will return if we need to evaluate cpu load again or not */
> diff --git a/drivers/cpufreq/cpufreq_governor.h
> b/drivers/cpufreq/cpufreq_governor.h
> index e16a961..9116135 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -213,6 +213,7 @@ struct dbs_data {
> unsigned int min_sampling_rate;
> int usage_count;
> void *tuners;
> + int queue_stop;
>
> /* dbs_mutex protects dbs_enable in governor start/stop */
> struct mutex mutex;
>
>>
>> Signed-off-by: Sergey Senozhatsky
>>
>> ---
>>
>> drivers/cpufreq/cpufreq.c | 5 +
>> drivers/cpufreq/cpufreq_governor.c | 17 +++--
>> drivers/cpufreq/cpufreq_stats.c| 2 +-
>> 3 files changed, 13 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 6a015ad..f8aacf1 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1943,13 +1943,10 @@ static int __cpuinit cpufreq_cpu_callback(struct
>> notifier_block *nfb,
>> case CPU_ONLINE:
>> cpufreq_add_dev(dev, NULL);
>> break;
>> -case CPU_DOWN_PREPARE:
>> +case CPU_POST_DEAD:
>> case CPU_UP_CANCELED_FROZEN:
>> __cpufreq_remove_dev(dev, NULL);
>> break;
>> -case CPU_DOWN_FAILED:
>> -cpufreq_add_dev(dev, NULL);
>> -break;
>> }
>> }
>> return NOTIFY_OK;
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> index 4645876..681d5d6 100644
>> --- a/drivers/cpufreq/cpufreq_governor.c
>> +++ b/drivers/cpufreq/cpufreq_governor.c
>> @@ -125,7 +125,11 @@ static inline void __gov_queue_work(int cpu, struct
>> dbs_data *dbs_data,
>> unsigned int delay)
>> {
>> struct cpu_dbs_common_info *cdbs =
>> dbs_data->cdata->get_cpu_cdbs(cpu);
>> -
>> +/* cpu offline might block existing gov_queue_work() user,
>> + * unblocking it after CPU_DEAD and before
Re: BUG: key ffff880c1148c478 not in .data! (V3.10.0)
On Mon, Jul 8, 2013 at 6:25 AM, Linda Walsh wrote: > Also am seeing this for the first time: > > (don't know, but seems unlikely to be related to > https://patchwork.kernel.org/patch/87359/ > Yet it is the only hit I found for the same message. > > > Looks like it's back to a more stable 3.9.8... > (*sigh*) > > > BUG: key 880c1148c478 not in .data! > [4.429474] [ cut here ] > [4.434236] WARNING: at kernel/lockdep.c:2987 > lockdep_init_map+0x45e/0x490() > [4.441414] DEBUG_LOCKS_WARN_ON(1) > [4.444684] Modules linked in: > [4.448168] usb 1-3.2: new low-speed USB device number 3 using ehci-pci > [4.454975] CPU: 10 PID: 1 Comm: swapper/0 Tainted: G I > 3.10.0-Isht-Van #1 > [4.462862] Hardware name: Dell Inc. PowerEdge T610/0CX0R0, BIOS 6.3.0 > 07/24/2012 > [4.470475] 0009 880c13175a70 815bb279 > 880c13175aa8 > [4.478221] 8104641c 880c11c12130 880c1148c478 > > [4.485988] 880c11c12058 880c12386180 880c13175b08 > 81046487 > [4.493800] Call Trace: > [4.496472] [] dump_stack+0x19/0x1b > [4.501776] [] warn_slowpath_common+0x5c/0x80 > [4.507917] [] warn_slowpath_fmt+0x47/0x50 > [4.513790] [] lockdep_init_map+0x45e/0x490 > [4.519775] [] debug_mutex_init+0x2d/0x40 > [4.525567] [] __mutex_init+0x51/0x60 > [4.531017] [] bus_register+0x158/0x2c0 > [4.536646] [] edac_create_sysfs_mci_device+0x53/0x540 Looks because that bus_type of 'struct mem_ctl_info' is allocated dynamically instead of being kept it in .data statically. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 2/3] PCI,pciehp: avoid add a device already exist before suspend during resume
>> ---
>> drivers/pci/hotplug/pciehp_core.c |9 ++---
>> 1 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/hotplug/pciehp_core.c
>> b/drivers/pci/hotplug/pciehp_core.c
>> index 7d72c5e..1542735 100644
>> --- a/drivers/pci/hotplug/pciehp_core.c
>> +++ b/drivers/pci/hotplug/pciehp_core.c
> [...]
>> @@ -311,10 +312,12 @@ static int pciehp_resume (struct pcie_device *dev)
>>
>> /* Check if slot is occupied */
>> pciehp_get_adapter_status(slot, );
>> -if (status)
>> -pciehp_enable_slot(slot);
>> -else
>> +if (status) {
>> +if (list_empty(>devices))
>> +pciehp_enable_slot(slot);
>> +} else if (!list_empty(>devices))
>> pciehp_disable_slot(slot);
>> +
>
> Coding style: braces for the "else if" branch too? Or change the first
> test to "if (status && list_empty([...]))" and drop the braces?
Hmmm, I will add the braces for "else if "
Change the first test "if (status && list_empty([...]))" is not a good idea,
because this change will modify the code logic, for example
if a device was present before suspend and still there during resume, we should
do nothing,
but after the logic change, we may disable it.
>
>> return 0;
>> }
>> #endif /* PM */
>
>
> Paul Bolle
>
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/11] 3.4.53-stable review
On Thu, 2013-07-11 at 17:33 -0700, Greg Kroah-Hartman wrote: > On Thu, Jul 11, 2013 at 08:24:33PM -0400, Paul Gortmaker wrote: > > On Thu, Jul 11, 2013 at 6:11 PM, Greg Kroah-Hartman > > wrote: > > > This is the start of the stable review cycle for the 3.4.53 release. > > > There are 11 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 should be made by Sat Jul 13 22:04:03 UTC 2013. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.53-rc1.gz > > > > Just happened to notice the v3.0 in the path vs. the 3.4 version. > > Wasn't sure that was intentional or not, so figured I'd mention it. > > It's intentional, it's always been there, but I guess I could use the > 3.x link instead, they both point to the same place. > I can vouch for it always being there. I had to add a work around in my -rt scripts to test if it was 3.0 or > 3.0, to determine what to post as the patch set to get to an -rt kernel: Or to build 3.0.85-rt113 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.85.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.85-rt113.patch.xz Or to build 3.4.52-rt67 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.52.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.52-rt67.patch.xz Note, it's not just with stable, it's also with the main kernel tree too. But it seems today they are the same directory. I think it wasn't like that before the break in. Otherwise, I doubt I would have spent time on that work around. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v3] x86: make jump_label use int3-based patching
On Thu, 2013-07-11 at 22:26 +0200, Jiri Kosina wrote:
> Make jump labels use text_poke_bp() for text patching instead of
> text_poke_smp(), avoiding the need for stop_machine().
>
> Signed-off-by: Jiri Kosina
> ---
> Changes:
>
> - unchanged since v1, patch 1/2 is the one being updated
>
> arch/x86/kernel/jump_label.c | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
Reviewed-by: Steven Rostedt
-- Steve
> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> index 2889b3d..460f5d9 100644
> --- a/arch/x86/kernel/jump_label.c
> +++ b/arch/x86/kernel/jump_label.c
> @@ -37,7 +37,19 @@ static void __jump_label_transform(struct jump_entry
> *entry,
> } else
> memcpy(, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE);
>
> - (*poker)((void *)entry->code, , JUMP_LABEL_NOP_SIZE);
> + /*
> + * Make text_poke_bp() a default fallback poker.
> + *
> + * At the time the change is being done, just ignore whether we
> + * are doing nop -> jump or jump -> nop transition, and assume
> + * always nop being the 'currently valid' instruction
> + *
> + */
> + if (poker)
> + (*poker)((void *)entry->code, , JUMP_LABEL_NOP_SIZE);
> + else
> + text_poke_bp((void *)entry->code, , JUMP_LABEL_NOP_SIZE,
> + (void *)entry->code + JUMP_LABEL_NOP_SIZE);
> }
>
> void arch_jump_label_transform(struct jump_entry *entry,
> @@ -45,7 +57,7 @@ void arch_jump_label_transform(struct jump_entry *entry,
> {
> get_online_cpus();
> mutex_lock(_mutex);
> - __jump_label_transform(entry, type, text_poke_smp);
> + __jump_label_transform(entry, type, NULL);
> mutex_unlock(_mutex);
> put_online_cpus();
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvm: reset arch memslot info on memslot creation
On Thu, 11 Jul 2013 10:41:53 +0300 Gleb Natapov wrote: > On Wed, Jul 10, 2013 at 10:49:56PM +0900, Takuya Yoshikawa wrote: > > On Wed, 10 Jul 2013 11:24:39 +0300 > > "Michael S. Tsirkin" wrote: > > > > > On x86, kvm_arch_create_memslot assumes that rmap/lpage_info for the > > > slot are zeroed out: if they weren't, error handling code after out_free > > > label will free memory which wasn't allocated here. > > > This always happens to be the case because on KVM_MR_DELETE we clear the > > > whole arch structure. So there's no bug, but it's cleaner not to rely > > > on this here. > > > > Yes, the assumption is that the function is called only with zero-sized > > slots. > > Since changing the size is not allowed, DELETE-CREATE is the only case we > > care about. > > > > But isn't it possible to make it explicit that zero-sized slots have always > > zero-cleared contents instead? Otherwise, there would be many troubles. > > > Do you have something in mind? > I remember that I once wrote code that assumed flags field was cleared before creating a new slot and was pointed out that such assumptions might be dangerous: actually, it's cleared separately but not so easy to notice. So, I want to make it clear what differentiate DELETE'ed slots from others. If we only assume (npages == 0), CREATE should properly set everything, having out_free troubles in mind like this patch. If we also assume the other fields are zero, then DELETE is responsible for that assumption, some comment in code may be helpful. Actually, (rmap==NULL) was once used to check if we needed to allocate memory for a new slot, meaning that we assumed the latter. I felt uneasy and changed that to (npages == 0). Let's make it clear the underlying assumptions now. Takuya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v3] x86: introduce int3-based instruction patching
On Fri, 2013-07-12 at 00:31 +0200, Jiri Kosina wrote: > On Thu, 11 Jul 2013, H. Peter Anvin wrote: > > > > synchronization after replacing "all but first" instructions should not > > > be necessary (on Intel hardware), as the syncing after the subsequent > > > patching of the first byte provides enough safety. > > > But there's not only Intel HW out there, and we'd rather be on a safe > > > side. > > > > Has anyone talked to AMD or VIA about this at all? Did anyone else ever > > make SMP-capable x86? > > If Boris can verify for AMD, that'd be good; we could then just remove one > extra syncing of the cores as a followup (can be done any time later, both > for alternative.c and ftrace in fact). > > With the "extra" sync, the procedure is already verified to work properly > by ftace. > I'd like to caution on the side of safety. The extra sync really doesn't hurt. Let's keep it in for a kernel release cycle to make sure everything else works properly, then we can look at optimizing it. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v3] x86: introduce int3-based instruction patching
On Thu, 2013-07-11 at 22:26 +0200, Jiri Kosina wrote:
Nitpick, and Joe Perches mentioned this earlier too. The below should be
in kerneldoc format. That is:
/**
* text_poke_bp() -- update instructions on live kernel on SMP
> +/*
> + * text_poke_bp() -- update instructions on live kernel on SMP
> + * @addr:address to patch
> + * @opcode: opcode of new instruction
> + * @len: length to copy
> + * @handler: address to jump to when the temporary breakpoint is hit
> + *
> +
> + * Modify multi-byte instruction by using int3 breakpoint on SMP.
Also, you have a missing asterisk.
See Documentation/kernel-doc-nano-HOWTO.txt for more info.
But other than that, you can add my:
Reviewed-by: Steven Rostedt
-- Steve
> + * In contrary to text_poke_smp(), we completely avoid stop_machine() here,
> + * and achieve the synchronization using int3 breakpoint.
> + *
> + * The way it is done:
> + * - add a int3 trap to the address that will be patched
> + * - sync cores
> + * - update all but the first byte of the patched range
> + * - sync cores
> + * - replace the first byte (int3) by the first byte of
> + * replacing opcode
> + * - sync cores
> + *
> + * Note: must be called under text_mutex.
> + */
> +void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
> +{
> + unsigned char int3 = 0xcc;
> +
> + bp_int3_handler = handler;
> + bp_int3_addr = (u8 *)addr + sizeof(int3);
> + bp_patching_in_progress = true;
> + /*
> + * Corresponding read barrier in int3 notifier for
> + * making sure the in_progress flags is correctly ordered wrt.
> + * patching
> + */
> + smp_wmb();
> +
> + text_poke(addr, , sizeof(int3));
> +
> + on_each_cpu(do_sync_core, NULL, 1);
> +
> + if (len - sizeof(int3) > 0) {
> + /* patch all but the first byte */
> + text_poke((char *)addr + sizeof(int3),
> + (const char *) opcode + sizeof(int3),
> + len - sizeof(int3));
> + /*
> + * According to Intel, this core syncing is very likely
> + * not necessary and we'd be safe even without it. But
> + * better safe than sorry (plus there's not only Intel).
> + */
> + on_each_cpu(do_sync_core, NULL, 1);
> + }
> +
> + /* patch the first byte */
> + text_poke(addr, opcode, sizeof(int3));
> +
> + on_each_cpu(do_sync_core, NULL, 1);
> +
> + bp_patching_in_progress = false;
> + smp_wmb();
> +
> + return addr;
> +}
> +
> +/* this one needs to run before anything else handles it as a
> + * regular exception */
> +static struct notifier_block int3_nb = {
> + .priority = 0x7fff,
> + .notifier_call = int3_notify
> +};
> +
> +static int __init int3_init(void)
> +{
> + return register_die_notifier(_nb);
> +}
> +
> +arch_initcall(int3_init);
> /*
> * Cross-modifying kernel text with stop_machine().
> * This code originally comes from immediate value.
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index bddf3b2..d6db7bd 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1709,7 +1709,7 @@ EXPORT_SYMBOL_GPL(unregister_kprobes);
>
> static struct notifier_block kprobe_exceptions_nb = {
> .notifier_call = kprobe_exceptions_notify,
> - .priority = 0x7fff /* we need to be notified first */
> + .priority = 0x7ff0 /* High priority, but not first. */
> };
>
> unsigned long __weak arch_deref_entry_point(void *entry)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/4] Have __free_pages_memory() free in larger chunks.
Currently, when free_all_bootmem() calls __free_pages_memory(), the
number of contiguous pages that __free_pages_memory() passes to the
buddy allocator is limited to BITS_PER_LONG. In order to be able to
free only the first page of a 2MiB chunk, we need that to be increased
to PTRS_PER_PMD.
Signed-off-by: Robin Holt
Signed-off-by: Nate Zimmer
To: "H. Peter Anvin"
To: Ingo Molnar
Cc: Linux Kernel
Cc: Linux MM
Cc: Rob Landley
Cc: Mike Travis
Cc: Daniel J Blueman
Cc: Andrew Morton
Cc: Greg KH
Cc: Yinghai Lu
Cc: Mel Gorman
---
mm/nobootmem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index bdd3fa2..3b512ca 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -83,10 +83,10 @@ void __init free_bootmem_late(unsigned long addr, unsigned
long size)
static void __init __free_pages_memory(unsigned long start, unsigned long end)
{
unsigned long i, start_aligned, end_aligned;
- int order = ilog2(BITS_PER_LONG);
+ int order = ilog2(max(BITS_PER_LONG, PTRS_PER_PMD));
- start_aligned = (start + (BITS_PER_LONG - 1)) & ~(BITS_PER_LONG - 1);
- end_aligned = end & ~(BITS_PER_LONG - 1);
+ start_aligned = (start + ((1UL << order) - 1)) & ~((1UL << order) - 1);
+ end_aligned = end & ~((1UL << order) - 1);
if (end_aligned <= start_aligned) {
for (i = start; i < end; i++)
@@ -98,7 +98,7 @@ static void __init __free_pages_memory(unsigned long start,
unsigned long end)
for (i = start; i < start_aligned; i++)
__free_pages_bootmem(pfn_to_page(i), 0);
- for (i = start_aligned; i < end_aligned; i += BITS_PER_LONG)
+ for (i = start_aligned; i < end_aligned; i += 1 << order)
__free_pages_bootmem(pfn_to_page(i), order);
for (i = end_aligned; i < end; i++)
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/4] Transparent on-demand struct page initialization embedded in the buddy allocator
We have been working on this since we returned from shutdown and have something to discuss now. We restricted ourselves to 2MiB initialization to keep the patch set a little smaller and more clear. First, I think I want to propose getting rid of the page flag. If I knew of a concrete way to determine that the page has not been initialized, this patch series would look different. If there is no definitive way to determine that the struct page has been initialized aside from checking the entire page struct is zero, then I think I would suggest we change the page flag to indicate the page has been initialized. The heart of the problem as I see it comes from expand(). We nearly always see a first reference to a struct page which is in the middle of the 2MiB region. Due to that access, the unlikely() check that was originally proposed really ends up referencing a different page entirely. We actually did not introduce an unlikely and refactor the patches to make that unlikely inside a static inline function. Also, given the strong warning at the head of expand(), we did not feel experienced enough to refactor it to make things always reference the 2MiB page first. With this patch, we did boot a 16TiB machine. Without the patches, the v3.10 kernel with the same configuration took 407 seconds for free_all_bootmem. With the patches and operating on 2MiB pages instead of 1GiB, it took 26 seconds so performance was improved. I have no feel for how the 1GiB chunk size will perform. I am on vacation for the next three days so I am sorry in advance for my infrequent or non-existant responses. Signed-off-by: Robin Holt Signed-off-by: Nate Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/4] memblock: Introduce a for_each_reserved_mem_region iterator.
As part of initializing struct page's in 2MiB chunks, we noticed that
at the end of free_all_bootmem(), there was nothing which had forced
the reserved/allocated 4KiB pages to be initialized.
This helper function will be used for that expansion.
Signed-off-by: Robin Holt
Signed-off-by: Nate Zimmer
To: "H. Peter Anvin"
To: Ingo Molnar
Cc: Linux Kernel
Cc: Linux MM
Cc: Rob Landley
Cc: Mike Travis
Cc: Daniel J Blueman
Cc: Andrew Morton
Cc: Greg KH
Cc: Yinghai Lu
Cc: Mel Gorman
---
include/linux/memblock.h | 18 ++
mm/memblock.c| 32
2 files changed, 50 insertions(+)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index f388203..e99bbd1 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -118,6 +118,24 @@ void __next_free_mem_range_rev(u64 *idx, int nid,
phys_addr_t *out_start,
i != (u64)ULLONG_MAX; \
__next_free_mem_range_rev(, nid, p_start, p_end, p_nid))
+void __next_reserved_mem_region(u64 *idx, phys_addr_t *out_start,
+ phys_addr_t *out_end);
+
+/**
+ * for_earch_reserved_mem_region - iterate over all reserved memblock areas
+ * @i: u64 used as loop variable
+ * @p_start: ptr to phys_addr_t for start address of the range, can be %NULL
+ * @p_end: ptr to phys_addr_t for end address of the range, can be %NULL
+ *
+ * Walks over reserved areas of memblock in. Available as soon as memblock
+ * is initialized.
+ */
+#define for_each_reserved_mem_region(i, p_start, p_end)
\
+ for (i = 0UL, \
+__next_reserved_mem_region(, p_start, p_end);\
+i != (u64)ULLONG_MAX; \
+__next_reserved_mem_region(, p_start, p_end))
+
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
int memblock_set_node(phys_addr_t base, phys_addr_t size, int nid);
diff --git a/mm/memblock.c b/mm/memblock.c
index c5fad93..0d7d6e7 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -564,6 +564,38 @@ int __init_memblock memblock_reserve(phys_addr_t base,
phys_addr_t size)
}
/**
+ * __next_reserved_mem_region - next function for for_each_reserved_region()
+ * @idx: pointer to u64 loop variable
+ * @out_start: ptr to phys_addr_t for start address of the region, can be %NULL
+ * @out_end: ptr to phys_addr_t for end address of the region, can be %NULL
+ *
+ * Iterate over all reserved memory regions.
+ */
+void __init_memblock __next_reserved_mem_region(u64 *idx,
+ phys_addr_t *out_start,
+ phys_addr_t *out_end)
+{
+ struct memblock_type *rsv =
+
+ if (*idx >= 0 && *idx < rsv->cnt) {
+ struct memblock_region *r = >regions[*idx];
+ phys_addr_t base = r->base;
+ phys_addr_t size = r->size;
+
+ if (out_start)
+ *out_start = base;
+ if (out_end)
+ *out_end = base + size - 1;
+
+ *idx += 1;
+ return;
+ }
+
+ /* signal end of iteration */
+ *idx = ULLONG_MAX;
+}
+
+/**
* __next_free_mem_range - next function for for_each_free_mem_range()
* @idx: pointer to u64 loop variable
* @nid: nid: node selector, %MAX_NUMNODES for all nodes
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PCIE resetting graphic card
Hi, Takao I know you are working on the PCIE resetting patches for the iommu kdump issue. You explicitly excluded the graphic card in your patch. I have some questions about this. Why can't we reset the graphic card like other pcie devices? We have problems, if 1st kernel is in kms mode kdump kernel will have no chance to switch back to VGA console. There's no serial port on most of recent laptops thus it's difficult to debug kdump issue. So if we can reset graphic card as well, and if it works I wonder if the 2nd kdump kernel can use vga console with nomodeset? -- Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/4] Seperate page initialization into a separate function.
Currently, memmap_init_zone() has all the smarts for initializing a
single page. When we convert to initializing pages in a 2MiB chunk,
we will need to do this equivalent work from two separate places
so we are breaking out a helper function.
Signed-off-by: Robin Holt
Signed-off-by: Nate Zimmer
To: "H. Peter Anvin"
To: Ingo Molnar
Cc: Linux Kernel
Cc: Linux MM
Cc: Rob Landley
Cc: Mike Travis
Cc: Daniel J Blueman
Cc: Andrew Morton
Cc: Greg KH
Cc: Yinghai Lu
Cc: Mel Gorman
---
mm/mm_init.c| 2 +-
mm/page_alloc.c | 75 +
2 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/mm/mm_init.c b/mm/mm_init.c
index c280a02..be8a539 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -128,7 +128,7 @@ void __init mminit_verify_pageflags_layout(void)
BUG_ON(or_mask != add_mask);
}
-void __meminit mminit_verify_page_links(struct page *page, enum zone_type zone,
+void mminit_verify_page_links(struct page *page, enum zone_type zone,
unsigned long nid, unsigned long pfn)
{
BUG_ON(page_to_nid(page) != nid);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c3edb62..635b131 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -697,6 +697,49 @@ static void free_one_page(struct zone *zone, struct page
*page, int order,
spin_unlock(>lock);
}
+static void __init_single_page(struct page *page, unsigned long zone, int nid,
int reserved)
+{
+ unsigned long pfn = page_to_pfn(page);
+ struct zone *z = _DATA(nid)->node_zones[zone];
+
+ set_page_links(page, zone, nid, pfn);
+ mminit_verify_page_links(page, zone, nid, pfn);
+ init_page_count(page);
+ page_mapcount_reset(page);
+ page_nid_reset_last(page);
+ if (reserved) {
+ SetPageReserved(page);
+ } else {
+ ClearPageReserved(page);
+ set_page_count(page, 0);
+ }
+ /*
+* Mark the block movable so that blocks are reserved for
+* movable at startup. This will force kernel allocations
+* to reserve their blocks rather than leaking throughout
+* the address space during boot when many long-lived
+* kernel allocations are made. Later some blocks near
+* the start are marked MIGRATE_RESERVE by
+* setup_zone_migrate_reserve()
+*
+* bitmap is created for zone's valid pfn range. but memmap
+* can be created for invalid pages (for alignment)
+* check here not to call set_pageblock_migratetype() against
+* pfn out of zone.
+*/
+ if ((z->zone_start_pfn <= pfn)
+ && (pfn < zone_end_pfn(z))
+ && !(pfn & (pageblock_nr_pages - 1)))
+ set_pageblock_migratetype(page, MIGRATE_MOVABLE);
+
+ INIT_LIST_HEAD(>lru);
+#ifdef WANT_PAGE_VIRTUAL
+ /* The shift won't overflow because ZONE_NORMAL is below 4G. */
+ if (!is_highmem_idx(zone))
+ set_page_address(page, __va(pfn << PAGE_SHIFT));
+#endif
+}
+
static bool free_pages_prepare(struct page *page, unsigned int order)
{
int i;
@@ -3934,37 +3977,7 @@ void __meminit memmap_init_zone(unsigned long size, int
nid, unsigned long zone,
continue;
}
page = pfn_to_page(pfn);
- set_page_links(page, zone, nid, pfn);
- mminit_verify_page_links(page, zone, nid, pfn);
- init_page_count(page);
- page_mapcount_reset(page);
- page_nid_reset_last(page);
- SetPageReserved(page);
- /*
-* Mark the block movable so that blocks are reserved for
-* movable at startup. This will force kernel allocations
-* to reserve their blocks rather than leaking throughout
-* the address space during boot when many long-lived
-* kernel allocations are made. Later some blocks near
-* the start are marked MIGRATE_RESERVE by
-* setup_zone_migrate_reserve()
-*
-* bitmap is created for zone's valid pfn range. but memmap
-* can be created for invalid pages (for alignment)
-* check here not to call set_pageblock_migratetype() against
-* pfn out of zone.
-*/
- if ((z->zone_start_pfn <= pfn)
- && (pfn < zone_end_pfn(z))
- && !(pfn & (pageblock_nr_pages - 1)))
- set_pageblock_migratetype(page, MIGRATE_MOVABLE);
-
- INIT_LIST_HEAD(>lru);
-#ifdef WANT_PAGE_VIRTUAL
- /* The shift won't overflow because ZONE_NORMAL is below 4G. */
- if (!is_highmem_idx(zone))
- set_page_address(page, __va(pfn << PAGE_SHIFT));
-#endif
+ __init_single_page(page, zone, nid, 1);
}
}
[RFC 4/4] Sparse initialization of struct page array.
During boot of large memory machines, a significant portion of boot
is spent initializing the struct page array. The vast majority of
those pages are not referenced during boot.
Change this over to only initializing the pages when they are
actually allocated.
Besides the advantage of boot speed, this allows us the chance to
use normal performance monitoring tools to determine where the bulk
of time is spent during page initialization.
Signed-off-by: Robin Holt
Signed-off-by: Nate Zimmer
To: "H. Peter Anvin"
To: Ingo Molnar
Cc: Linux Kernel
Cc: Linux MM
Cc: Rob Landley
Cc: Mike Travis
Cc: Daniel J Blueman
Cc: Andrew Morton
Cc: Greg KH
Cc: Yinghai Lu
Cc: Mel Gorman
---
include/linux/mm.h | 11 +
include/linux/page-flags.h | 5 +-
mm/nobootmem.c | 5 ++
mm/page_alloc.c| 117 +++--
4 files changed, 132 insertions(+), 6 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index e0c8528..3de08b5 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1330,8 +1330,19 @@ static inline void __free_reserved_page(struct page
*page)
__free_page(page);
}
+extern void __reserve_bootmem_region(phys_addr_t start, phys_addr_t end);
+
+static inline void __reserve_bootmem_page(struct page *page)
+{
+ phys_addr_t start = page_to_pfn(page) << PAGE_SHIFT;
+ phys_addr_t end = start + PAGE_SIZE;
+
+ __reserve_bootmem_region(start, end);
+}
+
static inline void free_reserved_page(struct page *page)
{
+ __reserve_bootmem_page(page);
__free_reserved_page(page);
adjust_managed_page_count(page, 1);
}
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 6d53675..79e8eb7 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -83,6 +83,7 @@ enum pageflags {
PG_owner_priv_1,/* Owner use. If pagecache, fs may use*/
PG_arch_1,
PG_reserved,
+ PG_uninitialized2mib, /* Is this the right spot? ntz - Yes - rmh */
PG_private, /* If pagecache, has fs-private data */
PG_private_2, /* If pagecache, has fs aux data */
PG_writeback, /* Page is under writeback */
@@ -211,6 +212,8 @@ PAGEFLAG(SwapBacked, swapbacked)
__CLEARPAGEFLAG(SwapBacked, swapbacked)
__PAGEFLAG(SlobFree, slob_free)
+PAGEFLAG(Uninitialized2Mib, uninitialized2mib)
+
/*
* Private page markings that may be used by the filesystem that owns the page
* for its own purposes.
@@ -499,7 +502,7 @@ static inline void ClearPageSlabPfmemalloc(struct page
*page)
#define PAGE_FLAGS_CHECK_AT_FREE \
(1 << PG_lru | 1 << PG_locked| \
1 << PG_private | 1 << PG_private_2 | \
-1 << PG_writeback | 1 << PG_reserved | \
+1 << PG_writeback | 1 << PG_reserved | 1 << PG_uninitialized2mib | \
1 << PG_slab| 1 << PG_swapcache | 1 << PG_active | \
1 << PG_unevictable | __PG_MLOCKED | __PG_HWPOISON | \
__PG_COMPOUND_LOCK)
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index 3b512ca..e3a386d 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -126,6 +126,9 @@ static unsigned long __init free_low_memory_core_early(void)
phys_addr_t start, end, size;
u64 i;
+ for_each_reserved_mem_region(i, , )
+ __reserve_bootmem_region(start, end);
+
for_each_free_mem_range(i, MAX_NUMNODES, , , NULL)
count += __free_memory_core(start, end);
@@ -162,6 +165,8 @@ unsigned long __init free_all_bootmem(void)
{
struct pglist_data *pgdat;
+ memblock_dump_all();
+
for_each_online_pgdat(pgdat)
reset_node_lowmem_managed_pages(pgdat);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 635b131..fe51eb9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -740,6 +740,54 @@ static void __init_single_page(struct page *page, unsigned
long zone, int nid, i
#endif
}
+static void expand_page_initialization(struct page *basepage)
+{
+ unsigned long pfn = page_to_pfn(basepage);
+ unsigned long end_pfn = pfn + PTRS_PER_PMD;
+ unsigned long zone = page_zonenum(basepage);
+ int reserved = PageReserved(basepage);
+ int nid = page_to_nid(basepage);
+
+ ClearPageUninitialized2Mib(basepage);
+
+ for( pfn++; pfn < end_pfn; pfn++ )
+ __init_single_page(pfn_to_page(pfn), zone, nid, reserved);
+}
+
+void ensure_pages_are_initialized(unsigned long start_pfn,
+ unsigned long end_pfn)
+{
+ unsigned long aligned_start_pfn = start_pfn & ~(PTRS_PER_PMD - 1);
+ unsigned long aligned_end_pfn;
+ struct page *page;
+
+ aligned_end_pfn = end_pfn & ~(PTRS_PER_PMD - 1);
+ aligned_end_pfn += PTRS_PER_PMD;
+ while (aligned_start_pfn < aligned_end_pfn) {
+ if (pfn_valid(aligned_start_pfn)) {
+ page =
Re: [PATCH] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
On 07/12/2013 09:41 AM, Steven Rostedt wrote: > On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote: > >> > Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c) >> > use '__init', so not waste memory keeping them around ? > Yeah, they should all be set to __init, but that's pretty low on the > totem poll, as distros don't enable selftests in their main kernels. Excuse me, my English is not quite well, I guess your meaning is: they should all be set to '__init', although it is minor in real world. Is it correct ? For me, I recommend to let all *selftest* as the same: "all add ' __init' or none add '__init'" (if choose add, all report warnings). Is it suitable to still send new related patch for it ? If so, could you provide your suggesting choice (all add, or none add) ? Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 1/3] PCI: introduce PCIe Device Serial Number Capability support
>>
> [...]
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 0fd1f15..10d190b 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -342,6 +342,7 @@ struct pci_dev {
>> struct list_head msi_list;
>> struct kset *msi_kset;
>> #endif
>> +u64 sn; /* device serieal number, 0 if not support */
>
> Typo: serieal
Thanks very much! Will update.
>
>> struct pci_vpd *vpd;
>> #ifdef CONFIG_PCI_ATS
>> union {
>
> [...]
>
>
> Paul Bolle
>
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 0/3] Use PCIe DSN to improve pciehp_resume
On 2013/7/11 22:19, Paul Bolle wrote: > On Thu, 2013-07-11 at 17:43 +0800, Yijing Wang wrote: >> v1->v2: Modify pci_get_dsn to pci_device_serial_number, >> power off slot before remove the old device during resume to avoid >> old .remove() method to touch new hardware. >> Fix other typo and fail check problems. >> Split the list_empty() guard into new patch. >> >> >> Yijing Wang (3): >> PCI: introduce PCIe Device Serial Number Capability support >> PCI,pciehp: avoid add a device already exist before suspend during >> resume >> PCI,pciehp: use PCIe DSN to identify device change during suspend >> >> drivers/pci/hotplug/pciehp_core.c | 54 >> ++-- >> drivers/pci/pci.c | 27 ++ >> drivers/pci/probe.c |2 + >> include/linux/pci.h |3 ++ >> 4 files changed, 83 insertions(+), 3 deletions(-) > > Series applies cleanly to v3.10 (but there was a small problem with 3/3, > which I'll mention in a reply to that patch). Compiles without warning. > Those two errors on every resume are now gone! I will check patch 3/3, Paul, Do you wireless card support Device Serial Number ? You can confirm it by lspci -vvv. > > Thanks. > > > Paul Bolle > > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote: > Maybe the pendulum has swung too far in the direction of holding back > changes and trying to avoid the risk of introducing regressions; > perhaps this would be a good topic to discuss at the Kernel Summit. Bah, I sent out a similar email about discussing this at KS too. Before seeing this one. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/19] 3.10.1-stable review
On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote: > > For .10 I had to start making a list of "shit that's broken that there's > > an outstanding patch for" and nagging people to send them week after week. > > Every time I reported a new bug I'd hit, I'd have to explain I wasn't > > running > > Linus' tree because there was so much other crap I had to carry just to > > get things to a baseline of stability before starting tests. > > > > By rc7 things got a lot better, but if we have fixes sitting around in > > git trees for weeks on end with no progress, that kinda sucks. > > We have patches with assigned CVE numbers sitting in subsystem trees > that didn't hit Linus's tree until this merge window. Now granted, I > don't necessarily agree that they were worth CVEs, but really, holding > them off from being merged for 2 months or so is really bad, and means > that something seems a bit broken with our development process. > > And thanks for nagging people, I really appreciate it, sad it's > necessary. What I try to do is, get all "stable" patches in before -rc4 is out. Once -rc4 is out, then I get a bit more picky with what to push to Linus. If it's not a regression (something that's been broken for a while) I don't push it. -rc5, I get even pickier, and by -rc6 and beyond, I only push things that may crash the kernel. If things just give bad output (for tracing), I tag it with stable and wait for the merge window. 3.10 was actually really bad for me. I had some major changes done to ftrace, and there were a lot of patches sent to me after -rc4 came out. A lot of them were nits and didn't crash the kernel, thus I only tagged them with stable. Some of them, we didn't get correct until Linus opened the merge window. Maybe this would be a good KS topic. What exactly is appropriate to push during the -rc's. Perhaps have criteria for the -rc levels. -rc1-3, take all bug fixes. -rc4,5, regressions, and more substantial bugs -rc6-.. get your act together. Only critical bug fixes. ?? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] PCI,pciehp: avoid add a device already exist during pciehp_resume
On 2013/7/11 18:19, Paul Bolle wrote: > Yijing, > > On Thu, 2013-07-11 at 11:55 +0800, Yijing Wang wrote: >> Can you provide the lspci -vvv and lspci - info messages ? >> I want to confirm your hardware information which cause your resume error. >> You can get these messages in any kernel version, that's ok. > > Would it be sufficient to send that information just for the two pcie > ports on my laptop, and the wireless card that is present in one of > those two ports? > If you can provide both the lspci -vvv and lspci - info before suspend and after resume, it's better. > And would it be OK to send that information off list? OK~ Thanks! Yijing. > >> When you suspend and resume the system, the wireless card is always >> present in pcie slot, right? > > Yes. I actually wouldn't even know how to remove it. I only discovered > my wireless card was in a pcie slot because of the error messages at > resume (which started a few releases ago, I think v3.7). > > > Paul Bolle > > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ext4: fix ext4_get_group_number() at cluster boundaries
On Thu, Jul 11, 2013 at 12:28:48PM +0100, Andy Whitcroft wrote: > Commit bd86298e60b8 introduced a new optimisation for callers who needed > only the ext4 group number and not the block offset within. It hand > calculates the group number from the block in the common case, falling > back to the original group offset implementation otherwise. A fix for this problem is already in the ext4 tree, and will be pushed to Linus shortly: http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/commit/?h=dev=960fd856fdc3b08b3638f3f9b6b4bfceb77660c7 Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 11 (usb/chipidea)
On Fri, Jul 12, 2013 at 2:47 AM, Randy Dunlap wrote: > On 07/10/13 21:17, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20130710: >> > > > on x86_64: > > # CONFIG_USB_GADGET is not set > > ERROR: "usb_gadget_map_request" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > ERROR: "usb_del_gadget_udc" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > ERROR: "usb_gadget_unmap_request" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > ERROR: "usb_add_gadget_udc" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > > > > Full randconfig file is attached. > > Should be fixed with below fix, the problem is the same with host. http://marc.info/?l=linux-usb=137331577204167=2 -- BR, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
On Thu, 11 Jul 2013, Michal Hocko wrote: > On Thu 11-07-13 12:26:34, Dave Chinner wrote: > > On Wed, Jul 10, 2013 at 10:06:05AM +0200, Michal Hocko wrote: > > > On Wed 10-07-13 12:31:39, Dave Chinner wrote: > > > [...] > > > > > 20761 [] xlog_grant_head_wait+0xdd/0x1a0 [xfs] > > > > > [] xlog_grant_head_check+0xc6/0xe0 [xfs] > > > > > [] xfs_log_reserve+0xff/0x240 [xfs] > > > > > [] xfs_trans_reserve+0x234/0x240 [xfs] > > > > > [] xfs_create+0x1a9/0x5c0 [xfs] > > > > > [] xfs_vn_mknod+0x8a/0x1a0 [xfs] > > > > > [] xfs_vn_create+0xe/0x10 [xfs] > > > > > [] vfs_create+0xad/0xd0 > > > > > [] lookup_open+0x1b8/0x1d0 > > > > > [] do_last+0x2de/0x780 > > > > > [] path_openat+0xda/0x400 > > > > > [] do_filp_open+0x43/0xa0 > > > > > [] do_sys_open+0x160/0x1e0 > > > > > [] sys_open+0x1c/0x20 > > > > > [] system_call_fastpath+0x16/0x1b > > > > > [] 0x > > > > > > > > That's an XFS log space issue, indicating that it has run out of > > > > space in IO the log and it is waiting for more to come free. That > > > > requires IO completion to occur. > > > > > > > > > [276962.652076] INFO: task xfs-data/sda9:930 blocked for more than > > > > > 480 seconds. > > > > > [276962.652087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > > > > disables this message. > > > > > [276962.652093] xfs-data/sda9 D 88001ffb9cc8 0 930 2 > > > > > 0x > > > > > > > > Oh, that's why. This is the IO completion worker... > > > > > > But that task doesn't seem to be stuck anymore (at least lockup watchdog > > > doesn't report it anymore and I have already rebooted to test with ext3 > > > :/). I am sorry if the these lockups logs were more confusing than > > > helpful, but they happened _long_ time ago and the system obviously > > > recovered from them. I am pasting only the traces for processes in D > > > state here again for reference. > > > > Right, there are various triggers that can get XFS out of the > > situation - it takes something to kick the log or metadata writeback > > and that can make space in the log free up and hence things get > > moving again. The problem will be that once in this low memory state > > everything in the filesystem will back up on slow memory allocation > > and it might take minutes to clear the backlog of IO completions > > > > > 20757 [] xlog_grant_head_wait+0xdd/0x1a0 [xfs] > > > [] xlog_grant_head_check+0xc6/0xe0 [xfs] > > > [] xfs_log_reserve+0xff/0x240 [xfs] > > > [] xfs_trans_reserve+0x234/0x240 [xfs] > > > > That is the stack of a process waiting for log space to come > > available. > > > > > We are wating for page under writeback but neither of the 2 paths starts > > > in xfs code. So I do not think waiting for PageWriteback causes a > > > deadlock here. > > > > The problem is this: the page that we are waiting for IO on is in > > the IO completion queue, but the IO compeltion requires memory > > allocation to complete the transaction. That memory allocation is > > causing memcg reclaim, which then waits for IO completion on another > > page, which may or may not end up in the same IO completion queue. > > The CMWQ can continue to process new Io completions - up to a point > > - so slow progress will be made. In the worst case, it can deadlock. > > OK, I thought something like that was going on but I just wanted to be > sure that I didn't manage to confuse you by the lockup messages. > > > > GFP_NOFS allocation is the mechanism by which filesystems are > > supposed to be able to avoid this recursive deadlock... > > Yes. > > > > [...] > > > > ... is running IO completion work and trying to commit a transaction > > > > that is blocked in memory allocation which is waiting for IO > > > > completion. It's disappeared up it's own fundamental orifice. > > > > > > > > Ok, this has absolutely nothing to do with the LRU changes - this is > > > > a pre-existing XFS/mm interaction problem from around 3.2. The > > > > question is now this: how the hell do I get memory allocation to not > > > > block waiting on IO completion here? This is already being done in > > > > GFP_NOFS allocation context here > > > > > > Just for reference. wait_on_page_writeback is issued only for memcg > > > reclaim because there is no other throttling mechanism to prevent from > > > too many dirty pages on the list, thus pre-mature OOM killer. See > > > e62e384e9d (memcg: prevent OOM with too many dirty pages) for more > > > details. The original patch relied on may_enter_fs but that check > > > disappeared by later changes by c3b94f44fc (memcg: further prevent OOM > > > with too many dirty pages). > > > > Aye. That's the exact code I was looking at yesterday and wondering > > "how the hell is waiting on page writeback valid in GFP_NOFS > > context?". It seems that memcg reclaim is intentionally ignoring > > GFP_NOFS to avoid OOM issues. That's a memcg implementation problem, > > not a filesystem or LRU infrastructure problem > > Agreed and until we have a
Re: [PATCH] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote: > Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c) > use '__init', so not waste memory keeping them around ? Yeah, they should all be set to __init, but that's pretty low on the totem poll, as distros don't enable selftests in their main kernels. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 1/3] PCI: introduce PCIe Device Serial Number Capability support
Hi Don,
Thanks for your review and comments very much!
>> +dev->sn = pci_device_serial_number(dev);
>> +
> Finally, 'the comment below':
> I know you were following Bjorn's suggestion, which I thought
> was an improvement, but why not do above assignment in
> pci_device_serial_number() ?
I don't do assignment in pci_device_serial_number() because
pci_device_serial_number()
is an EXPORT_SYMBOL, and will be used to get dsn for non-scaned device, for
example:
1. we have pcie device in slot before suspend.
2. we removed the device during suspend.
3. we reinserted a new device during suspend.
4. we should check the device change during resume, so we
try to use pcie device serial number to identify changes.
But the pci_dev structure maybe the old stale data. So
I prefer to get dsn by return.
what about this:
static void pci_init_capabilities(struct pci_dev *dev)
pci_dsn_init(dev);
..
void pci_dsn_init(dev)
{
dev->sn = pci_device_serial_number(dev);
}
> See above
> - Don
>
>> /* Vital Product Data */
>> pci_vpd_pci22_init(dev);
>>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 0fd1f15..10d190b 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -342,6 +342,7 @@ struct pci_dev {
>> struct list_head msi_list;
>> struct kset *msi_kset;
>> #endif
>> +u64 sn;/* device serieal number, 0 if not support */
>> struct pci_vpd *vpd;
>> #ifdef CONFIG_PCI_ATS
>> union {
>> @@ -995,6 +996,8 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
>> size_t count, void *buf);
>> ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
>> void *buf);
>> int pci_vpd_truncate(struct pci_dev *dev, size_t size);
>>
>> +u64 pci_device_serial_number(struct pci_dev *dev);
>> +
>> /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
>> resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
>> void pci_bus_assign_resources(const struct pci_bus *bus);
>
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote: > On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote: > > Drilling down the work items ahead of a real mainline push is high on > > priority list for discussion. > > > > The parties to be included in such a discussion are: > > > > - Jens Axboe (blk-mq author) > > - James Bottomley (scsi maintainer) > > - Christoph Hellwig (scsi) > > - Martin Petersen (scsi) > > - Tejun Heo (block + libata) > > - Hannes Reinecke (scsi error recovery) > > - Kent Overstreet (block, per-cpu ida) > > - Stephen Cameron (scsi-over-pcie driver) > > - Andrew Vasquez (qla2xxx LLD) > > - James Smart (lpfc LLD) > > Isn't this something that should have been discussed at the storage > mini-summit a few months ago? The scsi-mq prototype, along with blk-mq (in it's current form) did not exist a few short months ago. ;) > It seems very specific to one subsystem to be a kernel summit topic, > don't you think? It's no more subsystem specific than half of the other proposals so far, and given it's reach across multiple subsystems (block, scsi, target), and the amount of off-list interest on the topic, I think it would make a good candidate for discussion. Thanks, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote: > On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote: > > > > I'm sitting on top of over 170 more patches that have been marked for > > the stable releases right now that are not included in this set of > > releases. The fact that there are this many patches for stable stuff > > that are waiting to be merged through the main -rc1 merge window cycle > > is worrying to me. > > > > Why are subsystem maintainers holding on to fixes that are > > _supposedly_ affecting all users? I mean, 21 powerpc core changes > > that I don't see until a -rc1 merge? It's as if developers don't > > expect people to use a .0 release and are relying on me to get the > > fixes they have burried in their trees out to users. That's not that > > nice. 6 "core" iscsi-target fixes? That's the sign of either a > > broken subsystem maintainer, or a lack of understanding what the > > normal -rc kernel releases are supposed to be for. > In my defense here, the patches that have been CC'ed to 3.10.y stable are to address bugs in iser-target, and it's interaction with existing iscsi-target code after the large set of refactoring changes went in to support multi-transport operation. The reasons that they where not included in a v3.10-rc pull request is because the bugs where found sufficiently late enough in the cycle, and required large enough changes plus a non trival amount of manual failure injection testing to verify their correctness. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [git pull] device-mapper changes for 3.11
Hi Alasdair, On Thu, 11 Jul 2013 14:55:22 +0100 Alasdair G Kergon wrote: > > On Thu, Jul 11, 2013 at 04:20:40PM +1000, Stephen Rothwell wrote: > > Alistair, is there some reason that you cannot maintain some relatively > > stable git tree for me to fetch (instead of the quilt series). > > Well Mike Snitzer is becoming a joint maintainer and this also requires > changes to the workflow so watch this space. OK, noted. > > Also, > > there is not real reason to keep rebasing this stuff (especially just > > before sending it to Linus). > > Most of the time the patches are decoupled from the rest of the tree > and the final linux-next kernel is the same regardless of where the > quilt tree is attached. I maintain a single sequence of patches > where the ones ready for upstream float up to the top and the > linux-next export is a by-product and not the primary output. > > Anyway, like I say, we'll be changing things during the next couple of > cycles and we'll bear your suggestions in mind. Thanks, I will watch for developments. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFQBnCeH49Q.pgp Description: PGP signature
Re: [git pull] device-mapper changes for 3.11
Hi Mike, On Thu, 11 Jul 2013 09:35:11 -0400 Mike Snitzer wrote: > > I'll be transitioning in to maintain device mapper (for 3.12). Alasdair > will be helping me as needed but ultimately the plan is for me to be the > one sending DM changes upstream in the future. I will maintain a > kernel.org git tree with a 'for-next' branch for you to pull. I'll > likely base my for-next on Jens' for-next as a rule (unless that isn't > ideal on a linux-next process level). OK, that sounds fine as long as Jen's never rebases his branch (I think he is pretty good about that). > There will be a learning curve for me initially on how to interface with > linux-next, proper git rebase protocol relative to Linus' ideals, etc > but I hope to cut through that quickly. Excellent. Please feel free to ask if you have any questions. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpzgc3neLJvX.pgp Description: PGP signature
Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote: > Drilling down the work items ahead of a real mainline push is high on > priority list for discussion. > > The parties to be included in such a discussion are: > > - Jens Axboe (blk-mq author) > - James Bottomley (scsi maintainer) > - Christoph Hellwig (scsi) > - Martin Petersen (scsi) > - Tejun Heo (block + libata) > - Hannes Reinecke (scsi error recovery) > - Kent Overstreet (block, per-cpu ida) > - Stephen Cameron (scsi-over-pcie driver) > - Andrew Vasquez (qla2xxx LLD) > - James Smart (lpfc LLD) Isn't this something that should have been discussed at the storage mini-summit a few months ago? It seems very specific to one subsystem to be a kernel summit topic, don't you think? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 1/2 v2] x86: introduce int3-based instruction patching
(2013/07/12 1:46), Steven Rostedt wrote: > On Thu, 2013-07-11 at 09:31 -0700, H. Peter Anvin wrote: > >> The current code assumes that one of the two code sequences is a NOP, >> and therefore that jumping over the region is legal. This does not >> allow for transitioning one active code sequence to another. > > Correct, and I think we should keep the two changes separate, as the NOP > case is trivial. No need to complicate the trivial and common updates > (jump_labels and ftrace). But for things like kprobes, we could do a bit > more complex code, but it should probably be separate. Don't mind, kprobes optimization code prepares the destination code buffer to jump in before code patching. Thus, we just need to give the buffer address to text_poke_bp(). Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Remove Grant Likely
Unfortunately, I'm no longer to spend the time needed on maintainership. It is time for me to step aside and pass maintainership to other engineers. I'm not disappearing from Linux development, but it would be irresponsible for me to hold onto a job that I am unable to do. GPIO and SPI are in good hands with Linus and Mark. Rob Herring has a really good grasp on the DT core code, and in the last week there have been several volunteers to create and maintain a DT bindings tree. You can expect to see an email about that hit the list shortly. Signed-off-by: Grant Likely --- MAINTAINERS | 8 1 file changed, 8 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 250dc97..339fcdd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3564,10 +3564,8 @@ F: drivers/isdn/gigaset/ F: include/uapi/linux/gigaset_dev.h GPIO SUBSYSTEM -M: Grant Likely M: Linus Walleij S: Maintained -T: git git://git.secretlab.ca/git/linux-2.6.git F: Documentation/gpio.txt F: drivers/gpio/ F: include/linux/gpio* @@ -4411,8 +4409,6 @@ F:drivers/irqchip/ IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY) M: Benjamin Herrenschmidt -M: Grant Likely -T: git git://git.secretlab.ca/git/linux-2.6.git irqdomain/next S: Maintained F: Documentation/IRQ-domain.txt F: include/linux/irqdomain.h @@ -5945,11 +5941,8 @@ F: Documentation/i2c/busses/i2c-ocores F: drivers/i2c/busses/i2c-ocores.c OPEN FIRMWARE AND FLATTENED DEVICE TREE -M: Grant Likely M: Rob Herring L: devicetree-disc...@lists.ozlabs.org (moderated for non-subscribers) -W: http://fdt.secretlab.ca -T: git git://git.secretlab.ca/git/linux-2.6.git S: Maintained F: Documentation/devicetree F: drivers/of @@ -7623,7 +7616,6 @@ F:drivers/clk/spear/ SPI SUBSYSTEM M: Mark Brown -M: Grant Likely L: spi-devel-gene...@lists.sourceforge.net T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git Q: http://patchwork.kernel.org/project/spi-devel-general/list/ -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 1/2 v2] x86: introduce int3-based instruction patching
(2013/07/11 19:51), Jiri Kosina wrote:
>>> + * - update all but the first byte of the patched range
>>> + * - sync cores
>>> + * - replalace the first byte (int3) by the first byte of
>>> + * replacing opcode
>>> + * - sync cores
>>> + *
>>> + * Note: must be called under text_mutex.
>>> + */
>>> +void *text_poke_bp(void *addr, const void *opcode, size_t len, void
>>> *handler)
>>> +{
>>> + unsigned char int3 = 0xcc;
>>> +
>>
>> Here, you have to protect this code from others, since bp_* are
>> global.
>
> Caller is responsible for holding the text_mutex, so text_poke_bp() can't
> race with itself. And the proper consistency between text_poke_bp() and
> the notifier is achieved by the memory barriers.
Oops, right. I missed your "Note" line
>
> So what exact scenario do you have in mind here, please?
No, never mind...
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
When to push bug fixes to mainline
On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote: > > I'm sitting on top of over 170 more patches that have been marked for > the stable releases right now that are not included in this set of > releases. The fact that there are this many patches for stable stuff > that are waiting to be merged through the main -rc1 merge window cycle > is worrying to me. > > Why are subsystem maintainers holding on to fixes that are > _supposedly_ affecting all users? I mean, 21 powerpc core changes > that I don't see until a -rc1 merge? It's as if developers don't > expect people to use a .0 release and are relying on me to get the > fixes they have burried in their trees out to users. That's not that > nice. 6 "core" iscsi-target fixes? That's the sign of either a > broken subsystem maintainer, or a lack of understanding what the > normal -rc kernel releases are supposed to be for. At least at one point in the past, the rule that Linus had laid down after discussing things at Kernel Summits was after -rc2, or maybe -rc3 at the latest, the ***only*** fixes that should be sent to Linus would be for regression fixes or for really serious data integrity issues. The concern was that people were pushing bug fixes in -rc5 or -rc6 that were in some cases causing regressions. (As I recall, Linus laid down the law regarding this policy in his own inimitable and colorful style; which today would result in all sorts of tsk, tsking on Hacker News regarding his language. :-) In any case, I've been very conservative in _not_ pushing bug fixes to Linus after -rc3 (unless they are fixing a regression or the bug fix is super-serious); I'd much rather have them cook in the ext4 tree where they can get a lot more testing (a full regression test run for ext4 takes over 24 hours), and for people trying out linux-next. Maybe the pendulum has swung too far in the direction of holding back changes and trying to avoid the risk of introducing regressions; perhaps this would be a good topic to discuss at the Kernel Summit. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
On Friday, July 12, 2013 6:46 AM, Julius Werner wrote: > > Hi Jingoo, > > Yeah, I followed that discussion back then, but it seems to have > stalled a little (at least the HSIC patches haven't been picked up in > any kernel.org repo yet to my knowledge). > > The problem is that I think these approaches cannot work reliably. I > agree that it would be nice to control the HSIC device from its own > driver, and have spent quite some time playing around with the > usb/misc/usb3503.c driver to try to make this work... but there's a > timing dependency here that you just can't model correctly with > independent drivers. > > If the HSIC device is already active during boot (e.g. because it was > used by firmware), there's always a chance that the USB stack will > come up before the driver that resets it does. The device will be > enumerated as normal, and when the other driver later pulls the reset > signal the USB stack will not notice because there is no real > disconnect detection on HSIC. Only when you eventually try to send > another transfer to the device will you start to get timeouts, and the > newly reset device will not be able to reenumerate because the host > never asks it to. > > I really don't see how you could solve this without putting some kind > of synchronization mechanism in the USB drivers. So this leaves > ehci-s5p and phy-samsung-usb2 as the only possible places, and I chose > the latter since all the host-side HSIC initialization is also there > already. I think if you think of it as "reset whatever is on the other > side of this PHY", it's okay to put it as an optional feature into the > PHY driver. CC'ed Tomasz Figa, Dongjin Kim, Yulgon Kim Hi Tomasz, Dongjin, Julius Werner wants to put 'SMSC 3503 hub reset on Arndale board' to 'phy-samsung-usb*.c' files, because there is a timing dependency above mentioned. The following is the original patch sent by Julius Werner two day ago. (http://www.spinics.net/lists/linux-samsung-soc/msg20250.html) Previously, Olof mentioned that 'drivers/platform/arm/' would be used. (http://patches.linaro.org/16856/) Also, another way was mentioned by Fabio Estevam, using 'drivers/reset/gpio-reset.c' which is not merged yet. (http://permalink.gmane.org/gmane.linux.drivers.devicetree/36830) I think that 'phy-samsung-usb*.c' files are not a good place. However, Julius Werner's comment looks reasonable enough. If you have a comment, please feel free to share it. :) Thank you. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: rebase of the jdelvare-hwmon quilt series
On Fri, 12 Jul 2013 10:27:59 +1000 Stephen Rothwell wrote: > > As Paul said, new material should not enter linux-next until after -rc1 > is released. In fact, every time Linus opens a merge window, I send an > email to lkml and the linux-next list saying just that. I also often add > that message to the top of my daily release announcements (though I > forgot during this merge window). > > This restriction is imposed so that maintainers still getting their code > into the current merge window are not distracted by reports of problems > in linux-next to do with code that will not be merged in this merge > window. Of course, this does not apply to bug fixes etc. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp7mLFZiE4Eu.pgp Description: PGP signature
linux-next: manual merge of the arm-current tree with Linus' tree
Hi Russell,
Today's linux-next merge of the arm-current tree got a conflict in
arch/arm/mm/init.c between commit dbe67df4ba78 ("mm: enhance
free_reserved_area() to support poisoning memory with zero") from Linus'
tree and commit 319e0b4f02f7 ("ARM: mm: fix boot on SA1110 Assabet") from
the arm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mm/init.c
index 6833cbe,0ecc43f..000
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@@ -597,7 -600,7 +597,7 @@@ void __init mem_init(void
#ifdef CONFIG_SA
/* now that our DMA memory is actually so designated, we can free it */
- free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, -1, NULL);
- free_reserved_area(__va(PHYS_OFFSET), swapper_pg_dir, 0, NULL);
++ free_reserved_area(__va(PHYS_OFFSET), swapper_pg_dir, -1, NULL);
#endif
free_highpages();
pgpjnaPpPEhYB.pgp
Description: PGP signature
Re: [ 00/11] 3.4.53-stable review
On Thu, Jul 11, 2013 at 08:24:33PM -0400, Paul Gortmaker wrote: > On Thu, Jul 11, 2013 at 6:11 PM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 3.4.53 release. > > There are 11 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 should be made by Sat Jul 13 22:04:03 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.53-rc1.gz > > Just happened to notice the v3.0 in the path vs. the 3.4 version. > Wasn't sure that was intentional or not, so figured I'd mention it. It's intentional, it's always been there, but I guess I could use the 3.x link instead, they both point to the same place. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: rebase of the jdelvare-hwmon quilt series
Hi Jean, On Thu, 11 Jul 2013 19:17:52 -0400 Paul Gortmaker wrote: > > On Thu, Jul 11, 2013 at 3:39 AM, Jean Delvare wrote: > > > > FWIW I would have accepted the patch even if it was not trivial and it > > would have gone in linux-next just the same. The only difference is > > whether I consider the patch for this merge window or only for the next. > > The linux-next tree should not see "new" commits during the two week > window of the merge window -- only content for the active merge window > should be in linux-next during the merge window. Once the rc1 tag has > been completed, then you can add new content. This has been something > that Stephen broadcasts regularly for each merge window start. > > So there is nothing wrong with accepting the patch, but if it isn't destined > for this merge window, then it should not be forwarded to linux-next until > after rc1 gets tagged. > > > Is there a policy to not include new patches in linux-next during a > > merge window if the patch is for the next merge window? If so I wasn't > > aware of it. I always considered that the earlier a patch gets in > > linux-next, the better. > > Yes, see above. As Paul said, new material should not enter linux-next until after -rc1 is released. In fact, every time Linus opens a merge window, I send an email to lkml and the linux-next list saying just that. I also often add that message to the top of my daily release announcements (though I forgot during this merge window). This restriction is imposed so that maintainers still getting their code into the current merge window are not distracted by reports of problems in linux-next to do with code that will not be merged in this merge window. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpUxgY_WQ2Lf.pgp Description: PGP signature
Re: [ 00/11] 3.4.53-stable review
On Thu, Jul 11, 2013 at 6:11 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.53 release. > There are 11 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 should be made by Sat Jul 13 22:04:03 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.53-rc1.gz Just happened to notice the v3.0 in the path vs. the 3.4 version. Wasn't sure that was intentional or not, so figured I'd mention it. P. -- > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.4.53-rc1 > > Greg Kroah-Hartman > Revert "sched: Add missing call to calc_load_exit_idle()" > > Ben Hutchings > SCSI: sd: Fix parsing of 'temporary ' cache mode prefix > > J. Bruce Fields > nfsd4: fix decoding of compounds across page boundaries > > Greg Kroah-Hartman > Revert "serial: 8250_pci: add support for another kind of NetMos > Technology PCI 9835 Multi-I/O Controller" > > Greg Kroah-Hartman > MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information > > Kees Cook > crypto: sanitize argument for format string > > Kees Cook > block: do not pass disk names as format strings > > Mikulas Patocka > hpfs: better test for errors > > Kees Cook > charger-manager: Ensure event is not used as format string > > Jonathan Salwan > drivers/cdrom/cdrom.c: use kzalloc() for failing hardware > > Tyler Hicks > libceph: Fix NULL pointer dereference in auth client code > > > - > > Diffstat: > > MAINTAINERS| 1 + > Makefile | 4 ++-- > block/genhd.c | 2 +- > crypto/algapi.c| 3 ++- > drivers/block/nbd.c| 3 ++- > drivers/cdrom/cdrom.c | 2 +- > drivers/power/charger-manager.c| 2 +- > drivers/scsi/osd/osd_uld.c | 2 +- > drivers/scsi/sd.c | 2 +- > drivers/tty/serial/8250/8250_pci.c | 4 > fs/hpfs/map.c | 3 ++- > fs/hpfs/super.c| 8 +++- > fs/nfsd/nfs4xdr.c | 2 +- > kernel/time/tick-sched.c | 1 - > net/ceph/auth_none.c | 6 ++ > 15 files changed, 28 insertions(+), 17 deletions(-) > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / memhotplug: Fix a stale pointer in error path
(2013/07/11 1:47), Toshi Kani wrote:
> device->driver_data needs to be cleared when releasing its data,
> mem_device, in an error path of acpi_memory_device_add().
>
> Signed-off-by: Toshi Kani
> ---
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
> drivers/acpi/acpi_memhotplug.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index c711d11..999adb5 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -323,6 +323,7 @@ static int acpi_memory_device_add(struct acpi_device
> *device,
> /* Get the range from the _CRS */
> result = acpi_memory_get_device_resources(mem_device);
> if (result) {
> + device->driver_data = NULL;
> kfree(mem_device);
> return result;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/12] drivers/net/ethernet/cadence: don't use devm_pinctrl_get_select_default() in probe
From: Wolfram Sang Date: Wed, 10 Jul 2013 16:57:43 +0100 > Since commit ab78029 (drivers/pinctrl: grab default handles from device core), > we can rely on device core for setting the default pins. Compile tested only. > > Acked-by: Linus Walleij (personally at LCE13) > Signed-off-by: Wolfram Sang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] drivers/net/can/c_can: don't use devm_pinctrl_get_select_default() in probe
From: Wolfram Sang Date: Wed, 10 Jul 2013 16:57:42 +0100 > Since commit ab78029 (drivers/pinctrl: grab default handles from device core), > we can rely on device core for setting the default pins. Compile tested only. > > Acked-by: Linus Walleij (personally at LCE13) > Signed-off-by: Wolfram Sang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/12] drivers/net/ieee802154: don't use devm_pinctrl_get_select_default() in probe
From: Wolfram Sang Date: Wed, 10 Jul 2013 16:57:44 +0100 > Since commit ab78029 (drivers/pinctrl: grab default handles from device core), > we can rely on device core for setting the default pins. Compile tested only. > > Acked-by: Linus Walleij (personally at LCE13) > Signed-off-by: Wolfram Sang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ATTEND] scsi-mq prototype discussion
Hello, I would like to attend the 2013 Kernel Summit. At the summit, I would like to discuss scsi-mq, a high performance SCSI initiator prototype that utilizes the next-generation blk-mq effort by Jens Axboe. The long-term goal is a path to move beyond the long-standing small block random I/O limitations vs. raw make_request based drivers of the existing Linux/SCSI client stack. Along with using blk-mq's excellent native per-cpu primitive + NUMA local friendly queuing of pre-allocated struct request descriptor memory, the scsi-mq prototype currently avoids all I/O fast-path access of legacy scsi_host->host_lock, and bypasses existing scsi_request_fn() dispatch into scsi-mq enabled LLD code. It also allows scsi-core to eliminate all fast-path memory allocations using struct scsi_cmnd + $LLD_CMD pre-allocations based on a per struct blk_mq_hw_ctx -> scsi_device->sdev_mq_req context, along with per scsi_cmnd descriptor pre-allocation of SGL and sense buffer memory. So far the initial conversion of virtio-scsi + scsi-debug LLDs has been completed. Also, the intention is to keep the conversion requirements for existing LLDs to scsi-mq as simple as possible. There are still many areas that have been conveniently left out of the initial prototype, including proper fast-path get_device() + put_device() reference counting, a functioning scsi-generic IOCTL, anything close to per struct scsi_device error handling, amongst other things.. Drilling down the work items ahead of a real mainline push is high on priority list for discussion. The parties to be included in such a discussion are: - Jens Axboe (blk-mq author) - James Bottomley (scsi maintainer) - Christoph Hellwig (scsi) - Martin Petersen (scsi) - Tejun Heo (block + libata) - Hannes Reinecke (scsi error recovery) - Kent Overstreet (block, per-cpu ida) - Stephen Cameron (scsi-over-pcie driver) - Andrew Vasquez (qla2xxx LLD) - James Smart (lpfc LLD) Thank you, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] net/usb: add relative mii functions for r815x
From: Hayes Wang Date: Mon, 8 Jul 2013 10:41:21 +0800 > Base on cdc_ether, add the mii functions for RTL8152 and RTL8153. > The RTL8152 and RTL8153 support ECM mode which use the driver of > cdc_ether. Add the mii functions. Then, the basic PHY access is > possible. > > Signed-off-by: Hayes Wang This looks like a pretty straightforward addition of support for new chips, so applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 28/30] ACPI / hotplug / PCI: Sanitize acpiphp_get_(latch)|(adapter)_status()
From: Mika Westerberg
There is no need for a temporary variable and all the tricks with
ternary operators in acpiphp_get_(latch)|(adapter)_status(). Change
those functions to be a bit more straightforward.
[rjw: Changelog]
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 12 ++--
drivers/pci/hotplug/acpiphp_glue.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -1092,11 +1092,7 @@ u8 acpiphp_get_power_status(struct acpip
*/
u8 acpiphp_get_latch_status(struct acpiphp_slot *slot)
{
- unsigned int sta;
-
- sta = get_slot_status(slot);
-
- return (sta & ACPI_STA_DEVICE_UI) ? 0 : 1;
+ return !(get_slot_status(slot) & ACPI_STA_DEVICE_UI);
}
@@ -1106,9 +1102,5 @@ u8 acpiphp_get_latch_status(struct acpip
*/
u8 acpiphp_get_adapter_status(struct acpiphp_slot *slot)
{
- unsigned int sta;
-
- sta = get_slot_status(slot);
-
- return (sta == 0) ? 0 : 1;
+ return !!get_slot_status(slot);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 27/30] ACPI / hotplug / PCI: Get rid of unused constants in acpiphp.h
From: Mika Westerberg Drop some unused symbols from acpiphp.h and redefine SLOT_ENABLED (which is the only slot flag now) as 1. [rjw: Redefinition of SLOT_ENABLED, changelog] Signed-off-by: Mika Westerberg Signed-off-by: Kirill A. Shutemov Signed-off-by: Rafael J. Wysocki --- drivers/pci/hotplug/acpiphp.h | 4 drivers/pci/hotplug/acpiphp.h |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) Index: linux-pm/drivers/pci/hotplug/acpiphp.h === --- linux-pm.orig/drivers/pci/hotplug/acpiphp.h +++ linux-pm/drivers/pci/hotplug/acpiphp.h @@ -152,16 +152,12 @@ struct acpiphp_attention_info struct module *owner; }; -/* PCI bus bridge HID */ -#define ACPI_PCI_HOST_HID "PNP0A03" - /* ACPI _STA method value (ignore bit 4; battery present) */ #define ACPI_STA_ALL (0x000f) /* slot flags */ -#define SLOT_ENABLED (0x0002) -#define SLOT_MULTIFUNCTION (0x0004) +#define SLOT_ENABLED (0x0001) /* function flags */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 30/30] ACPI / hotplug / PCI: Clean up bridge_mutex usage
From: Rafael J. Wysocki
Do not acquire bridge_mutex around the addition of a slot to its
bridge's list of slots and arount the addition of a function to
its slot's list of functions, because that doesn't help anything
right now (those lists are walked without any locking anyway).
However, acquire bridge_mutex around the list walk in
acpiphp_remove_slots() and use list_for_each_entry() there,
because we terminate the walk as soon as we find the first matching
entry. This prevents that list walk from colliding with bridge
addition and removal.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -324,9 +324,7 @@ static acpi_status register_slot(acpi_ha
INIT_LIST_HEAD(>funcs);
mutex_init(>crit_sect);
- mutex_lock(_mutex);
list_add_tail(>node, >slots);
- mutex_unlock(_mutex);
/* Register slots for ejectable funtions only. */
if (acpi_pci_check_ejectable(pbus, handle) || is_dock_device(handle)) {
@@ -357,9 +355,7 @@ static acpi_status register_slot(acpi_ha
slot_found:
newfunc->slot = slot;
- mutex_lock(_mutex);
list_add_tail(>sibling, >funcs);
- mutex_unlock(_mutex);
if (pci_bus_read_dev_vendor_id(pbus, PCI_DEVFN(device, function),
, 60*1000))
@@ -997,17 +993,21 @@ void acpiphp_enumerate_slots(struct pci_
/* Destroy hotplug slots associated with the PCI bus */
void acpiphp_remove_slots(struct pci_bus *bus)
{
- struct acpiphp_bridge *bridge, *tmp;
+ struct acpiphp_bridge *bridge;
if (acpiphp_disabled)
return;
- list_for_each_entry_safe(bridge, tmp, _list, list)
+ mutex_lock(_mutex);
+ list_for_each_entry(bridge, _list, list)
if (bridge->pci_bus == bus) {
+ mutex_unlock(_mutex);
cleanup_bridge(bridge);
put_bridge(bridge);
- break;
+ return;
}
+
+ mutex_unlock(_mutex);
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 26/30] ACPI / hotplug / PCI: Check for new devices on enabled slots
From: Kirill A. Shutemov
Subject:
The current implementation of acpiphp_check_bridge() is pretty dumb:
- It enables a slot if it's not enabled and the slot status is
ACPI_STA_ALL.
- It disables a slot if it's enabled and the slot status is not
ACPI_STA_ALL.
This behavior is not sufficient to handle the Thunderbolt daisy
chaining case properly, however, because in that case the bus
behind the already enabled slot needs to be rescanned for new
devices.
For this reason, modify acpiphp_check_bridge() so that slots are
disabled and stopped if they are not in the ACPI_STA_ALL state.
For slots in the ACPI_STA_ALL state devices that don't respond
are trimmed using a new function, pci_trim_stale_devices(),
introduced specifically for this purpose. That function walks
the given bus and checks each device on it. If the device doesn't
respond, it is assumed to be gone and removed.
Once all of the stale device objects on the bus have been removed,
we start looking for new devices that might have appeared on that
bus. We do that even if the slot is already enabled (SLOT_ENABLED).
Moreover, make the bus check notification ignore SLOT_ENABLED and
go for enable_device() directly if bridge is NULL, so that devices
behind the slot are re-enumerated in that case too.
[rjw: Rebased, modified the changelog]
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Mika Westerberg
Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 49 +++--
drivers/pci/remove.c | 20 +++
include/linux/pci.h|1
3 files changed, 42 insertions(+), 28 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -705,41 +705,30 @@ static unsigned int get_slot_status(stru
* Iterate over all slots under this bridge and make sure that if a
* card is present they are enabled, and if not they are disabled.
*/
-static int acpiphp_check_bridge(struct acpiphp_bridge *bridge)
+static void acpiphp_check_bridge(struct acpiphp_bridge *bridge)
{
struct acpiphp_slot *slot;
- int retval = 0;
- int enabled, disabled;
-
- enabled = disabled = 0;
list_for_each_entry(slot, >slots, node) {
- unsigned int status = get_slot_status(slot);
- if (slot->flags & SLOT_ENABLED) {
- if (status == ACPI_STA_ALL)
- continue;
-
- retval = acpiphp_disable_and_eject_slot(slot);
- if (retval)
- goto err_exit;
+ struct pci_bus *bus = slot->bus;
+ struct pci_dev *dev, *tmp;
+
+ mutex_lock(>crit_sect);
+ /* wake up all functions */
+ if (get_slot_status(slot) == ACPI_STA_ALL) {
+ /* remove stale devices if any */
+ list_for_each_entry_safe(dev, tmp, >devices,
+bus_list)
+ if (PCI_SLOT(dev->devfn) == slot->device)
+ pci_trim_stale_devices(dev);
- disabled++;
+ /* configure all functions */
+ enable_device(slot);
} else {
- if (status != ACPI_STA_ALL)
- continue;
- retval = acpiphp_enable_slot(slot);
- if (retval) {
- err("Error occurred in enabling\n");
- goto err_exit;
- }
- enabled++;
+ disable_device(slot);
}
+ mutex_unlock(>crit_sect);
}
-
- dbg("%s: %d enabled, %d disabled\n", __func__, enabled, disabled);
-
- err_exit:
- return retval;
}
static void acpiphp_set_hpp_values(struct pci_bus *bus)
@@ -840,7 +829,11 @@ static void hotplug_event(acpi_handle ha
ACPI_UINT32_MAX, check_sub_bridges,
NULL, NULL, NULL);
} else {
- acpiphp_enable_slot(func->slot);
+ struct acpiphp_slot *slot = func->slot;
+
+ mutex_lock(>crit_sect);
+ enable_device(slot);
+ mutex_unlock(>crit_sect);
}
break;
Index: linux-pm/drivers/pci/remove.c
===
--- linux-pm.orig/drivers/pci/remove.c
+++ linux-pm/drivers/pci/remove.c
@@ -112,6 +112,26 @@ void pci_stop_and_remove_bus_device(stru
}
EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
+/**
+ *
[RFC][PATCH 29/30] ACPI / hotplug / PCI: Redefine enable_device() and disable_device()
From: Rafael J. Wysocki
Notice that functions enable_device() and disable_device() cannot
fail and their return values are ignored in the majority of places,
so redefine them as void and use the opportunity to change their
names to enable_slot() and disable_slot(), respectively, which much
better reflects what they do.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -543,13 +543,13 @@ static void check_hotplug_bridge(struct
}
/**
- * enable_device - enable, configure a slot
+ * enable_slot - enable, configure a slot
* @slot: slot to be enabled
*
* This function should be called per *physical slot*,
* not per each slot object in ACPI namespace.
*/
-static int __ref enable_device(struct acpiphp_slot *slot)
+static void __ref enable_slot(struct acpiphp_slot *slot)
{
struct pci_dev *dev;
struct pci_bus *bus = slot->bus;
@@ -567,6 +567,7 @@ static int __ref enable_device(struct ac
list_for_each_entry(dev, >devices, bus_list) {
if (PCI_SLOT(dev->devfn) != slot->device)
continue;
+
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
max = pci_scan_bridge(bus, dev, max, pass);
@@ -605,8 +606,6 @@ static int __ref enable_device(struct ac
continue;
}
}
-
- return 0;
}
/* return first device in slot, acquiring a reference on it */
@@ -628,16 +627,16 @@ static struct pci_dev *dev_in_slot(struc
}
/**
- * disable_device - disable a slot
+ * disable_slot - disable a slot
* @slot: ACPI PHP slot
*/
-static int disable_device(struct acpiphp_slot *slot)
+static void disable_slot(struct acpiphp_slot *slot)
{
struct acpiphp_func *func;
struct pci_dev *pdev;
/*
-* enable_device() enumerates all functions in this device via
+* enable_slot() enumerates all functions in this device via
* pci_scan_slot(), whether they have associated ACPI hotplug
* methods (_EJ0, etc.) or not. Therefore, we remove all functions
* here.
@@ -651,8 +650,6 @@ static int disable_device(struct acpiphp
acpiphp_bus_trim(func_to_handle(func));
slot->flags &= (~SLOT_ENABLED);
-
- return 0;
}
@@ -723,9 +720,9 @@ static void acpiphp_check_bridge(struct
pci_trim_stale_devices(dev);
/* configure all functions */
- enable_device(slot);
+ enable_slot(slot);
} else {
- disable_device(slot);
+ disable_slot(slot);
}
mutex_unlock(>crit_sect);
}
@@ -832,7 +829,7 @@ static void hotplug_event(acpi_handle ha
struct acpiphp_slot *slot = func->slot;
mutex_lock(>crit_sect);
- enable_device(slot);
+ enable_slot(slot);
mutex_unlock(>crit_sect);
}
break;
@@ -1019,16 +1016,13 @@ void acpiphp_remove_slots(struct pci_bus
*/
int acpiphp_enable_slot(struct acpiphp_slot *slot)
{
- int retval = 0;
-
mutex_lock(>crit_sect);
-
/* configure all functions */
if (!(slot->flags & SLOT_ENABLED))
- retval = enable_device(slot);
+ enable_slot(slot);
mutex_unlock(>crit_sect);
- return retval;
+ return 0;
}
/**
@@ -1045,9 +1039,7 @@ int acpiphp_disable_and_eject_slot(struc
mutex_lock(>crit_sect);
/* unconfigure all functions */
- retval = disable_device(slot);
- if (retval)
- goto err_exit;
+ disable_slot(slot);
list_for_each_entry(func, >funcs, sibling) {
/* We don't want to call _EJ0 on non-existing functions. */
@@ -1070,7 +1062,6 @@ int acpiphp_disable_and_eject_slot(struc
}
}
- err_exit:
mutex_unlock(>crit_sect);
return retval;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 22/30] ACPI / hotplug / PCI: Do not queue up event handling work items in vain
From: Rafael J. Wysocki
Modify handle_hotplug_event() to avoid queing up the execution of
handle_hotplug_event_work_fn() as a work item on kacpi_hotplug_wq
for non-hotplug events, such as ACPI_NOTIFY_DEVICE_WAKE. Move
the code printing diagnostic messages for those events into
handle_hotplug_event().
In addition to that, remove the bogus comment about how the core
should distinguish between hotplug and non-hotplug events and
queue them up on different workqueues. The core clearly cannot
know in advance what events will be interesting to the given
caller of acpi_install_notify_handler().
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 64 -
1 file changed, 29 insertions(+), 35 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -932,36 +932,11 @@ static void hotplug_event(acpi_handle ha
break;
- case ACPI_NOTIFY_DEVICE_WAKE:
- /* wake event */
- dbg("%s: Device wake notify on %s\n", __func__, objname);
- break;
-
case ACPI_NOTIFY_EJECT_REQUEST:
/* request device eject */
dbg("%s: Device eject notify on %s\n", __func__, objname);
acpiphp_disable_and_eject_slot(func->slot);
break;
-
- case ACPI_NOTIFY_FREQUENCY_MISMATCH:
- printk(KERN_ERR "Device %s cannot be configured due"
- " to a frequency mismatch\n", objname);
- break;
-
- case ACPI_NOTIFY_BUS_MODE_MISMATCH:
- printk(KERN_ERR "Device %s cannot be configured due"
- " to a bus mode mismatch\n", objname);
- break;
-
- case ACPI_NOTIFY_POWER_FAULT:
- printk(KERN_ERR "Device %s has suffered a power fault\n",
- objname);
- break;
-
- default:
- warn("notify_handler: unknown event type 0x%x for %s\n", type,
-objname);
- break;
}
if (bridge)
@@ -996,23 +971,42 @@ static void handle_hotplug_event(acpi_ha
{
struct acpiphp_context *context;
+ switch (type) {
+ case ACPI_NOTIFY_BUS_CHECK:
+ case ACPI_NOTIFY_DEVICE_CHECK:
+ case ACPI_NOTIFY_EJECT_REQUEST:
+ break;
+
+ case ACPI_NOTIFY_DEVICE_WAKE:
+ return;
+
+ case ACPI_NOTIFY_FREQUENCY_MISMATCH:
+ acpi_handle_err(handle, "Device cannot be configured due "
+ "to a frequency mismatch\n");
+ return;
+
+ case ACPI_NOTIFY_BUS_MODE_MISMATCH:
+ acpi_handle_err(handle, "Device cannot be configured due "
+ "to a bus mode mismatch\n");
+ return;
+
+ case ACPI_NOTIFY_POWER_FAULT:
+ acpi_handle_err(handle, "Device has suffered a power fault\n");
+ return;
+
+ default:
+ acpi_handle_warn(handle, "Unsupported event type 0x%x\n", type);
+ return;
+ }
+
mutex_lock(_context_lock);
context = acpiphp_get_context(handle);
if (context) {
get_bridge(context->func.parent);
acpiphp_put_context(context);
+ alloc_acpi_hp_work(handle, type, context, hotplug_event_work);
}
mutex_unlock(_context_lock);
- /*
-* Currently the code adds all hotplug events to the kacpid_wq
-* queue when it should add hotplug events to the kacpi_hotplug_wq.
-* The proper way to fix this is to reorganize the code so that
-* drivers (dock, etc.) do not call acpi_os_execute(), etc.
-* For now just re-add this work to the kacpi_hotplug_wq so we
-* don't deadlock on hotplug actions.
-*/
- if (context)
- alloc_acpi_hp_work(handle, type, context, hotplug_event_work);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 23/30] ACPI / hotplug / PCI: Do not exectute _PS0 and _PS3 directly
From: Rafael J. Wysocki
The ACPI-based PCI hotplug (acpiphp) core code need not and really
should not execute _PS0 and _PS3 directly for devices it handles.
First of all, it is not necessary to put devices into D3 after
acpi_bus_trim() has walked through them, because
acpi_device_unregister() invoked by it puts each device into D3cold
before returning. Thus after disable_device() the slot should be
powered down already.
Second, calling _PS0 directly on ACPI device objects may not be
appropriate, because it may require power resources to be set up in
a specific way in advance and that must be taken care of by the ACPI
core. Thus modify acpiphp_bus_add() to power up the device using
the appropriate interface after it has run acpi_bus_scan() on its
handle.
After that, the functions executing _PS0 and _PS3, power_on_slot()
and power_off_slot(), are not necessary any more, so drop them
and update the code calling them accordingly. Also drop the
function flags related to device power states, since they aren't
useful any more too.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |7 --
drivers/pci/hotplug/acpiphp_glue.c | 106 +++--
2 files changed, 10 insertions(+), 103 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -305,12 +305,6 @@ static acpi_status register_slot(acpi_ha
if (ACPI_SUCCESS(acpi_get_handle(handle, "_STA", )))
newfunc->flags |= FUNC_HAS_STA;
- if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS0", )))
- newfunc->flags |= FUNC_HAS_PS0;
-
- if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", )))
- newfunc->flags |= FUNC_HAS_PS3;
-
if (ACPI_SUCCESS(acpi_get_handle(handle, "_DCK", )))
newfunc->flags |= FUNC_HAS_DCK;
@@ -369,7 +363,7 @@ static acpi_status register_slot(acpi_ha
if (pci_bus_read_dev_vendor_id(pbus, PCI_DEVFN(device, function),
, 60*1000))
- slot->flags |= (SLOT_ENABLED | SLOT_POWEREDON);
+ slot->flags |= SLOT_ENABLED;
if (is_dock_device(handle)) {
/* we don't want to call this device's _EJ0
@@ -458,73 +452,6 @@ static void cleanup_bridge(struct acpiph
mutex_unlock(_mutex);
}
-static int power_on_slot(struct acpiphp_slot *slot)
-{
- acpi_status status;
- struct acpiphp_func *func;
- int retval = 0;
-
- /* if already enabled, just skip */
- if (slot->flags & SLOT_POWEREDON)
- goto err_exit;
-
- list_for_each_entry(func, >funcs, sibling) {
- if (func->flags & FUNC_HAS_PS0) {
- dbg("%s: executing _PS0\n", __func__);
- status = acpi_evaluate_object(func_to_handle(func),
- "_PS0", NULL, NULL);
- if (ACPI_FAILURE(status)) {
- warn("%s: _PS0 failed\n", __func__);
- retval = -1;
- goto err_exit;
- } else
- break;
- }
- }
-
- /* TBD: evaluate _STA to check if the slot is enabled */
-
- slot->flags |= SLOT_POWEREDON;
-
- err_exit:
- return retval;
-}
-
-
-static int power_off_slot(struct acpiphp_slot *slot)
-{
- acpi_status status;
- struct acpiphp_func *func;
-
- int retval = 0;
-
- /* if already disabled, just skip */
- if ((slot->flags & SLOT_POWEREDON) == 0)
- goto err_exit;
-
- list_for_each_entry(func, >funcs, sibling) {
- if (func->flags & FUNC_HAS_PS3) {
- status = acpi_evaluate_object(func_to_handle(func),
- "_PS3", NULL, NULL);
- if (ACPI_FAILURE(status)) {
- warn("%s: _PS3 failed\n", __func__);
- retval = -1;
- goto err_exit;
- } else
- break;
- }
- }
-
- /* TBD: evaluate _STA to check if the slot is disabled */
-
- slot->flags &= (~SLOT_POWEREDON);
-
- err_exit:
- return retval;
-}
-
-
-
/**
* acpiphp_max_busnr - return the highest reserved bus number under the given
bus.
* @bus: bus to start search with
@@ -571,8 +498,13 @@ static void acpiphp_bus_trim(acpi_handle
*/
static void acpiphp_bus_add(acpi_handle handle)
{
+ struct acpi_device *adev = NULL;
+
acpiphp_bus_trim(handle);
acpi_bus_scan(handle);
+ acpi_bus_get_device(handle, );
+ if (adev)
+ acpi_device_set_power(adev, ACPI_STATE_D0);
[RFC][PATCH 25/30] ACPI / hotplug / PCI: Allow slots without new devices to be rescanned
From: Kirill A. Shutemov
Currently, enable_device() checks the return value of pci_scan_slot()
and returns immediately if that's 0 (meaning that no new functions
have been found in the slot). However, if one of the functions in
the slot is a bridge, some new devices may appear below it even if
the bridge itself is present continuously, so it generally is
necessary to do the rescan anyway just in case. [In particular,
that's necessary with the Thunderbolt daisy chaining in which case
new devices may be connected to the existing ones down the chain.]
The correctness of this change relies on the ability of
pcibios_resource_survey_bus() to detect if it has already been called
for the given bus and to skip it if so. Failure to do that will lead
to resource allocation conflicts.
[rjw: Changelog]
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 11 ++-
drivers/pci/hotplug/acpiphp_glue.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -554,18 +554,13 @@ static int __ref enable_device(struct ac
struct pci_dev *dev;
struct pci_bus *bus = slot->bus;
struct acpiphp_func *func;
- int num, max, pass;
+ int max, pass;
LIST_HEAD(add_list);
list_for_each_entry(func, >funcs, sibling)
acpiphp_bus_add(func_to_handle(func));
- num = pci_scan_slot(bus, PCI_DEVFN(slot->device, 0));
- if (num == 0) {
- /* Maybe only part of funcs are added. */
- dbg("No new device found\n");
- goto err_exit;
- }
+ pci_scan_slot(bus, PCI_DEVFN(slot->device, 0));
max = acpiphp_max_busnr(bus);
for (pass = 0; pass < 2; pass++) {
@@ -611,8 +606,6 @@ static int __ref enable_device(struct ac
}
}
-
- err_exit:
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 18/30] ACPI / hotplug / PCI: Store parent in functions and bus in slots
From: Rafael J. Wysocki
To avoid chasing more pointers than necessary in some situations,
move the bridge pointer from struct acpiphp_slot to struct
acpiphp_func (and call it 'parent') and add a bus pointer to
struct acpiphp_slot.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |5 +++--
drivers/pci/hotplug/acpiphp_core.c |6 ++
drivers/pci/hotplug/acpiphp_glue.c | 25 +
3 files changed, 18 insertions(+), 18 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -94,7 +94,7 @@ struct acpiphp_bridge {
*/
struct acpiphp_slot {
struct list_head node;
- struct acpiphp_bridge *bridge; /* parent */
+ struct pci_bus *bus;
struct list_head funcs; /* one slot may have different
objects (i.e. for each function) */
struct slot *slot;
@@ -112,7 +112,8 @@ struct acpiphp_slot {
* typically 8 objects per slot (i.e. for each PCI function)
*/
struct acpiphp_func {
- struct acpiphp_slot *slot; /* parent */
+ struct acpiphp_bridge *parent;
+ struct acpiphp_slot *slot;
struct list_head sibling;
struct notifier_block nb;
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -165,7 +165,7 @@ static void free_bridge(struct kref *kre
/* Root bridges will not have hotplug context. */
if (context) {
/* Release the reference taken by acpiphp_enumerate_slots(). */
- put_bridge(context->func.slot->bridge);
+ put_bridge(context->func.parent);
context->bridge = NULL;
acpiphp_put_context(context);
}
@@ -188,7 +188,7 @@ static int post_dock_fixups(struct notif
void *v)
{
struct acpiphp_func *func = container_of(nb, struct acpiphp_func, nb);
- struct pci_bus *bus = func->slot->bridge->pci_bus;
+ struct pci_bus *bus = func->slot->bus;
u32 buses;
if (!bus->self)
@@ -249,14 +249,14 @@ static void acpiphp_dock_init(void *data
{
struct acpiphp_context *context = data;
- get_bridge(context->func.slot->bridge);
+ get_bridge(context->func.parent);
}
static void acpiphp_dock_release(void *data)
{
struct acpiphp_context *context = data;
- put_bridge(context->func.slot->bridge);
+ put_bridge(context->func.parent);
}
/* callback routine to register each ACPI PCI slot object */
@@ -296,6 +296,7 @@ static acpi_status register_slot(acpi_ha
}
newfunc = >func;
newfunc->function = function;
+ newfunc->parent = bridge;
mutex_unlock(_context_lock);
if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", )))
@@ -324,7 +325,7 @@ static acpi_status register_slot(acpi_ha
goto err;
}
- slot->bridge = bridge;
+ slot->bus = bridge->pci_bus;
slot->device = device;
INIT_LIST_HEAD(>funcs);
mutex_init(>crit_sect);
@@ -651,7 +652,7 @@ static void check_hotplug_bridge(struct
static int __ref enable_device(struct acpiphp_slot *slot)
{
struct pci_dev *dev;
- struct pci_bus *bus = slot->bridge->pci_bus;
+ struct pci_bus *bus = slot->bus;
struct acpiphp_func *func;
int num, max, pass;
LIST_HEAD(add_list);
@@ -721,7 +722,7 @@ static int __ref enable_device(struct ac
/* return first device in slot, acquiring a reference on it */
static struct pci_dev *dev_in_slot(struct acpiphp_slot *slot)
{
- struct pci_bus *bus = slot->bridge->pci_bus;
+ struct pci_bus *bus = slot->bus;
struct pci_dev *dev;
struct pci_dev *ret = NULL;
@@ -793,7 +794,7 @@ static unsigned int get_slot_status(stru
} else {
u32 dvid;
- pci_bus_read_config_dword(slot->bridge->pci_bus,
+ pci_bus_read_config_dword(slot->bus,
PCI_DEVFN(slot->device,
func->function),
PCI_VENDOR_ID, );
@@ -993,7 +994,7 @@ static void hotplug_event(acpi_handle ha
if (bridge)
acpiphp_check_bridge(bridge);
else
- acpiphp_check_bridge(func->slot->bridge);
+ acpiphp_check_bridge(func->parent);
break;
@@ -1048,7 +1049,7 @@ static void hotplug_event_work(struct wo
acpi_scan_lock_release();
kfree(hp_work); /* allocated in handle_hotplug_event() */
-
[RFC][PATCH 19/30] ACPI / hotplug / PCI: Rework namespace scanning and trimming routines
From: Rafael J. Wysocki
The acpiphp_bus_trim() and acpiphp_bus_add() functions need not
return error codes that are never checked, so redefine them and
simplify them a bit.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 52 +
1 file changed, 13 insertions(+), 39 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -552,53 +552,27 @@ static unsigned char acpiphp_max_busnr(s
return max;
}
-
/**
- * acpiphp_bus_add - add a new bus to acpi subsystem
- * @func: acpiphp_func of the bridge
+ * acpiphp_bus_trim - Trim device objects in an ACPI namespace subtree.
+ * @handle: ACPI device object handle to start from.
*/
-static int acpiphp_bus_add(struct acpiphp_func *func)
+static void acpiphp_bus_trim(acpi_handle handle)
{
- acpi_handle handle = func_to_handle(func);
- struct acpi_device *device;
- int ret_val;
-
- if (!acpi_bus_get_device(handle, )) {
- dbg("bus exists... trim\n");
- /* this shouldn't be in here, so remove
-* the bus then re-add it...
-*/
- acpi_bus_trim(device);
- }
-
- ret_val = acpi_bus_scan(handle);
- if (!ret_val)
- ret_val = acpi_bus_get_device(handle, );
-
- if (ret_val)
- dbg("error adding bus, %x\n", -ret_val);
+ struct acpi_device *adev = NULL;
- return ret_val;
+ acpi_bus_get_device(handle, );
+ if (adev)
+ acpi_bus_trim(adev);
}
-
/**
- * acpiphp_bus_trim - trim a bus from acpi subsystem
- * @handle: handle to acpi namespace
+ * acpiphp_bus_add - Scan ACPI namespace subtree.
+ * @handle: ACPI object handle to start the scan from.
*/
-static int acpiphp_bus_trim(acpi_handle handle)
+static void acpiphp_bus_add(acpi_handle handle)
{
- struct acpi_device *device;
- int retval;
-
- retval = acpi_bus_get_device(handle, );
- if (retval) {
- dbg("acpi_device not found\n");
- return retval;
- }
-
- acpi_bus_trim(device);
- return 0;
+ acpiphp_bus_trim(handle);
+ acpi_bus_scan(handle);
}
static void acpiphp_set_acpi_region(struct acpiphp_slot *slot)
@@ -661,7 +635,7 @@ static int __ref enable_device(struct ac
goto err_exit;
list_for_each_entry(func, >funcs, sibling)
- acpiphp_bus_add(func);
+ acpiphp_bus_add(func_to_handle(func));
num = pci_scan_slot(bus, PCI_DEVFN(slot->device, 0));
if (num == 0) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 24/30] ACPI / hotplug / PCI: Do not check SLOT_ENABLED in enable_device()
From: Kirill A. Shutemov
With Thunderbolt you can daisy chain devices: connect new devices to
an already plugged one. In that case the "hotplug slot" is already
enabled, but we still want to look for new PCI devices behind it.
Reuse enable_device() to scan for new PCI devices on enabled slots
and push the SLOT_ENABLED check up into acpiphp_enable_slot().
[rjw: Rebased, modified the changelog]
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 5 ++---
drivers/pci/hotplug/acpiphp_glue.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -557,9 +557,6 @@ static int __ref enable_device(struct ac
int num, max, pass;
LIST_HEAD(add_list);
- if (slot->flags & SLOT_ENABLED)
- goto err_exit;
-
list_for_each_entry(func, >funcs, sibling)
acpiphp_bus_add(func_to_handle(func));
@@ -1036,11 +1033,14 @@ void acpiphp_remove_slots(struct pci_bus
*/
int acpiphp_enable_slot(struct acpiphp_slot *slot)
{
- int retval;
+ int retval = 0;
mutex_lock(>crit_sect);
+
/* configure all functions */
- retval = enable_device(slot);
+ if (!(slot->flags & SLOT_ENABLED))
+ retval = enable_device(slot);
+
mutex_unlock(>crit_sect);
return retval;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 17/30] ACPI / hotplug / PCI: Drop handle field from struct acpiphp_bridge
From: Rafael J. Wysocki
The handle field in struct acpiphp_bridge is only used by
acpiphp_enumerate_slots(), but in that function the local handle
variable can be used instead, so make that happen and drop handle
from struct acpiphp_bridge.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |1 -
drivers/pci/hotplug/acpiphp_glue.c |5 ++---
2 files changed, 2 insertions(+), 4 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -76,7 +76,6 @@ struct acpiphp_bridge {
struct list_head list;
struct list_head slots;
struct kref ref;
- acpi_handle handle;
struct acpiphp_context *context;
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -1107,7 +1107,6 @@ void acpiphp_enumerate_slots(struct pci_
INIT_LIST_HEAD(>slots);
kref_init(>ref);
- bridge->handle = handle;
bridge->pci_dev = pci_dev_get(bus->self);
bridge->pci_bus = bus;
@@ -1147,10 +1146,10 @@ void acpiphp_enumerate_slots(struct pci_
mutex_unlock(_mutex);
/* register all slot objects under this bridge */
- status = acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge->handle, 1,
+ status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
register_slot, NULL, bridge, NULL);
if (ACPI_FAILURE(status)) {
- acpi_handle_err(bridge->handle, "failed to register slots\n");
+ acpi_handle_err(handle, "failed to register slots\n");
cleanup_bridge(bridge);
put_bridge(bridge);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 15/30] ACPI / hotplug / PCI: Embed function struct into struct acpiphp_context
From: Rafael J. Wysocki
Since there has to be a struct acpiphp_func object for every struct
acpiphp_context created by register_slot(), the struct acpiphp_func
one can be embedded into the struct acpiphp_context one, which allows
some code simplifications to be made.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |8 +--
drivers/pci/hotplug/acpiphp_glue.c | 42 +
2 files changed, 21 insertions(+), 29 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -113,7 +113,6 @@ struct acpiphp_slot {
* typically 8 objects per slot (i.e. for each PCI function)
*/
struct acpiphp_func {
- struct acpiphp_context *context;
struct acpiphp_slot *slot; /* parent */
struct list_head sibling;
@@ -126,11 +125,16 @@ struct acpiphp_func {
struct acpiphp_context {
acpi_handle handle;
- struct acpiphp_func *func;
+ struct acpiphp_func func;
struct acpiphp_bridge *bridge;
unsigned int refcount;
};
+static inline struct acpiphp_context *func_to_context(struct acpiphp_func
*func)
+{
+ return container_of(func, struct acpiphp_context, func);
+}
+
/*
* struct acpiphp_attention_info - device specific attention registration
*
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -128,7 +128,7 @@ static void acpiphp_put_context(struct a
if (--context->refcount)
return;
- WARN_ON(context->func || context->bridge);
+ WARN_ON(context->bridge);
acpi_detach_data(context->handle, acpiphp_context_handler);
kfree(context);
}
@@ -155,12 +155,9 @@ static void free_bridge(struct kref *kre
bridge = container_of(kref, struct acpiphp_bridge, ref);
list_for_each_entry_safe(slot, next, >slots, node) {
- list_for_each_entry_safe(func, tmp, >funcs, sibling) {
- context = func->context;
- context->func = NULL;
- acpiphp_put_context(context);
- kfree(func);
- }
+ list_for_each_entry_safe(func, tmp, >funcs, sibling)
+ acpiphp_put_context(func_to_context(func));
+
kfree(slot);
}
@@ -168,7 +165,7 @@ static void free_bridge(struct kref *kre
/* Root bridges will not have hotplug context. */
if (context) {
/* Release the reference taken by acpiphp_enumerate_slots(). */
- put_bridge(context->func->slot->bridge);
+ put_bridge(context->func.slot->bridge);
context->bridge = NULL;
acpiphp_put_context(context);
}
@@ -252,14 +249,14 @@ static void acpiphp_dock_init(void *data
{
struct acpiphp_context *context = data;
- get_bridge(context->func->slot->bridge);
+ get_bridge(context->func.slot->bridge);
}
static void acpiphp_dock_release(void *data)
{
struct acpiphp_context *context = data;
- put_bridge(context->func->slot->bridge);
+ put_bridge(context->func.slot->bridge);
}
/* callback routine to register each ACPI PCI slot object */
@@ -290,23 +287,16 @@ static acpi_status register_slot(acpi_ha
device = (adr >> 16) & 0x;
function = adr & 0x;
- newfunc = kzalloc(sizeof(struct acpiphp_func), GFP_KERNEL);
- if (!newfunc)
- return AE_NO_MEMORY;
-
- newfunc->handle = handle;
- newfunc->function = function;
-
mutex_lock(_context_lock);
context = acpiphp_init_context(handle);
if (!context) {
mutex_unlock(_context_lock);
acpi_handle_err(handle, "No hotplug context\n");
- kfree(newfunc);
return AE_NOT_EXIST;
}
- newfunc->context = context;
- context->func = newfunc;
+ newfunc = >func;
+ newfunc->handle = handle;
+ newfunc->function = function;
mutex_unlock(_context_lock);
if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", )))
@@ -415,10 +405,8 @@ static acpi_status register_slot(acpi_ha
err:
mutex_lock(_context_lock);
- context->func = NULL;
acpiphp_put_context(context);
mutex_unlock(_context_lock);
- kfree(newfunc);
return status;
}
@@ -961,7 +949,7 @@ void acpiphp_check_host_bridge(acpi_hand
static void hotplug_event(acpi_handle handle, u32 type, void *data)
{
struct acpiphp_context *context = data;
- struct acpiphp_func *func = context->func;
+ struct acpiphp_func *func = >func;
struct acpiphp_bridge
[RFC][PATCH 14/30] ACPI / hotplug / PCI: Drop flags field from struct acpiphp_bridge
From: Rafael J. Wysocki
The only bridge flag used by the ACPI-based PCI hotplug (ACPIPHP)
code is BRIDGE_HAS_EJ0, but it is only used by the event handling
function hotplug_event() and if that flag is set, the corresponding
function flag FUNC_HAS_EJ0 is set as well, so that bridge flag is
redundant.
For this reason, drop BRIDGE_HAS_EJ0 and all code referring to it
and since it is the only bridge flag defined, drop the flags field
from struct acpiphp_bridge entirely.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |5 -
drivers/pci/hotplug/acpiphp_glue.c |9 -
2 files changed, 14 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -80,8 +80,6 @@ struct acpiphp_bridge {
struct acpiphp_context *context;
- u32 flags;
-
/* This bus (host bridge) or Secondary bus (PCI-to-PCI bridge) */
struct pci_bus *pci_bus;
@@ -152,9 +150,6 @@ struct acpiphp_attention_info
/* ACPI _STA method value (ignore bit 4; battery present) */
#define ACPI_STA_ALL (0x000f)
-/* bridge flags */
-#define BRIDGE_HAS_EJ0 (0x0001)
-
/* slot flags */
#define SLOT_POWEREDON (0x0001)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -1009,9 +1009,6 @@ static void hotplug_event(acpi_handle ha
case ACPI_NOTIFY_EJECT_REQUEST:
/* request device eject */
dbg("%s: Device eject notify on %s\n", __func__, objname);
- if (bridge && !(bridge->flags & BRIDGE_HAS_EJ0))
- break;
-
if (!(acpiphp_disable_slot(func->slot)))
acpiphp_eject_slot(func->slot);
@@ -1148,12 +1145,6 @@ void acpiphp_enumerate_slots(struct pci_
mutex_unlock(_context_lock);
}
- status = acpi_get_handle(bridge->handle, "_EJ0", );
- if (ACPI_SUCCESS(status)) {
- dbg("found ejectable p2p bridge\n");
- bridge->flags |= BRIDGE_HAS_EJ0;
- }
-
/* must be added to the list prior to calling register_slot */
mutex_lock(_mutex);
list_add(>list, _list);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 16/30] ACPI / hotplug / PCI: Drop handle field from struct acpiphp_func
From: Rafael J. Wysocki
The ACPI handle stored in struct acpiphp_func is also stored in the
struct acpiphp_context object containing it and it is trivial to get
from a struct acpiphp_func pointer to the handle field of the outer
struct acpiphp_context.
Hence, the handle field of struct acpiphp_func is redundant, so drop
it and provide a helper function, func_to_handle(), allowing it
users to get the ACPI handle for the given struct acpiphp_func
pointer.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |6 -
drivers/pci/hotplug/acpiphp_glue.c | 42 ++---
2 files changed, 30 insertions(+), 18 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -117,7 +117,6 @@ struct acpiphp_func {
struct list_head sibling;
struct notifier_block nb;
- acpi_handle handle;
u8 function; /* pci function# */
u32 flags; /* see below */
@@ -135,6 +134,11 @@ static inline struct acpiphp_context *fu
return container_of(func, struct acpiphp_context, func);
}
+static inline acpi_handle func_to_handle(struct acpiphp_func *func)
+{
+ return func_to_context(func)->handle;
+}
+
/*
* struct acpiphp_attention_info - device specific attention registration
*
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -295,7 +295,6 @@ static acpi_status register_slot(acpi_ha
return AE_NOT_EXIST;
}
newfunc = >func;
- newfunc->handle = handle;
newfunc->function = function;
mutex_unlock(_context_lock);
@@ -436,12 +435,14 @@ static void cleanup_bridge(struct acpiph
list_for_each_entry(slot, >slots, node) {
list_for_each_entry(func, >funcs, sibling) {
- if (is_dock_device(func->handle)) {
- unregister_hotplug_dock_device(func->handle);
+ acpi_handle handle = func_to_handle(func);
+
+ if (is_dock_device(handle)) {
+ unregister_hotplug_dock_device(handle);
unregister_dock_notifier(>nb);
}
if (!(func->flags & FUNC_HAS_DCK)) {
- status =
acpi_remove_notify_handler(func->handle,
+ status = acpi_remove_notify_handler(handle,
ACPI_SYSTEM_NOTIFY,
handle_hotplug_event);
if (ACPI_FAILURE(status))
@@ -469,7 +470,8 @@ static int power_on_slot(struct acpiphp_
list_for_each_entry(func, >funcs, sibling) {
if (func->flags & FUNC_HAS_PS0) {
dbg("%s: executing _PS0\n", __func__);
- status = acpi_evaluate_object(func->handle, "_PS0",
NULL, NULL);
+ status = acpi_evaluate_object(func_to_handle(func),
+ "_PS0", NULL, NULL);
if (ACPI_FAILURE(status)) {
warn("%s: _PS0 failed\n", __func__);
retval = -1;
@@ -501,7 +503,8 @@ static int power_off_slot(struct acpiphp
list_for_each_entry(func, >funcs, sibling) {
if (func->flags & FUNC_HAS_PS3) {
- status = acpi_evaluate_object(func->handle, "_PS3",
NULL, NULL);
+ status = acpi_evaluate_object(func_to_handle(func),
+ "_PS3", NULL, NULL);
if (ACPI_FAILURE(status)) {
warn("%s: _PS3 failed\n", __func__);
retval = -1;
@@ -555,10 +558,11 @@ static unsigned char acpiphp_max_busnr(s
*/
static int acpiphp_bus_add(struct acpiphp_func *func)
{
+ acpi_handle handle = func_to_handle(func);
struct acpi_device *device;
int ret_val;
- if (!acpi_bus_get_device(func->handle, )) {
+ if (!acpi_bus_get_device(handle, )) {
dbg("bus exists... trim\n");
/* this shouldn't be in here, so remove
* the bus then re-add it...
@@ -566,9 +570,9 @@ static int acpiphp_bus_add(struct acpiph
acpi_bus_trim(device);
}
- ret_val = acpi_bus_scan(func->handle);
+ ret_val = acpi_bus_scan(handle);
if (!ret_val)
- ret_val = acpi_bus_get_device(func->handle, );
+ ret_val =
[RFC][PATCH 9/30] ACPI / hotplug / PCI: Drop func field from struct acpiphp_bridge
From: Rafael J. Wysocki
Since the func pointer in struct acpiphp_context can always be used
instead of the func pointer in struct acpiphp_bridge, drop the
latter.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |2 --
drivers/pci/hotplug/acpiphp_glue.c |3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -79,8 +79,6 @@ struct acpiphp_bridge {
acpi_handle handle;
struct acpiphp_context *context;
- /* Ejectable PCI-to-PCI bridge (PCI bridge and PCI function) */
- struct acpiphp_func *func;
int nr_slots;
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -181,7 +181,7 @@ static void free_bridge(struct kref *kre
context = bridge->context;
/* Release the reference acquired by acpiphp_enumerate_slots(). */
if (context->handler_for_func)
- put_bridge(bridge->func->slot->bridge);
+ put_bridge(context->func->slot->bridge);
put_device(>pci_bus->dev);
pci_dev_put(bridge->pci_dev);
@@ -1235,7 +1235,6 @@ void acpiphp_enumerate_slots(struct pci_
}
if (context->handler_for_func) {
/* Notify handler already installed. */
- bridge->func = context->func;
get_bridge(context->func->slot->bridge);
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 13/30] ACPI / hotplug / PCI: Use common slot count variable in register_slot()
From: Rafael J. Wysocki
It is not necessary to use per-bridge slot count fields just in
order to label slots for devices without _SUN, so use a common
static slot_count variable for this purpose and drop the nr_slots
field from struct acpiphp_bridge.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |2 --
drivers/pci/hotplug/acpiphp_glue.c |7 ---
2 files changed, 4 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -80,8 +80,6 @@ struct acpiphp_bridge {
struct acpiphp_context *context;
- int nr_slots;
-
u32 flags;
/* This bus (host bridge) or Secondary bus (PCI-to-PCI bridge) */
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -346,20 +346,21 @@ static acpi_status register_slot(acpi_ha
/* Register slots for ejectable funtions only. */
if (acpi_pci_check_ejectable(pbus, handle) || is_dock_device(handle)) {
+ static unsigned int slot_count;
unsigned long long sun;
int retval;
- bridge->nr_slots++;
+ slot_count++;
status = acpi_evaluate_integer(handle, "_SUN", NULL, );
if (ACPI_FAILURE(status))
- sun = bridge->nr_slots;
+ sun = slot_count;
dbg("found ACPI PCI Hotplug slot %llu at PCI %04x:%02x:%02x\n",
sun, pci_domain_nr(pbus), pbus->number, device);
retval = acpiphp_register_hotplug_slot(slot, sun);
if (retval) {
- bridge->nr_slots--;
+ slot_count--;
if (retval == -EBUSY)
warn("Slot %llu already registered by another "
"hotplug driver\n", sun);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
