Re: [PATCH 1/4] drm/dsi: Add flag for continuous clock behavior
Hi Andrejz, On Thu, Jul 3, 2014 at 5:23 PM, Andrzej Hajda wrote: > > Hi Alexandre, > > Thanks for the patch. > > On 07/02/2014 02:19 PM, Alexandre Courbot wrote: >> As per section 5.6.1 of the DSI specification, all DSI transmitters must >> support continuous clock behavior on the clock lane, while non-continuous >> mode support is only optional. Add a flag that allows devices to indicate >> that they require continuous clock mode to operate properly. >> >> Signed-off-by: Alexandre Courbot >> --- >> include/drm/drm_mipi_dsi.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h >> index 944f33f..5913ef4 100644 >> --- a/include/drm/drm_mipi_dsi.h >> +++ b/include/drm/drm_mipi_dsi.h >> @@ -94,6 +94,8 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host); >> #define MIPI_DSI_MODE_VSYNC_FLUSHBIT(8) >> /* disable EoT packets in HS mode */ >> #define MIPI_DSI_MODE_EOT_PACKET BIT(9) >> +/* use continuous clock behavior on the clock lane */ >> +#define MIPI_DSI_MODE_CLOCK_CONTINUOUS BIT(10) >> > > According to MIPI DSI specification "All DSI transmitters and receivers > shall support continuous clock behavior on the Clock Lane, and > optionally may support non-continuous clock behavior". It suggests that > continuous clock should be default behavior. So maybe better is to > introduce sth like: > +#define MIPI_DSI_MODE_CLOCK_NON_CONTINUOUS BIT(10) I started under the assumption that current host drivers assumed non-continuous clock (as the Tegra driver currently does). In that light, it seemed to make sense (and to be less intrusive) to introduce that flag as a restriction rather than a capability. But if you think this should be a capability I am not strongly against it - either way, host drivers need to be changed to take that flag into account. -- 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] firmware loader: inform direct failure when udev loader is disabled
At Wed, 2 Jul 2014 09:55:05 -0700,
Luis R. Rodriguez wrote:
>
> From: "Luis R. Rodriguez"
>
> Now that the udev firmware loader is optional request_firmware()
> will not provide any information on the kernel ring buffer if
> direct firmware loading failed and udev firmware loading is disabled.
> If no information is needed request_firmware_direct() should be used
> for optional firmware, at which point drivers can take on the onus
> over informing of any failures, if udev firmware loading is disabled
> though we should at the very least provide some sort of information
> as when the udev loader was enabled by default back in the days.
>
> With this change with a simple firmware load test module [0]:
>
> Example output without FW_LOADER_USER_HELPER_FALLBACK
>
> platform fake-dev.0: Direct firmware load for fake.bin failed
> with error -2
>
> Example with FW_LOADER_USER_HELPER_FALLBACK
>
> platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
> platform fake-dev.0: Falling back to user helper
>
> Without this change without FW_LOADER_USER_HELPER_FALLBACK we
> get no output logged upon failure.
>
> Cc: Tom Gundersen
> Cc: Ming Lei
> Cc: Greg Kroah-Hartman
> Cc: Abhay Salunke
> Cc: Stefan Roese
> Cc: Arnd Bergmann
> Cc: Kay Sievers
> Cc: Takashi Iwai
> Signed-off-by: Luis R. Rodriguez
> ---
>
> Use FW_OPT_NO_WARN instead.
Looks good to me.
Reviewed-by: Takashi Iwai
thanks,
Takashi
>
> drivers/base/firmware_class.c | 13 +++--
> include/linux/firmware.h | 15 ---
> 2 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 46ea5f4..08e67cc 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -109,6 +109,7 @@ static inline long firmware_loading_timeout(void)
> #else
> #define FW_OPT_FALLBACK 0
> #endif
> +#define FW_OPT_NO_WARN (1U << 3)
>
> struct firmware_cache {
> /* firmware_buf instance will be added into the below list */
> @@ -1116,10 +1117,11 @@ _request_firmware(const struct firmware **firmware_p,
> const char *name,
>
> ret = fw_get_filesystem_firmware(device, fw->priv);
> if (ret) {
> - if (opt_flags & FW_OPT_USERHELPER) {
> + if (!(opt_flags & FW_OPT_NO_WARN))
> dev_warn(device,
> - "Direct firmware load failed with error %d\n",
> - ret);
> + "Direct firmware load for %s failed with error
> %d\n",
> + name, ret);
> + if (opt_flags & FW_OPT_USERHELPER) {
> dev_warn(device, "Falling back to user helper\n");
> ret = fw_load_from_user_helper(fw, name, device,
> opt_flags, timeout);
> @@ -1176,7 +1178,6 @@ request_firmware(const struct firmware **firmware_p,
> const char *name,
> }
> EXPORT_SYMBOL(request_firmware);
>
> -#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> /**
> * request_firmware: - load firmware directly without usermode helper
> * @firmware_p: pointer to firmware image
> @@ -1193,12 +1194,12 @@ int request_firmware_direct(const struct firmware
> **firmware_p,
> {
> int ret;
> __module_get(THIS_MODULE);
> - ret = _request_firmware(firmware_p, name, device, FW_OPT_UEVENT);
> + ret = _request_firmware(firmware_p, name, device,
> + FW_OPT_UEVENT | FW_OPT_NO_WARN);
> module_put(THIS_MODULE);
> return ret;
> }
> EXPORT_SYMBOL_GPL(request_firmware_direct);
> -#endif
>
> /**
> * release_firmware: - release the resource associated with a firmware image
> diff --git a/include/linux/firmware.h b/include/linux/firmware.h
> index 67e5b80..5c41c5e 100644
> --- a/include/linux/firmware.h
> +++ b/include/linux/firmware.h
> @@ -45,6 +45,8 @@ int request_firmware_nowait(
> struct module *module, bool uevent,
> const char *name, struct device *device, gfp_t gfp, void *context,
> void (*cont)(const struct firmware *fw, void *context));
> +int request_firmware_direct(const struct firmware **fw, const char *name,
> + struct device *device);
>
> void release_firmware(const struct firmware *fw);
> #else
> @@ -66,13 +68,12 @@ static inline void release_firmware(const struct firmware
> *fw)
> {
> }
>
> -#endif
> +static inline int request_firmware_direct(const struct firmware **fw,
> + const char *name,
> + struct device *device)
> +{
> + return -EINVAL;
> +}
>
> -#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> -int request_firmware_direct(const struct firmware **fw, const char *name,
> - struct device *device);
> -#else
> -#define request_firmware_direct request_firmware
>
Re: [PATCH 05/18] power: reset: Add AT91 reset driver
On Jul 3, 2014, at 10:59 PM, Maxime Ripard
wrote:
> On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>>> +++ b/drivers/power/reset/at91-reset.c
>>> @@ -0,0 +1,202 @@
>>> +/*
>>> + * Atmel AT91 SAM9 SoCs reset code
>>> + *
>>> + * Copyright (C) 2014 Maxime Ripard
>>> + *
>>> + * Maxime Ripard
>>
>> you can not own the copyright as it’s basically a copy of other
>> people code
>
> The previous names are missing, right.
>
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2. This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#include
>>> +
>>> +#include
>>> +#include
>>> +
>>> +#define AT91_RSTC_CR 0x00/* Reset Controller Control
>>> Register */
>>> +#defineAT91_RSTC_PROCRST BIT(0) /* Processor Reset */
>>> +#defineAT91_RSTC_PERRSTBIT(2) /* Peripheral Reset */
>>> +#defineAT91_RSTC_EXTRSTBIT(3) /* External Reset */
>>> +#defineAT91_RSTC_KEY (0xa5 << 24)/* KEY Password */
>>> +
>>> +#define AT91_RSTC_SR 0x04/* Reset Controller Status
>>> Register */
>>> +#defineAT91_RSTC_URSTS BIT(0) /* User Reset Status */
>>> +#defineAT91_RSTC_RSTTYPGENMASK(10, 8) /* Reset Type */
>>> +#defineAT91_RSTC_NRSTL BIT(16) /* NRST Pin Level */
>>> +#defineAT91_RSTC_SRCMP BIT(17) /* Software Reset
>>> Command in Progress */
>>> +
>>> +#define AT91_RSTC_MR 0x08/* Reset Controller Mode
>>> Register */
>>> +#defineAT91_RSTC_URSTENBIT(0) /* User Reset Enable */
>>> +#defineAT91_RSTC_URSTIEN BIT(4) /* User Reset Interrupt
>>> Enable */
>>> +#defineAT91_RSTC_ERSTL GENMASK(11, 8) /* External Reset
>>> Length */
>>> +
>>> +enum reset_type {
>>> + RESET_TYPE_GENERAL = 0,
>>> + RESET_TYPE_WAKEUP = 1,
>>> + RESET_TYPE_WATCHDOG = 2,
>>> + RESET_TYPE_SOFTWARE = 3,
>>> + RESET_TYPE_USER = 4,
>>> +};
>>> +
>>> +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
>>> +
>>> +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
>>> +{
>>> + asm volatile(
>>> + ".balign 32\n\t"
>>> +
>>> + "str%2, [%0, #" __stringify(AT91_SDRAMC_TR) "]\n\t"
>>> + "str%3, [%0, #" __stringify(AT91_SDRAMC_LPR) "]\n\t"
>>> + "str%4, [%1, #" __stringify(AT91_RSTC_CR) "]\n\t"
>>> +
>>> + "b .\n\t"
>>> + :
>>> + : "r" (at91_ramc_base[0]),
>>> + "r" (at91_rstc_base),
>>> + "r" (1),
>>> + "r" (AT91_SDRAMC_LPCB_POWER_DOWN),
>>> + "r" (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST));
>>> +}
>>> +
>>> +static void at91sam9g45_restart(enum reboot_mode mode, const char *cmd)
>>> +{
>>> + asm volatile(
>>> + "cmp%1, #0\n\t"
>>> + "beq1f\n\t"
>>> +
>>> + "ldrr0, [%1]\n\t"
>>> + "cmpr0, #0\n\t"
>>> +
>>> + ".balign 32\n\t"
>>> +
>>> + "1: str %3, [%0, #" __stringify(AT91_DDRSDRC_RTR)
>>> "]\n\t"
>>> + " str %4, [%0, #" __stringify(AT91_DDRSDRC_RTR)
>>> "]\n\t"
>>> + " strne %3, [%1, #" __stringify(AT91_DDRSDRC_RTR)
>>> "]\n\t"
>>> + " strne %4, [%1, #" __stringify(AT91_DDRSDRC_RTR)
>>> "]\n\t"
>>> + " str %5, [%2, #" __stringify(AT91_RSTC_CR) "]\n\t"
>>> +
>>> + " b .\n\t"
>>> + :
>>> + : "r" (at91_ramc_base[0]),
>>> + "r" (at91_ramc_base[1]),
>>> + "r" (at91_rstc_base),
>>> + "r" (1),
>>> + "r" (AT91_DDRSDRC_LPCB_POWER_DOWN),
>>> + "r" (AT91_RSTC_KEY | AT91_RSTC_PERRST | AT91_RSTC_PROCRST)
>>> + : "r0");
>>> +}
>>> +
>> move this to an assembly file more easy to read than a C code
>
> Nope. It's a pain to pass variable to an external assembly file, and
> this makes the use of global variable pretty much mandatory, which is
> definitely not great.
Not at all I did for the PM slow clock code just write a function and pas it as
a parameter
you have 3
so basically you have to use the current and just pass at91_ramc_base[0],
at91_ramc_base[1]
and at91_rstc_base
it’s 3 lignes of modification, if you have at91_ramc_base and at91_ramc_base
same
so NACK
>
>>
>>> +static void __init at91_reset_status(struct platform_device *pdev)
>>> +{
>>> + u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
>>> + char *reason;
>>> +
>>> + switch ((reg & AT91_RSTC_RSTTYP) >> 8) {
>>> + case RESET_TYPE_GENERAL:
>>> + reason = "general reset";
>>> + break;
>>> + case RESET_TYPE_WAKEUP:
>>> +
Re: direct device assignment in nested VM
On 2014-07-04 05:27, Hu Yaohui wrote: > Hi All, > Is direct device assignment in nested VM supported in the latest KVM > mainline now? Le Tan is currently working on emulated device assignment (VT-d emulation in QEMU). This is the necessary first step and could later be extended to enable assignment of physical devices to nested guests with support of the host IOMMU (out of scope for Le's project, though). Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- 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]Pid conversion between pid namespace
Chen-san, I would like to recommend that you summarize pros/cons for all ideas so far. For example, - A) make new system call for transrate A-1) systemcall(ID, NS1, NS2) into (ID). pros: - foo - baa cons: - hoge - hogehogehoge A-2) pid_t getnspid(pid_t query_pid, pid_t observer_pid) (ditto) B) make/change proc file/directories B-1) expand /proc/pid/status (ditto) B-2) /proc//ns/proc/ which would contain everything from /proc//. (ditto) -- Please make clear what is the good/bad point of each opinion by the above, - Is it hard to keep compatiblity? - Is it hard to understand for administorator/programmer? - Is it difficult to show for "nested containers"? - Is userland tool necessary? - any other problems? I hope it will be good discussion by the above. Thanks, > Hi, > > We had some discussions on how to carry out > pid conversion between pid namespace via: > syscall[1] and procfs[2]. > > Pavel suggested that a syscall like > (ID, NS1, NS2) into (ID). > > Serge suggested that a syscall > pid_t getnspid(pid_t query_pid, pid_t observer_pid). > > > Eric and Richard suggested a procfs solution is > more appropriate. > > Oleg suggested that we should expand /proc/pid/status > to report this kind of information. > > And Richard suggested adding a directory like > /proc//ns/proc/ which would contain everything > from /proc//. > > As procfs provided a more user friendly interface, > how about expose all sets of tgid, pid, pgid, sid > by expanding /proc/PID/status in procfs? > And we could also expose ns hierarchy under /proc, > which could be another reference. > > Ex: > init_pid_nsns1 ns2 > t1 2 > t2 `- 3 1 > t3 `- 4 `- 51 > > We could get in /proc/t3/status: > NSpid: 4 5 1 > We knew that pid 1 in container is pid 4 in init ns. > > And we could get ns hierarchy under /proc/ns_hierarchy like: > init_ns->ns1->ns2 (as the result of readlink) > ->ns3 > We knew that t3 in ns2, and its hierarchy. > > How these ideas looks like? > Any comments would be appreciated. > > Thanks, > - Chen > > > a) syscall > http://lwn.net/Articles/602987/ > > b) procfs > http://www.spinics.net/lists/kernel/msg1751688.html > -- Yasunori Goto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: nVMX: Fix IRQs inject to L2 which belong to L1 since race
On 2014-07-04 04:52, Wanpeng Li wrote: > On Thu, Jul 03, 2014 at 01:27:05PM -0400, Bandan Das wrote: > [...] >> # modprobe kvm_intel ept=0 nested=1 enable_shadow_vmcs=0 >> >> The Host CPU - Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz >> qemu cmd to run L1 - >> # qemu-system-x86_64 -drive >> file=level1.img,if=virtio,id=disk0,format=raw,cache=none,werror=stop,rerror=stop,aio=threads >> -drive >> file=level2.img,if=virtio,id=disk1,format=raw,cache=none,werror=stop,rerror=stop,aio=threads >> -vnc :2 --enable-kvm -monitor stdio -m 4G -net >> nic,macaddr=00:23:32:45:89:10 -net >> tap,ifname=tap0,script=/etc/qemu-ifup,downscript=no -smp 4 -cpu Nehalem,+vmx >> -serial pty >> >> qemu cmd to run L2 - >> # sudo qemu-system-x86_64 -hda VM/level2.img -vnc :0 --enable-kvm -monitor >> stdio -m 2G -smp 2 -cpu Nehalem -redir tcp:::22 >> >> Additionally, >> L0 is FC19 with 3.16-rc3 >> L1 and L2 are Ubuntu 14.04 with 3.13.0-24-generic >> >> Then start a kernel compilation inside L2 with "make -j3" >> >> There's no call trace on L0, both L0 and L1 are hung (or rather really slow) >> and >> L1 serial spews out CPU softlock up errors. Enabling panic on softlockup on >> L1 will give >> a trace with smp_call_function_many() I think the corresponding code in >> kernel/smp.c that >> triggers this is >> >> WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() >> && !oops_in_progress && !early_boot_irqs_disabled); >> >> I know in most cases this is usually harmless, but in this specific case, >> it seems it's stuck here forever. >> >> Sorry, I don't have a L1 call trace handy atm, I can post that if you are >> interested. >> >> Note that this can take as much as 30 to 40 minutes to appear but once it >> does, >> you will know because both L1 and L2 will be stuck with the serial messages >> as I mentioned >> before. From my side, let me try this on another system to rule out any >> machine specific >> weirdness going on.. >> > > Thanks for your pointing out. > >> Please let me know if you need any further information. >> > > I just run kvm-unit-tests w/ vmx.flat and eventinj.flat. > > > w/ vmx.flat and w/o my patch applied > > [...] > > Test suite : interrupt > FAIL: direct interrupt while running guest > PASS: intercepted interrupt while running guest > FAIL: direct interrupt + hlt > FAIL: intercepted interrupt + hlt > FAIL: direct interrupt + activity state hlt > FAIL: intercepted interrupt + activity state hlt > PASS: running a guest with interrupt acknowledgement set > SUMMARY: 69 tests, 6 failures > > w/ vmx.flat and w/ my patch applied > > [...] > > Test suite : interrupt > PASS: direct interrupt while running guest > PASS: intercepted interrupt while running guest > PASS: direct interrupt + hlt > FAIL: intercepted interrupt + hlt > PASS: direct interrupt + activity state hlt > PASS: intercepted interrupt + activity state hlt > PASS: running a guest with interrupt acknowledgement set > > SUMMARY: 69 tests, 2 failures Which version (hash) of kvm-unit-tests are you using? All tests up to 307621765a are running fine here, but since a0e30e712d not much is completing successfully anymore: enabling apic paging enabled cr0 = 80010011 cr3 = 7fff000 cr4 = 20 PASS: test vmxon with FEATURE_CONTROL cleared PASS: test vmxon without FEATURE_CONTROL lock PASS: test enable VMX in FEATURE_CONTROL PASS: test FEATURE_CONTROL lock bit PASS: test vmxon FAIL: test vmptrld PASS: test vmclear init_vmcs : make_vmcs_current error FAIL: test vmptrst init_vmcs : make_vmcs_current error vmx_run : vmlaunch failed. FAIL: test vmlaunch FAIL: test vmlaunch SUMMARY: 10 tests, 4 unexpected failures Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- 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] fs/direct-io.c: Fix compilation warning for uninitialized variables
From: Pramod Gurav
Fixes below warning while compiling the kernel.
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
fs/direct-io.c:913:16: note: ‘to’ was declared here
fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
fs/direct-io.c:913:10: note: ‘from’ was declared here
Signed-off-by: Pramod Gurav
CC: Alexander Viro
CC: linux-fsde...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
fs/direct-io.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 98040ba..6ad5d2c 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct dio_submit
*sdio,
while (sdio->block_in_file < sdio->final_block_in_request) {
struct page *page;
- size_t from, to;
+ size_t from = 0, to = 0;
page = dio_get_page(dio, sdio, , );
if (IS_ERR(page)) {
ret = PTR_ERR(page);
--
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 v3 0/5] ALSA/ASoC/dmaengine: Fix 3 bytes physical sample support
At Thu, 3 Jul 2014 13:02:52 +0100, Mark Brown wrote: > > On Thu, Jul 03, 2014 at 03:08:08PM +0530, Vinod Koul wrote: > > > Yes makes sense to go thru ASoC tree. Mark can you keep this in immutable > > branch, which I can merge to my tree for any future fixes... > > Fine by me - Takashi? Sure, please take my ack to the whole series, too: Acked-by: Takashi Iwai thanks, Takashi -- 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: mpt2sas stuck installing
On Thu, Jul 3 2014 Joe Julian wrote: > I have a knox enclosure with an unresponsive drive. When the mpt2sas > module is loaded the module loading process hangs. modprobe/insmod is > stuck and any further attempts to load modules also hang. By > blacklisting the module and loading it last, I can get the computer to > boot, but attempting to manually load the module will still hang. When I > shut down, I get the following: > > [55473.508343] mpt2sas1: _config_request: timeout > [55474.510395] BUG: unable to handle kernel paging request at c90020ae > [55474.513048] IP: [] mpt2sas_base_get_iocstate+0x10/0x30 > [mpt2sas] > [55474.525196] PGD 103f80c067 PUD 203f003067 PMD 1026dca067 PTE 0 > [55474.526115] Oops: [#1] SMP > [55474.527837] Modules linked in: raid456 async_pq async_xor xor async_memcpy > async_raid6_recov raid6_pq async_tx ses enclosure mpt2sas raid_class rdma_ucm > ib_ucm rdma_cm iw_cm ib_addr ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en > mlx4_ib(-) ib_sa ib_mad ib_core coretemp mlx4_core kvm_intel kvm 8021q garp > stp ghash_clmulni_intel llc aesni_intel ablk_helper cryptd nfsd lrw > aes_x86_64 xts psmouse gf128mul sb_edac nfs_acl auth_rpcgss edac_core mei > microcode serio_raw mac_hid lp lpc_ich nfs fscache parport lockd sunrpc ext2 > isci libsas ahci libahci e1000e scsi_transport_sas [last unloaded: mlx4_core] > [55474.538831] CPU 2 > [55474.539218] Pid: 3516, comm: scsi_eh_10 Not tainted 3.8.0-38-generic > #56~precise1-Ubuntu Quanta F03R /Winterfell > [55474.541004] RIP: 0010:[] [] > mpt2sas_base_get_iocstate+0x10/0x30 [mpt2sas] > [55474.542772] RSP: 0018:881019a39ae8 EFLAGS: 00010246 > [55474.543590] RAX: c90020ae RBX: 88100fd1e6b0 RCX: > > [55474.546285] RDX: 881019a39fd8 RSI: 0001 RDI: > 88100fd1e6b0 > [55474.548451] RBP: 881019a39ae8 R08: R09: > > [55474.549585] R10: 07db R11: 07da R12: > 0001 > [55474.550689] R13: 881019a39bbc R14: R15: > 881019a39c80 > [55474.551791] FS: () GS:88103fc4() > knlGS: > [55474.553044] CS: 0010 DS: ES: CR0: 80050033 > [55474.553928] CR2: c90020ae CR3: 01c0d000 CR4: > 000407e0 > [55474.555187] DR0: DR1: DR2: > > [55474.557030] DR3: DR6: 0ff0 DR7: > 0400 > [55474.558139] Process scsi_eh_10 (pid: 3516, threadinfo 881019a38000, > task 8810257b5d00) > [55474.560748] Stack: > [55474.561069] 881019a39b98 a03c183a 0006 > 0006 > [55474.562218] 88100fd1eb00 88100fd1eaf8 88100fd1e6d0 > > [55474.563343] 881019a3 8105b3ea 88100fd1ead8 > > [55474.564595] Call Trace: > [55474.565003] [] _config_request.constprop.5+0x15a/0x590 > [mpt2sas] > [55474.568223] [] ? console_unlock+0x1a/0x30 > [55474.569896] [] > mpt2sas_config_get_expander_pg0+0x8a/0xf0 [mpt2sas] > [55474.571322] [] > _scsih_search_responding_expanders+0x5c/0xe0 [mpt2sas] > [55474.572582] [] ? > _scsih_search_responding_sas_devices+0xa9/0xc0 [mpt2sas] > [55474.573912] [] mpt2sas_scsih_reset_handler+0xbe/0x1a0 > [mpt2sas] > [55474.575191] [] _base_reset_handler+0x1f/0x40 [mpt2sas] > [55474.576250] [] > mpt2sas_base_hard_reset_handler+0x1ae/0x1e0 [mpt2sas] > [55474.577500] [] _scsih_host_reset+0x5c/0xb0 [mpt2sas] > [55474.578554] [] scsi_try_host_reset+0x53/0x110 > [55474.579729] [] scsi_eh_host_reset+0x4c/0x170 > [55474.580764] [] scsi_eh_ready_devs+0x82/0xa0 > [55474.581866] [] scsi_unjam_host+0xed/0x1d0 > [55474.584848] [] scsi_error_handler+0x165/0x1c0 > [55474.585984] [] ? scsi_unjam_host+0x1d0/0x1d0 > [55474.592375] [] kthread+0xc0/0xd0 > [55474.594325] [] ? flush_kthread_worker+0xb0/0xb0 > [55474.595654] [] ret_from_fork+0x7c/0xb0 > [55474.598729] [] ? flush_kthread_worker+0xb0/0xb0 > [55474.607501] Code: c7 c2 f8 7d 3d a0 48 c7 c7 52 ac 3d a0 31 c0 e8 f1 de 31 > e1 e9 f6 fe ff ff 66 90 66 66 66 66 90 55 48 8b 87 88 00 00 00 48 89 e5 <8b> > 00 89 c2 81 e2 00 00 00 f0 85 f6 0f 45 c2 5d c3 66 66 66 66 > [55474.611823] RIP [] mpt2sas_base_get_iocstate+0x10/0x30 > [mpt2sas] > [55474.613007] RSP > [55474.613548] CR2: c90020ae > [55474.614183] ---[ end trace a817d8e30eb9f07c ]--- Hi Joe, I was investigating a crash inside mpt2sas_base_get_iocstate just earlier today. In my case, it appeared that ioc->chip had been cleared when mpt2sas_base_get_iocstate tried to reference through it. This was with a newer kernel on RHEL7, but it also occured early in mpt2sas_base_get_iocstate and EAX held the bogo address. A few follow up questions: Do you happen to have kdump enabled? Were there any other interesting log messages after loading the driver? Is this crash easily reproducible? Regards, -- Joe
Re: __trace_remove_event_dirs() leaks file->filter ? (Was: probe_event_disable()->synchronize_sched())
(2014/07/04 2:01), Oleg Nesterov wrote: > On 07/03, Oleg Nesterov wrote: >> >> Hmm. Off-topic, but it seems that instance_rmdir() leaks the memory? Say, >> file->filter? > > Perhaps I am totally confused, but don't we need something like the patch > below? I'll try to recheck later... > > Better yet, we can probably move destroy_preds() from event_remove() to > remove_event_file_dir()... not sure, need to recheck. Ah, yes, it seems event_remove releases preds, and remove_event_file_dir() called from event_trace_del_tracer() doesn't release it. BTW, with following patch, we'd better remove destroy_preds() from event_remove() and add destroy_call_preds() at the very last of the function. Thank you, > > Oleg. > > --- x/kernel/trace/trace_events.c > +++ x/kernel/trace/trace_events.c > @@ -470,6 +470,7 @@ static void remove_event_file_dir(struct > ftrace_event_file *file) > > list_del(>list); > remove_subsystem(file->system); > + destroy_file_preds(file); > kmem_cache_free(file_cachep, file); > } > > > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] irq_work: Implement remote queueing
On Wed, Jun 25, 2014 at 10:08 PM, Peter Zijlstra wrote:
> On Wed, Jun 25, 2014 at 10:23:21AM -0600, Stephen Warren wrote:
>> On 06/25/2014 04:19 AM, Peter Zijlstra wrote:
>> > On Wed, Jun 25, 2014 at 03:24:11PM +0530, Srivatsa S. Bhat wrote:
>> >> Wait, that was a stupid idea. hotplug_cfd() already invokes irq_work_run
>> >> indirectly via flush_smp_call_function_queue(). So irq_work_cpu_notify()
>> >> doesn't need to invoke it again, AFAIU. So perhaps we can get rid of
>> >> irq_work_cpu_notify() altogether?
>> >
>> > Just so...
>> >
>> > getting up at 6am and sitting in an airport terminal doesn't seem to
>> > agree with me; any more silly fail here?
>> >
>> > ---
>> > Subject: irq_work: Remove BUG_ON in irq_work_run()
>> > From: Peter Zijlstra
>> > Date: Wed Jun 25 07:13:07 CEST 2014
>> >
>> > Because of a collision with 8d056c48e486 ("CPU hotplug, smp: flush any
>> > pending IPI callbacks before CPU offline"), which ends up calling
>> > hotplug_cfd()->flush_smp_call_function_queue()->irq_work_run(), which
>> > is not from IRQ context.
>> >
>> > And since that already calls irq_work_run() from the hotplug path,
>> > remove our entire hotplug handling.
>>
>> Tested-by: Stephen Warren
>>
>> [with the s/static// already mentioned in this thread, obviously:-)]
>
> Right; I pushed out a fixed version right before loosing my tubes at the
> airport :-)
>
> https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/commit/?h=timers/nohz=921d8b81281ecdca686369f52165d04fa3505bd7
This patch fixes boot issue on Exynos5420/5800 based boards with bL
switcher enabled.
FWIW,
Tested-by: Sachin Kamat
--
Regards,
Sachin.
--
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 RFC tip/core/rcu] Parallelize and economize NOCB kthread wakeups
On Fri, Jul 04, 2014 at 05:23:56AM +0200, Mike Galbraith wrote: > On Thu, 2014-07-03 at 09:29 -0700, Paul E. McKenney wrote: > > On Thu, Jul 03, 2014 at 07:48:40AM +0200, Mike Galbraith wrote: > > > On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote: > > > > On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote: > > > > > > > > NO_HZ_FULL is a property of a set of CPUs. isolcpus is supposed to go > > > > > away as being a redundant interface to manage a single property of a > > > > > set > > > > > of CPUs, but it's perfectly fine for NO_HZ_FULL to add an interface to > > > > > manage a single property of a set of CPUs. What am I missing? > > > > > > > > Well, for now, it can only be specified at build time or at boot time. > > > > In theory, it is possible to change a CPU from being callback-offloaded > > > > to not at runtime, but there would need to be an extremely good reason > > > > for adding that level of complexity. Lots of "fun" races in there... > > > > > > Yeah, understood. > > > > > > (still it's a NO_HZ_FULL wart though IMHO, would be prettier and more > > > usable if it eventually became unified with cpuset and learned how to > > > tap-dance properly;) > > > > Agreed, it would in some sense be nice. What specifically do you need > > it for? > > I personally have zero use for the thing (git/vi aren't particularly > perturbation sensitive;). I'm just doing occasional drive-by testing > from a distro perspective, how well does it work, what does it cost etc. > > > Are you really running workloads that generate large numbers of > > callbacks spread across most of the CPUs? It was this sort of workload > > that caused Rik's system to show scary CPU-time accumulation, due to > > the high overhead of frequent one-to-many wakeups. > > > > If your systems aren't running that kind of high-callback-rate workload, > > just set CONFIG_RCU_NOCB_CPU_ALL=y and don't worry about it. > > > > If your systems -are- running that kind of high-callback-rate workload, > > but your system has fewer than 200 CPUs, ensure that you have enough > > housekeeping CPUs to allow the grace-period kthread sufficient CPU time, > > set CONFIG_RCU_NOCB_CPU_ALL=y and don't worry about it. > > > > If your systems -are- running that kind of high-callback-rate workload, > > and your system has more than 200 CPUs, apply the following patch, > > set CONFIG_RCU_NOCB_CPU_ALL=y and once again don't worry about it. ;-) > > Turn it on and don't worry about it is exactly what distros want the > obscure feature with very few users to be. Last time I did a drive-by, > my boxen said I should continue to worry about it ;-) Yep, which is the reason for the patch on the last email. Then again, exactly which feature and which reason for worry? Thanx, Paul -- 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: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Suman, On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna wrote: > OK, but we would still require this function to lookup the registered > device from the controller-phandle to retrieve the base_id. Can we retrieve the base_id from the parent DT node itself? Thanks, Ohad. -- 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: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Suman, On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna wrote: > Not at the moment, with the existing platform implementations. So, if I > understand you correctly, you are asking to leave out the xlate ops and > make the of_hwspin_lock_simple_xlate() internal until a need for an > xlate method arises. Yes, please. It seems to me this way we're reducing complexity without compromising anything. > This also means, we only support a value of 1 for #hwlock-cells. When a different #hwlock-cells value shows up, someone would have to write a new xlate implementation anyway. At the same time, the xlate ops could be brought back quite easily. Since we're not imposing anything on the DT data, this doesn't affect our ability to support these scenarios in the future, but unless I'm missing a current use case, these scenarios right now seems somewhat fictional. > But, that would mean DT-based client users would have to invoke two > function calls to request a hwspinlock. We already have an API to get > the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF > API for requesting a lock directly rather than giving an OF API for > getting the lock id. This is in keeping in convention with what other > drivers do normally - a regular get and an OF get. I can modify it if > you still prefer the OF API for getting a global lock id, but I feel its > a burden for client users. Let's discuss this. I was actually thinking of the more general use case of an heterogenous system: - driver gets the global lock id from a remote processor - driver then requests the specific lock Looking at these cases, the OF scenario only differs in the small part of fetching the lock id, and if we keep the regular request_specific API we'll have more common code between drivers. What do you think? > Also, do you prefer an open property-name in client users (like I am > doing at the moment) or imposing a standard property name "hwlocks"? Good point - I think we can start with an imposed "hwlocks" name, and evolve in the future as needed (again, only because we're not really imposing anything on the DT data - this is just kernel code that we could always extend as needed). Thanks, Ohad. -- 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 usb-gadget tree with the usb.current tree
Hi Felipe,
Today's linux-next merge of the usb-gadget tree got a conflict in
drivers/usb/musb/musb_cppi41.c between commit c58d80f523ff ("usb: musb:
Ensure that cppi41 timer gets armed on premature DMA TX irq") from the
usb.current tree and commit 50aea6fca771 ("usb: musb: cppi41: fire
hrtimer according to programmed channel length") from the usb-gadget
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/usb/musb/musb_cppi41.c
index 5341bb223b7c,adfffe884891..
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@@ -312,15 -271,13 +271,13 @@@ static void cppi41_dma_callback(void *p
goto out;
}
}
- if (is_isoc(hw_ep, 0)) {
- schedule_work(_channel->dma_completion);
- goto out;
- }
list_add_tail(_channel->tx_check,
>early_tx_list);
- if (!hrtimer_active(>early_tx)) {
+ if (!hrtimer_is_queued(>early_tx)) {
+ unsigned long usecs = cppi41_channel->total_len / 10;
+
hrtimer_start_range_ns(>early_tx,
- ktime_set(0, 140 * NSEC_PER_USEC),
+ ktime_set(0, usecs * NSEC_PER_USEC),
40 * NSEC_PER_USEC,
HRTIMER_MODE_REL);
}
signature.asc
Description: PGP signature
Re: probe_event_disable()->synchronize_sched() (Was: tracing/uprobes: Revert "Support mix of ftrace and perf")
(2014/07/04 1:22), Oleg Nesterov wrote: >> One possible scenario is here; someone disables an event and tries to remove >> it (both will be done by different syscalls). If we don't synchronize >> the first disabling, the event flag set disabled, but the event itself >> is not disabled. Thus event handler is still possible to be running >> somewhere when it is removed. > > See above. "remove" can't succed until all ftrace_event_file's are inactive. > And probe_event_disable() does uprobe_unregister() in this case which (again) > serializes with the callbacks itself. Ah, I see. kprobes uses disable_kprobe() instead of unregister, and that is not serialized. >> The other path of __trace_remove_event_call() is trace_module_remove_events() >> which is not related to kprobes/uprobes (Even so, there is no obvious check >> of >> that.) > > Yes, uprobe can ignore modules ;) > >>> So why? Looks like, the only reason is instance_rmdir() which can do >>> TRACE_REG_UNREGISTER and after that destroy this ftrace_event_file? >>> But event_trace_del_tracer() also has synchronize_sched() right after >>> __ftrace_set_clr_event_nolock() ? >> >> I think it doesn't need to call synchronize_sched() because >> event_trace_del_tracer() ensures that all events are disabled >> (handlers are not running anymore) > > Not really, afaics... Well yes, it calls __ftrace_set_clr_event_nolock(), > but this can race with the callbacks; this doesn't necessary call > uprobe_unregister() because there can be other active ftrace_event_file's. > So we need to synchronize before we start to destroy the data. > > So do you agree that we can remove that synchronize_sched() in trace_uprobe.c > and replace it with call_rcu? Yes for uprobes, kprobes still need it. :) Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Filesystem lockup with CONFIG_PREEMPT_RT
On Thu, 2014-07-03 at 16:08 -0700, Austin Schuh wrote: > On Tue, Jul 1, 2014 at 12:32 PM, Austin Schuh wrote: > > On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh > > wrote: > >> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner > >> wrote: > >>> Completely untested patch below. > > I've tested it and looked it over now, and feel pretty confident in > the patch. Thanks Thomas! FWIW, I flogged my boxen hard with the virgin tglx patch applied again after merging 3.14-rt5 with 3.14.10. It remained thoroughly boring. -Mike -- 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] mach-spear: fixed spear1340.c file
Hi Nick, On Fri, Jul 4, 2014 at 2:07 AM, Nick Krause wrote: > Very well then I will read the documentation on Kconfig in order to > understand that and fix up my patches for that. > On the other hand I will send a email before the patches to tell in > what order to apply them. As already asked by Paul, please don't top-post: http://en.wikipedia.org/wiki/Posting_style#Top-posting Firstly, in case we are going to get these patches in these have to be merged together, otherwise inbetween these two we will have duplicate functions for the same thing.. Kernel should work/build properly between commits, so that git bisect works.. Now about this: > -/* FIXME: Move SATA PHY code into a standalone driver */ I don't think it was just about creating another file for this. Otherwise how hard is it for the author then? It was probably more about updating the interface of the sata driver to accept stub drivers, so that we don't have to keep stuff here. So, this patch wouldn't fix the FIXME and so better drop this patchset completely. Thanks for trying though. --- Viresh -- 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/
mach-shmobile: FIXME message in file pm-sh732.c
While searching for FIX ME messages when using cscope on the latest kernels I get a message on 68 of this file and was wondering what I need to define SMFRAM as in order for it to point to things needed to support this portion of the hardware. Cheers Nick -- 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/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 4 July 2014 03:46, Mike Turquette wrote: > Sorry for being dense, but I still do not get why trying to dynamically > discover a shared rate-changeable clock is a better approach than simply > describing the hardware in DT? > > Is adding a property to the CPU binding that describes how the CPUs in a > cluster expect to use a clock somehow a non-starter? It is certainly a > win for readability when staring at DT and trying to understand how DVFS > on that CPU is meant to work (as opposed to hiding that knowledge behind > a tree walk). Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that. There are separate threads going on for that and probably somebody else was trying to push for that. That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :) -- viresh -- 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/2] clockevents: introduce ->set_dev_mode() which can return error
From: Viresh Kumar
Currently, the ->set_mode() method of a clockevent device is not
allowed to fail, so it has no return value. In order to add new
clockevent modes, and allow the setting of those modes to fail, we
need the clockevent core to be able to detect when setting a mode
fails.
To allow detection of mode setting failures, introduce a new method
->set_dev_mode() which can return an error if the given mode is not
supported or fails.
Since all current modes are still not allowed to fail, the core code
simply WARNs if any modes fail. Future patches that add new mode
support will add proper error recovery based on failure conditions.
Signed-off-by: Viresh Kumar
Reviewed-by: Kevin Hilman
[khilman: rework changelogs, minor formatting/checkpatch cleanups]
Signed-off-by: Kevin Hilman
---
include/linux/clockchips.h | 5 -
kernel/time/clockevents.c | 21 ++---
kernel/time/timer_list.c | 5 -
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
index 2e4cb67f6e56..d969659cf688 100644
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@ -81,7 +81,8 @@ enum clock_event_mode {
* @mode: operating mode assigned by the management code
* @features: features
* @retries: number of forced programming retries
- * @set_mode: set mode function
+ * @set_dev_mode: set dev mode function
+ * @set_mode: set mode function (deprecated, use set_dev_mode instead)
* @broadcast: function to broadcast events
* @min_delta_ticks: minimum delta value in ticks stored for reconfiguration
* @max_delta_ticks: maximum delta value in ticks stored for reconfiguration
@@ -109,6 +110,8 @@ struct clock_event_device {
unsigned long retries;
void(*broadcast)(const struct cpumask *mask);
+ int (*set_dev_mode)(enum clock_event_mode mode,
+ struct clock_event_device *);
void(*set_mode)(enum clock_event_mode mode,
struct clock_event_device *);
void(*suspend)(struct clock_event_device *);
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index ad362c260ef4..4758dfb818cf 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -105,7 +105,16 @@ void clockevents_set_mode(struct clock_event_device *dev,
enum clock_event_mode mode)
{
if (dev->mode != mode) {
- dev->set_mode(mode, dev);
+ if (dev->set_dev_mode) {
+ int ret = dev->set_dev_mode(mode, dev);
+
+ /* Currently available modes shouldn't fail */
+ WARN_ONCE(ret, "Requested mode: %d, error: %d\n",
+ mode, ret);
+ } else {
+ dev->set_mode(mode, dev);
+ }
+
dev->mode = mode;
/*
@@ -446,8 +455,14 @@ int __clockevents_update_freq(struct clock_event_device
*dev, u32 freq)
if (dev->mode == CLOCK_EVT_MODE_ONESHOT)
return clockevents_program_event(dev, dev->next_event, false);
- if (dev->mode == CLOCK_EVT_MODE_PERIODIC)
- dev->set_mode(CLOCK_EVT_MODE_PERIODIC, dev);
+ if (dev->mode == CLOCK_EVT_MODE_PERIODIC) {
+ /* Shouldn't fail while switching to PERIODIC MODE */
+ if (dev->set_dev_mode)
+ WARN_ON_ONCE(dev->set_dev_mode(CLOCK_EVT_MODE_PERIODIC,
+ dev));
+ else
+ dev->set_mode(CLOCK_EVT_MODE_PERIODIC, dev);
+ }
return 0;
}
diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index 61ed862cdd37..957a04951ef0 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -229,7 +229,10 @@ print_tickdevice(struct seq_file *m, struct tick_device
*td, int cpu)
SEQ_printf(m, "\n");
SEQ_printf(m, " set_mode: ");
- print_name_offset(m, dev->set_mode);
+ if (dev->set_dev_mode)
+ print_name_offset(m, dev->set_dev_mode);
+ else
+ print_name_offset(m, dev->set_mode);
SEQ_printf(m, "\n");
SEQ_printf(m, " event_handler: ");
--
1.9.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/
[PATCH 0/2] clockevents: introduce ->set_dev_mode() and convert a few drivers
Currently, the ->set_mode() method of a clockevent device is not allowed to fail, so it has no return value. In order to add new clockevent modes, and allow the setting of those modes to fail, we need the clockevent core to be able to detect when setting a mode fails. Rather than changing the current ->set_mode() and requiring all clockevent devices to change immedately, introduce a new mode setting method ->set_dev_mode() which returns 'int'. In addition, migrate a few drivers over to the new method to demonstrate how the new method is to be used, and how to convert. Proposal for new method originally suggested by Thomas Gleixner[1]. [1] https://lkml.org/lkml/2014/5/10/86 Viresh Kumar (2): clockevents: introduce ->set_dev_mode() which can return error clockevents: migrate some drivers to new ->set_dev_mode() drivers/clocksource/arm_arch_timer.c | 46 +--- drivers/clocksource/bcm2835_timer.c | 10 +++ drivers/clocksource/bcm_kona_timer.c | 15 --- drivers/clocksource/i8253.c | 11 +--- drivers/clocksource/time-armada-370-xp.c | 21 +++ include/linux/clockchips.h | 5 +++- kernel/time/clockevents.c| 21 --- kernel/time/timer_list.c | 5 +++- 8 files changed, 91 insertions(+), 43 deletions(-) -- 1.9.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/
[PATCH 2/2] clockevents: migrate some drivers to new ->set_dev_mode()
From: Viresh Kumar
Clockevents core now supports ->set_dev_mode() (as a replacement to
->set_mode()), with capability to return error codes.
This patch migrates few clockevent drivers to the new method to demonstrate how
to convert to the new interface.
Drivers are modified to return -ENOSYS when requested to switch to unsupported
mode and return 0 on success. This patch shouldn't result in any other
functional change in drivers.
Most of the changes are automated with help of Coccinelle
(http://coccinelle.lip6.fr/) and the ones left are around the switch
block which are handled manually. Some additional changes (like
adding 'int ret = 0' and 'return ret') as well as whitespace fixups
were also done manually after coccinelle.
A simplified version of the semantic patch is:
//
@@
identifier m,c,setmode;
@@
-void
+int
setmode(enum clock_event_mode m, struct clock_event_device *c);
@@
identifier setmode;
@@
-void
+int
setmode(enum clock_event_mode, struct clock_event_device *);
@fixret@
identifier m,c,setmode;
@@
-void
+int
setmode(enum clock_event_mode m, struct clock_event_device *c)
{
...
+ return 0;
}
@depends on fixret@
identifier ced;
identifier fixret.setmode;
@@
... struct clock_event_device ced = {
...,
-.set_mode
+.set_dev_mode
= setmode,
};
@depends on fixret@
expression ced;
identifier fixret.setmode;
@@
- ced->set_mode
+ ced->set_dev_mode
= setmode
@depends on fixret@
identifier fixret.setmode;
@@
{
.
-set_mode
+set_dev_mode
= setmode
}
@depends on fixret@
expression ced;
identifier fixret.setmode;
@@
- ced.set_mode
+ ced.set_dev_mode
= setmode
//
Signed-off-by: Viresh Kumar
Reviewed-by: Kevin Hilman
[khilman: rework changelog, minor formatting, checkpatch cleanups]
Signed-off-by: Kevin Hilman
---
drivers/clocksource/arm_arch_timer.c | 46 +---
drivers/clocksource/bcm2835_timer.c | 10 +++
drivers/clocksource/bcm_kona_timer.c | 15 ---
drivers/clocksource/i8253.c | 11 +---
drivers/clocksource/time-armada-370-xp.c | 21 +++
5 files changed, 65 insertions(+), 38 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 5163ec13429d..e139776be034 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -179,8 +179,8 @@ static irqreturn_t arch_timer_handler_virt_mem(int irq,
void *dev_id)
return timer_handler(ARCH_TIMER_MEM_VIRT_ACCESS, evt);
}
-static __always_inline void timer_set_mode(const int access, int mode,
- struct clock_event_device *clk)
+static __always_inline int timer_set_mode(const int access, int mode,
+ struct clock_event_device *clk)
{
unsigned long ctrl;
switch (mode) {
@@ -190,33 +190,37 @@ static __always_inline void timer_set_mode(const int
access, int mode,
ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
break;
- default:
+ case CLOCK_EVT_MODE_ONESHOT:
+ case CLOCK_EVT_MODE_RESUME:
break;
+ default:
+ return -ENOSYS;
}
+ return 0;
}
-static void arch_timer_set_mode_virt(enum clock_event_mode mode,
-struct clock_event_device *clk)
+static int arch_timer_set_mode_virt(enum clock_event_mode mode,
+ struct clock_event_device *clk)
{
- timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode, clk);
+ return timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode, clk);
}
-static void arch_timer_set_mode_phys(enum clock_event_mode mode,
-struct clock_event_device *clk)
+static int arch_timer_set_mode_phys(enum clock_event_mode mode,
+ struct clock_event_device *clk)
{
- timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
+ return timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
}
-static void arch_timer_set_mode_virt_mem(enum clock_event_mode mode,
-struct clock_event_device *clk)
+static int arch_timer_set_mode_virt_mem(enum clock_event_mode mode,
+ struct clock_event_device *clk)
{
- timer_set_mode(ARCH_TIMER_MEM_VIRT_ACCESS, mode, clk);
+ return timer_set_mode(ARCH_TIMER_MEM_VIRT_ACCESS, mode, clk);
}
-static void arch_timer_set_mode_phys_mem(enum clock_event_mode mode,
-struct clock_event_device *clk)
+static int arch_timer_set_mode_phys_mem(enum clock_event_mode mode,
+ struct clock_event_device *clk)
{
- timer_set_mode(ARCH_TIMER_MEM_PHYS_ACCESS, mode, clk);
+ return timer_set_mode(ARCH_TIMER_MEM_PHYS_ACCESS, mode, clk);
}
static __always_inline void set_next_event(const int access,
Re: [RFA][PATCH 18/27] sparc64,ftrace: Remove check of obsolete variable function_trace_stop
From: Steven Rostedt Date: Thu, 3 Jul 2014 12:41:46 -0400 > Do you have any problem with this patch going through my tree? It > compiles, but I do not have any hardware to test it. If you can verify > that this patch works and ack it, it would be much appreciated. > > This code is at: > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > > branch: rfc/remove-function-trace-stop I can look at this next week at the earliest. But frankly I have no problem if you just merge it as-is now, we can sort out any fallout later. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/16] MAINTAINERS: Update Samsunt MFD drivers pattern
On Fri, 2014-07-04 at 09:15 +0530, Sachin Kamat wrote: > In any case, if this patch is going to be appled, please fix typo in subject > > s/Samsunt/Samsung I think Sangboem is going to submit something appropriate instead. -- 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/
[block, blk] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
Hi Tejun,
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-mq-percpu_ref
commit c924ec35e72ce0d6c289b858d323f7eb3f5076a5 ("block, blk-mq: draining can't
be skipped even if bypass_depth was non-zero")
+--+++
| | ea854572ee |
c924ec35e7 |
+--+++
| boot_successes | 26 | 10
|
| early-boot-hang | 1 |
|
| boot_failures| 0 | 16
|
| BUG:unable_to_handle_kernel_NULL_pointer_dereference | 0 | 16
|
| Oops | 0 | 16
|
| RIP:blk_throtl_drain | 0 | 16
|
| kernel_BUG_at_arch/x86/mm/pageattr.c | 0 | 7
|
| invalid_opcode | 0 | 7
|
| RIP:change_page_attr_set_clr | 0 | 7
|
| Kernel_panic-not_syncing:Fatal_exception | 0 | 16
|
| backtrace:scsi_debug_exit| 0 | 6
|
| backtrace:SyS_delete_module | 0 | 6
|
| backtrace:do_vfs_ioctl | 0 | 10
|
| backtrace:SyS_ioctl | 0 | 10
|
+--+++
[ 522.186410] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
[ 522.368967] EXT4-fs (dm-0): recovery complete
[ 522.415305] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
[ 523.030685] BUG: unable to handle kernel NULL pointer dereference at
0028
[ 523.031682] IP: [] blk_throtl_drain+0x30/0x150
[ 523.031682] PGD a8d1c067 PUD a71fd067 PMD 0 [ 523.031682] Oops: [#1]
SMP [ 523.031682] Modules linked in: dm_flakey dm_mod fuse sg sr_mod cdrom
ata_generic pata_acpi cirrus syscopyarea snd_pcm sysfillrect snd_timer
sysimgblt floppy snd ttm soundcore parport_pc drm_kms_helper parport drm pcspkr
i2c_piix4 ata_piix libata
[ 523.031682] CPU: 0 PID: 30028 Comm: dmsetup Not tainted
3.16.0-rc1-01463-g94b6452 #1
[ 523.031682] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 523.031682] task: 88011560bb20 ti: 8800a6c7c000 task.ti:
8800a6c7c000
[ 523.031682] RIP: 0010:[] []
blk_throtl_drain+0x30/0x150
[ 523.031682] RSP: 0018:8800a6c7fb58 EFLAGS: 00010046
[ 523.031682] RAX: RBX: 88011503be40 RCX: 7fff
[ 523.031682] RDX: 0016 RSI: RDI:
[ 523.031682] RBP: 8800a6c7fb70 R08: R09: 0046
[ 523.031682] R10: 8800a6c7fb70 R11: 813dcbb1 R12: 88011503be40
[ 523.031682] R13: 8800d50a7700 R14: 88011503c498 R15:
[ 523.031682] FS: 7fa84cf11800() GS:88011fc0()
knlGS:
[ 523.031682] CS: 0010 DS: ES: CR0: 8005003b
[ 523.031682] CR2: 0028 CR3: 7ed12000 CR4: 06f0
[ 523.031682] Stack:
[ 523.031682] 88011503be40 88011503c4a8
8800a6c7fb80
[ 523.031682] 813cba6e 8800a6c7fbb0 813b0b6c
88011503be40
[ 523.031682] 81cf3920 88011503be40 8800aad17a00
8800a6c7fbc8
[ 523.031682] Call Trace:
[ 523.031682] [] blkcg_drain_queue+0xe/0x10
[ 523.031682] [] __blk_drain_queue+0x7c/0x180
[ 523.031682] [] blk_queue_bypass_start+0x8e/0xd0
[ 523.031682] [] blkcg_deactivate_policy+0x38/0x140
[ 523.031682] [] blk_throtl_exit+0x34/0x50
[ 523.031682] [] blkcg_exit_queue+0x48/0x70
[ 523.031682] [] blk_release_queue+0x26/0x100
[ 523.031682] [] kobject_cleanup+0x77/0x1b0
[ 523.031682] [] kobject_put+0x28/0x60
[ 523.031682] [] blk_cleanup_queue+0x119/0x1c0
[ 523.031682] [] __dm_destroy+0x1f3/0x280 [dm_mod]
[ 523.031682] [] dm_destroy+0x13/0x20 [dm_mod]
[ 523.031682] [] dev_remove+0x11e/0x180 [dm_mod]
[ 523.031682] [] ? dev_suspend+0x250/0x250 [dm_mod]
[ 523.031682] [] ctl_ioctl+0x269/0x500 [dm_mod]
[ 523.031682] [] ? extract_buf+0xbb/0x130
[ 523.031682] [] dm_ctl_ioctl+0x13/0x20 [dm_mod]
[ 523.031682] [] do_vfs_ioctl+0x300/0x520
[ 523.031682] [] ? file_has_perm+0x86/0xa0
[ 523.031682] [] SyS_ioctl+0x81/0xa0
[ 523.031682] [] system_call_fastpath+0x16/0x1b
[ 523.031682] Code: 55 65 ff 04 25 a0 c7 00 00 48 89 e5 41 55 41 54 49 89 fc
53 4c 8b af 40 07 00 00 49 8b 85 a0 00 00 00 31 ff 48 8b 80 c8 05 00 00 <48> 8b
70 28 e8 37 8d d2 ff 48 85 c0 48 89 c3
Re: [kernel/watchdog.c] ed235875e2c: -14.2% will-it-scale.scalability
Hi all,
Sorry please ignore this report: it seems there are no obvious
relationship between the code change and the regression.
Thanks,
Fengguang
On Fri, Jul 04, 2014 at 11:45:31AM +0800, Jet Chen wrote:
> Hi Aaron,
>
> FYI, we noticed the below changes on
>
> commit ed235875e2ca983197831337a986f0517074e1a0 ("kernel/watchdog.c: print
> traces for all cpus on lockup detection")
>
> test case: lkp-snb01/will-it-scale/signal1
>
> f3aca3d09525f87 ed235875e2ca983197831337a
> --- -
> 0.12 ~ 0% -14.2% 0.10 ~ 0% TOTAL will-it-scale.scalability
> 506146 ~ 0% -4.4% 484004 ~ 0% TOTAL
> will-it-scale.per_process_ops
> 12193 ~ 4% +12.6% 13726 ~ 6% TOTAL
> slabinfo.kmalloc-256.active_objs
> 12921 ~ 4% +12.3% 14516 ~ 5% TOTAL
> slabinfo.kmalloc-256.num_objs
> 123094 ~ 3% -6.5% 115117 ~ 3% TOTAL meminfo.Committed_AS
>
> Legend:
> ~XX%- stddev percent
> [+-]XX% - change percent
>
>
> will-it-scale.per_process_ops
>
> 515000 ++-+
> | .*.*.*.*. .*|
> 51 *+* *.*.* + .*. *. |
> 505000 ++ * *.*.*.*. .* .*.*.*. .*.*.*. + *.*.*.*.*.*
> | * * * *.* |
> 50 ++ |
> | |
> 495000 ++ |
> | |
> 49 ++ |
> 485000 ++O O O O O O |
> | O O O O O O O O OO |
> 48 O+O O O OO |
> | |
> 475000 ++-+
>
>
> [*] bisect-good sample
> [O] bisect-bad sample
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
> Thanks,
> Jet
>
> echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu11/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu12/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu14/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu16/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu17/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu18/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu19/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu20/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu21/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu22/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu23/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu24/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu25/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu26/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu27/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu28/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu29/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu30/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu31/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu8/cpufreq/scaling_governor
> echo performance >
Re: [PATCH 09/16] MAINTAINERS: Update Samsunt MFD drivers pattern
On Fri, Jul 4, 2014 at 5:23 AM, Sangbeom Kim wrote: > On Friday, July 04, 2014 7:08 AM, Joe Perches wrote: > >> F: drivers/regulator/s2m*.c >> F: drivers/regulator/s5m*.c >> -F: drivers/rtc/rtc-sec.c >> F: include/linux/mfd/samsung/ >> > > Yes, You are right. > There is no rtc-sec.c > Instead, rtc-s5m.c was upstreamed. > I will post update patch. Joe, In any case, if this patch is going to be appled, please fix typo in subject s/Samsunt/Samsung -- Regards, Sachin. -- 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/
[kernel/watchdog.c] ed235875e2c: -14.2% will-it-scale.scalability
Hi Aaron,
FYI, we noticed the below changes on
commit ed235875e2ca983197831337a986f0517074e1a0 ("kernel/watchdog.c: print
traces for all cpus on lockup detection")
test case: lkp-snb01/will-it-scale/signal1
f3aca3d09525f87 ed235875e2ca983197831337a
--- -
0.12 ~ 0% -14.2% 0.10 ~ 0% TOTAL will-it-scale.scalability
506146 ~ 0% -4.4% 484004 ~ 0% TOTAL will-it-scale.per_process_ops
12193 ~ 4% +12.6% 13726 ~ 6% TOTAL
slabinfo.kmalloc-256.active_objs
12921 ~ 4% +12.3% 14516 ~ 5% TOTAL slabinfo.kmalloc-256.num_objs
123094 ~ 3% -6.5% 115117 ~ 3% TOTAL meminfo.Committed_AS
Legend:
~XX%- stddev percent
[+-]XX% - change percent
will-it-scale.per_process_ops
515000 ++-+
| .*.*.*.*. .*|
51 *+* *.*.* + .*. *. |
505000 ++ * *.*.*.*. .* .*.*.*. .*.*.*. + *.*.*.*.*.*
| * * * *.* |
50 ++ |
| |
495000 ++ |
| |
49 ++ |
485000 ++O O O O O O |
| O O O O O O O O OO |
48 O+O O O OO |
| |
475000 ++-+
[*] bisect-good sample
[O] bisect-bad sample
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Jet
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu11/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu12/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu14/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu16/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu17/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu18/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu19/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu20/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu21/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu22/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu23/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu24/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu25/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu26/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu27/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu28/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu29/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu30/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu31/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu8/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu9/cpufreq/scaling_governor
./runtest.py signal1 25 1 8 16 24 32
Re: [PATCH 3/4] DRBG: fix memory corruption for AES192
Am Freitag, 4. Juli 2014, 11:12:35 schrieb Herbert Xu: Hi Herbert, > On Tue, Jul 01, 2014 at 05:08:48PM +0200, Stephan Mueller wrote: > > For the CTR DRBG, the drbg_state->scratchpad temp buffer (i.e. the > > memory location immediately before the drbg_state->tfm variable > > is the buffer that the BCC function operates on. BCC operates > > blockwise. Making the temp buffer drbg_statelen(drbg) in size is > > sufficient when the DRBG state length is a multiple of the block > > size. For AES192 this is not the case and the length for temp is > > insufficient (yes, that also means for such ciphers, the final > > output of all BCC rounds are truncated before used to update the > > state of the DRBG!!). > > > > The patch enlarges the temp buffer from drbg_statelen to > > drbg_statelen + drbg_blocklen to have sufficient space. > > > > Reported-by: Fengguang Wu > > Signed-off-by: Stephan Mueller > > BTW your patches were all corrupted by your mailer so I had to > fix them by hand. Please check the cryptodev tree to ensure > that my fixes are correct. The patch fixing the memory corruption is completely and correctly applied. Apologies for sending broken patches. If I shall resend them corrected, please let me know. > > In future please test your patches by applying your own patches > returned via the list. I will do that. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] DRBG: fix memory corruption for AES192
Am Freitag, 4. Juli 2014, 11:08:10 schrieb Herbert Xu: Hi Herbert, > On Tue, Jul 01, 2014 at 05:08:48PM +0200, Stephan Mueller wrote: > > For the CTR DRBG, the drbg_state->scratchpad temp buffer (i.e. the > > memory location immediately before the drbg_state->tfm variable > > is the buffer that the BCC function operates on. BCC operates > > blockwise. Making the temp buffer drbg_statelen(drbg) in size is > > sufficient when the DRBG state length is a multiple of the block > > size. For AES192 this is not the case and the length for temp is > > insufficient (yes, that also means for such ciphers, the final > > output of all BCC rounds are truncated before used to update the > > state of the DRBG!!). > > > > The patch enlarges the temp buffer from drbg_statelen to > > drbg_statelen + drbg_blocklen to have sufficient space. > > > > Reported-by: Fengguang Wu > > Signed-off-by: Stephan Mueller > > I have applied just this patch out of your series. You patches > depend on the previous four patches which I have not yet applied > since there are still outstanding issues with two of them. Thank you. The raised issues are for patches [1] and [2]. The issue around [1] is whether there is Kconfig solution for the problem of selecting at least one or more than one configure option from a set of options. This should avoid having a module init function with returns an error. The selection of DRBG cores shall allow the user to compile the DRBG to suit his needs and reduce the footprint of the DRBG. Since at least one DRBG core must be selected as otherwise the DRBG is meaningless. Unfortunately I have not found a solution with Kconfig and all given suggestions also did not lead to a solution. So, if anybody has a suggestion on how to solve the issue, I will try it out. Regarding [2], the issue is that ARRAY_SIZE returns different variable types on different platforms (e.g. unsigned long on x86_64 vs unsigned int on i386). Thus I have to use a type cast. This issue may be fixed by forcing a particular type to ARRAY_SIZE. Such change, however, may have quite some ripple effects throughout the kernel. Therefore, IMHO such a patch should not be made in the realm of the DRBG patchset and the type cast should be allowed. [1] https://lkml.org/lkml/2014/6/28/489 [2] https://lkml.org/lkml/2014/6/28/492 -- Ciao Stephan -- 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/
direct device assignment in nested VM
Hi All, Is direct device assignment in nested VM supported in the latest KVM mainline now? Thanks, Yaohui -- 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] Documentation: Fix typo in DocBook files
This patch fixed spelling typo in various template files within Documentation/Docbook. Signed-off-by: Masanari Iida --- Documentation/DocBook/gadget.tmpl | 2 +- Documentation/DocBook/genericirq.tmpl | 4 ++-- Documentation/DocBook/kernel-locking.tmpl | 2 +- Documentation/DocBook/libata.tmpl | 6 +++--- Documentation/DocBook/media_api.tmpl | 2 +- Documentation/DocBook/regulator.tmpl | 2 +- Documentation/DocBook/uio-howto.tmpl | 4 ++-- Documentation/DocBook/usb.tmpl| 2 +- Documentation/DocBook/writing-an-alsa-driver.tmpl | 2 +- 9 files changed, 13 insertions(+), 13 deletions(-) diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 4017f14..2c425d7 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl @@ -708,7 +708,7 @@ hardware level details could be very different. Systems need specialized hardware support to implement OTG, notably including a special Mini-AB jack -and associated transciever to support Dual-Role +and associated transceiver to support Dual-Role operation: they can act either as a host, using the standard Linux-USB host side driver stack, diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index 46347f6..59fb5c0 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl @@ -182,7 +182,7 @@ Each interrupt is described by an interrupt descriptor structure irq_desc. The interrupt is referenced by an 'unsigned int' numeric - value which selects the corresponding interrupt decription structure + value which selects the corresponding interrupt description structure in the descriptor structures array. The descriptor structure contains status information and pointers to the interrupt flow method and the interrupt chip structure @@ -470,7 +470,7 @@ if (desc->irq_data.chip->irq_eoi) To avoid copies of identical implementations of IRQ chips the core provides a configurable generic interrupt chip - implementation. Developers should check carefuly whether the + implementation. Developers should check carefully whether the generic chip fits their needs before implementing the same functionality slightly differently themselves. diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 19f2a5a..e584ee1 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1760,7 +1760,7 @@ as it would be on UP. -There is a furthur optimization possible here: remember our original +There is a further optimization possible here: remember our original cache code, where there were no reference counts and the caller simply held the lock whenever using the object? This is still possible: if you hold the lock, no one can delete the object, so you don't need to diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index deb71ba..d7fcdc5 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -677,7 +677,7 @@ and other resources, etc. - ATA_QCFLAG_ACTIVE is clared from qc->flags. + ATA_QCFLAG_ACTIVE is cleared from qc->flags. @@ -708,7 +708,7 @@ and other resources, etc. - qc->waiting is claread completed (in that order). + qc->waiting is cleared completed (in that order). @@ -1163,7 +1163,7 @@ and other resources, etc. Once sense data is acquired, this type of errors can be - handled similary to other SCSI errors. Note that sense data + handled similarly to other SCSI errors. Note that sense data may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such cases, the error should be considered as an ATA bus error and diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 4decb46..03f9a1f 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -68,7 +68,7 @@ several digital tv standards. While it is called as DVB API, in fact it covers several different video standards including DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated - to documment support also for DVB-S2, ISDB-T and ISDB-S. + to document support also for DVB-S2, ISDB-T and ISDB-S. The third part covers the Remote Controller API. The fourth part covers the Media Controller API. For additional information and for the latest development code, diff --git a/Documentation/DocBook/regulator.tmpl
Re: [PATCH RFC tip/core/rcu] Parallelize and economize NOCB kthread wakeups
On Thu, 2014-07-03 at 09:29 -0700, Paul E. McKenney wrote: > On Thu, Jul 03, 2014 at 07:48:40AM +0200, Mike Galbraith wrote: > > On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote: > > > On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote: > > > > > > NO_HZ_FULL is a property of a set of CPUs. isolcpus is supposed to go > > > > away as being a redundant interface to manage a single property of a set > > > > of CPUs, but it's perfectly fine for NO_HZ_FULL to add an interface to > > > > manage a single property of a set of CPUs. What am I missing? > > > > > > Well, for now, it can only be specified at build time or at boot time. > > > In theory, it is possible to change a CPU from being callback-offloaded > > > to not at runtime, but there would need to be an extremely good reason > > > for adding that level of complexity. Lots of "fun" races in there... > > > > Yeah, understood. > > > > (still it's a NO_HZ_FULL wart though IMHO, would be prettier and more > > usable if it eventually became unified with cpuset and learned how to > > tap-dance properly;) > > Agreed, it would in some sense be nice. What specifically do you need > it for? I personally have zero use for the thing (git/vi aren't particularly perturbation sensitive;). I'm just doing occasional drive-by testing from a distro perspective, how well does it work, what does it cost etc. > Are you really running workloads that generate large numbers of > callbacks spread across most of the CPUs? It was this sort of workload > that caused Rik's system to show scary CPU-time accumulation, due to > the high overhead of frequent one-to-many wakeups. > > If your systems aren't running that kind of high-callback-rate workload, > just set CONFIG_RCU_NOCB_CPU_ALL=y and don't worry about it. > > If your systems -are- running that kind of high-callback-rate workload, > but your system has fewer than 200 CPUs, ensure that you have enough > housekeeping CPUs to allow the grace-period kthread sufficient CPU time, > set CONFIG_RCU_NOCB_CPU_ALL=y and don't worry about it. > > If your systems -are- running that kind of high-callback-rate workload, > and your system has more than 200 CPUs, apply the following patch, > set CONFIG_RCU_NOCB_CPU_ALL=y and once again don't worry about it. ;-) Turn it on and don't worry about it is exactly what distros want the obscure feature with very few users to be. Last time I did a drive-by, my boxen said I should continue to worry about it ;-) -Mike -- 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: DNAME_INLINE_LEN versus CONFIG_GENERIC_LOCKBREAK
> IF you've turned on debugging options, then you've already lost more > performance that careful packing of the dentry slab cache gains you. > There's no point in carefully tuning DNAME_INLINE_LEN for debug > options - it's just code that will break and annoy people as debug > implementations change. lockbreak is not a debug option. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] DRBG: fix memory corruption for AES192
On Tue, Jul 01, 2014 at 05:08:48PM +0200, Stephan Mueller wrote: > For the CTR DRBG, the drbg_state->scratchpad temp buffer (i.e. the > memory location immediately before the drbg_state->tfm variable > is the buffer that the BCC function operates on. BCC operates > blockwise. Making the temp buffer drbg_statelen(drbg) in size is > sufficient when the DRBG state length is a multiple of the block > size. For AES192 this is not the case and the length for temp is > insufficient (yes, that also means for such ciphers, the final > output of all BCC rounds are truncated before used to update the > state of the DRBG!!). > > The patch enlarges the temp buffer from drbg_statelen to > drbg_statelen + drbg_blocklen to have sufficient space. > > Reported-by: Fengguang Wu > Signed-off-by: Stephan Mueller BTW your patches were all corrupted by your mailer so I had to fix them by hand. Please check the cryptodev tree to ensure that my fixes are correct. In future please test your patches by applying your own patches returned via the list. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] netxen: fix stats.rxdropped collection in get_ethtool_stats()
Please drop this wrong post and see V2.
Thanks,
Ethan
On 2014/7/4 22:48, Ethan Zhao wrote:
netxen driver has implemented netxen_nic_get_ethtool_stats() interface,
but doesn't collect stats.rxdropped in driver, so we will get
different statistic information while using ifconfig and ethtool.
this patch fills stats.rxdropped field with data from net core
with dev_get_stats() just as ixgbe driver does for some of its stats.
Tested with last netxen driver 4.0.82
Compiled with net-next branch 3.16-rc2
Signed-off-by: Ethan Zhao
Tested-by: Sriharsha Yadagudde
---
.../ethernet/qlogic/netxen/netxen_nic_ethtool.c| 42 +++
1 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index 4ca2c19..97fc2db 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -33,28 +33,36 @@
#include "netxen_nic.h"
#include "netxen_nic_hw.h"
+enum {NETDEV_STATS, NETXEN_STATS};
+
struct netxen_nic_stats {
char stat_string[ETH_GSTRING_LEN];
+ int type;
int sizeof_stat;
int stat_offset;
};
-#define NETXEN_NIC_STAT(m) sizeof(((struct netxen_adapter *)0)->m), \
+#define NETXEN_NIC_STAT(m) NETXEN_STATS, \
+ sizeof(((struct netxen_adapter *)0)->m), \
offsetof(struct netxen_adapter, m)
+#define NETXEN_NETDEV_STAT(m) NETDEV_STATS, \
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
+
#define NETXEN_NIC_PORT_WINDOW 0x1
#define NETXEN_NIC_INVALID_DATA 0xDEADBEEF
static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
{"xmit_called", NETXEN_NIC_STAT(stats.xmitcalled)},
{"xmit_finished", NETXEN_NIC_STAT(stats.xmitfinished)},
- {"rx_dropped", NETXEN_NIC_STAT(stats.rxdropped)},
- {"tx_dropped", NETXEN_NIC_STAT(stats.txdropped)},
+ {"rx_dropped", NETXEN_NETDEV_STAT(rx_dropped)},
+ {"tx_dropped", NETXEN_NIC_STAT(tx_dropped)},
{"csummed", NETXEN_NIC_STAT(stats.csummed)},
- {"rx_pkts", NETXEN_NIC_STAT(stats.rx_pkts)},
+ {"rx_pkts", NETXEN_NIC_STAT(rx_packets)},
{"lro_pkts", NETXEN_NIC_STAT(stats.lro_pkts)},
- {"rx_bytes", NETXEN_NIC_STAT(stats.rxbytes)},
- {"tx_bytes", NETXEN_NIC_STAT(stats.txbytes)},
+ {"rx_bytes", NETXEN_NIC_STAT(rx_bytes)},
+ {"tx_bytes", NETXEN_NIC_STAT(tx_bytes)},
};
#define NETXEN_NIC_STATS_LEN ARRAY_SIZE(netxen_nic_gstrings_stats)
@@ -679,11 +687,27 @@ netxen_nic_get_ethtool_stats(struct net_device *dev,
{
struct netxen_adapter *adapter = netdev_priv(dev);
int index;
+ struct rtnl_link_stats64 temp;
+ const struct rtnl_link_stats64 *net_stats;
+ char *p = NULL;
+ net_stats = dev_get_stats(dev, );
for (index = 0; index < NETXEN_NIC_STATS_LEN; index++) {
- char *p =
- (char *)adapter +
- netxen_nic_gstrings_stats[index].stat_offset;
+
+ switch (netxen_nic_gstrings_stats[index].type) {
+ case NETDEV_STATS:
+ p = (char *)net_stats +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ case NETXEN_STATS:
+ p = (char *)adapter +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ default:
+ data [index] = 0;
+ continue;
+ }
+
data[index] =
(netxen_nic_gstrings_stats[index].sizeof_stat ==
sizeof(u64)) ? *(u64 *) p : *(u32 *) p;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] DRBG: fix memory corruption for AES192
On Tue, Jul 01, 2014 at 05:08:48PM +0200, Stephan Mueller wrote: > For the CTR DRBG, the drbg_state->scratchpad temp buffer (i.e. the > memory location immediately before the drbg_state->tfm variable > is the buffer that the BCC function operates on. BCC operates > blockwise. Making the temp buffer drbg_statelen(drbg) in size is > sufficient when the DRBG state length is a multiple of the block > size. For AES192 this is not the case and the length for temp is > insufficient (yes, that also means for such ciphers, the final > output of all BCC rounds are truncated before used to update the > state of the DRBG!!). > > The patch enlarges the temp buffer from drbg_statelen to > drbg_statelen + drbg_blocklen to have sufficient space. > > Reported-by: Fengguang Wu > Signed-off-by: Stephan Mueller I have applied just this patch out of your series. You patches depend on the previous four patches which I have not yet applied since there are still outstanding issues with two of them. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: remove redundant code in machine_halt
> -Original Message- > From: Neil Zhang > Sent: 2014年5月14日 15:52 > To: Neil Zhang; linux-arm-ker...@lists.infradead.org; > linux-kernel@vger.kernel.org > Cc: rmk+ker...@arm.linux.org.uk > Subject: RE: [PATCH] ARM: remove redundant code in machine_halt > > > -Original Message- > > From: Neil Zhang [mailto:zhan...@marvell.com] > > Sent: 2014年5月7日 13:50 > > To: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org > > Cc: rmk+ker...@arm.linux.org.uk; Neil Zhang > > Subject: [PATCH] ARM: remove redundant code in machine_halt > > > > There is no need to call local_irq_disable twice. > > > > Signed-off-by: Neil Zhang > > --- > > arch/arm/kernel/process.c |1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index > > 81ef686..18cfce4 100644 > > --- a/arch/arm/kernel/process.c > > +++ b/arch/arm/kernel/process.c > > @@ -195,7 +195,6 @@ void machine_halt(void) > > local_irq_disable(); > > smp_send_stop(); > > > > - local_irq_disable(); > > while (1); > > } > > > > -- > > 1.7.9.5 > > Any comments? > Ping! > Best Regards, > Neil Zhang Best Regards, Neil Zhang
[PATCH] x86,kprobes: Don't try to resolve kprobe faults from userspace
This commit: commit 6f6343f53d133bae516caf3d254bce37d8774625 Author: Masami Hiramatsu Date: Thu Apr 17 17:17:33 2014 +0900 kprobes/x86: Call exception handlers directly from do_int3/do_debug Trying to dereference addr when addr is user-controlled is completely bogus. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/kprobes/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index 7596df6..67e6d19 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -574,6 +574,9 @@ int kprobe_int3_handler(struct pt_regs *regs) struct kprobe *p; struct kprobe_ctlblk *kcb; + if (user_mode_vm(regs)) + return 0; + addr = (kprobe_opcode_t *)(regs->ip - sizeof(kprobe_opcode_t)); /* * We don't want to be preempted for the entire -- 1.9.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/
Re: [PATCH] KVM: nVMX: Fix IRQs inject to L2 which belong to L1 since race
On Thu, Jul 03, 2014 at 01:27:05PM -0400, Bandan Das wrote: [...] ># modprobe kvm_intel ept=0 nested=1 enable_shadow_vmcs=0 > >The Host CPU - Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz >qemu cmd to run L1 - ># qemu-system-x86_64 -drive >file=level1.img,if=virtio,id=disk0,format=raw,cache=none,werror=stop,rerror=stop,aio=threads > -drive >file=level2.img,if=virtio,id=disk1,format=raw,cache=none,werror=stop,rerror=stop,aio=threads > -vnc :2 --enable-kvm -monitor stdio -m 4G -net nic,macaddr=00:23:32:45:89:10 >-net tap,ifname=tap0,script=/etc/qemu-ifup,downscript=no -smp 4 -cpu >Nehalem,+vmx -serial pty > >qemu cmd to run L2 - ># sudo qemu-system-x86_64 -hda VM/level2.img -vnc :0 --enable-kvm -monitor >stdio -m 2G -smp 2 -cpu Nehalem -redir tcp:::22 > >Additionally, >L0 is FC19 with 3.16-rc3 >L1 and L2 are Ubuntu 14.04 with 3.13.0-24-generic > >Then start a kernel compilation inside L2 with "make -j3" > >There's no call trace on L0, both L0 and L1 are hung (or rather really slow) >and >L1 serial spews out CPU softlock up errors. Enabling panic on softlockup on L1 >will give >a trace with smp_call_function_many() I think the corresponding code in >kernel/smp.c that >triggers this is > >WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() > && !oops_in_progress && !early_boot_irqs_disabled); > >I know in most cases this is usually harmless, but in this specific case, >it seems it's stuck here forever. > >Sorry, I don't have a L1 call trace handy atm, I can post that if you are >interested. > >Note that this can take as much as 30 to 40 minutes to appear but once it does, >you will know because both L1 and L2 will be stuck with the serial messages as >I mentioned >before. From my side, let me try this on another system to rule out any >machine specific >weirdness going on.. > Thanks for your pointing out. >Please let me know if you need any further information. > I just run kvm-unit-tests w/ vmx.flat and eventinj.flat. w/ vmx.flat and w/o my patch applied [...] Test suite : interrupt FAIL: direct interrupt while running guest PASS: intercepted interrupt while running guest FAIL: direct interrupt + hlt FAIL: intercepted interrupt + hlt FAIL: direct interrupt + activity state hlt FAIL: intercepted interrupt + activity state hlt PASS: running a guest with interrupt acknowledgement set SUMMARY: 69 tests, 6 failures w/ vmx.flat and w/ my patch applied [...] Test suite : interrupt PASS: direct interrupt while running guest PASS: intercepted interrupt while running guest PASS: direct interrupt + hlt FAIL: intercepted interrupt + hlt PASS: direct interrupt + activity state hlt PASS: intercepted interrupt + activity state hlt PASS: running a guest with interrupt acknowledgement set SUMMARY: 69 tests, 2 failures w/ eventinj.flat and w/o my patch applied SUMMARY: 13 tests, 0 failures w/ eventinj.flat and w/ my patch applied SUMMARY: 13 tests, 0 failures I'm not sure if the bug you mentioned has any relationship with "Fail: intercepted interrupt + hlt" which has already present before my patch. Regards, Wanpeng Li >Thanks >Bandan > >> Regards, >> Wanpeng Li >> >>>almost once in three times; it never happens if I run with ept=1, however, >>>I think that's only because the test completes sooner. But I can confirm >>>that I don't see it if I always set REQ_EVENT if nested_run_pending is set >>>instead of >>>the approach this patch takes. >>>(Any debug hints help appreciated!) >>> >>>So, I am not sure if this is the right fix. Rather, I think the safer thing >>>to do is to have the interrupt pending check for injection into L1 at >>>the "same site" as the call to kvm_queue_interrupt() just like we had before >>>commit b6b8a1451fc40412c57d1. Is there any advantage to having all the >>>nested events checks together ? >>> >>>PS - Actually, a much easier fix (or rather hack) is to return 1 in >>>vmx_interrupt_allowed() (as I mentioned elsewhere) only if >>>!is_guest_mode(vcpu) That way, the pending interrupt interrupt >>>can be taken care of correctly during the next vmexit. >>> >>>Bandan >>> Jan >> [...] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] staging: comedi: addi_apci_1564: miscellaneous fixes and cleanups
On Thu, Jul 3, 2014 at 4:39 AM, Ian Abbott wrote: > On 2014-07-03 03:15, Chase Southwood wrote: >> >> This patchset moves a misplaced include to the proper file, swaps out an >> overly >> aggressive placement of apci1564_reset(), and cleans up >> apci1564_interrupt(). >> >> Chase Southwood (3): >>staging: comedi: addi_apci_1564: move addi_watchdog.h include to >> addi_apci_1564.c >>staging: comedi: addi_apci_1564: fix use of apci1564_reset() to >> disable DI interrupts >>staging: comedi: addi_apci_1564: clean up apci1564_interrupt() >> >> .../comedi/drivers/addi-data/hwdrv_apci1564.c | 2 - >> drivers/staging/comedi/drivers/addi_apci_1564.c| 139 >> + >> 2 files changed, 32 insertions(+), 109 deletions(-) >> > > Looks good! You didn't list the v2 changes though. Maybe you could > summarize them here? I always forget to do _something_, don't I? Here are the changes: CHANGES FROM V1: *Patches 1 and 2 did not change. *In Patch 3, check for interrupts from unknown sources has been removed. *Individual status variables for the subdevices in the interrupt handler have been swapped out in favor of a single status variable that is reused for all subdevices. Thanks, Chase > > Reviewed-by: Ian Abbott > > > -- > -=( Ian Abbott @ MEV Ltd.E-mail: )=- > -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- -- 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: FW: [PATCH 04/16] MAINTAINERS: Update clk/sirf patterns
On Fri, 2014-07-04 at 09:33 +0800, Barry Song wrote:
> >> -Original Message-
> >> From: Joe Perches [mailto:j...@perches.com]
> >> Sent: Friday, July 04, 2014 6:08 AM
[]
> >> commit 7bf21bc81f28 ("clk: sirf: re-arch to make the codes support both
> >> prima2 and atlas6") moved the files, update the patterns.
[]
> >> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> >> @@ -894,7 +894,7 @@ L:linux-arm-ker...@lists.infradead.org
> >> (moderated for non-subscribers)
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git
> >> S: Maintained
> >> F: arch/arm/mach-prima2/
> >> -F: drivers/clk/clk-prima2.c
> >> +F: drivers/clk/sirf/
>
> has "N: [^a-z]sirf" included this?
Kinda. From MAINTAINERS:
N: Files and directories with regex patterns.
N: [^a-z]tegra all files whose path contains the word tegra
One pattern per line. Multiple N: lines acceptable.
scripts/get_maintainer.pl has different behavior for files that
match F: pattern and matches of N: patterns. By default,
get_maintainer will not look at git log history when an F: pattern
match occurs. When an N: match occurs, git log history is used
to also notify the people that have git commit signatures.
--
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: One bug of SDHCI driver
Hi, just use the MMC_CAP2_SDIO_IRQ_NOTHREAD? if (!err && host->sdio_irq && !(host->quirks & MMC_CAP2_SDIO_IRQ_NOTHREAD)) wake_up_process(host->sdio_irq_thread); I didn't test this..but i believe that it will be fixed. Best Regards, Jaehoon Chung On 07/04/2014 12:47 AM, Fu, Zhonghui wrote: > > Hi, all > > The statement "mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;" is added in > "sdhci_add_host" function in host/sdhci.c file. In some cases, this will make > "host->sdio_irq_thread" a NULL pointer in "mmc_sdio_resume" functon of > core/sdio.c file and lead to resume failure. Could you please give me some > advice how to fix this bug? > > > > Thanks, > Zhonghui > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] kvm, memory-hotplug: Update ept identity pagetable when it is migrated.
Hi Gleb, On 07/03/2014 12:34 AM, Gleb Natapov wrote: On Wed, Jul 02, 2014 at 05:00:36PM +0800, Tang Chen wrote: ept identity pagetable is pinned in memory, and as a result it cannot be migrated/hot-removed. But actually it doesn't need to be pinned in memory. This patch introduces a new vcpu request: KVM_REQ_MIGRATE_EPT to reset ept indetity pagetable related variable. This request will be made when kvm_mmu_notifier_invalidate_page() is called when the page is unmapped from the qemu user space to reset kvm->arch.ept_identity_pagetable to NULL. And will also be made when ept violation happens to reset kvm->arch.ept_identity_pagetable to the new page. kvm->arch.ept_identity_pagetable is never used as a page address, just boolean null/!null to see if identity pagetable is initialized. I do not see why would we want to track its address at all. Changing it to bool and assigning true during initialization should be enough. We already have kvm->arch.ept_identity_pagetable_done to indicate if the ept identity table is initialized. If we make kvm->arch.ept_identity_pagetable to bool, do you mean we have: kvm->arch.ept_identity_pagetable: indicate if ept page is allocated, kvm->arch.ept_identity_pagetable_done: indicate if ept page is initialized ? I don't think we need this. Shall we remove kvm->arch.ept_identity_pagetable ? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: video: fbdev: atmel_lcdfb.c: Add ability to inverted backlight PWM.
The code has a variable to change the polarity of the PWM backlight control but
it was not being initialized. This patch adds a devicetree entry to set the
variable if required.
Signed-off-by: Michael Welling
---
.../devicetree/bindings/video/atmel,lcdc.txt |1 +
drivers/video/fbdev/atmel_lcdfb.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt
b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
index 1ec175e..b75af94 100644
--- a/Documentation/devicetree/bindings/video/atmel,lcdc.txt
+++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
@@ -46,6 +46,7 @@ Required properties (as per of_videomode_helper):
Optional properties (as per of_videomode_helper):
- atmel,lcdcon-backlight: enable backlight
+ - atmel,lcdcon-backlight-inverted: invert backlight PWM polarity
- atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
- atmel,power-control-gpio: gpio to power on or off the LCD (as many as
needed)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c
b/drivers/video/fbdev/atmel_lcdfb.c
index d36e830..92640d4 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -290,7 +290,7 @@ static void init_contrast(struct atmel_lcdfb_info *sinfo)
/* contrast pwm can be 'inverted' */
if (pdata->lcdcon_pol_negative)
- contrast_ctr &= ~(ATMEL_LCDC_POL_POSITIVE);
+ contrast_ctr &= ~(ATMEL_LCDC_POL_POSITIVE);
/* have some default contrast/backlight settings */
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
@@ -1097,6 +1097,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info
*sinfo)
pdata->lcd_wiring_mode = ret;
pdata->lcdcon_is_backlight = of_property_read_bool(display_np,
"atmel,lcdcon-backlight");
+ pdata->lcdcon_pol_negative = of_property_read_bool(display_np,
"atmel,lcdcon-backlight-inverted");
timings = of_get_display_timings(display_np);
if (!timings) {
--
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 4/4] kvm, mem-hotplug: Update apic access page when it is migrated.
Hi Gleb,
Thanks for the advices. Please see below.
On 07/03/2014 09:55 PM, Gleb Natapov wrote:
..
@@ -575,6 +575,7 @@ struct kvm_arch {
unsigned int tss_addr;
struct page *apic_access_page;
+ bool apic_access_page_migrated;
Better have two requests KVM_REQ_APIC_PAGE_MAP, KVM_REQ_APIC_PAGE_UNMAP IMO.
vcpu->requests is an unsigned long, and we can only has 64 requests. Isn't
adding two requests for apic page and another similar two for ept page too
many ? Not sure.
gpa_t wall_clock;
@@ -739,6 +740,7 @@ struct kvm_x86_ops {
void (*hwapic_isr_update)(struct kvm *kvm, int isr);
void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
void (*set_virtual_x2apic_mode)(struct kvm_vcpu *vcpu, bool set);
+ void (*set_apic_access_page_addr)(struct kvm *kvm, hpa_t hpa);
void (*deliver_posted_interrupt)(struct kvm_vcpu *vcpu, int vector);
void (*sync_pir_to_irr)(struct kvm_vcpu *vcpu);
int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c0d72f6..a655444 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3436,6 +3436,21 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t
gpa, u32 error_code,
kvm_make_request(KVM_REQ_MIGRATE_EPT, vcpu);
}
+ if (gpa == VMX_APIC_ACCESS_PAGE_ADDR&&
+ vcpu->kvm->arch.apic_access_page_migrated) {
Why check arch.apic_access_page_migrated here? Isn't it enough that the fault
is on apic
address.
True. It's enough. Followed.
+ int i;
+
+ vcpu->kvm->arch.apic_access_page_migrated = false;
+
+ /*
+* We need update APIC_ACCESS_ADDR pointer in each VMCS of
+* all the online vcpus.
+*/
+ for (i = 0; i< atomic_read(>kvm->online_vcpus); i++)
+ kvm_make_request(KVM_REQ_MIGRATE_APIC,
+vcpu->kvm->vcpus[i]);
make_all_cpus_request(). You need to kick all vcpus from a guest mode.
OK, followed. But would you please explain more about this. :)
Why need to kick all vcpus from guest mode when making request to all
vcpus ?
+ }
+
spin_unlock(>kvm->mmu_lock);
return r;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c336cb3..abc152f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3988,7 +3988,7 @@ static int alloc_apic_access_page(struct kvm *kvm)
if (r)
goto out;
- page = gfn_to_page(kvm, VMX_APIC_ACCESS_PAGE_ADDR>> PAGE_SHIFT);
+ page = gfn_to_page_no_pin(kvm, VMX_APIC_ACCESS_PAGE_ADDR>> PAGE_SHIFT);
if (is_error_page(page)) {
r = -EFAULT;
goto out;
@@ -7075,6 +7075,12 @@ static void vmx_set_virtual_x2apic_mode(struct kvm_vcpu
*vcpu, bool set)
vmx_set_msr_bitmap(vcpu);
}
+static void vmx_set_apic_access_page_addr(struct kvm *kvm, hpa_t hpa)
+{
+ if (vm_need_virtualize_apic_accesses(kvm))
This shouldn't even been called if apic access page is not supported. Nor
mmu_notifier path neither tdp_page_fault path should ever see 0xfee0
address. BUG() is more appropriate here.
I don't quite understand. Why calling this function here will leed to bug ?
(Sorry, I'm not quite understand the internal of KVM. Please help.)
+ vmcs_write64(APIC_ACCESS_ADDR, hpa);
+}
+
static void vmx_hwapic_isr_update(struct kvm *kvm, int isr)
{
u16 status;
@@ -8846,6 +8852,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.enable_irq_window = enable_irq_window,
.update_cr8_intercept = update_cr8_intercept,
.set_virtual_x2apic_mode = vmx_set_virtual_x2apic_mode,
+ .set_apic_access_page_addr = vmx_set_apic_access_page_addr,
svm needs that too.
OK, will add one for svm.
.vm_has_apicv = vmx_vm_has_apicv,
.load_eoi_exitmap = vmx_load_eoi_exitmap,
.hwapic_irr_update = vmx_hwapic_irr_update,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a26524f..14e7174 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5943,6 +5943,24 @@ static void vcpu_migrated_page_update_ept(struct
kvm_vcpu *vcpu)
}
}
+static void vcpu_migrated_page_update_apic(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = vcpu->kvm;
+
+ if (kvm->arch.apic_access_page_migrated) {
+ if (kvm->arch.apic_access_page)
+ kvm->arch.apic_access_page = pfn_to_page(0);
All vcpus will access apic_access_page without locking here. May be
set kvm->arch.apic_access_page to zero in mmu_notifier and here call
kvm_x86_ops->set_apic_access_page_addr(kvm, kvm->arch.apic_access_page);
I'm a little confused. apic access page's phys_addr is stored in vmcs, and
I think it will be used by vcpu directly to access the physical page.
Setting kvm->arch.apic_access_page to zero will not stop
Re: [PATCH 4/4] kvm, mem-hotplug: Update apic access page when it is migrated.
Hi Gleb,
Thanks for the advices. Please see below.
On 07/03/2014 09:55 PM, Gleb Natapov wrote:
..
@@ -575,6 +575,7 @@ struct kvm_arch {
unsigned int tss_addr;
struct page *apic_access_page;
+ bool apic_access_page_migrated;
Better have two requests KVM_REQ_APIC_PAGE_MAP, KVM_REQ_APIC_PAGE_UNMAP IMO.
vcpu->requests is an unsigned long, and we can only has 64 requests. Isn't
adding two requests for apic page and another similar two for ept page too
many ? Not sure.
gpa_t wall_clock;
@@ -739,6 +740,7 @@ struct kvm_x86_ops {
void (*hwapic_isr_update)(struct kvm *kvm, int isr);
void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
void (*set_virtual_x2apic_mode)(struct kvm_vcpu *vcpu, bool set);
+ void (*set_apic_access_page_addr)(struct kvm *kvm, hpa_t hpa);
void (*deliver_posted_interrupt)(struct kvm_vcpu *vcpu, int vector);
void (*sync_pir_to_irr)(struct kvm_vcpu *vcpu);
int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c0d72f6..a655444 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3436,6 +3436,21 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t
gpa, u32 error_code,
kvm_make_request(KVM_REQ_MIGRATE_EPT, vcpu);
}
+ if (gpa == VMX_APIC_ACCESS_PAGE_ADDR&&
+ vcpu->kvm->arch.apic_access_page_migrated) {
Why check arch.apic_access_page_migrated here? Isn't it enough that the fault
is on apic
address.
True. It's enough. Followed.
+ int i;
+
+ vcpu->kvm->arch.apic_access_page_migrated = false;
+
+ /*
+* We need update APIC_ACCESS_ADDR pointer in each VMCS of
+* all the online vcpus.
+*/
+ for (i = 0; i< atomic_read(>kvm->online_vcpus); i++)
+ kvm_make_request(KVM_REQ_MIGRATE_APIC,
+vcpu->kvm->vcpus[i]);
make_all_cpus_request(). You need to kick all vcpus from a guest mode.
OK, followed. But would you please explain more about this. :)
Why need to kick all vcpus from guest mode when making request to all
vcpus ?
+ }
+
spin_unlock(>kvm->mmu_lock);
return r;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c336cb3..abc152f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3988,7 +3988,7 @@ static int alloc_apic_access_page(struct kvm *kvm)
if (r)
goto out;
- page = gfn_to_page(kvm, VMX_APIC_ACCESS_PAGE_ADDR>> PAGE_SHIFT);
+ page = gfn_to_page_no_pin(kvm, VMX_APIC_ACCESS_PAGE_ADDR>> PAGE_SHIFT);
if (is_error_page(page)) {
r = -EFAULT;
goto out;
@@ -7075,6 +7075,12 @@ static void vmx_set_virtual_x2apic_mode(struct kvm_vcpu
*vcpu, bool set)
vmx_set_msr_bitmap(vcpu);
}
+static void vmx_set_apic_access_page_addr(struct kvm *kvm, hpa_t hpa)
+{
+ if (vm_need_virtualize_apic_accesses(kvm))
This shouldn't even been called if apic access page is not supported. Nor
mmu_notifier path neither tdp_page_fault path should ever see 0xfee0
address. BUG() is more appropriate here.
I don't quite understand. Why calling this function here will leed to bug ?
(Sorry, I'm not quite understand the internal of KVM. Please help.)
+ vmcs_write64(APIC_ACCESS_ADDR, hpa);
+}
+
static void vmx_hwapic_isr_update(struct kvm *kvm, int isr)
{
u16 status;
@@ -8846,6 +8852,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.enable_irq_window = enable_irq_window,
.update_cr8_intercept = update_cr8_intercept,
.set_virtual_x2apic_mode = vmx_set_virtual_x2apic_mode,
+ .set_apic_access_page_addr = vmx_set_apic_access_page_addr,
svm needs that too.
OK, will add one for svm.
.vm_has_apicv = vmx_vm_has_apicv,
.load_eoi_exitmap = vmx_load_eoi_exitmap,
.hwapic_irr_update = vmx_hwapic_irr_update,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a26524f..14e7174 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5943,6 +5943,24 @@ static void vcpu_migrated_page_update_ept(struct
kvm_vcpu *vcpu)
}
}
+static void vcpu_migrated_page_update_apic(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = vcpu->kvm;
+
+ if (kvm->arch.apic_access_page_migrated) {
+ if (kvm->arch.apic_access_page)
+ kvm->arch.apic_access_page = pfn_to_page(0);
All vcpus will access apic_access_page without locking here. May be
set kvm->arch.apic_access_page to zero in mmu_notifier and here call
kvm_x86_ops->set_apic_access_page_addr(kvm, kvm->arch.apic_access_page);
I'm a little confused. apic access page's phys_addr is stored in vmcs, and
I think it will be used by vcpu directly to access the physical page.
Setting kvm->arch.apic_access_page to zero will not stop
Re: [PATCH] ACPI / EC: Free saved_ec on error exit path
2014-07-03 7:35 GMT+08:00 Colin King :
> From: Colin Ian King
>
> Smatch detected two memory leaks on saved_ec:
>
> drivers/acpi/ec.c:1070 acpi_ec_ecdt_probe() warn: possible
> memory leak of 'saved_ec'
> drivers/acpi/ec.c:1109 acpi_ec_ecdt_probe() warn: possible
> memory leak of 'saved_ec'
>
> Free saved_ec on these two error exit paths to stop the memory
> leak. Note that saved_ec maybe null, but kfree on null is allowed.
>
Acked-by: Lan Tianyu
> Signed-off-by: Colin Ian King
> ---
> drivers/acpi/ec.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index ad11ba4..9800f50 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -1066,8 +1066,10 @@ int __init acpi_ec_ecdt_probe(void)
> /* fall through */
> }
>
> - if (EC_FLAGS_SKIP_DSDT_SCAN)
> + if (EC_FLAGS_SKIP_DSDT_SCAN) {
> + kfree(saved_ec);
> return -ENODEV;
> + }
>
> /* This workaround is needed only on some broken machines,
> * which require early EC, but fail to provide ECDT */
> @@ -1105,6 +1107,7 @@ install:
> }
> error:
> kfree(boot_ec);
> + kfree(saved_ec);
> boot_ec = NULL;
> return -ENODEV;
> }
> --
> 2.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards
Tianyu Lan
--
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, 3.16-rc] rwsem: optimistic spinning causing performance degradation
On Thu, 2014-07-03 at 18:46 -0700, Jason Low wrote:
> On Fri, 2014-07-04 at 11:01 +1000, Dave Chinner wrote:
> > FWIW, the rwsems in the struct xfs_inode are often heavily
> > read/write contended, so there are lots of IO related workloads that
> > are going to regress on XFS without this optimisation...
> >
> > Anyway, consider the patch:
> >
> > Tested-by: Dave Chinner
>
> Hi Dave,
>
> Thanks for testing. I'll update the patch with an actual changelog.
---
Subject: [PATCH] rwsem: In rwsem_can_spin_on_owner(), return false if no owner
It was found that the rwsem optimistic spinning feature can potentially degrade
performance when there are readers. Perf profiles indicate in some workloads
that significant time can be spent spinning on !owner. This is because we don't
set the lock owner when readers(s) obtain the rwsem.
In this patch, we'll modify rwsem_can_spin_on_owner() such that we'll return
false if there is no lock owner. The rationale is that if we just entered the
slowpath, yet there is no lock owner, then there is a possibility that a reader
has the lock. To be conservative, we'll avoid spinning in these situations.
Dave Chinner found performance benefits with this patch in the xfs_repair
workload, where the total run time went from approximately 4 minutes 24 seconds,
down to approximately 1 minute 26 seconds with the patch.
Tested-by: Dave Chinner
Signed-off-by: Jason Low
---
kernel/locking/rwsem-xadd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index dacc321..c40c7d2 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -285,10 +285,10 @@ static inline bool rwsem_try_write_lock_unqueued(struct
rw_semaphore *sem)
static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
{
struct task_struct *owner;
- bool on_cpu = true;
+ bool on_cpu = false;
if (need_resched())
- return 0;
+ return false;
rcu_read_lock();
owner = ACCESS_ONCE(sem->owner);
@@ -297,9 +297,9 @@ static inline bool rwsem_can_spin_on_owner(struct
rw_semaphore *sem)
rcu_read_unlock();
/*
-* If sem->owner is not set, the rwsem owner may have
-* just acquired it and not set the owner yet or the rwsem
-* has been released.
+* If sem->owner is not set, yet we have just recently entered the
+* slowpath, then there is a possibility reader(s) may have the lock.
+* To be safe, avoid spinning in these situations.
*/
return on_cpu;
}
--
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: [regression, 3.16-rc] rwsem: optimistic spinning causing performance degradation
On Fri, 2014-07-04 at 11:01 +1000, Dave Chinner wrote: > [re-added lkml] > > On Thu, Jul 03, 2014 at 11:50:20AM -0700, Jason Low wrote: > > On Wed, Jul 2, 2014 at 7:32 PM, Dave Chinner wrote: > > > This is what the kernel profile looks like on the strided run: > > > > > > - 83.06% [kernel] [k] osq_lock > > >- osq_lock > > > - 100.00% rwsem_down_write_failed > > > - call_rwsem_down_write_failed > > > - 99.55% sys_mprotect > > > tracesys > > > __GI___mprotect > > > - 12.02% [kernel] [k] rwsem_down_write_failed > > > > Hi Dave, > > > > So with no sign of rwsem_spin_on_owner(), yet with such heavy contention in > > osq_lock, this makes me wonder if it's spending most of its time spinning > > on !owner while a reader has the lock? (We don't set sem->owner for the > > readers.) > > > > If that's an issue, maybe the below is worth a test, in which we'll just > > avoid spinning if rwsem_can_spin_on_owner() finds that there is no owner. > > If we just had to enter the slowpath yet there is no owner, we'll be > > conservative > > and assume readers have the lock. > > That makes it quite a bit faster: > > XFS_REPAIR SummaryFri Jul 4 10:39:32 2014 > > Phase Start End Duration > Phase 1:07/04 10:38:04 07/04 10:38:05 1 second > Phase 2:07/04 10:38:05 07/04 10:38:08 3 seconds > Phase 3:07/04 10:38:08 07/04 10:39:12 1 minute, 4 seconds > Phase 4:07/04 10:39:12 07/04 10:39:21 9 seconds > Phase 5:07/04 10:39:21 07/04 10:39:22 1 second > Phase 6:07/04 10:39:22 07/04 10:39:30 8 seconds > Phase 7:07/04 10:39:30 07/04 10:39:30 > > Total run time: 1 minute, 26 seconds > done > > real1m28.504s > user1m23.990s > sys 3m20.132s > > So system time goes down massively, and speed comes up to within 30% > of the single AG run. But it's still 2-3000 IOPS down, but it's > acceptible for the moment. > > FWIW, the kernel profile ifor the multi-AG run now looks like: > > 29.64% [kernel] [k] _raw_spin_unlock_irq >- _raw_spin_unlock_irq > + 35.34% __schedule > - 34.15% call_rwsem_down_write_failed > + 99.27% sys_mprotect > - 30.02% call_rwsem_down_read_failed >95.59% __do_page_fault > - 24.65% [kernel] [k] _raw_spin_unlock_irqrestore >- _raw_spin_unlock_irqrestore > - 69.38% rwsem_wake > - call_rwsem_wake > - 83.32% sys_mprotect > + 15.54% __do_page_fault > + 22.55% try_to_wake_up > + 9.77% [kernel] [k] default_send_IPI_mask_sequence_phys > - 3.21% [kernel] [k] smp_call_function_many >- smp_call_function_many > - 99.22% flush_tlb_page > + 2.51% [kernel] [k] rwsem_down_write_failed > > It's much more like the 3.15 profile - it's only wasting half the > CPU spinning on the internal spinlock and it's now going fast enough > to be blowing another 10-12% of the CPU time sending tlb flushes to > other CPUs > > One thing I did notice, even with the single-AG-at-a-time run, is > that the system time is *significantly* reduced with this patch, > even though it doesn't change performance. > > ie unpatched: > > unpatched patched > runtime 0m58s 1m2s > systime 4m55s 1m1s > > So not spinning when there are read holders is a major win even > when there are few threads contending on read/write. > > FWIW, the rwsems in the struct xfs_inode are often heavily > read/write contended, so there are lots of IO related workloads that > are going to regress on XFS without this optimisation... > > Anyway, consider the patch: > > Tested-by: Dave Chinner Hi Dave, Thanks for testing. I'll update the patch with an actual changelog. -- 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] define PAGECACHE_TAG_* as enumeration under include/uapi
On Fri, Jul 04, 2014 at 11:16:39AM +1000, Dave Chinner wrote: > On Thu, Jul 03, 2014 at 05:52:12PM -0400, Naoya Horiguchi wrote: > > We need the pagecache tags to be exported to userspace later in this > > series for fincore(2), so this patch moves the definition to the new > > include file for preparation. We also use the number of pagecache tags, > > so this patch also adds it. > > > > Signed-off-by: Naoya Horiguchi > > NACK. > > The radix tree tags are deeply internal implementation details. > They are an artifact of the current mark-and-sweep writeback > algorithm, and as such should never, ever be exposed to userspace, > let alone fixed in an ABI we need to support forever more. Hm, OK, so I'll do whole this series without pagecache tag things. Thanks, Naoya Horiguchi -- 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] [sched] Don't account time after deadline twice
We calculate difference between two readings of a clock to see how
much time has elapsed. Part of the time between rq_clock(rq) -
dl_se->deadline can indeed be accounted for by reading a different
clock
(i.e., rq_clock_task()) if the task was running during the period.
And that is how dl_se->runtime is obtained. After all, both clocks are
running independently, right? Furthermore, the caller of
dl_runtime_exceeded() will still use rq_clock() and dl_se->deadline to
determine if we throttle or replenish. Anyway, I have failed to see
any steal of time. Could you please give a concrete example (perhaps
with numbers)?
thanks,
-Zhihui
On Thu, Jul 3, 2014 at 5:50 AM, Juri Lelli wrote:
> On Wed, 2 Jul 2014 19:44:04 -0400
> Zhihui Zhang wrote:
>
>> My point is that rq_clock(rq) - dl_se->deadline is already part of
>> dl_se->runtime, which is decremented before calling dl_runtime_exceeded().
>
> But, we decrement dl_se->runtime looking at rq_clock_task(rq), that is
> in general <= rq_clock(rq), that we use to handle deadlines. So, if we
> do like you suggest, in some cases we could end up stealing some
> bandwidth from the system. Indeed, we prefer some pessimism here.
>
> Thanks,
>
> - Juri
>
>> So the following line is not needed in the case of both overrun and missing
>> deadline:
>>
>> dl_se->runtime -= rq_clock(rq) - dl_se->deadline;
>>
>> Or did I miss anything?
>>
>> thanks,
>>
>>
>> On Tue, Jul 1, 2014 at 9:59 AM, Juri Lelli wrote:
>>
>> > On Tue, 1 Jul 2014 15:08:16 +0200
>> > Peter Zijlstra wrote:
>> >
>> > > On Sun, Jun 29, 2014 at 09:26:10PM -0400, Zhihui Zhang wrote:
>> > > > Unless we want to double-penalize an overrun task, the time after the
>> > deadline
>> > > > and before the current time is already accounted in the negative
>> > dl_se->runtime
>> > > > value. So we can leave it as is in the case of dmiss && rorun.
>> > >
>> > > Juri?
>> > >
>> > > > Signed-off-by: Zhihui Zhang
>> > > > ---
>> > > > kernel/sched/deadline.c | 6 ++
>> > > > 1 file changed, 2 insertions(+), 4 deletions(-)
>> > > >
>> > > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
>> > > > index fc4f98b1..67df0d6 100644
>> > > > --- a/kernel/sched/deadline.c
>> > > > +++ b/kernel/sched/deadline.c
>> > > > @@ -579,10 +579,8 @@ int dl_runtime_exceeded(struct rq *rq, struct
>> > sched_dl_entity *dl_se)
>> > > > * the next instance. Thus, if we do not account that, we are
>> > > > * stealing bandwidth from the system at each deadline miss!
>> > > > */
>> > > > - if (dmiss) {
>> > > > - dl_se->runtime = rorun ? dl_se->runtime : 0;
>> >
>> > If we didn't return 0 before, we are going to throttle (or replenish)
>> > the entity, and you want runtime to be <=0. So, this is needed.
>> >
>> > > > - dl_se->runtime -= rq_clock(rq) - dl_se->deadline;
>> > > > - }
>> >
>> > A little pessimism in some cases, due to the fact that we use both
>> > rq_clock and rq_clock_task (for the budget).
>> >
>> > Thanks,
>> >
>> > - Juri
>> >
>> > > > + if (dmiss && !rorun)
>> > > > + dl_se->runtime = dl_se->deadline - rq_clock(rq);
>> > > >
>> > > > return 1;
>> > > > }
>> > > > --
>> > > > 1.8.1.2
>> > > >
>> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the net tree
Hi all,
After merging the net tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "phy_resume" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
Caused by commit 0acf16768740 ("net: stmmac: add platform init/exit for
Altera's ARM socfpga").
I reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: FW: [PATCH 04/16] MAINTAINERS: Update clk/sirf patterns
>> -Original Message-
>> From: Joe Perches [mailto:j...@perches.com]
>> Sent: Friday, July 04, 2014 6:08 AM
>> To: Andrew Morton
>> Cc: Barry Song; linux-kernel@vger.kernel.org
>> Subject: [PATCH 04/16] MAINTAINERS: Update clk/sirf patterns
>>
>> commit 7bf21bc81f28 ("clk: sirf: re-arch to make the codes support both
>> prima2 and atlas6") moved the files, update the patterns.
>>
>> Signed-off-by: Joe Perches
>> cc: Barry Song
>> ---
>> MAINTAINERS | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e3531a5..90ee3d6 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -894,7 +894,7 @@ L:linux-arm-ker...@lists.infradead.org
>> (moderated for non-subscribers)
>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git
>> S: Maintained
>> F: arch/arm/mach-prima2/
>> -F: drivers/clk/clk-prima2.c
>> +F: drivers/clk/sirf/
has "N: [^a-z]sirf" included this?
>> F: drivers/clocksource/timer-prima2.c
>> F: drivers/clocksource/timer-marco.c
>> N: [^a-z]sirf
>> --
>> 1.8.1.2.459.gbcd45b4.dirty
-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: DNAME_INLINE_LEN versus CONFIG_GENERIC_LOCKBREAK
On Thu, Jul 03, 2014 at 12:53:01PM -0700, Andi Kleen wrote: > Rasmus Villemoes writes: > > > In dcache.h, DNAME_INLINE_LEN is carefully chosen so that sizeof(struct > > dentry) is a (specific) multiple of 64 bytes. Obviously this breaks when > > certain debug options are chosen (DEBUG_LOCK_ALLOC and DEBUG_SPINLOCK), > > but also, AFAICT, on architectures with CONFIG_GENERIC_LOCKBREAK. > > > > I'm not sure it matters, but if it does, I'd suggest putting a > > BUILD_BUG_ON somewhere, protected by suitable #ifdefs, so that the code > > documents the assumptions that went into the particular choice of > > DNAME_INLINE_LEN (this would also help catch changes to some of the > > structures embedded in struct dentry which would violate those > > assumptions). > > The right fix would be to pad it correctly for these other variants > too. IF you've turned on debugging options, then you've already lost more performance that careful packing of the dentry slab cache gains you. There's no point in carefully tuning DNAME_INLINE_LEN for debug options - it's just code that will break and annoy people as debug implementations change. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k: Remove FIXME comment in file sun3_pgalloc.h
On Wed, 2 Jul 2014, Nicholas Krause wrote: > Removes a FIXME comment in this file due to it not compiling as it now > compiles. What got fixed? It doesn't say "FIXME - this doesn't compile". > > Signed-off-by: Nicholas Krause > --- > arch/m68k/include/asm/sun3_pgalloc.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/m68k/include/asm/sun3_pgalloc.h > b/arch/m68k/include/asm/sun3_pgalloc.h > index f868506..1798f25 100644 > --- a/arch/m68k/include/asm/sun3_pgalloc.h > +++ b/arch/m68k/include/asm/sun3_pgalloc.h > @@ -12,7 +12,6 @@ > > #include > > -/* FIXME - when we get this compiling */ > /* erm, now that it's compiling, what do we do with it? */ > #define _KERNPG_TABLE 0 > > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/rtc/interface.c: check the error after __rtc_read_time()
In __rtc_set_alarm(), the error after __rtc_read_time() is not checked. If rtc device fail to read time, we cannot guarantee the following process. Add the verification code for returned __rtc_read_time() error. Signed-off-by: Hyogi Gim --- drivers/rtc/interface.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index 5813fa5..5b2717f 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -348,6 +348,8 @@ static int __rtc_set_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm) /* Make sure we're not setting alarms in the past */ err = __rtc_read_time(rtc, ); + if (err) + return err; rtc_tm_to_time(, ); if (scheduled <= now) return -ETIME; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] define PAGECACHE_TAG_* as enumeration under include/uapi
On Thu, Jul 03, 2014 at 05:52:12PM -0400, Naoya Horiguchi wrote: > We need the pagecache tags to be exported to userspace later in this > series for fincore(2), so this patch moves the definition to the new > include file for preparation. We also use the number of pagecache tags, > so this patch also adds it. > > Signed-off-by: Naoya Horiguchi NACK. The radix tree tags are deeply internal implementation details. They are an artifact of the current mark-and-sweep writeback algorithm, and as such should never, ever be exposed to userspace, let alone fixed in an ABI we need to support forever more. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] USB: EHCI: tegra: Fix probe order issue leading to broken USB
The Tegra USB complex has a particularly annoying misdesign: some of the
UTMI pad configuration registers are global for all the 3 USB controllers
on the chip, but those registers are located in the first controller's
register space and will be cleared when the reset to the first
controller is asserted. Currently, this means that if the 1st controller
were to finish probing after the 2nd or 3rd controller, USB would not
work at all.
Fix this situation by always resetting the 1st controller before doing
any other setup to any of the controllers, and then never ever reset the
first controller again. As the UTMI registers are related to the PHY,
the PHY driver should probably reset the Tegra controllers instead,
but since old device trees only have reset phandles in the EHCI nodes,
do it here, which means a bit of device tree groveling. Those old DTs
also won't get the reset fix from this commit, so we'll dev_warn() them,
but the driver will still keep probing successfully.
Signed-off-by: Tuomas Tynkkynen
---
v2 changes: assume we can find the usb1 reset from the PHY DT node,
don't fail if it's not found but just issue a warning
drivers/usb/host/ehci-tegra.c | 62 +++--
1 file changed, 59 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 5590567..f495775 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -46,6 +46,7 @@
#define DRV_NAME "tegra-ehci"
static struct hc_driver __read_mostly tegra_ehci_hc_driver;
+static bool usb1_reset_attempted;
struct tegra_ehci_soc_config {
bool has_hostpc;
@@ -60,6 +61,61 @@ struct tegra_ehci_hcd {
enum tegra_usb_phy_port_speed port_speed;
};
+/*
+ * The 1st USB controller contains some UTMI pad registers that are global for
+ * all the controllers on the chip. Those registers are also cleared when
+ * reset is asserted to the 1st controller. This means that the 1st controller
+ * can only be reset when no other controlled has finished probing. So we'll
+ * reset the 1st controller before doing any other setup on any of the
+ * controllers, and then never again.
+ *
+ * Since this is a PHY issue, the Tegra PHY driver should probably be doing
+ * the resetting of the USB controllers. But to keep compatibility with old
+ * device trees that don't have reset phandles in the PHYs, do it here.
+ * Those old DTs will be vulnerable to total USB breakage if the 1st EHCI
+ * device isn't the first one to finish probing, so warn them.
+ */
+static int tegra_reset_usb_controller(struct platform_device *pdev)
+{
+ struct device_node *phy_np;
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct tegra_ehci_hcd *tegra =
+ (struct tegra_ehci_hcd *)hcd_to_ehci(hcd)->priv;
+
+ phy_np = of_parse_phandle(pdev->dev.of_node, "nvidia,phy", 0);
+ if (!phy_np)
+ return -ENOENT;
+
+ if (!usb1_reset_attempted) {
+ struct reset_control *usb1_reset;
+
+ usb1_reset = of_reset_control_get(phy_np, "usb");
+ if (IS_ERR(usb1_reset)) {
+ dev_warn(>dev,
+"can't get utmi-pads reset from the PHY\n");
+ dev_warn(>dev,
+"continuing, but please update your DT\n");
+ } else {
+ reset_control_assert(usb1_reset);
+ udelay(1);
+ reset_control_deassert(usb1_reset);
+ }
+
+ reset_control_put(usb1_reset);
+ usb1_reset_attempted = true;
+ }
+
+ if (!of_property_read_bool(phy_np, "nvidia,has-utmi-pad-registers")) {
+ reset_control_assert(tegra->rst);
+ udelay(1);
+ reset_control_deassert(tegra->rst);
+ }
+
+ of_node_put(phy_np);
+
+ return 0;
+}
+
static int tegra_ehci_internal_port_reset(
struct ehci_hcd *ehci,
u32 __iomem *portsc_reg
@@ -389,9 +445,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
if (err)
goto cleanup_hcd_create;
- reset_control_assert(tegra->rst);
- udelay(1);
- reset_control_deassert(tegra->rst);
+ err = tegra_reset_usb_controller(pdev);
+ if (err)
+ goto cleanup_clk_en;
u_phy = devm_usb_get_phy_by_phandle(>dev, "nvidia,phy", 0);
if (IS_ERR(u_phy)) {
--
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/
[PATCH v2 0/4] Tegra USB probe order issue fix
Hi all, Here's a second version of the probe order issue series. This time I've added the USB1 resets to the PHYs, thus replacing the really ugly parts with something slightly better. Old device trees will still probe successfully, but instead of this bugfix they'll get a dev_warn(). The reset control patch was dropped, as a similar patch from someone else has landed in linux-next. For a recap of the issue from the previous series: Basically, the register area of the 1st USB controller contains some registers that are global to all of the controllers, but that are also cleared when reset is asserted to the 1st controller. So if (say) the 3rd controller would be the first one to finish probing successfully, then the reset that happens during the 1st controller's probe would result in broken USB. So the before doing anything with the USB HW, we should reset the 1st controller once, and then never ever reset it again. While testing that the 1st USB controller still works without a reset when the driver is unbound and bound again, I discovered an unbalanced regulator_disable + clk_disable_unprepare in the PHY code if the EHCI driver is unbound and rebound. This is fixed in patch 4. Thanks, Tuomas. Tuomas Tynkkynen (4): USB: tegra: Add resets & has-utmi-pad-registers flag to the PHY binding ARM: tegra: Add resets & has-utmi-pad-registers flag to all USB PHYs USB: EHCI: tegra: Fix probe order issue leading to broken USB USB: PHY: tegra: Call tegra_usb_phy_close only on device removal .../bindings/usb/nvidia,tegra20-usb-phy.txt|8 +++ arch/arm/boot/dts/tegra114.dtsi|5 ++ arch/arm/boot/dts/tegra124.dtsi|7 +++ arch/arm/boot/dts/tegra20.dtsi |7 +++ arch/arm/boot/dts/tegra30.dtsi |7 +++ drivers/usb/host/ehci-tegra.c | 62 +++- drivers/usb/phy/phy-tegra-usb.c|8 +-- 7 files changed, 96 insertions(+), 8 deletions(-) -- 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/
[PATCH v2 4/4] USB: PHY: tegra: Call tegra_usb_phy_close only on device removal
tegra_usb_phy_close() is supposed to undo the effects of
tegra_usb_phy_init(). It is also currently added as the USB PHY shutdown
callback, which is wrong, since tegra_usb_phy_init() is only called
during probing wheras the shutdown callback can get called multiple
times. This then leads to warnings about unbalanced regulator_disable if
the EHCI driver is unbound and bound again at runtime.
Signed-off-by: Tuomas Tynkkynen
---
v2 changes: none
drivers/usb/phy/phy-tegra-usb.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index bbe4f8e..72e04a9 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -686,10 +686,8 @@ static int ulpi_phy_power_off(struct tegra_usb_phy *phy)
return gpio_direction_output(phy->reset_gpio, 0);
}
-static void tegra_usb_phy_close(struct usb_phy *x)
+static void tegra_usb_phy_close(struct tegra_usb_phy *phy)
{
- struct tegra_usb_phy *phy = container_of(x, struct tegra_usb_phy,
u_phy);
-
if (!IS_ERR(phy->vbus))
regulator_disable(phy->vbus);
@@ -1061,14 +1059,13 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
if (err < 0)
return err;
- tegra_phy->u_phy.shutdown = tegra_usb_phy_close;
tegra_phy->u_phy.set_suspend = tegra_usb_phy_suspend;
platform_set_drvdata(pdev, tegra_phy);
err = usb_add_phy_dev(_phy->u_phy);
if (err < 0) {
- tegra_usb_phy_close(_phy->u_phy);
+ tegra_usb_phy_close(tegra_phy);
return err;
}
@@ -1080,6 +1077,7 @@ static int tegra_usb_phy_remove(struct platform_device
*pdev)
struct tegra_usb_phy *tegra_phy = platform_get_drvdata(pdev);
usb_remove_phy(_phy->u_phy);
+ tegra_usb_phy_close(tegra_phy);
return 0;
}
--
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/
[PATCH v2 1/4] USB: tegra: Add resets & has-utmi-pad-registers flag to the PHY binding
When Tegra was converted to use the standard reset bindings, the PHY was
forgotten, probably because all the resetting of the USB blocks were
done in the EHCI driver. What also went unnoticed is that resetting the
1st on-chip USB module also wipes some of the UTMI pad configuration
registers that are also used by the other USB blocks. So this fact needs
to be described in the device tree, and the driver modified not to reset
the 1st module at inappropriate times.
In order to stay compatible with old device trees, the USB drivers will
still function without these properties but with the old,
potentially buggy behaviour.
Signed-off-by: Tuomas Tynkkynen
---
v2 changes: new patch, didn't exist in v1
.../bindings/usb/nvidia,tegra20-usb-phy.txt|8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
index ba797d3..c9205fb 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
@@ -20,6 +20,12 @@ Required properties :
Present if phy_type == utmi.
- ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2).
Present if phy_type == ulpi, and ULPI link mode is in use.
+ - resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names : Must include the following entries:
+ - usb: The PHY's own reset signal.
+ - utmi-pads: The reset of the PHY containing the chip-wide UTMI pad control
+ registers. Required even if phy_type == ulpi.
Required properties for phy_type == ulpi:
- nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
@@ -56,6 +62,8 @@ Optional properties:
host means this is a host controller
peripheral means it is device controller
otg means it can operate as either ("on the go")
+ - nvidia,has-utmi-pad-registers : boolean indicates whether this controller
+contains the UTMI pad control registers common to all USB controllers.
VBUS control (required for dr_mode == otg, optional for dr_mode == host):
- vbus-supply: regulator for VBUS
--
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/
[PATCH v2 2/4] ARM: tegra: Add resets & has-utmi-pad-registers flag to all USB PHYs
Add new properties to all of the Tegra PHYs that are now required according to the binding. In order to stay compatible with old device trees, the USB drivers will still function without these reset properties but with the old, potentially buggy behaviour. Signed-off-by: Tuomas Tynkkynen --- v2 changes: new patch, didn't exist in v1 arch/arm/boot/dts/tegra114.dtsi |5 + arch/arm/boot/dts/tegra124.dtsi |7 +++ arch/arm/boot/dts/tegra20.dtsi |7 +++ arch/arm/boot/dts/tegra30.dtsi |7 +++ 4 files changed, 26 insertions(+) diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi index 335a1d8..80b8edd 100644 --- a/arch/arm/boot/dts/tegra114.dtsi +++ b/arch/arm/boot/dts/tegra114.dtsi @@ -672,6 +672,8 @@ <_car TEGRA114_CLK_PLL_U>, <_car TEGRA114_CLK_USBD>; clock-names = "reg", "pll_u", "utmi-pads"; + resets = <_car 22>, <_car 22>; + reset-names = "usb", "utmi-pads"; nvidia,hssync-start-delay = <0>; nvidia,idle-wait-delay = <17>; nvidia,elastic-limit = <16>; @@ -682,6 +684,7 @@ nvidia,hssquelch-level = <2>; nvidia,hsdiscon-level = <5>; nvidia,xcvr-hsslew = <12>; + nvidia,has-utmi-pad-registers; status = "disabled"; }; @@ -705,6 +708,8 @@ <_car TEGRA114_CLK_PLL_U>, <_car TEGRA114_CLK_USBD>; clock-names = "reg", "pll_u", "utmi-pads"; + resets = <_car 59>, <_car 22>; + reset-names = "usb", "utmi-pads"; nvidia,hssync-start-delay = <0>; nvidia,idle-wait-delay = <17>; nvidia,elastic-limit = <16>; diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi index d675186..5b14d79 100644 --- a/arch/arm/boot/dts/tegra124.dtsi +++ b/arch/arm/boot/dts/tegra124.dtsi @@ -643,6 +643,8 @@ <_car TEGRA124_CLK_PLL_U>, <_car TEGRA124_CLK_USBD>; clock-names = "reg", "pll_u", "utmi-pads"; + resets = <_car 22>, <_car 22>; + reset-names = "usb", "utmi-pads"; nvidia,hssync-start-delay = <0>; nvidia,idle-wait-delay = <17>; nvidia,elastic-limit = <16>; @@ -653,6 +655,7 @@ nvidia,hssquelch-level = <2>; nvidia,hsdiscon-level = <5>; nvidia,xcvr-hsslew = <12>; + nvidia,has-utmi-pad-registers; status = "disabled"; }; @@ -677,6 +680,8 @@ <_car TEGRA124_CLK_PLL_U>, <_car TEGRA124_CLK_USBD>; clock-names = "reg", "pll_u", "utmi-pads"; + resets = <_car 58>, <_car 22>; + reset-names = "usb", "utmi-pads"; nvidia,hssync-start-delay = <0>; nvidia,idle-wait-delay = <17>; nvidia,elastic-limit = <16>; @@ -711,6 +716,8 @@ <_car TEGRA124_CLK_PLL_U>, <_car TEGRA124_CLK_USBD>; clock-names = "reg", "pll_u", "utmi-pads"; + resets = <_car 59>, <_car 22>; + reset-names = "usb", "utmi-pads"; nvidia,hssync-start-delay = <0>; nvidia,idle-wait-delay = <17>; nvidia,elastic-limit = <16>; diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi index 243d84c..1908f69 100644 --- a/arch/arm/boot/dts/tegra20.dtsi +++ b/arch/arm/boot/dts/tegra20.dtsi @@ -645,6 +645,8 @@ <_car TEGRA20_CLK_CLK_M>, <_car TEGRA20_CLK_USBD>; clock-names = "reg", "pll_u", "timer", "utmi-pads"; + resets = <_car 22>, <_car 22>; + reset-names = "usb", "utmi-pads"; nvidia,has-legacy-mode; nvidia,hssync-start-delay = <9>; nvidia,idle-wait-delay = <17>; @@ -653,6 +655,7 @@ nvidia,xcvr-setup = <9>; nvidia,xcvr-lsfslew = <1>; nvidia,xcvr-lsrslew = <1>; + nvidia,has-utmi-pad-registers; status = "disabled"; }; @@ -676,6 +679,8 @@ <_car TEGRA20_CLK_PLL_U>, <_car TEGRA20_CLK_CDEV2>; clock-names = "reg", "pll_u", "ulpi-link"; + resets = <_car 58>, <_car 22>; + reset-names = "usb", "utmi-pads"; status = "disabled"; }; @@ -700,6 +705,8 @@ <_car TEGRA20_CLK_CLK_M>, <_car TEGRA20_CLK_USBD>; clock-names = "reg", "pll_u", "timer", "utmi-pads"; + resets = <_car 59>, <_car 22>; + reset-names = "usb", "utmi-pads";
Re: [RFC] Cancellable MCS spinlock rework
On Thu, 2014-07-03 at 16:35 -0400, Waiman Long wrote: > I do see a point in reducing the size of the rwsem structure. However, I > don't quite understand the point of converting pointers in the > optimistic_spin_queue structure to atomic_t. The structure is cacheline > aligned and there is no saving in size. Converting them to atomic_t does > have a bit of additional overhead of converting the encoded cpu number > back to the actual pointer. > > So my suggestion is to just change what is stored in the mutex and rwsem > structure to atomic_t, but keep the pointers in the > optimistic_spin_queue structure. Peter, would you prefer going with the above? If we were to keep the pointers to the next and prev nodes in the struct optimistic_spin_queue instead of converting them to atomic_t to store their cpu #, we'd still need to keep track of the cpu #. In the unqueue phase of osq_lock, we might have to reload prev = node->prev which we then may cmpxchg() it with the lock tail. The method we can think of so far would be to add a regular int variable to optimistic_spin_queue and initialize it to the CPU #, during the time we also initialize node->locked and node->next at the beginning of osq_lock. The cost wouldn't be much of an issue since optimistic_spin_queue is cache aligned. -- 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, 3.16-rc] rwsem: optimistic spinning causing performance degradation
[re-added lkml] On Thu, Jul 03, 2014 at 11:50:20AM -0700, Jason Low wrote: > On Wed, Jul 2, 2014 at 7:32 PM, Dave Chinner wrote: > > This is what the kernel profile looks like on the strided run: > > > > - 83.06% [kernel] [k] osq_lock > >- osq_lock > > - 100.00% rwsem_down_write_failed > > - call_rwsem_down_write_failed > > - 99.55% sys_mprotect > > tracesys > > __GI___mprotect > > - 12.02% [kernel] [k] rwsem_down_write_failed > > Hi Dave, > > So with no sign of rwsem_spin_on_owner(), yet with such heavy contention in > osq_lock, this makes me wonder if it's spending most of its time spinning > on !owner while a reader has the lock? (We don't set sem->owner for the > readers.) > > If that's an issue, maybe the below is worth a test, in which we'll just > avoid spinning if rwsem_can_spin_on_owner() finds that there is no owner. > If we just had to enter the slowpath yet there is no owner, we'll be > conservative > and assume readers have the lock. That makes it quite a bit faster: XFS_REPAIR SummaryFri Jul 4 10:39:32 2014 Phase Start End Duration Phase 1:07/04 10:38:04 07/04 10:38:05 1 second Phase 2:07/04 10:38:05 07/04 10:38:08 3 seconds Phase 3:07/04 10:38:08 07/04 10:39:12 1 minute, 4 seconds Phase 4:07/04 10:39:12 07/04 10:39:21 9 seconds Phase 5:07/04 10:39:21 07/04 10:39:22 1 second Phase 6:07/04 10:39:22 07/04 10:39:30 8 seconds Phase 7:07/04 10:39:30 07/04 10:39:30 Total run time: 1 minute, 26 seconds done real1m28.504s user1m23.990s sys 3m20.132s So system time goes down massively, and speed comes up to within 30% of the single AG run. But it's still 2-3000 IOPS down, but it's acceptible for the moment. FWIW, the kernel profile ifor the multi-AG run now looks like: 29.64% [kernel] [k] _raw_spin_unlock_irq - _raw_spin_unlock_irq + 35.34% __schedule - 34.15% call_rwsem_down_write_failed + 99.27% sys_mprotect - 30.02% call_rwsem_down_read_failed 95.59% __do_page_fault - 24.65% [kernel] [k] _raw_spin_unlock_irqrestore - _raw_spin_unlock_irqrestore - 69.38% rwsem_wake - call_rwsem_wake - 83.32% sys_mprotect + 15.54% __do_page_fault + 22.55% try_to_wake_up + 9.77% [kernel] [k] default_send_IPI_mask_sequence_phys - 3.21% [kernel] [k] smp_call_function_many - smp_call_function_many - 99.22% flush_tlb_page + 2.51% [kernel] [k] rwsem_down_write_failed It's much more like the 3.15 profile - it's only wasting half the CPU spinning on the internal spinlock and it's now going fast enough to be blowing another 10-12% of the CPU time sending tlb flushes to other CPUs One thing I did notice, even with the single-AG-at-a-time run, is that the system time is *significantly* reduced with this patch, even though it doesn't change performance. ie unpatched: unpatched patched runtime 0m58s 1m2s systime 4m55s 1m1s So not spinning when there are read holders is a major win even when there are few threads contending on read/write. FWIW, the rwsems in the struct xfs_inode are often heavily read/write contended, so there are lots of IO related workloads that are going to regress on XFS without this optimisation... Anyway, consider the patch: Tested-by: Dave Chinner Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: probe_event_disable()->synchronize_sched()
(2014/07/03 16:44), Namhyung Kim wrote: > Hi Masami, > > On Thu, 03 Jul 2014 14:46:09 +0900, Masami Hiramatsu wrote: >> One possible scenario is here; someone disables an event and tries to remove >> it (both will be done by different syscalls). If we don't synchronize >> the first disabling, the event flag set disabled, but the event itself >> is not disabled. Thus event handler is still possible to be running >> somewhere when it is removed. > > But, IIUC both of disable and remove path are protected by event_mutex. > So one cannot see the case of disabled event flag but enabled event, no? No, the flag is not protect the trace event handler itself. I meant that running handlers and the flag was not synchronized. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] USB driver fixes for 3.16-rc4
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee: Linux 3.16-rc2 (2014-06-21 19:02:54 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.16-rc4 for you to fetch changes up to e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a: usb: chipidea: udc: delete td from req's td list at ep_dequeue (2014-07-01 23:06:02 -0700) USB bugfixes for 3.16-rc4 Here's a round of USB bugfixes, quirk additions, and new device ids for 3.16-rc4. Nothing major in here at all, just a bunch of tiny changes. All have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): usb-storage/SCSI: Add broken_fua blacklist flag Andreas Larsson (1): usb: gadget: gr_udc: Fix check for invalid number of microframes Andrzej Pietrasiewicz (2): usb: gadget: OS descriptors configfs cleanup usb: gadget: OS descriptors: provide interface directory names Bjørn Mork (1): usb: option: add/modify Olivetti Olicard modems Dan Carpenter (1): usb: gadget: f_rndis: fix an error code on allocation failure Ezequiel Garcia (1): usb: musb: Fix panic upon musb_am335x module removal Felipe Balbi (1): Revert "tools: ffs-test: convert to new descriptor format fixing compilation error" George Cherian (3): usb: dwc3: dwc3-omap: Fix the crash on module removal usb: dwc3: dwc3-omap: Disable/Enable only wrapper interrupts in prepare/complete usb: musb: core: Handle Babble condition only in HOST mode Greg Kroah-Hartman (3): Merge tag 'fixes-for-v3.16-rc2' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'usb-serial-3.16-rc3' of git://git.kernel.org/.../johan/usb-serial into usb-linus Merge tag 'fixes-for-v3.16-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Jeff Westfahl (1): usb: gadget: u_ether: synchronize with transmit when stopping queue Johan Hovold (3): MAINTAINERS: drop two usb-serial subdriver entries USB: ftdi_sio: fix null deref at port probe MAINTAINERS: update e-mail address Kuninori Morimoto (1): usb: renesas: gadget: fixup: complete STATUS stage after receiving Linus Walleij (1): usb: musb: ux500: don't propagate the OF node Lothar Waßmann (1): usb: musb: dsps: fix the base address for accessing the mode register Lu Baolu (1): xhci: clear root port wake on bits if controller isn't wake-up capable Marcus Nutzinger (1): usb: gadget: gadgetfs: correct dev state Mathias Nyman (2): xhci: Use correct SLOT ID when handling a reset device command xhci: correct burst count field for isoc transfers on 1.0 xhci hosts Michal Nazarewicz (4): tools: ffs-test: convert to new descriptor format fixing compilation error usb: gadget: f_fs: fix NULL pointer dereference when there are no strings usb: gadget: f_fs: resurect usb_functionfs_descs_head structure tools: ffs-test: fix header values endianess Oliver Neukum (1): USB: option: add device ID for SpeedUp SU9800 usb 3g modem Peter Chen (1): usb: chipidea: udc: delete td from req's td list at ep_dequeue Srinivas Kandagatla (2): usb: phy: msm: Do not do runtime pm if the phy is not idle usb: Kconfig: make EHCI_MSM selectable for QCOM SOCs Thomas Gleixner (1): usb: musb: Ensure that cppi41 timer gets armed on premature DMA TX irq Wang, Yu (1): xhci: Fix runtime suspended xhci from blocking system suspend. Zhuang Jin Can (1): usb: dwc3: gadget: check link trb after free_slot is increased MAINTAINERS | 14 +- drivers/scsi/sd.c | 5 - drivers/usb/chipidea/udc.c | 7 +++ drivers/usb/dwc3/Kconfig| 1 + drivers/usb/dwc3/dwc3-omap.c| 17 ++--- drivers/usb/dwc3/gadget.c | 8 drivers/usb/gadget/configfs.c | 37 +++-- drivers/usb/gadget/configfs.h | 1 + drivers/usb/gadget/f_fs.c | 12 +++- drivers/usb/gadget/f_rndis.c| 6 -- drivers/usb/gadget/gr_udc.c | 5 +++-- drivers/usb/gadget/inode.c | 7 ++- drivers/usb/gadget/u_ether.c| 3 +++ drivers/usb/host/Kconfig| 2 +- drivers/usb/host/xhci-hub.c | 5 - drivers/usb/host/xhci-ring.c| 9 ++--- drivers/usb/host/xhci.c | 10 +++--- drivers/usb/musb/musb_am335x.c | 23 ++- drivers/usb/musb/musb_core.c| 2 +- drivers/usb/musb/musb_cppi41.c | 2 +- drivers/usb/musb/musb_dsps.c| 9 - drivers/usb/musb/ux500.c| 1 - drivers/usb/phy/phy-msm-usb.c | 4 +++- drivers/usb/renesas_usbhs/fifo.c| 8
[GIT PULL] Staging driver fixes for 3.16-rc4
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee: Linux 3.16-rc2 (2014-06-21 19:02:54 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-3.16-rc4 for you to fetch changes up to 6b64168de843b16e96a22f9e98c6afc92ee1da71: Merge tag 'iio-fixes-for-3.16b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus (2014-06-29 09:43:23 -0700) Staging driver bugfixes for 3.16-rc4 Nothing major here, just 4 small bugfixes that resolve some issues reported for the IIO (staging and non-staging) and the tidspbridge driver. Signed-off-by: Greg Kroah-Hartman Adam Thomson (1): iio: of_iio_channel_get_by_name() returns non-null pointers for error legs Dan Carpenter (1): staging: iio/ad7291: fix error code in ad7291_probe() Greg Kroah-Hartman (1): Merge tag 'iio-fixes-for-3.16b' of git://git.kernel.org/.../jic23/iio into staging-linus Peter Meerwald (1): iio:adc:ad799x: Fix reading and writing of event values, apply shift Suman Anna (1): staging: tidspbridge: fix an erroneous removal of parentheses drivers/iio/adc/ad799x.c | 8 ++-- drivers/iio/inkern.c | 6 -- drivers/staging/iio/adc/ad7291.c | 4 ++-- drivers/staging/tidspbridge/core/tiomap3430.c | 6 -- 4 files changed, 16 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Driver core fixes for 3.16-rc4
The following changes since commit 4c834452aad01531db949414f94f817a86348d59: Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/driver-core-3.16-rc4 for you to fetch changes up to 4a3a99045177369700c60d074c0e525e8093b0fc: lz4: add overrun checks to lz4_uncompress_unknownoutputsize() (2014-07-03 16:12:04 -0700) Driver core fixes for 3.16-rc4 Well, one drivercore fix for kernfs to resolve a reported issue with sysfs files being updated from atomic contexts, and another lz4 bugfix for testing potential buffer overflows. Signed-off-by: Greg Kroah-Hartman Greg Kroah-Hartman (1): lz4: add overrun checks to lz4_uncompress_unknownoutputsize() Tejun Heo (1): kernfs: kernfs_notify() must be useable from non-sleepable contexts fs/kernfs/file.c | 69 ++-- include/linux/kernfs.h | 1 + lib/lz4/lz4_decompress.c | 6 - 3 files changed, 61 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modules: Fix build error in moduleloader.h
(2014/07/03 22:21), Steven Rostedt wrote:
> Fengguang Wu's build bot detected that if moduleloader.h is included in
> a C file (used by ftrace and kprobes to access module_alloc() when
> available), that it can fail to build if CONFIG_MODULES and
> CONFIG_MODULES_USE_ELF_REL is not defined.
>
> This is because there's a printk() that dereferences struct module to
> print the name of the module. But as struct module does not exist when
> CONFIG_MODULES is not defined we get this error:
>
>include/linux/moduleloader.h: In function 'apply_relocate':
>>> include/linux/moduleloader.h:48:63: error: dereferencing pointer to
>>> incomplete type
> printk(KERN_ERR "module %s: REL relocation unsupported\n", me->name);
> ^
> Avoid the printk if CONFIG_MODULES is not set.
Looks OK to me. BTW, CONFIG_KPROBES depends on CONFIG_MODULES,
so currently kprobes itself doesn't hit that problem.
Reviewed-by: Masami Hiramatsu
Thank you, :)
>
> Reported-by: kbuild test robot
> Signed-off-by: Steven Rostedt
> ---
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index 560ca53..d9da807 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -45,7 +45,10 @@ static inline int apply_relocate(Elf_Shdr *sechdrs,
>unsigned int relsec,
>struct module *me)
> {
> +/* me->name only exists if modules are enabled */
> +#ifdef CONFIG_MODULES
> printk(KERN_ERR "module %s: REL relocation unsupported\n", me->name);
> +#endif
> return -ENOEXEC;
> }
> #endif
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Emit a warning on file add/move/delete
Whenever files are added, moved, or deleted, the
MAINTAINERS file patterns can be out of sync or
outdated.
To try to keep MAINTAINERS more up-to-date, add a
one-time warning whenever a patch does any of those.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 496f9ab..0cf8b98 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1679,7 +1679,7 @@ sub process {
my $in_header_lines = $file ? 0 : 1;
my $in_commit_log = 0; #Scanning lines before patch
-
+ my $reported_maintainer_file = 0;
my $non_utf8_charset = 0;
my $last_blank_line = 0;
@@ -2012,6 +2012,17 @@ sub process {
"Please use 12 to 16 chars for the git commit ID
like: '${init_char}ommit $id (\"$desc\")'\n" . $herecurr);
}
+# Check for added, moved or deleted files
+ if (!$reported_maintainer_file && !$in_commit_log &&
+ ($line =~ /^(?:new|deleted) file mode\s*\d+\s*$/ ||
+$line =~ /^rename (?:from|to) [\w\/\.\-]+\s*$/ ||
+($line =~ /\{\s*([\w\/\.\-]*)\s*\=\>\s*([\w\/\.\-]*)\s*\}/
&&
+ (defined($1) || defined($2) {
+ $reported_maintainer_file = 1;
+ WARN("FILE_PATH_CHANGES",
+"added, moved or deleted file(s), does MAINTAINERS
need updating?\n" . $herecurr);
+ }
+
# Check for wrappage within a valid hunk of the file
if ($realcnt != 0 && $line !~ m{^(?:\+|-| |\\ No newline|$)}) {
ERROR("CORRUPTED_PATCH",
--
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/
[no subject]
Good day, We are Christian loan organization, we help people financially for a loan, if interested, please contact us at marieloanlend...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zram: revalidate disk after capacity change
Hello Sasha,
On Thu, Jul 03, 2014 at 04:39:48PM -0400, Sasha Levin wrote:
> On 06/25/2014 09:16 PM, Minchan Kim wrote:
> > Alexander reported mkswap on /dev/zram0 is failed if other process
> > is opening the block device file.
> >
> > Step is as follows,
> >
> > 0. Reset the unused zram device.
> > 1. Use a program that opens /dev/zram0 with O_RDWR and sleeps
> >until killed.
> > 2. While that program sleeps, echo the correct value to
> >/sys/block/zram0/disksize.
> > 3. Verify (e.g. in /proc/partitions) that the disk size is applied
> >correctly. It is.
> > 4. While that program still sleeps, attempt to mkswap /dev/zram0.
> >This fails: mkswap: error: swap area needs to be at least 40 KiB
> >
> > When I investigated, the size get by ioctl(fd, BLKGETSIZE64, xxx)
> > on mkswap to get a size of blockdev was zero although zram0 has
> > right size by 2.
> >
> > The reason is zram didn't revalidate disk after changing capacity
> > so that size of blockdev's inode is not uptodate until all of file
> > is close.
> >
> > This patch should fix the BUG.
> >
> > Cc: sta...@vger.kernel.org
> > Reported-and-Tested-by: Alexander E. Patrakov
> > Signed-off-by: Minchan Kim
>
> Hi Minchan,
>
> This patch causes the following lockdep warning:
>
>
> [ 249.545546] =
> [ 249.546510] [ INFO: inconsistent lock state ]
> [ 249.547201] 3.16.0-rc3-next-20140703-sasha-00022-g0b37949-dirty #761 Not
> tainted
> [ 249.548316] -
> [ 249.548980] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage.
> [ 249.550044] kswapd1/3912 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 249.550044] (>init_lock){+-}, at: zram_make_request
> (drivers/block/zram/zram_drv.c:1047)
> [ 249.550044] {RECLAIM_FS-ON-W} state was registered at:
> [ 249.550044] mark_held_locks (kernel/locking/lockdep.c:2523)
> [ 249.550044] lockdep_trace_alloc (kernel/locking/lockdep.c:2745
> kernel/locking/lockdep.c:2760)
> [ 249.550044] kmem_cache_alloc (mm/slub.c:1246 mm/slub.c:2386 mm/slub.c:2459
> mm/slub.c:2464)
> [ 249.550044] bdev_alloc_inode (fs/block_dev.c:440)
> [ 249.550044] alloc_inode (fs/inode.c:208)
> [ 249.550044] iget5_locked (fs/inode.c:1017)
> [ 249.550044] bdget (fs/block_dev.c:568)
> [ 249.550044] bdget_disk (include/linux/genhd.h:268 block/genhd.c:727)
> [ 249.550044] revalidate_disk (fs/block_dev.c:1042)
> [ 249.550044] disksize_store (drivers/block/zram/zram_drv.c:685)
> [ 249.550044] dev_attr_store (drivers/base/core.c:138)
> [ 249.550044] sysfs_kf_write (fs/sysfs/file.c:115)
> [ 249.550044] kernfs_fop_write (fs/kernfs/file.c:308)
> [ 249.550044] vfs_write (fs/read_write.c:532)
> [ 249.550044] SyS_write (fs/read_write.c:584 fs/read_write.c:576)
> [ 249.550044] tracesys (arch/x86/kernel/entry_64.S:542)
> [ 249.550044] irq event stamp: 4395
> [ 249.550044] hardirqs last enabled at (4395): throtl_update_dispatch_stats
> (./arch/x86/include/asm/paravirt.h:809 (discriminator 2)
> block/blk-throttle.c:982 (discriminator 2))
> [ 249.550044] hardirqs last disabled at (4394): throtl_update_dispatch_stats
> (block/blk-throttle.c:977)
> [ 249.550044] softirqs last enabled at (4252): __do_softirq
> (./arch/x86/include/asm/preempt.h:22 kernel/softirq.c:296)
> [ 249.550044] softirqs last disabled at (4233): irq_exit
> (kernel/softirq.c:346 kernel/softirq.c:387)
> [ 249.550044]
> [ 249.550044] other info that might help us debug this:
> [ 249.550044] Possible unsafe locking scenario:
> [ 249.550044]
> [ 249.550044]CPU0
> [ 249.550044]
> [ 249.550044] lock(>init_lock);
> [ 249.550044]
> [ 249.550044] lock(>init_lock);
> [ 249.550044]
> [ 249.550044] *** DEADLOCK ***
> [ 249.550044]
> [ 249.550044] no locks held by kswapd1/3912.
> [ 249.550044]
> [ 249.550044] stack backtrace:
> [ 249.550044] CPU: 1 PID: 3912 Comm: kswapd1 Not tainted
> 3.16.0-rc3-next-20140703-sasha-00022-g0b37949-dirty #761
> [ 249.550044] 9cbff170 8801b3e6f358 99489804
>
> [ 249.550044] 8801b3e5 8801b3e6f3b8 9947dc97
>
> [ 249.550044] 0001 88010001 9cbff280
> 8801b3e6f3b8
> [ 249.550044] Call Trace:
> [ 249.550044] dump_stack (lib/dump_stack.c:52)
> [ 249.550044] print_usage_bug (kernel/locking/lockdep.c:2257)
> [ 249.550044] ? print_irq_inversion_bug (kernel/locking/lockdep.c:2347)
> [ 249.550044] mark_lock (kernel/locking/lockdep.c:2465
> kernel/locking/lockdep.c:2920)
> [ 249.550044] __lock_acquire (kernel
Re: mm: memcontrol: rewrite uncharge API: problems
On Thu, Jul 03, 2014 at 12:54:36PM -0700, Hugh Dickins wrote: > On Wed, 2 Jul 2014, Hugh Dickins wrote: > > On Wed, 2 Jul 2014, Johannes Weiner wrote: > > > > > > Could you give the following patch a spin? I put it in the mmots > > > stack on top of mm-memcontrol-rewrite-charge-api-fix-shmem_unuse-fix. > > > > I'm just with the laptop until this evening. I slapped it on top of > > my 3.16-rc2-mm1 plus fixes (but obviously minus my memcg_batch one > > - which incidentally continues to run without crashing on the G5), > > and it quickly gave me this lockdep splat, which doesn't look very > > different from the one before. > > > > I see there's now an -rc3-mm1, I'll try it out on that in half an > > hour... but unless I send word otherwise, assume that's the same. > > Yes, I get that lockdep report each time on -rc3-mm1 + your patch. There are two instances where I missed to make >lock IRQ-safe: diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 91b621846e10..bbaa3f4cf4db 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3919,7 +3919,7 @@ unsigned long mem_cgroup_soft_limit_reclaim(struct zone *zone, int order, gfp_mask, _scanned); nr_reclaimed += reclaimed; *total_scanned += nr_scanned; - spin_lock(>lock); + spin_lock_irq(>lock); /* * If we failed to reclaim anything from this memory cgroup @@ -3959,7 +3959,7 @@ unsigned long mem_cgroup_soft_limit_reclaim(struct zone *zone, int order, */ /* If excess == 0, no tree ops */ __mem_cgroup_insert_exceeded(mz, mctz, excess); - spin_unlock(>lock); + spin_unlock_irq(>lock); css_put(>memcg->css); loop++; /* That should make it complete - but the IRQ toggling costs are fairly high so I'm rewriting the batching code to use the page lists that most uncharges have anyway, and then batch the no-IRQ sections. > I also twice got a flurry of res_counter.c:28 underflow warnings. > Hmm, 62 of them each time (I was checking for a number near 512, > which would suggest a THP/4k confusion, but no). The majority > of them coming from mem_cgroup_reparent_charges. I haven't seen these yet. But the location makes sense: if there are any imbalances they'll be noticed during a group's final uncharges. > But the laptop stayed up fine (for two hours before I had to stop > it), and the G5 has run fine with that load for 16 hours now, no > problems with release_pages, and not even a res_counter.c:28 (but > I don't use lockdep on it). Great! > The x86 workstation ran fine for 4.5 hours, then hit some deadlock > which I doubt had any connection to your changes: looked more like > a jbd2 transaction was failing to complete (which, with me trying > ext4 on loop on tmpfs, might be more my problem than anyone else's). > > Oh, but nearly forgot, I did an earlier run on the laptop last night, > which crashed within minutes on > > VM_BUG_ON_PAGE(!(pc->flags & PCG_MEM)) > mm/memcontrol.c:6680! > page had count 1 mapcount 0 mapping anon index 0x196 > flags locked uptodate reclaim swapbacked, pcflags 1, memcg not root > mem_cgroup_migrate < move_to_new_page < migrate_pages < compact_zone < > compact_zone_order < try_to_compact_pages < __alloc_pages_direct_compact < > __alloc_pages_nodemask < alloc_pages_vma < do_huge_pmd_anonymous_page < > handle_mm_fault < __do_page_fault Haven't seen that one yet, either. The only way I can see this happen is when the same page gets selected for migration twice in a row. Maybe a race with putback, where it gets added to the LRU but isolated by compaction before putback drops the refcount - will verify that. Thanks for your reports! -- 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] arm64: PCI(e) arch support
Hi Tanmay, Liviu, On 7/4/2014 2:57 AM, Tanmay Inamdar wrote: Reposting on request of several people since previously posted one was corrupted. This patch adds the arch support for PCI(e) for arm64. The files added or modified in this patch are based on PCI(e) support in 32bit arm. Please note that this patch is just for the reference. Liviu Dudau from ARM has posted his v8 series of patch to support PCIe in arm64. The patch will apply against 3.13 Linux Kernel Signed-off-by: Tanmay Inamdar do we foresee similar type of changes in u-boot to support PCI(e) for ARM64. Regards, Prabhakar -- 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] x86,cpu-hotplug: clear llc_shared_mask at CPU hotplug
(2014/07/03 18:51), Borislav Petkov wrote: On Thu, Jul 03, 2014 at 01:52:52PM +0900, Yasuaki Ishimatsu wrote: I think that the reason to apply CPU number to ACPI ID is that CPU is used for the application without considering physical CPU. So even if CPU number is changed, it is no matter. I don't think I understand what you're saying here... Thus the readded cores is numbered to unused CPU number. Well, maybe we should use some method to number cores in a stable manner so that they don't get new numbers when they reappear. I think the mask has 2 meanings as follows: - representing CPUs that share same CPU cache. ... that share the last level cache. - representing onlined CPUs no, for that we have cpu_online_mask. So even if we keep their old numbers, we should clear the mask when offlinig CPU. No, cpu_online_mask is for onlined cores. I think the mask which shows which cores share a last level cache should not be changed *IF* the core numbers remain stable, that is. If so, why following maps are cleared by CPU offline? - cpu_sigling_map - cpu_core_map I think the masks are used by cpumask_weight(). So they must be cleared at CPU offline. And currently llc_shared_map is not used by cpumask_weight(). So even if we don't clear the mask, there is no problem. But llc_shared_map will be used by cpumask_weight(). In this case, some problem will occur and we will spent time the investigation of the problem. So even if we keep CPU number, the mask should be cleared at CPU offline. Thanks, Yasuaki Ishimatsu -- 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] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereferenc
On Friday, July 04, 2014 5:19 AM, Rickard Strandqvist wrote:
>
> Fix for possible null pointer dereferenc, and there is a risk
> for memory leak if something unexpected
s/dereferenc/dereference
The columns of this commit is too long.
Please keep about 80 columns.
> happens and the function returns.
> It now use Managed Device Resource instead.
s/use/uses
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/i2c/busses/i2c-pxa.c | 37 -
> 1 file changed, 16 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index be671f7..2edb633 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1141,10 +1141,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
> struct resource *res = NULL;
> int ret, irq;
>
> - i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
> + i2c = devm_kzalloc(>dev, sizeof(struct pxa_i2c), GFP_KERNEL);
> if (!i2c) {
> ret = -ENOMEM;
> - goto emalloc;
> + goto err_nothing_to_release;
> }
>
> /* Default adapter num to device id; i2c_pxa_probe_dt can override. */
> @@ -1154,18 +1154,19 @@ static int i2c_pxa_probe(struct platform_device *dev)
> if (ret > 0)
> ret = i2c_pxa_probe_pdata(dev, i2c, _type);
> if (ret < 0)
> - goto eclk;
> + goto err_nothing_to_release;
>
> res = platform_get_resource(dev, IORESOURCE_MEM, 0);
> irq = platform_get_irq(dev, 0);
> if (res == NULL || irq < 0) {
> ret = -ENODEV;
> - goto eclk;
> + goto err_nothing_to_release;
> }
>
> - if (!request_mem_region(res->start, resource_size(res), res->name)) {
> + if (!devm_request_mem_region(>dev, res->start,
> + resource_size(res), res->name)) {
> ret = -ENOMEM;
> - goto eclk;
> + goto emalloc;
> }
>
> i2c->adap.owner = THIS_MODULE;
> @@ -1176,16 +1177,16 @@ static int i2c_pxa_probe(struct platform_device *dev)
>
> strlcpy(i2c->adap.name, "pxa_i2c-i2c", sizeof(i2c->adap.name));
>
> - i2c->clk = clk_get(>dev, NULL);
> + i2c->clk = devm_clk_get(>dev, NULL);
> if (IS_ERR(i2c->clk)) {
> ret = PTR_ERR(i2c->clk);
> - goto eclk;
> + goto emalloc;
> }
>
> - i2c->reg_base = ioremap(res->start, resource_size(res));
> - if (!i2c->reg_base) {
> + i2c->reg_base = devm_ioremap_resource(>dev, res));
> + if (IS_ERR(i2c->reg_base)) {
> ret = -EIO;
> - goto eremap;
> + goto emalloc;
> }
>
> i2c->reg_ibmr = i2c->reg_base + pxa_reg_layout[i2c_type].ibmr;
> @@ -1227,10 +1228,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
> i2c->adap.algo = _pxa_pio_algorithm;
> } else {
> i2c->adap.algo = _pxa_algorithm;
> - ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
> - dev_name(>dev), i2c);
> + ret = devm_request_irq(>dev, irq, i2c_pxa_handler,
> + IRQF_SHARED, dev_name(>dev), i2c);
> if (ret)
> - goto ereqirq;
> + goto emalloc;
> }
>
> i2c_pxa_reset(i2c);
> @@ -1261,15 +1262,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
> eadapt:
> if (!i2c->use_pio)
> free_irq(irq, i2c);
> -ereqirq:
> - clk_disable_unprepare(i2c->clk);
> - iounmap(i2c->reg_base);
> -eremap:
> - clk_put(i2c->clk);
> -eclk:
> - kfree(i2c);
> emalloc:
> release_mem_region(res->start, resource_size(res));
This function can be removed, because devm_request_mem_region()
is used. So, please remove release_mem_region().
Best regards,
Jingoo Han
> +err_nothing_to_release:
> return ret;
> }
>
> --
> 1.7.10.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] Documentation: Fix typo in DocBook/mtdnand.tmpl
This patch fixed spelling typo found in DocBook/mtdnand.tmpl. Signed-off-by: Masanari Iida --- Documentation/DocBook/mtdnand.tmpl | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index cd11926..a3b50c1 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -91,7 +91,7 @@ [MTD Interface] These functions provide the interface to the MTD kernel API. - They are not replacable and provide functionality + They are not replaceable and provide functionality which is complete hardware independent. @@ -100,14 +100,14 @@ [GENERIC] - Generic functions are not replacable and provide functionality + Generic functions are not replaceable and provide functionality which is complete hardware independent. [DEFAULT] Default functions provide hardware related functionality which is suitable for most of the implementations. These functions can be replaced by the - board driver if neccecary. Those functions are called via pointers in the + board driver if necessary. Those functions are called via pointers in the NAND chip description structure. The board driver can set the functions which should be replaced by board dependent functions before calling nand_scan(). If the function pointer is NULL on entry to nand_scan() then the pointer @@ -264,7 +264,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd) is set up nand_scan() is called. This function tries to detect and identify then chip. If a chip is found all the internal data fields are initialized accordingly. - The structure(s) have to be zeroed out first and then filled with the neccecary + The structure(s) have to be zeroed out first and then filled with the necessary information about the device. @@ -327,7 +327,7 @@ module_init(board_init); Exit function - The exit function is only neccecary if the driver is + The exit function is only necessary if the driver is compiled as a module. It releases all resources which are held by the chip driver and unregisters the partitions in the MTD layer. @@ -494,7 +494,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) in this case. See rts_from4.c and diskonchip.c for implementation reference. In those cases we must also use bad block tables on FLASH, because the ECC layout is - interferring with the bad block marker positions. + interfering with the bad block marker positions. See bad block table support for details. @@ -542,7 +542,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) nand_scan() calls the function nand_default_bbt(). nand_default_bbt() selects appropriate default - bad block table desriptors depending on the chip information + bad block table descriptors depending on the chip information which was retrieved by nand_scan(). @@ -554,7 +554,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) Flash based tables - It may be desired or neccecary to keep a bad block table in FLASH. + It may be desired or necessary to keep a bad block table in FLASH. For AG-AND chips this is mandatory, as they have no factory marked bad blocks. They have factory marked good blocks. The marker pattern is erased when the block is erased to be reused. So in case of @@ -565,10 +565,10 @@ static void board_select_chip (struct mtd_info *mtd, int chip) of the blocks. - The blocks in which the tables are stored are procteted against + The blocks in
RE: [PATCH 09/16] MAINTAINERS: Update Samsunt MFD drivers pattern
On Friday, July 04, 2014 7:08 AM, Joe Perches wrote: > F: drivers/regulator/s2m*.c > F: drivers/regulator/s5m*.c > -F: drivers/rtc/rtc-sec.c > F: include/linux/mfd/samsung/ > Yes, You are right. There is no rtc-sec.c Instead, rtc-s5m.c was upstreamed. I will post update patch. Thanks, Sangbeom. -- 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: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data
On Tue, Jul 01, 2014 at 10:22:49PM -0500, Felipe Balbi wrote: > Hi, > > On Fri, Jun 13, 2014 at 07:11:58PM +, Paul Walmsley wrote: > > Hi Felipe, Tomi, > > > > On Fri, 13 Jun 2014, Felipe Balbi wrote: > > > > > On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote: > > > > From: Sathya Prakash M R > > > > > > > > Add DSS hwmod data for AM43xx. > > > > > > > > Cc: Andrew Morton > > > > Acked-by: Rajendra Nayak > > > > Signed-off-by: Sathya Prakash M R > > > > Signed-off-by: Tomi Valkeinen > > > > Signed-off-by: Felipe Balbi > > > > --- > > > > > > > > Note that this patch was originally send on May 9th [1], changes were > > > > requested > > > > and a new version was sent on May 19th [2], then on May 27th [3] Tomi > > > > pinged > > > > maintainer again and go no response. > > > > > > > > Without this patch, we cannot get display working on any AM437x devices. > > > > > > > > [1] http://marc.info/?l=linux-arm-kernel=139963677925227=2 > > > > [2] http://marc.info/?l=linux-arm-kernel=140049799425512=2 > > > > [3] http://marc.info/?l=linux-arm-kernel=140117232826754=2 > > > > > > > > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 > > > > ++ > > > > arch/arm/mach-omap2/prcm43xx.h | 1 + > > > > 2 files changed, 99 insertions(+) > > > > Sorry for the delay on this. Have been corresponding with TI management > > to figure out what to do about patches for AM43xx. I don't have boards or > > public documentation for these devices, so it's impossible for me to > > documentation is now available publicly > > http://www.ti.com/product/AM4379 at [1] you can find most (all?) board-related documentation. [2] will give you AM437x GP EVM schematics. [1] http://processors.wiki.ti.com/index.php/AM437X_EVM_Boards [2] http://processors.wiki.ti.com/images/9/95/Am437x_gp_evm_3k0006_schematic_rev1_4a.pdf -- balbi signature.asc Description: Digital signature
Re: [PATCH 16/16] MAINTAINERS: Update rcu torture patterns
On Thu, Jul 03, 2014 at 03:08:00PM -0700, Joe Perches wrote:
> commit 51b1130eb582 ("rcutorture: Abstract rcu_torture_random()")
> moved the file, update the patterns
>
> Signed-off-by: Joe Perches
> cc: "Paul E. McKenney"
Acked-by: Paul E. McKenney
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index de0d181..473c00c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7374,7 +7374,7 @@ L: linux-kernel@vger.kernel.org
> S: Supported
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> F: Documentation/RCU/torture.txt
> -F: kernel/rcu/torture.c
> +F: kernel/rcu/rcutorture.c
>
> RCUTORTURE TEST FRAMEWORK
> M: "Paul E. McKenney"
> @@ -7418,7 +7418,7 @@ X: Documentation/RCU/torture.txt
> F: include/linux/rcu*
> X: include/linux/srcu.h
> F: kernel/rcu/
> -X: kernel/rcu/torture.c
> +X: kernel/torture.c
>
> REAL TIME CLOCK (RTC) SUBSYSTEM
> M: Alessandro Zummo
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
--
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: Filesystem lockup with CONFIG_PREEMPT_RT
On Tue, Jul 1, 2014 at 12:32 PM, Austin Schuh wrote: > On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh wrote: >> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote: >>> Completely untested patch below. I've tested it and looked it over now, and feel pretty confident in the patch. Thanks Thomas! I've been running this fix with my extra lock steps for a couple days now on 3 machines, and haven't seen any issues. On each of the machines, I've got a CAN card generating about 1 CPU worth of load from interrupts, and the rest of the cores are tied up putting work on the work queues with the killer_module. What next? Austin -- 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] ix86: fix vDSO build
On 07/03/2014 10:35 AM, Jan Beulich wrote:
Relying on static functions used just once to get inlined (and
subsequently have dead code paths eliminated) is wrong: Compilers are
free to decide whether they do this, regardless of optimization level.
With this not happening for vdso_addr() (observed with gcc 4.1.x), an
unresolved reference to align_vdso_addr() causes the build to fail.
Tested-by: Boris Ostrovsky
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
---
arch/x86/vdso/vma.c|4
1 file changed, 4 insertions(+)
--- 3.16-rc3/arch/x86/vdso/vma.c
+++ 3.16-rc3-x86-vdso-build/arch/x86/vdso/vma.c
@@ -62,6 +62,9 @@ struct linux_binprm;
Only used for the 64-bit and x32 vdsos. */
static unsigned long vdso_addr(unsigned long start, unsigned len)
{
+#ifdef CONFIG_X86_32
+ return 0;
+#else
unsigned long addr, end;
unsigned offset;
end = (start + PMD_SIZE - 1) & PMD_MASK;
@@ -83,6 +86,7 @@ static unsigned long vdso_addr(unsigned
addr = align_vdso_addr(addr);
return addr;
+#endif
}
static int map_vdso(const struct vdso_image *image, bool calculate_addr)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: fix vDSO build
On 07/03/2014 10:34 AM, Jan Beulich wrote: Certain ld versions (observed with 2.20.0) put an empty .rela.dyn section into shared object files, breaking the assumption on the number of sections to be copied to the final output. Simply discard any empty SHT_REL and SHT_RELA sections to address this. Tested-by: Boris Ostrovsky Signed-off-by: Jan Beulich Cc: Andy Lutomirski --- arch/x86/vdso/vdso2c.h |3 +++ 1 file changed, 3 insertions(+) --- 3.16-rc3/arch/x86/vdso/vdso2c.h +++ 3.16-rc3-x86-vdso-build/arch/x86/vdso/vdso2c.h @@ -93,6 +93,9 @@ static void BITSFUNC(copy_section)(struc uint64_t flags = GET_LE(>sh_flags); bool copy = flags & SHF_ALLOC && + (GET_LE(>sh_size) || +(GET_LE(>sh_type) != SHT_RELA && + GET_LE(>sh_type) != SHT_REL)) && strcmp(name, ".altinstructions") && strcmp(name, ".altinstr_replacement"); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lz4: add overrun checks to lz4_uncompress_unknownoutputsize()
From: Greg Kroah-Hartman
Jan points out that I forgot to make the needed fixes to the
lz4_uncompress_unknownoutputsize() function to mirror the changes done
in lz4_decompress() with regards to potential pointer overflows.
The only in-kernel user of this function is the zram code, which only
takes data from a valid compressed buffer that it made itself, so it's
not a big issue. But due to external kernel modules using this
function, it's better to be safe here.
Reported-by: Jan Beulich
Cc: "Don A. Bailey"
Cc: stable
Signed-off-by: Greg Kroah-Hartman
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index b74da447e81e..7a85967060a5 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -192,6 +192,8 @@ static int lz4_uncompress_unknownoutputsize(const char
*source, char *dest,
int s = 255;
while ((ip < iend) && (s == 255)) {
s = *ip++;
+ if (unlikely(length > (size_t)(length + s)))
+ goto _output_error;
length += s;
}
}
@@ -232,6 +234,8 @@ static int lz4_uncompress_unknownoutputsize(const char
*source, char *dest,
if (length == ML_MASK) {
while (ip < iend) {
int s = *ip++;
+ if (unlikely(length > (size_t)(length + s)))
+ goto _output_error;
length += s;
if (s == 255)
continue;
@@ -284,7 +288,7 @@ static int lz4_uncompress_unknownoutputsize(const char
*source, char *dest,
/* write overflow error detected */
_output_error:
- return (int) (-(((char *) ip) - source));
+ return -1;
}
int lz4_decompress(const unsigned char *src, size_t *src_len,
--
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] mmc: hsmmc: Add reset gpio configuration option.
On Thu, Jul 03, 2014 at 10:49:23PM +0200, Marek Belisko wrote: > From: NeilBrown > > If a 'gpio_reset' is specified, then hold it low while > turning the power regulator on. > This is needed for some wi2wi wireless modules, particularly > when the regulator is held active by some other client. > The wi2wi needs to be reset if power isn't actually removed, and > the gpio can be used to do this. > > Signed-off-by: NeilBrown Obvious statement knowing what's been going on elsewhere... A while back, Olof produced a couple of patches to add /generic/ support to deal with power and reset controls for SDIO WIFI cards. Patches were posted to linux-arm-kernel and other places around January time this year. No real conclusion came out of it, and it kind of died. The point here is that this is not an OMAP problem. We have this very same problem on different platforms and different SoCs. Why should we have N different solutions to the same problem. Why can't we have one solution to fix this issue, rather than having every host driver implement some different solution to what's a common problem. If everyone is going to run away from generic problems and continue inventing their own private solutions to generic problems, the kernel is just going to become severely bloated and unmaintainable... Please, sort out generic problems with generic solutions. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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 01/18] lib: bitmap: Make nbits parameter of bitmap_empty unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "nbits" is non-negative. Since no-one passes a
negative bit-count, this shouldn't affect the semantics.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4 ++--
lib/bitmap.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 7ad6345..3d3fd6b 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -88,7 +88,7 @@
* lib/bitmap.c provides these functions:
*/
-extern int __bitmap_empty(const unsigned long *bitmap, int bits);
+extern int __bitmap_empty(const unsigned long *bitmap, unsigned int nbits);
extern int __bitmap_full(const unsigned long *bitmap, int bits);
extern int __bitmap_equal(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits);
@@ -257,7 +257,7 @@ static inline int bitmap_subset(const unsigned long *src1,
return __bitmap_subset(src1, src2, nbits);
}
-static inline int bitmap_empty(const unsigned long *src, int nbits)
+static inline int bitmap_empty(const unsigned long *src, unsigned nbits)
{
if (small_const_nbits(nbits))
return ! (*src & BITMAP_LAST_WORD_MASK(nbits));
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 06f7e4f..3789110 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -40,9 +40,9 @@
* for the best explanations of this ordering.
*/
-int __bitmap_empty(const unsigned long *bitmap, int bits)
+int __bitmap_empty(const unsigned long *bitmap, unsigned int bits)
{
- int k, lim = bits/BITS_PER_LONG;
+ unsigned int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (bitmap[k])
return 0;
--
1.9.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/
[PATCH 05/18] lib: bitmap: Remove unnecessary mask from bitmap_complement
Since the extra bits are "don't care", there is no reason to mask the
last word to the used bits when complementing. This shaves off yet a
few bytes.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 2 +-
lib/bitmap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 21fb52f..f42d72d 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -225,7 +225,7 @@ static inline void bitmap_complement(unsigned long *dst,
const unsigned long *sr
unsigned int nbits)
{
if (small_const_nbits(nbits))
- *dst = ~(*src) & BITMAP_LAST_WORD_MASK(nbits);
+ *dst = ~(*src);
else
__bitmap_complement(dst, src, nbits);
}
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 0f2f845..4387e3c 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -93,7 +93,7 @@ void __bitmap_complement(unsigned long *dst, const unsigned
long *src, unsigned
dst[k] = ~src[k];
if (bits % BITS_PER_LONG)
- dst[k] = ~src[k] & BITMAP_LAST_WORD_MASK(bits);
+ dst[k] = ~src[k];
}
EXPORT_SYMBOL(__bitmap_complement);
--
1.9.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/
[PATCH 04/18] lib: bitmap: Make nbits parameter of bitmap_complement unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "nbits" is non-negative. Since no-one passes a
negative bit-count, this shouldn't affect the semantics.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 6 +++---
lib/bitmap.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 1e0f46c..21fb52f 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -93,7 +93,7 @@ extern int __bitmap_full(const unsigned long *bitmap,
unsigned int nbits);
extern int __bitmap_equal(const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int nbits);
extern void __bitmap_complement(unsigned long *dst, const unsigned long *src,
- int bits);
+ unsigned int nbits);
extern void __bitmap_shift_right(unsigned long *dst,
const unsigned long *src, int shift, int bits);
extern void __bitmap_shift_left(unsigned long *dst,
@@ -222,7 +222,7 @@ static inline int bitmap_andnot(unsigned long *dst, const
unsigned long *src1,
}
static inline void bitmap_complement(unsigned long *dst, const unsigned long
*src,
- int nbits)
+ unsigned int nbits)
{
if (small_const_nbits(nbits))
*dst = ~(*src) & BITMAP_LAST_WORD_MASK(nbits);
@@ -231,7 +231,7 @@ static inline void bitmap_complement(unsigned long *dst,
const unsigned long *sr
}
static inline int bitmap_equal(const unsigned long *src1,
- const unsigned long *src2, int nbits)
+ const unsigned long *src2, unsigned int nbits)
{
if (small_const_nbits(nbits))
return ! ((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits));
diff --git a/lib/bitmap.c b/lib/bitmap.c
index d6bb955..0f2f845 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -86,9 +86,9 @@ int __bitmap_equal(const unsigned long *bitmap1,
}
EXPORT_SYMBOL(__bitmap_equal);
-void __bitmap_complement(unsigned long *dst, const unsigned long *src, int
bits)
+void __bitmap_complement(unsigned long *dst, const unsigned long *src,
unsigned int bits)
{
- int k, lim = bits/BITS_PER_LONG;
+ unsigned int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
dst[k] = ~src[k];
--
1.9.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/
[PATCH 02/18] lib: bitmap: Make nbits parameter of bitmap_full unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "nbits" is non-negative. Since no-one passes a
negative bit-count, this shouldn't affect the semantics.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4 ++--
lib/bitmap.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 3d3fd6b..bc7e520 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -89,7 +89,7 @@
*/
extern int __bitmap_empty(const unsigned long *bitmap, unsigned int nbits);
-extern int __bitmap_full(const unsigned long *bitmap, int bits);
+extern int __bitmap_full(const unsigned long *bitmap, unsigned int nbits);
extern int __bitmap_equal(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits);
extern void __bitmap_complement(unsigned long *dst, const unsigned long *src,
@@ -265,7 +265,7 @@ static inline int bitmap_empty(const unsigned long *src,
unsigned nbits)
return __bitmap_empty(src, nbits);
}
-static inline int bitmap_full(const unsigned long *src, int nbits)
+static inline int bitmap_full(const unsigned long *src, unsigned int nbits)
{
if (small_const_nbits(nbits))
return ! (~(*src) & BITMAP_LAST_WORD_MASK(nbits));
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 3789110..9859f38 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -55,9 +55,9 @@ int __bitmap_empty(const unsigned long *bitmap, unsigned int
bits)
}
EXPORT_SYMBOL(__bitmap_empty);
-int __bitmap_full(const unsigned long *bitmap, int bits)
+int __bitmap_full(const unsigned long *bitmap, unsigned int bits)
{
- int k, lim = bits/BITS_PER_LONG;
+ unsigned int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (~bitmap[k])
return 0;
--
1.9.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/
[PATCH 07/18] lib: bitmap: Make nbits parameter of bitmap_intersects unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "nbits" is non-negative. Since no-one passes a
negative bit-count, this shouldn't affect the semantics.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4 ++--
lib/bitmap.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 7048782..2f3f3a4 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -107,7 +107,7 @@ extern void __bitmap_xor(unsigned long *dst, const unsigned
long *bitmap1,
extern int __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int nbits);
extern int __bitmap_intersects(const unsigned long *bitmap1,
- const unsigned long *bitmap2, int bits);
+ const unsigned long *bitmap2, unsigned int nbits);
extern int __bitmap_subset(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits);
extern int __bitmap_weight(const unsigned long *bitmap, int bits);
@@ -240,7 +240,7 @@ static inline int bitmap_equal(const unsigned long *src1,
}
static inline int bitmap_intersects(const unsigned long *src1,
- const unsigned long *src2, int nbits)
+ const unsigned long *src2, unsigned int nbits)
{
if (small_const_nbits(nbits))
return ((*src1 & *src2) & BITMAP_LAST_WORD_MASK(nbits)) != 0;
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 0320737..e85daa9 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -230,9 +230,9 @@ int __bitmap_andnot(unsigned long *dst, const unsigned long
*bitmap1,
EXPORT_SYMBOL(__bitmap_andnot);
int __bitmap_intersects(const unsigned long *bitmap1,
- const unsigned long *bitmap2, int bits)
+ const unsigned long *bitmap2, unsigned int bits)
{
- int k, lim = bits/BITS_PER_LONG;
+ unsigned int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (bitmap1[k] & bitmap2[k])
return 1;
--
1.9.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/
[PATCH 03/18] lib: bitmap: Make nbits parameter of bitmap_equal unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "nbits" is non-negative. Since no-one passes a
negative bit-count, this shouldn't affect the semantics.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 2 +-
lib/bitmap.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index bc7e520..1e0f46c 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -91,7 +91,7 @@
extern int __bitmap_empty(const unsigned long *bitmap, unsigned int nbits);
extern int __bitmap_full(const unsigned long *bitmap, unsigned int nbits);
extern int __bitmap_equal(const unsigned long *bitmap1,
- const unsigned long *bitmap2, int bits);
+ const unsigned long *bitmap2, unsigned int nbits);
extern void __bitmap_complement(unsigned long *dst, const unsigned long *src,
int bits);
extern void __bitmap_shift_right(unsigned long *dst,
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 9859f38..d6bb955 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -71,9 +71,9 @@ int __bitmap_full(const unsigned long *bitmap, unsigned int
bits)
EXPORT_SYMBOL(__bitmap_full);
int __bitmap_equal(const unsigned long *bitmap1,
- const unsigned long *bitmap2, int bits)
+ const unsigned long *bitmap2, unsigned int bits)
{
- int k, lim = bits/BITS_PER_LONG;
+ unsigned int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (bitmap1[k] != bitmap2[k])
return 0;
--
1.9.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/
[PATCH 10/18] lib: bitmap: Make the start index of bitmap_set unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "start" is non-negative.
Also, use the names "start" and "len" for the two parameters in both
header file and implementation, instead of the previous mix.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 2 +-
lib/bitmap.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 64b0ebe..ad2c67d 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -112,7 +112,7 @@ extern int __bitmap_subset(const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int nbits);
extern int __bitmap_weight(const unsigned long *bitmap, unsigned int nbits);
-extern void bitmap_set(unsigned long *map, int i, int len);
+extern void bitmap_set(unsigned long *map, unsigned int start, int len);
extern void bitmap_clear(unsigned long *map, int start, int nr);
extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
unsigned long size,
diff --git a/lib/bitmap.c b/lib/bitmap.c
index f69435c..2a3a92f 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -274,21 +274,21 @@ int __bitmap_weight(const unsigned long *bitmap, unsigned
int bits)
}
EXPORT_SYMBOL(__bitmap_weight);
-void bitmap_set(unsigned long *map, int start, int nr)
+void bitmap_set(unsigned long *map, unsigned int start, int len)
{
unsigned long *p = map + BIT_WORD(start);
- const int size = start + nr;
+ const unsigned int size = start + len;
int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
- while (nr - bits_to_set >= 0) {
+ while (len - bits_to_set >= 0) {
*p |= mask_to_set;
- nr -= bits_to_set;
+ len -= bits_to_set;
bits_to_set = BITS_PER_LONG;
mask_to_set = ~0UL;
p++;
}
- if (nr) {
+ if (len) {
mask_to_set &= BITMAP_LAST_WORD_MASK(size);
*p |= mask_to_set;
}
--
1.9.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/
[PATCH 14/18] lib: bitmap: Change parameter of bitmap_*_region to unsigned
Changing the pos parameter of __reg_op to unsigned allows the compiler
to generate slightly smaller and simpler code. Also update its callers
bitmap_*_region to receive and pass unsigned int. The return types of
bitmap_find_free_region and bitmap_allocate_region are still int to
allow a negative error code to be returned. An int is certainly
capable of representing any realistic return value.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 6 +++---
lib/bitmap.c | 12 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 83c1c7d..2100378 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -140,9 +140,9 @@ extern void bitmap_onto(unsigned long *dst, const unsigned
long *orig,
const unsigned long *relmap, int bits);
extern void bitmap_fold(unsigned long *dst, const unsigned long *orig,
int sz, int bits);
-extern int bitmap_find_free_region(unsigned long *bitmap, int bits, int order);
-extern void bitmap_release_region(unsigned long *bitmap, int pos, int order);
-extern int bitmap_allocate_region(unsigned long *bitmap, int pos, int order);
+extern int bitmap_find_free_region(unsigned long *bitmap, unsigned int bits,
int order);
+extern void bitmap_release_region(unsigned long *bitmap, unsigned int pos, int
order);
+extern int bitmap_allocate_region(unsigned long *bitmap, unsigned int pos, int
order);
extern void bitmap_copy_le(void *dst, const unsigned long *src, int nbits);
extern int bitmap_ord_to_pos(const unsigned long *bitmap, int n, int bits);
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 2714df9..c2f3807 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1042,7 +1042,7 @@ enum {
REG_OP_RELEASE, /* clear all bits in region */
};
-static int __reg_op(unsigned long *bitmap, int pos, int order, int reg_op)
+static int __reg_op(unsigned long *bitmap, unsigned int pos, int order, int
reg_op)
{
int nbits_reg; /* number of bits in region */
int index; /* index first long of region in bitmap */
@@ -1108,11 +1108,11 @@ done:
* Return the bit offset in bitmap of the allocated region,
* or -errno on failure.
*/
-int bitmap_find_free_region(unsigned long *bitmap, int bits, int order)
+int bitmap_find_free_region(unsigned long *bitmap, unsigned int bits, int
order)
{
- int pos, end; /* scans bitmap by regions of size order */
+ unsigned int pos, end; /* scans bitmap by regions of size
order */
- for (pos = 0 ; (end = pos + (1 << order)) <= bits; pos = end) {
+ for (pos = 0 ; (end = pos + (1U << order)) <= bits; pos = end) {
if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
continue;
__reg_op(bitmap, pos, order, REG_OP_ALLOC);
@@ -1133,7 +1133,7 @@ EXPORT_SYMBOL(bitmap_find_free_region);
*
* No return value.
*/
-void bitmap_release_region(unsigned long *bitmap, int pos, int order)
+void bitmap_release_region(unsigned long *bitmap, unsigned int pos, int order)
{
__reg_op(bitmap, pos, order, REG_OP_RELEASE);
}
@@ -1150,7 +1150,7 @@ EXPORT_SYMBOL(bitmap_release_region);
* Return 0 on success, or %-EBUSY if specified region wasn't
* free (not all bits were zero).
*/
-int bitmap_allocate_region(unsigned long *bitmap, int pos, int order)
+int bitmap_allocate_region(unsigned long *bitmap, unsigned int pos, int order)
{
if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
return -EBUSY;
--
1.9.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/
[PATCH 13/18] lib: bitmap: Fix typo in kerneldoc for bitmap_pos_to_ord
A few lines above, it was stated that positions for non-set bits are mapped to -1, which is obviously also what the code does. Signed-off-by: Rasmus Villemoes --- lib/bitmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/bitmap.c b/lib/bitmap.c index d4b3a6d..2714df9 100644 --- a/lib/bitmap.c +++ b/lib/bitmap.c @@ -712,7 +712,7 @@ EXPORT_SYMBOL(bitmap_parselist_user); * * If for example, just bits 4 through 7 are set in @buf, then @pos * values 4 through 7 will get mapped to 0 through 3, respectively, - * and other @pos values will get mapped to 0. When @pos value 7 + * and other @pos values will get mapped to -1. When @pos value 7 * gets mapped to (returns) @ord value 3 in this example, that means * that bit 7 is the 3rd (starting with 0th) set bit in @buf. * -- 1.9.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/
[PATCH 12/18] lib: bitmap: Simplify bitmap_parselist
We want len to be the index of the first '\n', or the length of the
string if there is no newline. This is a good example of the
usefulness of strchrnul(). Use that instead, thus eliminating a branch
and a call to strlen().
Signed-off-by: Rasmus Villemoes
---
lib/bitmap.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 5d25403..d4b3a6d 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -665,13 +665,8 @@ static int __bitmap_parselist(const char *buf, unsigned
int buflen,
int bitmap_parselist(const char *bp, unsigned long *maskp, int nmaskbits)
{
- char *nl = strchr(bp, '\n');
- int len;
-
- if (nl)
- len = nl - bp;
- else
- len = strlen(bp);
+ char *nl = strchrnul(bp, '\n');
+ int len = nl - bp;
return __bitmap_parselist(bp, len, 0, maskp, nmaskbits);
}
--
1.9.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/
[PATCH 09/18] lib: bitmap: Make nbits parameter of bitmap_weight unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "nbits" is non-negative. Since no-one passes a negative
bit-count, this shouldn't affect the semantics.
I didn't change the return type, since that might change the semantics
of some expression containing a call to bitmap_weight(). Certainly an
int is capable of holding the result.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4 ++--
lib/bitmap.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 87e88f7..64b0ebe 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -110,7 +110,7 @@ extern int __bitmap_intersects(const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int nbits);
extern int __bitmap_subset(const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int nbits);
-extern int __bitmap_weight(const unsigned long *bitmap, int bits);
+extern int __bitmap_weight(const unsigned long *bitmap, unsigned int nbits);
extern void bitmap_set(unsigned long *map, int i, int len);
extern void bitmap_clear(unsigned long *map, int start, int nr);
@@ -273,7 +273,7 @@ static inline int bitmap_full(const unsigned long *src,
unsigned int nbits)
return __bitmap_full(src, nbits);
}
-static inline int bitmap_weight(const unsigned long *src, int nbits)
+static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)
{
if (small_const_nbits(nbits))
return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
diff --git a/lib/bitmap.c b/lib/bitmap.c
index c9bff53..f69435c 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -259,9 +259,10 @@ int __bitmap_subset(const unsigned long *bitmap1,
}
EXPORT_SYMBOL(__bitmap_subset);
-int __bitmap_weight(const unsigned long *bitmap, int bits)
+int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
{
- int k, w = 0, lim = bits/BITS_PER_LONG;
+ unsigned int k, lim = bits/BITS_PER_LONG;
+ int w = 0;
for (k = 0; k < lim; k++)
w += hweight_long(bitmap[k]);
--
1.9.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/
[PATCH 08/18] lib: bitmap: Make nbits parameter of bitmap_subset unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "nbits" is non-negative. Since no-one passes a
negative bit-count, this shouldn't affect the semantics.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4 ++--
lib/bitmap.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 2f3f3a4..87e88f7 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -109,7 +109,7 @@ extern int __bitmap_andnot(unsigned long *dst, const
unsigned long *bitmap1,
extern int __bitmap_intersects(const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int nbits);
extern int __bitmap_subset(const unsigned long *bitmap1,
- const unsigned long *bitmap2, int bits);
+ const unsigned long *bitmap2, unsigned int nbits);
extern int __bitmap_weight(const unsigned long *bitmap, int bits);
extern void bitmap_set(unsigned long *map, int i, int len);
@@ -249,7 +249,7 @@ static inline int bitmap_intersects(const unsigned long
*src1,
}
static inline int bitmap_subset(const unsigned long *src1,
- const unsigned long *src2, int nbits)
+ const unsigned long *src2, unsigned int nbits)
{
if (small_const_nbits(nbits))
return ! ((*src1 & ~(*src2)) & BITMAP_LAST_WORD_MASK(nbits));
diff --git a/lib/bitmap.c b/lib/bitmap.c
index e85daa9..c9bff53 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -245,9 +245,9 @@ int __bitmap_intersects(const unsigned long *bitmap1,
EXPORT_SYMBOL(__bitmap_intersects);
int __bitmap_subset(const unsigned long *bitmap1,
- const unsigned long *bitmap2, int bits)
+ const unsigned long *bitmap2, unsigned int bits)
{
- int k, lim = bits/BITS_PER_LONG;
+ unsigned int k, lim = bits/BITS_PER_LONG;
for (k = 0; k < lim; ++k)
if (bitmap1[k] & ~bitmap2[k])
return 0;
--
1.9.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/
[PATCH 11/18] lib: bitmap: Make the start index of bitmap_clear unsigned
The compiler can generate slightly smaller and simpler code when it
knows that "start" is non-negative.
Also, use the names "start" and "len" for the two parameters for
consistency with bitmap_set.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 2 +-
lib/bitmap.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index ad2c67d..83c1c7d 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -113,7 +113,7 @@ extern int __bitmap_subset(const unsigned long *bitmap1,
extern int __bitmap_weight(const unsigned long *bitmap, unsigned int nbits);
extern void bitmap_set(unsigned long *map, unsigned int start, int len);
-extern void bitmap_clear(unsigned long *map, int start, int nr);
+extern void bitmap_clear(unsigned long *map, unsigned int start, int len);
extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
unsigned long size,
unsigned long start,
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 2a3a92f..5d25403 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -295,21 +295,21 @@ void bitmap_set(unsigned long *map, unsigned int start,
int len)
}
EXPORT_SYMBOL(bitmap_set);
-void bitmap_clear(unsigned long *map, int start, int nr)
+void bitmap_clear(unsigned long *map, unsigned int start, int len)
{
unsigned long *p = map + BIT_WORD(start);
- const int size = start + nr;
+ const unsigned int size = start + len;
int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK(start);
- while (nr - bits_to_clear >= 0) {
+ while (len - bits_to_clear >= 0) {
*p &= ~mask_to_clear;
- nr -= bits_to_clear;
+ len -= bits_to_clear;
bits_to_clear = BITS_PER_LONG;
mask_to_clear = ~0UL;
p++;
}
- if (nr) {
+ if (len) {
mask_to_clear &= BITMAP_LAST_WORD_MASK(size);
*p &= ~mask_to_clear;
}
--
1.9.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/
