[tip:x86/urgent] x86, suspend: Correct the restore of CR4, EFER; skip computing EFLAGS.ID
Commit-ID: 1396adc3c2bdc556d4cdd1cf107aa0b6d59fbb1e Gitweb: http://git.kernel.org/tip/1396adc3c2bdc556d4cdd1cf107aa0b6d59fbb1e Author: H. Peter Anvin AuthorDate: Mon, 1 Oct 2012 14:34:42 -0700 Committer: Ingo Molnar CommitDate: Tue, 2 Oct 2012 08:42:31 +0200 x86, suspend: Correct the restore of CR4, EFER; skip computing EFLAGS.ID The patch: 73201dbe x86, suspend: On wakeup always initialize cr4 and EFER ... was incorrectly committed in an intermediate (unfinished) form. - We need to test CF, not ZF, for a bit test with btl. - We don't actually need to compute the existence of EFLAGS.ID, since we set a flag at suspend time if CR4 should be restored. Signed-off-by: H. Peter Anvin Cc: Rafael J. Wysocki Link: http://lkml.kernel.org/r/1348529239-17943-1-git-send-email-...@linux.intel.com Signed-off-by: Ingo Molnar --- arch/x86/realmode/rm/wakeup_asm.S | 15 +++ 1 files changed, 3 insertions(+), 12 deletions(-) diff --git a/arch/x86/realmode/rm/wakeup_asm.S b/arch/x86/realmode/rm/wakeup_asm.S index e56479e..9e7e147 100644 --- a/arch/x86/realmode/rm/wakeup_asm.S +++ b/arch/x86/realmode/rm/wakeup_asm.S @@ -74,18 +74,9 @@ ENTRY(wakeup_start) lidtl wakeup_idt - /* Clear the EFLAGS but remember if we have EFLAGS.ID */ - movl $X86_EFLAGS_ID, %ecx - pushl %ecx - popfl - pushfl - popl %edi + /* Clear the EFLAGS */ pushl $0 popfl - pushfl - popl %edx - xorl %edx, %edi - andl %ecx, %edi /* %edi is zero iff CPUID & %cr4 are missing */ /* Check header signature... */ movlsignature, %eax @@ -120,12 +111,12 @@ ENTRY(wakeup_start) movl%eax, %cr3 btl $WAKEUP_BEHAVIOR_RESTORE_CR4, %edi - jz 1f + jnc 1f movlpmode_cr4, %eax movl%eax, %cr4 1: btl $WAKEUP_BEHAVIOR_RESTORE_EFER, %edi - jz 1f + jnc 1f movlpmode_efer, %eax movlpmode_efer + 4, %edx movl$MSR_EFER, %ecx -- 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/
Netperf UDP_STREAM regression due to not sending IPIs in ttwu_queue()
I'm going through old test results to see could I find any leftover performance regressions that have not yet been fixed (most have at this point or at least changed in such a way to make a plain revert impossible). One major regression still left is with netperf UDP_STREAM regression. Bisection points the finger straight at 518cd623 (sched: Only queue remote wakeups when crossing cache boundaries). Problem was introduced between 3.2 and 3.3, current kernel still sucks as the following results show. NETPERF UDP 3.3.0 3.3.0 3.6.0 vanilla revert-518cd623 vanilla Tput 64 328.38 ( 0.00%) 436.58 ( 32.95%) 312.51 ( -4.83%) Tput 128661.43 ( 0.00%) 869.88 ( 31.52%) 625.70 ( -5.40%) Tput 256 1310.27 ( 0.00%) 1724.45 ( 31.61%) 1243.65 ( -5.08%) Tput 1024 5466.85 ( 0.00%) 6601.43 ( 20.75%) 4838.86 (-11.49%) Tput 2048 10885.95 ( 0.00%)12694.06 ( 16.61%) 9161.75 (-15.84%) Tput 3312 15930.33 ( 0.00%)19327.67 ( 21.33%)14106.26 (-11.45%) Tput 4096 18025.47 ( 0.00%)22183.12 ( 23.07%)16636.01 ( -7.71%) Tput 8192 30076.42 ( 0.00%)37280.86 ( 23.95%)28575.84 ( -4.99%) Tput 1638447742.12 ( 0.00%)56123.21 ( 17.55%)46060.57 ( -3.52%) Machine is a single-socket I7-2600. Netperf was running in loopback testing UDP_STREAM instead of TCP_STREAM which the commit was intended to fix. The netperf server and client were bound to CPUs 0 and 1 respectively. Scheduling domains for those two CPUs look like [0.788535] CPU0 attaching sched-domain: [0.788537] domain 0: span 0,4 level SIBLING [0.788538] groups: 0 (cpu_power = 589) 4 (cpu_power = 589) [0.788541] domain 1: span 0-7 level MC [0.788543]groups: 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) [0.788548] CPU1 attaching sched-domain: [0.788549] domain 0: span 1,5 level SIBLING [0.788550] groups: 1 (cpu_power = 589) 5 (cpu_power = 589) [0.788552] domain 1: span 0-7 level MC [0.788553]groups: 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) 0,4 (cpu_power = 1178) CPUs 0,1 are not SMT siblings but are in the same MC domain so would share a common higher scheduling domain when searching for SD_SHARE_PKG_RESOURCES. I get the logic of the patch that only sends an IPI if waking up cross-domain but it's not a universal win either apparently. Unfortunately as I'm a bit weak on the scheduler, it's not obvious to me what the correct path forward is. FWIW, the following shows the results of allowing IPIs to be sent. NETPERF UDP 3.3.0 3.3.0 3.6.0 3.6.0 vanilla sendipi-v1r1 vanilla sendipi-v1r1 Tput 64 328.38 ( 0.00%) 423.46 ( 28.95%) 312.51 ( -4.83%) 391.83 ( 19.32%) Tput 128661.43 ( 0.00%) 845.78 ( 27.87%) 625.70 ( -5.40%) 783.14 ( 18.40%) Tput 256 1310.27 ( 0.00%) 1681.17 ( 28.31%) 1243.65 ( -5.08%) 1548.88 ( 18.21%) Tput 1024 5466.85 ( 0.00%) 6553.80 ( 19.88%) 4838.86 (-11.49%) 5902.06 ( 7.96%) Tput 2048 10885.95 ( 0.00%)12760.77 ( 17.22%) 9161.75 (-15.84%) 11245.34 ( 3.30%) Tput 3312 15930.33 ( 0.00%)19480.40 ( 22.28%)14106.26 (-11.45%) 17186.32 ( 7.88%) Tput 4096 18025.47 ( 0.00%)22659.79 ( 25.71%)16636.01 ( -7.71%) 20111.05 ( 11.57%) Tput 8192 30076.42 ( 0.00%)36865.53 ( 22.57%)28575.84 ( -4.99%) 33801.49 ( 12.39%) Tput 1638447742.12 ( 0.00%)55127.99 ( 15.47%)46060.57 ( -3.52%) 52262.36 ( 9.47%) MMTests Statistics: duration 3.3.0 3.3.0 3.6.0 3.6.0 vanillasendipi-v1r1 vanillasendipi-v1r1 User 54.60 33.87 41.32 39.81 System 2441.70 1245.99 1419.30 1380.85 Elapsed 3010.63 1546.65 1764.70 1716.92 A plain revert on 3.3 was a massive win but sending the IPI at least gets most of the performance back. It's not so great on 3.6 but too much has changed to make a plain revert feasible. It's also worth noting that in 3.3 at least, sending the IPI made netperf performance less variable. I am inferring this from the fact that it completed in about half the time and required fewer iterations to be confident of the result. This is obviously a stupid hack but illustrates the point. Not-signed-off-as-this-obviously-breaking-intent-of-original-patch --- kernel/sched/core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 649c9f8..79d483c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1548,7 +1548,7 @@ static void ttwu_queue(struct task_struct
Re: How do I get mac80211 debugfs?
Hi, Could it be that debugfs is not mounted on your filesystem ? In case mount | grep debugfs returns nothing, you can run: mount -t debugfs none_debugs /sys/kernel/debug and try again. Also make sure that CONFIG_MAC80211_DEBUGFS is set location is: -> Networking support (NET [=y])│ -> Wireless (WIRELESS [=y]) Regards, Rami Rosen On Tue, Oct 2, 2012 at 1:06 AM, Kevin Cruz wrote: > Hey Johannes, > None of this should be too much of an effort for me. Thankfully I > don't find terminals to be daunting. > >> Yeah ... we saw this in the lab at some point, but somehow we couldn't >> reproduce it again later. The issue is that we stop the queues, and >> never restart them, and if it's the same issue then it's definitely the >> driver's fault. > >> To confirm, when you get this, can you please do > >> sudo cat /sys/kernel/debug/ieee80211/phy*/queues > >> (assuming you have mac80211 debugfs compiled) > > So I tried that but all I got back was: > > cat: /sys/kernel/debug/ieee80211/phy*/queues: No such file or directory > > so I'm assuming it's because I must not have mac80211 debugfs. So how > do I get it? > > Thanks, Kevin > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 10/01/2012 11:47 AM, Maarten Lankhorst wrote: Op 28-09-12 21:42, Thomas Hellstrom schreef: On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten From another email As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, [1] While this would not cause any deadlocks, Any decent lockdep code would establish lru->reserve as the locking order once a lru- reserve trylock succeeds, but the locking order is really reserve->lru for obvious reasons, which means we will get a lot of lockdep errors? Yes, there are a two reversals like these already in the TTM code, and I'm not very proud of them. I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. I've never looked into how lockdep works. Is this something that can be done permanently or just for testing purposes? Although not related to this, is it possible to do something similar to the trylock reversal in the fault() code where mmap_sem() and reserve() change order using a reserve trylock? And this is even before it starts to get interesting, like how you guarantee that when you release a buffer from the delayed delete list, you're the only process having a reference? l thought list_kref made sure of that? Even if not the only one with a reference, the list_empty check would make sure it would only run on
Re: How do I get mac80211 debugfs?
Hi Kevin, > So I tried that but all I got back was: > > cat: /sys/kernel/debug/ieee80211/phy*/queues: No such file or directory > > so I'm assuming it's because I must not have mac80211 debugfs. So how > do I get it? First, make sure it's mounted, check "mount" and if not mount it: sudo mount -t debugfs debugfs /sys/kernel/debug If that doesn't work you don't have it enabled in the kernel config, check for CONFIG_DEBUG_FS. If you do have it, but not mac80211's files, check for CONFIG_MAC80211_DEBUGFS. Thanks, johannes -- 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/
[git pull] Input updates for 3.7-rc0
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. A few drivers were updated with device tree bindings and others got a few small cleanups and fixes. You will get a conflict in omap-keymap driver (a small formatting cleanup clashed with work coming from another tree), please let me know if you want me to resolve it. Thanks! Changelog: - Alexandre Pereira da Silva (3): Input: gpio_keys - clean up device tree parser Input: gpio_keys_polled - convert to dt Input: gpio_keys_polled - fix dt pdata->nbuttons Andy Shevchenko (1): Input: hgpk - use %*ph to dump small buffer Baodong Chen (1): Input: random formatting fixes Daniel Mack (3): Input: rotary-encoder - defer calls gpio_to_irq() Input: rotary-encoder - use gpio_request_one() Input: rotary-encoder - add DT bindings David Herrmann (1): Input: uinput - return -EINVAL when read buffer size is too small Dmitry Torokhov (8): Input: gpio-keys-polled - constify pointers to platform data Input: rotary-encoder - constify platform data pointers Input: get rid of MATCH_BIT() macro Input: uinput - take event lock when fetching events from buffer Input: uinput - fix race that can block nonblocking read Input: uinput - mark failed submission requests as free Input: uinput - specify exact bit sizes on userspace APIs Input: uinput - fix formatting Jason Gerecke (2): Input: wacom - add support for EMR on Cintiq 24HD touch Input: wacom - mark Intuos5 pad as in-prox when touching buttons Josh (1): Input: omap-keypad - fixed formatting Michael Schutte (1): Input: Add KD[GS]KBDIACRUC ioctls to the compatible list NeilBrown (2): Input: gpio_keys - report a wakeup_event for a button press Input: twl4030-pwrbutton - report a wakeup_event on button press Sachin Kamat (1): Input: s3c2410_ts - make s3c_ts_pmops const Seth Forshee (1): Input: synaptics - adjust threshold for treating position values as negative Stephen Warren (1): Input: tegra - move platform data header Tobias Klauser (2): Input: samsung-keypad - use of_match_ptr() Input: samsung-keypad - use of_get_child_count() helper Diffstat: .../devicetree/bindings/input/gpio-keys-polled.txt | 38 .../devicetree/bindings/input/rotary-encoder.txt | 36 drivers/input/apm-power.c | 2 +- drivers/input/ff-core.c| 4 +- drivers/input/ff-memless.c | 14 +- drivers/input/input.c | 43 +++-- drivers/input/joydev.c | 2 +- drivers/input/keyboard/gpio_keys.c | 169 +- drivers/input/keyboard/gpio_keys_polled.c | 147 +-- drivers/input/keyboard/omap-keypad.c | 8 +- drivers/input/keyboard/samsung-keypad.c| 10 +- drivers/input/keyboard/tegra-kbc.c | 2 +- drivers/input/misc/rotary_encoder.c| 140 ++- drivers/input/misc/twl4030-pwrbutton.c | 1 + drivers/input/misc/uinput.c| 197 + drivers/input/mouse/hgpk.c | 9 +- drivers/input/mouse/synaptics.c| 31 +++- drivers/input/mousedev.c | 9 +- drivers/input/sparse-keymap.c | 4 +- drivers/input/tablet/wacom_wac.c | 2 +- drivers/input/touchscreen/s3c2410_ts.c | 2 +- fs/compat_ioctl.c | 2 + .../mach/kbc.h => include/linux/input/tegra_kbc.h | 0 include/linux/uinput.h | 27 +-- 24 files changed, 611 insertions(+), 288 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/gpio-keys-polled.txt create mode 100644 Documentation/devicetree/bindings/input/rotary-encoder.txt rename arch/arm/mach-tegra/include/mach/kbc.h => include/linux/input/tegra_kbc.h (100%) -- Dmitry pgpC1nCoYaWpk.pgp Description: PGP signature
Re: [GIT PULL] Asymmetric keys and module signing
Josh Boyer writes: > On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote: >> Rusty Russell wrote: >> >> > [2.808075] Loading module verification certificates >> > [2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has >> > expired >> > [2.810500] MODSIGN: Problem loading in-kernel X.509 certificate (-127) >> >> Hmmm... Other people have seen that. >> >> Ah! >> >> I wonder if the problem is that the certificate is valid for 100 years >> That might well cause an overflow on a 32-bit system. > > That does seem quite plausible. The comparisons are done with time_t, > which boils down to 'long' and 100 years in seconds would overflow > LONG_MAX. > >> Could you try changing the '36500' in kernel/Makefile to something shorter, >> like 365? > > I tried two values today. One close to LONG_MAX (24800 or ~68 years), > and 10 years (3650). The former still seemed to overflow, but > specifying a 10yr lifetime appears to have worked. That's because the timestamp is absolute, right? Indeed, that seems to be the limit here. Here's my solution (tested, and it breaks if you change 214730 to 214760 as expected): >From 2a4b91c2c29739191c6f7db9abee9296ae505c39 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Tue, 2 Oct 2012 12:55:06 +0930 Subject: [PATCH] MODSIGN: fix expiry of auto-generated certificates on 32-bit systems 100-year certificates make time_t wrap, resulting in: [2.835272] X.509: Cert a94f6776f3f5483b0764011d1fcc6c0298362e63 has expired [2.836346] MODSIGN: Problem loading in-kernel X.509 certificate (-127) Signed-off-by: Rusty Russell diff --git a/kernel/Makefile b/kernel/Makefile index e951adf..86336c9 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -168,6 +168,13 @@ endif ifeq ($(sign_key_with_hash),) $(error Could not determine digest type to use from kernel config) endif +ifeq ($(CONFIG_64BIT),y) +# 100 years is beyond my best-before date, anyway. +end_of_time_days=36500 +else +# Until 32-bit time_t wraps, with some slack. +end_of_time_days=$(shell expr \( 214730 - `date -u +%s` \) / 86400 ) +endif signing_key.priv signing_key.x509: x509.genkey @echo "###" @@ -180,7 +187,8 @@ signing_key.priv signing_key.x509: x509.genkey @echo "###" @echo "### rngd -r /dev/hwrandom" @echo "###" - openssl req -new -nodes -utf8 $(sign_key_with_hash) -days 36500 -batch \ + openssl req -new -nodes -utf8 $(sign_key_with_hash) \ + -days $(end_of_time_days) -batch \ -x509 -config x509.genkey \ -outform DER -out signing_key.x509 \ -keyout signing_key.priv -- 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 changes for module and virtio trees.
Hi Stephen, Please remove my quilt tree http://ozlabs.org/~rusty/kernel/rr-latest/ from linux-next, and use my git trees from now on: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git Branches: modules-next virtio-next For others: beware that these will rebase, usually once after the merge window closes (so I can work on a more modern tree), and again just before it opens (where I squash in fixup patches). Cheers, Rusty. -- 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: [GIT PULL] Asymmetric keys and module signing
David Howells writes: > Rusty Russell wrote: > >> I noticed the Cert number didn't change with rebuilds: "distclean" >> didn't remove some files: >> >> $ git clean -f -f -x -d >> Removing extra_certificates >> Removing signing_key.priv >> Removing signing_key.x509 >> Removing signing_key.x509.keyid >> Removing signing_key.x509.signer >> Removing x509.genkey > > I'm not sure whether distclean should remove those, since they can be > externally supplied, or whether x509.genkey should have a Makefile dependency > on kernel/Makefile. > > I lean towards 'yes' when I'm altering kernel/Makefile trying to get things > right, and 'no' when I'm doing a make distclean to change my config or > changing kernel/Makefile for some unrelated reason. Right. I think we need to use different names for generated vs supplied files, then, because 'distclean' really must delete generated files. But it turns out you do try to clean these files, it just doesn't work. See below. I've applied this, as well, to my tree: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git modules-next BTW, you missed a Signed-off-by: on your "MODSIGN: Use the same digest for the autogen key sig as for the module sig" patch. Please update. Cheers, Rusty. >From 8921e2ede91f93dcdbd08fa6613f8458de5f8afe Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Tue, 2 Oct 2012 14:35:24 +0930 Subject: [PATCH] MODSIGN: Make mrproper should remove generated files. It doesn't, because the clean targets don't include kernel/Makefile, and because two files were missing from the list. Signed-off-by: Rusty Russell diff --git a/Makefile b/Makefile index 1c88ec3..e70ebfe 100644 --- a/Makefile +++ b/Makefile @@ -995,7 +995,10 @@ MRPROPER_DIRS += include/config usr/include include/generated \ arch/*/include/generated MRPROPER_FILES += .config .config.old .version .old_version \ include/linux/version.h \ - Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS + Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \ + signing_key.priv signing_key.x509 x509.genkey \ + extra_certificates signing_key.x509.keyid \ + signing_key.x509.signer # clean - Delete most, but leave enough to build external modules # diff --git a/kernel/Makefile b/kernel/Makefile index 86336c9..bb94783 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -216,4 +216,3 @@ x509.genkey: @echo >>x509.genkey "subjectKeyIdentifier=hash" @echo >>x509.genkey "authorityKeyIdentifier=keyid" endif -CLEAN_FILES += signing_key.priv signing_key.x509 x509.genkey extra_certificates -- 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] modsign: don't use bashism in sh scripts.
David Howells writes: > Rusty Russell wrote: > >> -source ./.config >> +. ./.config > > Does that make a difference? It does on Ubuntu, where /bin/sh => dash. "source" is a bashism. Cheers, Rusty. -- 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] block: makes bio_split support bio without data
On Fri, 28 Sep 2012 09:23:43 -0700 Kent Overstreet
wrote:
> On Mon, Sep 24, 2012 at 02:56:39PM +1000, NeilBrown wrote:
> >
> > Hi Jens,
> > this patch has been sitting in my -next tree for a little while and I was
> > hoping for it to go in for the next merge window.
> > It simply allows bio_split() to be used on bios without a payload, such as
> > 'discard'.
>
> Thing is, at some point in the stack a discard bio is going to have data
> - see blk_add_rquest_payload(), and it used to be the single page was
> added to discard bios above generic_make_request(), in
> blkdev_issue_discard() or whatever it's called.
>
> So while I'm sure your code works, it's just a fragile way of doing it.
>
> There's also other types of bios where bi_size has nothing to do with
> the amount of data in the bi_io_vec - actually I think this is a new
> thing, since Martin Petersen just added REQ_WRITE_SAME and I don't think
> there were any other instances besides REQ_DISCARD before.
>
> So my preference would be defining a mask (REQ_DISCARD|REQ_WRITE_SAME),
> and if bio->bi_rw & that mask is true, just duplicate the bvec or
> whatever.
Hi Kent,
I'm afraid I don't see the relevance of your comments to the patch.
The current bio_split code can successfully split a bio with zero or one
bi_vec entry. If there are more than that, we cannot split.
How does it matter whether the bio is a DISCARD or a WRITE_SAME or a DATA or
whatever?
NeilBrown
>
> That way it's much more explicit and less likely to trip someone else
> up later.
>
> (I've actually got a patch in my tree that does just that, but it's
> special cased in bio_advance() which makes things work out really
> nicely).
>
> > Are you happy with it going in though my 'md' tree, or would you rather
> > take
> > it though your 'block' tree?
> >
> > Thanks,
> > NeilBrown
> >
> >
> > From: Shaohua Li
> > Date: Thu, 20 Sep 2012 09:36:03 +1000
> > Subject: [PATCH] block: makes bio_split support bio without data
> >
> > discard bio hasn't data attached. We hit a BUG_ON with such bio. This makes
> > bio_split works for such bio.
> >
> > Signed-off-by: Shaohua Li
> > Signed-off-by: NeilBrown
> >
> > diff --git a/fs/bio.c b/fs/bio.c
> > index 71072ab..dbb7a6c 100644
> > --- a/fs/bio.c
> > +++ b/fs/bio.c
> > @@ -1501,7 +1501,7 @@ struct bio_pair *bio_split(struct bio *bi, int
> > first_sectors)
> > trace_block_split(bdev_get_queue(bi->bi_bdev), bi,
> > bi->bi_sector + first_sectors);
> >
> > - BUG_ON(bi->bi_vcnt != 1);
> > + BUG_ON(bi->bi_vcnt != 1 && bi->bi_vcnt != 0);
> > BUG_ON(bi->bi_idx != 0);
> > atomic_set(&bp->cnt, 3);
> > bp->error = 0;
> > @@ -1511,17 +1511,19 @@ struct bio_pair *bio_split(struct bio *bi, int
> > first_sectors)
> > bp->bio2.bi_size -= first_sectors << 9;
> > bp->bio1.bi_size = first_sectors << 9;
> >
> > - bp->bv1 = bi->bi_io_vec[0];
> > - bp->bv2 = bi->bi_io_vec[0];
> > - bp->bv2.bv_offset += first_sectors << 9;
> > - bp->bv2.bv_len -= first_sectors << 9;
> > - bp->bv1.bv_len = first_sectors << 9;
> > + if (bi->bi_vcnt != 0) {
> > + bp->bv1 = bi->bi_io_vec[0];
> > + bp->bv2 = bi->bi_io_vec[0];
> > + bp->bv2.bv_offset += first_sectors << 9;
> > + bp->bv2.bv_len -= first_sectors << 9;
> > + bp->bv1.bv_len = first_sectors << 9;
> >
> > - bp->bio1.bi_io_vec = &bp->bv1;
> > - bp->bio2.bi_io_vec = &bp->bv2;
> > + bp->bio1.bi_io_vec = &bp->bv1;
> > + bp->bio2.bi_io_vec = &bp->bv2;
> >
> > - bp->bio1.bi_max_vecs = 1;
> > - bp->bio2.bi_max_vecs = 1;
> > + bp->bio1.bi_max_vecs = 1;
> > + bp->bio2.bi_max_vecs = 1;
> > + }
> >
> > bp->bio1.bi_end_io = bio_pair_end_1;
> > bp->bio2.bi_end_io = bio_pair_end_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/
signature.asc
Description: PGP signature
Re: [PATCHv3 2/4] Input: keypad: Add smsc ece1099 keypad driver
Hi Sourav,
On Mon, Oct 01, 2012 at 04:31:50PM +0530, Sourav Poddar wrote:
> From: G, Manjunath Kondaiah
>
> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
> supports a keypad scan matrix of 23*8.This driver uses this
> device as a keypad driver.
>
> Tested on omap5430 evm with 3.6-rc6 custom kernel.
>
> Cc: Dmitry Torokhov
> Cc: Benoit Cousson
> Cc: Felipe Balbi
> Cc: Santosh Shilimkar
> Signed-off-by: G, Manjunath Kondaiah
> Signed-off-by: Sourav Poddar
> Acked-by: Felipe Balbi
> ---
> Changes since v2:
> - Replace magic numbers through driver variable.
> - Provide comments for some initialisation done in probe.
> drivers/input/keyboard/Kconfig | 11 +
> drivers/input/keyboard/Makefile |1 +
> drivers/input/keyboard/smsc-ece1099-keypad.c | 304
> ++
> 3 files changed, 316 insertions(+), 0 deletions(-)
> create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index c50fa75..b03a39c 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -593,6 +593,17 @@ config KEYBOARD_TWL4030
> To compile this driver as a module, choose M here: the
> module will be called twl4030_keypad.
>
> +config KEYBOARD_SMSC
> + tristate "SMSC ECE1099 keypad support"
Should also select INPUT_MATRIXKMAP.
> + depends on I2C
> + help
> + Say Y here if your board use the smsc keypad controller
> + for omap5 defconfig. It's safe to say enable this
> + even on boards that don't use the keypad controller.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called smsc-ece1099-keypad.
> +
> config KEYBOARD_XTKBD
> tristate "XT keyboard"
> select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 44e7600..0f2aa26 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X) +=
> tc3589x-keypad.o
> obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
> obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> +obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
> obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c
> b/drivers/input/keyboard/smsc-ece1099-keypad.c
> new file mode 100644
> index 000..15dc147
> --- /dev/null
> +++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
> @@ -0,0 +1,304 @@
> +/*
> + * SMSC_ECE1099 Keypad driver
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define KEYPRESS_TIME 200
> +
> +struct smsc_keypad {
> + struct smsc *smsc;
> + struct matrix_keymap_data *keymap_data;
> + unsigned int last_key_state[16];
> + unsigned int last_col;
> + unsigned int last_key_ms[16];
> + unsigned short *keymap;
> + struct i2c_client *client;
> + struct input_dev *input;
> + int rows, cols;
> + int row_shift;
> + bool no_autorepeat;
> + unsignedirq;
> + struct device *dev;
> +};
> +
> +static void smsc_kp_scan(struct smsc_keypad *kp)
> +{
> + struct input_dev *input = kp->input;
> + int i, j;
> + int row, col;
> + int temp, code;
> + unsigned int new_state[16];
> + unsigned int bits_changed;
> + int this_ms;
> +
> + smsc_write(kp->dev, SMSC_KP_INT_MASK, 0x00);
> + smsc_write(kp->dev, SMSC_KP_INT_STAT, 0xFF);
> +
> + /* Scan for row and column */
> + for (i = 0; i < kp->cols; i++) {
> + smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
> + /* Read Row Status */
> + smsc_read(kp->dev, SMSC_KP_IN, &temp);
> + if (temp == 0xFF)
> + continue;
> +
> + col = i;
> + for (j = 0; j < kp->rows; j++) {
> + if ((temp & 0x01) != 0x00) {
> + temp = temp >> 1;
> + continue;
> + }
> +
> + row = j;
> + new_state[col] = (1 << row);
> + bits_changed = kp->last_key_state[col] ^ new_state[col];
> + this_ms = jiffies_to_msecs(jiffies);
> + i
Re: [RFC PATCH 0/6] ACPI: ACPI 5.0 device enumeration proposal
On Mon, Oct 01, 2012 at 02:30:00PM +, Zhang, Rui wrote: > > > > -Original Message- > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > > Sent: Monday, October 01, 2012 2:45 PM > > To: Zhang, Rui > > Cc: LKML; linux-pm; linux-i2c; linux-a...@vger.kernel.org; Len, Brown; > > Rafael J. Wysocki; Grant Likely; Dirk Brandewie > > Subject: Re: [RFC PATCH 0/6] ACPI: ACPI 5.0 device enumeration proposal > > Importance: High > > > > On Fri, Sep 28, 2012 at 03:37:43PM +0800, Zhang Rui wrote: > > > > > > the main idea is that, for Serial Buses like I2C and SPI, we > > enumerate > > > the controller as a platform device, and then enumerate the slaves > > via > > > i2c/spi_register_board_info. And then, when the controller is really > > > probed and enabled in the platform driver, the SPI/I2C bus code will > > > enumerate I2C/SPI slaves automatically. > > > And for the other devices, we will enumerate all of them as platform > > > devices, which is not covered in this patch set yet. > > > > Can you show some example how we could use this new code for example > > with an existing I2C/SPI slave driver? > > This is just prototype patch set that I want to illustrate my idea > on ACPI device enumeration, to get more thoughts on this. > So no example driver so far. But surely you have thought how this should be done? Otherwise we only see a part of the solution here. What if this enumeration you introduce here doesn't play well when I2C/SPI are added? > > > Let's say the device uses few > > GPIOs, one for interrupt and other for triggering firmware download. In > > addition to that it needs a special parameters that can be extracted > > running the "_DSM" method of the device. > > > > Normally the driver would get this stuff from the platform data or from > > Device Tree but how it is done with these patches? > > Can you show me an example driver that gets the special parameters from > Device Tree? drivers/misc/eeprom/at25.c but there are much more if you search for DT enabled drivers. Now, I don't know what is the proper way to pass parameters in ACPI but "_DSM" seems to be one that is being used. -- 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] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
On Wed, Sep 26, 2012 at 04:57:43PM +0530, Philip, Avinash wrote:
> Add support for device-tree binding and of_xlate for EHRWPM driver.
> of_xlate provides EHRPWM polarity configuration from client driver
> device-tree.
> Also size of pwm-cells set to 3 to support pwm channel number, pwm
> period & polarity configuration from device tree.
Oh, I forgot to mention this in my reply to the previous patch, but you
should consistently use PWM to refer to PWM devices, so the above should
be "PWM channel number" and "PWM period & polarity". And the property is
named "#pwm-cells".
> Signed-off-by: Philip, Avinash
> ---
> :00 100644 000... 05d9d63... A
> Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
> :100644 100644 caf00fe... ae23c2b... Mdrivers/pwm/pwm-tiehrpwm.c
> .../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 26 +
> drivers/pwm/pwm-tiehrpwm.c | 107
>
> 2 files changed, 133 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
> b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
> new file mode 100644
> index 000..05d9d63
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
> @@ -0,0 +1,26 @@
> +TI SOC EHRPWM based PWM controller
> +
> +Required properties:
> +- compatible : Must be "ti,am33xx-ehrpwm"
> +- #pwm-cells: Should be 3. Number of cells being used to specify PWM
> property.
> + First cell specifies the per-chip index of the PWM to use, the second
> + cell is the period cycle in nanoseconds and the third cell is the
"period cycle" doesn't make much sense. It should be "period" only. This
also applies to the previous patch.
> + polarity of PWM output. Polarity 0 gives normal polarity and 1 gives
> + inversed polarity (inverse duty cycle)
I don't think "inversed" exists. It should be either "inverted polarity"
or "inverse polarity".
> +- reg: physical base address and size of the registers map. For am33xx,
> + 2 register maps are present (EHRPWM register space & PWM subsystem common
> + config space). Order should be maintained with EHRPWM register map as first
> + entry & PWM subsystem common config space as second entry.
> +
> +Optional properties:
> +- ti,hwmods: Name of the hwmod associated to the EHRPWM:
> + "ehrpwm", being the 0-based instance number from the HW spec
I don't see where this property is used. There is no code in this patch
that parses it.
> +static struct pwm_device *of_ehrpwm_xlate(struct pwm_chip *chip,
> + const struct of_phandle_args *args)
> +{
> + struct pwm_device *pwm;
> +
> + if (chip->of_pwm_n_cells < PWM_CELL_SIZE)
> + return ERR_PTR(-EINVAL);
> +
> + if (args->args[0] >= chip->npwm)
> + return ERR_PTR(-EINVAL);
> +
> + pwm = pwm_request_from_chip(chip, args->args[0], NULL);
> + if (IS_ERR(pwm))
> + return pwm;
> +
> + pwm_set_period(pwm, args->args[1]);
> + pwm_set_polarity(pwm, args->args[2]);
> + return pwm;
> +}
This is an exact duplicate of the ECAP's of_xlate(). Maybe we should
make this part of the PWM core. If so it is probably safer to define the
values for the third cell as flags, where the polarity is encoded in bit
0, and make the function handle this accordingly to allow other bits to
be added in the future.
The same comments as for patch 1 apply to the rest of this patch as
well.
Thierry
pgpVTB0DU0wLA.pgp
Description: PGP signature
Re: [RFC PATCH 5/6] ACPI: Introduce ACPI I2C controller enumeration driver
On Mon, Oct 01, 2012 at 02:19:49PM +, Zhang, Rui wrote:
>
>
> > -Original Message-
> > From: linux-i2c-ow...@vger.kernel.org [mailto:linux-i2c-
> > ow...@vger.kernel.org] On Behalf Of Mika Westerberg
> > Sent: Monday, October 01, 2012 2:55 PM
> > To: Zhang, Rui
> > Cc: LKML; linux-pm; linux-i2c; linux-a...@vger.kernel.org; Len, Brown;
> > Rafael J. Wysocki; Grant Likely; Dirk Brandewie
> > Subject: Re: [RFC PATCH 5/6] ACPI: Introduce ACPI I2C controller
> > enumeration driver
> > Importance: High
> >
> > On Fri, Sep 28, 2012 at 03:40:32PM +0800, Zhang Rui wrote:
> > > +acpi_status __init i2c_enumerate_slave(acpi_handle handle, u32 level,
> > > +void *data, void **return_value) {
> > > + int result;
> > > + acpi_status status;
> > > + struct acpi_buffer buffer;
> > > + struct acpi_resource *resource;
> > > + struct acpi_resource_gpio *gpio;
> > > + struct acpi_resource_i2c_serialbus *i2c;
> > > + int i;
> > > + struct acpi_i2c_root *root = data;
> > > + struct i2c_board_info info;
> > > + struct acpi_device *device;
> > > +
> > > + if (acpi_bus_get_device(handle, &device))
> > > + return AE_OK;
> > > +
> > > + status = acpi_get_current_resources(handle, &buffer);
> > > + if (ACPI_FAILURE(status)) {
> > > + dev_err(&device->dev, "Failed to get ACPI resources\n");
> > > + return AE_OK;
> > > + }
> > > +
> > > + for (i = 0; i < buffer.length; i += sizeof(struct acpi_resource))
> > {
> > > + resource = (struct acpi_resource *)(buffer.pointer + i);
> > > +
> > > + switch (resource->type) {
> > > + case ACPI_RESOURCE_TYPE_GPIO:
> > > + gpio = &resource->data.gpio;
> > > +
> > > + if (gpio->connection_type ==
> > ACPI_RESOURCE_GPIO_TYPE_INT) {
> > > + result =
> > > + acpi_device_get_gpio_irq
> > > + (gpio->resource_source.string_ptr,
> > > + gpio->pin_table[0], &info.irq);
> >
> > acpi_device_get_gpio_irq() is not defined in this patch series?
> >
> ACPI GPIO controller patch has already been sent out, but in ACPI mailing
> list only.
It would have been good idea to mention this in the cover letter at least.
>
> > Also you need to do the gpio_request()/gpio_to_irq() things somewhere.
> > Are they handled in acpi_device_get_gpio_irq()?
> >
> Yep.
>
> > How about GpioIo resources?
> >
> This is not covered in this patch set, but will be in the next patch set.
>
> > > + if (result)
> > > + dev_err(&device->dev,
> > > + "Failed to get IRQ\n");
> > > + }
> > > + break;
> > > + case ACPI_RESOURCE_TYPE_SERIAL_BUS:
> > > + i2c = &resource->data.i2c_serial_bus;
> > > +
> > > + info.addr = i2c->slave_address;
> > > + break;
> > > + default:
> > > + break;
> > > + }
> > > + }
> > > +
> > > + add_slave(root, &info);
> > > +
> > > + kfree(buffer.pointer);
> > > + return AE_OK;
> > > +}
> > > +
> > > +static int __devinit acpi_i2c_root_add(struct acpi_device *device) {
> > > + acpi_status status;
> > > + struct acpi_i2c_root *root;
> > > + struct resource *resources;
> > > + int result;
> > > +
> > > + if (!device->pnp.unique_id) {
> > > + dev_err(&device->dev,
> > > + "Unsupported ACPI I2C controller. No UID\n");
> >
> > Where does this restriction come from? As far as I understand UID is
> > optional.
> >
>
> _UID is optional.
> But it seems to be required for SPB buses that need ACPI device enumeration.
> At least this is true for the ACPI 5 compatible ACPI tables I have.
Yes but if some vendor is not setting it (as it is optional) you still want
your code to work, right?
--
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/6] Introduce acpi_match_device_id().
On Mon, Oct 01, 2012 at 01:56:17PM +, Zhang, Rui wrote:
>
>
> > -Original Message-
> > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> > Sent: Monday, October 01, 2012 2:38 PM
> > To: Zhang, Rui
> > Cc: LKML; linux-pm; linux-i2c; linux-a...@vger.kernel.org; Len, Brown;
> > Rafael J. Wysocki; Grant Likely; Dirk Brandewie
> > Subject: Re: [RFC PATCH 1/6] Introduce acpi_match_device_id().
> > Importance: High
> >
> > On Sat, Sep 29, 2012 at 01:31:52PM +, Zhang, Rui wrote:
> > >
> > > > > +{
> > > > > + acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
> > > >
> > > > If the device is not bound to an ACPI handle this will return NULL.
> > > > And I don't see you doing that in this series meaning that..
> > > >
> > >
> > >
> > > You're right, I should set pdev->archdata.acpi_handle to the I2C
> > > controller in i2c_root.c.
> >
> > There already is an API for that - check drivers/acpi/glue.c.
>
> Do you mean acpi_bind?
No, I mean register_acpi_bus_type(). You can see an example of this looking
PCI, USB, .., drivers.
--
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 00/11] x86/microcode: Early load microcode
On 10/01/2012 09:27 AM, Borislav Petkov wrote: On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote: Hey, Any chance of this getting merge for the 3.7 cycle? It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898 Yes, Fenghua who has been working on it unfortunately got preempted at an inopportune moment. It will get fixed. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/
[GIT PULL] GPIO changes for v3.7
Hi Linus, this is my major GPIO pull request for the v3.7 merge window. The description of what's going on is in the tag (see below). I think some of it is prerequisites for the ARM SoC tree so better send this pull early. All has boiled in -next for some time except the 4 topmost commits, which are oneline fixes (would else be -rc material) and a documentation fix. Please pull it in! Yours, Linus Walleij The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-for-v3.7 for you to fetch changes up to 901acf5b2910434501c221a363bb3486b647b5c4: gpio: pcf857x: select IRQ_DOMAIN (2012-09-30 23:38:53 +0200) So this is the LW GPIO patch stack for v3.7: - refactoring from Thierry Redding at Arnd Bergmann's request to use the seq_file iterator interface in gpiolib. - A new driver for Avionic Design's N-bit GPIO expander. - Two instances of mutexes replaced by spinlocks from Axel Lin to code that is supposed to be fastpath compliant. - IRQ demuxer and gpio_to_irq() support for pcf857x by Kuninori Morimoto. - Dynamic GPIO numbers, device tree support, daisy chaining and some other fixes for the 74x164 driver by Maxime Ripard. - IRQ domain and device tree support for the tc3589x driver by Lee Jones. - Some conversion to use managed resources devm_* code. - Some instances of clk_prepare() or clk_prepare_enable() added to support the new, stricter common clock framework. - Some for_each_set_bit() simplifications. - Then a lot of fixes as we fixed up all of the above tripping over our own shoelaces and that kind of thing. Arnd Bergmann (1): gpio: pcf857x: select IRQ_DOMAIN Axel Lin (12): gpio: gpio-ml-ioh: Use spinlock for register access protection gpio: gpio-pch: Use spinlock for register access protection gpio: mc9s08dz60: Use devm_kzalloc API gpio: Remove broken mark for da9052 gpio driver gpio: da9052: Convert to use devm_kzalloc API gpio: tps65912: Convert to use devm_kzalloc API gpio: Use DEFINE_PCI_DEVICE_TABLE macro gpio: adp5588: Use module_i2c_driver gpio: wm831x: Convert to use devm_kzalloc API gpio: wm8350: Convert to use devm_kzalloc API gpio: em: Use irq_data_get_irq_chip_data() at appropriate places gpio: sx150x: Use irq_data_get_irq_chip_data() at appropriate places Julia Lawall (1): drivers/gpio/gpio-pxa.c: use clk_prepare_enable and clk_disable_unprepare Kuninori Morimoto (3): gpio: pcf857x: enable gpio_to_irq() support gpio: pcf857x: fixup smatch WARNING ARM: shmobile: kzm9g: use gpio-keys instead of gpio-keys-polled Lee Jones (2): gpio: Provide the tc3589x GPIO expander driver with an IRQ domain gpio: Enable the tc3298x GPIO expander driver for Device Tree Maxime Ripard (6): gpio: 74x164: Use module_spi_driver boiler plate function gpio: 74x164: Use devm_kzalloc gpio: 74x164: Use dynamic gpio number assignment if no pdata is present gpio: 74x164: Add device tree support gpio: 74x164: dts: Add documentation for the dt binding gpio: 74x164: Add support for the daisy-chaining Murali Karicheri (1): gpio: davinci: preparation for switch to common clock framework Roland Stigge (2): gpio-lpc32xx: Add GPI_28 gpio: Document device_node's det_debounce Sachin Kamat (1): dt: Fix incorrect reference in gpio-led documentation Thierry Reding (3): gpiolib: Use seq_file's iterator interface gpio: Add Avionic Design N-bit GPIO expander support gpio: adnp: dt: Reference generic interrupt binding Wei Yongjun (2): gpio_msm: using for_each_set_bit to simplify the code gpio: pxa: using for_each_set_bit to simplify the code .../devicetree/bindings/gpio/gpio-74x164.txt | 22 + .../devicetree/bindings/gpio/gpio-adnp.txt | 34 ++ Documentation/devicetree/bindings/gpio/led.txt | 2 +- arch/arm/configs/kzm9g_defconfig | 2 +- arch/arm/mach-shmobile/board-kzm9g.c | 5 +- drivers/gpio/Kconfig | 14 +- drivers/gpio/Makefile | 1 + drivers/gpio/gpio-74x164.c | 103 +++- drivers/gpio/gpio-adnp.c | 611 + drivers/gpio/gpio-adp5588.c| 14 +- drivers/gpio/gpio-bt8xx.c | 2 +- drivers/gpio/gpio-da9052.c | 15 +- drivers/gpio/gpio-davinci.c| 2 +- drivers/gpio/gpio-em.c | 12 +- drivers/gpio/gpio-lpc32xx.c| 3 +- drivers/gpio/gpio-mc9s08dz60.c
Re: [PATCH 1/2] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
On Wed, Sep 26, 2012 at 04:57:42PM +0530, Philip, Avinash wrote:
[...]
> +#include
[...]
> +static struct pwmss_platform_data am33xx_data = {
> + .has_configspace= true,
> +};
This structure is defined in a public header. I don't see why it has to,
given that it's only used to associate some data with an of_device_id
entry below. Since AM33xx never had anything but OF support in the
mainline kernel I don't think we should add platform data.
> +#ifdef CONFIG_OF
> +static const struct of_device_id ecap_of_match[] = {
> + {
> + .compatible = "ti,am33xx-ecap",
> + .data = &am33xx_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ecap_of_match);
> +#endif
> +
I don't quite see why we need to pass this platform data to the device
at all since there is no other variant anyway. I think this should only
be added if this turns out to be required at some point.
> static int __devinit ecap_pwm_probe(struct platform_device *pdev)
> {
> int ret;
> struct resource *r;
> struct clk *clk;
> struct ecap_pwm_chip *pc;
> + struct pwmss_platform_data *pdata = pdev->dev.platform_data;
> + const struct of_device_id *match;
> + u16 regval;
> + struct pinctrl *pinctrl;
> +
> + match = of_match_device(of_match_ptr(ecap_of_match), &pdev->dev);
I've never seen of_match_ptr() used this way. Maybe you should think
about not #ifdef'ing OF specific code at all. That way ecap_of_match
will always exist and you could use the IS_ENABLED() macro to
conditionalize at compile time. The compiler will probably be clever
enough to optimize the ecap_of_match away if OF is not enabled.
Given my comment earlier, since AM33xx is OF only you might just as well
add a depends on OF to this driver and things will become a lot easier.
> +
> + if (match)
> + pdata = (struct pwmss_platform_data *)match->data;
> +
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(pinctrl))
> + dev_warn(&pdev->dev, "failed to configure pins from driver\n");
>
> pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
> if (!pc) {
> @@ -211,6 +268,8 @@ static int __devinit ecap_pwm_probe(struct
> platform_device *pdev)
>
> pc->chip.dev = &pdev->dev;
> pc->chip.ops = &ecap_pwm_ops;
> + pc->chip.of_xlate = of_ecap_xlate;
> + pc->chip.of_pwm_n_cells = PWM_CELL_SIZE;
> pc->chip.base = -1;
> pc->chip.npwm = 1;
>
> @@ -231,13 +290,56 @@ static int __devinit ecap_pwm_probe(struct
> platform_device *pdev)
> }
>
> pm_runtime_enable(&pdev->dev);
> +
> + /*
> + * Some platform has extra PWM-subsystem common config space
> + * and requires special handling of clock gating.
> + */
> + if (pdata && pdata->has_configspace) {
> + r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!r) {
> + dev_err(&pdev->dev, "no memory resource defined\n");
> + ret = -ENODEV;
> + goto err_disable_clock;
> + }
> +
> + pc->config_base = devm_ioremap(&pdev->dev, r->start,
> + resource_size(r));
> + if (!pc->config_base) {
> + dev_err(&pdev->dev, "failed to ioremap() registers\n");
> + ret = -EADDRNOTAVAIL;
> + goto err_disable_clock;
> + }
Isn't this missing a request_mem_region()? I assume you don't do that
here because you need the same region in the EHRPWM driver, right? This
should be indication enough that the design is not right here. I think
we need a proper abstraction here. Can this not be done via PM runtime
support? If not, maybe this should be represented by clock objects since
the bit obviously enables a clock.
> +
> + /* Enable ECAP clock gating at PWM-subsystem common config */
> + pm_runtime_get_sync(&pdev->dev);
> + regval = readw(pc->config_base + PWMSS_CLKCONFIG);
> + regval |= PWMSS_ECAP_CLK_EN;
> + writew(regval, pc->config_base + PWMSS_CLKCONFIG);
> + pm_runtime_put_sync(&pdev->dev);
> + }
> +
> platform_set_drvdata(pdev, pc);
> return 0;
> +
> +err_disable_clock:
> + pm_runtime_disable(&pdev->dev);
> + return ret;
> }
>
> static int __devexit ecap_pwm_remove(struct platform_device *pdev)
> {
> struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
> + u16 regval;
> +
> + if (pc->config_base) {
> + /* Disable ECAP clock gating at PWM-subsystem common config */
> + pm_runtime_get_sync(&pdev->dev);
> + regval = readw(pc->config_base + PWMSS_CLKCONFIG);
> + regval &= ~PWMSS_ECAP_CLK_EN;
> + writew(regval, pc->config_base + PWMSS_CLKCONFIG);
> + pm_runtime_put_sync(&pdev->dev);
> + }
>
> pm_runtime_put_sync(&
Re: [ 026/180] eCryptfs: Improve statfs reporting
On Mon, Oct 01, 2012 at 10:46:56PM -0700, Tyler Hicks wrote: > On 2012-10-02 00:52:23, Willy Tarreau wrote: > > 2.6.32-longterm review patch. If anyone has any objections, please let me > > know. > > Hi - Please drop this patch. It incorrectly calculates f_namelen and I > haven't had a chance to fix it yet. When I get a fix ready, I'll forward > the corrected patch to stable@v.k.o. Thanks! Done, thanks Tyler ! 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: [PATCH] HID: picoLCD: Remove use of deprecated function
On Tue, Oct 02, 2012 at 12:18:00AM +0200, Jiri Kosina wrote: > Linus has just pulled from me, so if you could take care of this merge > conflict, that'd be awesome. Will do. Thanks. -- tejun -- 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 signal tree with the vfs tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in fs/exec.c
between commit 5b8a94d461a7 ("coredump: move core dump functionality into
its own file") from the vfs tree and commits 282124d18626 ("generic
kernel_execve()") and 38b983b3461e ("generic sys_execve()") from the signal
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/exec.c
index 48fb26e,50a1270..000
--- a/fs/exec.c
+++ b/fs/exec.c
@@@ -1645,3 -2031,342 +1644,55 @@@ int get_dumpable(struct mm_struct *mm
{
return __get_dumpable(mm->flags);
}
+
-static void wait_for_dump_helpers(struct file *file)
-{
- struct pipe_inode_info *pipe;
-
- pipe = file->f_path.dentry->d_inode->i_pipe;
-
- pipe_lock(pipe);
- pipe->readers++;
- pipe->writers--;
-
- while ((pipe->readers > 1) && (!signal_pending(current))) {
- wake_up_interruptible_sync(&pipe->wait);
- kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
- pipe_wait(pipe);
- }
-
- pipe->readers--;
- pipe->writers++;
- pipe_unlock(pipe);
-
-}
-
-
-/*
- * umh_pipe_setup
- * helper function to customize the process used
- * to collect the core in userspace. Specifically
- * it sets up a pipe and installs it as fd 0 (stdin)
- * for the process. Returns 0 on success, or
- * PTR_ERR on failure.
- * Note that it also sets the core limit to 1. This
- * is a special value that we use to trap recursive
- * core dumps
- */
-static int umh_pipe_setup(struct subprocess_info *info, struct cred *new)
-{
- struct file *files[2];
- struct fdtable *fdt;
- struct coredump_params *cp = (struct coredump_params *)info->data;
- struct files_struct *cf = current->files;
- int err = create_pipe_files(files, 0);
- if (err)
- return err;
-
- cp->file = files[1];
-
- sys_close(0);
- fd_install(0, files[0]);
- spin_lock(&cf->file_lock);
- fdt = files_fdtable(cf);
- __set_open_fd(0, fdt);
- __clear_close_on_exec(0, fdt);
- spin_unlock(&cf->file_lock);
-
- /* and disallow core files too */
- current->signal->rlim[RLIMIT_CORE] = (struct rlimit){1, 1};
-
- return 0;
-}
-
-void do_coredump(long signr, int exit_code, struct pt_regs *regs)
-{
- struct core_state core_state;
- struct core_name cn;
- struct mm_struct *mm = current->mm;
- struct linux_binfmt * binfmt;
- const struct cred *old_cred;
- struct cred *cred;
- int retval = 0;
- int flag = 0;
- int ispipe;
- bool need_nonrelative = false;
- static atomic_t core_dump_count = ATOMIC_INIT(0);
- struct coredump_params cprm = {
- .signr = signr,
- .regs = regs,
- .limit = rlimit(RLIMIT_CORE),
- /*
- * We must use the same mm->flags while dumping core to avoid
- * inconsistency of bit flags, since this flag is not protected
- * by any locks.
- */
- .mm_flags = mm->flags,
- };
-
- audit_core_dumps(signr);
-
- binfmt = mm->binfmt;
- if (!binfmt || !binfmt->core_dump)
- goto fail;
- if (!__get_dumpable(cprm.mm_flags))
- goto fail;
-
- cred = prepare_creds();
- if (!cred)
- goto fail;
- /*
- * We cannot trust fsuid as being the "true" uid of the process
- * nor do we know its entire history. We only know it was tainted
- * so we dump it as root in mode 2, and only into a controlled
- * environment (pipe handler or fully qualified path).
- */
- if (__get_dumpable(cprm.mm_flags) == SUID_DUMPABLE_SAFE) {
- /* Setuid core dump mode */
- flag = O_EXCL; /* Stop rewrite attacks */
- cred->fsuid = GLOBAL_ROOT_UID; /* Dump root private */
- need_nonrelative = true;
- }
-
- retval = coredump_wait(exit_code, &core_state);
- if (retval < 0)
- goto fail_creds;
-
- old_cred = override_creds(cred);
-
- /*
- * Clear any false indication of pending signals that might
- * be seen by the filesystem code called to write the core file.
- */
- clear_thread_flag(TIF_SIGPENDING);
-
- ispipe = format_corename(&cn, signr);
-
- if (ispipe) {
- int dump_count;
- char **helper_argv;
-
- if (ispipe < 0) {
- printk(KERN_WARNING "format_corename failed\n");
- printk(KERN_WARNING "Aborting core\n");
- goto fail_corename;
- }
-
- if (cprm.limit == 1) {
- /* See umh_pipe_setup() whic
Re: [ 026/180] eCryptfs: Improve statfs reporting
On 2012-10-02 00:52:23, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me
> know.
Hi - Please drop this patch. It incorrectly calculates f_namelen and I
haven't had a chance to fix it yet. When I get a fix ready, I'll forward
the corrected patch to stable@v.k.o. Thanks!
Tyler
>
> --
>
> From: Tyler Hicks
>
> commit 4a26620df451ad46151ad21d711ed43e963c004e upstream.
>
> BugLink: http://bugs.launchpad.net/bugs/885744
>
> statfs() calls on eCryptfs files returned the wrong filesystem type and,
> when using filename encryption, the wrong maximum filename length.
>
> If mount-wide filename encryption is enabled, the cipher block size and
> the lower filesystem's max filename length will determine the max
> eCryptfs filename length. Pre-tested, known good lengths are used when
> the lower filesystem's namelen is 255 and a cipher with 8 or 16 byte
> block sizes is used. In other, less common cases, we fall back to a safe
> rounded-down estimate when determining the eCryptfs namelen.
>
> https://launchpad.net/bugs/885744
>
> Signed-off-by: Tyler Hicks
> Reported-by: Kees Cook
> Reviewed-by: Kees Cook
> Reviewed-by: John Johansen
> Signed-off-by: Colin Ian King
> Acked-by: Stefan Bader
> Signed-off-by: Tim Gardner
> Signed-off-by: Willy Tarreau
> ---
> fs/ecryptfs/crypto.c | 68
> fs/ecryptfs/ecryptfs_kernel.h | 11 ++
> fs/ecryptfs/keystore.c|9 ++---
> fs/ecryptfs/super.c | 18 ++-
> 4 files changed, 92 insertions(+), 14 deletions(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index 7e164bb..7786bf6 100644
> --- a/fs/ecryptfs/crypto.c
> +++ b/fs/ecryptfs/crypto.c
> @@ -2039,6 +2039,17 @@ out:
> return;
> }
>
> +static size_t ecryptfs_max_decoded_size(size_t encoded_size)
> +{
> + /* Not exact; conservatively long. Every block of 4
> + * encoded characters decodes into a block of 3
> + * decoded characters. This segment of code provides
> + * the caller with the maximum amount of allocated
> + * space that @dst will need to point to in a
> + * subsequent call. */
> + return ((encoded_size + 1) * 3) / 4;
> +}
> +
> /**
> * ecryptfs_decode_from_filename
> * @dst: If NULL, this function only sets @dst_size and returns. If
> @@ -2057,13 +2068,7 @@ ecryptfs_decode_from_filename(unsigned char *dst,
> size_t *dst_size,
> size_t dst_byte_offset = 0;
>
> if (dst == NULL) {
> - /* Not exact; conservatively long. Every block of 4
> - * encoded characters decodes into a block of 3
> - * decoded characters. This segment of code provides
> - * the caller with the maximum amount of allocated
> - * space that @dst will need to point to in a
> - * subsequent call. */
> - (*dst_size) = (((src_size + 1) * 3) / 4);
> + (*dst_size) = ecryptfs_max_decoded_size(src_size);
> goto out;
> }
> while (src_byte_offset < src_size) {
> @@ -2289,3 +2294,52 @@ out_free:
> out:
> return rc;
> }
> +
> +#define ENC_NAME_MAX_BLOCKLEN_8_OR_16143
> +
> +int ecryptfs_set_f_namelen(long *namelen, long lower_namelen,
> +struct ecryptfs_mount_crypt_stat *mount_crypt_stat)
> +{
> + struct blkcipher_desc desc;
> + struct mutex *tfm_mutex;
> + size_t cipher_blocksize;
> + int rc;
> +
> + if (!(mount_crypt_stat->flags & ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES)) {
> + (*namelen) = lower_namelen;
> + return 0;
> + }
> +
> + rc = ecryptfs_get_tfm_and_mutex_for_cipher_name(&desc.tfm, &tfm_mutex,
> + mount_crypt_stat->global_default_fn_cipher_name);
> + if (unlikely(rc)) {
> + (*namelen) = 0;
> + return rc;
> + }
> +
> + mutex_lock(tfm_mutex);
> + cipher_blocksize = crypto_blkcipher_blocksize(desc.tfm);
> + mutex_unlock(tfm_mutex);
> +
> + /* Return an exact amount for the common cases */
> + if (lower_namelen == NAME_MAX
> + && (cipher_blocksize == 8 || cipher_blocksize == 16)) {
> + (*namelen) = ENC_NAME_MAX_BLOCKLEN_8_OR_16;
> + return 0;
> + }
> +
> + /* Return a safe estimate for the uncommon cases */
> + (*namelen) = lower_namelen;
> + (*namelen) -= ECRYPTFS_FNEK_ENCRYPTED_FILENAME_PREFIX_SIZE;
> + /* Since this is the max decoded size, subtract 1 "decoded block" len */
> + (*namelen) = ecryptfs_max_decoded_size(*namelen) - 3;
> + (*namelen) -= ECRYPTFS_TAG_70_MAX_METADATA_SIZE;
> + (*namelen) -= ECRYPTFS_FILENAME_MIN_RANDOM_PREPEND_BYTES;
> + /* Worst case is that the filename is padded nearly a full block size */
> + (*namelen) -= cipher_blocksize - 1;
> +
> + if ((*namelen) < 0)
> + (*namelen) = 0;
> +
> + return 0;
> +}
> diff --git
Re: Re: [PATCH v3 1/3] devfreq: Core updates to support devices which can idle
> On 27 September 2012 13:50, MyungJoo Ham wrote:
> >> Prepare devfreq core framework to support devices which
> >> can idle. When device idleness is detected perhaps through
> >> runtime-pm, need some mechanism to suspend devfreq load
> >> monitoring and resume back when device is online. Present
> >> code continues monitoring unless device is removed from
> >> devfreq core.
> >>
> >> This patch introduces following design changes,
> >>
> >> - use per device work instead of global work to monitor device
> >> load. This enables suspend/resume of device devfreq and
> >> reduces monitoring code complexity.
> >> - decouple delayed work based load monitoring logic from core
> >> by introducing helpers functions to be used by governors. This
> >> provides flexibility for governors either to use delayed work
> >> based monitoring functions or to implement their own mechanism.
> >> - devfreq core interacts with governors via events to perform
> >> specific actions. These events include start/stop devfreq.
> >> This sets ground for adding suspend/resume events.
> >>
> >> The devfreq apis are not modified and are kept intact.
> >>
> >> Signed-off-by: Rajagopal Venkat
> >
> > Hello,
> >
> >
> > I'll do more through review tomorrow (sorry, I was occuppied by
> > something other than Linux tasks for a while again); however,
> > there are two concerns in this patch.
> >
> > 1. (minor but may bothersome in some rare but not-ignorable cases)
> > Serialization issue between suspend/resume
> > functions; this may happen with some failure or interrupts while entering
> > STR or
> > unexpected usage of the API at drivers.
>
> Regarding the invalid usage of suspend/resume apis, we can have
> additional checks
> something like,
>
> void devfreq_monitor_suspend(struct devfreq *devfreq)
> {
> .
> if (devfreq->stop_polling)
> return;
> ..
> }
>
> void devfreq_monitor_resume(struct devfreq *devfreq)
> {
> .
> if (!devfreq->stop_polling)
> return;
> ..
> }
>
> >
> > For example, if devfreq_monitor_suspend() and devfreq_montir_resume() are
> > called
> > almost simultaneously, we may execute 1) locked part of suspend, 2) locked
> > part of
> > resume, 3) cancel_delayed_work_sync of suspend.
> >
> > Then, we may have stop_polling = false w/ cancel_delayed_work_sync() in
> > effect.
> >
> > Let's not assume that suspend() and resume() may called almost
> > simultaneously,
> > especially in subsystem core code.
(sorry, I missed "not be" between "may" and "called" here)
> >
>
> These devfreq_monitor_suspend() and devfreq_monitor_resume() functions are
> executed when device idleness is detected. Perhaps,
> - using runtime-pm: the runtime_suspend() and runtime_resume() are mutually
> exclusive and is guaranteed not to run in parallel.
> - driver may have its own mechanism: in my opinion, driver should ensure
> suspend/resume are sequential even for it to know its devfreq status.
>
> Assuming even if above sequence occurs, I don't see any problem having
> stop_polling = false w/ cancel_delayed_work_sync() in effect. Since the
> suspend
> is the last one to complete, monitoring will not continue.
Why don't you simply extend the mutex-locked context?
I.e.,
+ mutex_lock(&devfreq->lock);
+ devfreq->stop_polling = true;
+ mutex_unlock(&devfreq->lock);
+ cancel_delayed_work_sync(&devfreq->work);
-->
+ mutex_lock(&devfreq->lock);
+ devfreq->stop_polling = true;
+ cancel_delayed_work_sync(&devfreq->work);
+ mutex_unlock(&devfreq->lock);
This serializes data-update and the execution based on the data-update,
resolving any inconsistency issues with the queue-status and devfreq
variable.
It doesn't have a heavy overhead to extend it and we have the
probably of inconsistency due to serialization issues.
>
> >
> > 2. What if polling_ms = 0 w/ active governors (such as ondemand)?
> >
> > Users may declare the initial polling_ms = 0 w/ simple-ondemand in order to
> > pause sampling at boot-time and start sampling at run-time some time later.
> >
> > It appears that this patch will start forcibly at boot-time in such a case.
>
> Yes. This is a valid case which can be handled by
>
> void devfreq_monitor_start(struct devfreq *devfreq)
> {
> INIT_DELAYED_WORK_DEFERRABLE(&devfreq->work, devfreq_monitor);
> + if (devfreq->profile->polling_ms)
> queue_delayed_work(devfreq_wq, &devfreq->work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
> }
Please add the checking statement to every queue_delayed_work() statement:
resume and interval-update functions.
Cheers!
MyungJoo
Re: [PATCH v2 1/3] w1: mxc_w1: Adapt the clock name to the new clock framework
On Mon, Oct 01, 2012 at 02:51:44PM -0300, Fabio Estevam (fabio.este...@freescale.com) wrote: > Evgeny, > > Any comments, please? I have no objections per se, but I'm hardly an expert in imx clock framework :) Since it is only one patch in set of 3, I suppose it will be pushed through different tree than w1. Feel free to add my ack. Acked-by: Evgeniy Polyakov -- Evgeniy Polyakov -- 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 arm-soc tree with the spi-mb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/spi/spi-tegra.c between commit 536a53a300d0 ("spi: remove
completely broken Tegra driver") from the spi-mb tree and commit
5bd276118189 ("spi: tegra: remove support of legacy DMA driver based
access") from the arm-soc tree.
I removed the file and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpOKVz5m3Bkd.pgp
Description: PGP signature
linux-next: manual merge of the arm-soc tree with the spi-mb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/spi/Kconfig between commit 536a53a300d0 ("spi: remove completely
broken Tegra driver") from the spi-mb tree and commit 5bd276118189 ("spi:
tegra: remove support of legacy DMA driver based access") from the
arm-soc tree.
I fixed it up (by removing the SPI_TEGRA section) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpROpR5lndwI.pgp
Description: PGP signature
Re: [PATCH v3 -tip 5/5] AHCI: Support multiple MSIs
* Alexander Gordeev wrote:
> Take advantage of multiple MSIs implementation on x86 - on systems with
> IRQ remapping AHCI ports not only get assigned separate MSI vectors -
> but also separate IRQs. As result, interrupts generated by different
> ports could be serviced on different CPUs rather than on a single one.
>
> In cases when number of allocated MSIs is less than requested the Sharing
> Last MSI mode does not get used, no matter implemented in hardware or not.
> Instead, the driver assumes the advantage of multiple MSIs is negated and
> falls back to the single MSI mode as if MRSM bit was set (some Intel chips
> implement this strategy anyway - MRSM bit gets set even if the number of
> allocated MSIs exceeds the number of implemented ports).
>
> Signed-off-by: Alexander Gordeev
> ---
> drivers/ata/ahci.c| 91 --
> drivers/ata/ahci.h|6 +++
> drivers/ata/libahci.c | 118
> ++---
> 3 files changed, 205 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 7862d17..5463fcea 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1057,6 +1057,84 @@ static inline void ahci_gtf_filter_workaround(struct
> ata_host *host)
> {}
> #endif
>
> +int ahci_init_interrupts(struct pci_dev *pdev, struct ahci_host_priv *hpriv)
> +{
> + int rc;
> + unsigned int maxvec;
> +
> + if (!(hpriv->flags & AHCI_HFLAG_NO_MSI)) {
> + rc = pci_enable_msi_block_auto(pdev, &maxvec);
> + if (rc > 0) {
> + if ((rc == maxvec) || (rc == 1))
> + return rc;
> + /* assume that advantage of multipe MSIs is negated,
> + * so fallback to single MSI mode to save resources */
Please use the customary (multi-line) comment style:
/*
* Comment .
* .. goes here.
*/
specified in Documentation/CodingStyle.
> + pci_disable_msi(pdev);
> + if (!pci_enable_msi(pdev))
> + return 1;
> + }
> + }
> +
> + pci_intx(pdev, 1);
> + return 0;
> +}
> +
> +/**
> + * ahci_host_activate - start AHCI host, request IRQs and register it
> + * @host: target ATA host
> + * @irq: base IRQ number to request
> + * @n_msis: number of MSIs allocated for this host
> + * @irq_handler: irq_handler used when requesting IRQs
> + * @irq_flags: irq_flags used when requesting IRQs
> + *
> + * Similar to ata_host_activate, but requests IRQs according to AHCI-1.1
> + * when multiple MSIs were allocated. That is one MSI per port, starting
> + * from @irq.
> + *
> + * LOCKING:
> + * Inherited from calling layer (may sleep).
> + *
> + * RETURNS:
> + * 0 on success, -errno otherwise.
> + */
> +int ahci_host_activate(struct ata_host *host, int irq, unsigned int n_msis)
> +{
> + int i, rc;
> +
> + /* Sharing Last Message among several ports is not supported */
> + if (n_msis < host->n_ports)
> + return -EINVAL;
> +
> + rc = ata_host_start(host);
> + if (rc)
> + return rc;
> +
> + for (i = 0; i < host->n_ports; i++) {
> + rc = devm_request_threaded_irq(host->dev,
> + irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
> + dev_driver_string(host->dev), host->ports[i]);
> + if (rc)
> + goto out_free_irqs;
> + }
> +
> + for (i = 0; i < host->n_ports; i++)
> + ata_port_desc(host->ports[i], "irq %d", irq + i);
> +
> + rc = ata_host_register(host, &ahci_sht);
> + if (rc)
> + goto out_free_all_irqs;
> +
> + return 0;
> +
> +out_free_all_irqs:
> + i = host->n_ports;
> +out_free_irqs:
> + for (; i; i--)
> + devm_free_irq(host->dev, irq + i - 1, host->ports[i]);
Please test the failure path somehow - for example I'm quite
sure that the line above is buggy and will crash/hang a real
system: it should be host->ports[i-1].
Writing it as:
devm_free_irq(host->dev, irq + i-1, host->ports[i-1]);
would help readability as well as bit - or just:
for (i--; i >= 0; i--)
devm_free_irq(host->dev, irq + i, host->ports[i]);
(untested)
> +
> + return rc;
> +}
> +
> static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> {
> unsigned int board_id = ent->driver_data;
> @@ -1065,7 +1143,7 @@ static int ahci_init_one(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> struct device *dev = &pdev->dev;
> struct ahci_host_priv *hpriv;
> struct ata_host *host;
> - int n_ports, i, rc;
> + int n_ports, n_msis, i, rc;
> int ahci_pci_bar = AHCI_PCI_BAR_STANDARD;
>
> VPRINTK("ENTER\n");
> @@ -1150,11 +1228,12 @@ static int ahci_init_one(struct pci_dev *pdev, const
> struct pci_de
[PATCH v2] serial/arc-uart: Add new driver
From: Vineet Gupta Driver for non-standard on-chip UART, instantiated in the ARC (Synopsys) FPGA Boards such as ARCAngel4/ML50x v2: * ttyARC used as device name * Dynamic assignment of major/minor numbers. * Ref counting tty in rx routine to prevent it from disappearing in case of a hangup * set_termios fixes: - hardware flow control/parity are marked as unsupported - baud written back to termios * cosmetics such as commenting the need for @running_on_iss, empty lines etc Signed-off-by: Vineet Gupta --- drivers/tty/serial/Kconfig| 25 ++ drivers/tty/serial/Makefile |1 + drivers/tty/serial/arc_uart.c | 746 + include/linux/serial_core.h |3 + 4 files changed, 775 insertions(+), 0 deletions(-) create mode 100644 drivers/tty/serial/arc_uart.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 4720b4b..af4bd69 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1360,4 +1360,29 @@ config SERIAL_EFM32_UART_CONSOLE depends on SERIAL_EFM32_UART=y select SERIAL_CORE_CONSOLE +config SERIAL_ARC + bool "ARC UART driver support" + select SERIAL_CORE + default y + help + Driver for on-chip UART for ARC(Synopsys) for the legacy + FPGA Boards (ML50x/ARCAngel4) + +config SERIAL_ARC_CONSOLE + bool + select SERIAL_CORE_CONSOLE + depends on SERIAL_ARC=y + default y + help + Enable system Console on ARC UART + +config SERIAL_ARC_NR_PORTS + int 'Number of ports' + range 1 3 + default 1 + depends on SERIAL_ARC + help + Set this to the number of serial ports you want the driver + to support. + endmenu diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index 7257c5d..2b70b5f 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -79,3 +79,4 @@ obj-$(CONFIG_SERIAL_XILINX_PS_UART) += xilinx_uartps.o obj-$(CONFIG_SERIAL_SIRFSOC) += sirfsoc_uart.o obj-$(CONFIG_SERIAL_AR933X) += ar933x_uart.o obj-$(CONFIG_SERIAL_EFM32_UART) += efm32-uart.o +obj-$(CONFIG_SERIAL_ARC) += arc_uart.o diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c new file mode 100644 index 000..b65bfe4 --- /dev/null +++ b/drivers/tty/serial/arc_uart.c @@ -0,0 +1,746 @@ +/* + * ARC On-Chip(fpga) UART Driver + * + * Copyright (C) 2010-2012 Synopsys, Inc. (www.synopsys.com) + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * vineetg: July 10th 2012 + * -Decoupled the driver from arch/arc + *+Using platform_get_resource() for irq/membase (thx to bfin_uart.c) + *+Using early_platform_xxx() for early console (thx to mach-shmobile/xxx) + * + * Vineetg: Aug 21st 2010 + * -Is uart_tx_stopped() not done in tty write path as it has already been + * taken care of, in serial core + * + * Vineetg: Aug 18th 2010 + * -New Serial Core based ARC UART driver + * -Derived largely from blackfin driver albiet with some major tweaks + * + * TODO: + * -check if sysreq works + */ + +#if defined(CONFIG_SERIAL_ARC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) +#define SUPPORT_SYSRQ +#endif + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * ARC UART Hardware Specs + / +#define ARC_UART_TX_FIFO_SIZE 1 + +/* + * UART Register set (this is not a Standards Compliant IP) + * Also each reg is Word aligned, but only 8 bits wide + */ +#define R_ID0 0 +#define R_ID1 1 +#define R_ID2 2 +#define R_ID3 3 +#define R_DATA 4 +#define R_STS 5 +#define R_BAUDL6 +#define R_BAUDH7 + +/* Bits for UART Status Reg (R/W) */ +#define RXIENB 0x04 /* Receive Interrupt Enable */ +#define TXIENB 0x40 /* Transmit Interrupt Enable */ + +#define RXEMPTY 0x20 /* Receive FIFO Empty: No char receivede */ +#define TXEMPTY 0x80 /* Transmit FIFO Empty, thus char can be written into */ + +#define RXFULL 0x08 /* Receive FIFO full */ +#define RXFULL1 0x10 /* Receive FIFO has space for 1 char (tot space=4) */ + +#define RXFERR 0x01 /* Frame Error: Stop Bit not detected */ +#define RXOERR 0x02 /* OverFlow Err: Char recv but RXFULL still set */ + +/* Uart bit fiddling helpers: lowest level */ +#define RBASE(uart, reg) ((unsigned int *)uart->port.membase + reg) +#define UART_REG_SET(u, r, v) writeb((v), RBASE(u, r)) +#define UART_REG_GET(u, r)readb(RBASE(u, r)) + +#define UART_REG_OR(u, r, v) UART_REG_SET(u, r, UART_REG_GET(u, r) | (v)) +#define UART_REG_CLR(u, r, v) UART_REG_SET(u, r, UART_REG_GET(u, r) & ~(v)) + +/* Uart bit fiddling helpers: API level */ +#define UART_SET_DATA(uart, val) UART_REG_SET(uart, R_DATA, val) +#define UART_GET_DATA(uart)
Re: [PATCH v3 -tip 2/5] x86, MSI: Allocate as many multiple IRQs as requested
* Alexander Gordeev wrote: > When multiple MSIs are enabled with pci_enable_msi_block() the number of > allocated IRQs 'nvec' is rounded up to the nearest value of power of two. > That could lead to a condition when number of requested and used IRQs is > less than number of actually allocated IRQs. > > This fix introduces 'msi_desc::nvec' field to address the above issue - > when non-zero, it holds the number of allocated IRQs. Otherwise, the old > method is used. > > Signed-off-by: Alexander Gordeev > --- > arch/x86/kernel/apic/io_apic.c | 16 +++- > drivers/pci/msi.c | 10 -- > include/linux/msi.h|1 + > 3 files changed, 16 insertions(+), 11 deletions(-) This should be switched with the first patch: first extend the generic MSI code, then add x86 support for that variant. Adding multi-MSI support in one patch then tweaking it in the very next patch makes little sense and cannot possibly have been tested much so it's a potential bisection trap. Thanks, Ingo -- 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 v3 -tip 3/5] x86, MSI: Minor readability fixes
* Alexander Gordeev wrote:
> Signed-off-by: Alexander Gordeev
> ---
> arch/x86/kernel/apic/io_apic.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 84d632b..0489699 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -3123,7 +3123,7 @@ static int msi_compose_msg(struct pci_dev *pdev,
> unsigned int irq,
>
> if (irq_remapped(cfg)) {
> compose_remapped_msi_msg(pdev, irq, dest, msg, hpet_id);
> - return err;
> + return 0;
> }
>
> if (x2apic_enabled())
> @@ -3150,7 +3150,7 @@ static int msi_compose_msg(struct pci_dev *pdev,
> unsigned int irq,
> MSI_DATA_DELIVERY_LOWPRI) |
> MSI_DATA_VECTOR(cfg->vector);
>
> - return err;
> + return 0;
> }
>
> static int
> @@ -3232,7 +3232,7 @@ int setup_msix_irqs(struct pci_dev *dev, int nvec)
> list_for_each_entry(msidesc, &dev->msi_list, list) {
> irq = create_irq_nr(irq_want, node);
> if (irq == 0)
> - return -1;
> + return -ENOSPC;
> irq_want = irq + 1;
> if (!irq_remapping_enabled)
> goto no_ir;
This should be backported into earlier patches.
Thanks,
Ingo
--
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 v3 -tip 1/5] x86, MSI: Support multiple MSIs in presense of IRQ remapping
* Alexander Gordeev wrote:
> The MSI specification has several constraints in comparison with MSI-X,
> most notable of them is the inability to configure MSIs independently.
> As a result, it is impossible to dispatch interrupts from different
> queues to different CPUs. This is largely devalues the support of
> multiple MSIs in SMP systems.
>
> Also, a necessity to allocate a contiguous block of vector numbers for
> devices capable of multiple MSIs might cause a considerable pressure on
> x86 interrupt vector allocator and could lead to fragmentation of the
> interrupt vectors space.
>
> This patch overcomes both drawbacks in presense of IRQ remapping and
> lets devices take advantage of multiple queues and per-IRQ affinity
> assignments.
>
> Signed-off-by: Alexander Gordeev
> ---
> arch/x86/kernel/apic/io_apic.c | 174 +--
> include/linux/irq.h|6 ++
> kernel/irq/chip.c | 30 +--
> kernel/irq/irqdesc.c | 31 +++
> 4 files changed, 206 insertions(+), 35 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index c265593..d5cb13c 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -305,6 +305,11 @@ static int alloc_irq_from(unsigned int from, int node)
> return irq_alloc_desc_from(from, node);
> }
>
> +static int alloc_irqs_from(unsigned int from, unsigned int count, int node)
> +{
> + return irq_alloc_descs_from(from, count, node);
> +}
> +
> static void free_irq_at(unsigned int at, struct irq_cfg *cfg)
> {
> free_irq_cfg(at, cfg);
> @@ -2991,37 +2996,58 @@ device_initcall(ioapic_init_ops);
> /*
> * Dynamic irq allocate and deallocation
> */
> -unsigned int create_irq_nr(unsigned int from, int node)
> +unsigned int __create_irqs(unsigned int from, unsigned int count, int node)
> {
> - struct irq_cfg *cfg;
> + struct irq_cfg **cfg;
> unsigned long flags;
> - unsigned int ret = 0;
> - int irq;
> + int irq, i;
>
> if (from < nr_irqs_gsi)
> from = nr_irqs_gsi;
>
> - irq = alloc_irq_from(from, node);
> - if (irq < 0)
> - return 0;
> - cfg = alloc_irq_cfg(irq, node);
> - if (!cfg) {
> - free_irq_at(irq, NULL);
> + cfg = kzalloc_node(count * sizeof(cfg[0]), GFP_KERNEL, node);
> + if (!cfg)
> return 0;
> +
> + irq = alloc_irqs_from(from, count, node);
> + if (irq < 0)
> + goto out_cfgs;
> +
> + for (i = 0; i < count; i++) {
> + cfg[i] = alloc_irq_cfg(irq + i, node);
> + if (!cfg[i])
> + goto out_irqs;
> }
>
> raw_spin_lock_irqsave(&vector_lock, flags);
> - if (!__assign_irq_vector(irq, cfg, apic->target_cpus()))
> - ret = irq;
> + for (i = 0; i < count; i++)
> + if (__assign_irq_vector(irq + i, cfg[i], apic->target_cpus()))
> + goto out_vecs;
> raw_spin_unlock_irqrestore(&vector_lock, flags);
>
> - if (ret) {
> - irq_set_chip_data(irq, cfg);
> - irq_clear_status_flags(irq, IRQ_NOREQUEST);
> - } else {
> - free_irq_at(irq, cfg);
> + for (i = 0; i < count; i++) {
> + irq_set_chip_data(irq + i, cfg[i]);
> + irq_clear_status_flags(irq + i, IRQ_NOREQUEST);
> }
> - return ret;
> +
> + kfree(cfg);
> + return irq;
> +
> +out_vecs:
> + for (; i; i--)
> + __clear_irq_vector(irq + i - 1, cfg[i - 1]);
> + raw_spin_unlock_irqrestore(&vector_lock, flags);
> +out_irqs:
> + for (i = 0; i < count; i++)
> + free_irq_at(irq + i, cfg[i]);
> +out_cfgs:
> + kfree(cfg);
> + return 0;
> +}
> +
> +unsigned int create_irq_nr(unsigned int from, int node)
> +{
> + return __create_irqs(from, 1, node);
> }
>
> int create_irq(void)
> @@ -3054,6 +3080,27 @@ void destroy_irq(unsigned int irq)
> free_irq_at(irq, cfg);
> }
>
> +static inline void destroy_irqs(unsigned int irq, unsigned int count)
> +{
> + unsigned int i;
> + for (i = 0; i < count; i++)
Missing newline.
> + destroy_irq(irq + i);
> +}
> +
> +static inline int
> +can_create_pow_of_two_irqs(unsigned int from, unsigned int count)
> +{
> + if ((count > 1) && (count % 2))
> + return -EINVAL;
> +
> + for (; count; count = count / 2) {
> + if (!irq_can_alloc_irqs(from, count))
> + return count;
> + }
> +
> + return -ENOSPC;
> +}
> +
> /*
> * MSI message composition
> */
> @@ -3145,18 +3192,25 @@ static struct irq_chip msi_chip = {
> .irq_retrigger = ioapic_retrigger_irq,
> };
>
> -static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, int
> irq)
> +static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
> + unsigned int irq_base, unsig
Re: [PATCH v3 -tip 5/5] AHCI: Support multiple MSIs
On 10/02/2012 12:21 AM, Bjorn Helgaas wrote: On Mon, Oct 1, 2012 at 9:04 PM, Jeff Garzik wrote: On 10/01/2012 04:13 AM, Alexander Gordeev wrote: Take advantage of multiple MSIs implementation on x86 - on systems with IRQ remapping AHCI ports not only get assigned separate MSI vectors - but also separate IRQs. As result, interrupts generated by different ports could be serviced on different CPUs rather than on a single one. In cases when number of allocated MSIs is less than requested the Sharing Last MSI mode does not get used, no matter implemented in hardware or not. Instead, the driver assumes the advantage of multiple MSIs is negated and falls back to the single MSI mode as if MRSM bit was set (some Intel chips implement this strategy anyway - MRSM bit gets set even if the number of allocated MSIs exceeds the number of implemented ports). Signed-off-by: Alexander Gordeev --- drivers/ata/ahci.c| 91 -- drivers/ata/ahci.h|6 +++ drivers/ata/libahci.c | 118 ++--- 3 files changed, 205 insertions(+), 10 deletions(-) Acked-by: Jeff Garzik Normally, this amount of changes would -really- need to go through the libata tree. However, given the amount of dependencies, it either needs a merge tree or to go through the PCI tree...? Any maintainer comments on disposition? For what it's worth, the bulk of this change is outside PCI, so it doesn't seem to me like it should go through the PCI tree. I think I did ack the part that touched PCI, and there's not much activity in the PCI MSI area right now, so I'm fine with it going through libata or whatever people think makes sense. That works for me, too. I'm ready to queue it, if libata tree is fine with people. Jeff -- 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 00/11] x86/microcode: Early load microcode
On Mon, Oct 01, 2012 at 07:37:04PM -0400, Jamie Gloudon wrote:
> On Mon, Oct 01, 2012 at 06:27:45PM +0200, Borislav Petkov wrote:
> > On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> > > Hey,
> > >
> > > Any chance of this getting merge for the 3.7 cycle?
> >
> > It is not ready yet: http://marc.info/?l=linux-kernel&m=134910582107898
> >
> > Out of curiosity: why do you nee it?
> >
> Seems like a better alternative to microcode_ctl which some distros don't
> contain.
[ Let me reorganize the mail chain as it should be,
without top-posting. Please try not to top-post:
http://curl.haxx.se/mail/etiquette.html#Do_Not_Top_Post ]
Well,
if you want to reload your microcode, you shouldn't be needing
microcode_ctl (I believe this should be the case too on Intel, from
staring at the code - on AMD it works).
Basically, you simply put the microcode binaries into
/lib/firmware/{amd,intel}-ucode/ and then do as root:
$ echo 1 > /sys/devices/system/cpu/microcode/reload
That's it, no need for special tools.
--
Regards/Gruss,
Boris.
--
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: build failure after merge of the xen-two tree
Hi Konrad, After merging the xen-two tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/built-in.o: In function `xen_start_kernel': (.init.text+0xa88): undefined reference to `xen_acpi_notify_hypervisor_state' drivers/built-in.o: In function `dbgp_reset_prep': (.text+0x12ddeb): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0x12e6a9): undefined reference to `xen_dbgp_external_startup' I have used the xen-two tree from next-20121001 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpHsLiEh2alQ.pgp Description: PGP signature
Re: [PATCH v2 2/2] hwmon: (ads7828) add support for ADS7830
On Mon, Oct 01, 2012 at 11:28:21PM -0400, Vivien Didelot wrote:
> Hi Guenter,
>
Hi Vivien,
[ ... ]
> > > + } else {
> > > + dev_dbg(&client->dev, "doesn't look like an "
> > > + "ADS7828 compatible device\n");
> >
> > WARNING: quoted string split across lines
> > #190: FILE: drivers/hwmon/ads7828.c:196:
> > + dev_dbg(&client->dev, "doesn't look like an
> > "
> > + "ADS7828 compatible device\n");
> Hum ok, so the reason for that is that it breaks the ability to grep a
> string... Makes sense.
> >
> > Better:
> > dev_dbg(&client->dev,
> > "doesn't look like an ADS7828
> > compatible device\n");
> This exceeds 80 chars, but I'll find a shorter message.
That is ok nowadays if it is due to a quoted string.
Guenter
--
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] serial/arc-uart: Add new driver
On Friday 28 September 2012 06:32 PM, Alan Cox wrote:
>> +static void
>> +arc_serial_set_termios(struct uart_port *port, struct ktermios
>> *termios,
>> + struct ktermios *old)
>> +{
>> +struct arc_uart_port *uart = (struct arc_uart_port *)port;
>> +unsigned int baud, uartl, uarth, hw_val;
>> +unsigned long flags;
>> +
> Two things here. Firstly you want to write the actual baud back to the
> termios (tty_termios_encode_baud_rate) unless B0 is set.
>
> Secondly if you don't support hardware flow control, character size
> setting etc then you need to set those bits back so the caller knows.
> Two ways to do that. Either initialise the default termios for the tty
> type to the correct values and use tty_termios_copy_hw() or set them in
> the termios handler.
Just to give you an idea, is something on the lines of following OK for
both the above points above !
- uart_update_timeout(port, termios->c_cflag, baud);
+ new->c_cflag &= ~(CMSPAR|CRTSCTS); /* Don't care for
parity/flow ctrl */
+
+ if (old)
+ tty_termios_copy_hw(new, old);
+
+ /* Don't rewrite B0 */
+ if (tty_termios_baud_rate(new))
+ tty_termios_encode_baud_rate(new, baud, baud);
+
+ uart_update_timeout(port, new->c_cflag, baud);
Respun patch to follow shortly.
Thx,
Vineet
--
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: build failure in dwarf-regs.c
Hey Ben, Adding some people to CC... Excerpts from Ben Guthro's message of 2012-10-02 11:02:59 +1000: > I pulled the latest bits up to 797b9e5ae93270ec27a1f1ed48cd697d01b2269f - > but am seeing the following build failure with gcc 4.6.3 Building that SHA works for me (on x86, haven't tried PPC yet)... > CC arch/x86/util/dwarf-regs.o Is this correct? i.e. Are you building perf for x86? What commandline are you using to build? Any exported environment variables that may be relevant? What dev libraries does perf warn is missing (Is libdw-dev among them)? > arch/x86/util/dwarf-regs.c:72:13: error: no previous prototype for > 'get_arch_regstr' [-Werror=missing-prototypes] Hmmm... util/include/dwarf-regs.h not included? DWARF_SUPPORT undefined but still building that file for some reason? Can't see any obvious way that could happen... You didn't happen to see an warning along the lines of 'DWARF register mappings not defined for x86' did you? > `/data/home/bguthro/dev/orc-newdev.git/linux/build/tools/tools/perf' I hope the two 'tools' here is just an O= artefact? > git blame shows that line coming in from the following changeset - though > April is a long time ago in kernel time Especially when it's April from two years ago... > - so this must have come in with some other merge in this 3.7 window Seems likely, especially as (excerpt from git diff --stat v3.6 797b9e5 -- tools/perf): tools/perf/arch/x86/Makefile| 3 + tools/perf/arch/x86/include/perf_regs.h | 80 +++ tools/perf/Makefile | 173 -- I see a few changes in there that may have caused this... Since I can't reproduce this myself I can't narrow it down, so I'm adding David Ahern, Namhyung Kim & Jiri Olsa to CC who have touched lines that look like the might be relevant. Ben: You should be able to narrow down the cause of the breakage a bit more with git bisect start 797b9e5 v3.6 -- tools/perf/Makefile Cheers, -Ian -- 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/
[GIT PULL] user namespace changes for v3.7
Linus, Please pull the for-linus git tree from: git://git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: 72235465864d84cedb2d9f26f8e1de824ee20339 userns: Convert the ufs filesystem to use kuid/kgid where appropriate The tree is against v3.6-rc1 This is a mostly modest set of changes to enable basic user namespace support. This allows the code to code to compile with user namespaces enabled and removes the assumption there is only the initial user namespace. Everything is converted except for the most complex of the filesystems: autofs4, 9p, afs, ceph, cifs, coda, fuse, gfs2, ncpfs, nfs, ocfs2 and xfs as those patches need a bit more review. The strategy is to push kuid_t and kgid_t values are far down into subsystems and filesystems as reasonable. Leaving the make_kuid and from_kuid operations to happen at the edge of userspace, as the values come off the disk, and as the values come in from the network. Letting compile type incompatible compile errors (present when user namespaces are enabled) guide me to find the issues. The most tricky areas have been the places where we had an implicit union of uid and gid values and were storing them in an unsigned int. Those places were converted into explicit unions. I made certain to handle those places with simple trivial patches. Out of that work I discovered we have generic interfaces for storing quota by projid. I had never heard of the project identifiers before. Adding full user namespace support for project identifiers accounts for most of the code size growth in my git tree. Ultimately there will be work to relax privlige checks from "capable(FOO)" to "ns_capable(user_ns, FOO)" where it is safe allowing root in a user names to do those things that today we only forbid to non-root users because it will confuse suid root applications. While I was pushing kuid_t and kgid_t changes deep into the audit code I made a few other cleanups. I capitalized on the fact we process netlink messages in the context of the message sender. I removed usage of NETLINK_CRED, and started directly using current->tty. Some of these patches have also made it into maintainer trees, with no problems from identical code from different trees showing up in linux-next. After reading through all of this code I feel like I might be able to win a game of kernel trivial pursuit. Eric Dan Carpenter (1): ipv6: move dereference after check in fl_free() Eric W. Biederman (106): userns: Allow the usernamespace support to build after the removal of usbfs userns: Fix link restrictions to use uid_eq userns: Convert net/core/scm.c to use kuids and kgids userns: Convert __dev_set_promiscuity to use kuids in audit logs userns: Convert sock_i_uid to return a kuid_t userns: Allow USER_NS and NET simultaneously in Kconfig userns: Make seq_file's user namespace accessible userns: Print out socket uids in a user namespace aware fashion. userns: Use kgids for sysctl_ping_group_range net ip6 flowlabel: Make owner a union of struct pid * and kuid_t pidns: Export free_pid_ns userns: Convert net/ax25 to use kuid_t where appropriate netlink: Make the sending netlink socket availabe in NETLINK_CB userns: Implement sk_user_ns userns: Teach inet_diag to work with user namespaces userns: nfnetlink_log: Report socket uids in the log sockets user namespace net sched: Pass the skb into change so it can access NETLINK_CB userns: Convert cls_flow to work with user namespaces enabled userns: Convert xt_LOG to print socket kuids and kgids as uids and gids userns xt_recent: Specify the owner/group of ip_list_perms in the initial user namespace userns: xt_owner: Add basic user namespace support. userns: Make the airo wireless driver use kuids for proc uids and gids userns: Convert tun/tap to use kuid and kgid where appropriate userns: Enable building of pf_key sockets when user namespace support is enabled. userns: Make credential debugging user namespace safe. userns: Convert debugfs to use kuid/kgid where appropriate. userns: Convert process event connector to handle kuids and kgids userns: Convert ipc to use kuid and kgid where appropriate userns: Convert drm to use kuid and kgid and struct pid where appropriate userns: Convert security/keys to the new userns infrastructure userns: net: Call key_alloc with GLOBAL_ROOT_UID, GLOBAL_ROOT_GID instead of 0, 0 audit: Limit audit requests to processes in the initial pid and user namespaces. audit: Use current instead of NETLINK_CREDS() in audit_filter audit: kill audit_prepare_user_tty audit: Simply AUDIT_TTY_SET and AUDIT_TTY_GET audit: Properly set the origin port id of audit messages. audit: Remove the unused uid parameter from audit_receive_filter audit: Don't pass pid or
Re: [RFC v9 PATCH 16/21] memory-hotplug: free memmap of sparse-vmemmap
On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:
From: Yasuaki Ishimatsu
All pages of virtual mapping in removed memory cannot be freed, since some pages
used as PGD/PUD includes not only removed memory but also other memory. So the
patch checks whether page can be freed or not.
How to check whether page can be freed or not?
1. When removing memory, the page structs of the revmoved memory are filled
with 0FD.
2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be cleared.
In this case, the page used as PT/PMD can be freed.
Applying patch, __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is integrated
into one. So __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is deleted.
Note: vmemmap_kfree() and vmemmap_free_bootmem() are not implemented for ia64,
ppc, s390, and sparc.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
arch/ia64/mm/discontig.c |8 +++
arch/powerpc/mm/init_64.c |8 +++
arch/s390/mm/vmem.c |8 +++
arch/sparc/mm/init_64.c |8 +++
arch/x86/mm/init_64.c | 119 +
include/linux/mm.h|2 +
mm/memory_hotplug.c | 17 +--
mm/sparse.c |5 +-
8 files changed, 158 insertions(+), 17 deletions(-)
diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
index 33943db..0d23b69 100644
--- a/arch/ia64/mm/discontig.c
+++ b/arch/ia64/mm/discontig.c
@@ -823,6 +823,14 @@ int __meminit vmemmap_populate(struct page *start_page,
return vmemmap_populate_basepages(start_page, size, node);
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 3690c44..835a2b3 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -299,6 +299,14 @@ int __meminit vmemmap_populate(struct page *start_page,
return 0;
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
index eda55cd..4b42b0b 100644
--- a/arch/s390/mm/vmem.c
+++ b/arch/s390/mm/vmem.c
@@ -227,6 +227,14 @@ out:
return ret;
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index add1cc7..1384826 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2078,6 +2078,14 @@ void __meminit vmemmap_populate_print_last(void)
}
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 0075592..4e8f8a4 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1138,6 +1138,125 @@ vmemmap_populate(struct page *start_page, unsigned long
size, int node)
return 0;
}
+#define PAGE_INUSE 0xFD
+
+unsigned long find_and_clear_pte_page(unsigned long addr, unsigned long end,
+ struct page **pp, int *page_size)
+{
+ pgd_t *pgd;
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+ void *page_addr;
+ unsigned long next;
+
+ *pp = NULL;
+
+ pgd = pgd_offset_k(addr);
+ if (pgd_none(*pgd))
+ return pgd_addr_end(addr, end);
+
+ pud = pud_offset(pgd, addr);
+ if (pud_none(*pud))
+ return pud_addr_end(addr, end);
+
+ if (!cpu_has_pse) {
+ next = (addr + PAGE_SIZE) & PAGE_MASK;
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd))
+ return next;
+
+ pte = pte_offset_kernel(pmd, addr);
+ if (pte_none(*pte))
+ return next;
+
+ *page_size = PAGE_SIZE;
+ *pp = pte_page(*pte);
+ } else {
+ next = pmd_addr_end(addr, end);
+
+ pmd = pmd_offset(pud, addr)
Re: [PATCH v3 -tip 5/5] AHCI: Support multiple MSIs
On Mon, Oct 1, 2012 at 9:04 PM, Jeff Garzik wrote: > On 10/01/2012 04:13 AM, Alexander Gordeev wrote: >> >> Take advantage of multiple MSIs implementation on x86 - on systems with >> IRQ remapping AHCI ports not only get assigned separate MSI vectors - >> but also separate IRQs. As result, interrupts generated by different >> ports could be serviced on different CPUs rather than on a single one. >> >> In cases when number of allocated MSIs is less than requested the Sharing >> Last MSI mode does not get used, no matter implemented in hardware or not. >> Instead, the driver assumes the advantage of multiple MSIs is negated and >> falls back to the single MSI mode as if MRSM bit was set (some Intel chips >> implement this strategy anyway - MRSM bit gets set even if the number of >> allocated MSIs exceeds the number of implemented ports). >> >> Signed-off-by: Alexander Gordeev >> --- >> drivers/ata/ahci.c| 91 -- >> drivers/ata/ahci.h|6 +++ >> drivers/ata/libahci.c | 118 >> ++--- >> 3 files changed, 205 insertions(+), 10 deletions(-) > > > Acked-by: Jeff Garzik > > Normally, this amount of changes would -really- need to go through the > libata tree. However, given the amount of dependencies, it either needs a > merge tree or to go through the PCI tree...? > > Any maintainer comments on disposition? For what it's worth, the bulk of this change is outside PCI, so it doesn't seem to me like it should go through the PCI tree. I think I did ack the part that touched PCI, and there's not much activity in the PCI MSI area right now, so I'm fine with it going through libata or whatever people think makes sense. -- 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 xen-two tree with Linus' tree
Hi Konrad,
Today's linux-next merge of the xen-two tree got a conflict in
drivers/xen/Makefile between commit 9fa5780beea1 ("USB EHCI/Xen:
propagate controller reset information to hypervisor") from Linus' tree
and commit 13febc84849d ("xen: do not compile manage, balloon, pci, acpi,
pcpu and cpu_hotplug on ARM") from the xen-two tree.
I fixed it up (I am not sure exactly what it should depend on - see
below) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/xen/Makefile
index a4a3cab,cd28aae..000
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus
nostackp := $(call cc-option, -fno-stack-protector)
CFLAGS_features.o := $(nostackp)
+ obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
+ dom0-$(CONFIG_PCI) += pci.o
++dom0-$(CONFIG_X86) += dbgp.o
+ dom0-$(CONFIG_ACPI) += acpi.o
+ dom0-$(CONFIG_X86) += pcpu.o
obj-$(CONFIG_BLOCK) += biomerge.o
- obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
obj-$(CONFIG_XEN_XENCOMM) += xencomm.o
obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o
obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o
pgpKErJkcxuZr.pgp
Description: PGP signature
Re: [PATCH] ACPI: Add new sysfs interface to export device description
> > To address your comment, I was trying to differentiate between the existence > of the _STR method and the failure to evaluate it. > If an STR method exists, we create the sysfs file. If it fails to evaluate, we will see "No Description" when we read the file. > This would indicate that something is wrong as opposed to the system not > having an _STR. > If you feel that this is unnecessary, or should be done differently let me > know. This patch looks useful, and I this does seem like a logical place to export this information. however, I'd think that an empty attribute instead of "No description" is sufficient to cover the case of _STR existing, but for some reason failing to evaluate. thanks, Len Brown, Intel Open Source Technology Center -- 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 xen-two tree with the arm tree
Hi Konrad,
Today's linux-next merge of the xen-two tree got a conflict in
arch/arm/Kconfig between commit bd51e2f59558 ("ARM: 7506/1: allow for
ATAGS to be configured out when DT support is selected") from the arm
tree and commit eff8d6447d5f ("xen/arm: introduce CONFIG_XEN on ARM")
from the xen-two 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/Kconfig
index 7df4acc,3361466..000
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -1897,6 -1891,22 +1897,16 @@@ config CC_STACKPROTECTO
neutralized via a kernel panic.
This feature requires gcc version 4.2 or above.
-config DEPRECATED_PARAM_STRUCT
- bool "Provide old way to pass kernel parameters"
- help
-This was deprecated in 2001 and announced to live on for 5 years.
-Some old boot loaders still use this way.
-
+ config XEN_DOM0
+ def_bool y
+ depends on XEN
+
+ config XEN
+ bool "Xen guest support on ARM (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && ARM && OF
+ help
+ Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+
endmenu
menu "Boot options"
pgp8dcxrcgJU7.pgp
Description: PGP signature
linux-next: manual merge of the dt-rh tree with Linus' tree
Hi Rob,
Today's linux-next merge of the dt-rh tree got a conflict in
drivers/of/base.c include/linux/of.h between commit 3296193d1421 ("dt:
introduce for_each_available_child_of_node, of_get_next_available_child")
from Linus' tree and commit 9c19761a7ecd ("dt: introduce
of_get_child_by_name to get child node by name") from the dt-rh 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 drivers/of/base.c
index 4a8d46f,e2e8136..000
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@@ -364,33 -364,29 +364,56 @@@ struct device_node *of_get_next_child(c
EXPORT_SYMBOL(of_get_next_child);
/**
+ *of_get_next_available_child - Find the next available child node
+ *@node: parent node
+ *@prev: previous child of the parent node, or NULL to get first
+ *
+ * This function is like of_get_next_child(), except that it
+ * automatically skips any disabled nodes (i.e. status = "disabled").
+ */
+struct device_node *of_get_next_available_child(const struct device_node
*node,
+ struct device_node *prev)
+{
+ struct device_node *next;
+
+ read_lock(&devtree_lock);
+ next = prev ? prev->sibling : node->child;
+ for (; next; next = next->sibling) {
+ if (!of_device_is_available(next))
+ continue;
+ if (of_node_get(next))
+ break;
+ }
+ of_node_put(prev);
+ read_unlock(&devtree_lock);
+ return next;
+}
+EXPORT_SYMBOL(of_get_next_available_child);
+
+/**
+ *of_get_child_by_name - Find the child node by name for a given parent
+ *@node: parent node
+ *@name: child name to look for.
+ *
+ * This function looks for child node for given matching name
+ *
+ *Returns a node pointer if found, with refcount incremented, use
+ *of_node_put() on it when done.
+ *Returns NULL if node is not found.
+ */
+ struct device_node *of_get_child_by_name(const struct device_node *node,
+ const char *name)
+ {
+ struct device_node *child;
+
+ for_each_child_of_node(node, child)
+ if (child->name && (of_node_cmp(child->name, name) == 0))
+ break;
+ return child;
+ }
+ EXPORT_SYMBOL(of_get_child_by_name);
+
+ /**
*of_find_node_by_path - Find a node matching a full OF path
*@path: The full path to match
*
diff --cc include/linux/of.h
index 5c7a158,fabb524..000
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@@ -190,9 -190,8 +190,11 @@@ extern struct device_node *of_get_paren
extern struct device_node *of_get_next_parent(struct device_node *node);
extern struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev);
+extern struct device_node *of_get_next_available_child(
+ const struct device_node *node, struct device_node *prev);
+
+ extern struct device_node *of_get_child_by_name(const struct device_node
*node,
+ const char *name);
#define for_each_child_of_node(parent, child) \
for (child = of_get_next_child(parent, NULL); child != NULL; \
child = of_get_next_child(parent, child))
pgpW37k9sBScn.pgp
Description: PGP signature
[tip:x86/acpi] ACPI: Fix build when disabled
Commit-ID: 3dfd8235002727dbd759bb0f80f8ac862f392071
Gitweb: http://git.kernel.org/tip/3dfd8235002727dbd759bb0f80f8ac862f392071
Author: David Rientjes
AuthorDate: Mon, 1 Oct 2012 20:38:47 -0700
Committer: H. Peter Anvin
CommitDate: Mon, 1 Oct 2012 20:41:43 -0700
ACPI: Fix build when disabled
"ACPI: Store valid ACPI tables passed via early initrd in reserved
memblock areas" breaks the build if either CONFIG_ACPI or
CONFIG_BLK_DEV_INITRD is disabled:
arch/x86/kernel/setup.c: In function 'setup_arch':
arch/x86/kernel/setup.c:944: error: implicit declaration of function
'acpi_initrd_override'
or
arch/x86/built-in.o: In function `setup_arch':
(.init.text+0x1397): undefined reference to `initrd_start'
arch/x86/built-in.o: In function `setup_arch':
(.init.text+0x139e): undefined reference to `initrd_end'
The dummy acpi_initrd_override() function in acpi.h isn't defined without
CONFIG_ACPI and initrd_{start,end} are declared but not defined without
CONFIG_BLK_DEV_INITRD.
[ hpa: applying this as a fix, but this really should be done cleaner ]
Signed-off-by: David Rientjes
Link:
http://lkml.kernel.org/r/alpine.deb.2.00.1210012032470.31...@chino.kir.corp.google.com
Signed-off-by: H. Peter Anvin
Cc: Thomas Renninger
Cc: Len Brown
---
arch/x86/kernel/setup.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 764e543..bf82c1e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -941,7 +941,9 @@ void __init setup_arch(char **cmdline_p)
reserve_initrd();
+#if defined(CONFIG_ACPI) && defined(CONFIG_BLK_DEV_INITRD)
acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start);
+#endif
reserve_crashkernel();
--
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: CONFIG_EXPERT is a booby trap
On Sun, 30 Sep 2012, Tim Shepard wrote: > And may I suggest that CONFIG_EXPERT should be factored into two > CONFIGs, one of which makes configuration things visible, and another > which changes the default values to something more appropriate for > embedded systems (perhaps call it CONFIG_EMBEDDED_DEFAULTS). That way > you'd have to select CONFIG_EXPERT, and then select the > CONFIG_EMBEDDED_DEFAULTS option that CONFIG_EXPERT made visible to > actually change any configuration, and the documentation for > CONFIG_EMBEDDED_DEFAULTS could explain that it changes defaults > throughout the tree (and selecting CONFIG_EXPERT alone would not go off > and muck things up with no warning). > I think you can get away with changing everything that is doing "default !EXPERT" to do "default !EMBEDDED" since it's usually only done for things that are known not to be interesting for the embedded world and significantly increase the size of the kernel memory footprint. What it's really saying is to "enable it by default on everything that doesn't need to make the smallest kernel possible." Aside from that, separating CONFIG_EXPERT from CONFIG_EMBEDDED is something that has been discussed a few times and can be done when it makes clear sense and you can get consensus on the change. We always accept patches. -- 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: CONFIG_EXPERT is a booby trap
On Mon, 1 Oct 2012, Tim Shepard wrote: > Interestingly, of the 26 configs that use EXPERT in the default > clause, 15 of them are in drivers/hid (see below). > > -Tim Shepard >s...@alum.mit.edu > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > $ find . -type f -name Kconfig'*' -print | xargs fgrep default | grep EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/hid/Kconfig: default !EXPERT > ./drivers/media/common/tuners/Kconfig: default y if !EXPERT > ./drivers/media/common/tuners/Kconfig: default y if EXPERT > ./drivers/media/dvb/frontends/Kconfig: default y if EXPERT > ./drivers/media/video/Kconfig: default y if !EXPERT > ./init/Kconfig: default !EXPERT > ./lib/Kconfig.debug:default !EXPERT > ./net/rfkill/Kconfig: default y if !EXPERT > ./usr/Kconfig: default !EXPERT > ./usr/Kconfig: default !EXPERT > ./usr/Kconfig: default !EXPERT > ./usr/Kconfig: default !EXPERT I don't think selecting CONFIG_EXPERT should change whether a config option is enabled or disabled by default, I think it should only change whether certain options are available for enabling or disabling. These do need care when fixing, though, and in the above circumstances you may find that s/EXPERT/EMBEDDED/ is the right change. -- 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 x86/acpi] ACPI: Fix build when disabled
"ACPI: Store valid ACPI tables passed via early initrd in reserved
memblock areas" breaks the build if either CONFIG_ACPI or
CONFIG_BLK_DEV_INITRD is disabled:
arch/x86/kernel/setup.c: In function 'setup_arch':
arch/x86/kernel/setup.c:944: error: implicit declaration of function
'acpi_initrd_override'
or
arch/x86/built-in.o: In function `setup_arch':
(.init.text+0x1397): undefined reference to `initrd_start'
arch/x86/built-in.o: In function `setup_arch':
(.init.text+0x139e): undefined reference to `initrd_end'
The dummy acpi_initrd_override() function in acpi.h isn't defined without
CONFIG_ACPI and initrd_{start,end} are declared but not defined without
CONFIG_BLK_DEV_INITRD.
Signed-off-by: David Rientjes
---
arch/x86/kernel/setup.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -941,7 +941,9 @@ void __init setup_arch(char **cmdline_p)
reserve_initrd();
+#if defined(CONFIG_ACPI) && defined(CONFIG_BLK_DEV_INITRD)
acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start);
+#endif
reserve_crashkernel();
--
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 v5 3/3] tracing: Format non-nanosec times from tsc clock without a decimal point.
With the addition of the "tsc" clock, formatting timestamps to look like
fractional seconds is misleading. Mark clocks as either in nanoseconds or
not, and format non-nanosecond timestamps as decimal integers.
Tested:
$ cd /sys/kernel/debug/tracing/
$ cat trace_clock
[local] global tsc
$ echo sched_switch > set_event
$ echo 1 > tracing_enabled ; sleep 0.0005 ; echo 0 > tracing_enabled
$ cat trace
-0 [000] 6330.52: sched_switch: prev_comm=swapper
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964
next_prio=120
sleep-29964 [000] 6330.555628: sched_switch: prev_comm=bash
prev_pid=29964 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0
next_prio=120
...
$ echo 1 > options/latency-format
$ cat trace
-0 0 4104553247us+: sched_switch: prev_comm=swapper prev_pid=0
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964 next_prio=120
sleep-29964 0 4104553322us+: sched_switch: prev_comm=bash prev_pid=29964
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
...
$ echo tsc > trace_clock
$ cat trace
$ echo 1 > tracing_enabled ; sleep 0.0005 ; echo 0 > tracing_enabled
$ echo 0 > options/latency-format
$ cat trace
-0 [000] 16490053398357: sched_switch: prev_comm=swapper
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128
next_prio=120
sleep-31128 [000] 16490053588518: sched_switch: prev_comm=bash
prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0
next_prio=120
...
echo 1 > options/latency-format
$ cat trace
-0 0 91557653238+: sched_switch: prev_comm=swapper prev_pid=0
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128 next_prio=120
sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
...
v2:
Move arch-specific bits out of generic code.
v4:
Fix x86_32 build due to 64-bit division.
Google-Bug-Id: 6980623
Signed-off-by: David Sharp
Cc: Steven Rostedt
Cc: Masami Hiramatsu
---
arch/x86/include/asm/trace_clock.h |2 +-
include/linux/ftrace_event.h |6 +++
kernel/trace/trace.c | 15 +-
kernel/trace/trace.h |4 --
kernel/trace/trace_output.c| 81 +---
5 files changed, 75 insertions(+), 33 deletions(-)
diff --git a/arch/x86/include/asm/trace_clock.h
b/arch/x86/include/asm/trace_clock.h
index 7ee0d8c..45e17f5 100644
--- a/arch/x86/include/asm/trace_clock.h
+++ b/arch/x86/include/asm/trace_clock.h
@@ -9,7 +9,7 @@
extern u64 notrace trace_clock_x86_tsc(void);
# define ARCH_TRACE_CLOCKS \
- { trace_clock_x86_tsc, "x86-tsc" },
+ { trace_clock_x86_tsc, "x86-tsc", .in_ns = 0 },
#endif
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 642928c..c760670 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -86,6 +86,12 @@ struct trace_iterator {
cpumask_var_t started;
};
+enum trace_iter_flags {
+ TRACE_FILE_LAT_FMT = 1,
+ TRACE_FILE_ANNOTATE = 2,
+ TRACE_FILE_TIME_IN_NS = 4,
+};
+
struct trace_event;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 4e26df3..cff3427 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -476,10 +476,11 @@ static const char *trace_options[] = {
static struct {
u64 (*func)(void);
const char *name;
+ int in_ns; /* is this clock in nanoseconds? */
} trace_clocks[] = {
- { trace_clock_local,"local" },
- { trace_clock_global, "global" },
- { trace_clock_counter, "counter" },
+ { trace_clock_local,"local",1 },
+ { trace_clock_global, "global", 1 },
+ { trace_clock_counter, "counter", 0 },
ARCH_TRACE_CLOCKS
};
@@ -2425,6 +2426,10 @@ __tracing_open(struct inode *inode, struct file *file)
if (ring_buffer_overruns(iter->tr->buffer))
iter->iter_flags |= TRACE_FILE_ANNOTATE;
+ /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+ if (trace_clocks[trace_clock_id].in_ns)
+ iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
+
/* stop the trace while dumping */
tracing_stop();
@@ -3324,6 +3329,10 @@ static int tracing_open_pipe(struct inode *inode, struct
file *filp)
if (trace_flags & TRACE_ITER_LATENCY_FMT)
iter->iter_flags |= TRACE_FILE_LAT_FMT;
+ /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+ if (trace_clocks[trace_clock_id].in_ns)
+ iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
+
iter->cpu_file = cpu_file;
iter->tr = &global_trace;
mutex_init(&iter->mutex);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 55e1f7f..84fefed 100644
--- a/kernel/trace/
[PATCH v5 2/3] tracing: Reset ring buffer when changing trace_clocks
Because the "tsc" clock isn't in nanoseconds, the ring buffer must be reset when changing clocks so that incomparable timestamps don't end up in the same trace. Tested: Confirmed switching clocks resets the trace buffer. Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt Cc: Masami Hiramatsu --- kernel/trace/trace.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 92fb08e..4e26df3 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -4012,6 +4012,14 @@ static ssize_t tracing_clock_write(struct file *filp, const char __user *ubuf, if (max_tr.buffer) ring_buffer_set_clock(max_tr.buffer, trace_clocks[i].func); + /* +* New clock may not be consistent with the previous clock. +* Reset the buffer so that it doesn't have incomparable timestamps. +*/ + tracing_reset_online_cpus(&global_trace); + if (max_tr.buffer) + tracing_reset_online_cpus(&max_tr); + mutex_unlock(&trace_types_lock); *fpos += cnt; -- 1.7.7.3 -- 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 v5 1/3] tracing,x86: Add a TSC trace_clock
In order to promote interoperability between userspace tracers and ftrace, add a trace_clock that reports raw TSC values which will then be recorded in the ring buffer. Userspace tracers that also record TSCs are then on exactly the same time base as the kernel and events can be unambiguously interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups Google-Bug-Id: 6980623 Signed-off-by: David Sharp Cc: Steven Rostedt Cc: Masami Hiramatsu Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Acked-by: Ingo Molnar --- arch/alpha/include/asm/trace_clock.h |6 ++ arch/arm/include/asm/trace_clock.h|6 ++ arch/avr32/include/asm/trace_clock.h |6 ++ arch/blackfin/include/asm/trace_clock.h |6 ++ arch/c6x/include/asm/trace_clock.h|6 ++ arch/cris/include/asm/trace_clock.h |6 ++ arch/frv/include/asm/trace_clock.h|6 ++ arch/h8300/include/asm/trace_clock.h |6 ++ arch/hexagon/include/asm/trace_clock.h|6 ++ arch/ia64/include/asm/trace_clock.h |6 ++ arch/m32r/include/asm/trace_clock.h |6 ++ arch/m68k/include/asm/trace_clock.h |6 ++ arch/microblaze/include/asm/trace_clock.h |6 ++ arch/mips/include/asm/trace_clock.h |6 ++ arch/mn10300/include/asm/trace_clock.h|6 ++ arch/openrisc/include/asm/trace_clock.h |6 ++ arch/parisc/include/asm/trace_clock.h |6 ++ arch/powerpc/include/asm/trace_clock.h|6 ++ arch/s390/include/asm/trace_clock.h |6 ++ arch/score/include/asm/trace_clock.h |6 ++ arch/sh/include/asm/trace_clock.h |6 ++ arch/sparc/include/asm/trace_clock.h |6 ++ arch/tile/include/asm/trace_clock.h |6 ++ arch/um/include/asm/trace_clock.h |6 ++ arch/unicore32/include/asm/trace_clock.h |6 ++ arch/x86/include/asm/trace_clock.h| 16 arch/x86/kernel/Makefile |1 + arch/x86/kernel/trace_clock.c | 21 + arch/xtensa/include/asm/trace_clock.h |6 ++ include/asm-generic/trace_clock.h | 16 include/linux/trace_clock.h |2 ++ kernel/trace/trace.c |1 + 32 files changed, 213 insertions(+), 0 deletions(-) create mode 100644 arch/alpha/include/asm/trace_clock.h create mode 100644 arch/arm/include/asm/trace_clock.h create mode 100644 arch/avr32/include/asm/trace_clock.h create mode 100644 arch/blackfin/include/asm/trace_clock.h create mode 100644 arch/c6x/include/asm/trace_clock.h create mode 100644 arch/cris/include/asm/trace_clock.h create mode 100644 arch/frv/include/asm/trace_clock.h create mode 100644 arch/h8300/include/asm/trace_clock.h create mode 100644 arch/hexagon/include/asm/trace_clock.h create mode 100644 arch/ia64/include/asm/trace_clock.h create mode 100644 arch/m32r/include/asm/trace_clock.h create mode 100644 arch/m68k/include/asm/trace_clock.h create mode 100644 arch/microblaze/include/asm/trace_clock.h create mode 100644 arch/mips/include/asm/trace_clock.h create mode 100644 arch/mn10300/include/asm/trace_clock.h create mode 100644 arch/openrisc/include/asm/trace_clock.h create mode 100644 arch/parisc/include/asm/trace_clock.h create mode 100644 arch/powerpc/include/asm/trace_clock.h create mode 100644 arch/s390/include/asm/trace_clock.h create mode 100644 arch/score/include/asm/trace_clock.h create mode 100644 arch/sh/include/asm/trace_clock.h create mode 100644 arch/sparc/include/asm/trace_clock.h create mode 100644 arch/tile/include/asm/trace_clock.h create mode 100644 arch/um/include/asm/trace_clock.h create mode 100644 arch/unicore32/include/asm/trace_clock.h create mode 100644 arch/x86/include/asm/trace_clock.h create mode 100644 arch/x86/kernel/trace_clock.c create mode 100644 arch/xtensa/include/asm/trace_clock.h create mode 100644 include/asm-generic/trace_clock.h diff --git a/arch/alpha/include/asm/trace_clock.h b/arch/alpha/include/asm/trace_clock.h new file mode 100644 index 000..f35fab8 --- /dev/null +++ b/arch/alpha/include/asm/trace_clock.h @@ -0,0 +1,6 @@ +#ifndef _ASM_TRACE_CLOCK_H +#define _ASM_TRACE_CLOCK_H + +#include + +#endif diff --git a/arch/arm/include/asm/trace_clock.h b/arch/arm/include/asm/trace_clock.h new file mode 100644 index 000..f35fab8 --- /dev/null +++ b/arch/arm/include/asm/trace_clock.h @@ -0,0 +1,6 @@ +#ifndef _ASM_TRACE_CLOCK_H +#define _ASM_TRACE_CLOCK_H + +#include + +#endif diff --git a/arch/avr32/include/asm/trace_clock.h b/arch/avr32/include/asm/trace_clock.h new file mode 100644 index 000..f35fab8 --- /dev/null +++ b/arch/avr32/include/asm/trace_clock.h @@ -0,0 +1,6 @@ +#ifndef _ASM_TRACE_C
Re: [PATCH v2 2/2] hwmon: (ads7828) add support for ADS7830
Hi Guenter,
On Mon, 2012-10-01 at 18:20 -0700, Guenter Roeck wrote:
> On Mon, Oct 01, 2012 at 07:16:24PM -0400, Vivien Didelot wrote:
> > From: Guillaume Roguez
> >
> > The ADS7830 device is almost the same as the ADS7828,
> > except that it does 8-bit sampling, instead of 12-bit.
> > This patch extends the ads7828 driver to support this chip.
> >
> > Signed-off-by: Guillaume Roguez
> > Signed-off-by: Vivien Didelot
>
> Hi Guillaume,
> Hi Vivien,
>
> couple of comments below.
>
> > ---
> > Documentation/hwmon/ads7828 | 12 --
> > drivers/hwmon/Kconfig | 7 +++---
> > drivers/hwmon/ads7828.c | 58
> > -
> > 3 files changed, 55 insertions(+), 22 deletions(-)
> >
> > diff --git a/Documentation/hwmon/ads7828 b/Documentation/hwmon/ads7828
> > index 2bbebe6..4366a87 100644
> > --- a/Documentation/hwmon/ads7828
> > +++ b/Documentation/hwmon/ads7828
> > @@ -8,8 +8,15 @@ Supported chips:
> > Datasheet: Publicly available at the Texas Instruments website :
> > http://focus.ti.com/lit/ds/symlink/ads7828.pdf
> >
> > + * Texas Instruments ADS7830
> > +Prefix: 'ads7830'
> > +Addresses scanned: I2C 0x48, 0x49, 0x4a, 0x4b
> > +Datasheet: Publicly available at the Texas Instruments website:
> > + http://focus.ti.com/lit/ds/symlink/ads7830.pdf
> > +
> > Authors:
> > Steve Hardy
> > +Guillaume Roguez
> >
> > Module Parameters
> > -
> > @@ -24,9 +31,10 @@ Module Parameters
> > Description
> > ---
> >
> > -This driver implements support for the Texas Instruments ADS7828.
> > +This driver implements support for the Texas Instruments ADS7828, and
> > ADS7830.
> >
>
> s/,//
Sounds like an abuse of the serial comma :-)
>
> > -This device is a 12-bit 8-channel A-D converter.
> > +The ADS7828 device is a 12-bit 8-channel A/D converter, while the ADS7830
> > does
> > +8-bit sampling.
> >
> > It can operate in single ended mode (8 +ve inputs) or in differential mode,
> > where 4 differential pairs can be measured.
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 83e3e9d..960c8c5 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -1060,11 +1060,12 @@ config SENSORS_ADS1015
> > will be called ads1015.
> >
> > config SENSORS_ADS7828
> > - tristate "Texas Instruments ADS7828"
> > + tristate "Texas Instruments ADS7828 and compatibles"
> > depends on I2C
> > help
> > - If you say yes here you get support for Texas Instruments ADS7828
> > - 12-bit 8-channel ADC device.
> > + If you say yes here you get support for Texas Instruments ADS7828 and
> > + ADS7830 8-channel A/D converters. ADS7828 resolution is 12-bit, while
> > + it is 8-bit on ADS7830.
> >
> > This driver can also be built as a module. If so, the module
> > will be called ads7828.
> > diff --git a/drivers/hwmon/ads7828.c b/drivers/hwmon/ads7828.c
> > index fb3010d..91fc629 100644
> > --- a/drivers/hwmon/ads7828.c
> > +++ b/drivers/hwmon/ads7828.c
> > @@ -1,11 +1,13 @@
> > /*
> > - * ads7828.c - lm_sensors driver for ads7828 12-bit 8-channel ADC
> > + * ads7828.c - driver for TI ADS7828 8-channel A/D converter and
> > compatibles
> > * (C) 2007 EADS Astrium
> > *
> > * This driver is based on the lm75 and other lm_sensors/hwmon drivers
> > *
> > * Written by Steve Hardy
> > *
> > + * ADS7830 support by Guillaume Roguez
> >
> > + *
> > * For further information, see the Documentation/hwmon/ads7828 file.
> > *
> > * This program is free software; you can redistribute it and/or modify
> > @@ -41,6 +43,9 @@
> > #define ADS7828_CMD_PD30x0C/* Internal ref ON && A/D ON */
> > #define ADS7828_INT_VREF_MV2500/* Internal vref is 2.5V,
> > 2500mV */
> >
> > +/* List of supported devices */
> > +enum ads7828_chips { ads7828, ads7830 };
> > +
> > /* Addresses to scan */
> > static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
> > I2C_CLIENT_END };
> > @@ -53,9 +58,7 @@ module_param(se_input, bool, S_IRUGO);
> > module_param(int_vref, bool, S_IRUGO);
> > module_param(vref_mv, int, S_IRUGO);
> >
> > -/* Global Variables */
> > static u8 ads7828_cmd_byte; /* cmd byte without channel bits */
>
> At some point we may have to look into the configuration ... using module
> parameters doesn't seem to be right here. Should be platform data or device
> tree. But that is for later ... just something to keep in mind.
>
> > -static unsigned int ads7828_lsb_resol; /* resolution of the ADC sample lsb
> > */
> >
> > /**
> > * struct ads7828_data - client specific data
> > @@ -64,6 +67,8 @@ static unsigned int ads7828_lsb_resol; /* resolution of
> > the ADC sample lsb */
> > * @valid: Validity flag.
> > * @last_updated: Last updated time (in jiffies).
> > * @adc_input: ADS7828_NCH samples.
> > + * @lsb_re
Re: [PATCH v2] slab: Ignore internal flags in cache creation
On Mon, 1 Oct 2012, Glauber Costa wrote: > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 9c21725..f2682ee 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -107,6 +107,15 @@ struct kmem_cache *kmem_cache_create(const char *name, > size_t size, size_t align > if (!kmem_cache_sanity_check(name, size) == 0) > goto out_locked; > > + /* > + * Some allocators will constraint the set of valid flags to a subset > + * of all flags. We expect them to define CACHE_CREATE_MASK in this > + * case, and we'll just provide them with a sanitized version of the > + * passed flags. > + */ > +#ifdef CACHE_CREATE_MASK > + flags &= ~CACHE_CREATE_MASK; > +#endif > > s = __kmem_cache_alias(name, size, align, flags, ctor); > if (s) flags &= CACHE_CREATE_MASK After that's done: Acked-by: David Rientjes Thanks for working through this. -- 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 v3 -tip 5/5] AHCI: Support multiple MSIs
On 10/01/2012 04:13 AM, Alexander Gordeev wrote: Take advantage of multiple MSIs implementation on x86 - on systems with IRQ remapping AHCI ports not only get assigned separate MSI vectors - but also separate IRQs. As result, interrupts generated by different ports could be serviced on different CPUs rather than on a single one. In cases when number of allocated MSIs is less than requested the Sharing Last MSI mode does not get used, no matter implemented in hardware or not. Instead, the driver assumes the advantage of multiple MSIs is negated and falls back to the single MSI mode as if MRSM bit was set (some Intel chips implement this strategy anyway - MRSM bit gets set even if the number of allocated MSIs exceeds the number of implemented ports). Signed-off-by: Alexander Gordeev --- drivers/ata/ahci.c| 91 -- drivers/ata/ahci.h|6 +++ drivers/ata/libahci.c | 118 ++--- 3 files changed, 205 insertions(+), 10 deletions(-) Acked-by: Jeff Garzik Normally, this amount of changes would -really- need to go through the libata tree. However, given the amount of dependencies, it either needs a merge tree or to go through the PCI tree...? Any maintainer comments on disposition? Jeff -- 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: [GIT PULL 0/12] ARM: soc: updates for 3.7, first batch
* Olof Johansson [121001 19:36]: > On Mon, Oct 01, 2012 at 07:22:34PM -0700, Linus Torvalds wrote: > > > Anyway, you should double-check the merges, the "soc.h" one in > > particular is suspect. > > Yes, my bad for not remembering to move the tag forward. The patch is below. Thanks, the current head is building just fine for omaps with that fix. Regards, Tony -- 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] hwmon: (ads7828) driver cleanup
On Mon, Oct 01, 2012 at 10:16:07PM -0400, Vivien Didelot wrote: > Hi Guenter, > [ ... ] > > > > > > -/* Each client has this additional data */ > > > +/** > > > + * struct ads7828_data - client specific data > > > + * @hwmon_dev: The hwmon device. > > > + * @update_lock: Mutex protecting updates. > > > + * @valid: Validity flag. > > > + * @last_updated:Last updated time (in jiffies). > > > + * @adc_input: ADS7828_NCH samples. > > > + */ > > This isn't really an externally visible API, so I wonder if it provides > > value to > > document it this way. No strong opinion, just wondering. > I found the version below a bit cluttered, that's why I used the > KernelDoc notation. Would you prefer something else, like right-aligned > comments? Tab aligned, maybe ? Not sure if that works out, though. Guenter -- 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: [ 094/127] md: make sure metadata is updated when spares are activated or removed.
On Fri, 28 Sep 2012 16:57:45 -0700 Greg Kroah-Hartman wrote: > On Sat, Sep 29, 2012 at 12:51:04AM +0200, Ben Hutchings wrote: > > On Fri, 2012-09-28 at 13:34 -0700, Greg Kroah-Hartman wrote: > > > 3.0-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: NeilBrown > > > > > > commit 6dafab6b1383e912cd252fa809570b484eb6e0dc upstream. > > [...] > > > This is suitable for -stable as out-of-data metadata could lead > > > to data corruption. > > > This is only relevant for 3.3 and later 9when 'replacement' as > > > introduced. > > [...] > > > > Assuming Neil hasn't changed his mind about this, it should therefore > > not be applied to 3.0. > > Neil, is this true? > > greg k-h Yes it is true - my bad. I should have realised that when you pointed out that the backport wasn't clean. The patch won't hurt 3.0, but it isn't necessary at all, so best leave it out. Thanks, NeilBrown signature.asc Description: PGP signature
[PATCH] net: ethernet: davinci_cpdma: decrease the desc count when cleaning up the remaining packets
chan->count is used by rx channel. If the desc count is not updated by the clean up loop in cpdma_chan_stop, the value written to the rxfree register in cpdma_chan_start will be incorrect. Signed-off-by: Tao Hou --- drivers/net/ethernet/ti/davinci_cpdma.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c index d15c888..4995673 100644 --- a/drivers/net/ethernet/ti/davinci_cpdma.c +++ b/drivers/net/ethernet/ti/davinci_cpdma.c @@ -863,6 +863,7 @@ int cpdma_chan_stop(struct cpdma_chan *chan) next_dma = desc_read(desc, hw_next); chan->head = desc_from_phys(pool, next_dma); + chan->count--; chan->stats.teardown_dequeue++; /* issue callback without locks held */ -- 1.7.9.5 -- 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: [GIT PULL 0/12] ARM: soc: updates for 3.7, first batch
On Mon, Oct 01, 2012 at 07:26:26PM -0700, Linus Torvalds wrote: > On Mon, Oct 1, 2012 at 7:22 PM, Linus Torvalds > wrote: > > > > Ok, I've merged them all. As usual, my end result is slightly > > different from yours, although the differences are pretty small. > > Oh, one more thing: I suspect the OMAP_OCP2SCP config option should > depend on CONFIG_ARM or something. Just based on the name, I assume it > doesn't actually work on x86-64, but I see the question.. Ah, yes. It should build fine and not cause breakage, but it's largely pointless to offer the option. Patch below. -Olof >From 5ae0b658cc10af29d7a0a66f2a412a754011ca0e Mon Sep 17 00:00:00 2001 From: Olof Johansson Date: Mon, 1 Oct 2012 19:39:33 -0700 Subject: [PATCH] drivers/bus: make ocp2scp depend on OMAP2+ No use in enabling the driver on platforms where it won't be useful. Signed-off-by: Olof Johansson Cc: Tony Lindgren --- drivers/bus/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index bbec35d..0f51ed6 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -6,6 +6,7 @@ menu "Bus devices" config OMAP_OCP2SCP tristate "OMAP OCP2SCP DRIVER" + depends on ARCH_OMAP2PLUS help Driver to enable ocp2scp module which transforms ocp interface protocol to scp protocol. In OMAP4, USB PHY is connected via -- 1.7.10.1.488.g05fbf7a -- 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: [GIT PULL 0/12] ARM: soc: updates for 3.7, first batch
On Mon, Oct 1, 2012 at 7:22 PM, Linus Torvalds wrote: > > Ok, I've merged them all. As usual, my end result is slightly > different from yours, although the differences are pretty small. Oh, one more thing: I suspect the OMAP_OCP2SCP config option should depend on CONFIG_ARM or something. Just based on the name, I assume it doesn't actually work on x86-64, but I see the question.. Linus -- 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: [GIT PULL 0/12] ARM: soc: updates for 3.7, first batch
Hi,
On Mon, Oct 01, 2012 at 07:22:34PM -0700, Linus Torvalds wrote:
> On Mon, Oct 1, 2012 at 4:56 PM, Olof Johansson wrote:
> >
> > Here is the first batch of pull requests for arm-soc for this merge
> > window. Some of them are tiny, and we will probably start to combine
> > them into slightly larger misc branches in the future. I didn't do it
> > this time around since the dependencies between branches ended up quite
> > complex this time around.
>
> Ok, I've merged them all. As usual, my end result is slightly
> different from yours, although the differences are pretty small.
Thanks!
> - I added exynos4210-trats.dtb to the "dtb-$(CONFIG_ARCH_EXYNOS)"
> case in arch/arm/boot/dts/Makefile
>
>That seemed to be the right thing, otherwise that dtb file isn't
> actually accessed from anything. Hmm?
Hmm. I know I did that edit. I've had cases where git rerere has forgotten
about edits to "new" files that were not part of the original conflict, and
I might have replayed that merge and lost it there. Thanks for catching it.
> - Commit dbc04161048d ("ARM: OMAP: Split plat/hardware.h, use local
> soc.h for omap2+") added the line
>
> #include "soc.h"
>
>to arch/arm/mach-omap2/omap_l3_noc.c, and I left it in as it moved
> into drivers/bus/.
>
>My resolution is quite possibly wrong, but I didn't know what the
> right thing to do was. Please double-check.
I had a patch for this but I forgot to move the tag to include it, my local
branch with the resolutions has it since I used the branch head, not the tag,
to merge it.
The SHA is a55eb3ec0e38e2db17207b204c050fbcdf750abb. Or the patch is included
below if that's easier.
> - non-semantic order/whitespace difference for
> CONFIG_CLKSRC_ARM_GENERIC in drivers/clocksource/Makefile.
>
>I didn't want to mix the generic case up with the random cases.
Yes, makes sense, thanks. I wonder if the file should be sorted to reduce
conflicts on new additions soon anyway, maybe.
> Anyway, you should double-check the merges, the "soc.h" one in
> particular is suspect.
Yes, my bad for not remembering to move the tag forward. The patch is below.
Thanks!
-Olof
>From a55eb3ec0e38e2db17207b204c050fbcdf750abb Mon Sep 17 00:00:00 2001
From: Olof Johansson
Date: Thu, 20 Sep 2012 16:14:25 -0700
Subject: [PATCH] drivers: bus: omap_l3: fixup merge conflict resolution
This fixes a local merge conflict resolution done wrong locally in
arm-soc for-next. soc.h was added on a cleanup branch, but the driver
was moved and the header no longer needed.
Signed-off-by: Olof Johansson
---
arch/arm/mach-omap2/omap_l3_noc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index f447e02..4f8f3cf 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -28,7 +28,6 @@
#include
#include
-#include "soc.h"
#include "omap_l3_noc.h"
/*
--
1.7.10.1.488.g05fbf7a
--
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/4] mfd: 88pm860x: use irqdomain
On Sat, Sep 29, 2012 at 7:28 AM, Samuel Ortiz wrote: > Hi Haojian: > > On Fri, Sep 21, 2012 at 06:06:51PM +0800, Haojian Zhuang wrote: >> @@ -593,13 +610,9 @@ static int __devinit device_irq_init(struct pm860x_chip >> *chip, >> : chip->companion; >> unsigned char status_buf[INT_STATUS_NUM]; >> unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT; >> - int i, data, mask, ret = -EINVAL; > That one breaks the build: > > drivers/mfd/88pm860x-core.c: In function ‘device_irq_init’: > drivers/mfd/88pm860x-core.c:628:7: error: ‘i’ undeclared (first use in this > function) > drivers/mfd/88pm860x-core.c:628:7: note: each undeclared identifier is > reported only once for each function it appears in > drivers/mfd/88pm860x-core.c:629:3: error: ‘__irq’ undeclared (first use in > this function) > make[2]: *** [drivers/mfd/88pm860x-core.o] Error 1 > > I removed this patchset until it builds... > I'm sorry for inconvenience. Now fix it. Regards Haojian -- 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: [GIT PULL 0/12] ARM: soc: updates for 3.7, first batch
On Mon, Oct 1, 2012 at 4:56 PM, Olof Johansson wrote:
>
> Here is the first batch of pull requests for arm-soc for this merge
> window. Some of them are tiny, and we will probably start to combine
> them into slightly larger misc branches in the future. I didn't do it
> this time around since the dependencies between branches ended up quite
> complex this time around.
Ok, I've merged them all. As usual, my end result is slightly
different from yours, although the differences are pretty small.
- I added exynos4210-trats.dtb to the "dtb-$(CONFIG_ARCH_EXYNOS)"
case in arch/arm/boot/dts/Makefile
That seemed to be the right thing, otherwise that dtb file isn't
actually accessed from anything. Hmm?
- Commit dbc04161048d ("ARM: OMAP: Split plat/hardware.h, use local
soc.h for omap2+") added the line
#include "soc.h"
to arch/arm/mach-omap2/omap_l3_noc.c, and I left it in as it moved
into drivers/bus/.
My resolution is quite possibly wrong, but I didn't know what the
right thing to do was. Please double-check.
- non-semantic order/whitespace difference for
CONFIG_CLKSRC_ARM_GENERIC in drivers/clocksource/Makefile.
I didn't want to mix the generic case up with the random cases.
Anyway, you should double-check the merges, the "soc.h" one in
particular is suspect.
Linus
--
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] mfd: 88pm860x: use irqdomain
Use irqdomain and allocating interrupts. It's necessary for supporting
DT mode.
Signed-off-by: Haojian Zhuang
---
drivers/mfd/88pm860x-core.c | 65 +--
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index 72bf290..5b56fe8 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -520,15 +521,12 @@ static void pm860x_irq_sync_unlock(struct irq_data *data)
static void pm860x_irq_enable(struct irq_data *data)
{
- struct pm860x_chip *chip = irq_data_get_irq_chip_data(data);
- pm860x_irqs[data->irq - chip->irq_base].enable
- = pm860x_irqs[data->irq - chip->irq_base].offs;
+ pm860x_irqs[data->hwirq].enable = pm860x_irqs[data->hwirq].offs;
}
static void pm860x_irq_disable(struct irq_data *data)
{
- struct pm860x_chip *chip = irq_data_get_irq_chip_data(data);
- pm860x_irqs[data->irq - chip->irq_base].enable = 0;
+ pm860x_irqs[data->hwirq].enable = 0;
}
static struct irq_chip pm860x_irq_chip = {
@@ -539,6 +537,25 @@ static struct irq_chip pm860x_irq_chip = {
.irq_disable= pm860x_irq_disable,
};
+static int pm860x_irq_domain_map(struct irq_domain *d, unsigned int virq,
+irq_hw_number_t hw)
+{
+ irq_set_chip_data(virq, d->host_data);
+ irq_set_chip_and_handler(virq, &pm860x_irq_chip, handle_edge_irq);
+ irq_set_nested_thread(virq, 1);
+#ifdef CONFIG_ARM
+ set_irq_flags(virq, IRQF_VALID);
+#else
+ irq_set_noprobe(virq);
+#endif
+ return 0;
+}
+
+static struct irq_domain_ops pm860x_irq_domain_ops = {
+ .map= pm860x_irq_domain_map,
+ .xlate = irq_domain_xlate_onetwocell,
+};
+
static int __devinit device_gpadc_init(struct pm860x_chip *chip,
struct pm860x_platform_data *pdata)
{
@@ -593,13 +610,9 @@ static int __devinit device_irq_init(struct pm860x_chip
*chip,
: chip->companion;
unsigned char status_buf[INT_STATUS_NUM];
unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
- int i, data, mask, ret = -EINVAL;
- int __irq;
-
- if (!pdata || !pdata->irq_base) {
- dev_warn(chip->dev, "No interrupt support on IRQ base\n");
- return -EINVAL;
- }
+ int data, mask, ret = -EINVAL;
+ int nr_irqs, irq_base = -1;
+ struct device_node *node = i2c->dev.of_node;
mask = PM8607_B0_MISC1_INV_INT | PM8607_B0_MISC1_INT_CLEAR
| PM8607_B0_MISC1_INT_MASK;
@@ -639,25 +652,23 @@ static int __devinit device_irq_init(struct pm860x_chip
*chip,
goto out;
mutex_init(&chip->irq_lock);
- chip->irq_base = pdata->irq_base;
+
+ if (pdata && pdata->irq_base)
+ irq_base = pdata->irq_base;
+ nr_irqs = ARRAY_SIZE(pm860x_irqs);
+ chip->irq_base = irq_alloc_descs(irq_base, 0, nr_irqs, 0);
+ if (chip->irq_base < 0) {
+ dev_err(&i2c->dev, "Failed to allocate interrupts, ret:%d\n",
+ chip->irq_base);
+ ret = -EBUSY;
+ goto out;
+ }
+ irq_domain_add_legacy(node, nr_irqs, chip->irq_base, 0,
+ &pm860x_irq_domain_ops, chip);
chip->core_irq = i2c->irq;
if (!chip->core_irq)
goto out;
- /* register IRQ by genirq */
- for (i = 0; i < ARRAY_SIZE(pm860x_irqs); i++) {
- __irq = i + chip->irq_base;
- irq_set_chip_data(__irq, chip);
- irq_set_chip_and_handler(__irq, &pm860x_irq_chip,
-handle_edge_irq);
- irq_set_nested_thread(__irq, 1);
-#ifdef CONFIG_ARM
- set_irq_flags(__irq, IRQF_VALID);
-#else
- irq_set_noprobe(__irq);
-#endif
- }
-
ret = request_threaded_irq(chip->core_irq, NULL, pm860x_irq, flags |
IRQF_ONESHOT,
"88pm860x", chip);
if (ret) {
--
1.7.9.5
--
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] hwmon: (ads7828) driver cleanup
Hi Guenter,
On Mon, 2012-10-01 at 18:07 -0700, Guenter Roeck wrote:
> On Mon, Oct 01, 2012 at 07:16:23PM -0400, Vivien Didelot wrote:
> > * Remove unused macros;
> > * Point to the documentation;
> > * Coding Style fixes (Kernel Doc, spacing);
> > * Move driver declaration to avoid adding function prototypes.
> >
> > Signed-off-by: Vivien Didelot
>
> Hi Vivien,
>
> > ---
> > drivers/hwmon/ads7828.c | 91
> > +++--
> > 1 file changed, 43 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/hwmon/ads7828.c b/drivers/hwmon/ads7828.c
> > index bf3fdf4..fb3010d 100644
> > --- a/drivers/hwmon/ads7828.c
> > +++ b/drivers/hwmon/ads7828.c
> > @@ -6,7 +6,7 @@
> > *
> > * Written by Steve Hardy
> > *
> > - * Datasheet available at: http://focus.ti.com/lit/ds/symlink/ads7828.pdf
> > + * For further information, see the Documentation/hwmon/ads7828 file.
> > *
> > * This program is free software; you can redistribute it and/or modify
> > * it under the terms of the GNU General Public License as published by
> > @@ -34,14 +34,12 @@
> > #include
> >
> > /* The ADS7828 registers */
> > -#define ADS7828_NCH 8 /* 8 channels of 12-bit A-D supported */
> > -#define ADS7828_CMD_SD_SE 0x80 /* Single ended inputs */
> > -#define ADS7828_CMD_SD_DIFF 0x00 /* Differential inputs */
> > -#define ADS7828_CMD_PD0 0x0 /* Power Down between A-D conversions */
> > -#define ADS7828_CMD_PD1 0x04 /* Internal ref OFF && A-D ON */
> > -#define ADS7828_CMD_PD2 0x08 /* Internal ref ON && A-D OFF */
> > -#define ADS7828_CMD_PD3 0x0C /* Internal ref ON && A-D ON */
> > -#define ADS7828_INT_VREF_MV 2500 /* Internal vref is 2.5V, 2500mV */
> > +#define ADS7828_NCH8 /* 8 channels supported */
> > +#define ADS7828_CMD_SD_SE 0x80/* Single ended inputs */
> > +#define ADS7828_CMD_SD_DIFF0x00/* Differential inputs */
> > +#define ADS7828_CMD_PD10x04/* Internal ref OFF && A/D ON */
> > +#define ADS7828_CMD_PD30x0C/* Internal ref ON && A/D ON */
> > +#define ADS7828_INT_VREF_MV2500/* Internal vref is 2.5V,
> > 2500mV */
> >
> > /* Addresses to scan */
> > static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
> > @@ -59,25 +57,26 @@ module_param(vref_mv, int, S_IRUGO);
> > static u8 ads7828_cmd_byte; /* cmd byte without channel bits */
> > static unsigned int ads7828_lsb_resol; /* resolution of the ADC sample lsb
> > */
> >
> > -/* Each client has this additional data */
> > +/**
> > + * struct ads7828_data - client specific data
> > + * @hwmon_dev: The hwmon device.
> > + * @update_lock: Mutex protecting updates.
> > + * @valid: Validity flag.
> > + * @last_updated: Last updated time (in jiffies).
> > + * @adc_input: ADS7828_NCH samples.
> > + */
> This isn't really an externally visible API, so I wonder if it provides value
> to
> document it this way. No strong opinion, just wondering.
I found the version below a bit cluttered, that's why I used the
KernelDoc notation. Would you prefer something else, like right-aligned
comments?
>
> > struct ads7828_data {
> > struct device *hwmon_dev;
> > - struct mutex update_lock; /* mutex protect updates */
> > - char valid; /* !=0 if following fields are valid */
> > - unsigned long last_updated; /* In jiffies */
> > - u16 adc_input[ADS7828_NCH]; /* ADS7828_NCH 12-bit samples */
> > + struct mutex update_lock;
> > + char valid;
> > + unsigned long last_updated;
> > + u16 adc_input[ADS7828_NCH];
> > };
> >
> > -/* Function declaration - necessary due to function dependencies */
> > -static int ads7828_detect(struct i2c_client *client,
> > - struct i2c_board_info *info);
> > -static int ads7828_probe(struct i2c_client *client,
> > -const struct i2c_device_id *id);
> > -
> > static inline u8 channel_cmd_byte(int ch)
> > {
> > /* cmd byte C2,C1,C0 - see datasheet */
> > - u8 cmd = (((ch>>1) | (ch&0x01)<<2)<<4);
> > + u8 cmd = (((ch >> 1) | (ch & 0x01) << 2) << 4);
> > cmd |= ads7828_cmd_byte;
> > return cmd;
> > }
> > @@ -120,9 +119,8 @@ static ssize_t show_in(struct device *dev, struct
> > device_attribute *da,
> > ads7828_lsb_resol)/1000);
>
> Can you fix this one as well since you are at it ? There is another one in
> sensors_ads7828_init().
> [ Wonder why checkpatch doesn't complain about it ]
Sure.
>
> > }
> >
> > -#define in_reg(offset)\
> > -static SENSOR_DEVICE_ATTR(in##offset##_input, S_IRUGO, show_in,\
> > - NULL, offset)
> > +#define in_reg(offset) \
> > +static SENSOR_DEVICE_ATTR(in##offset##_input, S_IRUGO, show_in, NULL,
> > offset)
> >
> This causes a checkpatch error - checkpatch doesn't like the multi-line
> macros.
My bad, I'm on a 2.6.37 box, I didn't checkout the upstream version of
checkpatch.pl too.
>
> > in_reg(0);
> > in_reg(1);
>
> Since it seems to be hardly worth i
[PATCHv2] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
TPM_STARTUP has not been issued. Detect this and automatically
issue TPM_STARTUP.
This is for embedded applications where the kernel is the first thing
to touch the TPM.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm.c | 43 +++
drivers/char/tpm/tpm.h |6 ++
2 files changed, 45 insertions(+), 4 deletions(-)
changes in v2:
- Created a tpm_startup function as per Kent's comment
- Fixed the TPM_ST_* constants to be 16 bit
- Provide ST_STATE and ST_DEACTIVATED constants for future users
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 817f0ee..5d79093 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -473,7 +473,7 @@ static ssize_t transmit_cmd(struct tpm_chip *chip, struct
tpm_cmd_t *cmd,
return -EFAULT;
err = be32_to_cpu(cmd->header.out.return_code);
- if (err != 0)
+ if (err != 0 && desc)
dev_err(chip->dev, "A TPM error (%d) occurred %s\n", err, desc);
return err;
@@ -489,6 +489,16 @@ static const struct tpm_input_header tpm_getcap_header = {
.ordinal = TPM_ORD_GET_CAP
};
+#define TPM_ORD_STARTUP cpu_to_be32(153)
+#define TPM_ST_CLEAR cpu_to_be16(1)
+#define TPM_ST_STATE cpu_to_be16(2)
+#define TPM_ST_DEACTIVATED cpu_to_be16(3)
+static const struct tpm_input_header tpm_startup_header = {
+ .tag = TPM_TAG_RQU_COMMAND,
+ .length = cpu_to_be32(12),
+ .ordinal = TPM_ORD_STARTUP
+};
+
ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, cap_t *cap,
const char *desc)
{
@@ -532,6 +542,15 @@ void tpm_gen_interrupt(struct tpm_chip *chip)
}
EXPORT_SYMBOL_GPL(tpm_gen_interrupt);
+static int tpm_startup(struct tpm_chip *chip, __be16 startup_type)
+{
+ struct tpm_cmd_t start_cmd;
+ start_cmd.header.in = tpm_startup_header;
+ start_cmd.params.startup_in.startup_type = startup_type;
+ return transmit_cmd(chip, &start_cmd, TPM_INTERNAL_RESULT_SIZE,
+ "attempting to start the TPM");
+}
+
int tpm_get_timeouts(struct tpm_chip *chip)
{
struct tpm_cmd_t tpm_cmd;
@@ -545,11 +564,27 @@ int tpm_get_timeouts(struct tpm_chip *chip)
tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+ rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, 0);
- rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
- "attempting to determine the timeouts");
- if (rc)
+ if (rc == TPM_ERR_INVALID_POSTINIT) {
+ /* The TPM is not started, we are the first to talk to it.
+ Execute a startup command. */
+ dev_info(chip->dev, "Issuing TPM_STARTUP");
+ if (tpm_startup(chip, TPM_ST_CLEAR))
+ return rc;
+
+ tpm_cmd.header.in = tpm_getcap_header;
+ tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+ tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+ tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+ rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, 0);
+ }
+ if (rc) {
+ dev_err(chip->dev,
+ "A TPM error (%d) occurred attempting to determine the
timeouts\n",
+ rc);
goto duration;
+ }
if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
be32_to_cpu(tpm_cmd.header.out.length)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 917f727..2d583ef 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -41,6 +41,7 @@ enum tpm_addr {
#define TPM_WARN_DOING_SELFTEST 0x802
#define TPM_ERR_DEACTIVATED 0x6
#define TPM_ERR_DISABLED0x7
+#define TPM_ERR_INVALID_POSTINIT 38
#define TPM_HEADER_SIZE10
extern ssize_t tpm_show_pubek(struct device *, struct device_attribute *attr,
@@ -269,6 +270,10 @@ struct tpm_pcrextend_in {
u8 hash[TPM_DIGEST_SIZE];
}__attribute__((packed));
+struct tpm_startup_in {
+ __be16 startup_type;
+} __packed;
+
typedef union {
struct tpm_getcap_params_out getcap_out;
struct tpm_readpubek_params_out readpubek_out;
@@ -277,6 +282,7 @@ typedef union {
struct tpm_pcrread_in pcrread_in;
struct tpm_pcrread_out pcrread_out;
struct tpm_pcrextend_in pcrextend_in;
+ struct tpm_startup_in startup_in;
} tpm_cmd_params;
struct tpm_cmd_t {
--
1.7.4.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/
[PATCH 7/7] aoe: update aoe-internal version number to 50
Signed-off-by: Ed Cashin --- drivers/block/aoe/aoe.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h index c2bf797..d2ed7f1 100644 --- a/drivers/block/aoe/aoe.h +++ b/drivers/block/aoe/aoe.h @@ -1,5 +1,5 @@ /* Copyright (c) 2012 Coraid, Inc. See COPYING for GPL terms. */ -#define VERSION "49" +#define VERSION "50" #define AOE_MAJOR 152 #define DEVICE_NAME "aoe" -- 1.7.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/
[PATCH 6/7] aoe: update documentation to better reflect aoe-plus-udev usage
Signed-off-by: Ed Cashin
---
Documentation/aoe/aoe.txt| 49 +++--
Documentation/aoe/mkdevs.sh | 41 ---
Documentation/aoe/mkshelf.sh | 28
Documentation/aoe/status.sh |3 ++
4 files changed, 35 insertions(+), 86 deletions(-)
delete mode 100644 Documentation/aoe/mkdevs.sh
delete mode 100644 Documentation/aoe/mkshelf.sh
diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt
index b3e4756..bfc9cb1 100644
--- a/Documentation/aoe/aoe.txt
+++ b/Documentation/aoe/aoe.txt
@@ -1,3 +1,8 @@
+ATA over Ethernet is a network protocol that provides simple access to
+block storage on the LAN.
+
+ http://support.coraid.com/documents/AoEr11.txt
+
The EtherDrive (R) HOWTO for 2.6 and 3.x kernels is found at ...
http://support.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html
@@ -26,20 +31,12 @@ CREATING DEVICE NODES
There is a udev-install.sh script that shows how to install these
rules on your system.
- If you are not using udev, two scripts are provided in
- Documentation/aoe as examples of static device node creation for
- using the aoe driver.
-
-rm -rf /dev/etherd
-sh Documentation/aoe/mkdevs.sh /dev/etherd
-
- ... or to make just one shelf's worth of block device nodes ...
-
-sh Documentation/aoe/mkshelf.sh /dev/etherd 0
-
There is also an autoload script that shows how to edit
/etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when
- necessary.
+ necessary. Preloading the aoe module is preferable to autoloading,
+ however, because AoE discovery takes a few seconds. It can be
+ confusing when an AoE device is not present the first time the a
+ command is run but appears a second later.
USING DEVICE NODES
@@ -54,9 +51,9 @@ USING DEVICE NODES
"echo > /dev/etherd/discover" tells the driver to find out what AoE
devices are available.
- These character devices may disappear and be replaced by sysfs
- counterparts. Using the commands in aoetools insulates users from
- these implementation details.
+ In the future these character devices may disappear and be replaced
+ by sysfs counterparts. Using the commands in aoetools insulates
+ users from these implementation details.
The block devices are named like this:
@@ -79,8 +76,8 @@ USING SYSFS
The netif attribute is the network interface on the localhost
through which we are communicating with the remote AoE device.
- There is a script in this directory that formats this information
- in a convenient way. Users with aoetools can use the aoe-stat
+ There is a script in this directory that formats this information in
+ a convenient way. Users with aoetools should use the aoe-stat
command.
root@makki root# sh Documentation/aoe/status.sh
@@ -124,3 +121,21 @@ DRIVER OPTIONS
usage example for the module parameter.
modprobe aoe_iflist="eth1 eth3"
+
+ The aoe_deadsecs module parameter determines the maximum number of
+ seconds that the driver will wait for an AoE device to provide a
+ response to an AoE command. After aoe_deadsecs seconds have
+ elapsed, the AoE device will be marked as "down".
+
+ The aoe_maxout module parameter has a default of 128. This is the
+ maximum number of unresponded packets that will be sent to an AoE
+ target at one time.
+
+ The aoe_dyndevs module parameter defaults to 1, meaning that the
+ driver will assign a block device minor number to a discovered AoE
+ target based on the order of its discovery. With dynamic minor
+ device numbers in use, a greater range of AoE shelf and slot
+ addresses can be supported. Users with udev will never have to
+ think about minor numbers. Using aoe_dyndevs=0 allows device nodes
+ to be pre-created using a static minor-number scheme with the
+ aoe-mkshelf script in the aoetools.
diff --git a/Documentation/aoe/mkdevs.sh b/Documentation/aoe/mkdevs.sh
deleted file mode 100644
index 44c0ab7..000
--- a/Documentation/aoe/mkdevs.sh
+++ /dev/null
@@ -1,41 +0,0 @@
-#!/bin/sh
-
-n_shelves=${n_shelves:-10}
-n_partitions=${n_partitions:-16}
-
-if test "$#" != "1"; then
- echo "Usage: sh `basename $0` {dir}" 1>&2
- echo " n_partitions=16 sh `basename $0` {dir}" 1>&2
- exit 1
-fi
-dir=$1
-
-MAJOR=152
-
-echo "Creating AoE devnode files in $dir ..."
-
-set -e
-
-mkdir -p $dir
-
-# (Status info is in sysfs. See status.sh.)
-# rm -f $dir/stat
-# mknod -m 0400 $dir/stat c $MAJOR 1
-rm -f $dir/err
-mknod -m 0400 $dir/err c $MAJOR 2
-rm -f $dir/discover
-mknod -m 0200 $dir/discover c $MAJOR 3
-rm -f $dir/interfaces
-mknod -m 0200 $dir/interfaces c $MAJOR 4
-rm -f $dir/revalidate
-mknod -m 0200 $dir/revalidate c $MAJOR 5
-rm -f $dir/flush
-mknod -m 0200 $dir/flush c $MAJOR 6
-
-export n_partitions
-mkshelf=`echo $0 | sed 's!mkdevs!mkshelf!'`
-i=0
-while test $i -lt $n_shelves; do
- sh -xc "sh $mkshelf $dir $i"
- i=`expr $i + 1`
-done
diff -
RE: [PATCH net,1/3] hyperv: Fix the max_xfer_size in RNDIS initialization
> From: David Miller [da...@davemloft.net] > Sent: Monday, October 01, 2012 6:39 PM > To: Haiyang Zhang > Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de; > jasow...@redhat.com; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org > Subject: Re: [PATCH net,1/3] hyperv: Fix the max_xfer_size in RNDIS > initialization > These patches do not apply cleanly to the current net-next tree > which is the only place where patches should be targetted right > now. I will rebase the patch set to the net-next tree soon. Thanks, - Haiyang -- 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 5/7] aoe: remove unused code
Signed-off-by: Ed Cashin
---
drivers/block/aoe/aoe.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index 4ae2468..c2bf797 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -10,9 +10,6 @@
#define AOE_PARTITIONS (16)
#endif
-#define SYSMINOR(aoemajor, aoeminor) ((aoemajor) * NPERSHELF + (aoeminor))
-#define AOEMAJOR(sysminor) ((sysminor) / NPERSHELF)
-#define AOEMINOR(sysminor) ((sysminor) % NPERSHELF)
#define WHITESPACE " \t\v\f\n"
enum {
@@ -82,7 +79,6 @@ enum {
enum {
DEFAULTBCNT = 2 * 512, /* 2 sectors */
- NPERSHELF = 16, /* number of slots per shelf address */
MIN_BUFS = 16,
NTARGETS = 8,
NAOEIFS = 8,
--
1.7.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/
[PATCH 4/7] aoe: make dynamic block minor numbers the default
Because udev use is so widespread, making the old static mapping the default is too conservative, given the severe limitations it places on usable AoE addresses. Storage virtualization and larger shelves have made the old limitations too confining. These changes make the dynamic block device minor numbers the default, removing the limitations on usable AoE addresses. The static arrangement is still available with aoe_dyndevs=0, and the aoe-stat tool from the userland aoetools package, the user space counterpart to the aoe driver, recognizes the case where there is a mismatch between the minor number in sysfs and the minor number in a special device file. Signed-off-by: Ed Cashin --- drivers/block/aoe/aoedev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/block/aoe/aoedev.c b/drivers/block/aoe/aoedev.c index 3d494fd..90e5b53 100644 --- a/drivers/block/aoe/aoedev.c +++ b/drivers/block/aoe/aoedev.c @@ -19,7 +19,7 @@ static void aoedev_freedev(struct aoedev *); static void freetgt(struct aoedev *d, struct aoetgt *t); static void skbpoolfree(struct aoedev *d); -static int aoe_dyndevs; +static int aoe_dyndevs = 1; module_param(aoe_dyndevs, int, 0644); MODULE_PARM_DESC(aoe_dyndevs, "Use dynamic minor numbers for devices."); -- 1.7.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/
[PATCH 3/7] aoe: update and specify AoE address guards and error messages
In general, specific is better when it comes to messages about
AoE usage problems. Also, explicit checks for the AoE broadcast
addresses are added.
Signed-off-by: Ed Cashin
---
drivers/block/aoe/aoe.h|2 --
drivers/block/aoe/aoecmd.c | 17 +++--
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index 7b694f7..4ae2468 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -49,8 +49,6 @@ struct aoe_hdr {
__be32 tag;
};
-#define AOE_MAXSHELF (0x-1)/* one less than the broadcast shelf
address */
-
struct aoe_atahdr {
unsigned char aflags;
unsigned char errfeat;
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 94e810c..3804a0a 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -1349,15 +1349,14 @@ aoecmd_cfg_rsp(struct sk_buff *skb)
"Check shelf dip switches.\n");
return;
}
- if (aoemajor > AOE_MAXSHELF) {
- pr_info("aoe: e%ld.%d: shelf number too large\n",
+ if (aoemajor == 0x) {
+ pr_info("aoe: e%ld.%d: broadcast shelf number invalid\n",
aoemajor, (int) h->minor);
return;
}
-
- d = aoedev_by_aoeaddr(aoemajor, h->minor, 1);
- if (d == NULL) {
- pr_info("aoe: device allocation failure\n");
+ if (h->minor == 0xff) {
+ pr_info("aoe: e%ld.%d: broadcast slot number invalid\n",
+ aoemajor, (int) h->minor);
return;
}
@@ -1365,6 +1364,12 @@ aoecmd_cfg_rsp(struct sk_buff *skb)
if (n > aoe_maxout) /* keep it reasonable */
n = aoe_maxout;
+ d = aoedev_by_aoeaddr(aoemajor, h->minor, 1);
+ if (d == NULL) {
+ pr_info("aoe: device allocation failure\n");
+ return;
+ }
+
spin_lock_irqsave(&d->lock, flags);
t = gettgt(d, h->src);
--
1.7.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/
[PATCH 2/7] aoe: retain static block device numbers for backwards compatibility
The old mapping between AoE target shelf and slot addresses and
the block device minor number is retained as a
backwards-compatible feature, with a new "aoe_dyndevs" module
parameter available for enabling dynamic block device minor
numbers.
Signed-off-by: Ed Cashin
---
drivers/block/aoe/aoedev.c | 54 +--
1 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/block/aoe/aoedev.c b/drivers/block/aoe/aoedev.c
index 68a7a5a..3d494fd 100644
--- a/drivers/block/aoe/aoedev.c
+++ b/drivers/block/aoe/aoedev.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "aoe.h"
static void dummy_timer(ulong);
@@ -18,6 +19,10 @@ static void aoedev_freedev(struct aoedev *);
static void freetgt(struct aoedev *d, struct aoetgt *t);
static void skbpoolfree(struct aoedev *d);
+static int aoe_dyndevs;
+module_param(aoe_dyndevs, int, 0644);
+MODULE_PARM_DESC(aoe_dyndevs, "Use dynamic minor numbers for devices.");
+
static struct aoedev *devlist;
static DEFINE_SPINLOCK(devlist_lock);
@@ -34,7 +39,7 @@ static DEFINE_SPINLOCK(used_minors_lock);
static DECLARE_BITMAP(used_minors, N_DEVS);
static int
-minor_get(ulong *minor)
+minor_get_dyn(ulong *sysminor)
{
ulong flags;
ulong n;
@@ -48,10 +53,53 @@ minor_get(ulong *minor)
error = -1;
spin_unlock_irqrestore(&used_minors_lock, flags);
- *minor = n * AOE_PARTITIONS;
+ *sysminor = n * AOE_PARTITIONS;
return error;
}
+static int
+minor_get_static(ulong *sysminor, ulong aoemaj, int aoemin)
+{
+ ulong flags;
+ ulong n;
+ int error = 0;
+ enum {
+ /* for backwards compatibility when !aoe_dyndevs,
+* a static number of supported slots per shelf */
+ NPERSHELF = 16,
+ };
+
+ n = aoemaj * NPERSHELF + aoemin;
+ if (aoemin >= NPERSHELF || n >= N_DEVS) {
+ pr_err("aoe: %s with e%ld.%d\n",
+ "cannot use static minor device numbers",
+ aoemaj, aoemin);
+ error = -1;
+ } else {
+ spin_lock_irqsave(&used_minors_lock, flags);
+ if (test_bit(n, used_minors)) {
+ pr_err("aoe: %s %lu\n",
+ "existing device already has static minor
number",
+ n);
+ error = -1;
+ } else
+ set_bit(n, used_minors);
+ spin_unlock_irqrestore(&used_minors_lock, flags);
+ }
+
+ *sysminor = n;
+ return error;
+}
+
+static int
+minor_get(ulong *sysminor, ulong aoemaj, int aoemin)
+{
+ if (aoe_dyndevs)
+ return minor_get_dyn(sysminor);
+ else
+ return minor_get_static(sysminor, aoemaj, aoemin);
+}
+
static void
minor_free(ulong minor)
{
@@ -293,7 +341,7 @@ aoedev_by_aoeaddr(ulong maj, int min, int do_alloc)
d->ref++;
break;
}
- if (d || !do_alloc || minor_get(&sysminor) < 0)
+ if (d || !do_alloc || minor_get(&sysminor, maj, min) < 0)
goto out;
d = kcalloc(1, sizeof *d, GFP_ATOMIC);
if (!d)
--
1.7.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/
[PATCH 1/7] aoe: support more AoE addresses with dynamic block device minor numbers
The ATA over Ethernet protocol uses a major (shelf) and
minor (slot) address to identify a particular storage target.
These changes remove an artificial limitation the aoe driver
imposes on the use of AoE addresses. For example, without these
changes, the slot address has a maximum of 15, but users commonly
use slot numbers much greater than that.
The AoE shelf and slot address space is often used sparsely.
Instead of using a static mapping between AoE addresses and the
block device minor number, the block device minor numbers are now
allocated on demand.
Signed-off-by: Ed Cashin
---
drivers/block/aoe/aoe.h|6 ++--
drivers/block/aoe/aoeblk.c |2 +-
drivers/block/aoe/aoechr.c |2 +-
drivers/block/aoe/aoecmd.c | 25 -
drivers/block/aoe/aoedev.c | 86 ++--
5 files changed, 72 insertions(+), 49 deletions(-)
diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index 27d0a21..7b694f7 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -49,6 +49,8 @@ struct aoe_hdr {
__be32 tag;
};
+#define AOE_MAXSHELF (0x-1)/* one less than the broadcast shelf
address */
+
struct aoe_atahdr {
unsigned char aflags;
unsigned char errfeat;
@@ -211,8 +213,7 @@ void aoe_ktstop(struct ktstate *k);
int aoedev_init(void);
void aoedev_exit(void);
-struct aoedev *aoedev_by_aoeaddr(int maj, int min);
-struct aoedev *aoedev_by_sysminor_m(ulong sysminor);
+struct aoedev *aoedev_by_aoeaddr(ulong maj, int min, int do_alloc);
void aoedev_downdev(struct aoedev *d);
int aoedev_flush(const char __user *str, size_t size);
void aoe_failbuf(struct aoedev *, struct buf *);
@@ -223,4 +224,3 @@ void aoenet_exit(void);
void aoenet_xmit(struct sk_buff_head *);
int is_aoe_netif(struct net_device *ifp);
int set_aoe_iflist(const char __user *str, size_t size);
-
diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
index 83160ab..00dfc50 100644
--- a/drivers/block/aoe/aoeblk.c
+++ b/drivers/block/aoe/aoeblk.c
@@ -249,7 +249,7 @@ aoeblk_gdalloc(void *vp)
q->queuedata = d;
d->gd = gd;
gd->major = AOE_MAJOR;
- gd->first_minor = d->sysminor * AOE_PARTITIONS;
+ gd->first_minor = d->sysminor;
gd->fops = &aoe_bdops;
gd->private_data = d;
set_capacity(gd, d->ssize);
diff --git a/drivers/block/aoe/aoechr.c b/drivers/block/aoe/aoechr.c
index deb30c1..ed57a89 100644
--- a/drivers/block/aoe/aoechr.c
+++ b/drivers/block/aoe/aoechr.c
@@ -91,7 +91,7 @@ revalidate(const char __user *str, size_t size)
pr_err("aoe: invalid device specification %s\n", buf);
return -EINVAL;
}
- d = aoedev_by_aoeaddr(major, minor);
+ d = aoedev_by_aoeaddr(major, minor, 0);
if (!d)
return -EINVAL;
spin_lock_irqsave(&d->lock, flags);
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 39dacdb..94e810c 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -1149,7 +1149,7 @@ aoecmd_ata_rsp(struct sk_buff *skb)
h = (struct aoe_hdr *) skb->data;
aoemajor = be16_to_cpu(get_unaligned(&h->major));
- d = aoedev_by_aoeaddr(aoemajor, h->minor);
+ d = aoedev_by_aoeaddr(aoemajor, h->minor, 0);
if (d == NULL) {
snprintf(ebuf, sizeof ebuf, "aoecmd_ata_rsp: ata response "
"for unknown device %d.%d\n",
@@ -1330,7 +1330,7 @@ aoecmd_cfg_rsp(struct sk_buff *skb)
struct aoe_hdr *h;
struct aoe_cfghdr *ch;
struct aoetgt *t;
- ulong flags, sysminor, aoemajor;
+ ulong flags, aoemajor;
struct sk_buff *sl;
struct sk_buff_head queue;
u16 n;
@@ -1349,18 +1349,15 @@ aoecmd_cfg_rsp(struct sk_buff *skb)
"Check shelf dip switches.\n");
return;
}
- if (h->minor >= NPERSHELF) {
- pr_err("aoe: e%ld.%d %s, %d\n",
- aoemajor, h->minor,
- "slot number larger than the maximum",
- NPERSHELF-1);
+ if (aoemajor > AOE_MAXSHELF) {
+ pr_info("aoe: e%ld.%d: shelf number too large\n",
+ aoemajor, (int) h->minor);
return;
}
- sysminor = SYSMINOR(aoemajor, h->minor);
- if (sysminor * AOE_PARTITIONS + AOE_PARTITIONS > MINORMASK) {
- printk(KERN_INFO "aoe: e%ld.%d: minor number too large\n",
- aoemajor, (int) h->minor);
+ d = aoedev_by_aoeaddr(aoemajor, h->minor, 1);
+ if (d == NULL) {
+ pr_info("aoe: device allocation failure\n");
return;
}
@@ -1368,12 +1365,6 @@ aoecmd_cfg_rsp(struct sk_buff *skb)
if (n > aoe_maxout) /* keep it reasonable */
n = aoe_maxout;
- d = aoedev_by_sysminor_m(sysminor);
- if (d == NULL) {
-
linux-next: manual merge of the net-next tree with Linus' tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
Documentation/feature-removal-schedule.txt between commit 9c0ece069b32
("Get rid of Documentation/feature-removal.txt") from Linus' tree and
commits 965505015bec ("netfilter: remove xt_NOTRACK") and 7b55279f6a45
("NFC: Remove the pn544 raw driver") from the net-next tree.
I removed the file and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpIigYByvmjh.pgp
Description: PGP signature
linux-next: build failure after merge of the acpi tree
Hi Len,
After merging the acpi tree, today's linux-next build (x86_64_allmodconfig)
failed like this:
drivers/usb/core/usb-acpi.c: In function 'usb_acpi_check_port_connect_type':
drivers/usb/core/usb-acpi.c:90:18: error: storage size of 'pld' isn't known
Caused by commit 05f916894a69 ("usb/acpi: Store info on device
removability") from Linus' tree interacting with commit 8ede06aba5df
("ACPI: Use ACPICA native way to decode the PLD buffer") from the acpi
tree.
I applied this merge fix that I have been applying to the usb tree (which
has now been merged by Linus).
From: Stephen Rothwell
Date: Mon, 24 Sep 2012 16:51:38 +1000
Subject: [PATCH] usb-acpi: Comply with the ACPI API change after usb tree merge
Signed-off-by: Stephen Rothwell
---
drivers/usb/core/usb-acpi.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 0ef7d42..e9b159a 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -87,7 +87,7 @@ static int usb_acpi_check_port_connect_type(struct usb_device
*hdev,
acpi_status status;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *upc;
- struct acpi_pld pld;
+ struct acpi_pld_info *pld;
int ret = 0;
/*
@@ -111,13 +111,13 @@ static int usb_acpi_check_port_connect_type(struct
usb_device *hdev,
}
if (upc->package.elements[0].integer.value)
- if (pld.user_visible)
+ if (pld->user_visible)
usb_set_hub_port_connect_type(hdev, port1,
USB_PORT_CONNECT_TYPE_HOT_PLUG);
else
usb_set_hub_port_connect_type(hdev, port1,
USB_PORT_CONNECT_TYPE_HARD_WIRED);
- else if (!pld.user_visible)
+ else if (!pld->user_visible)
usb_set_hub_port_connect_type(hdev, port1, USB_PORT_NOT_USED);
out:
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpInAZvF9q1Q.pgp
Description: PGP signature
Re: [RFC v9 PATCH 01/21] memory-hotplug: rename remove_memory() to offline_memory()/offline_pages()
Hi Kosaki-san, 2012/09/29 7:15, KOSAKI Motohiro wrote: On Thu, Sep 27, 2012 at 11:50 PM, Yasuaki Ishimatsu wrote: Hi Chen, 2012/09/28 11:22, Ni zhan Chen wrote: On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote: From: Yasuaki Ishimatsu remove_memory() only try to offline pages. It is called in two cases: 1. hot remove a memory device 2. echo offline >/sys/devices/system/memory/memoryXX/state In the 1st case, we should also change memory block's state, and notify the userspace that the memory block's state is changed after offlining pages. So rename remove_memory() to offline_memory()/offline_pages(). And in the 1st case, offline_memory() will be used. The function offline_memory() is not implemented. In the 2nd case, offline_pages() will be used. But this time there is not a function associated with add_memory. To associate with add_memory() later, we renamed it. Then, you introduced bisect breakage. It is definitely unacceptable. What is "bisect breakage" meaning? Thanks, Yasuaki Ishimatsu NAK. -- 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/2] hwmon: (ads7828) add support for ADS7830
On Mon, Oct 01, 2012 at 07:16:24PM -0400, Vivien Didelot wrote:
> From: Guillaume Roguez
>
> The ADS7830 device is almost the same as the ADS7828,
> except that it does 8-bit sampling, instead of 12-bit.
> This patch extends the ads7828 driver to support this chip.
>
> Signed-off-by: Guillaume Roguez
> Signed-off-by: Vivien Didelot
Hi Guillaume,
Hi Vivien,
couple of comments below.
> ---
> Documentation/hwmon/ads7828 | 12 --
> drivers/hwmon/Kconfig | 7 +++---
> drivers/hwmon/ads7828.c | 58
> -
> 3 files changed, 55 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/hwmon/ads7828 b/Documentation/hwmon/ads7828
> index 2bbebe6..4366a87 100644
> --- a/Documentation/hwmon/ads7828
> +++ b/Documentation/hwmon/ads7828
> @@ -8,8 +8,15 @@ Supported chips:
> Datasheet: Publicly available at the Texas Instruments website :
> http://focus.ti.com/lit/ds/symlink/ads7828.pdf
>
> + * Texas Instruments ADS7830
> +Prefix: 'ads7830'
> +Addresses scanned: I2C 0x48, 0x49, 0x4a, 0x4b
> +Datasheet: Publicly available at the Texas Instruments website:
> + http://focus.ti.com/lit/ds/symlink/ads7830.pdf
> +
> Authors:
> Steve Hardy
> +Guillaume Roguez
>
> Module Parameters
> -
> @@ -24,9 +31,10 @@ Module Parameters
> Description
> ---
>
> -This driver implements support for the Texas Instruments ADS7828.
> +This driver implements support for the Texas Instruments ADS7828, and
> ADS7830.
>
s/,//
> -This device is a 12-bit 8-channel A-D converter.
> +The ADS7828 device is a 12-bit 8-channel A/D converter, while the ADS7830
> does
> +8-bit sampling.
>
> It can operate in single ended mode (8 +ve inputs) or in differential mode,
> where 4 differential pairs can be measured.
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 83e3e9d..960c8c5 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1060,11 +1060,12 @@ config SENSORS_ADS1015
> will be called ads1015.
>
> config SENSORS_ADS7828
> - tristate "Texas Instruments ADS7828"
> + tristate "Texas Instruments ADS7828 and compatibles"
> depends on I2C
> help
> - If you say yes here you get support for Texas Instruments ADS7828
> - 12-bit 8-channel ADC device.
> + If you say yes here you get support for Texas Instruments ADS7828 and
> + ADS7830 8-channel A/D converters. ADS7828 resolution is 12-bit, while
> + it is 8-bit on ADS7830.
>
> This driver can also be built as a module. If so, the module
> will be called ads7828.
> diff --git a/drivers/hwmon/ads7828.c b/drivers/hwmon/ads7828.c
> index fb3010d..91fc629 100644
> --- a/drivers/hwmon/ads7828.c
> +++ b/drivers/hwmon/ads7828.c
> @@ -1,11 +1,13 @@
> /*
> - * ads7828.c - lm_sensors driver for ads7828 12-bit 8-channel ADC
> + * ads7828.c - driver for TI ADS7828 8-channel A/D converter and compatibles
> * (C) 2007 EADS Astrium
> *
> * This driver is based on the lm75 and other lm_sensors/hwmon drivers
> *
> * Written by Steve Hardy
> *
> + * ADS7830 support by Guillaume Roguez
>
> + *
> * For further information, see the Documentation/hwmon/ads7828 file.
> *
> * This program is free software; you can redistribute it and/or modify
> @@ -41,6 +43,9 @@
> #define ADS7828_CMD_PD3 0x0C/* Internal ref ON && A/D ON */
> #define ADS7828_INT_VREF_MV 2500/* Internal vref is 2.5V, 2500mV */
>
> +/* List of supported devices */
> +enum ads7828_chips { ads7828, ads7830 };
> +
> /* Addresses to scan */
> static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
> I2C_CLIENT_END };
> @@ -53,9 +58,7 @@ module_param(se_input, bool, S_IRUGO);
> module_param(int_vref, bool, S_IRUGO);
> module_param(vref_mv, int, S_IRUGO);
>
> -/* Global Variables */
> static u8 ads7828_cmd_byte; /* cmd byte without channel bits */
At some point we may have to look into the configuration ... using module
parameters doesn't seem to be right here. Should be platform data or device
tree. But that is for later ... just something to keep in mind.
> -static unsigned int ads7828_lsb_resol; /* resolution of the ADC sample lsb */
>
> /**
> * struct ads7828_data - client specific data
> @@ -64,6 +67,8 @@ static unsigned int ads7828_lsb_resol; /* resolution of the
> ADC sample lsb */
> * @valid: Validity flag.
> * @last_updated:Last updated time (in jiffies).
> * @adc_input: ADS7828_NCH samples.
> + * @lsb_resol: Resolution of the A/D converter sample LSB.
> + * @read_channel:Function used to read a channel.
> */
> struct ads7828_data {
> struct device *hwmon_dev;
> @@ -71,6 +76,8 @@ struct ads7828_data {
> char valid;
> unsigned long last_updated;
> u16 adc_input[ADS7828_NCH];
> + unsigned int lsb_resol;
> + s32
linux-next: manual merge of the v4l-dvb tree with Linus' tree
Hi Mauro,
Today's linux-next merge of the v4l-dvb tree got a conflict in
Documentation/feature-removal-schedule.txt between commit 9c0ece069b32
("Get rid of Documentation/feature-removal.txt") from Linus' tree and
commit 251658e5185e ("[media] Schedule removal of i.MX25 support in
mx2_camera.c") from the v4l-dvb tree.
I just removed the file and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpvifXZFAj9w.pgp
Description: PGP signature
linux-next: build failure in dwarf-regs.c
I pulled the latest bits up to 797b9e5ae93270ec27a1f1ed48cd697d01b2269f - but am seeing the following build failure with gcc 4.6.3 CC arch/x86/util/dwarf-regs.o arch/x86/util/dwarf-regs.c:72:13: error: no previous prototype for 'get_arch_regstr' [-Werror=missing-prototypes] cc1: all warnings being treated as errors make[3]: *** [arch/x86/util/dwarf-regs.o] Error 1 make[3]: Leaving directory `/data/home/bguthro/dev/orc-newdev.git/linux/build/tools/tools/perf' make[2]: *** [build-linux-tools] Error 2 make[2]: Leaving directory `/data/home/bguthro/dev/orc-newdev.git/linux' make[1]: *** [install-kernel] Error 2 make[1]: Leaving directory `/data/home/bguthro/dev/orc-newdev.git/orc-kernel' make: *** [dist-kernels] Error 2 git blame shows that line coming in from the following changeset - though April is a long time ago in kernel time - so this must have come in with some other merge in this 3.7 window commit cd932c593995abee1d1a8a0bfe608f7d103d87ad Author: Ian Munsie Date: Tue Apr 20 16:58:32 2010 +1000 perf: Move arch specific code into separate arch directory The perf userspace tool included some architecture specific code to map registers from the DWARF register number into the names used by the regs and stack access API. This moves the architecture specific code out into a separate arch/x86 directory along with the infrastructure required to use it. Signed-off-by: Ian Munsie Acked-by: Masami Hiramatsu Signed-off-by: Paul Mackerras Apologies to Ian, who may reciece this multiple times, as I worked out some email bounce issues with 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: linux-next: build failure after merge of the nfs tree
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Stephen Rothwell
> Sent: Monday, October 01, 2012 8:39 PM
> To: Trond Myklebust
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: linux-next: build failure after merge of the nfs tree
>
> Hi Trond,
>
> After merging the nfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/nfs/callback.c: In function 'nfs_minorversion_callback_svc_setup':
> fs/nfs/callback.c:206:21: error: 'ENOTSUP' undeclared (first use in this
> function)
>
> Caused by commit 141e1f553b6e ("NFSv4: Fix the minor version callback
> channel startup").
>
Hi Stephen,
Thanks! We've already fixed this issue and pushed out a new tree...
Cheers
Trond
--
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] hwmon: (ads7828) driver cleanup
On Mon, Oct 01, 2012 at 07:16:23PM -0400, Vivien Didelot wrote:
> * Remove unused macros;
> * Point to the documentation;
> * Coding Style fixes (Kernel Doc, spacing);
> * Move driver declaration to avoid adding function prototypes.
>
> Signed-off-by: Vivien Didelot
Hi Vivien,
> ---
> drivers/hwmon/ads7828.c | 91
> +++--
> 1 file changed, 43 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/hwmon/ads7828.c b/drivers/hwmon/ads7828.c
> index bf3fdf4..fb3010d 100644
> --- a/drivers/hwmon/ads7828.c
> +++ b/drivers/hwmon/ads7828.c
> @@ -6,7 +6,7 @@
> *
> * Written by Steve Hardy
> *
> - * Datasheet available at: http://focus.ti.com/lit/ds/symlink/ads7828.pdf
> + * For further information, see the Documentation/hwmon/ads7828 file.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> @@ -34,14 +34,12 @@
> #include
>
> /* The ADS7828 registers */
> -#define ADS7828_NCH 8 /* 8 channels of 12-bit A-D supported */
> -#define ADS7828_CMD_SD_SE 0x80 /* Single ended inputs */
> -#define ADS7828_CMD_SD_DIFF 0x00 /* Differential inputs */
> -#define ADS7828_CMD_PD0 0x0 /* Power Down between A-D conversions */
> -#define ADS7828_CMD_PD1 0x04 /* Internal ref OFF && A-D ON */
> -#define ADS7828_CMD_PD2 0x08 /* Internal ref ON && A-D OFF */
> -#define ADS7828_CMD_PD3 0x0C /* Internal ref ON && A-D ON */
> -#define ADS7828_INT_VREF_MV 2500 /* Internal vref is 2.5V, 2500mV */
> +#define ADS7828_NCH 8 /* 8 channels supported */
> +#define ADS7828_CMD_SD_SE0x80/* Single ended inputs */
> +#define ADS7828_CMD_SD_DIFF 0x00/* Differential inputs */
> +#define ADS7828_CMD_PD1 0x04/* Internal ref OFF && A/D ON */
> +#define ADS7828_CMD_PD3 0x0C/* Internal ref ON && A/D ON */
> +#define ADS7828_INT_VREF_MV 2500/* Internal vref is 2.5V, 2500mV */
>
> /* Addresses to scan */
> static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
> @@ -59,25 +57,26 @@ module_param(vref_mv, int, S_IRUGO);
> static u8 ads7828_cmd_byte; /* cmd byte without channel bits */
> static unsigned int ads7828_lsb_resol; /* resolution of the ADC sample lsb */
>
> -/* Each client has this additional data */
> +/**
> + * struct ads7828_data - client specific data
> + * @hwmon_dev: The hwmon device.
> + * @update_lock: Mutex protecting updates.
> + * @valid: Validity flag.
> + * @last_updated:Last updated time (in jiffies).
> + * @adc_input: ADS7828_NCH samples.
> + */
This isn't really an externally visible API, so I wonder if it provides value to
document it this way. No strong opinion, just wondering.
> struct ads7828_data {
> struct device *hwmon_dev;
> - struct mutex update_lock; /* mutex protect updates */
> - char valid; /* !=0 if following fields are valid */
> - unsigned long last_updated; /* In jiffies */
> - u16 adc_input[ADS7828_NCH]; /* ADS7828_NCH 12-bit samples */
> + struct mutex update_lock;
> + char valid;
> + unsigned long last_updated;
> + u16 adc_input[ADS7828_NCH];
> };
>
> -/* Function declaration - necessary due to function dependencies */
> -static int ads7828_detect(struct i2c_client *client,
> - struct i2c_board_info *info);
> -static int ads7828_probe(struct i2c_client *client,
> - const struct i2c_device_id *id);
> -
> static inline u8 channel_cmd_byte(int ch)
> {
> /* cmd byte C2,C1,C0 - see datasheet */
> - u8 cmd = (((ch>>1) | (ch&0x01)<<2)<<4);
> + u8 cmd = (((ch >> 1) | (ch & 0x01) << 2) << 4);
> cmd |= ads7828_cmd_byte;
> return cmd;
> }
> @@ -120,9 +119,8 @@ static ssize_t show_in(struct device *dev, struct
> device_attribute *da,
> ads7828_lsb_resol)/1000);
Can you fix this one as well since you are at it ? There is another one in
sensors_ads7828_init().
[ Wonder why checkpatch doesn't complain about it ]
> }
>
> -#define in_reg(offset)\
> -static SENSOR_DEVICE_ATTR(in##offset##_input, S_IRUGO, show_in,\
> - NULL, offset)
> +#define in_reg(offset) \
> +static SENSOR_DEVICE_ATTR(in##offset##_input, S_IRUGO, show_in, NULL, offset)
>
This causes a checkpatch error - checkpatch doesn't like the multi-line macros.
> in_reg(0);
> in_reg(1);
Since it seems to be hardly worth it anyway (yes, I know there are 8 of them),
would be great if you can just get rid of the macro and just use
static SENSOR_DEVICE_ATTR(in[1-8]_input, ...)
instead.
> @@ -158,25 +156,6 @@ static int ads7828_remove(struct i2c_client *client)
> return 0;
> }
>
> -static const struct i2c_device_id ads7828_id[] = {
> - { "ads7828", 0 },
> - { }
> -};
> -MODULE_DEVICE_TABLE(i2c, ads7828_id);
> -
> -/* This is the driver that will be inserted */
> -static struct i2c_driver ads7828_driver = {
> - .
Re: [PATCH 10/36] AArch64: MMU definitions
On 07/06/2012 05:05 PM, Catalin Marinas wrote: > +/* > + * PAGE_OFFSET - the virtual address of the start of the kernel image. > + * VA_BITS - the maximum number of bits for virtual addresses. > + * TASK_SIZE - the maximum size of a user space task. > + * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area. > + * The module space lives between the addresses given by TASK_SIZE > + * and PAGE_OFFSET - it must be within 128MB of the kernel text. > + */ > +#define PAGE_OFFSET UL(0xffc0) > +#define MODULES_END (PAGE_OFFSET) > +#define MODULES_VADDR(MODULES_END - SZ_64M) > +#define VA_BITS (39) > +#define TASK_SIZE_64 (UL(1) << VA_BITS) Pedantic nit pick. Shouldn't that "it must be within 128MB of the kernel text" be "within 128MB of the *end* of the kernel text"? The point being that on AArch64 unconditional branches are encoded as imm26+1 (27 bits) and so you're going with -64MB to ensure that you're within the range. Jon. -- 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: [REGRESSION] nfsd crashing with 3.6.0-rc7 on PowerPC
On Mon, 2012-10-01 at 16:03 +0200, Alexander Graf wrote: > Phew. Here we go :). It looks to be more of a PPC specific problem than it > appeared as at first: Ok, so I suspect the problem is the pushing down of the locks which breaks with iommu backends that have a separate flush callback. In that case, the flush moves out of the allocator lock. Now we do call flush before we return, still, but it becomes racy I suspect, but somebody needs to give it a closer look. I'm hoping Anton or Nish will later today. Cheers, Ben. > > b4c3a8729ae57b4f84d661e16a192f828eca1d03 is first bad commit > commit b4c3a8729ae57b4f84d661e16a192f828eca1d03 > Author: Anton Blanchard > Date: Thu Jun 7 18:14:48 2012 + > > powerpc/iommu: Implement IOMMU pools to improve multiqueue adapter > performance > > At the moment all queues in a multiqueue adapter will serialise > against the IOMMU table lock. This is proving to be a big issue, > especially with 10Gbit ethernet. > > This patch creates 4 pools and tries to spread the load across > them. If the table is under 1GB in size we revert back to the > original behaviour of 1 pool and 1 largealloc pool. > > We create a hash to map CPUs to pools. Since we prefer interrupts to > be affinitised to primary CPUs, without some form of hashing we are > very likely to end up using the same pool. As an example, POWER7 > has 4 way SMT and with 4 pools all primary threads will map to the > same pool. > > The largealloc pool is reduced from 1/2 to 1/4 of the space to > partially offset the overhead of breaking the table up into pools. > > Some performance numbers were obtained with a Chelsio T3 adapter on > two POWER7 boxes, running a 100 session TCP round robin test. > > Performance improved 69% with this patch applied. > > Signed-off-by: Anton Blanchard > Signed-off-by: Benjamin Herrenschmidt > > :04 04 039ae3cbdcfded9c6b13e58a3fc67609f1b587b0 > 6755a8c4a690cc80dcf834d1127f21db925476d6 March > > > Alex -- 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 10/10] bug.h: Add gcc 4.2+ versions of BUILD_BUG_ON_* macros
On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos wrote: > BUILD_BUG_ON42(arg) > BUILD_BUG_ON_CONST42(arg) > > Prior to gcc 4.2, the optimizer was unable to determine that many > constant values stored in structs were indeed compile-time constants and > optimize them out. Sometimes, it will find an intergral value to be a > compile-time constant, but fail to perform a bit-wise AND at > compile-time. These two macros provide a mechanism to perform these > build-time checks, but not break on older compilers where we already > know they can't be checked at compile time. > > For specific details, consult the doc comments for BUILD_BUG_ON_CONST. > These macros are used in the generic rbtree code. I think the names are quite confusing. BUILD_BUG_ON_NON_CONST42 sounds like it's checking if 42 is a constant. The name probably shouldn't mention what compiler versions support this check, but instead it should hint as to when you should use this instead of BUILD_BUG_ON_CONST ? Maybe BUILD_BUG_ON_CONST_DEREF or something (I'm pretty bad with names too :) -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error
On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos wrote:
> Negative sized arrays wont create a compile-time error in some cases
> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> the error function attribute that will. This patch modifies
> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
> function attribute so that you don't have to build the entire kernel to
> discover that you have a problem, and then enjoy trying to track it down
> from a link-time error.
Few other alternatives I've seen used in other projects (from memory,
so I may have gotten the details wrong):
1) if (condition) { __asm__(".error \"Some error message\""); }
2) switch (0) {
case 0: break;
case !condition: break;
}
(fails to compile if !condition evaluates to 0)
If you can get the first suggestion to work it'd be nice, as you could
get some descriptive error message (you can add the line number there
too).
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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] Extensible AIO interface
On Mon, Oct 01, 2012 at 04:44:39PM -0700, Zach Brown wrote: > And what about duplicate instances of a given attribute id? Use the > first? The last? Error? Depends on the id? I thought of a better idea, instead of explicitly checking for disallowed dups: We want to return -ENOTHANDLED for not handled attributes anyways, so let's just do that for dups - that'll catch erronious usage just fine and a generic mechanism's better than a one off hack any day. This does mean we can't punt on return values, which isn't a bad thing. Also, if we've got duplicate attributes userspace needs to be able to figure out which return value was for which attribute. Two possibilities: one, return values come out in the same order attributes went in. That'd work, but I dislike the subtlety and I expect it'd be a pain for userspace. Instead, let's just stick a u64 cookie in the attribute and include that in the return, just like we do everywhere else. -- 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 v3 1/3] tracing,x86: add a TSC trace_clock
On Mon, 2012-10-01 at 17:33 -0700, David Sharp wrote: > > Unfortunately this isn't enough. You need to add a stub in all > > arch/*/include/asm/ directories. That has: > > Oh really? Okay. Sorry, I really don't know the mechanics of the arch > trees. I'll work on that now, and then send you a new series since I > forgot to send out my last update. It's a good idea to cross compile archs, especially if you make any change that affects archs (like this one did). Just use ktest.pl. You can download the cross tools at: http://kernel.org/pub/tools/crosstool/files/bin/x86_64/ And you can use the example config file in: tools/testing/ktest/examples/crosstests.conf That's basically the test I use to test cross compiling of other archs. -- 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/
linux-next: build failure after merge of the nfs tree
Hi Trond,
After merging the nfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/nfs/callback.c: In function 'nfs_minorversion_callback_svc_setup':
fs/nfs/callback.c:206:21: error: 'ENOTSUP' undeclared (first use in this
function)
Caused by commit 141e1f553b6e ("NFSv4: Fix the minor version callback
channel startup").
I have used the nfs tree from next-20121001 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp6YF9wfQdMY.pgp
Description: PGP signature
Re: [RFC v9 PATCH 06/21] memory-hotplug: export the function acpi_bus_remove()
On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:
From: Wen Congyang
The function acpi_bus_remove() can remove a acpi device from acpi device.
IIUC, s/acpi device/acpi bus
When a acpi device is removed, we need to call this function to remove
the acpi device from acpi bus. So export this function.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
drivers/acpi/scan.c |3 ++-
include/acpi/acpi_bus.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index d1ecca2..1cefc34 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1224,7 +1224,7 @@ static int acpi_device_set_context(struct acpi_device
*device)
return -ENODEV;
}
-static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
+int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
{
if (!dev)
return -EINVAL;
@@ -1246,6 +1246,7 @@ static int acpi_bus_remove(struct acpi_device *dev, int
rmdevice)
return 0;
}
+EXPORT_SYMBOL(acpi_bus_remove);
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index bde976e..2ccf109 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -360,6 +360,7 @@ bool acpi_bus_power_manageable(acpi_handle handle);
bool acpi_bus_can_wakeup(acpi_handle handle);
int acpi_power_resource_register_device(struct device *dev, acpi_handle
handle);
void acpi_power_resource_unregister_device(struct device *dev, acpi_handle
handle);
+int acpi_bus_remove(struct acpi_device *dev, int rmdevice);
#ifdef CONFIG_ACPI_PROC_EVENT
int acpi_bus_generate_proc_event(struct acpi_device *device, u8 type, int
data);
int acpi_bus_generate_proc_event4(const char *class, const char *bid, u8
type, int data);
--
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] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
On 09/24/12 10:19, Will Deacon wrote: > Ok, I've pushed a bunch of patches to my hw-breakpoint branch (head commit > 55cb726797c7). I'll post them to the list after the merge window, but please > do take them for a spin if you get a chance. > Forgot to reply here. Took them for a spin last week with that commit. No more boot hangs but I can't say much else beyond that. When you post to the list I'll add my tested-by. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 v3 1/3] tracing,x86: add a TSC trace_clock
On Fri, Sep 28, 2012 at 8:15 PM, Steven Rostedt wrote: > On Thu, 2012-09-20 at 15:52 -0700, David Sharp wrote: > >> diff --git a/include/asm-generic/trace_clock.h >> b/include/asm-generic/trace_clock.h >> new file mode 100644 >> index 000..6726f1b >> --- /dev/null >> +++ b/include/asm-generic/trace_clock.h >> @@ -0,0 +1,16 @@ >> +#ifndef _ASM_GENERIC_TRACE_CLOCK_H >> +#define _ASM_GENERIC_TRACE_CLOCK_H >> +/* >> + * Arch-specific trace clocks. >> + */ >> + >> +/* >> + * Additional trace clocks added to the trace_clocks >> + * array in kernel/trace/trace.c >> + * None if the architecture has not defined it. >> + */ >> +#ifndef ARCH_TRACE_CLOCKS >> +# define ARCH_TRACE_CLOCKS >> +#endif >> + >> +#endif /* _ASM_GENERIC_TRACE_CLOCK_H */ > > Unfortunately this isn't enough. You need to add a stub in all > arch/*/include/asm/ directories. That has: Oh really? Okay. Sorry, I really don't know the mechanics of the arch trees. I'll work on that now, and then send you a new series since I forgot to send out my last update. > > --- trace_clock.h: > #ifndef _ASM_TRACE_CLOCK_H > #define _ASM_TRACE_CLOCK_H > > #include > > #endif > --- > > > Because running this against my cross-compile test, failed on all archs > but x86. > > -- 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/
[PATCH] [PATCH] x86: Don't clobber top of pt_regs in nested NMI
The nested NMI modifies the place (instruction, flags and stack)
that the first NMI will iret to. However, the copy of registers
modified is exactly the one that is the part of pt_regs in
the first NMI. This can change the behaviour of the first NMI.
In particular, Google's arch_trigger_all_cpu_backtrace handler
also prints regions of memory surrounding addresses appearing in
registers. This results in handled exceptions, after which nested NMIs
start coming in. These nested NMIs change the value of registers
in pt_regs. This can cause the original NMI handler to produce
incorrect output.
We solve this problem by interchanging the position of the preserved
copy of the iret registers ("saved") and the copy subject to being
trampled by nested NMI ("copied").
Signed-off-by: Salman Qazi
---
arch/x86/kernel/entry_64.S | 41 +++--
1 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 44531ac..b5d6e43 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1739,9 +1739,10 @@ nested_nmi:
1:
/* Set up the interrupted NMIs stack to jump to repeat_nmi */
- leaq -6*8(%rsp), %rdx
+ leaq -1*8(%rsp), %rdx
movq %rdx, %rsp
- CFI_ADJUST_CFA_OFFSET 6*8
+ CFI_ADJUST_CFA_OFFSET 1*8
+ leaq -10*8(%rsp), %rdx
pushq_cfi $__KERNEL_DS
pushq_cfi %rdx
pushfq_cfi
@@ -1749,8 +1750,8 @@ nested_nmi:
pushq_cfi $repeat_nmi
/* Put stack back */
- addq $(11*8), %rsp
- CFI_ADJUST_CFA_OFFSET -11*8
+ addq $(6*8), %rsp
+ CFI_ADJUST_CFA_OFFSET -6*8
nested_nmi_out:
popq_cfi %rdx
@@ -1776,18 +1777,18 @@ first_nmi:
* +-+
* | NMI executing variable |
* +-+
-* | Saved SS|
-* | Saved Return RSP|
-* | Saved RFLAGS|
-* | Saved CS|
-* | Saved RIP |
-* +-+
* | copied SS |
* | copied Return RSP |
* | copied RFLAGS |
* | copied CS |
* | copied RIP |
* +-+
+* | Saved SS|
+* | Saved Return RSP|
+* | Saved RFLAGS|
+* | Saved CS|
+* | Saved RIP |
+* +-+
* | pt_regs |
* +-+
*
@@ -1803,9 +1804,14 @@ first_nmi:
/* Set the NMI executing variable on the stack. */
pushq_cfi $1
+ /*
+* Leave room for the "copied" frame
+*/
+ subq $(5*8), %rsp
+
/* Copy the stack frame to the Saved frame */
.rept 5
- pushq_cfi 6*8(%rsp)
+ pushq_cfi 11*8(%rsp)
.endr
CFI_DEF_CFA_OFFSET SS+8-RIP
@@ -1826,12 +1832,15 @@ repeat_nmi:
* is benign for the non-repeat case, where 1 was pushed just above
* to this very stack slot).
*/
- movq $1, 5*8(%rsp)
+ movq $1, 10*8(%rsp)
/* Make another copy, this one may be modified by nested NMIs */
+ addq $(10*8), %rsp
.rept 5
- pushq_cfi 4*8(%rsp)
+ pushq_cfi -6*8(%rsp)
.endr
+ subq $(5*8), %rsp
+
CFI_DEF_CFA_OFFSET SS+8-RIP
end_repeat_nmi:
@@ -1882,8 +1891,12 @@ nmi_swapgs:
SWAPGS_UNSAFE_STACK
nmi_restore:
RESTORE_ALL 8
+
+ /* Pop the extra iret frame */
+ addq $(5*8), %rsp
+
/* Clear the NMI executing stack variable */
- movq $0, 10*8(%rsp)
+ movq $0, 5*8(%rsp)
jmp irq_return
CFI_ENDPROC
END(nmi)
--
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 v7 05/49] audit: add a new "type" field to audit_names struct
For now, we just have two possibilities:
UNKNOWN: for a new audit_names record that we don't know anything about yet
NORMAL: for everything else
In later patches, we'll add other types so we can distinguish and update
records created under different circumstances.
Signed-off-by: Jeff Layton
---
include/linux/audit.h | 5 +
kernel/auditsc.c | 15 ++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 2d8b761..48c49eb 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -450,6 +450,11 @@ struct audit_field {
extern int __init audit_register_class(int class, unsigned *list);
extern int audit_classify_syscall(int abi, unsigned syscall);
extern int audit_classify_arch(int arch);
+
+/* audit_names->type values */
+#defineAUDIT_TYPE_UNKNOWN 0 /* we don't know yet */
+#define AUDIT_TYPE_NORMAL 1 /* a "normal" audit record */
+
#ifdef CONFIG_AUDITSYSCALL
/* These are defined in auditsc.c */
/* Public API */
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ff58089..bd11d09 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -120,6 +120,7 @@ struct audit_names {
struct audit_cap_data fcap;
unsigned intfcap_ver;
int name_len; /* number of name's characters to log */
+ unsigned char type; /* record type */
boolname_put; /* call __putname() for this name */
/*
* This was an allocated audit_names and not from the array of
@@ -2009,7 +2010,8 @@ retry:
#endif
}
-static struct audit_names *audit_alloc_name(struct audit_context *context)
+static struct audit_names *audit_alloc_name(struct audit_context *context,
+ unsigned char type)
{
struct audit_names *aname;
@@ -2024,6 +2026,7 @@ static struct audit_names *audit_alloc_name(struct
audit_context *context)
}
aname->ino = (unsigned long)-1;
+ aname->type = type;
list_add_tail(&aname->list, &context->names_list);
context->name_count++;
@@ -2054,7 +2057,7 @@ void __audit_getname(const char *name)
return;
}
- n = audit_alloc_name(context);
+ n = audit_alloc_name(context, AUDIT_TYPE_UNKNOWN);
if (!n)
return;
@@ -2171,12 +2174,13 @@ void __audit_inode(const char *name, const struct
dentry *dentry)
out_alloc:
/* unable to find the name from a previous getname() */
- n = audit_alloc_name(context);
+ n = audit_alloc_name(context, AUDIT_TYPE_NORMAL);
if (!n)
return;
out:
handle_path(dentry);
audit_copy_inode(n, dentry, inode);
+ n->type = AUDIT_TYPE_NORMAL;
}
/**
@@ -2233,6 +2237,7 @@ void __audit_inode_child(const struct inode *parent,
audit_copy_inode(n, dentry, inode);
else
n->ino = (unsigned long)-1;
+ n->type = AUDIT_TYPE_NORMAL;
found_child = n->name;
goto add_names;
}
@@ -2240,14 +2245,14 @@ void __audit_inode_child(const struct inode *parent,
add_names:
if (!found_parent) {
- n = audit_alloc_name(context);
+ n = audit_alloc_name(context, AUDIT_TYPE_NORMAL);
if (!n)
return;
audit_copy_inode(n, NULL, parent);
}
if (!found_child) {
- n = audit_alloc_name(context);
+ n = audit_alloc_name(context, AUDIT_TYPE_NORMAL);
if (!n)
return;
--
1.7.11.4
--
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 v7 06/49] audit: set the name_len in audit_inode for parent lookups
Currently, this gets set mostly by happenstance when we call into
audit_inode_child. While that might be a little more efficient, it seems
wrong. If the syscall ends up failing before audit_inode_child ever gets
called, then you'll have an audit_names record that shows the full path
but has the parent inode info attached.
Fix this by passing in a parent flag when we call audit_inode that gets
set to the value of LOOKUP_PARENT. We can then fix up the pathname for
the audit entry correctly from the get-go.
While we're at it, clean up the no-op macro for audit_inode in the
!CONFIG_AUDITSYSCALL case.
Signed-off-by: Jeff Layton
---
fs/namei.c| 14 +++---
fs/open.c | 4 ++--
fs/xattr.c| 8
include/linux/audit.h | 13 -
ipc/mqueue.c | 8
kernel/audit.h| 1 +
kernel/auditfilter.c | 30 ++
kernel/auditsc.c | 41 +
8 files changed, 85 insertions(+), 34 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index d43..6c9d86d 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1977,7 +1977,7 @@ static int do_path_lookup(int dfd, const char *name,
retval = path_lookupat(dfd, name, flags | LOOKUP_REVAL, nd);
if (likely(!retval))
- audit_inode(name, nd->path.dentry);
+ audit_inode(name, nd->path.dentry, flags & LOOKUP_PARENT);
return retval;
}
@@ -2652,7 +2652,7 @@ static int do_last(struct nameidata *nd, struct path
*path,
error = complete_walk(nd);
if (error)
return error;
- audit_inode(pathname, nd->path.dentry);
+ audit_inode(pathname, nd->path.dentry, 0);
if (open_flag & O_CREAT) {
error = -EISDIR;
goto out;
@@ -2662,7 +2662,7 @@ static int do_last(struct nameidata *nd, struct path
*path,
error = complete_walk(nd);
if (error)
return error;
- audit_inode(pathname, dir);
+ audit_inode(pathname, dir, 0);
goto finish_open;
}
@@ -2691,7 +2691,7 @@ static int do_last(struct nameidata *nd, struct path
*path,
if (error)
return error;
- audit_inode(pathname, dir);
+ audit_inode(pathname, dir, 0);
error = -EISDIR;
/* trailing slashes? */
if (nd->last.name[nd->last.len])
@@ -2721,7 +2721,7 @@ retry_lookup:
!S_ISREG(file->f_path.dentry->d_inode->i_mode))
will_truncate = false;
- audit_inode(pathname, file->f_path.dentry);
+ audit_inode(pathname, file->f_path.dentry, 0);
goto opened;
}
@@ -2738,7 +2738,7 @@ retry_lookup:
* create/update audit record if it already exists.
*/
if (path->dentry->d_inode)
- audit_inode(pathname, path->dentry);
+ audit_inode(pathname, path->dentry, 0);
/*
* If atomic_open() acquired write access it is dropped now due to
@@ -2803,7 +2803,7 @@ finish_lookup:
error = -ENOTDIR;
if ((nd->flags & LOOKUP_DIRECTORY) && !nd->inode->i_op->lookup)
goto out;
- audit_inode(pathname, nd->path.dentry);
+ audit_inode(pathname, nd->path.dentry, 0);
finish_open:
if (!S_ISREG(nd->inode->i_mode))
will_truncate = false;
diff --git a/fs/open.c b/fs/open.c
index e1f2cdb..ec06921 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -481,7 +481,7 @@ SYSCALL_DEFINE2(fchmod, unsigned int, fd, umode_t, mode)
file = fget(fd);
if (file) {
- audit_inode(NULL, file->f_path.dentry);
+ audit_inode(NULL, file->f_path.dentry, 0);
err = chmod_common(&file->f_path, mode);
fput(file);
}
@@ -594,7 +594,7 @@ SYSCALL_DEFINE3(fchown, unsigned int, fd, uid_t, user,
gid_t, group)
if (error)
goto out_fput;
dentry = file->f_path.dentry;
- audit_inode(NULL, dentry);
+ audit_inode(NULL, dentry, 0);
error = chown_common(&file->f_path, user, group);
mnt_drop_write_file(file);
out_fput:
diff --git a/fs/xattr.c b/fs/xattr.c
index 4d45b71..588455b 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -408,7 +408,7 @@ SYSCALL_DEFINE5(fsetxattr, int, fd, const char __user *,
name,
if (!f)
return error;
dentry = f->f_path.dentry;
- audit_inode(NULL, dentry);
+ audit_inode(NULL, dentry, 0);
error = mnt_want_write_file(f);
if (!error) {
error = setxattr(dentry, name, value, size, flags);
@@ -502,7 +502,7 @@ SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *,
name,
f = fget_light(fd, &fput_needed);
if
[PATCH v7 07/49] audit: remove dirlen argument to audit_compare_dname_path
All the callers set this to NULL now.
Signed-off-by: Jeff Layton
---
kernel/audit.h | 3 +--
kernel/audit_watch.c | 2 +-
kernel/auditfilter.c | 6 +-
kernel/auditsc.c | 4 ++--
4 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/kernel/audit.h b/kernel/audit.h
index 276ca88..ee31316 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -77,8 +77,7 @@ static inline int audit_hash_ino(u32 ino)
extern int audit_match_class(int class, unsigned syscall);
extern int audit_comparator(const u32 left, const u32 op, const u32 right);
extern int parent_len(const char *path);
-extern int audit_compare_dname_path(const char *dname, const char *path,
- int *dirlen);
+extern int audit_compare_dname_path(const char *dname, const char *path);
extern struct sk_buff *audit_make_reply(int pid, int seq, int type,
int done, int multi,
const void *payload, int size);
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 3823281..b6a873a 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -265,7 +265,7 @@ static void audit_update_watch(struct audit_parent *parent,
/* Run all of the watches on this parent looking for the one that
* matches the given dname */
list_for_each_entry_safe(owatch, nextw, &parent->watches, wlist) {
- if (audit_compare_dname_path(dname, owatch->path, NULL))
+ if (audit_compare_dname_path(dname, owatch->path))
continue;
/* If the update involves invalidating rules, do the inode-based
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 29b167b..f9c48d0 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1230,8 +1230,7 @@ int parent_len(const char *path)
/* Compare given dentry name with last component in given path,
* return of 0 indicates a match. */
-int audit_compare_dname_path(const char *dname, const char *path,
-int *dirlen)
+int audit_compare_dname_path(const char *dname, const char *path)
{
int dlen, plen;
const char *p;
@@ -1260,9 +1259,6 @@ int audit_compare_dname_path(const char *dname, const
char *path,
p++;
}
- /* return length of path's directory component */
- if (dirlen)
- *dirlen = p - path;
return strncmp(p, dname, dlen);
}
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 011e923..b03ef6a 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2236,7 +2236,7 @@ void __audit_inode_child(const struct inode *parent,
continue;
if (n->ino == parent->i_ino &&
- !audit_compare_dname_path(dname, n->name, NULL)) {
+ !audit_compare_dname_path(dname, n->name)) {
found_parent = n->name;
goto add_names;
}
@@ -2249,7 +2249,7 @@ void __audit_inode_child(const struct inode *parent,
/* strcmp() is the more likely scenario */
if (!strcmp(dname, n->name) ||
-!audit_compare_dname_path(dname, n->name, NULL)) {
+!audit_compare_dname_path(dname, n->name)) {
if (inode)
audit_copy_inode(n, dentry, inode);
else
--
1.7.11.4
--
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 v7 08/49] audit: make audit_compare_dname_path use parent_len helper
From: Eric Paris
Signed-off-by: Eric Paris
---
kernel/auditfilter.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index f9c48d0..f47ba18 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1232,32 +1232,19 @@ int parent_len(const char *path)
* return of 0 indicates a match. */
int audit_compare_dname_path(const char *dname, const char *path)
{
- int dlen, plen;
+ int dlen, pathlen, parentlen;
const char *p;
- if (!dname || !path)
- return 1;
-
dlen = strlen(dname);
- plen = strlen(path);
- if (plen < dlen)
+ pathlen = strlen(path);
+ if (pathlen < dlen)
return 1;
- /* disregard trailing slashes */
- p = path + plen - 1;
- while ((*p == '/') && (p > path))
- p--;
-
- /* find last path component */
- p = p - dlen + 1;
- if (p < path)
+ parentlen = parent_len(path);
+ if (pathlen - parentlen != dlen)
return 1;
- else if (p > path) {
- if (*--p != '/')
- return 1;
- else
- p++;
- }
+
+ p = path + parentlen;
return strncmp(p, dname, dlen);
}
--
1.7.11.4
--
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 v7 09/49] audit: optimize audit_compare_dname_path
In the cases where we already know the length of the parent, pass it as
a parm so we don't need to recompute it. In the cases where we don't
know the length, pass in AUDIT_NAME_FULL (-1) to indicate that it should
be determined.
Signed-off-by: Jeff Layton
---
kernel/audit.h | 5 -
kernel/audit_watch.c | 3 ++-
kernel/auditfilter.c | 16 +++-
kernel/auditsc.c | 8 +++-
4 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/kernel/audit.h b/kernel/audit.h
index ee31316..34af33c 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -74,10 +74,13 @@ static inline int audit_hash_ino(u32 ino)
return (ino & (AUDIT_INODE_BUCKETS-1));
}
+/* Indicates that audit should log the full pathname. */
+#define AUDIT_NAME_FULL -1
+
extern int audit_match_class(int class, unsigned syscall);
extern int audit_comparator(const u32 left, const u32 op, const u32 right);
extern int parent_len(const char *path);
-extern int audit_compare_dname_path(const char *dname, const char *path);
+extern int audit_compare_dname_path(const char *dname, const char *path, int
plen);
extern struct sk_buff *audit_make_reply(int pid, int seq, int type,
int done, int multi,
const void *payload, int size);
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index b6a873a..f8e9353 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -265,7 +265,8 @@ static void audit_update_watch(struct audit_parent *parent,
/* Run all of the watches on this parent looking for the one that
* matches the given dname */
list_for_each_entry_safe(owatch, nextw, &parent->watches, wlist) {
- if (audit_compare_dname_path(dname, owatch->path))
+ if (audit_compare_dname_path(dname, owatch->path,
+AUDIT_NAME_FULL))
continue;
/* If the update involves invalidating rules, do the inode-based
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index f47ba18..1e0899d 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1228,11 +1228,17 @@ int parent_len(const char *path)
return p - path;
}
-/* Compare given dentry name with last component in given path,
- * return of 0 indicates a match. */
-int audit_compare_dname_path(const char *dname, const char *path)
+/**
+ * audit_compare_dname_path - compare given dentry name with last component in
+ * given path. Return of 0 indicates a match.
+ * @dname: dentry name that we're comparing
+ * @path: full pathname that we're comparing
+ * @parentlen: length of the parent if known. Passing in AUDIT_NAME_FULL
+ * here indicates that we must compute this value.
+ */
+int audit_compare_dname_path(const char *dname, const char *path, int
parentlen)
{
- int dlen, pathlen, parentlen;
+ int dlen, pathlen;
const char *p;
dlen = strlen(dname);
@@ -1240,7 +1246,7 @@ int audit_compare_dname_path(const char *dname, const
char *path)
if (pathlen < dlen)
return 1;
- parentlen = parent_len(path);
+ parentlen = parentlen == AUDIT_NAME_FULL ? parent_len(path) : parentlen;
if (pathlen - parentlen != dlen)
return 1;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index b03ef6a..52d1f0f 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -81,9 +81,6 @@
* a name dynamically and also add those to the list anchored by names_list. */
#define AUDIT_NAMES5
-/* Indicates that audit should log the full pathname. */
-#define AUDIT_NAME_FULL -1
-
/* no execve audit message should be longer than this (userspace limits) */
#define MAX_EXECVE_AUDIT_LEN 7500
@@ -2236,7 +2233,7 @@ void __audit_inode_child(const struct inode *parent,
continue;
if (n->ino == parent->i_ino &&
- !audit_compare_dname_path(dname, n->name)) {
+ !audit_compare_dname_path(dname, n->name, n->name_len)) {
found_parent = n->name;
goto add_names;
}
@@ -2249,7 +2246,8 @@ void __audit_inode_child(const struct inode *parent,
/* strcmp() is the more likely scenario */
if (!strcmp(dname, n->name) ||
-!audit_compare_dname_path(dname, n->name)) {
+ !audit_compare_dname_path(dname, n->name,
+ AUDIT_NAME_FULL)) {
if (inode)
audit_copy_inode(n, dentry, inode);
else
--
1.7.11.4
--
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
[PATCH v7 10/49] audit: overhaul __audit_inode_child to accomodate retrying
In order to accomodate retrying path-based syscalls, we need to add a
new "type" argument to audit_inode_child. This will tell us whether
we're looking for a child entry that represents a create or a delete.
If we find a parent, don't automatically assume that we need to create a
new entry. Instead, use the information we have to try to find an
existing entry first. Update it if one is found and create a new one if
not.
Signed-off-by: Jeff Layton
---
fs/btrfs/ioctl.c | 2 +-
fs/namei.c | 2 +-
include/linux/audit.h| 12 ++
include/linux/fsnotify.h | 8 +++
kernel/auditsc.c | 57 +---
5 files changed, 44 insertions(+), 37 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 7e78d47..45f987b 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -614,7 +614,7 @@ static int btrfs_may_delete(struct inode *dir,struct dentry
*victim,int isdir)
return -ENOENT;
BUG_ON(victim->d_parent->d_inode != dir);
- audit_inode_child(dir, victim);
+ audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE);
error = inode_permission(dir, MAY_WRITE | MAY_EXEC);
if (error)
diff --git a/fs/namei.c b/fs/namei.c
index 6c9d86d..64f7350 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2180,7 +2180,7 @@ static int may_delete(struct inode *dir,struct dentry
*victim,int isdir)
return -ENOENT;
BUG_ON(victim->d_parent->d_inode != dir);
- audit_inode_child(dir, victim);
+ audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE);
error = inode_permission(dir, MAY_WRITE | MAY_EXEC);
if (error)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 155524b..0f7284a 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -455,6 +455,8 @@ extern int audit_classify_arch(int arch);
#defineAUDIT_TYPE_UNKNOWN 0 /* we don't know yet */
#define AUDIT_TYPE_NORMAL 1 /* a "normal" audit record */
#define AUDIT_TYPE_PARENT 2 /* a parent audit record */
+#define AUDIT_TYPE_CHILD_DELETE 3 /* a child being deleted */
+#define AUDIT_TYPE_CHILD_CREATE 4 /* a child being created */
#ifdef CONFIG_AUDITSYSCALL
/* These are defined in auditsc.c */
@@ -470,7 +472,8 @@ extern void audit_putname(const char *name);
extern void __audit_inode(const char *name, const struct dentry *dentry,
unsigned int parent);
extern void __audit_inode_child(const struct inode *parent,
- const struct dentry *dentry);
+ const struct dentry *dentry,
+ const unsigned char type);
extern void __audit_seccomp(unsigned long syscall, long signr, int code);
extern void __audit_ptrace(struct task_struct *t);
@@ -511,9 +514,10 @@ static inline void audit_inode(const char *name, const
struct dentry *dentry,
__audit_inode(name, dentry, parent);
}
static inline void audit_inode_child(const struct inode *parent,
-const struct dentry *dentry) {
+const struct dentry *dentry,
+const unsigned char type) {
if (unlikely(!audit_dummy_context()))
- __audit_inode_child(parent, dentry);
+ __audit_inode_child(parent, dentry, type);
}
void audit_core_dumps(long signr);
@@ -641,7 +645,7 @@ extern int audit_signals;
#define __audit_inode(n,d,p) do { ; } while (0)
#define __audit_inode_child(p,d) do { ; } while (0)
#define audit_inode(n,d,p) do { ; } while (0)
-#define audit_inode_child(p,d) do { ; } while (0)
+#define audit_inode_child(p,d,t) do { ; } while (0)
#define audit_core_dumps(i) do { ; } while (0)
#define audit_seccomp(i,s,c) do { ; } while (0)
#define auditsc_get_stamp(c,t,s) (0)
diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 9c28471..0fbfb46 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -109,7 +109,7 @@ static inline void fsnotify_move(struct inode *old_dir,
struct inode *new_dir,
if (source)
fsnotify(source, FS_MOVE_SELF, moved->d_inode,
FSNOTIFY_EVENT_INODE, NULL, 0);
- audit_inode_child(new_dir, moved);
+ audit_inode_child(new_dir, moved, AUDIT_TYPE_CHILD_CREATE);
}
/*
@@ -155,7 +155,7 @@ static inline void fsnotify_inoderemove(struct inode *inode)
*/
static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
{
- audit_inode_child(inode, dentry);
+ audit_inode_child(inode, dentry, AUDIT_TYPE_CHILD_CREATE);
fsnotify(inode, FS_CREATE, dentry->d_inode, FSNOTIFY_EVENT_INODE,
dentry->d_name.name, 0);
}
@@ -168,7 +168,7 @@ static inline void fsnotify_create(struct inode *inode,
struct dentry *dentry)
static inline void fsnotify_link(struct inode *dir, struct inode *inode,
st
