Re: [PATCH] perf tools: fix type mismatch - long vs __statfs_word
+CC acme, Peter On Wednesday 13 August 2014 10:34 PM, Alexey Brodkin wrote: > From "include/uapi/asm-generic/statfs.h" it is seen that "statfs.f_type" is of > type "__statfs_word" which in its turn is "__u32" (unsigned int) for 32-bit > systems. > > So in case of compilation with "-Werror" following breakage happens: > --->--- > fs.c: In function ‘fs__valid_mount’: > fs.c:76:24: error: comparison between signed and unsigned integer expressions > [-Werror=sign-compare] > else if (st_fs.f_type != magic) > ^ > cc1: all warnings being treated as errors > --->--- > > Note that now when fs.c is in "lib/api/fs" and in "tools/lib/api/Makefile" > CFLAGS has hard-coded "-Werror" this is inevitable even if one builds "perf" > with "WERROR=0". > > Signed-off-by: Alexey Brodkin > > Cc: Vineet Gupta > Cc: Borislav Petkov > Cc: Jiri Olsa > Cc: Cody P Schafer > Cc: Arnaldo Carvalho de Melo > --- > tools/lib/api/fs/fs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c > index c1b49c3..4b2fa7b 100644 > --- a/tools/lib/api/fs/fs.c > +++ b/tools/lib/api/fs/fs.c > @@ -75,7 +75,7 @@ static int fs__valid_mount(const char *fs, long magic) > > if (statfs(fs, _fs) < 0) > return -ENOENT; > - else if (st_fs.f_type != magic) > + else if ((long)st_fs.f_type != magic) > return -ENOENT; > > return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: lustre: lmv: lmv_internal.h: fix checkpatch.pl spacing errors
lmv_internal.h:96: ERROR: space prohibited after that open parenthesis '('
lmv_internal.h:96: ERROR: space required before the open parenthesis '('
lmv_internal.h:147: WARNING: space prohibited between function name and open
parenthesis '('
Signed-off-by: Juston Li
---
drivers/staging/lustre/lustre/lmv/lmv_internal.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lmv/lmv_internal.h
b/drivers/staging/lustre/lustre/lmv/lmv_internal.h
index 80e6604..b911e76 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_internal.h
+++ b/drivers/staging/lustre/lustre/lmv/lmv_internal.h
@@ -93,7 +93,7 @@ static inline struct lmv_stripe_md *lmv_get_mea(struct
ptlrpc_request *req)
if (mea->mea_count == 0)
return NULL;
- if( mea->mea_magic != MEA_MAGIC_LAST_CHAR &&
+ if (mea->mea_magic != MEA_MAGIC_LAST_CHAR &&
mea->mea_magic != MEA_MAGIC_ALL_CHARS &&
mea->mea_magic != MEA_MAGIC_HASH_SEGMENT)
return NULL;
@@ -144,7 +144,7 @@ struct lmv_tgt_desc
*lmv_locate_mds(struct lmv_obd *lmv, struct md_op_data *op_data,
struct lu_fid *fid);
/* lproc_lmv.c */
-#if defined (CONFIG_PROC_FS)
+#if defined(CONFIG_PROC_FS)
void lprocfs_lmv_init_vars(struct lprocfs_static_vars *lvars);
#else
static inline void lprocfs_lmv_init_vars(struct lprocfs_static_vars *lvars)
--
2.1.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/
Re: [PATCH v9 net-next 2/4] net: filter: split filter.h and expose eBPF to user space
On Wed, Sep 3, 2014 at 8:46 AM, Daniel Borkmann wrote: > On 09/03/2014 05:17 AM, Alexei Starovoitov wrote: >> >> allow user space to generate eBPF programs >> >> uapi/linux/bpf.h: eBPF instruction set definition >> >> linux/filter.h: the rest >> >> This patch only moves macro definitions, but practically it freezes >> existing >> eBPF instruction set, though new instructions can still be added in the >> future. >> >> These eBPF definitions cannot go into uapi/linux/filter.h, since the names >> may conflict with existing applications. >> >> Full eBPF ISA description is in Documentation/networking/filter.txt >> >> Signed-off-by: Alexei Starovoitov > > > Ok, given you post the remaining two RFCs later on this window as > you indicate, I have no objections: > > Acked-by: Daniel Borkmann David, I see that all 4 patches are marked as rfc, whereas I tagged only 3 and 4 as 'rfc' and mentioned in cover letter that they will be coming for real in stage III. Here they support patch 2 and show the future changes to bpf.h file. Patches 1 and 2 are good to go. Note that they're on top of Hannes's patch: http://patchwork.ozlabs.org/patch/385266/ Do you want me to resubmit just first two? 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 v4] x86, hotplug: fix llc shared map unreleased during cpu hotplug
(2014/09/04 14:20), Ingo Molnar wrote: * Wanpeng Li wrote: BUG: unable to handle kernel NULL pointer dereference at 0004 IP: [..] find_busiest_group PGD 5a9d5067 PUD 13067 PMD 0 Oops: [#3] SMP [...] Call Trace: load_balance ? _raw_spin_unlock_irqrestore idle_balance __schedule schedule schedule_timeout ? lock_timer_base schedule_timeout_uninterruptible msleep lock_device_hotplug_sysfs online_store dev_attr_store sysfs_write_file vfs_write SyS_write system_call_fastpath Last level cache shared map is built during cpu up and build sched domain routine takes advantage of it to setup sched domain cpu topology, however, llc shared map is unreleased during cpu disable which lead to invalid sched domain cpu topology. This patch fix it by release llc shared map correctly during cpu disable. Very little is said in this changelog about how the bug was found, how likely it is to occur for others, what systems are affected, etc. Hi Wanpeng, In my understanding, the panic occurs by just onlining CPU as follows: echo 1 > /sys/devices/system/cpu/cpuX/online So, how about add the information? Thanks, Yasuaki Ishimatsu Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:locking/core] locking/semaphore: Resolve some shadow warnings
Commit-ID: 315427691c7a064718b5ad7d378d7f1c1898a626
Gitweb: http://git.kernel.org/tip/315427691c7a064718b5ad7d378d7f1c1898a626
Author: Mark Rustad
AuthorDate: Wed, 3 Sep 2014 03:17:24 -0700
Committer: Ingo Molnar
CommitDate: Thu, 4 Sep 2014 07:17:24 +0200
locking/semaphore: Resolve some shadow warnings
Resolve some shadow warnings resulting from using the name
jiffies, which is a well-known global. This is not a problem
of course, but it could be a trap for someone copying and
pasting code, and it just makes W=2 a little cleaner.
Signed-off-by: Mark Rustad
Signed-off-by: Jeff Kirsher
Acked-by: Peter Zijlstra
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Paul E. McKenney
Link:
http://lkml.kernel.org/r/1409739444-13635-1-git-send-email-jeffrey.t.kirs...@intel.com
Signed-off-by: Ingo Molnar
---
kernel/locking/semaphore.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 6815171..b8120ab 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -36,7 +36,7 @@
static noinline void __down(struct semaphore *sem);
static noinline int __down_interruptible(struct semaphore *sem);
static noinline int __down_killable(struct semaphore *sem);
-static noinline int __down_timeout(struct semaphore *sem, long jiffies);
+static noinline int __down_timeout(struct semaphore *sem, long timeout);
static noinline void __up(struct semaphore *sem);
/**
@@ -145,14 +145,14 @@ EXPORT_SYMBOL(down_trylock);
/**
* down_timeout - acquire the semaphore within a specified time
* @sem: the semaphore to be acquired
- * @jiffies: how long to wait before failing
+ * @timeout: how long to wait before failing
*
* Attempts to acquire the semaphore. If no more tasks are allowed to
* acquire the semaphore, calling this function will put the task to sleep.
* If the semaphore is not released within the specified number of jiffies,
* this function returns -ETIME. It returns 0 if the semaphore was acquired.
*/
-int down_timeout(struct semaphore *sem, long jiffies)
+int down_timeout(struct semaphore *sem, long timeout)
{
unsigned long flags;
int result = 0;
@@ -161,7 +161,7 @@ int down_timeout(struct semaphore *sem, long jiffies)
if (likely(sem->count > 0))
sem->count--;
else
- result = __down_timeout(sem, jiffies);
+ result = __down_timeout(sem, timeout);
raw_spin_unlock_irqrestore(>lock, flags);
return result;
@@ -248,9 +248,9 @@ static noinline int __sched __down_killable(struct
semaphore *sem)
return __down_common(sem, TASK_KILLABLE, MAX_SCHEDULE_TIMEOUT);
}
-static noinline int __sched __down_timeout(struct semaphore *sem, long jiffies)
+static noinline int __sched __down_timeout(struct semaphore *sem, long timeout)
{
- return __down_common(sem, TASK_UNINTERRUPTIBLE, jiffies);
+ return __down_common(sem, TASK_UNINTERRUPTIBLE, timeout);
}
static noinline void __sched __up(struct semaphore *sem)
--
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 4/4] kconfig: link CONFIG_CROSS_COMPILE with environment variable
On Thu, Sep 4, 2014 at 1:11 AM, Paul Bolle wrote: > Hi Konstantin, > > On Mon, 2014-09-01 at 11:16 +0400, Konstantin Khlebnikov wrote: >> Cross-compiler tool prefix can be set in command line, in the environment >> variable CROSS_COMPILE or in config file, in option CONFIG_COROSS_COMPILE. >> Also some arch/*/Makefile provides default value. >> >> This patch links config option CONFIG_CROSS_COMPILE and variable >> CROSS_COMPILE >> in both directions: environment/command line has higher priority and updates >> value saved in the config file, config option acts as default value for it. >> >> This is especially useful together with option O=dir which allows to create >> separate directory for each target architecture and kernel flavor: >> >> # make O=build/arm ARCH=arm CROSS_COMPILE=arm-none-eabi- defconfig >> # make -C build/arm >> >> Signed-off-by: Konstantin Khlebnikov > > I have only had a quick glance at this series. Just a quick question to > help me understand where it is going. > > Would this patch mean that, if a (def)config file has both ARCH and > CROSS_COMPILE set, one could use that (def)config file and invoke "make > $whatever_target" and expect it to do the right thing (provided a > suitable cross compiler is installed)? > > This implies cross compiler prefixes are standardized across > distributions, I guess. Maybe they're not. As I know they are not strictly standardized. Naming convention is arch[-vendor][-os]-abi, but there is a lot of possible combinations. > >> --- >> Makefile |6 +- >> init/Kconfig |1 + >> 2 files changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/Makefile b/Makefile >> index f648405..1044f40 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -263,7 +263,11 @@ endif >> # "make" in the configured kernel build directory always uses that. >> # Default value for CROSS_COMPILE is not to prefix executables >> # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile >> -CROSS_COMPILE?= $(CONFIG_CROSS_COMPILE:"%"=%) >> +ifndef CROSS_COMPILE >> + CROSS_COMPILE := $(shell $(srctree)/scripts/config \ >> + --file $(KBUILD_OUTPUT)$(KCONFIG_CONFIG) \ >> + --if-undef "" --state "CROSS_COMPILE") >> +endif >> >> # Architecture as present in compile.h >> UTS_MACHINE := $(ARCH) >> diff --git a/init/Kconfig b/init/Kconfig >> index e84c642..1c2f621 100644 >> --- a/init/Kconfig >> +++ b/init/Kconfig >> @@ -47,6 +47,7 @@ config INIT_ENV_ARG_LIMIT >> >> config CROSS_COMPILE >> string "Cross-compiler tool prefix" >> + option env="CROSS_COMPILE" >> help >> Same as running 'make CROSS_COMPILE=prefix-' but stored for >> default make runs in this kernel build directory. You don't >> > > > Paul Bolle > -- 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] mmc: dw_mmc: Don't enable interrupts until we're ready
Hi Doug
On 09/03/2014 08:37 AM, Doug Anderson wrote:
> On dw_mmc there's a small race if you happen to get a card detect
> interrupt at just the wrong time during probe. You may have enabled
> the interrupt but host->slot[0] may be NULL.
>
> Fix the race by enabling interrupts all the way at the end of the
> probe. We can also use free_irq() instead of dw_mmc specific masking
> to mask the IRQ at removal time. Note that since we're now managing
> freeing of the irq ourselves, there's no need to use devm.
>
> FYI, the crash would look like:
> dwmmc_rockchip ff0c.dwmmc: DW MMC controller at irq 64, 32 bit host
> data width, 256 deep fifo
> Unable to handle kernel NULL pointer dereference at virtual address
> pgd = c0004000
> [] *pgd=
> ...
> ...
> [] (dw_mci_work_routine_card) from []
> (process_one_work+0x260/0x3c4)
> [] (process_one_work) from []
> (worker_thread+0x240/0x3a8)
> [] (worker_thread) from [] (kthread+0x100/0x118)
> [] (kthread) from [] (ret_from_fork+0x14/0x20)
>
> Signed-off-by: Doug Anderson
> ---
> FYI: making dw_mmc into a module and trying module removal was not
> tested. I'd appreciate any testing that folks can do there. This
> code should be the equivalent and makes the error case of probe match
> the removal case more closely now.
>
> drivers/mmc/host/dw_mmc.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 7f227e9..540ba3c 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2577,10 +2577,6 @@ int dw_mci_probe(struct dw_mci *host)
> goto err_dmaunmap;
> }
> INIT_WORK(>card_work, dw_mci_work_routine_card);
> - ret = devm_request_irq(host->dev, host->irq, dw_mci_interrupt,
> -host->irq_flags, "dw-mci", host);
> - if (ret)
> - goto err_workqueue;
>
> if (host->pdata->num_slots)
> host->num_slots = host->pdata->num_slots;
> @@ -2619,11 +2615,21 @@ int dw_mci_probe(struct dw_mci *host)
> goto err_workqueue;
> }
>
> + ret = request_irq(host->irq, dw_mci_interrupt, host->irq_flags,
> + "dw-mci", host);
> + if (ret)
> + goto err_initted;
I didn't test and consider race condition yet.
But if located "request_irq" at here, we can be confused something,
since there is "dev_info(host->dev, "%d slots initialized\n", init_slots)"
message at above.
I think you can relocate this.
Best Regards,
Jaehoon Chung
> +
> if (host->quirks & DW_MCI_QUIRK_IDMAC_DTO)
> dev_info(host->dev, "Internal DMAC interrupt fix enabled.\n");
>
> return 0;
>
> +err_initted:
> + for (i = 0; i < host->num_slots; i++)
> + if (host->slot[i])
> + dw_mci_cleanup_slot(host->slot[i], i);
> +
> err_workqueue:
> destroy_workqueue(host->card_workqueue);
>
> @@ -2649,8 +2655,7 @@ void dw_mci_remove(struct dw_mci *host)
> {
> int i;
>
> - mci_writel(host, RINTSTS, 0x);
> - mci_writel(host, INTMASK, 0); /* disable all mmc interrupt first */
> + free_irq(host->irq, host);
>
> for (i = 0; i < host->num_slots; i++) {
> dev_dbg(host->dev, "remove slot %d\n", i);
>
--
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 v4] x86, hotplug: fix llc shared map unreleased during cpu hotplug
* Wanpeng Li wrote: > BUG: unable to handle kernel NULL pointer dereference at 0004 > IP: [..] find_busiest_group > PGD 5a9d5067 PUD 13067 PMD 0 > Oops: [#3] SMP > [...] > Call Trace: > load_balance > ? _raw_spin_unlock_irqrestore > idle_balance > __schedule > schedule > schedule_timeout > ? lock_timer_base > schedule_timeout_uninterruptible > msleep > lock_device_hotplug_sysfs > online_store > dev_attr_store > sysfs_write_file > vfs_write > SyS_write > system_call_fastpath > > Last level cache shared map is built during cpu up and build sched domain > routine takes advantage of it to setup sched domain cpu topology, however, > llc shared map is unreleased during cpu disable which lead to invalid sched > domain cpu topology. This patch fix it by release llc shared map correctly > during cpu disable. Very little is said in this changelog about how the bug was found, how likely it is to occur for others, what systems are affected, etc. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/26] locking: Add non-fatal spin lock assert
* Peter Zijlstra wrote: > On Wed, Sep 03, 2014 at 10:50:01AM -0400, Peter Hurley wrote: > > So a lockdep-only assert is unlikely to draw attention to existing bugs, > > especially in established drivers. > > By the same logic lockdep will not find locking errors in established > drivers. Indeed, this patch is ill-advised in several ways: - it extends an API variant that we want to phase - emits a warning even if say lockdep has already emitted a warning and locking state is not guaranteed to be consistent. - makes the kernel more expensive once fully debugged, in that non-fatal checks are unconditional. Also please submit locking related patches as standalone series to the locking subsystem, not embedded in an unrelated series. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] pinctrl: imx/mxs: move freescale drivers to subdir
On Wed, Sep 03, 2014 at 02:13:56PM +0200, Linus Walleij wrote: > This moves all the Freescale-related drivers (i.MX and MXS) to > its own subdirectory to clear the view. > > Cc: Alexander Shiyan > Cc: Shawn Guo > Cc: Anson Huang > Cc: Fabio Estevam > Cc: Denis Carikli > Cc: Markus Pargmann > Cc: Greg Ungerer > Cc: Sascha Hauer > Signed-off-by: Linus Walleij Acked-by: Shawn Guo -- 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: Tainting the kernel on raw I/O access
* H. Peter Anvin wrote: > In a meeting earlier today, we discussed MSR access and that it could be > used to do bad things. The same applies to other forms of raw I/O > (/dev/mem, /dev/port, ioperm, iopl, etc.) > > This is basically the same problem with which the secure boot people > have been struggling. > > Peter Z. suggested we should taint the kernel on raw I/O access, and I > tend to concur. Lets start with the 'only for developers and the crazy' interfaces, like /dev/msr access, and extend it step by step? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] QE: move qe code from arch/powerpc to drivers/soc
LS1 is arm cpu and it has qe ip block.
move qe code from platform directory to public directory.
QE is an IP block integrates several comunications peripheral
controllers. It can implement a variety of applications, such
as uart, usb and tdm and so on.
Signed-off-by: Zhao Qiang
---
Changes for v2:
- mv code to drivers/soc
arch/powerpc/Kconfig | 2 -
arch/powerpc/platforms/83xx/km83xx.c | 4 +-
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
arch/powerpc/platforms/Kconfig | 19 -
arch/powerpc/sysdev/Makefile | 1 -
arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
drivers/soc/Kconfig| 2 +
drivers/soc/Makefile | 2 +
drivers/soc/qe/Kconfig | 45 ++
.../sysdev/qe_lib => drivers/soc/qe}/Makefile | 0
.../sysdev/qe_lib => drivers/soc/qe}/gpio.c| 2 +-
.../powerpc/sysdev/qe_lib => drivers/soc/qe}/qe.c | 4 +-
.../sysdev/qe_lib => drivers/soc/qe}/qe_ic.c | 2 +-
.../sysdev/qe_lib => drivers/soc/qe}/qe_ic.h | 2 +-
.../sysdev/qe_lib => drivers/soc/qe}/qe_io.c | 2 +-
.../powerpc/sysdev/qe_lib => drivers/soc/qe}/ucc.c | 6 +--
.../sysdev/qe_lib => drivers/soc/qe}/ucc_fast.c| 8 ++--
.../sysdev/qe_lib => drivers/soc/qe}/ucc_slow.c| 8 ++--
.../powerpc/sysdev/qe_lib => drivers/soc/qe}/usb.c | 4 +-
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 +-
.../include/asm => include/linux/fsl}/immap_qe.h | 0
.../powerpc/include/asm => include/linux/fsl}/qe.h | 2 +-
.../include/asm => include/linux/fsl}/qe_ic.h | 0
.../include/asm => include/linux/fsl}/ucc.h| 4 +-
.../include/asm => include/linux/fsl}/ucc_fast.h | 6 +--
.../include/asm => include/linux/fsl}/ucc_slow.h | 6 +--
44 files changed, 113 insertions(+), 113 deletions(-)
delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig
create mode 100644 drivers/soc/qe/Kconfig
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/Makefile (100%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/gpio.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe_ic.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe_ic.h (98%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe_io.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/ucc.c (98%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/ucc_fast.c (98%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/ucc_slow.c (98%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/usb.c (96%)
rename {arch/powerpc/include/asm => include/linux/fsl}/immap_qe.h (100%)
rename {arch/powerpc/include/asm => include/linux/fsl}/qe.h (99%)
rename {arch/powerpc/include/asm => include/linux/fsl}/qe_ic.h (100%)
rename {arch/powerpc/include/asm => include/linux/fsl}/ucc.h (96%)
rename {arch/powerpc/include/asm => include/linux/fsl}/ucc_fast.h (98%)
rename {arch/powerpc/include/asm => include/linux/fsl}/ucc_slow.h (99%)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index bd6dd6e..65ca032 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1050,8 +1050,6 @@ source "drivers/Kconfig"
source "fs/Kconfig"
-source "arch/powerpc/sysdev/qe_lib/Kconfig"
-
source "lib/Kconfig"
source "arch/powerpc/Kconfig.debug"
diff --git a/arch/powerpc/platforms/83xx/km83xx.c
b/arch/powerpc/platforms/83xx/km83xx.c
index bf4c447..584d8cc 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -37,8 +37,8 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/misc.c
Re: [PATCH] mmc: sdhci-msm: Make tuning block table endian agnostic
Hi, Stephen.
On 09/03/2014 10:57 PM, Stephen Boyd wrote:
> If we're tuning on a big-endian CPU we'll never determine we properly
> tuned the device because we compare the data we received from the
> controller with a table that assumes the CPU is little-endian.
> Change the table to be an array of bytes instead of 32-bit words
> so we can use memcmp() without needing to byte-swap every word
> depending on the endianess of the CPU.
>
> Cc: Asutosh Das
> Cc: Venkat Gopalakrishnan
> Reviewed-by: Georgi Djakov
> Fixes: 415b5a75da43 "mmc: sdhci-msm: Add platform_execute_tuning
> implementation"
> Signed-off-by: Stephen Boyd
> ---
> drivers/mmc/host/sdhci-msm.c | 42 +++---
> 1 file changed, 27 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 40573a58486a..5aabffc15ae8 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -47,22 +47,34 @@
> #define CMUX_SHIFT_PHASE_SHIFT 24
> #define CMUX_SHIFT_PHASE_MASK(7 << CMUX_SHIFT_PHASE_SHIFT)
>
> -static const u32 tuning_block_64[] = {
> - 0x00ff0fff, 0xccc3ccff, 0xffcc3cc3, 0xeffefffe,
> - 0xddffdfff, 0xfbfffbff, 0xff7fffbf, 0xefbdf777,
> - 0xf0fff0ff, 0x3cccfc0f, 0xcfcc33cc, 0xeeffefff,
> - 0xfdfffdff, 0xffbfffdf, 0xfff7ffbb, 0xde7b7ff7
> +static const u8 tuning_block_64[] = {
> + 0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
> + 0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
> + 0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
> + 0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
> + 0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
> + 0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
> + 0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
> + 0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
> };
>
> -static const u32 tuning_block_128[] = {
> - 0xff00, 0x, 0x, 0x33cc,
> - 0xcccc, 0x, 0xeeff, 0xffff,
> - 0xffdd, 0x, 0xbbff, 0xbbff,
> - 0xffbb, 0xff77, 0x77ff, 0xffeeddbb,
> - 0x00ff, 0x00ff, 0xcc00, 0xcc33,
> - 0x, 0xffcc, 0xffee, 0x,
> - 0xddff, 0xddff, 0xffdd, 0xffbb,
> - 0x, 0x77ff, 0xffff, 0xeeddbb77
> +static const u8 tuning_block_128[] = {
> + 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
> + 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
> + 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
> + 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
> + 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
> + 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
> + 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
> + 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
> + 0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
> + 0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
> + 0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
> + 0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
> + 0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
> + 0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
> + 0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
> + 0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
> };
In dw-mmc.c, tuning_block values are same.
So I think we can move these value into generic header. how about?
Best Regards,
Jaehoon Chung
>
> struct sdhci_msm_host {
> @@ -359,7 +371,7 @@ static int sdhci_msm_execute_tuning(struct sdhci_host
> *host, u32 opcode)
> {
> int tuning_seq_cnt = 3;
> u8 phase, *data_buf, tuned_phases[16], tuned_phase_cnt = 0;
> - const u32 *tuning_block_pattern = tuning_block_64;
> + const u8 *tuning_block_pattern = tuning_block_64;
> int size = sizeof(tuning_block_64); /* Pattern size in bytes */
> int rc;
> struct mmc_host *mmc = host->mmc;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] do_exit(): Solve possibility of BUG() due to race with try_to_wake_up()
* Peter Zijlstra wrote: > > Ah, I simply do not know what is cheaper, even on x86. Well, > > we need to enable/disable irqs, but again I do not really > > know how much does this cost. > > Ah good point about that IRQ thing, yes that's horribly > expensive. Enabling/disabling local IRQs is not really expensive (it's a flat cost essentially - below 10 cycles on modern x86 CPUs) - especially if we consider the 100x-1000x frequency difference between schedule() and exit(), on typical systems: $ grep -E 'ctxt|processes' /proc/stat ctxt 47166536 processes 91876 And that's from a system that emphatically does not schedule much. On others the difference is much larger. So please don't push complexity into the scheduler from lower-freq areas of the kernel! Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RESEND PATCH] arm64: dts: add symlink
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Tuesday, September 02, 2014 2:12 PM
> To: Pankaj Dubey
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; naus...@samsung.com; Catalin Marinas;
> robh...@kernel.org; thomas...@samsung.com
> Subject: Re: [RESEND PATCH] arm64: dts: add symlink
>
> On Tue, Sep 02, 2014 at 04:49:16AM +0100, Pankaj Dubey wrote:
> > Add symlink to include/dt-bindings from arch/arm64/boot/dts/include/
> > to match the ones in ARM architectures so that preprocessed device
> > tree files can include various useful constant definitions.
> >
> > See commit c58299aa8754 ("kbuild: create an "include chroot" for DT
> > bindings") merged in v3.10-rc1 for details.
> >
> > CC: Catalin Marinas
> > Signed-off-by: Pankaj Dubey
> > ---
> >
> > Resubmitting this change as now it will be required for Samsung ARM64
> > based SoC.
>
> Just include this change in the series adding a .dts that needs it -- it
doesn't really
> make sense in isolation (unless somebody desperately wants this in?).
>
OK, we will include this patch in series adding a .dts that needs it in next
respin.
@Naveen: Please include this patch whenever you are respinning Exynos7 dts
patches.
Thanks,
Pankaj Dubey
> Will
--
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] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set
On 09/04/2014 10:30 AM, Andrew Morton wrote:
> On Thu, 04 Sep 2014 10:08:09 +0800 Junxiao Bi wrote:
>
>> On 09/04/2014 07:10 AM, Andrew Morton wrote:
>>> On Wed, 3 Sep 2014 13:54:54 +0800 Junxiao Bi wrote:
>>>
commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
during memory allocation")
introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory
allocation, __GFP_IO is cleared
when this flag is set, but __GFP_FS implies __GFP_IO, it should also be
cleared. Or it may still
run into I/O, like in superblock shrinker.
>>>
>>> Is there an actual bug which inspired this fix? If so, please describe
>>> it.
>>>
>> Yes, an ocfs2 deadlock bug is related to this, there is a workqueue in
>> ocfs2 who is for building tcp connections and processing ocfs2 message.
>> Like when an new node is up in ocfs2 cluster, the workqueue will try to
>> build the connections to it, since there are some common code in
>> networking like sock_alloc() using GFP_KERNEL to allocate memory, direct
>> reclaim will be triggered and call into superblock shrinker if available
>> memory is not enough even set PF_MEMALLOC_NOIO for the workqueue. To
>> shrink the inode cache, ocfs2 needs release cluster lock and this
>> depends on workqueue to do it, so cause the deadlock. Not sure whether
>> there are similar issue for other cluster fs, like nfs, it is possible
>> rpciod hung like the ocfs2 workqueue?
>
> All this info should be in the changelog.
>
>>
>>> I don't think it's accurate to say that __GFP_FS implies __GFP_IO.
>>> Where did that info come from?
>> __GFP_FS allowed callback into fs during memory allocation, and fs may
>> do io whatever __GFP_IO is set?
>
> __GFP_FS and __GFP_IO are (or were) for communicating to vmscan: don't
> enter the fs for writepage, don't write back swapcache.
>
> I guess those concepts have grown over time without a ton of thought
> going into it. Yes, I suppose that if a filesystem's writepage is
> called (for example) it expects that it will be able to perform
> writeback and it won't check (or even be passed) the __GFP_IO setting.
>
> So I guess we could say that !__GFP_FS && GFP_IO is not implemented and
> shouldn't occur.
>
> That being said, it still seems quite bad to disable VFS cache
> shrinking for PF_MEMALLOC_NOIO allocation attempts.
Even without this ocfs2 deadlock bug, the implement of PF_MEMALLOC_NOIO
is wrong. See the deadlock case described in its log below. Let see the
case "block device runtime resume", since __GFP_FS is not cleared, it
could run into fs writepage and cause deadlock.
>From 21caf2fc1931b485483ddd254b634fa8f0099963 Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Fri, 22 Feb 2013 16:34:08 -0800
Subject: [PATCH] mm: teach mm by current context info to not do I/O during
memory allocation
This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
'struct task_struct'), so that the flag can be set by one task to avoid
doing I/O inside memory allocation in the task's context.
The patch trys to solve one deadlock problem caused by block device, and
the problem may happen at least in the below situations:
- during block device runtime resume, if memory allocation with
GFP_KERNEL is called inside runtime resume callback of any one of its
ancestors(or the block device itself), the deadlock may be triggered
inside the memory allocation since it might not complete until the block
device becomes active and the involed page I/O finishes. The situation
is pointed out first by Alan Stern. It is not a good approach to
convert all GFP_KERNEL[1] in the path into GFP_NOIO because several
subsystems may be involved(for example, PCI, USB and SCSI may be
involved for usb mass stoarage device, network devices involved too in
the iSCSI case)
- during block device runtime suspend, because runtime resume need to
wait for completion of concurrent runtime suspend.
- during error handling of usb mass storage deivce, USB bus reset will
be put on the device, so there shouldn't have any memory allocation with
GFP_KERNEL during USB bus reset, otherwise the deadlock similar with
above may be triggered. Unfortunately, any usb device may include one
mass storage interface in theory, so it requires all usb interface
drivers to handle the situation. In fact, most usb drivers don't know
how to handle bus reset on the device and don't provide .pre_set() and
.post_reset() callback at all, so USB core has to unbind and bind driver
for these devices. So it is still not practical to resort to GFP_NOIO
for solving the problem.
Thanks,
Junxiao.
>
>>>
>>> And the superblock shrinker is a good example of why this shouldn't be
>>> the case. The main thing that code does is to reclaim clean fs objects
>>> without performing IO. AFAICT the proposed patch will significantly
>>> weaken PF_MEMALLOC_NOIO allocation attempts by needlessly preventing
>>> the kernel from reclaiming such
Re: [PATCH 3.14 00/88] 3.14.18-stable review
On 09/03/2014 04:44 PM, Greg Kroah-Hartman wrote: On Wed, Sep 03, 2014 at 03:04:34PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.18 release. There are 88 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Sep 5 22:04:52 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.18-rc1.gz and the diffstat can be found below. -rc2 is out to fix some issues: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.18-rc2.gz Build results: total: 137 pass: 137 fail: 0 Qemu tests all passed. Detailed build and test results are available at http://server.roeck-us.net:8010/builders. On a side note, I got an error on e-mails to linux-foundation.org. Should that have been linuxfoundation.org ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
Thu, 04 Sep 2014 10:09:19 +0530 от Pankaj Dubey :
> Hi Arnd,
>
> On Tuesday, September 02, 2014 Arnd Bergmann wrote,
> > To: Pankaj Dubey
> > Cc: linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; lee.jo...@linaro.org; kgene@samsung.com;
> > li...@arm.linux.org.uk; vikas.saj...@samsung.com; jo...@samsung.com;
> > naus...@samsung.com; thomas...@samsung.com; chow@samsung.com;
> > tomasz.f...@gmail.com; Tomasz Figa; Alexander Shiyan; Michal Simek
> > Subject: Re: [PATCH v2] mfd: syscon: Decouple syscon interface from
> platform
> > devices
...
> > > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) -{
> > > - struct device *dev;
> > > - struct syscon *syscon;
> > > -
> > > - dev = driver_find_device(_driver.driver, NULL, (void *)s,
> > > - syscon_match_pdevname);
> > > - if (!dev)
> > > - return ERR_PTR(-EPROBE_DEFER);
> > > -
> > > - syscon = dev_get_drvdata(dev);
> > > -
> > > - return syscon->regmap;
> > > -}
> > > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
> >
> > I think this can actually be left intact if that helps with clps71xx.
> > It could be done in a hacky way using bus_find_device_by_name() to keep it
> simple,
> > or in a somewhat nicer way by keeping the syscon platform_driver around
> for the
> > non-DT case.
> >
>
> Ok as per our last discussion you mentioned that clps71xx will be soon
> migrating to DT.
> So if that is not going to happen sooner, I would also prefer better keep
> syscon_regmap_lookup_by_pdevname and syscon platform_driver for non-DT case,
> so that this issue should not block this patch.
>
> So please let's make final call to keep syscon platform_driver for non-DT
> case which eventually
> can be dropped once clps71xx driver migrates to DT based. So that I can
> prepare next patchset
> keeping syscon platform_driver support and syscon_regmap_lookup_by_pdevname
> API support
> for non-DT case and send across for review.
Arnd, can you force the applying of the latest clps711x patches to accelerate
the process?
I mean latest 3 arm-soc patches from Aug, 19.
After that I will need to make a patch for the SPI and TTY subsystems, then
initial DT
support will be introduced.
---
Re: [RFC PATCH] pm: prevent suspend until power supply events are processed
On 4 September 2014 10:21, Viresh Kumar wrote: >>> >> + /* dependent power supplies (e.g. battery) may have changed >>> >> +* state as a result of this event, so poll again and hold >>> >> +* the wakeup_source until all events are processed. >>> >> +*/ But isn't this comment still incorrect? Its not about dependent supplies but the race between the work-handler and its enqueuing? -- 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.16 000/125] 3.16.2-stable review
On 09/03/2014 04:44 PM, Greg Kroah-Hartman wrote: On Wed, Sep 03, 2014 at 03:05:57PM -0700, Greg Kroah-Hartman wrote: -- Note, there are a _lot_ of patches submitted for stable kernels that have yet to be applied, well over 200+ at the moment. Given that this series is already over 100 patches, I figured it was a good as a time as any to push this out. Don't worry, if you have emailed/marked patches to be included, and they aren't here, wait a few more releases for me to catch up, thanks. -- This is the start of the stable review cycle for the 3.16.2 release. There are 125 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Sep 5 22:06:09 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.2-rc1.gz and the diffstat can be found below. -rc2 is out to resolve some reported issues and remove some patches that should not have been there (yet): kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.2-rc2.gz Build results: total: 136 pass: 136 fail: 0 Qemu tests all passed. Detailed build and test results are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/55] 3.10.54-stable review
On 09/03/2014 04:44 PM, Greg Kroah-Hartman wrote: On Wed, Sep 03, 2014 at 03:04:50PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.54 release. There are 55 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Sep 5 22:04:21 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.54-rc1.gz and the diffstat can be found below. -rc2 is now out to resolve some reported errors: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.54-rc2.gz Build results: total: 137 pass: 137 fail: 0 Most of the qemu tests passed except for mips:smp, which crashes with BUG: using smp_processor_id() in preemptible [] code: kjournald/44 This is not a new problem, but an old one discovered due to an added qemu test. I sent you a reference to a patch to fix this problem a couple of weeks ago. Let me know if I should resend it. Detailed test results are available at http://server.roeck-us.net:8010/builders. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v4] x86: only load initrd above 4g on second try
Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
loaded above 4G"), the kernel freezes at the earliest possible moment
when trying to boot via UEFI on Asus laptop.
Revert to old way to load initrd under 4G on first try,
second try will use above 4G buffer when initrd is too big
and does not fit under 4G.
-v2: add print out for second try, and print out files buf address.
-v3: can not snprintf
-v4: drop address print out for files buf
Reported-by: Mantas Mikulėnas
Tested-by: Anders Darander
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/eboot.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
Index: linux-2.6/arch/x86/boot/compressed/eboot.c
===
--- linux-2.6.orig/arch/x86/boot/compressed/eboot.c
+++ linux-2.6/arch/x86/boot/compressed/eboot.c
@@ -1032,7 +1032,6 @@ struct boot_params *make_boot_params(str
int i;
unsigned long ramdisk_addr;
unsigned long ramdisk_size;
- unsigned long initrd_addr_max;
efi_early = c;
sys_table = (efi_system_table_t *)(unsigned long)efi_early->table;
@@ -1095,15 +1094,20 @@ struct boot_params *make_boot_params(str
memset(sdt, 0, sizeof(*sdt));
- if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
- initrd_addr_max = -1UL;
- else
- initrd_addr_max = hdr->initrd_addr_max;
-
status = handle_cmdline_files(sys_table, image,
(char *)(unsigned long)hdr->cmd_line_ptr,
- "initrd=", initrd_addr_max,
+ "initrd=", hdr->initrd_addr_max,
_addr, _size);
+
+ if (status != EFI_SUCCESS &&
+ hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G) {
+ efi_printk(sys_table, "Trying to load files to higher
address\n");
+ status = handle_cmdline_files(sys_table, image,
+ (char *)(unsigned long)hdr->cmd_line_ptr,
+ "initrd=", -1UL,
+ _addr, _size);
+ }
+
if (status != EFI_SUCCESS)
goto fail2;
hdr->ramdisk_image = ramdisk_addr & 0x;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] pm: prevent suspend until power supply events are processed
Thanks for your quick reply :) On 4 September 2014 00:43, Zoran Markovic wrote: > Note that power_supply_changed_work() could race with > power_supply_changed(), as well as with itself. You could theoretically run > power_supply_changed() several times and queue several > power_supply_changed_work() calls. The first run of > power_supply_changed_work() would cancel all previous power_supply_changed() > and the remaining runs would just encounter psy->changed == FALSE and fall > through. That's not completely true. You can't queue the same work multiple times. And the work is queued only if its not pending. The pending bit is just cleared before calling the work-handler. The worst corner case is that the work-handler, i.e. power_supply_changed_work() is called and just before taking the lock, another work is enqueued. Now for the first iteration of power_supply_changed_work() we will surely get changes as TRUE, but for second one it may be FALSE. So, yes my theory was incorrect. >> >> + psy->changed = false; >> >> + spin_unlock_irqrestore(>changed_lock, flags); >> >> + class_for_each_device(power_supply_class, NULL, psy, >> >> + __power_supply_changed_work); >> >> + power_supply_update_leds(psy); >> >> + kobject_uevent(>dev->kobj, KOBJ_CHANGE); >> >> + spin_lock_irqsave(>changed_lock, flags); >> >> + } >> >> + /* dependent power supplies (e.g. battery) may have changed >> >> +* state as a result of this event, so poll again and hold >> >> +* the wakeup_source until all events are processed. >> >> +*/ >> >> + if (!psy->changed) >> >> + pm_relax(psy->dev); >> > >> > I got a bit confused here. Does the above comment say this: >> > >> > The supplies dependent on 'psy' may change states and that *may* >> > change the state of 'psy' again? And so psy->changed is set to true >> > again? > > This is where power_supply_changed_work() could race with another > power_supply_changed(). By the time you hit the check for !psy->changed, > another work may have been already queued. Calling pm_relax() without this > check could defer that work until next resume. Hmm.. Correct here as well. Thanks for your explanation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 1/2] freezer: check OOM kill while being frozen
On Wed, Sep 3, 2014 at 8:42 AM, Tejun Heo wrote:
> Hello, Cong.
>
> On Tue, Sep 02, 2014 at 03:52:40PM -0700, Cong Wang wrote:
>> diff --git a/kernel/freezer.c b/kernel/freezer.c
>> index 33cbcb0..b06a059 100644
>> --- a/kernel/freezer.c
>> +++ b/kernel/freezer.c
>> @@ -56,7 +56,8 @@ static bool should_thaw_current(bool check_kthr_stop)
>> {
>> if (!freezing(current) ||
>> (check_kthr_stop && kthread_should_stop()) ||
>> - test_thread_flag(TIF_MEMDIE))
>> + /* It might not be safe to check TIF_MEMDIE for pm freeze */
>> + (cgroup_freezing(current) && test_thread_flag(TIF_MEMDIE)))
>> return true;
>> else
>> return false;
>>
>> Are you happy now, Tejun? :)
>
> Yes, this should be a lot safer. The function still looks weird to me
> tho.
Cool.
>
> if (cond)
> return true;
> else
> return false;
>
> is equivalent to
>
> return cond;
>
> If you're worried that the conditional is too complex and harms
> readability you can do
>
> /* explain cond0 */
> if (cond0)
> return true;
>
> /* explain cond1 */
> if (cond1)
> return true;
>
> return false;
>
Sure, definitely much more readable. I will update this patch.
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 v2] mfd: syscon: Decouple syscon interface from platform devices
Hi Boris,
On Wednesday, September 03, 2014 Boris BREZILLON wrote,
> To: Arnd Bergmann
> Cc: Pankaj Dubey; kgene@samsung.com; li...@arm.linux.org.uk; Alexander
> Shiyan; naus...@samsung.com; Tomasz Figa; linux-kernel@vger.kernel.org;
> jo...@samsung.com; linux-samsung-...@vger.kernel.org;
thomas...@samsung.com;
> tomasz.f...@gmail.com; vikas.saj...@samsung.com; chow@samsung.com;
> lee.jo...@linaro.org; Michal Simek; linux-arm-ker...@lists.infradead.org;
Mark
> Brown
> Subject: Re: [PATCH v2] mfd: syscon: Decouple syscon interface from
platform
> devices
>
> On Wed, 03 Sep 2014 15:49:04 +0200
> Arnd Bergmann wrote:
>
> > On Wednesday 03 September 2014 15:16:11 Boris BREZILLON wrote:
> > > I checked that part, and it appears most of the code is already
> > > there (see usage of regmap_attach_dev function here [1]).
> > >
> > > The only problem I see is that errors are still printed with
> > > dev_err, which, AFAIK, will trigger a kernel panic if dev is NULL.
> >
> > Actually not:
> >
> > static int __dev_printk(const char *level, const struct device *dev,
> > struct va_format *vaf) {
> > if (!dev)
> > return printk("%s(NULL device *): %pV", level, vaf);
> >
> > return dev_printk_emit(level[1] - '0', dev,
> >"%s %s: %pV",
> >dev_driver_string(dev), dev_name(dev),
> > vaf); }
> >
>
> My bad then (I don't know where I looked at to think NULL dev was not
gracefully
> handled :-)). Thanks for pointing this out.
> Given that, I think it should work fine even with a NULL dev.
> I'll give it a try on at91 ;-).
>
We have tested this patch, on Exynos board and found working well.
In our use case DT based drivers such as USB Phy, SATA Phy, Watchdog are
calling
syscon_regmap_lookup_by APIs to get regmap handle to Exynos PMU and it
worked
well for these drivers.
It would be great if after testing you share result here or give a
Tested-By.
Thanks,
Pankaj Dubey
> Best Regards,
>
> Boris
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.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: Re: [RFC PATCH v3 4/4] ftracetest: Add XFAIL/XPASS and POSIX.3 std. result codes
(2014/09/04 11:29), Namhyung Kim wrote: >> diff --git a/tools/testing/ftrace/test.d/basic3.tc >> b/tools/testing/ftrace/test.d/basic3.tc >> index 0c1a3a2..7bc5a53 100644 >> --- a/tools/testing/ftrace/test.d/basic3.tc >> +++ b/tools/testing/ftrace/test.d/basic3.tc >> @@ -1,8 +1,9 @@ >> #!/bin/sh >> # description: Basic trace clock test >> -[ -f trace_clock ] || exit 1 >> +[ -f trace_clock ] || exit $FAIL # this is basic feature, must be there >> for c in `cat trace_clock | tr -d \[\]`; do >> - echo $c > trace_clock || exit 1 >> - grep '\['$c'\]' trace_clock || exit 1 >> + echo $c > trace_clock || exit $FAIL >> + grep '\['$c'\]' trace_clock || exit $FAIL >> done >> -echo local > trace_clock >> +echo local > trace_clock || exit $FAIL >> +exit $PASS > > IMHO it's a bit sad that we need to write every test in this way - > adding '|| exit $FAIL' for every command. It'd be better if only > exceptional cases require that explicitly and normal cases live in > simple. > > Can we do better - like using trap or something? Hmm, no, trap is only for the signal trapping, and using signal means run "kill" command for special errors. That may not be what you want... :( Perhaps, "set -e" may help you to simplify the script. But since it also returns various exit code, you can not control it. (I hope to have the "atexit" for dash...) Anyway, IMHO, the test cases should express what happened clearly since the test is a kind of verification process. 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: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
Hi Arnd,
On Tuesday, September 02, 2014 Arnd Bergmann wrote,
> To: Pankaj Dubey
> Cc: linux-arm-ker...@lists.infradead.org;
linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; lee.jo...@linaro.org; kgene@samsung.com;
> li...@arm.linux.org.uk; vikas.saj...@samsung.com; jo...@samsung.com;
> naus...@samsung.com; thomas...@samsung.com; chow@samsung.com;
> tomasz.f...@gmail.com; Tomasz Figa; Alexander Shiyan; Michal Simek
> Subject: Re: [PATCH v2] mfd: syscon: Decouple syscon interface from
platform
> devices
>
> On Tuesday 02 September 2014 20:12:15 Pankaj Dubey wrote:
> > Currently a syscon entity can only be registered directly through a
> > platform device that binds to a dedicated syscon driver. However in
> > certain cases it is required to bind a device with it's dedicated
> > driver rather than binding with syscon driver.
> >
> > For example, certain SoCs (e.g. Exynos) contain system controller
> > blocks which perform various functions such as power domain control,
> > CPU power management, low power mode control, but in addition contain
> > certain IP integration glue, such as various signal masks, coprocessor
> > power control, etc. In such case, there is a need to have a dedicated
> > driver for such system controller but also share registers with other
> > drivers. The latter is where the syscon interface is helpful.
> >
> > This patch decouples syscon object from syscon platform driver, and
> > allows to create syscon objects first time when it is required by
> > calling of syscon_regmap_lookup_by APIs and keeps a list of such
> > syscon objects along with syscon provider device_nodes and regmap
handles.
> >
> > Signed-off-by: Pankaj Dubey
> > Signed-off-by: Tomasz Figa
> > ---
> > V1 of this patchset [1] and related discussion can be found here [1].
> >
> > Changes since v1:
> > - Removed of_syscon_unregister function.
> > - Modified of_syscon_register function and it will be used by syscon.c
> >to create syscon objects whenever required.
> > - Removed platform device support from syscon.
> > - Removed syscon_regmap_lookup_by_pdevname API support.
> > - As there are significant changes w.r.t patchset v1, I am taking over
> >author for this patchset from Tomasz Figa.
>
> Note that you got the Signed-off-by: list wrong, you should never have any
people
> listed as Signed-off-by after your own name, and they should be listed
before your
> name only when you are forwarding their patches.
>
Sorry, I was not aware of this. I will take care in future.
> > Note: Current kernel has clps711x user of
> > syscon_regmap_lookup_by_pdevname and will be broken after this patch.
> > As per discussion over here [1], patches for making these drivers DT
> > based are ready and once that is done they can use
> syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible.
> >
> > [1]: https://lkml.org/lkml/2014/8/22/81
>
> Adding Alexander Shiyan to Cc here, so we can make sure this is well
coordinated.
>
> I'm also adding Michal Simek, since here was involved in earlier
discussions about
> doing this.
>
Thanks.
> > drivers/mfd/syscon.c | 143
+---
> > include/linux/mfd/syscon.h |1 +
> > 2 files changed, 44 insertions(+), 100 deletions(-)
>
> I certainly like the diffstat ;-)
>
> > struct syscon {
> > + struct device_node *np;
> > struct regmap *regmap;
> > + struct list_head list;
> > };
>
> Right
>
> > @@ -68,27 +72,6 @@ struct regmap
> > *syscon_regmap_lookup_by_compatible(const char *s) }
> > EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> >
> > -static int syscon_match_pdevname(struct device *dev, void *data) -{
> > - return !strcmp(dev_name(dev), (const char *)data);
> > -}
> > -
> > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) -{
> > - struct device *dev;
> > - struct syscon *syscon;
> > -
> > - dev = driver_find_device(_driver.driver, NULL, (void *)s,
> > -syscon_match_pdevname);
> > - if (!dev)
> > - return ERR_PTR(-EPROBE_DEFER);
> > -
> > - syscon = dev_get_drvdata(dev);
> > -
> > - return syscon->regmap;
> > -}
> > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
>
> I think this can actually be left intact if that helps with clps71xx.
> It could be done in a hacky way using bus_find_device_by_name() to keep it
simple,
> or in a somewhat nicer way by keeping the syscon platform_driver around
for the
> non-DT case.
>
Ok as per our last discussion you mentioned that clps71xx will be soon
migrating to DT.
So if that is not going to happen sooner, I would also prefer better keep
syscon_regmap_lookup_by_pdevname and syscon platform_driver for non-DT case,
so that this issue should not block this patch.
So please let's make final call to keep syscon platform_driver for non-DT
case which eventually
can be dropped once clps71xx driver migrates to DT based. So that I can
prepare next patchset
keeping
Re: [PATCH v9 3/3] regulator: RK808: Remove pdata from the regulator
Chris, On Wed, Sep 3, 2014 at 6:12 PM, Chris Zhong wrote: > Signed-off-by: Chris Zhong > > Tested-by: Heiko Stuebner > --- > > Changes in v9: > Adviced by Doug > - add reg_np > > Changes in v8: > Adviced by Doug > - remove rk808_regulator_dts() function > - remove the check about "client->dev.of_node" > > Changes in v7: > - remove pdata struct from header file, add rk808_regulator struct > > Changes in v6: > - remove the redundant code > > Changes in v5: > - re-edit base on Mark's branch > > Changes in v4: > - use >dev replace rk808->dev > > Changes in v3: None > Changes in v2: > Adviced by Mark Browm: > - change of_find_node_by_name to find_child_by_name > - use RK808_NUM_REGULATORS as the name of the constant > - create a pdata when missing platform data > - use the rk808_reg name to supply_regulator name > - replace regulator_register with devm_regulator_register > - some other problem with coding style > > drivers/regulator/rk808-regulator.c | 91 > +++ > 1 file changed, 18 insertions(+), 73 deletions(-) Reviewed-by: Doug Anderson Tested-by: Doug Anderson -- 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 v9 1/3] RTC: RK808: add RTC driver for RK808
Chris,
On Wed, Sep 3, 2014 at 6:12 PM, Chris Zhong wrote:
> Adding RTC driver for supporting RTC device present inside RK808 PMIC.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Zhang Qing
>
> Tested-by: Heiko Stuebner
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
> + rk808_rtc->irq = platform_get_irq(pdev, 0);
> + if (rk808_rtc->irq < 0) {
> + dev_err(>dev, "Wake up is not possible as irq = %d\n",
> + rk808_rtc->irq);
Technically you shouldn't print the error if it's -EPROBE_DEFER.
...but I think that's really unlikely here (I can't imagine any real
cases where the interrupt parent for RK808 would actually be deferred)
so I won't push 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/
Re: Re: [PATCH 06/12] clk: mmp: add mmp private gate clock
On Thu, Sep 4, 2014 at 12:02 PM, Chao Xie wrote:
>
>
> At 2014-09-04 01:55:37, "Mike Turquette" wrote:
>>Quoting Chao Xie (2014-08-25 21:38:18)
>>> From: Chao Xie
>>>
>>> Some SOCes have this kind of the gate clock
>>> 1. There are some bits to control the gate not only one bit.
>>> 2. Some clocks has operations of "out of reset" and "enable".
>>>To enable clock, we need do "out of reset" and "enable".
>>>To disable clock, we may not need "set to reset". It depends
>>>on the SOCes' design.
>>
>>Are there any other IP blocks affected by the "out of reset" and "set to
>>reset" states? I wonder if you might benefit from the reset controller
>>framework? For example see,
>>
>>drivers/clk/qcom/gcc-apq8084.c
>>
>>
>
>>
> Thanks to point it out.
> To use the reset framework, there are some problem.
> 1. the reset bit is combined with the clocks disable/enable bits in same
> register. Seperating setting them means spinlock
> protection and 2 operations for read-update the bits.
>
>
> except that, i think reset framework can bring some benefits.
Check out the sunxi gates clk
(drivers/clk/sunxi/clk-sunxi.c:sunxi_gates_clk_setup())
In particular, the usb gate clk, which has gates and reset controls
in the same register. The driver registers separate clk gates and reset
controls for each bit, but uses the same spinlock for all bits.
ChenYu
> Even without the reset bit, we still need the gate clocks.
> The enable/disable is not a bit operation, and it is bits operation for some
> devices.
> In fact i want to use it to replace the old clk-apbc and clk-apmu clocks.
>
>>> +static int mmp_clk_gate_enable(struct clk_hw *hw)
>>> +{
>>> + struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
>>> + struct clk *clk = hw->clk;
>>> + unsigned long flags = 0;
>>> + unsigned long rate;
>>> + u32 tmp;
>>> +
>>> + if (gate->lock)
>>> + spin_lock_irqsave(gate->lock, flags);
>>> +
>>> + tmp = readl(gate->reg);
>>> + tmp &= ~gate->mask;
>>> + tmp |= gate->val_enable;
>>> + writel(tmp, gate->reg);
>>> +
>>> + if (gate->lock)
>>> + spin_unlock_irqrestore(gate->lock, flags);
>>> +
>>> + if (gate->flags & MMP_CLK_GATE_NEED_DELAY) {
>>> + rate = __clk_get_rate(clk);
>>> + /* Need delay 2 cycles. */
>>> + udelay(200/rate);
>>
>>How long are these delays? Long enough to warrant using clk_prepare
>>instead of clk_enable? Are these clocks enabled from interrupt context?
>
>>
> For power optimization, some clocks need to be enabled/disable in interrupt
> context.
> The worst delay is rate=32KHZ, so the delay is 62.5us.
--
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] partitions: efi.c: fix formatting and function readability
From: jpoirier
Fixed coding style issues, refactored the protective MBR check
function for readability, and removed an explicit return from a
function returning void.
Signed-off-by: Joseph Poirier
Signed-off-by: jpoirier
---
block/partitions/efi.c | 222 -
1 file changed, 110 insertions(+), 112 deletions(-)
diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index 56d08fd..21d0fcb 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -37,7 +37,7 @@
* - Ported to 2.5.7-pre1 and 2.5.7-dj2
* - Applied patch to avoid fault in alternate header handling
* - cleaned up find_valid_gpt
- * - On-disk structure and copy in memory is *always* LE now -
+ * - On-disk structure and copy in memory is *always* LE now -
* swab fields as needed
* - remove print_gpt_header()
* - only use first max_p partition entries, to keep the kernel minor number
@@ -54,7 +54,7 @@
* - moved le_efi_guid_to_cpus() back into this file. GPT is the only
* thing that keeps EFI GUIDs on disk.
* - Changed gpt structure names and members to be simpler and more Linux-like.
- *
+ *
* Wed Oct 17 2001 Matt Domsch
* - Removed CONFIG_DEVFS_VOLUMES_UUID code entirely per Martin Wilck
*
@@ -79,7 +79,7 @@
*
* Wed Jun 6 2001 Martin Wilck
* - added devfs volume UUID support (/dev/volumes/uuids) for
- * mounting file systems by the partition GUID.
+ * mounting file systems by the partition GUID.
*
* Tue Dec 5 2000 Matt Domsch
* - Moved crc32() to linux/lib, added efi_crc32().
@@ -109,8 +109,7 @@
* the partition tables happens after init too.
*/
static int force_gpt;
-static int __init
-force_gpt_fn(char *str)
+static int __init force_gpt_fn(char *str)
{
force_gpt = 1;
return 1;
@@ -124,14 +123,13 @@ __setup("gpt", force_gpt_fn);
* @len: length of buf
*
* Description: Returns EFI-style CRC32 value for @buf
- *
+ *
* This function uses the little endian Ethernet polynomial
* but seeds the function with ~0, and xor's with ~0 at the end.
* Note, the EFI Specification, v1.02, has a reference to
* Dr. Dobbs Journal, May 1994 (actually it's in May 1992).
*/
-static inline u32
-efi_crc32(const void *buf, unsigned long len)
+static inline u32 efi_crc32(const void *buf, unsigned long len)
{
return (crc32(~0L, buf, len) ^ ~0L);
}
@@ -139,7 +137,7 @@ efi_crc32(const void *buf, unsigned long len)
/**
* last_lba(): return number of last logical block of device
* @bdev: block device
- *
+ *
* Description: Returns last LBA value on success, 0 on error.
* This is stored (by sd and ide-geometry) in
* the part[0] entry for this disk, and is the number of
@@ -202,37 +200,35 @@ static int is_pmbr_valid(legacy_mbr *mbr, sector_t
total_sectors)
* now check if there are other partition types for
* hybrid MBR.
*/
- goto check_hybrid;
+ break;
}
}
- if (ret != GPT_MBR_PROTECTIVE)
- goto done;
-check_hybrid:
- for (i = 0; i < 4; i++)
- if ((mbr->partition_record[i].os_type !=
- EFI_PMBR_OSTYPE_EFI_GPT) &&
- (mbr->partition_record[i].os_type != 0x00))
- ret = GPT_MBR_HYBRID;
-
- /*
-* Protective MBRs take up the lesser of the whole disk
-* or 2 TiB (32bit LBA), ignoring the rest of the disk.
-* Some partitioning programs, nonetheless, choose to set
-* the size to the maximum 32-bit limitation, disregarding
-* the disk size.
-*
-* Hybrid MBRs do not necessarily comply with this.
-*
-* Consider a bad value here to be a warning to support dd'ing
-* an image from a smaller disk to a larger disk.
-*/
if (ret == GPT_MBR_PROTECTIVE) {
+ for (i = 0; i < 4; i++)
+ if ((mbr->partition_record[i].os_type !=
+ EFI_PMBR_OSTYPE_EFI_GPT) &&
+ (mbr->partition_record[i].os_type != 0x00)) {
+ ret = GPT_MBR_HYBRID;
+ goto done;
+ }
+ /*
+* Protective MBRs take up the lesser of the whole disk
+* or 2 TiB (32bit LBA), ignoring the rest of the disk.
+* Some partitioning programs, nonetheless, choose to set
+* the size to the maximum 32-bit limitation, disregarding
+* the disk size.
+*
+* Hybrid MBRs do not necessarily comply with this.
+*
+* Consider a bad value here to be a warning to support dd'ing
+* an image from a smaller disk to a larger disk.
+*/
sz =
Re:Re: [PATCH 06/12] clk: mmp: add mmp private gate clock
At 2014-09-04 01:55:37, "Mike Turquette" wrote:
>Quoting Chao Xie (2014-08-25 21:38:18)
>> From: Chao Xie
>>
>> Some SOCes have this kind of the gate clock
>> 1. There are some bits to control the gate not only one bit.
>> 2. Some clocks has operations of "out of reset" and "enable".
>>To enable clock, we need do "out of reset" and "enable".
>>To disable clock, we may not need "set to reset". It depends
>>on the SOCes' design.
>
>Are there any other IP blocks affected by the "out of reset" and "set to
>reset" states? I wonder if you might benefit from the reset controller
>framework? For example see,
>
>drivers/clk/qcom/gcc-apq8084.c
>
>
>
Thanks to point it out.
To use the reset framework, there are some problem.
1. the reset bit is combined with the clocks disable/enable bits in same
register. Seperating setting them means spinlock
protection and 2 operations for read-update the bits.
except that, i think reset framework can bring some benefits.
Even without the reset bit, we still need the gate clocks.
The enable/disable is not a bit operation, and it is bits operation for some
devices.
In fact i want to use it to replace the old clk-apbc and clk-apmu clocks.
>> +static int mmp_clk_gate_enable(struct clk_hw *hw)
>> +{
>> + struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
>> + struct clk *clk = hw->clk;
>> + unsigned long flags = 0;
>> + unsigned long rate;
>> + u32 tmp;
>> +
>> + if (gate->lock)
>> + spin_lock_irqsave(gate->lock, flags);
>> +
>> + tmp = readl(gate->reg);
>> + tmp &= ~gate->mask;
>> + tmp |= gate->val_enable;
>> + writel(tmp, gate->reg);
>> +
>> + if (gate->lock)
>> + spin_unlock_irqrestore(gate->lock, flags);
>> +
>> + if (gate->flags & MMP_CLK_GATE_NEED_DELAY) {
>> + rate = __clk_get_rate(clk);
>> + /* Need delay 2 cycles. */
>> + udelay(200/rate);
>
>How long are these delays? Long enough to warrant using clk_prepare
>instead of clk_enable? Are these clocks enabled from interrupt context?
>
For power optimization, some clocks need to be enabled/disable in interrupt
context.
The worst delay is rate=32KHZ, so the delay is 62.5us.
>Regards,
>Mike
N嫥叉靣笡y氊b瞂千v豝�)藓{.n�+壏{睉赙zXФ洝塄}财爖�:+v墾�珣赙zZ+€�+zf＂穐殘啳嗃iz� 畐ア�?櫒璀�&�)撷f旟^j谦y呩@A玜囤
0鹅h�鍜i
Re: Re: [RFC PATCH v3 0/4] ftrace: Add a ftrace test collection
(2014/09/04 11:42), Namhyung Kim wrote: > On Tue, 02 Sep 2014 11:06:32 +, Masami Hiramatsu wrote: >> Hi, >> >> Here is the collection of testcases for ftrace version 3. >> This is just some updates and fixes according to the >> discussion at previous version. >> https://lkml.org/lkml/2014/8/26/304 >> >> The major updates are: >> - Fix some expressions to work on dash (Thanks Luis!) >> - Support UNRESOLVED/UNTESTED/UNSUPPORTED results for testcase. >>Those are POSIX 1003.3 standard. >>(see http://www.gnu.org/software/dejagnu/manual/x47.html for >> more details) >> - Fix to show error logs. >> >> ftracetest is a small dash script for testing ftrace features. >> It will be required to add a unit test for each new feature >> after this is merged, because of preventing feature regressions. >> >> This version still be out of the selftest. However, at the kernel >> summit, I talked with Shuah about that. And since the kselftest >> will be the standard kernel unit test framework, I agreed to >> move this under the selftest. But I also would like to ask Steven >> and Namhyung to agree with it before moving. >> >> Actually, since we've already has similar shell-script base >> testcase under kselftest, we can easily move this under >> selftests. > > By [k]selftest, did you mean tools/testing/selftests/ ? Yes, and I will just move tools/testing/ftrace to tools/testing/selftests/ftrace and add a Makefile. > Anyway I have no objection to the move. Thank you! > > Thanks for your work! > Namhyung > -- 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] ARM: cns3xxx: fix allmodconfig panic in pci driver
于 2014/9/3 21:27, Arnd Bergmann 写道: > On Wednesday 03 September 2014 21:18:12 Xia Kaixu wrote: >> From: Xia Kaixu >> >> The kernel panic occurs when running an allmodconfig kernel on >> OMAP4460. The inicall "cns3xxx_pcie_init" does not check which >> hardware it's running on and just tries to access to its specific >> registers. Now call it from .init_late callback from the two >> machine descriptors. >> >> Signed-off-by: Xia Kaixu >> Signed-off-by: Arnd Bergmann >> Cc: Anton Vorontsov >> Cc: Felix Fietkau >> Cc: Imre Kaloz >> Cc: linaro-ker...@lists.linaro.org >> Cc: linux-arm-ker...@lists.infradead.org > > Hi Kaixu, > > it seems this time all the Cc's worked. One thing I just noticed is that > you confused the 'Signed-off-by' lines. I did look at the patch earlier > before you sent it out but unfortunately missed that. > > You can read again in Documentation/SubmittingPatches about how > they work, but the short version is that you must never put someone > else's name in Signed-off-by under a patch you write yourself. > When we apply the patch, I (or whoever else does) will put that > line below yours to document who handled the patch. Sure, you are right. Thanks for the reminder! > > Otherwise, the patch looks good to me, thanks a lot for doing it. > > Arnd > > ___ > linaro-kernel mailing list > linaro-ker...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-kernel > -- 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 v7 1/2] i2c: imx: add DMA support for freescale i2c driver
Hi Wolfram,
I fixed the mentioned issues before in v7. Could you please help to review this
patch?
Thanks & Regards
Yuan Yao
-Original Message-
From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org] On
Behalf Of Yuan Yao
Sent: Wednesday, August 13, 2014 5:47 PM
To: w...@the-dreams.de; ma...@denx.de
Cc: mark.rutl...@arm.com; linux-kernel@vger.kernel.org;
linux-...@vger.kernel.org; Duan Fugang-B38611; shawn@linaro.org;
linux-arm-ker...@lists.infradead.org; l...@karo-electronics.de
Subject: [PATCH v7 1/2] i2c: imx: add DMA support for freescale i2c driver
Add dma support for i2c. This function depend on DMA driver.
You can turn on it by write both the dmas and dma-name properties in dts node.
DMA is optional, even DMA request unsuccessfully, i2c can also work well.
Signed-off-by: Yuan Yao
---
drivers/i2c/busses/i2c-imx.c | 351 +--
1 file changed, 341 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index
aa8bc14..a09bf8c 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -37,22 +37,27 @@
/** Includes
***
***/
-#include
-#include
-#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
#include
#include
-#include
#include
+#include
#include
-#include
-#include
-#include
-#include
+#include
+#include
#include
#include
+#include
#include
+#include
+#include
+#include
/** Defines
***/
@@ -63,6 +68,12 @@
/* Default value */
#define IMX_I2C_BIT_RATE 10 /* 100kHz */
+/* Enable DMA if transfer byte size is bigger than this threshold.
+ * As the hardware request, it must bigger than 4.
+ */
+#define IMX_I2C_DMA_THRESHOLD 16
+#define IMX_I2C_DMA_TIMEOUT1000
+
/* IMX I2C registers:
* the I2C register offset is different between SoCs,
* to provid support for all these chips, split the @@ -88,6 +99,7 @@
#define I2SR_IBB 0x20
#define I2SR_IAAS 0x40
#define I2SR_ICF 0x80
+#define I2CR_DMAEN 0x02
#define I2CR_RSTA 0x04
#define I2CR_TXAK 0x08
#define I2CR_MTX 0x10
@@ -174,6 +186,17 @@ struct imx_i2c_hwdata {
unsignedi2cr_ien_opcode;
};
+struct imx_i2c_dma {
+ struct dma_chan *chan_tx;
+ struct dma_chan *chan_rx;
+ struct dma_chan *chan_using;
+ struct completion cmd_complete;
+ dma_addr_t dma_buf;
+ unsigned intdma_len;
+ unsigned intdma_transfer_dir;
+ unsigned intdma_data_dir;
+};
+
struct imx_i2c_struct {
struct i2c_adapter adapter;
struct clk *clk;
@@ -186,6 +209,8 @@ struct imx_i2c_struct {
unsigned intcur_clk;
unsigned intbitrate;
const struct imx_i2c_hwdata *hwdata;
+
+ struct imx_i2c_dma *dma;
};
static const struct imx_i2c_hwdata imx1_i2c_hwdata = { @@ -256,6 +281,132 @@
static inline unsigned char imx_i2c_read_reg(struct imx_i2c_struct *i2c_imx,
return readb(i2c_imx->base + (reg << i2c_imx->hwdata->regshift)); }
+/* Functions for DMA support */
+static int i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
+ dma_addr_t phy_addr)
+{
+ struct imx_i2c_dma *dma;
+ struct dma_slave_config dma_sconfig;
+ struct device *dev = _imx->adapter.dev;
+ int ret;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma->chan_tx = dma_request_slave_channel(dev, "tx");
+ if (!dma->chan_tx) {
+ dev_dbg(dev, "can't request DMA tx channel\n");
+ ret = -ENODEV;
+ goto fail_al;
+ }
+
+ dma_sconfig.dst_addr = phy_addr +
+ (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
+ dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ dma_sconfig.dst_maxburst = 1;
+ dma_sconfig.direction = DMA_MEM_TO_DEV;
+ ret = dmaengine_slave_config(dma->chan_tx, _sconfig);
+ if (ret < 0) {
+ dev_dbg(dev, "can't configure tx channel\n");
+ goto fail_tx;
+ }
+
+ dma->chan_rx = dma_request_slave_channel(dev, "rx");
+ if (!dma->chan_rx) {
+ dev_dbg(dev, "can't request DMA rx channel\n");
+ ret = -ENODEV;
+ goto fail_tx;
+ }
+
+ dma_sconfig.src_addr = phy_addr +
+ (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
+
Re: [PATCH] net: treewide: Fix typo found in DocBook/networking.xml
From: Masanari Iida Date: Wed, 3 Sep 2014 12:59:15 +0900 > * When used in combination with the softirq_exit tracepoint > - * we can determine the softirq handler runtine. > + * we can determine the softirq handler runtime. > */ The author of this comment meant to say "routine" not "runtime" -- 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] cgroup: Delay the clearing of cgrp->kn->priv
于 2014/9/2 23:33, Tejun Heo 写道:
> Hello, Li.
>
> On Tue, Sep 02, 2014 at 06:56:58PM +0800, Li Zefan wrote:
>> for ((; ;))
>> {
>> echo $$ > /cgroup/sub/cgroup.procs
>> ech $$ > /cgce 6f2e0c38c2108a74 ]---
>
> copy & paste error?
> ...
oops
>> Reported-by: Toralf Förster
>> Signed-off-by: Li Zefan
>> ---
>>
>> Toralf, Thanks for reporting the bug. I'm not able to repy to your email,
>> because I was kicked out of the cgroup mailing list so didn't receive
>> emails from mailing list for a week.
>>
>> ---
>> kernel/cgroup.c | 19 +--
>> 1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>> index 1c56924..e03fc62 100644
>> --- a/kernel/cgroup.c
>> +++ b/kernel/cgroup.c
>> @@ -4185,6 +4185,15 @@ static void css_release_work_fn(struct work_struct
>> *work)
>>
>> mutex_unlock(_mutex);
>>
>> +/*
>> + * There are two control paths which try to determine cgroup from
>> + * dentry without going through kernfs - cgroupstats_build() and
>> + * css_tryget_online_from_dir(). Those are supported by RCU
>> + * protecting clearing of cgrp->kn->priv backpointer.
>> + */
>> +if (!ss && cgroup_parent(cgrp))
>> +RCU_INIT_POINTER(*(void __rcu __force **)>kn->priv, NULL);
>
> Can we move the above into the preceding else block? I don't think
> holding cgroup_mutex or not makes any difference here.
> Also, why do
> we need the cgroup_parent() check? Do we deref root's kn->priv in the
> destruction path? If so, can you please note that in the comment?
>
I think the check is not necessary. I was trying to make smaller difference
than the original code, and RCU_INIT_POINTER() is in cgroup_rmdir() which
won't be called on root cgroup.
--
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 v9 1/3] RTC: RK808: add RTC driver for RK808
Adding RTC driver for supporting RTC device present inside RK808 PMIC.
Signed-off-by: Chris Zhong
Signed-off-by: Zhang Qing
Tested-by: Heiko Stuebner
---
Changes in v9:
Adviced by Dmitry
- if(rk808_rtc->irq < 0), return rk808_rtc->irq
Changes in v8:
Adviced by Doug
- coding style
- fix regmap_update_bits()
- if(rk808_rtc->irq < 0) return err num
Changes in v7:
Adviced by doug
- read rtc time from shadowed registers
Adviced by Dmitry
- use CONFIG_PM_SLEEP replace CONFIG_PM
- use SIMPLE_DEV_PM_OPS replace dev_pm_ops
- fix dev_warn
- coding style
Adviced by Heiko
- remove rtc_ctl
Changes in v6:
Adviced by doug
- move RTC_READSEL setting into probe
Changes in v5:
- fixed a bug about set_time failed
Changes in v4:
- use >dev replace rk808->dev
Changes in v3: None
Changes in v2:
Adviced by javier.martinez
- Add a separate clock driver, rather than in RTC driver
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile|1 +
drivers/rtc/rtc-rk808.c | 426 +++
3 files changed, 437 insertions(+)
create mode 100644 drivers/rtc/rtc-rk808.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a168e96..aeab9d9 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_RK808
+ tristate "Rockchip RK808 RTC"
+ depends on MFD_RK808
+ help
+ If you say yes here you will get support for the
+ RTC of RK808 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rk808-rtc.
+
config RTC_DRV_RS5C372
tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56f061c..91fe4647 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_RTC_DRV_PUV3) += rtc-puv3.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
+obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
new file mode 100644
index 000..b8cd399
--- /dev/null
+++ b/drivers/rtc/rtc-rk808.c
@@ -0,0 +1,426 @@
+/*
+ * RTC driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong
+ * Author: Zhang Qing
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* RTC_CTRL_REG bitfields */
+#define BIT_RTC_CTRL_REG_STOP_RTC_MBIT(0)
+
+/* RK808 has a shadowed register for saving a "frozen" RTC time.
+ * When user setting "GET_TIME" to 1, the time will save in this shadowed
+ * register. If set "READSEL" to 1, user read rtc time register, actually
+ * get the time of that moment. If we need the real time, clr this bit.
+ */
+#define BIT_RTC_CTRL_REG_RTC_GET_TIME BIT(6)
+#define BIT_RTC_CTRL_REG_RTC_READSEL_M BIT(7)
+#define BIT_RTC_INTERRUPTS_REG_IT_ALARM_M BIT(3)
+#define RTC_STATUS_MASK0xFE
+
+#define SECONDS_REG_MSK0x7F
+#define MINUTES_REG_MAK0x7F
+#define HOURS_REG_MSK 0x3F
+#define DAYS_REG_MSK 0x3F
+#define MONTHS_REG_MSK 0x1F
+#define YEARS_REG_MSK 0xFF
+#define WEEKS_REG_MSK 0x7
+
+/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
+
+#define NUM_TIME_REGS (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
+#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
+
+struct rk808_rtc {
+ struct rk808 *rk808;
+ struct rtc_device *rtc;
+ int irq;
+};
+
+/* Read current time and date in RTC */
+static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
+{
+ struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
+ struct rk808 *rk808 = rk808_rtc->rk808;
+ u8 rtc_data[NUM_TIME_REGS];
+ int ret;
+
+ /* Force an update of the shadowed registers right now */
+ ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+BIT_RTC_CTRL_REG_RTC_GET_TIME,
+0);
+ if (ret) {
+ dev_err(dev, "Failed to update bits
[GIT PULL] platform-drivers-x86 MAINTAINERS and fixes for v3.17
Hi Linus, This is my first pull request since taking on maintenance for the platform-drivers-x86 tree from Matthew Garrett. These have passed my build testing and been run through Fengguang's LKP tests. Due to timing this round, these have not spent any time in linux-next. I have asked Stephen to include my for-next branch in linux-next going forward, once he's back from vacation. Thanks, Darren Hart Intel Open Source Technology Center The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef: Linux 3.17-rc2 (2014-08-25 15:36:20 -0700) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v3.17-1 for you to fetch changes up to aeaac098bd58349d7415acd998089309fd798190: toshiba_acpi: fix and cleanup toshiba_kbd_bl_mode_store() (2014-09-03 10:45:12 -0700) platform-drivers-x86 MAINTAINERS and fixes for v3.17 toshiba_acpi: Re-enable hotkeys and cleanups ideapad-laptop: Revert touchpad disable, and cleanup static/const usage MAINTAINERS: Update platform-drivers-x86 maintainer and tree Benjamin Tissoires (1): platform/x86: toshiba: re-enable acpi hotkeys after suspend to disk Dan Carpenter (1): toshiba_acpi: fix and cleanup toshiba_kbd_bl_mode_store() Darren Hart (1): MAINTAINERS: Update platform-drivers-x86 maintainer and tree Hans de Goede (1): Revert "ideapad-laptop: Disable touchpad interface on Yoga models" Mathias Krause (1): ideapad-laptop: Constify DMI table for real! MAINTAINERS | 4 ++-- drivers/platform/x86/ideapad-laptop.c | 31 ++- drivers/platform/x86/toshiba_acpi.c | 27 --- 3 files changed, 24 insertions(+), 38 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/
[PATCH v5] x86,cpu-hotplug: assign same CPU number to readded CPU
llc_shared_map is not cleared even if CPU is offline or hot removed.
So when hot-plugging CPU and assigning new CPU number to hot-added CPU,
the mask has wrong value. The mask is used by CSF schduler to create
sched_domain. So it breaks CFS scheduler.
Here is a example on my system.
My system has 4 sockets and each socket has 15 cores and HT is enabled.
In this case, each core of sockes is numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-44, 90-104
Socket#3 | 45-59, 105-119
Then llc_shared_mask of CPU#30 has 0x3fff8001fffc000.
It means that last level cache of Socket#2 is shared with
CPU#30-44 and 90-104.
When hot-removing socket#2 and #3, each core of sockets is numbered
as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains
having 0x3fff8001fffc000.
After that, when hot-adding socket#2 and #3, each core of sockets is
numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-59
Socket#3 | 90-119
Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffc000.
It means that last level cache of Socket#2 is shared with CPU#30-59
and 90-104. So the mask has wrong value.
At first, I cleared hot-removed CPU number's bit from llc_shared_map
when hot removing CPU. But Borislav suggested that the problem will
disappear if readded CPU is assigned same CPU number. And llc_shared_map
must not be changed.
So the patch assigns same CPU number to readded CPU by linking CPU
number to APIC ID. And by the patch, the problem disappers.
Signed-off-by: Yasuaki Ishimatsu
Suggested-by: Borislav Petkov
Reviewed-by: Toshi Kani
---
v2: change cpuid to cpunum
v3: fix Borislav's email address of Suggested-by
fix typo (ACPI ID to APIC ID)
v4: change cpu_used_xxx to cpu_number_xxx
v5: rebase to 3.17-rc3
---
arch/x86/kernel/apic/apic.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 6776027..c476827 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -220,6 +220,23 @@ static void apic_pm_activate(void);
static unsigned long apic_phys;
/*
+ * Bind APIC ID to Logical CPU number
+ * Logical CPU number to APIC ID does not change by this array
+ * even if CPU is hotplugged. So don't clear the array even if
+ * CPU is hot-removed
+ */
+static int apicid_to_cpunum[MAX_LOCAL_APIC] = {
+ [0 ... MAX_LOCAL_APIC-1] = -1,
+};
+
+/*
+ * Represent Logical CPU number bound to APIC ID
+ * Don't clear a bit even if CPU is hot-removed
+ */
+static DECLARE_BITMAP(cpu_number_bits, CONFIG_NR_CPUS);
+static struct cpumask *const cpu_number_mask = to_cpumask(cpu_number_bits);
+
+/*
* Get the LAPIC version
*/
static inline int lapic_get_version(void)
@@ -2109,6 +2126,17 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
+static int get_cpunum(int apicid)
+{
+ int cpu;
+
+ cpu = apicid_to_cpunum[apicid];
+ if (cpu < 0)
+ cpu = cpumask_next_zero(-1, cpu_number_mask);
+
+ return cpu;
+}
+
int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
@@ -2186,7 +2214,9 @@ int generic_processor_info(int apicid, int version)
*/
cpu = 0;
} else
- cpu = cpumask_next_zero(-1, cpu_present_mask);
+ cpu = get_cpunum(apicid);
+
+ apicid_to_cpunum[apicid] = cpu;
/*
* Validate version
@@ -2215,6 +2245,7 @@ int generic_processor_info(int apicid, int version)
early_per_cpu(x86_cpu_to_logical_apicid, cpu) =
apic->x86_32_early_logical_apicid(cpu);
#endif
+ cpumask_set_cpu(cpu, cpu_number_mask);
set_cpu_possible(cpu, true);
set_cpu_present(cpu, true);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools: Fix build-id matching on vmlinux
Ping!
On Tue, 26 Aug 2014 15:38:39 +0900, Namhyung Kim wrote:
> There's a problem on finding correct kernel symbols when perf report
> runs on a different kernel. Although a part of the problem was solved
> by the prior commit 0a7e6d1b6844 ("perf tools: Check recorded kernel
> version when finding vmlinux"), there's a remaining problem still.
>
> When perf records samples, it synthesizes the kernel map using
> machine__mmap_name() and ref_reloc_sym like "[kernel.kallsyms]_text".
> You can easily see it using 'perf report -D' command.
>
> After finishing record, it goes through the recorded events to find
> maps/dsos actually used. And then record build-id info of them.
>
> During this process, it needs to load symbols in a dso and it'd call
> dso__load_vmlinux() since the default value of the symbol_conf.try_
> vmlinux_path is true. However it changes dso->long_name to a real
> path of the vmlinux file (e.g. /lib/modules/3.16.0-rc2+/build/vmlinux)
> if one is running on a custom kernel.
>
> It resulted in that perf report reads the build-id of the vmlinux, but
> cannot use it since it only knows about the [kernel.kallsyms] map. It
> then falls back to possible vmlinux paths by using the recorded kernel
> version (in case of a recent version) or a running kernel silently
> (which might break the result). I think it's worth going to the
> stable tree.
>
> I can think of a couple of ways to fix it. In this patch, I changed
> to use the name of "[kernel.kallsyms]" for the kernel build-id event
> instead of not trying vmlinux paths. This way we can provide maximum
> info (like annotation) with minimum change IMHO.
>
> Before:
>
> $ perf record -a usleep 1
>
> $ perf buildid-list
> 00d5ff078efe1d30b8492854f259215fd877ce30
> /lib/modules/3.16.0-rc2+/build/vmlinux
> 78186287bba77069a056a5ccbeb14b7fd2ca3a4b /usr/lib64/libc-2.17.so
> 4eadca6cb82e0a85edb87c15b5e3980742514501 /usr/lib64/ld-2.17.so
> 1e272ca30081e81ef41935a630eb2f4c636798b4 /usr/lib64/dri/swrast_dri.so
>
> $ perf buildid-list -H
> [kernel.kallsyms]
> 78186287bba77069a056a5ccbeb14b7fd2ca3a4b /usr/lib64/libc-2.17.so
> 4eadca6cb82e0a85edb87c15b5e3980742514501 /usr/lib64/ld-2.17.so
> 1e272ca30081e81ef41935a630eb2f4c636798b4 /usr/lib64/dri/swrast_dri.so
> /tmp/perf-2523.map
>
> After:
>
> $ perf record -a usleep 1
>
> $ perf buildid-list
> 00d5ff078efe1d30b8492854f259215fd877ce30 [kernel.kallsyms]
> 78186287bba77069a056a5ccbeb14b7fd2ca3a4b /usr/lib64/libc-2.17.so
> 4eadca6cb82e0a85edb87c15b5e3980742514501 /usr/lib64/ld-2.17.so
> 1e272ca30081e81ef41935a630eb2f4c636798b4 /usr/lib64/dri/swrast_dri.so
>
> $ perf buildid-list -H
> 00d5ff078efe1d30b8492854f259215fd877ce30 [kernel.kallsyms]
> 78186287bba77069a056a5ccbeb14b7fd2ca3a4b /usr/lib64/libc-2.17.so
> 4eadca6cb82e0a85edb87c15b5e3980742514501 /usr/lib64/ld-2.17.so
> 1e272ca30081e81ef41935a630eb2f4c636798b4 /usr/lib64/dri/swrast_dri.so
> /tmp/perf-2523.map
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/header.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index 158c787ce0c4..5c4093dee467 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -263,6 +263,9 @@ static int __dsos__write_buildid_table(struct list_head
> *head,
> machine__mmap_name(machine, nm, sizeof(nm));
> name = nm;
> name_len = strlen(nm) + 1;
> + } else if (dso__is_vmlinux(pos)) {
> + name = pos->name;
> + name_len = strlen(pos->name) + 1;
> } else {
> name = pos->long_name;
> name_len = pos->long_name_len + 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/4] ftrace: Add a ftrace test collection
On Tue, 02 Sep 2014 11:06:32 +, Masami Hiramatsu wrote: > Hi, > > Here is the collection of testcases for ftrace version 3. > This is just some updates and fixes according to the > discussion at previous version. > https://lkml.org/lkml/2014/8/26/304 > > The major updates are: > - Fix some expressions to work on dash (Thanks Luis!) > - Support UNRESOLVED/UNTESTED/UNSUPPORTED results for testcase. >Those are POSIX 1003.3 standard. >(see http://www.gnu.org/software/dejagnu/manual/x47.html for > more details) > - Fix to show error logs. > > ftracetest is a small dash script for testing ftrace features. > It will be required to add a unit test for each new feature > after this is merged, because of preventing feature regressions. > > This version still be out of the selftest. However, at the kernel > summit, I talked with Shuah about that. And since the kselftest > will be the standard kernel unit test framework, I agreed to > move this under the selftest. But I also would like to ask Steven > and Namhyung to agree with it before moving. > > Actually, since we've already has similar shell-script base > testcase under kselftest, we can easily move this under > selftests. By [k]selftest, did you mean tools/testing/selftests/ ? Anyway I have no objection to the move. Thanks for your work! Namhyung -- 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] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set
On Thu, 04 Sep 2014 10:08:09 +0800 Junxiao Bi wrote:
> On 09/04/2014 07:10 AM, Andrew Morton wrote:
> > On Wed, 3 Sep 2014 13:54:54 +0800 Junxiao Bi wrote:
> >
> >> commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
> >> during memory allocation")
> >> introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory
> >> allocation, __GFP_IO is cleared
> >> when this flag is set, but __GFP_FS implies __GFP_IO, it should also be
> >> cleared. Or it may still
> >> run into I/O, like in superblock shrinker.
> >
> > Is there an actual bug which inspired this fix? If so, please describe
> > it.
> >
> Yes, an ocfs2 deadlock bug is related to this, there is a workqueue in
> ocfs2 who is for building tcp connections and processing ocfs2 message.
> Like when an new node is up in ocfs2 cluster, the workqueue will try to
> build the connections to it, since there are some common code in
> networking like sock_alloc() using GFP_KERNEL to allocate memory, direct
> reclaim will be triggered and call into superblock shrinker if available
> memory is not enough even set PF_MEMALLOC_NOIO for the workqueue. To
> shrink the inode cache, ocfs2 needs release cluster lock and this
> depends on workqueue to do it, so cause the deadlock. Not sure whether
> there are similar issue for other cluster fs, like nfs, it is possible
> rpciod hung like the ocfs2 workqueue?
All this info should be in the changelog.
>
> > I don't think it's accurate to say that __GFP_FS implies __GFP_IO.
> > Where did that info come from?
> __GFP_FS allowed callback into fs during memory allocation, and fs may
> do io whatever __GFP_IO is set?
__GFP_FS and __GFP_IO are (or were) for communicating to vmscan: don't
enter the fs for writepage, don't write back swapcache.
I guess those concepts have grown over time without a ton of thought
going into it. Yes, I suppose that if a filesystem's writepage is
called (for example) it expects that it will be able to perform
writeback and it won't check (or even be passed) the __GFP_IO setting.
So I guess we could say that !__GFP_FS && GFP_IO is not implemented and
shouldn't occur.
That being said, it still seems quite bad to disable VFS cache
shrinking for PF_MEMALLOC_NOIO allocation attempts.
> >
> > And the superblock shrinker is a good example of why this shouldn't be
> > the case. The main thing that code does is to reclaim clean fs objects
> > without performing IO. AFAICT the proposed patch will significantly
> > weaken PF_MEMALLOC_NOIO allocation attempts by needlessly preventing
> > the kernel from reclaiming such objects?
> Even fs didn't do io in superblock shrinker, it is possible for a fs
> process who is not convenient to set GFP_NOFS holding some fs lock and
> call back fs again?
>
> PF_MEMALLOC_NOIO is only set for some special processes. I think it
> won't affect much.
Maybe not now. But once we add hacks like this, people say "goody" and
go and use them rather than exerting the effort to sort out their
deadlocks properly :( There will be more PF_MEMALLOC_NOIO users in
2019.
Dunno, I'd like to hear David's thoughts but perhaps it would be better
to find some way to continue to permit PF_MEMALLOC_NOIO to shrink VFS
caches for most filesystems and find some fs-specific fix for ocfs2.
That would mean testing PF_MEMALLOC_NOIO directly I guess.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 4/4] ftracetest: Add XFAIL/XPASS and POSIX.3 std. result codes
On Tue, 02 Sep 2014 11:06:59 +, Masami Hiramatsu wrote: > Add XFAIL, XPASS and POSIX 1003.3 std. codes (UNRESOLVED/ > UNTESTED/UNSUPPORTED) as a result code. These are > used for the results that test case is expected to fail or > unsupported feature (by config). > This also introduces PASS/FAIL/XFAIL/XPASS/UNSUP/UNTST/UNRES > result codes for each testcase. Since the results are not > binary, each testcase must use these codes to return the > test result. > > Changes in v3: > - Add UNRESOLVED/UNTESTED codes. > - Fix to handle undefined codes. > - Add a document about return codes. > - Fix to show failure logs. > - Don't use -e option for echo since dash doesn't support it. > > Signed-off-by: Masami Hiramatsu > --- [SNIP] > diff --git a/tools/testing/ftrace/test.d/basic3.tc > b/tools/testing/ftrace/test.d/basic3.tc > index 0c1a3a2..7bc5a53 100644 > --- a/tools/testing/ftrace/test.d/basic3.tc > +++ b/tools/testing/ftrace/test.d/basic3.tc > @@ -1,8 +1,9 @@ > #!/bin/sh > # description: Basic trace clock test > -[ -f trace_clock ] || exit 1 > +[ -f trace_clock ] || exit $FAIL # this is basic feature, must be there > for c in `cat trace_clock | tr -d \[\]`; do > - echo $c > trace_clock || exit 1 > - grep '\['$c'\]' trace_clock || exit 1 > + echo $c > trace_clock || exit $FAIL > + grep '\['$c'\]' trace_clock || exit $FAIL > done > -echo local > trace_clock > +echo local > trace_clock || exit $FAIL > +exit $PASS IMHO it's a bit sad that we need to write every test in this way - adding '|| exit $FAIL' for every command. It'd be better if only exceptional cases require that explicitly and normal cases live in simple. Can we do better - like using trap or something? Thanks, Namhyung -- 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] zram: add num_discards for discarded pages stat
Hello Sergey, First of all, Sorry for late response. On Tue, Aug 26, 2014 at 11:15:43PM +0900, Sergey Senozhatsky wrote: > Hello, > > On (08/26/14 14:08), Minchan Kim wrote: > > Hi, > > > > On Mon, Aug 25, 2014 at 08:01:18PM +0900, Sergey Senozhatsky wrote: > > > Hello, > > > > > > On (08/25/14 09:36), Minchan Kim wrote: > > > > Hello Chao, > > > > > > > > On Fri, Aug 22, 2014 at 04:21:01PM +0800, Chao Yu wrote: > > > > > Since we have supported handling discard request in this commit > > > > > f4659d8e620d08bd1a84a8aec5d2f5294a242764 (zram: support REQ_DISCARD), > > > > > zram got > > > > > one more chance to free unused memory whenever received discard > > > > > request. But > > > > > without stating for discard request, there is no method for user to > > > > > know whether > > > > > discard request has been handled by zram or how many blocks were > > > > > discarded by > > > > > zram when user wants to know the effect of discard. > > > > > > > > My concern is that how much we are able to know the effect of discard > > > > exactly with your patch. > > > > > > > > The issue I can think of is zram-swap discard. > > > > Now, zram handles notification from VM to free duplicated copy between > > > > VM-owned memory and zRAM-owned's one so discarding for zram-swap might > > > > be pointless overhead but your stat indicates lots of free page > > > > discarded > > > > without real freeing > > > > > > this is why I've moved stats accounting to the place where actual > > > zs_free() happens. and, frankly, I still would like to see the number > > > of zs_free() calls, rather than the number of slot free notifications > > > and REQ_DISCARD (or separately), because they all end up calling > > > zs_free(). iow, despite the call path, from the user point of view > > > they are just zs_free() -- the number of pages that's been freed by > > > the 3rd party and we had have to deal with that. > > > > My qeustion is that what user can do with the only real freeing count? > > Could you give me a concret example? > > for !swap device case it's identicall to `num_discarded'. > for swap device case, it's a bit more complicated (less convenient) if > we actually can receive both slot free and delayed REQ_DISCARDs. > > > It's a just number of real freeing count so if you were admin, what > > do you expect from that? That's what I'd like to see in changelog. > > > > > > > > > so that user might think "We should keep enable > > > > swap discard for zRAM because the stat indicates it's really good". > > > > > > > > In summary, wouldn't it better to have two? > > > > > > > > num_discards, > > > > num_failed_discards? > > > > > > do we actully need this? the only value I can think of (perhaps I'm > > > missing something) is that we can make sure that we need to support > > > both slot free and REQ_DISCARDS, or we can leave only REQ_DISCARDS. > > > is there anything else? > > > > The secnario I imagined with two stat is how REQ_DISCARDS is effective > > from swap layer. Normally, slot free logic is called in advance > > when the page is zapped or swap read happens to avoid duplicate copy, > > so discard request from swap space would be just overhead without > > any benefit so we might guide zram-swap user don't use "swap -d". > > Otherwise, as failed_discard ratio is low, it means it would be > > better to remove swap slot free logic because swap discard works well > > without slot free hint.(Although I don't think) > > yes, so it looks like it is a developer's stat - to make some > observations and to come up with some decisions. do we really > want to put it into release? Agree. I was too specific for my purpose and it couldn't be a compelling reason to make it export for general purpose. Actually, discard req sent by swap for getting free cluster shouldn't be success(i,e num_discarded should be zero) because zram_slot_free_notify will always free the duplicated copy in advance so user don't have any gain with 'swapon -d'. Now, I agree with you that we shouldn't add more stat without compelling reason so it would be better to rename notify_free with discarded and move it in zram_free_page like your patch. https://lkml.org/lkml/2014/8/21/294 I will ask to Andrew to revert Chao's patch and pick your patch after a few days unless Chao has another opinion. > > > I'm not strongly against and we can proceed with Chao's patch. > > -ss > > > My point is I'm not saying you're wrong but adding a new stat is easy > > and I need a compelling reason that how it can help users. > > > > Thanks. > > > > > > > > -ss > > > > > > > For it, we should modify zram_free_page has return value. > > > > What do other guys think? > > > > > > > > > > > > > > In this patch, we add num_discards to stat discarded pages, and > > > > > export it to > > > > > sysfs for users. > > > > > > > > > > * From v1 > > > > > * Update zram document to show num_discards in statistics list. > > > > > > > > > > * From v2 > > >
Re: workqueue: WARN at at kernel/workqueue.c:2176
On 09/03/2014 11:15 PM, Peter Zijlstra wrote:
> On Mon, Sep 01, 2014 at 11:04:23AM +0800, Lai Jiangshan wrote:
>> Hi, Peter
>>
>> Could you make a patch for it, please? Jason J. Herne's test showed we
>> addressed the bug. But the fix is not in kernel yet. Some new highly
>> related reports are come up again.
>>
>> I don't want to argue any more, no matter how the patch will be,
>> I will accept. And please add the following tags in your patch:
>
> Well; I said http://marc.info/?l=linux-kernel=140187009016179 was a
> good patch and only asked you to add a comment and make it a nice patch
> which I could apply: http://marc.info/?l=linux-kernel=140187477317886=2
>
I posted this patch as a quick fix for early test...
It didn't match my own criteria which may be diverted from the community
although.
I'm sorry for having pushed my personal thinking to the community and resulted
that you had to write comment for my patch which was my responsibility.
> Instead you posted an entirely different patch again.
>
> So how about the below?
Acked
>
> ---
> Subject: sched: Migrate waking tasks
> From: Lai Jiangshan
> Date: Wed, 4 Jun 2014 16:25:15 +0800
>
> Current code can fail to migrate a waking task (silently) when TTWU_QUEUE is
> enabled.
>
> When a task is waking, it is pending on the wake_list of the rq, but it is not
> queued (task->on_rq == 0). In this case, set_cpus_allowed_ptr() and
> __migrate_task() will not migrate it because its invisible to them.
>
> This behavior is incorrect, because the task has been already woken, it will
> be
> running on the wrong CPU without correct placement until the next wake-up or
> update for cpus_allowed.
>
> To fix this problem, we need to finish the wakeup (so they appear on
> the runqueue) before we migrate them.
>
> Reported-by: Sasha Levin
> Reported-by: Jason J. Herne
> Tested-by: Jason J. Herne
> signed-off-by: Lai Jiangshan
> Signed-off-by: Peter Zijlstra (Intel)
> Link: http://lkml.kernel.org/r/538ed7eb.5050...@cn.fujitsu.com
> ---
> kernel/sched/core.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4642,7 +4642,7 @@ int set_cpus_allowed_ptr(struct task_str
> goto out;
>
> dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
> - if (task_on_rq_queued(p)) {
> + if (task_on_rq_queued(p) || p->state == TASK_WAKING) {
unrelated question: why we have to stop the cpu even the task is
not running?
--
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] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set
On 09/03/2014 08:20 PM, Trond Myklebust wrote:
> On Wed, Sep 3, 2014 at 1:54 AM, Junxiao Bi wrote:
>> commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
>> during memory allocation")
>> introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory
>> allocation, __GFP_IO is cleared
>> when this flag is set, but __GFP_FS implies __GFP_IO, it should also be
>> cleared. Or it may still
>> run into I/O, like in superblock shrinker.
>>
>> Signed-off-by: Junxiao Bi
>> Cc: joyce.xue
>> Cc: Ming Lei
>> ---
>> include/linux/sched.h |6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 5c2c885..2fb2c47 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1936,11 +1936,13 @@ extern void thread_group_cputime_adjusted(struct
>> task_struct *p, cputime_t *ut,
>> #define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
>> #define used_math() tsk_used_math(current)
>>
>> -/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
>> +/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags
>> + * __GFP_FS is also cleared as it implies __GFP_IO.
>> + */
>> static inline gfp_t memalloc_noio_flags(gfp_t flags)
>> {
>> if (unlikely(current->flags & PF_MEMALLOC_NOIO))
>> - flags &= ~__GFP_IO;
>> + flags &= ~(__GFP_IO | __GFP_FS);
>> return flags;
>> }
>>
>
> Shouldn't this be a stable fix? If it is needed, then it will affect
> all kernels that define PF_MEMALLOC_NOIO.
Yes, should be. An ocfs2 deadlock bug related to this.
Thanks,
Junxiao.
>
--
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/5] Clocksource: Flextimer: Fix counter clock prescaler calculation.
> Subject: Re: [PATCH 4/5] Clocksource: Flextimer: Fix counter clock prescaler
> calculation.
>
> On Tue, 26 Aug 2014, Xiubo Li wrote:
>
> > We should minus one after calculating the counter input clock's
> > prescaler.
> >
> > Signed-off-by: Xiubo Li
> > Signed-off-by: Jingchang Lu
> > ---
> > drivers/clocksource/fsl_ftm_timer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clocksource/fsl_ftm_timer.c
> b/drivers/clocksource/fsl_ftm_timer.c
> > index f70fcf2..974890e 100644
> > --- a/drivers/clocksource/fsl_ftm_timer.c
> > +++ b/drivers/clocksource/fsl_ftm_timer.c
> > @@ -311,7 +311,7 @@ static int __init ftm_calc_closest_round_cyc(unsigned
> long freq)
> > HZ * (1 << priv->ps++));
> > } while (priv->periodic_cyc > 0x);
> >
> > - if (priv->ps > FTM_PS_MAX) {
> > + if (--priv->ps > FTM_PS_MAX) {
>
> Looking at this makes me run away screaming. Just because you
> increment priv->ps unconditionally in the loop above, you decrement it
> again here. Why not fix the calculation proper in the first place?
>
> for (cyc = ~0UL, ps = 0, div = HZ; cyc > 0x; ps++, div *= 2)
> cyc = DIV_ROUND_CLOSEST(freq, div);
>
Yes, this looks nice.
Thanks,
BRs
Xiubo
--
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] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set
On 09/04/2014 07:10 AM, Andrew Morton wrote:
> On Wed, 3 Sep 2014 13:54:54 +0800 Junxiao Bi wrote:
>
>> commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
>> during memory allocation")
>> introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory
>> allocation, __GFP_IO is cleared
>> when this flag is set, but __GFP_FS implies __GFP_IO, it should also be
>> cleared. Or it may still
>> run into I/O, like in superblock shrinker.
>
> Is there an actual bug which inspired this fix? If so, please describe
> it.
>
Yes, an ocfs2 deadlock bug is related to this, there is a workqueue in
ocfs2 who is for building tcp connections and processing ocfs2 message.
Like when an new node is up in ocfs2 cluster, the workqueue will try to
build the connections to it, since there are some common code in
networking like sock_alloc() using GFP_KERNEL to allocate memory, direct
reclaim will be triggered and call into superblock shrinker if available
memory is not enough even set PF_MEMALLOC_NOIO for the workqueue. To
shrink the inode cache, ocfs2 needs release cluster lock and this
depends on workqueue to do it, so cause the deadlock. Not sure whether
there are similar issue for other cluster fs, like nfs, it is possible
rpciod hung like the ocfs2 workqueue?
> I don't think it's accurate to say that __GFP_FS implies __GFP_IO.
> Where did that info come from?
__GFP_FS allowed callback into fs during memory allocation, and fs may
do io whatever __GFP_IO is set?
>
> And the superblock shrinker is a good example of why this shouldn't be
> the case. The main thing that code does is to reclaim clean fs objects
> without performing IO. AFAICT the proposed patch will significantly
> weaken PF_MEMALLOC_NOIO allocation attempts by needlessly preventing
> the kernel from reclaiming such objects?
Even fs didn't do io in superblock shrinker, it is possible for a fs
process who is not convenient to set GFP_NOFS holding some fs lock and
call back fs again?
PF_MEMALLOC_NOIO is only set for some special processes. I think it
won't affect much.
Thanks,
Junxiao.
>
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1936,11 +1936,13 @@ extern void thread_group_cputime_adjusted(struct
>> task_struct *p, cputime_t *ut,
>> #define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
>> #define used_math() tsk_used_math(current)
>>
>> -/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
>> +/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags
>> + * __GFP_FS is also cleared as it implies __GFP_IO.
>> + */
>> static inline gfp_t memalloc_noio_flags(gfp_t flags)
>> {
>> if (unlikely(current->flags & PF_MEMALLOC_NOIO))
>> -flags &= ~__GFP_IO;
>> +flags &= ~(__GFP_IO | __GFP_FS);
>> return flags;
>> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/5] Clocksource: Flextimer: Use Macro for clock source selection.
> Subject: Re: [PATCH 5/5] Clocksource: Flextimer: Use Macro for clock source > selection. > > On Tue, 26 Aug 2014, Xiubo Li wrote: > > FTM source clock is selectable: > > Source clock can be the system clock, the fixed frequency clock, > > or an external clock. > > Fixed frequency clock is an additional clock input to allow the > > selection of an on chip clock source other than the system clock. > > Selecting external clock connects FTM clock to a chip level input > > pin therefore allowing to synchronize the FTM counter with an off > > chip clock source > > > > Clock Source Selection: > > Selects one of the three FTM counter clock sources. > > > > 00 No clock selected. This in effect disables the FTM counter. > > 01 System clock > > --- > > 10 Fixed frequency clock > > 11 External clock > > > > These two will be useful for the alarm on LS1 platform in late future, > > the system clock's frequency is too high to get a long delay timer when > > go to sleep, so the fixed or external clock could be used instead. > > And how is that relevant to changing the mask from a hardcoded value > to a constant? It's still hardcoded at compile time and I don't see > how that helps chosing the clock at runtime for a particular use case. > > > #define FTM_SC 0x00 > > +#define FTM_SC_CLKS_NON0 > > +#define FTM_SC_CLKS_SYS1 > > #define FTM_SC_CLK_SHIFT 3 > > #define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT) > > #define FTM_SC_CLK(c) ((c) << FTM_SC_CLK_SHIFT) > > @@ -67,7 +69,7 @@ static inline void ftm_counter_enable(void __iomem *base) > > /* select and enable counter clock source */ > > val = ftm_readl(base + FTM_SC); > > val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK); > > - val |= priv->ps | FTM_SC_CLK(1); > > + val |= priv->ps | FTM_SC_CLK(FTM_SC_CLKS_SYS); > > ftm_writel(val, base + FTM_SC); > > } > > > > @@ -77,7 +79,8 @@ static inline void ftm_counter_disable(void __iomem *base) > > > > /* disable counter clock source */ > > val = ftm_readl(base + FTM_SC); > > - val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK); > > + val &= ~(FTM_SC_CLK_MASK); > > So you remove the FTM_SC_PS_MASK without mentioning it in the > changelog. Either this is by mistake or it wants to be documented WHY > it is not needed in the first place. > This is just prepare for the other new features in the future. And delay this changes maybe better. Thanks, BRs Xiubo -- 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/5] Clocksource: Flextimer: Fix counter clock prescaler calculation.
Hi Thomas, Thanks very much for your comments. Firstly I must tell the true that English is not my mother language. > Subject: Re: [PATCH 4/5] Clocksource: Flextimer: Fix counter clock prescaler > calculation. > > On Tue, 26 Aug 2014, Xiubo Li wrote: > > > We should minus one after calculating the counter input clock's > > prescaler. > > And that's a complete useless changelog. > > A) It lacks a proper description of the problem > > B) It lacks a proper argument WHY we must decrement the prescaler >value > >Hint: I used the verb "must" instead of "should". Can you figure >out why? > Yes, we should use 'must' here, because we are using 'ps++' in the loop code, the correct value should be 'ps = ps - 1', after the loop. BRs Xiubo -- 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/3] GPIO: gpio-dwapb: Enable platform driver binding to MFD driver
>
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -136,7 +136,6 @@ config GPIO_DWAPB
> > tristate "Synopsys DesignWare APB GPIO driver"
> > select GPIO_GENERIC
> > select GENERIC_IRQ_CHIP
> > - depends on OF_GPIO
> you need either OF_GPIO or PCI
Since we enable this module not only support OF devices, but also support MFD
devices, so we remove OF_GPIO dependency.
For 'PCI', the original code is also not depended on PCI, and this patch also
not, do you think it is necessary?
> >
> > struct dwapb_gpio {
> > struct device *dev;
> > void __iomem*regs;
> > struct dwapb_gpio_port *ports;
> > - unsigned intnr_ports;
> you could keep this the way it is
It has been moved to 'pdata'.
> > struct irq_domain *domain;
> > + const struct dwapb_gpio_platform_data *pdata;
>
> and not making this a member of this struct. I've been going up and down the
> source and I don't see the need to marry dwapb_gpio to
> dwapb_gpio_platform_data.
> That dwapb_gpio_port_property thing has a long name. Could you just set it up,
> pass it for registration and the free it? You can't free the pdata for the
> non-OF
> tree but for the OF case you keep that struct around for no reason.
> You could safe some memory and use pdata directly for setup.
Here, 'pdata' is used for both OF and MFD. For MFD, 'pdata' is passed from MFD.
For OF, 'pdata' is getting from device nodes properties. Why do we have such
design? Because it can make the handling
more easy for flowing routine. All necessary properties get from 'pdata', never
care it is from OF or MFD. And someone
are working on replacing OF interface with a firmware agnostic device_property*
interface which will work with both OF and ACPI.
More information for this design, please contact Darren Hart
. Darren Hart wrote to me:
"Generally speaking, rather than if/else blocks throughout the code checking if
it is enumerated via open firmware or as a platform device,
a cleaner approach is to check if the pdata is null, and if so, populate the
pdata from the open firmware description if present.
Then use the pdata throughout the driver.
Something to keep in mind is that we are working to replace the of_* interface
with a firmware agnostic device_property* interface
which will work with both OF and ACPI. Patches to hit LKML this week for the
acpi and driver core.
Organizing the code as described above will better encapsulate the
firmware-config logic and make it easier to update."
And you can also refer the code 'driver/input/keyboard/gpio_keys.c', and this
patch takes it as an example.
> > };
> >
> > static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
> > @@ -207,22 +209,24 @@ static int dwapb_irq_set_type(struct irq_data *d,
> u32 type)
> > return 0;
> > }
> >
> > +static irqreturn_t dwapb_irq_handler_mfd(int irq, void *dev_id) {
> > + struct irq_desc *desc = irq_to_desc(irq);
> > +
> > + dwapb_irq_handler(irq, desc);
> > +
> > + return IRQ_HANDLED;
>
> I suggest to teach dwapb_irq_handler() to return something that makes you
> decide whether or not IRQ_HANDLED is the thing to do here. If something goes
> crazy the core has no way of knowing and shutting you down.
> Also invoking ->irq_eoi() _before_ your shared was invoked might not smart.
> What you want is something like
>
> static u32 _dwapb_irq_handler(struct dwapb_gpio *gpio, struct irq_chip
> *chip) {
> u32 irq_status = readl_relaxed(gpio->regs + GPIO_INTSTATUS);
>u32 ret = irq_status;
>
> while (irq_status) {
> int hwirq = fls(irq_status) - 1;
> int gpio_irq = irq_find_mapping(gpio->domain, hwirq);
>
> generic_handle_irq(gpio_irq);
> irq_status &= ~BIT(hwirq);
>
> if ((irq_get_trigger_type(gpio_irq) &
> IRQ_TYPE_SENSE_MASK)
> == IRQ_TYPE_EDGE_BOTH)
> dwapb_toggle_trigger(gpio, hwirq);
> }
>return ret;
> }
>
> static void dwapb_irq_handler(u32 irq, struct irq_desc *desc) {
> struct dwapb_gpio *gpio = irq_get_handler_data(irq);
> struct irq_chip *chip = irq_desc_get_chip(desc);
>
> _dwapb_irq_handler(gpio, chip);
>
> if (chip->irq_eoi)
> chip->irq_eoi(irq_desc_get_irq_data(desc));
> }
>
> static irqreturn_t dwapb_irq_handler_mfd(int irq, void *dev_id) {
> struct irq_desc *desc = irq_to_desc(irq);
> struct irq_chip *chip = irq_desc_get_chip(desc);
> int worked;
>
> worked = dwapb_irq_handler(dev_id, chip);
> if (worked)
> return IRQ_HANDLED;
> else
> return IRQ_NONE;
> }
>
> How about it?
OK, I will improve it as your suggestion.
> > + irq_set_handler_data(port->pp->irq, gpio);
>
> This does not look like it belongs here. It should only be used together with
> irq_set_chained_handler()
Re: [PATCH v3 5/6] mm/hugetlb: add migration entry check in __unmap_hugepage_range
On Thu, 28 Aug 2014, Naoya Horiguchi wrote:
> If __unmap_hugepage_range() tries to unmap the address range over which
> hugepage migration is on the way, we get the wrong page because pte_page()
> doesn't work for migration entries. This patch calls pte_to_swp_entry() and
> migration_entry_to_page() to get the right page for migration entries.
>
> Signed-off-by: Naoya Horiguchi
> Cc: # [2.6.36+]
2.6.36+? But this one doesn't affect hwpoisoned.
I admit I've lost track of how far back hugetlb migration goes:
oh, to 2.6.37+, that fits with what you marked on some commits earlier.
But then 2/6 says 3.12+. Help! Please remind me of the sequence of events.
> ---
> mm/hugetlb.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git mmotm-2014-08-25-16-52.orig/mm/hugetlb.c
> mmotm-2014-08-25-16-52/mm/hugetlb.c
> index 1ed9df6def54..0a455ee0 100644
> --- mmotm-2014-08-25-16-52.orig/mm/hugetlb.c
> +++ mmotm-2014-08-25-16-52/mm/hugetlb.c
> @@ -2652,6 +2652,13 @@ void __unmap_hugepage_range(struct mmu_gather *tlb,
> struct vm_area_struct *vma,
> if (huge_pte_none(pte))
> goto unlock;
>
> + if (unlikely(is_hugetlb_entry_migration(pte))) {
> + swp_entry_t entry = pte_to_swp_entry(pte);
> +
> + page = migration_entry_to_page(entry);
> + goto clear;
> + }
> +
This surprises me: are you sure? Obviously you know hugetlb migration
much better than I do: is it done in a significantly different way from
order:0 page migration? In the order:0 case, there is no reference to
the page corresponding to the migration entry placed in a page table,
just the remaining reference held by the task doing the migration. But
here you are jumping to the code which unmaps and frees a present page.
I can see that a fix is necessary, but I would have expected it to
consist of merely changing the "HWPoisoned" comment below to include
migration entries, and changing its test from
if (unlikely(is_hugetlb_entry_hwpoisoned(pte))) {
to
if (unlikely(!pte_present(pte))) {
> /*
>* HWPoisoned hugepage is already unmapped and dropped reference
>*/
> @@ -2677,7 +2684,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb,
> struct vm_area_struct *vma,
>*/
> set_vma_resv_flags(vma, HPAGE_RESV_UNMAPPED);
> }
> -
> +clear:
> pte = huge_ptep_get_and_clear(mm, address, ptep);
> tlb_remove_tlb_entry(tlb, ptep, address);
> if (huge_pte_dirty(pte))
> --
> 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 2/5] Clocksource: Flextimer: Use internal clocksource read API.
> Subject: Re: [PATCH 2/5] Clocksource: Flextimer: Use internal clocksource read > API. > > On Tue, 26 Aug 2014, Xiubo Li wrote: > > > Since the Flextimer device will be implemented in BE mode on > > LS1 SoC, and in LE mode on Vybrid, LS2 SoCs, so here we need > > the endianness judgment before doing the mmio. > > Brilliant. So for every clocksource read you take a conditional. > > > @@ -238,7 +243,7 @@ static int __init ftm_clocksource_init(unsigned long > freq) > > sched_clock_register(ftm_read_sched_clock, 16, freq / (1 << priv->ps)); > > err = clocksource_mmio_init(priv->clksrc_base + FTM_CNT, "fsl-ftm", > > freq / (1 << priv->ps), 300, 16, > > - clocksource_mmio_readl_up); > > + ftm_clocksource_read_up); > > What's wrong with having endianess aware clocksource_mmio functions > and make the decision at init time? > Since the FTM will be in BE mode on LS1 platform, but will be in LE mode On LS2 platform. And ftm_clocksource_read_up() will adapt to this different. Thanks, BRs Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/4] ftracetest: Initial commit for ftracetest
(2014/09/04 10:41), Namhyung Kim wrote:
> Hi Masami,
>
> Just a nit..
>
>
> On Tue, 02 Sep 2014 11:06:39 +, Masami Hiramatsu wrote:
>> ftracetest is a collection of testcase shell-scripts for ftrace.
>> To avoid regressions of ftrace, these testcases check correct
>> ftrace behaviors. If someone would like to add any features on
>> ftrace, the patch series should have at least one testcase for
>> checking the new behavior.
>
>
> [SNIP]
>> +# Run one test case
>> +run_test() { # testfile
>> + local testname=`basename $1`
>> + local testlog=`mktemp --tmpdir=$LOG_DIR ${testname}-XX.log`
>> + testcase $1
>> + echo "execute: "$1 > $testlog
>> + (cd $TRACING_DIR; set -x ; . $t) >> $testlog 2>&1
>
> s/$t/$1/ ?
Oops, right! I missed that. Since the $1 is same as $t, the
test itself works, but it should be fixed.
Thank you!
>
> Thanks,
> Namhyung
>
>
>> + ret=$?
>> + if [ $ret -ne 0 ]; then
>> +failed
>> +catlog $testlog
>> + else
>> +passed
>> +[ $KEEP_LOG -eq 0 ] && rm $testlog
>> + fi
>> +}
>> +
>> +# Main loop
>> +for t in $TEST_CASES; do
>> + run_test $t
>> +done
>> +prlog ""
>> +prlog "# of passed: " `echo $PASSED_CASES | wc -w`
>> +prlog "# of failed: " `echo $FAILED_CASES | wc -w`
>> +
>> +test -z "$FAILED_CASES" # if no error, return 0
>> diff --git a/tools/testing/ftrace/test.d/template
>> b/tools/testing/ftrace/test.d/template
>> new file mode 100644
>> index 000..ce5f735
>> --- /dev/null
>> +++ b/tools/testing/ftrace/test.d/template
>> @@ -0,0 +1,4 @@
>> +#!/bin/sh
>> +# description: %HERE DESCRIBE WHAT THIS DOES%
>> +# you have to add ".tc" extention for your testcase file
>> +exit 0 # Return 0 if the test is passed, otherwise return !0
>
--
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 v4] x86, hotplug: fix llc shared map unreleased during cpu hotplug
Ping Ingo, Peter, On Mon, Aug 25, 2014 at 01:32:47PM +0800, Wanpeng Li wrote: > >于 14-8-15 下午2:07, Borislav Petkov 写道: >>On Fri, Aug 15, 2014 at 11:00:42AM +0800, Wanpeng Li wrote: >>>Is it ok for you to apply this patch or still need update? >>Just be patient: we have the merge window still open and after that >>kernel summit coming up first. > >Thanks for pointing out. > >Regards, >Wanpeng Li > >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/4] ftracetest: Initial commit for ftracetest
Hi Masami,
Just a nit..
On Tue, 02 Sep 2014 11:06:39 +, Masami Hiramatsu wrote:
> ftracetest is a collection of testcase shell-scripts for ftrace.
> To avoid regressions of ftrace, these testcases check correct
> ftrace behaviors. If someone would like to add any features on
> ftrace, the patch series should have at least one testcase for
> checking the new behavior.
[SNIP]
> +# Run one test case
> +run_test() { # testfile
> + local testname=`basename $1`
> + local testlog=`mktemp --tmpdir=$LOG_DIR ${testname}-XX.log`
> + testcase $1
> + echo "execute: "$1 > $testlog
> + (cd $TRACING_DIR; set -x ; . $t) >> $testlog 2>&1
s/$t/$1/ ?
Thanks,
Namhyung
> + ret=$?
> + if [ $ret -ne 0 ]; then
> +failed
> +catlog $testlog
> + else
> +passed
> +[ $KEEP_LOG -eq 0 ] && rm $testlog
> + fi
> +}
> +
> +# Main loop
> +for t in $TEST_CASES; do
> + run_test $t
> +done
> +prlog ""
> +prlog "# of passed: " `echo $PASSED_CASES | wc -w`
> +prlog "# of failed: " `echo $FAILED_CASES | wc -w`
> +
> +test -z "$FAILED_CASES" # if no error, return 0
> diff --git a/tools/testing/ftrace/test.d/template
> b/tools/testing/ftrace/test.d/template
> new file mode 100644
> index 000..ce5f735
> --- /dev/null
> +++ b/tools/testing/ftrace/test.d/template
> @@ -0,0 +1,4 @@
> +#!/bin/sh
> +# description: %HERE DESCRIBE WHAT THIS DOES%
> +# you have to add ".tc" extention for your testcase file
> +exit 0 # Return 0 if the test is passed, otherwise return !0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/3] mm: add swap_get_free hint for zram
VM uses nr_swap_pages as one of information when it does
anonymous reclaim so that VM is able to throttle amount of swap.
Normally, the nr_swap_pages is equal to freeable space of swap disk
but for zram, it doesn't match because zram can limit memory usage
by knob(ie, mem_limit) so although VM can see lots of free space
from zram disk, zram can make fail intentionally once the allocated
space is over to limit. If it happens, VM should notice it and
stop reclaimaing until zram can obtain more free space but there
is a good way to do at the moment.
This patch adds new hint SWAP_GET_FREE which zram can return how
many of freeable space it has. With using that, this patch adds
__swap_full which returns true if the zram is full and substract
remained freeable space of the zram-swap from nr_swap_pages.
IOW, VM sees there is no more swap space of zram so that it stops
anonymous reclaiming until swap_entry_free free a page and increase
nr_swap_pages again.
Signed-off-by: Minchan Kim
---
include/linux/blkdev.h | 1 +
mm/swapfile.c | 45 +++--
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 17437b2c18e4..c1199806e0f1 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1611,6 +1611,7 @@ static inline bool blk_integrity_is_initialized(struct
gendisk *g)
enum swap_blk_hint {
SWAP_SLOT_FREE,
+ SWAP_GET_FREE,
};
struct block_device_operations {
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 4bff521e649a..72737e6dd5e5 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -484,6 +484,22 @@ new_cluster:
*scan_base = tmp;
}
+static bool __swap_full(struct swap_info_struct *si)
+{
+ if (si->flags & SWP_BLKDEV) {
+ long free;
+ struct gendisk *disk = si->bdev->bd_disk;
+
+ if (disk->fops->swap_hint)
+ if (!disk->fops->swap_hint(si->bdev,
+ SWAP_GET_FREE,
+ ))
+ return free <= 0;
+ }
+
+ return si->inuse_pages == si->pages;
+}
+
static unsigned long scan_swap_map(struct swap_info_struct *si,
unsigned char usage)
{
@@ -583,11 +599,21 @@ checks:
if (offset == si->highest_bit)
si->highest_bit--;
si->inuse_pages++;
- if (si->inuse_pages == si->pages) {
+ if (__swap_full(si)) {
+ struct gendisk *disk = si->bdev->bd_disk;
+
si->lowest_bit = si->max;
si->highest_bit = 0;
spin_lock(_avail_lock);
plist_del(>avail_list, _avail_head);
+ /*
+* If zram is full, it decreases nr_swap_pages
+* for stopping anonymous page reclaim until
+* zram has free space. Look at swap_entry_free
+*/
+ if (disk->fops->swap_hint)
+ atomic_long_sub(si->pages - si->inuse_pages,
+ _swap_pages);
spin_unlock(_avail_lock);
}
si->swap_map[offset] = usage;
@@ -796,6 +822,7 @@ static unsigned char swap_entry_free(struct
swap_info_struct *p,
/* free if no reference */
if (!usage) {
+ struct gendisk *disk = p->bdev->bd_disk;
dec_cluster_info_page(p, p->cluster_info, offset);
if (offset < p->lowest_bit)
p->lowest_bit = offset;
@@ -808,6 +835,21 @@ static unsigned char swap_entry_free(struct
swap_info_struct *p,
if (plist_node_empty(>avail_list))
plist_add(>avail_list,
_avail_head);
+ if ((p->flags & SWP_BLKDEV) &&
+ disk->fops->swap_hint) {
+ atomic_long_add(p->pages -
+ p->inuse_pages,
+ _swap_pages);
+ /*
+* reset [highest|lowest]_bit to avoid
+* scan_swap_map infinite looping if
+* cached free cluster's index by
+* scan_swap_map_try_ssd_cluster is
+* above p->highest_bit.
+*/
+ p->highest_bit = p->max - 1;
+ p->lowest_bit = 1;
+ }
spin_unlock(_avail_lock);
}
}
@@ -815,7 +857,6 @@ static unsigned char
[RFC 1/3] zram: generalize swap_slot_free_notify
Currently, swap_slot_free_notify is used for zram to free
duplicated copy page for memory efficiency when it knows
there is no reference to the swap slot.
Let's extend it to be able to use it for other purpose
so this patch generalizes it so that zram can get more hints
from VM.
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 7 ++-
drivers/block/zram/zram_drv.c | 18 --
include/linux/blkdev.h| 7 +--
mm/page_io.c | 7 ---
mm/swapfile.c | 7 ---
5 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/Documentation/filesystems/Locking
b/Documentation/filesystems/Locking
index f1997e9da61f..e7133874fd75 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -405,7 +405,7 @@ prototypes:
void (*unlock_native_capacity) (struct gendisk *);
int (*revalidate_disk) (struct gendisk *);
int (*getgeo)(struct block_device *, struct hd_geometry *);
- void (*swap_slot_free_notify) (struct block_device *, unsigned long);
+ int (*swap_hint) (struct block_device *, unsigned int, void *);
locking rules:
bd_mutex
@@ -418,14 +418,11 @@ media_changed:no
unlock_native_capacity:no
revalidate_disk: no
getgeo:no
-swap_slot_free_notify: no (see below)
+swap_hint: no
media_changed, unlock_native_capacity and revalidate_disk are called only from
check_disk_change().
-swap_slot_free_notify is called with swap_lock and sometimes the page lock
-held.
-
--- file_operations ---
prototypes:
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index be88d750b112..88661d62e46a 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -933,7 +933,8 @@ error:
bio_io_error(bio);
}
-static void zram_slot_free_notify(struct block_device *bdev,
+/* this callback is with swap_lock and sometimes page table lock held */
+static int zram_slot_free_notify(struct block_device *bdev,
unsigned long index)
{
struct zram *zram;
@@ -946,10 +947,23 @@ static void zram_slot_free_notify(struct block_device
*bdev,
zram_free_page(zram, index);
bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
atomic64_inc(>stats.notify_free);
+
+ return 0;
+}
+
+static int zram_swap_hint(struct block_device *bdev,
+ unsigned int hint, void *arg)
+{
+ int ret = -EINVAL;
+
+ if (hint == SWAP_SLOT_FREE)
+ ret = zram_slot_free_notify(bdev, (unsigned long)arg);
+
+ return ret;
}
static const struct block_device_operations zram_devops = {
- .swap_slot_free_notify = zram_slot_free_notify,
+ .swap_hint = zram_swap_hint,
.owner = THIS_MODULE
};
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 518b46555b80..17437b2c18e4 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1609,6 +1609,10 @@ static inline bool blk_integrity_is_initialized(struct
gendisk *g)
#endif /* CONFIG_BLK_DEV_INTEGRITY */
+enum swap_blk_hint {
+ SWAP_SLOT_FREE,
+};
+
struct block_device_operations {
int (*open) (struct block_device *, fmode_t);
void (*release) (struct gendisk *, fmode_t);
@@ -1624,8 +1628,7 @@ struct block_device_operations {
void (*unlock_native_capacity) (struct gendisk *);
int (*revalidate_disk) (struct gendisk *);
int (*getgeo)(struct block_device *, struct hd_geometry *);
- /* this callback is with swap_lock and sometimes page table lock held */
- void (*swap_slot_free_notify) (struct block_device *, unsigned long);
+ int (*swap_hint)(struct block_device *, unsigned int, void *);
struct module *owner;
};
diff --git a/mm/page_io.c b/mm/page_io.c
index 955db8b0d497..88a13d74c621 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -114,7 +114,7 @@ void end_swap_bio_read(struct bio *bio, int err)
* we again wish to reclaim it.
*/
struct gendisk *disk = sis->bdev->bd_disk;
- if (disk->fops->swap_slot_free_notify) {
+ if (disk->fops->swap_hint) {
swp_entry_t entry;
unsigned long offset;
@@ -122,8 +122,9 @@ void end_swap_bio_read(struct bio *bio, int err)
offset = swp_offset(entry);
SetPageDirty(page);
- disk->fops->swap_slot_free_notify(sis->bdev,
- offset);
+ disk->fops->swap_hint(sis->bdev,
+ SWAP_SLOT_FREE,
+
[RFC 0/3] make vm aware of zram-swap
VM uses nr_swap_pages as one of information when it reclaims anonymous page because nr_swap_pages means how many freeable space in swap so VM is able to throttle swap out if it found there is no more space in swap. But for zram-swap, there is size gap between virtual disksize and physical memory to be able to store compressed memory so nr_swap_pages is not correct parameter to throttle swap. It causes endless anonymous reclaim(ie, swapout) even if there is no free space in zram-swap so it makes system unresponsive. This patch adds new hint SWAP_GET_FREE so zram can return how many of freeable space to VM. With using that, VM can know whether zram is full and substract remained freeable space from nr_swap_pages to make it less than 0. IOW, from now on, VM sees there is no more space of zram so that it will stop anonymous reclaiming until swap_entry_free free a page which increases nr_swap_pages again. With this patch, user will see OOM when zram-swap is full instead of hang with no response. Minchan Kim (3): zram: generalize swap_slot_free_notify mm: add swap_get_free hint for zram zram: add swap_get_free hint Documentation/filesystems/Locking | 7 ++ drivers/block/zram/zram_drv.c | 36 +-- include/linux/blkdev.h| 8 -- mm/page_io.c | 7 +++--- mm/swapfile.c | 52 +++ 5 files changed, 93 insertions(+), 17 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/3] zram: add swap_get_free hint
This patch implement SWAP_GET_FREE handler in zram so that VM can
know how many zram has freeable space.
VM can use it to stop anonymous reclaiming once zram is full.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 88661d62e46a..8e22b20aa2db 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -951,6 +951,22 @@ static int zram_slot_free_notify(struct block_device *bdev,
return 0;
}
+static int zram_get_free_pages(struct block_device *bdev, long *free)
+{
+ struct zram *zram;
+ struct zram_meta *meta;
+
+ zram = bdev->bd_disk->private_data;
+ meta = zram->meta;
+
+ if (!zram->limit_pages)
+ return 1;
+
+ *free = zram->limit_pages - zs_get_total_pages(meta->mem_pool);
+
+ return 0;
+}
+
static int zram_swap_hint(struct block_device *bdev,
unsigned int hint, void *arg)
{
@@ -958,6 +974,8 @@ static int zram_swap_hint(struct block_device *bdev,
if (hint == SWAP_SLOT_FREE)
ret = zram_slot_free_notify(bdev, (unsigned long)arg);
+ else if (hint == SWAP_GET_FREE)
+ ret = zram_get_free_pages(bdev, arg);
return ret;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2] clockevents: re-calculate event when cpu enter idle
Below flow will have the redundant interrupts for broadcast timer:
1. Process A starts a hrtimer with 100ms timeout, then Process A will
wait on the waitqueue to sleep;
2. The CPU which Process A runs on will enter idle and call notify
CLOCK_EVT_NOTIFY_BROADCAST_ENTER, so the CPU will shutdown its local
and set broadcast timer's next event with delta for 100ms timeout;
3. After 70ms later, the CPU is waken up by other peripheral's interrupt
and Process A will be waken up as well; Process A will cancel the hrtimer
at this point, kernel will remove the timer event from the event queue
but it will not really disable broadcast timer;
4. So after 30ms later, the broadcast timer interrupt will be triggered
even though the timer has been cancelled by s/w in step 3.
To fix this issue, in theory cpu can check this situation when the cpu
enter and exit idle; So it can iterate the related idle cpus to calculate
the correct broadcast event value.
But with upper method, it has the side effect. Due the cpu enter and exit
idle state very frequently in short time, so can optimize to only calculate
the correct state only when the cpu join into broadcast timer and set the
next event after calculate a different event compare to previous time.
Signed-off-by: Leo Yan
---
kernel/time/tick-broadcast.c | 56 +---
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 64c5990..52f8879 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -324,6 +324,31 @@ unlock:
raw_spin_unlock(_broadcast_lock);
}
+static void tick_broadcast_oneshot_get_earlier_event(void)
+{
+ struct clock_event_device *bc;
+ struct tick_device *td;
+ ktime_t next_event;
+ int cpu, next_cpu = 0;
+
+ next_event.tv64 = KTIME_MAX;
+
+ /* iterate all expired events */
+ for_each_cpu(cpu, tick_broadcast_oneshot_mask) {
+
+ td = _cpu(tick_cpu_device, cpu);
+ if (td->evtdev->next_event.tv64 < next_event.tv64) {
+ next_event.tv64 = td->evtdev->next_event.tv64;
+ next_cpu = cpu;
+ }
+ }
+
+ bc = tick_broadcast_device.evtdev;
+ if (next_event.tv64 != KTIME_MAX &&
+ next_event.tv64 != bc->next_event.tv64)
+ tick_broadcast_set_event(bc, next_cpu, next_event, 0);
+}
+
/*
* Powerstate information: The system enters/leaves a state, where
* affected devices might stop
@@ -717,17 +742,32 @@ int tick_broadcast_oneshot_control(unsigned long reason)
if (!cpumask_test_and_set_cpu(cpu,
tick_broadcast_oneshot_mask)) {
WARN_ON_ONCE(cpumask_test_cpu(cpu,
tick_broadcast_pending_mask));
broadcast_shutdown_local(bc, dev);
+
+ /*
+* We only reprogram the broadcast timer if we did not
+* mark ourself in the force mask; If the current CPU
+* is in the force mask, then we are going to be woken
+* by the IPI right away.
+*/
+ if (cpumask_test_cpu(cpu, tick_broadcast_force_mask))
+ goto out;
+
/*
-* We only reprogram the broadcast timer if we
-* did not mark ourself in the force mask and
-* if the cpu local event is earlier than the
-* broadcast event. If the current CPU is in
-* the force mask, then we are going to be
-* woken by the IPI right away.
+* Reprogram the broadcast timer if the cpu local event
+* is earlier than the broadcast event;
*/
- if (!cpumask_test_cpu(cpu, tick_broadcast_force_mask) &&
- dev->next_event.tv64 < bc->next_event.tv64)
+ if (dev->next_event.tv64 < bc->next_event.tv64) {
tick_broadcast_set_event(bc, cpu,
dev->next_event, 1);
+ goto out;
+ }
+
+ /*
+* It's possible the cpu has cancelled the timer which
+* has set the broadcast event at last time, so
+* re-calculate the broadcast timer according to all
+* related cpus' expire events.
+*/
+ tick_broadcast_oneshot_get_earlier_event();
}
/*
* If the current CPU owns the hrtimer broadcast
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH] ftrace: The set_graph_function and set_graph_notrace file mode should be 0644 instead of 0444
Hi Chen,
On Wed, 3 Sep 2014 14:31:09 +0800, Chen LinX wrote:
> Signed-off-by: Chen LinX
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> kernel/trace/ftrace.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 5916a8e..00e7b9a 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -4406,10 +4406,10 @@ static __init int ftrace_init_dyn_debugfs(struct
> dentry *d_tracer)
> ftrace_create_filter_files(_ops, d_tracer);
>
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> - trace_create_file("set_graph_function", 0444, d_tracer,
> + trace_create_file("set_graph_function", 0644, d_tracer,
> NULL,
> _graph_fops);
> - trace_create_file("set_graph_notrace", 0444, d_tracer,
> + trace_create_file("set_graph_notrace", 0644, d_tracer,
> NULL,
> _graph_notrace_fops);
> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
--
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: [SMP BUG?] the return value of is_smp() is bug?
On 2014/9/1 18:26, Arnd Bergmann wrote: > On Monday 01 September 2014 18:00:58 long.wanglong wrote: >> On 2014/9/1 13:49, Wang Long wrote: >>> >>> Hi,all >>> >>> In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y >>> in .config file. the secondary core can not boot. >>> >>> when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file, >>> the secondary core can boot. >>> >>> But this does not happen in kernel 3.10 lts kernel, Whether the >>> CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot. >>> >>> Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel >>> 3.17-rc2 ? >>> >>> >> >> hi Arnd >> >> In above two cases, i also set CONFIG_SMP = y. in addtion, >> the CONFIG_SMP_ON_UP depends on CONFIG_SMP. when set >> CONFIG_SMP_ON_UP = y, the value of CONFIG_SMP must be y. > > I see. > > I'm looking at the code more closely now: > >>> config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y >>> command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel >>> arch/arm/boot/zImage -nographic >>> The output: >>> >>> .. >>> is_smp() return false; > > This test basically checks whether the __fixup_smp_on_up code was > run or not. This has changed in bc41b8724f24 "ARM: 7846/1: Update > SMP_ON_UP code to detect A9MPCore with 1 CPU devices", in order > to support a quirk in the Aegis platform. Can you try reverting > that commit? > > Arnd > > . > Hi Arnd When i revert the commit bc41b8724f24, the secondary core can boot. The problem is that qemu doesn't provide emulation of the SCU base address register. When reading the SCU base, qemu just return 0. In the real hardware, there is no this problem. -- 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 v9 3/3] regulator: RK808: Remove pdata from the regulator
Signed-off-by: Chris Zhong
Tested-by: Heiko Stuebner
---
Changes in v9:
Adviced by Doug
- add reg_np
Changes in v8:
Adviced by Doug
- remove rk808_regulator_dts() function
- remove the check about "client->dev.of_node"
Changes in v7:
- remove pdata struct from header file, add rk808_regulator struct
Changes in v6:
- remove the redundant code
Changes in v5:
- re-edit base on Mark's branch
Changes in v4:
- use >dev replace rk808->dev
Changes in v3: None
Changes in v2:
Adviced by Mark Browm:
- change of_find_node_by_name to find_child_by_name
- use RK808_NUM_REGULATORS as the name of the constant
- create a pdata when missing platform data
- use the rk808_reg name to supply_regulator name
- replace regulator_register with devm_regulator_register
- some other problem with coding style
drivers/regulator/rk808-regulator.c | 91 +++
1 file changed, 18 insertions(+), 73 deletions(-)
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
index e372008..0d5afc4 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -3,8 +3,8 @@
*
* Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
*
- * Author: Chris Zhong
- * Author: Zhang Qing
+ * Author: Chris Zhong
+ * Author: Zhang Qing
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -14,24 +14,16 @@
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
- *
*/
#include
-#include
#include
-#include
-#include
#include
-#include
#include
#include
#include
-#include
-#include
-/*
- * Field Definitions.
- */
+
+/* Field Definitions */
#define RK808_BUCK_VSEL_MASK 0x3f
#define RK808_BUCK4_VSEL_MASK 0xf
#define RK808_LDO_VSEL_MASK0x1f
@@ -50,10 +42,6 @@ static const int buck_contr_base_addr[] = {
RK808_BUCK4_CONFIG_REG,
};
-#define rk808_BUCK_SET_VOL_REG(x) (buck_set_vol_base_addr[x])
-#define rk808_BUCK_CONTR_REG(x) (buck_contr_base_addr[x])
-#define rk808_LDO_SET_VOL_REG(x) (ldo_set_vol_base_addr[x])
-
static const int ldo_set_vol_base_addr[] = {
RK808_LDO1_ON_VSEL_REG,
RK808_LDO2_ON_VSEL_REG,
@@ -65,9 +53,7 @@ static const int ldo_set_vol_base_addr[] = {
RK808_LDO8_ON_VSEL_REG,
};
-/*
- * rk808 voltage number
- */
+/* rk808 voltage number */
static const struct regulator_linear_range rk808_buck_voltage_ranges[] = {
REGULATOR_LINEAR_RANGE(70, 0, 63, 12500),
};
@@ -308,77 +294,35 @@ static struct of_regulator_match rk808_reg_matches[] = {
[RK808_ID_SWITCH2] = { .name = "SWITCH_REG2" },
};
-static int rk808_regulator_dts(struct i2c_client *client,
- struct rk808_board *pdata)
-{
- struct device_node *np, *reg_np;
- int i, ret;
-
- np = client->dev.of_node;
- if (!np) {
- dev_err(>dev, "could not find pmic sub-node\n");
- return -ENXIO;
- }
-
- reg_np = of_get_child_by_name(np, "regulators");
- if (!reg_np)
- return -ENXIO;
-
- ret = of_regulator_match(>dev, reg_np, rk808_reg_matches,
-RK808_NUM_REGULATORS);
- if (ret < 0) {
- dev_err(>dev,
- "failed to parse regulator data: %d\n", ret);
- return ret;
- }
-
- for (i = 0; i < RK808_NUM_REGULATORS; i++) {
- if (!rk808_reg_matches[i].init_data ||
- !rk808_reg_matches[i].of_node)
- continue;
-
- pdata->rk808_init_data[i] = rk808_reg_matches[i].init_data;
- pdata->of_node[i] = rk808_reg_matches[i].of_node;
- }
-
- return 0;
-}
-
static int rk808_regulator_probe(struct platform_device *pdev)
{
struct rk808 *rk808 = dev_get_drvdata(pdev->dev.parent);
struct i2c_client *client = rk808->i2c;
- struct rk808_board *pdata = dev_get_platdata(>dev);
+ struct device_node *reg_np;
struct regulator_config config = {};
struct regulator_dev *rk808_rdev;
- struct regulator_init_data *reg_data;
- int i = 0;
- int ret = 0;
+ int ret, i;
- if (!pdata) {
- pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata)
- return -ENOMEM;
- }
+ reg_np = of_get_child_by_name(client->dev.of_node, "regulators");
+ if (!reg_np)
+ return -ENXIO;
- ret = rk808_regulator_dts(client, pdata);
- if (ret)
+ ret = of_regulator_match(>dev, reg_np, rk808_reg_matches,
+RK808_NUM_REGULATORS);
+ if (ret < 0)
return ret;
/* Instantiate the regulators */
for (i = 0; i <
Re: [PATCH] eeepc-laptop: remove possible use of uninitialized value
On Wed, Sep 03, 2014 at 05:49:47PM -0700, Darren Hart wrote:
> On Thu, Sep 04, 2014 at 12:53:25AM +0200, Frans Klaver wrote:
> > In store_sys_acpi, if count equals zero, or parse_arg()s sscanf call
> > fails, 'value' remains possibly uninitialized. In that case 'value'
> > shouldn't be used to produce the store_sys_acpi()s return value.
> >
> > Only test the return value of set_acpi() if we can actually call it.
> > Return rv otherwise.
> >
> > Signed-off-by: Frans Klaver
> > ---
> > drivers/platform/x86/eeepc-laptop.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/platform/x86/eeepc-laptop.c
> > b/drivers/platform/x86/eeepc-laptop.c
> > index bd533c2..41f12ba 100644
> > --- a/drivers/platform/x86/eeepc-laptop.c
> > +++ b/drivers/platform/x86/eeepc-laptop.c
> > @@ -279,10 +279,10 @@ static ssize_t store_sys_acpi(struct device *dev, int
> > cm,
> > int rv, value;
> >
> > rv = parse_arg(buf, count, );
> > - if (rv > 0)
> > - value = set_acpi(eeepc, cm, value);
>
> That was rather horrible wasn't it? :-)
>
> > - if (value < 0)
> > - return -EIO;
> > + if (rv > 0) {
> > + if (set_acpi(eeepc, cm, value) < 0)
> > + return -EIO;
>
> Is there a compelling reason not to propogate the return code of set_acpi?
> (ENODEV specifically). I see -EIO in Documentation/filesystems/sysfs.txt, but
> it's used by default if the show() pointer is NULL (for example), but
> otherwise
> propogates the error.
>
> Specifically it states:
>
> - show() or store() can always return errors. If a bad value comes
> through, be sure to return an error.
>
> Greg, does this need to be -EIO? or is returning someting like ENODEV
> preferable
> if it more accurately reflects the error?
Just return the value of set_acpi() and you should be fine.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 2/3] clk: RK808: Add clkout driver for RK808
Signed-off-by: Chris Zhong
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
Tested-by: Heiko Stuebner
---
Changes in v9: None
Changes in v8:
Adviced by Mike
-rename "control" to "enable"
-define RK808_NR_OUTPUT 2
Changes in v7:
Adviced by doug
-fix coding style problems
Changes in v6:
Adviced by doug
- use correct argument call of_clk_add_provider in probe
Changes in v5:
Adviced by doug
- add some error checking in probe
- move "rockchip,rk808.h" into the patch about dt-bindings
Changes in v4:
Adviced by doug
- add "clock-output-names" propertiey
- add a header file "rockchip,rk808.h"
Changes in v3:
- fix compile err
Changes in v2:
Adviced by javier.martinez
- separated from rtc-rk808.c
drivers/clk/Kconfig |9 +++
drivers/clk/Makefile|1 +
drivers/clk/clk-rk808.c | 164 +++
3 files changed, 174 insertions(+)
create mode 100644 drivers/clk/clk-rk808.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index cfd3af7..84e0590 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -38,6 +38,15 @@ config COMMON_CLK_MAX77686
---help---
This driver supports Maxim 77686 crystal oscillator clock.
+config COMMON_CLK_RK808
+ tristate "Clock driver for RK808"
+ depends on MFD_RK808
+ ---help---
+ This driver supports RK808 crystal oscillator clock. These
+ multi-function devices have two fixed-rate oscillators,
+ clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
+ by control register.
+
config COMMON_CLK_SI5351
tristate "Clock driver for SiLabs 5351A/B/C"
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..99f53d5 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
diff --git a/drivers/clk/clk-rk808.c b/drivers/clk/clk-rk808.c
new file mode 100644
index 000..8981346
--- /dev/null
+++ b/drivers/clk/clk-rk808.c
@@ -0,0 +1,164 @@
+/*
+ * Clkout driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author:Chris Zhong
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RK808_NR_OUTPUT 2
+
+struct rk808_clkout {
+ struct rk808 *rk808;
+ struct clk_onecell_data clk_data;
+ struct clk_hw clkout1_hw;
+ struct clk_hw clkout2_hw;
+};
+
+static unsigned long rk808_clkout_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ return 32768;
+}
+
+static int rk808_clkout1_is_prepared(struct clk_hw *hw)
+{
+ return 1;
+}
+
+static int rk808_clkout2_enable(struct clk_hw *hw, bool enable)
+{
+ struct rk808_clkout *rk808_clkout = container_of(hw,
+struct rk808_clkout,
+clkout2_hw);
+ struct rk808 *rk808 = rk808_clkout->rk808;
+
+ return regmap_update_bits(rk808->regmap, RK808_CLK32OUT_REG,
+ CLK32KOUT2_EN, enable ? CLK32KOUT2_EN : 0);
+}
+
+static int rk808_clkout2_prepare(struct clk_hw *hw)
+{
+ return rk808_clkout2_enable(hw, true);
+}
+
+static void rk808_clkout2_unprepare(struct clk_hw *hw)
+{
+ rk808_clkout2_enable(hw, false);
+}
+
+static int rk808_clkout2_is_prepared(struct clk_hw *hw)
+{
+ struct rk808_clkout *rk808_clkout = container_of(hw,
+struct rk808_clkout,
+clkout2_hw);
+ struct rk808 *rk808 = rk808_clkout->rk808;
+ uint32_t val;
+
+ int ret = regmap_read(rk808->regmap, RK808_CLK32OUT_REG, );
+
+ if (ret < 0)
+ return ret;
+
+ return (val & CLK32KOUT2_EN) ? 1 : 0;
+}
+
+static const struct clk_ops rk808_clkout1_ops = {
+ .is_prepared = rk808_clkout1_is_prepared,
+ .recalc_rate = rk808_clkout_recalc_rate,
+};
+
+static const
[PATCH v9 0/3] Add rockchip RK808 pmic driver
This is the initial version of the RK808 PMIC. This is a power management IC for multimedia products. It provides regulators that are able to supply power to processor cores and other components. The chip provides other modules including RTC, Clockout Changes in v9: Adviced by Dmitry - if(rk808_rtc->irq < 0), return rk808_rtc->irq Adviced by Doug - add reg_np Changes in v8: Adviced by Doug - coding style - fix regmap_update_bits() - if(rk808_rtc->irq < 0) return err num Adviced by Mike -rename "control" to "enable" -define RK808_NR_OUTPUT 2 Adviced by Doug - remove rk808_regulator_dts() function - remove the check about "client->dev.of_node" Changes in v7: Adviced by doug - read rtc time from shadowed registers Adviced by Dmitry - use CONFIG_PM_SLEEP replace CONFIG_PM - use SIMPLE_DEV_PM_OPS replace dev_pm_ops - fix dev_warn - coding style Adviced by Heiko - remove rtc_ctl Adviced by doug -fix coding style problems - remove pdata struct from header file, add rk808_regulator struct Changes in v6: Adviced by doug - move RTC_READSEL setting into probe Adviced by doug - use correct argument call of_clk_add_provider in probe - remove the redundant code Changes in v5: - fixed a bug about set_time failed Adviced by doug - add some error checking in probe - move "rockchip,rk808.h" into the patch about dt-bindings - re-edit base on Mark's branch Changes in v4: - use >dev replace rk808->dev Adviced by doug - add "clock-output-names" propertiey - add a header file "rockchip,rk808.h" - use >dev replace rk808->dev Changes in v3: - fix compile err Changes in v2: Adviced by javier.martinez - Add a separate clock driver, rather than in RTC driver Adviced by javier.martinez - separated from rtc-rk808.c Adviced by Mark Browm: - change of_find_node_by_name to find_child_by_name - use RK808_NUM_REGULATORS as the name of the constant - create a pdata when missing platform data - use the rk808_reg name to supply_regulator name - replace regulator_register with devm_regulator_register - some other problem with coding style Chris Zhong (3): RTC: RK808: add RTC driver for RK808 clk: RK808: Add clkout driver for RK808 regulator: RK808: Remove pdata from the regulator drivers/clk/Kconfig |9 + drivers/clk/Makefile|1 + drivers/clk/clk-rk808.c | 164 ++ drivers/regulator/rk808-regulator.c | 91 ++-- drivers/rtc/Kconfig | 10 + drivers/rtc/Makefile|1 + drivers/rtc/rtc-rk808.c | 426 +++ 7 files changed, 629 insertions(+), 73 deletions(-) create mode 100644 drivers/clk/clk-rk808.c create mode 100644 drivers/rtc/rtc-rk808.c -- 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 4/6] mm/hugetlb: add migration entry check in hugetlb_change_protection
On Thu, 28 Aug 2014, Naoya Horiguchi wrote:
> There is a race condition between hugepage migration and change_protection(),
> where hugetlb_change_protection() doesn't care about migration entries and
> wrongly overwrites them. That causes unexpected results like kernel crash.
>
> This patch adds is_hugetlb_entry_(migration|hwpoisoned) check in this
> function to do proper actions.
>
> ChangeLog v3:
> - handle migration entry correctly (instead of just skipping)
>
> Signed-off-by: Naoya Horiguchi
> Cc: # [2.6.36+]
2.6.36+? For the hwpoisoned part of it, I suppose.
Then you'd better mentioned the hwpoisoned case in the comment above.
> ---
> mm/hugetlb.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git mmotm-2014-08-25-16-52.orig/mm/hugetlb.c
> mmotm-2014-08-25-16-52/mm/hugetlb.c
> index 2aafe073cb06..1ed9df6def54 100644
> --- mmotm-2014-08-25-16-52.orig/mm/hugetlb.c
> +++ mmotm-2014-08-25-16-52/mm/hugetlb.c
> @@ -3362,7 +3362,26 @@ unsigned long hugetlb_change_protection(struct
> vm_area_struct *vma,
> spin_unlock(ptl);
> continue;
> }
> - if (!huge_pte_none(huge_ptep_get(ptep))) {
> + pte = huge_ptep_get(ptep);
> + if (unlikely(is_hugetlb_entry_hwpoisoned(pte))) {
> + spin_unlock(ptl);
> + continue;
> + }
> + if (unlikely(is_hugetlb_entry_migration(pte))) {
> + swp_entry_t entry = pte_to_swp_entry(pte);
> +
> + if (is_write_migration_entry(entry)) {
> + pte_t newpte;
> +
> + make_migration_entry_read();
> + newpte = swp_entry_to_pte(entry);
> + set_pte_at(mm, address, ptep, newpte);
set_huge_pte_at.
(As usual, I can't bear to see these is_hugetlb_entry_hwpoisoned and
is_hugetlb_entry_migration examples go past without bleating about
wanting to streamline them a little; but agreed last time to leave
that to some later cleanup once all the stable backports are stable.)
> + pages++;
> + }
> + spin_unlock(ptl);
> + continue;
> + }
> + if (!huge_pte_none(pte)) {
> pte = huge_ptep_get_and_clear(mm, address, ptep);
> pte = pte_mkhuge(huge_pte_modify(pte, newprot));
> pte = arch_make_huge_pte(pte, vma, NULL, 0);
> --
> 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/
[stable -3.14] PM backports for pm_test / CONFIG_PM_DEBUG
Hi, If I enable CONFIG_PM_DEBUG on a 3.14.y kernel, I can see the following results: # cat /sys/power/state freeze standby mem # cat /sys/power/pm_test [none] core processors platform devices freezer # echo core > /sys/power/pm_test # cat /sys/power/state [ 22.581289] Unsupported pm_test mode for freeze state, please choose none/freezer/devices/platform. standby mem Note how 'freeze' is dropped from the supported states, and I get an extra printk message when I'm just checking if the state is valid. It looks like if I backport a few fixes, I get more sane behavior, where the warnings (and -EAGAIN) appear only when I actually try to enter an unsupported test mode: # echo core > /sys/power/pm_test # cat /sys/power/state freeze standby mem # echo freeze > /sys/power/state [ 27.833141] PM: Unsupported test mode for freeze state,please choose none/freezer/devices/platform. sh: echo: write error: Resource temporarily unavailable I think I've narrowed it down to this commit that should be backported to -stable (for 3.9+?): 43e8317b0bba PM / sleep: Use valid_state() for platform-dependent sleep states only But it needs to drag along this dependency too: 27ddcc6596e5 PM / sleep: Add state field to pm_states[] entries While at this, it looks like this commit might be deserving of -stable (3.9+). I haven't tested this one, as I don't have a good freeze+cpuidle setup; it just shows up in the commit log with an interesting description and a 'Fixes' tag: f3f125324fc1 PM / suspend: Make cpuidle work in the "freeze" state Regards, Brian -- 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: [SMP BUG?] the return value of is_smp() is bug?
On 2014/9/1 18:19, Russell King - ARM Linux wrote: > Firstly, do not send multiple copies of your message to mailing lists, > certainly not within the three hours that you sent your three copies. > If one of the addresses you sent the message to bounces, then it is > *only* that one recipient who doesn't get your message, everyone else > receives a copy. So, there's now three copies of your message in the > list archives, and people could end up replying to different messages. > > On Mon, Sep 01, 2014 at 07:35:34PM +0800, Wang Long wrote: >> Hi,all >> >> In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y >> in .config file. the secondary core can not boot. >> >> when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file, >> the secondary core can boot. >> >> But this does not happen in kernel 3.10 lts kernel, Whether the >> CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot. >> >> Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel >> 3.17-rc2 ? > > I think the answer is neither, because when the kernel is run on /real/ > hardware: > > http://www.arm.linux.org.uk/developer/build/result.php?type=boot=2514 > > it boots fine, bringing up all four CPUs. > >> config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y >> command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel >> arch/arm/boot/zImage -nographic > > I've no idea how qemu works here, but if the CPU doesn't indicate that > it's a SMP capable CPU, we will disable SMP extensions. > >> The output: >> >> .. >> is_smp() return false; >> CPU: Testing write buffer coherency: ok >> missing device node for CPU 0 >> CPU0: thread -1, cpu 0, socket 0, mpidr 8000 >> Setting up static identity map for 0x604643d8 - 0x60464430 >> Brought up 1 CPUs >> SMP: Total of 1 processors activated. >> CPU: All CPU(s) started in SVC mode. >> ... > > You have decided that you'll edit the kernel messages, removing at least > some of the information that could be relevant to the issue. Please, > only cut kernel messages when you are absolutely certain that they are > not relevant to the problem you're reporting. > > However, I don't think it would help much - I suspect that qemu doesn't > provide emulation of the SCU base address register, and that's what your > problem is. qemu needs to be fixed in that regard. > Hi,Russell King Thank you for your reply. I will not send multiple copies of message to mailing lists. The problem is that qemu doesn't provide emulation of the SCU base address register. -- 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 v4 2/4] dt-bindings: document Rockchip thermal
在 2014年09月03日 16:07, Heiko Stübner 写道:
Am Mittwoch, 3. September 2014, 10:10:37 schrieb Caesar Wang:
This add the necessary binding documentation for the thermal
found on Rockchip SoCs
Signed-off-by: zhaoyifeng
Signed-off-by: Caesar Wang
---
.../devicetree/bindings/thermal/rockchip-thermal.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt new file
mode 100644
index 000..1ed4d4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,20 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible: "rockchip,rk3288-tsadc"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: The interrupt number to the cpu. The interrupt specifier
format + depends on the interrupt controller.
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+ the peripheral clock.
You're using the passive-temp, critical-temp and force-shut-temp properties in
your driver without declaring them here.
frankly,the about are need be declared. but there are 4 types[0] for
trip in thermal framework,
there is no force-shut for me. So I want to change it three additional
properties in [PATCH V4 4/4],
[0]
{
THERMAL_TRIP_CRITICAL,
THERMAL_TRIP_HOT,
THERMAL_TRIP_PASSIVE,
THERMAL_TRIP_ACTIVE,
}
But more importantly, please use the generic trip-points for this. I guess it
shouldn't be a problem to introduce a "forced-shutdown" trippoint [0] for the
additional trip-point you have - thermal maintainers, please shout if I'm
wrong :-)
It's a good option.
I can send a patch,but I don't know whether the thermal maintainers will
accept it.
Maybe,they have a better way to suggest it.:-)
PS:I will sent a new patch If I still have no received their suggestions
in two days.
Heiko
[0] in a separate patch, changing
- thermal_trip_type enum in include/linux/thermal.h
- trip_types mapping in drivers/thermal/of-thermal.c
- Documentation/devicetree/bindings/thermal/thermal.txt
+
+Example:
+tsadc: tsadc@ff28 {
+ compatible = "rockchip,rk3288-tsadc";
+ reg = <0xff28 0x100>;
+ interrupts = ;
+ clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+};
--
Best regards,
Caesar
--
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] clk: Use ww_mutexes for clk_prepare_{lock/unlock}
Changing the rate of a "slow" clock can take 10s of milliseconds
while changing the rate of a "fast" clock can be done in a few
microseconds. With one prepare mutex a task that's trying to
change the rate of a fast clock may have to wait for a slow
clock's rate to change before it can proceed. Consider the case
of a GPU driver which wants to scale up the GPU speed before
drawing a frame that gets stuck behind a PLL being reprogrammed.
In this case the thread performing the drawing may have to wait
for 10s of milliseconds while the PLL stabilizes. At 60 FPS
waiting for more than 16ms to grab the prepare mutex can lead to
missed frame updates and visible artifacts.
Furthermore, the recursive prepare mutex suffers from a deadlock
when a clock, say clock S, is controlled by a chip sitting on the
SPI bus and we need to enable the SPI master controller's clock
to send a message to enable clock S. The SPI core will use a
different thread to enable the SPI controller's clock causing the
recursion detection mechanism to fail.
Remedy these problems by introducing a per-clock wound/wait mutex
to replace the global prepare mutex. This should allow discreet
parts of the clock tree to change rates and prepare/unprepare in
parallel with each-other. Unfortunately we lose the recursive
feature of the prepare mutex with this change and lockdep
complains if the same thread tries to call any clk_* operations
from within a clock op even if that thread is only acquiring new
locks that aren't already held.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 525 +---
include/linux/clk-private.h | 3 +
2 files changed, 445 insertions(+), 83 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index d2da11674f0b..9c911dc1464a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,18 +21,18 @@
#include
#include
#include
+#include
#include "clk.h"
static DEFINE_SPINLOCK(enable_lock);
-static DEFINE_MUTEX(prepare_lock);
+static DEFINE_WW_CLASS(prepare_ww_class);
-static struct task_struct *prepare_owner;
static struct task_struct *enable_owner;
-
-static int prepare_refcnt;
static int enable_refcnt;
+static DEFINE_MUTEX(clk_list_lock);
+static DEFINE_MUTEX(clk_notifier_lock);
static DEFINE_MUTEX(clk_lookup_lock);
static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
@@ -40,30 +40,236 @@ static HLIST_HEAD(clk_lookup_list);
static LIST_HEAD(clk_notifier_list);
/*** locking ***/
-static void clk_prepare_lock(void)
+static void __clk_unlock(struct list_head *list)
+{
+ struct clk *entry, *temp;
+
+ list_for_each_entry_safe (entry, temp, list, ww_list) {
+ list_del_init(>ww_list);
+ ww_mutex_unlock(>lock);
+ }
+}
+
+static void clk_unlock(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ __clk_unlock(list);
+ ww_acquire_fini(ctx);
+}
+
+static int clk_lock_one(struct clk *clk, struct list_head *list,
+ struct ww_acquire_ctx *ctx)
+{
+ int ret;
+
+ if (!clk)
+ return 0;
+
+ ret = ww_mutex_lock(>lock, ctx);
+ if (ret == -EDEADLK) {
+ __clk_unlock(list);
+ ww_mutex_lock_slow(>lock, ctx);
+ list_add(>ww_list, list);
+ } else if (ret != -EALREADY) {
+ list_add_tail(>ww_list, list);
+ }
+
+ return ret;
+}
+
+
+static int __clk_lock_subtree(struct clk *clk, struct list_head *list,
+struct ww_acquire_ctx *ctx)
+{
+ int ret;
+ struct clk *child;
+
+ lockdep_assert_held(>lock.base);
+
+ hlist_for_each_entry(child, >children, child_node) {
+ ret = clk_lock_one(child, list, ctx);
+ if (ret == -EDEADLK)
+ return ret;
+ ret = __clk_lock_subtree(child, list, ctx);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void clk_lock_subtree(struct clk *clk, struct list_head *list,
+struct ww_acquire_ctx *ctx)
+{
+ int ret;
+
+ do {
+ ret = clk_lock_one(clk, list, ctx);
+ if (ret == -EDEADLK)
+ continue;
+ ret = __clk_lock_subtree(clk, list, ctx);
+ } while (ret == -EDEADLK);
+}
+
+/* Lock a clock, it's parent (and optionally a new parent),
+ * and all it's descendents
+ */
+static void clk_parent_lock(struct clk *clk, struct clk *new_parent,
+ struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ int ret;
+
+ ww_acquire_init(ctx, _ww_class);
+
+ do {
+ ret = clk_lock_one(clk, list, ctx);
+ if (ret == -EDEADLK)
+ continue;
+ ret = clk_lock_one(clk->parent, list, ctx);
+ if (ret == -EDEADLK)
+ continue;
+
[PATCH v2 0/4] Use wound/wait mutexes in the common clock framework
The prepare mutex in the common clock framework can lead to tasks waiting a
long time for other tasks to finish a frequency switch or prepare/unprepare
step. In my particular case I have a clock controlled by a co-processor that
can take 10s of milliseconds to change rate. I've seen scenarios where it can
take more than 20ms for another thread to acquire the prepare mutex because
it's waiting on the co-processor to finish changing the rate. Pair this with a
display driver that wants to scale it's clock up before drawing a frame and you
may start dropping frames at 60FPS (one frame is budgeted 16ms).
Similar scenarios exist like CPUfreq scaling getting blocked for large amounts
of time when different CPUs scale independently of each other. Ideally
these CPUs wouldn't need to be ordered with respect to each other, but
the prepare_mutex forces a synchronization, leading to longer frequency
switching times and worse performance.
This patchset attempts to remedy these problems by introducing a per-clock
wwmutex. This allows multiple threads to be traversing and updating the tree at
the same time granted they don't touch the same subtree. In my testcase
this removes the contention on the prepare mutex and allows the display
driver to scale the clock up and down in parallel with CPUfreq, etc.
There is a drawback though: we lose the recursive mutex property. I don't have
a good solution for this besides "don't do that". I worry we actually have
use-cases for such a thing? Technically a thread recursing into the clock
framework probably wouldn't be acquiring the same locks (and even if it was we
could recognize that this is the same thread acquiring it again) but due to the
way wound/wait mutexes work we may need to release all locks and try again the
second time we're in the clock framework and that sounds really annoying to
handle. We'd need to have some list of threads and acquire contexts and then we
would need to rely on drivers returning -EDEADLK through the ops, etc. At least
lockdep will complain loudly when you try this so it isn't a silent failure,
but I admit this is a limitation.
Due to the loss of recursion we can't allow clock drivers to call the
non-underscore versions of the clock APIs. I don't see too many users
right now under drivers/clk but those would need to be updated before these
patches could be applied.
This is based on clk-next as of commit 16eeaec77922 "clk: at91: fix div by zero
in USB clock driver".
Changes since v1:
* Rebased onto clk-next
Stephen Boyd (4):
clk: Recalc rate and accuracy in underscore functions if not caching
clk: Make __clk_lookup() use a list instead of tree search
clk: Use lockless functions for debug printing
clk: Use ww_mutexes for clk_prepare_{lock/unlock}
drivers/clk/clk.c | 598 +++-
include/linux/clk-private.h | 4 +
2 files changed, 478 insertions(+), 124 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] clk: Use lockless functions for debug printing
In the near future we're going to move the prepare lock to a
per-clock ww_mutex. Use the lockless functions here for printing
the rate and accuracy so that we don't run into AA deadlocks in
the future.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 248a8612a12d..d2da11674f0b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -122,8 +122,8 @@ static void clk_summary_show_one(struct seq_file *s, struct
clk *c, int level)
seq_printf(s, "%*s%-*s %11d %12d %11lu %10lu\n",
level * 3 + 1, "",
30 - level * 3, c->name,
- c->enable_count, c->prepare_count, clk_get_rate(c),
- clk_get_accuracy(c));
+ c->enable_count, c->prepare_count, __clk_get_rate(c),
+ __clk_get_accuracy(c));
}
static void clk_summary_show_subtree(struct seq_file *s, struct clk *c,
@@ -180,8 +180,8 @@ static void clk_dump_one(struct seq_file *s, struct clk *c,
int level)
seq_printf(s, "\"%s\": { ", c->name);
seq_printf(s, "\"enable_count\": %d,", c->enable_count);
seq_printf(s, "\"prepare_count\": %d,", c->prepare_count);
- seq_printf(s, "\"rate\": %lu", clk_get_rate(c));
- seq_printf(s, "\"accuracy\": %lu", clk_get_accuracy(c));
+ seq_printf(s, "\"rate\": %lu", __clk_get_rate(c));
+ seq_printf(s, "\"accuracy\": %lu", __clk_get_accuracy(c));
}
static void clk_dump_subtree(struct seq_file *s, struct clk *c, int level)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] clk: Recalc rate and accuracy in underscore functions if not caching
When we move this code to use ww_mutex we'll need to call
__clk_get_rate() and __clk_get_accuracy(), instead of their
non-underscore counterparts, while holding the clock's prepare
mutex. Move the recalculation of these values into the underscore
functions so that we can call __clk_get_rate() and
__clk_get_accuracy() while holding locks.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b76fa69b44cb..1feaf708aa49 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -591,6 +591,8 @@ unsigned int __clk_get_prepare_count(struct clk *clk)
return !clk ? 0 : clk->prepare_count;
}
+static void __clk_recalc_rates(struct clk *clk, unsigned long msg);
+
unsigned long __clk_get_rate(struct clk *clk)
{
unsigned long ret;
@@ -600,6 +602,9 @@ unsigned long __clk_get_rate(struct clk *clk)
goto out;
}
+ if (clk->flags & CLK_GET_RATE_NOCACHE)
+ __clk_recalc_rates(clk, 0);
+
ret = clk->rate;
if (clk->flags & CLK_IS_ROOT)
@@ -613,11 +618,16 @@ out:
}
EXPORT_SYMBOL_GPL(__clk_get_rate);
+static void __clk_recalc_accuracies(struct clk *clk);
+
unsigned long __clk_get_accuracy(struct clk *clk)
{
if (!clk)
return 0;
+ if (clk->flags & CLK_GET_ACCURACY_NOCACHE)
+ __clk_recalc_accuracies(clk);
+
return clk->accuracy;
}
@@ -1083,9 +1093,6 @@ long clk_get_accuracy(struct clk *clk)
unsigned long accuracy;
clk_prepare_lock();
- if (clk && (clk->flags & CLK_GET_ACCURACY_NOCACHE))
- __clk_recalc_accuracies(clk);
-
accuracy = __clk_get_accuracy(clk);
clk_prepare_unlock();
@@ -1151,10 +1158,6 @@ unsigned long clk_get_rate(struct clk *clk)
unsigned long rate;
clk_prepare_lock();
-
- if (clk && (clk->flags & CLK_GET_RATE_NOCACHE))
- __clk_recalc_rates(clk, 0);
-
rate = __clk_get_rate(clk);
clk_prepare_unlock();
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] clk: Make __clk_lookup() use a list instead of tree search
In the near future we're going to move the prepare lock to be a
per-clock ww_mutex. __clk_lookup() is called very deep in the
set-rate path and we would like to avoid having to take all the
locks in the clock tree to search for a clock (basically
defeating the purpose of introducing per-clock locks). Introduce
a new list that contains all clocks registered in the system and
walk this list until the clock is found.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 52 +
include/linux/clk-private.h | 1 +
2 files changed, 21 insertions(+), 32 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 1feaf708aa49..248a8612a12d 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -33,8 +33,10 @@ static struct task_struct *enable_owner;
static int prepare_refcnt;
static int enable_refcnt;
+static DEFINE_MUTEX(clk_lookup_lock);
static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
+static HLIST_HEAD(clk_lookup_list);
static LIST_HEAD(clk_notifier_list);
/*** locking ***/
@@ -680,46 +682,23 @@ out:
}
EXPORT_SYMBOL_GPL(__clk_is_enabled);
-static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
-{
- struct clk *child;
- struct clk *ret;
-
- if (!strcmp(clk->name, name))
- return clk;
-
- hlist_for_each_entry(child, >children, child_node) {
- ret = __clk_lookup_subtree(name, child);
- if (ret)
- return ret;
- }
-
- return NULL;
-}
-
struct clk *__clk_lookup(const char *name)
{
- struct clk *root_clk;
- struct clk *ret;
+ struct clk *clk;
if (!name)
return NULL;
- /* search the 'proper' clk tree first */
- hlist_for_each_entry(root_clk, _root_list, child_node) {
- ret = __clk_lookup_subtree(name, root_clk);
- if (ret)
- return ret;
+ mutex_lock(_lookup_lock);
+ hlist_for_each_entry(clk, _lookup_list, lookup_node) {
+ if (!strcmp(clk->name, name))
+ goto found;
}
+ clk = NULL;
+found:
+ mutex_unlock(_lookup_lock);
- /* if not found, then search the orphan tree */
- hlist_for_each_entry(root_clk, _orphan_list, child_node) {
- ret = __clk_lookup_subtree(name, root_clk);
- if (ret)
- return ret;
- }
-
- return NULL;
+ return clk;
}
/*
@@ -1826,6 +1805,11 @@ int __clk_init(struct device *dev, struct clk *clk)
clk->parent = __clk_init_parent(clk);
+ /* Insert into clock lookup list */
+ mutex_lock(_lookup_lock);
+ hlist_add_head(>lookup_node, _lookup_list);
+ mutex_unlock(_lookup_lock);
+
/*
* Populate clk->parent if parent has already been __clk_init'd. If
* parent has not yet been __clk_init'd then place clk in the orphan
@@ -2120,6 +2104,10 @@ void clk_unregister(struct clk *clk)
hlist_del_init(>child_node);
+ mutex_lock(_lookup_lock);
+ hlist_del_init(>lookup_node);
+ mutex_unlock(_lookup_lock);
+
if (clk->prepare_count)
pr_warn("%s: unregistering prepared clock: %s\n",
__func__, clk->name);
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index efbf70b9fd84..3cd98a930006 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -48,6 +48,7 @@ struct clk {
unsigned long accuracy;
struct hlist_head children;
struct hlist_node child_node;
+ struct hlist_node lookup_node;
unsigned intnotifier_count;
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] aio: block exit_aio() until all context requests are completed
Hi Ben,
On 09/03/2014 10:43 PM, Benjamin LaHaise wrote:
> Hi Gu,
>
> On Wed, Sep 03, 2014 at 05:45:44PM +0800, Gu Zheng wrote:
>> It seems that exit_aio() also needs to wait for all iocbs to complete (like
>> io_destroy), but we missed the wait step in current implemention, so fix
>> it in the same way as we did in io_destroy.
>
> I actually already have another version of this patch queued up that
> checks the return value of kill_ioctx().
That's good, but I did not find it, have you sent it to the open list?
IMO, there's no need to check the return value of kill_ioctx(), because
context can be marked as DEAD only by io_destroy(), and io_destroy() is
on the block mode. So if we run into the calling of kill_ioctx() in
exit_aio, the context is surely valid.
Thanks,
Gu
>
> -ben
>
>> Signed-off-by: Gu Zheng
>> ---
>> fs/aio.c |7 ++-
>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 97bc62c..3e35b12 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -793,6 +793,8 @@ void exit_aio(struct mm_struct *mm)
>>
>> for (i = 0; i < table->nr; ++i) {
>> struct kioctx *ctx = table->table[i];
>> +struct completion requests_done =
>> +COMPLETION_INITIALIZER_ONSTACK(requests_done);
>>
>> if (!ctx)
>> continue;
>> @@ -804,7 +806,10 @@ void exit_aio(struct mm_struct *mm)
>> * that it needs to unmap the area, just set it to 0.
>> */
>> ctx->mmap_size = 0;
>> -kill_ioctx(mm, ctx, NULL);
>> +kill_ioctx(mm, ctx, _done);
>> +
>> +/* Wait until all IO for the context are done. */
>> +wait_for_completion(_done);
>> }
>>
>> RCU_INIT_POINTER(mm->ioctx_table, NULL);
>> --
>> 1.7.7
>
--
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] mmc: sdhci-esdhc-imx: Enable boot partition access from DT
Hi, Jean-Michel Some platforms which using Samsung exynos SoC, we write u-boot related bin files in boot partitions(in my case boot partition 1) to boot on eMMC. Some platforms which using Qualcomm SoC, written at logical address 0(User Data Area) and they use a-boot not u-boot. BTW, rpmb partition is not wide use now. As i know, some Intel platforms have use rpmb partition. Thanks, Hsinhsiang 2014-09-03 21:08 GMT+08:00 Jean-Michel Hautbois : > 2014-09-03 11:09 GMT+02:00 Ulf Hansson : >> On 3 September 2014 11:02, Adrian Hunter wrote: >>> On 09/03/2014 11:30 AM, Ulf Hansson wrote: On 2 September 2014 17:49, Jean-Michel Hautbois wrote: > This property is useful when we don't want to access boot partitions on > eMMC > > Signed-off-by: Jean-Michel Hautbois > --- > Documentation/devicetree/bindings/mmc/mmc.txt | 1 + > drivers/mmc/host/sdhci-esdhc-imx.c| 8 > include/linux/platform_data/mmc-esdhc-imx.h | 1 + > 3 files changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt > b/Documentation/devicetree/bindings/mmc/mmc.txt > index 431716e..59cc854 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc.txt > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > @@ -40,6 +40,7 @@ Optional properties: > - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported > - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported > - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported > +- no-boot-part : when preset, tells to access boot partitions > > *NOTE* on CD and WP polarity. To use common for all SD/MMC host > controllers line > polarity properties, we have to fix the meaning of the "normal" and > "inverted" > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c > b/drivers/mmc/host/sdhci-esdhc-imx.c > index ccec0e3..439e663 100644 > --- a/drivers/mmc/host/sdhci-esdhc-imx.c > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c > @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device > *pdev, > if (of_property_read_u32(np, "fsl,delay-line", > >delay_line)) > boarddata->delay_line = 0; > > + if (of_find_property(np, "no-boot-part", NULL)) > + boarddata->access_boot_part = false; > + else > + boarddata->access_boot_part = true; > + > return 0; > } > #else > @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct > platform_device *pdev) > host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; > } > > + if (!boarddata->access_boot_part) > + host->mmc->caps2 |= MMC_CAP2_BOOTPART_NOACC; > + Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding. Does it describe the hardware in some form? Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists at all. If there are cards that don't supports the BOOT area, shouldn't we have a card quirk for it instead of a host cap? Maybe Adrian Hunter, how originally wrote the patch for adding MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind it!? >>> >>> It was added because platform firmware was able to prevent access to the >>> boot partitions (for security I think), so attempts to access them would >>> fail messily. It was not related to any specific card. >> >> Adrian, appreciate your clarification. After all it seems like adding >> a DT binding for it should be appropriate. >> >> Kind regards >> Uffe > > Thanks Adrian :). > Well, there is boot partitions and rpmb partition, and maybe should we > have a binding to prevent access to both of them ? > Something else came to my mind, when you want to boot on eMMC, do you > need to write u-boot in boot partitions or is it written at the > logical adress 0 which is what fdisk uses as start ? > Because, if this is not usuable but just scanned I can't see why we > bother doing it... ? > > Thanks, > JM > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] V4L: uvcvideo: Add support for pan/tilt speed controls
Map V4L2_CID_TILT_SPEED and V4L2_CID_PAN_SPEED to the standard UVC
CT_PANTILT_RELATIVE_CONTROL terminal control request.
Tested by plugging a Logitech ConferenceCam C3000e USB camera
and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
Verified that it can pan and tilt at the same time in both directions.
Signed-off-by: Vincent Palatin
---
Changes from v1/v2:
- rebased
Changes from v3:
- removed gerrit-id
drivers/media/usb/uvc/uvc_ctrl.c | 58 +---
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 0eb82106..d703cb0 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -309,9 +309,8 @@ static struct uvc_control_info uvc_ctrls[] = {
.selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
.index = 12,
.size = 4,
- .flags = UVC_CTRL_FLAG_SET_CUR | UVC_CTRL_FLAG_GET_MIN
- | UVC_CTRL_FLAG_GET_MAX | UVC_CTRL_FLAG_GET_RES
- | UVC_CTRL_FLAG_GET_DEF
+ .flags = UVC_CTRL_FLAG_SET_CUR
+ | UVC_CTRL_FLAG_GET_RANGE
| UVC_CTRL_FLAG_AUTO_UPDATE,
},
{
@@ -391,6 +390,35 @@ static void uvc_ctrl_set_zoom(struct uvc_control_mapping
*mapping,
data[2] = min((int)abs(value), 0xff);
}
+static __s32 uvc_ctrl_get_rel_speed(struct uvc_control_mapping *mapping,
+ __u8 query, const __u8 *data)
+{
+ int first = mapping->offset / 8;
+ __s8 rel = (__s8)data[first];
+
+ switch (query) {
+ case UVC_GET_CUR:
+ return (rel == 0) ? 0 : (rel > 0 ? data[first+1]
+: -data[first+1]);
+ case UVC_GET_MIN:
+ return -data[first+1];
+ case UVC_GET_MAX:
+ case UVC_GET_RES:
+ case UVC_GET_DEF:
+ default:
+ return data[first+1];
+ }
+}
+
+static void uvc_ctrl_set_rel_speed(struct uvc_control_mapping *mapping,
+ __s32 value, __u8 *data)
+{
+ int first = mapping->offset / 8;
+
+ data[first] = value == 0 ? 0 : (value > 0) ? 1 : 0xff;
+ data[first+1] = min_t(int, abs(value), 0xff);
+}
+
static struct uvc_control_mapping uvc_ctrl_mappings[] = {
{
.id = V4L2_CID_BRIGHTNESS,
@@ -677,6 +705,30 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.data_type = UVC_CTRL_DATA_TYPE_SIGNED,
},
{
+ .id = V4L2_CID_PAN_SPEED,
+ .name = "Pan (Speed)",
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
+ .size = 16,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ .get= uvc_ctrl_get_rel_speed,
+ .set= uvc_ctrl_set_rel_speed,
+ },
+ {
+ .id = V4L2_CID_TILT_SPEED,
+ .name = "Tilt (Speed)",
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
+ .size = 16,
+ .offset = 16,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ .get= uvc_ctrl_get_rel_speed,
+ .set= uvc_ctrl_set_rel_speed,
+ },
+ {
.id = V4L2_CID_PRIVACY,
.name = "Privacy",
.entity = UVC_GUID_UVC_CAMERA,
--
2.1.0.rc2.206.gedb03e5
--
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 v9 5/6] clk: Add floor and ceiling constraints to clock rates
Quoting Stephen Boyd (2014-09-03 16:39:37)
> On 09/03/14 08:33, Tomeu Vizoso wrote:
> > +int clk_set_ceiling_rate(struct clk *clk_user, unsigned long rate)
> > +{
> > + struct clk_core *clk = clk_to_clk_core(clk_user);
> > +
> > + WARN(rate > 0 && rate < clk_user->floor_constraint,
> > + "clk %s dev %s con %s: new ceiling %lu lower than existing floor
> > %lu\n",
> > + __clk_get_name(clk), clk_user->dev_id, clk_user->con_id, rate,
> > + clk_user->floor_constraint);
> > +
> > + clk_user->ceiling_constraint = rate;
> > + return clk_provider_set_rate(clk, clk_provider_get_rate(clk));
> > +}
> > +EXPORT_SYMBOL_GPL(clk_set_ceiling_rate);
>
> Maybe I'm late to this patch series given that Mike applied it, but I
> wonder why we wouldn't just have one API that takes a min and a max,
> i.e. clk_set_rate_range(clk, min, max)? Then clk_set_rate() is a small
> wrapper on top that just sets min and max to the same value.
We certainly can have that. But being able to easily adjust a floor or
ceiling value seems like a good thing to me, and that is what these
functions do.
If we decide to have a clk_set_rate_range (where we perhaps pass zero in
for a value that we do not wish to constrain) then I imagine that
clk_set_ceiling_rate and clk_set_floor_rate will simply become a wrapper
for that function. No harm having it both ways. If one way of doing
things falls out of favor we can always cull it and update all the
users.
Regards,
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] eeepc-laptop: remove possible use of uninitialized value
On Thu, Sep 04, 2014 at 12:53:25AM +0200, Frans Klaver wrote:
> In store_sys_acpi, if count equals zero, or parse_arg()s sscanf call
> fails, 'value' remains possibly uninitialized. In that case 'value'
> shouldn't be used to produce the store_sys_acpi()s return value.
>
> Only test the return value of set_acpi() if we can actually call it.
> Return rv otherwise.
>
> Signed-off-by: Frans Klaver
> ---
> drivers/platform/x86/eeepc-laptop.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-laptop.c
> b/drivers/platform/x86/eeepc-laptop.c
> index bd533c2..41f12ba 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -279,10 +279,10 @@ static ssize_t store_sys_acpi(struct device *dev, int
> cm,
> int rv, value;
>
> rv = parse_arg(buf, count, );
> - if (rv > 0)
> - value = set_acpi(eeepc, cm, value);
That was rather horrible wasn't it? :-)
> - if (value < 0)
> - return -EIO;
> + if (rv > 0) {
> + if (set_acpi(eeepc, cm, value) < 0)
> + return -EIO;
Is there a compelling reason not to propogate the return code of set_acpi?
(ENODEV specifically). I see -EIO in Documentation/filesystems/sysfs.txt, but
it's used by default if the show() pointer is NULL (for example), but otherwise
propogates the error.
Specifically it states:
- show() or store() can always return errors. If a bad value comes
through, be sure to return an error.
Greg, does this need to be -EIO? or is returning someting like ENODEV preferable
if it more accurately reflects the error?
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] V4L: uvcvideo: Add support for pan/tilt speed controls
On Thu, Sep 4, 2014 at 4:40 AM, Vincent Palatin wrote:
> Map V4L2_CID_TILT_SPEED and V4L2_CID_PAN_SPEED to the standard UVC
> CT_PANTILT_RELATIVE_CONTROL terminal control request.
>
> Tested by plugging a Logitech ConferenceCam C3000e USB camera
> and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
> Verified that it can pan and tilt at the same time in both directions.
>
> Signed-off-by: Vincent Palatin
>
> Change-Id: I7b70b228e5c0126683f5f0be34ffd2807f5783dc
Sorry, forgot to mention this previously, please remove gerrit ids
from the patches.
Thanks,
P.
> ---
> Changes from v1/v2:
> - rebased
>
> drivers/media/usb/uvc/uvc_ctrl.c | 58
> +---
> 1 file changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 0eb82106..d703cb0 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -309,9 +309,8 @@ static struct uvc_control_info uvc_ctrls[] = {
> .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
> .index = 12,
> .size = 4,
> - .flags = UVC_CTRL_FLAG_SET_CUR |
> UVC_CTRL_FLAG_GET_MIN
> - | UVC_CTRL_FLAG_GET_MAX |
> UVC_CTRL_FLAG_GET_RES
> - | UVC_CTRL_FLAG_GET_DEF
> + .flags = UVC_CTRL_FLAG_SET_CUR
> + | UVC_CTRL_FLAG_GET_RANGE
> | UVC_CTRL_FLAG_AUTO_UPDATE,
> },
> {
> @@ -391,6 +390,35 @@ static void uvc_ctrl_set_zoom(struct uvc_control_mapping
> *mapping,
> data[2] = min((int)abs(value), 0xff);
> }
>
> +static __s32 uvc_ctrl_get_rel_speed(struct uvc_control_mapping *mapping,
> + __u8 query, const __u8 *data)
> +{
> + int first = mapping->offset / 8;
> + __s8 rel = (__s8)data[first];
> +
> + switch (query) {
> + case UVC_GET_CUR:
> + return (rel == 0) ? 0 : (rel > 0 ? data[first+1]
> +: -data[first+1]);
> + case UVC_GET_MIN:
> + return -data[first+1];
> + case UVC_GET_MAX:
> + case UVC_GET_RES:
> + case UVC_GET_DEF:
> + default:
> + return data[first+1];
> + }
> +}
> +
> +static void uvc_ctrl_set_rel_speed(struct uvc_control_mapping *mapping,
> + __s32 value, __u8 *data)
> +{
> + int first = mapping->offset / 8;
> +
> + data[first] = value == 0 ? 0 : (value > 0) ? 1 : 0xff;
> + data[first+1] = min_t(int, abs(value), 0xff);
> +}
> +
> static struct uvc_control_mapping uvc_ctrl_mappings[] = {
> {
> .id = V4L2_CID_BRIGHTNESS,
> @@ -677,6 +705,30 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
> .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> },
> {
> + .id = V4L2_CID_PAN_SPEED,
> + .name = "Pan (Speed)",
> + .entity = UVC_GUID_UVC_CAMERA,
> + .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
> + .size = 16,
> + .offset = 0,
> + .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
> + .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> + .get= uvc_ctrl_get_rel_speed,
> + .set= uvc_ctrl_set_rel_speed,
> + },
> + {
> + .id = V4L2_CID_TILT_SPEED,
> + .name = "Tilt (Speed)",
> + .entity = UVC_GUID_UVC_CAMERA,
> + .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
> + .size = 16,
> + .offset = 16,
> + .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
> + .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> + .get= uvc_ctrl_get_rel_speed,
> + .set= uvc_ctrl_set_rel_speed,
> + },
> + {
> .id = V4L2_CID_PRIVACY,
> .name = "Privacy",
> .entity = UVC_GUID_UVC_CAMERA,
> --
> 2.1.0.rc2.206.gedb03e5
>
--
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] trace: Resolve some missing-field-initializers warnings
From: Mark Rustad
Resolve some missing-field-initializers warnings by using a
more elaborated form of designated initialization.
Signed-off-by: Mark Rustad
Signed-off-by: Jeff Kirsher
---
kernel/trace/trace_export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
index d4ddde2..190bc09 100644
--- a/kernel/trace/trace_export.c
+++ b/kernel/trace/trace_export.c
@@ -177,7 +177,7 @@ struct ftrace_event_call __used event_##call = {
\
{ \
.name = #call,\
}, \
- .event.type = etype,\
+ .event = { .type= etype, }, \
.print_fmt = print,\
.flags = TRACE_EVENT_FL_IGNORE_ENABLE |
TRACE_EVENT_FL_USE_CALL_FILTER, \
}; \
--
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 v3 3/6] mm/hugetlb: fix getting refcount 0 page in hugetlb_fault()
On Thu, 28 Aug 2014, Naoya Horiguchi wrote:
> When running the test which causes the race as shown in the previous patch,
> we can hit the BUG "get_page() on refcount 0 page" in hugetlb_fault().
>
> This race happens when pte turns into migration entry just after the first
> check of is_hugetlb_entry_migration() in hugetlb_fault() passed with false.
> To fix this, we need to check pte_present() again with holding ptl.
>
> This patch also reorders taking ptl and doing pte_page(), because pte_page()
> should be done in ptl. Due to this reordering, we need use trylock_page()
> in page != pagecache_page case to respect locking order.
>
> ChangeLog v3:
> - doing pte_page() and taking refcount under page table lock
> - check pte_present after taking ptl, which makes it unnecessary to use
> get_page_unless_zero()
> - use trylock_page in page != pagecache_page case
> - fixed target stable version
ChangeLog vN below the --- (or am I contradicting some other advice?)
>
> Fixes: 66aebce747ea ("hugetlb: fix race condition in hugetlb_fault()")
> Signed-off-by: Naoya Horiguchi
> Cc: # [3.2+]
One bug, one warning, a couple of suboptimals...
> ---
> mm/hugetlb.c | 32 ++--
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git mmotm-2014-08-25-16-52.orig/mm/hugetlb.c
> mmotm-2014-08-25-16-52/mm/hugetlb.c
> index c5345c5edb50..2aafe073cb06 100644
> --- mmotm-2014-08-25-16-52.orig/mm/hugetlb.c
> +++ mmotm-2014-08-25-16-52/mm/hugetlb.c
> @@ -3184,6 +3184,15 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> vma, address);
> }
>
> + ptl = huge_pte_lock(h, mm, ptep);
> +
> + /* Check for a racing update before calling hugetlb_cow */
> + if (unlikely(!pte_same(entry, huge_ptep_get(ptep
> + goto out_ptl;
> +
> + if (!pte_present(entry))
> + goto out_ptl;
A comment on that test would be helpful. Is a migration entry
the only !pte_present() case you would expect to find there?
It would be better to test "entry" for this (or for being a migration
entry) higher up, just after getting "entry": less to unwind on error.
And better to call migration_entry_wait_huge(), after dropping locks,
before returning 0, so that we don't keep the cpu busy faulting while
the migration entry remains there. Maybe not important, but better.
Probably best done with a goto unwinding code at end of function.
(Whereas we don't worry about "wait"s in the !pte_same case,
because !pte_same indicates that change is already occurring:
it's prolonged pte_same cases that we want to get away from.)
> +
> /*
>* hugetlb_cow() requires page locks of pte_page(entry) and
>* pagecache_page, so here we need take the former one
> @@ -3192,22 +3201,17 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
>* so no worry about deadlock.
>*/
> page = pte_page(entry);
> - get_page(page);
> if (page != pagecache_page)
> - lock_page(page);
> -
> - ptl = huge_pte_lockptr(h, mm, ptep);
> - spin_lock(ptl);
> - /* Check for a racing update before calling hugetlb_cow */
> - if (unlikely(!pte_same(entry, huge_ptep_get(ptep
> - goto out_ptl;
> + if (!trylock_page(page))
> + goto out_ptl;
And, again to avoid keeping the cpu busy refaulting, it would be better
to wait_on_page_locked(), after dropping locks, before returning 0;
probably best done with another goto end of function.
>
> + get_page(page);
>
> if (flags & FAULT_FLAG_WRITE) {
> if (!huge_pte_write(entry)) {
> ret = hugetlb_cow(mm, vma, address, ptep, entry,
> pagecache_page, ptl);
> - goto out_ptl;
> + goto out_put_page;
> }
> entry = huge_pte_mkdirty(entry);
> }
> @@ -3215,7 +3219,11 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> if (huge_ptep_set_access_flags(vma, address, ptep, entry,
> flags & FAULT_FLAG_WRITE))
> update_mmu_cache(vma, address, ptep);
> -
> +out_put_page:
> + put_page(page);
If I'm reading this correctly, there's now a small but nasty chance that
this put_page will be the one which frees the page, and the unlock_page
below will then be unlocking a freed page. Our "Bad page" checks should
detect that case, so it won't be as serious as unlocking someone else's
page; but you still should avoid that possibility.
> +out_unlock_page:
mm/hugetlb.c:3231:1: warning: label `out_unlock_page' defined but not used
[-Wunused-label]
> + if (page != pagecache_page)
> + unlock_page(page);
> out_ptl:
> spin_unlock(ptl);
>
> @@ -3223,10 +3231,6 @@ int hugetlb_fault(struct mm_struct *mm,
Re: [PATCH] sched: fix timeval conversion to jiffies
On Thu, Aug 7, 2014 at 5:09 PM, Andrew Hunter wrote:
> timeval_to_jiffies rounding was broken. It essentially computed
> (eliding seconds)
>
> jiffies = usec * (NSEC_PER_USEC/TICK_NSEC)
>
> by using scaling arithmetic, which took the best approximation of
> NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
> x/(2^USEC_JIFFIE_SC), and computed:
>
> jiffies = (usec * x) >> USEC_JIFFIE_SC
>
> and it rounded this calculation up in the intermediate form (since we
> can't necessarily exactly represent TICK_NSEC in usec.) But the
> scaling arithmetic is a (very slight) *over*approximation of the true
> value: rounding the division up by adding 2^USEC_JIFFIE_SC - 1, when
> the error in scaling was added in, was sufficient to add one jiffie to
> the final result.
Apologies for the slow response here. I've never really touched any of
the code here, and parsing the above made me want to go do other
things. :)
Maybe with the next version of the patch, before you get into the
unwinding the math, you might practically describe what is broken,
then explain how its broken.
My quick read here is that we're converting a timespec -> jiffies, and
in doing so we round up by one jiffy.
This seems actually perfectly normal, as we usually end up rounding up
by a jiffy in many cases since we don't want to undershoot any
timeout, and we're always allowed return later then specified. That
said...
> In particular, with HZ=1000, we consistently computed that 1 usec
> was 11 jiffies; the same was true for any exact multiple of
> TICK_NSEC. This is obviously bad as a general rule, and caused
> observable user problems with setitimer() at the very least:
>
> setitimer(ITIMER_PROF, , NULL);
> setitimer(ITIMER_PROF, NULL, );
>
> would actually add a tick to val!
So this looks like an issue. Since we convert and store the internal
representation in jiffies, when we pull it back out, we get the
rounded up value, which is larger then the timespec value originally
submitted. This is really the core issue, correct? Or does this
manifest in other ways that are problematic (the patch seems to hint
that it does)?
> We could possibly still round in the intermediate form, adding
> something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
> convert usec->nsec, round in nanoseconds, and then convert using
> time*spec*_to_jiffies. This adds one constant multiplication, and is
> not observably slower in microbenchmarks on recent x86 hardware.
>
> Tested: the following program:
>
> int main() {
> struct itimerval zero = {{0, 0}, {0, 0}};
> /* Initially set to 10 ms. */
> struct itimerval initial = zero;
> initial.it_interval.tv_usec = 1;
> setitimer(ITIMER_PROF, , NULL);
> /* Save and restore several times. */
> for (size_t i = 0; i < 10; ++i) {
> struct itimerval prev;
> setitimer(ITIMER_PROF, , );
> /* on old kernels, this goes up by TICK_USEC every iteration */
> printf("previous value: %ld %ld %ld %ld\n",
>prev.it_interval.tv_sec, prev.it_interval.tv_usec,
>prev.it_value.tv_sec, prev.it_value.tv_usec);
> setitimer(ITIMER_PROF, , NULL);
> }
> return 0;
> }
>
> Signed-off-by: Andrew Hunter
> Reviewed-by: Paul Turner
> Reported-by: Aaron Jacobs
> Change-Id: I7cd0f0764847fd055d39531f54e6ea3dd3ce5453
> ---
> include/linux/jiffies.h | 12 ---
> kernel/time.c | 54
> +++--
> 2 files changed, 30 insertions(+), 36 deletions(-)
>
> diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
> index 1f44466..c367cbd 100644
> --- a/include/linux/jiffies.h
> +++ b/include/linux/jiffies.h
> @@ -258,23 +258,11 @@ extern unsigned long preset_lpj;
> #define SEC_JIFFIE_SC (32 - SHIFT_HZ)
> #endif
> #define NSEC_JIFFIE_SC (SEC_JIFFIE_SC + 29)
> -#define USEC_JIFFIE_SC (SEC_JIFFIE_SC + 19)
> #define SEC_CONVERSION ((unsigned long)u64)NSEC_PER_SEC <<
> SEC_JIFFIE_SC) +\
> TICK_NSEC -1) / (u64)TICK_NSEC))
>
> #define NSEC_CONVERSION ((unsigned long)u64)1 << NSEC_JIFFIE_SC) +\
> TICK_NSEC -1) / (u64)TICK_NSEC))
> -#define USEC_CONVERSION \
> -((unsigned long)u64)NSEC_PER_USEC << USEC_JIFFIE_SC)
> +\
> -TICK_NSEC -1) / (u64)TICK_NSEC))
> -/*
> - * USEC_ROUND is used in the timeval to jiffie conversion. See there
> - * for more details. It is the scaled resolution rounding value. Note
> - * that it is a 64-bit value. Since, when it is applied, we are already
> - * in jiffies (albit scaled), it is nothing but the bits we will shift
> - * off.
> - */
> -#define USEC_ROUND (u64)(((u64)1 << USEC_JIFFIE_SC) - 1)
> /*
> * The maximum jiffie value is (MAX_INT >> 1). Here we translate that
> * into seconds. The 64-bit case will overflow if we are not careful,
> diff --git a/kernel/time.c b/kernel/time.c
> index 7c7964c..3c49ab4 100644
> ---
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On 09/03/2014 04:53 PM, Andrew Bresticker wrote:
On Tue, Sep 2, 2014 at 5:50 PM, David Daney wrote:
[...]
Your comments don't really make sense to me in the context of my knowledge
of the GIC.
Of course all the CP0 timer and performance counter interrupts are per-CPU
and routed directly to the corresponding CP0_Cause[IP7..IP2] bits. We are
don't need to give them further consideration.
Here is the scenario you should consider:
o 16 CPU cores.
o 1 GIC routing interrupts from external sources to the 16 CPUs.
o 2 network controllers each with an interrupt line routed to the GIC.
Q: What would the GIC "interrupts" property look like?
Note that the GIC doesn't have a single "interrupt-parent", as it can route
interrupts to *all* 16 CPUs.
I propose that the GIC have neither an "interrupt-parent", nor "interrupts".
The fact that it is an "mti,global-interrupt-controller", means that the
software drivers for the GIC already know how to route interrupts, and any
information the device tree could contain is redundant.
Ok, I misunderstood your opposition to the binding.
My intention for the "interrupt-parent" and "interrupts" property of
the GIC was to express that GIC interrupts are routed to the CPU
interrupt vectors and that a certain set of these vectors are
available for use by the GIC. I would agree that these are mostly
redundant (obviously the GIC routes interrupts to CPU interrupt
vecotrs) and that it is not the most accurate description of the
GIC-CPU relationship (the CPU interrupt controller are per-CPU, not
global, and the GIC can route interrupts to any of them), though I'm
not sure that there's a better way of describing it in DT.
So that leaves us with something like this:
interrupt-controller@1bdc {
compatible = "mti,global-interrupt-controller";
interrupt-controller;
#interrupt-cells = <2>;
available-cpu-vectors = <2>, <3>, ...
Exactly what I had in mind, except for the missing "reg" property.
This gives software the information it needs, but doesn't impose any policy.
I will defer to others on the exact name the "available-cpu-vectors"
should have.
};
DT folks, thoughts?
--
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] PM / sleep: add configurable delay for pm_test
When CONFIG_PM_DEBUG=y, we provide a sysfs file (/sys/power/pm_test) for
selecting one of a few suspend test modes, where rather than entering a
full suspend state, the kernel will perform some subset of suspend
steps, wait 5 seconds, and then resume back to normal operation.
This mode is useful for (among other things) observing the state of the
system just before entering a sleep mode, for debugging or analysis
purposes. However, a constant 5 second wait is not sufficient for some
sorts of analysis; for example, on an SoC, one might want to use
external tools to probe the power states of various on-chip controllers
or clocks.
This patch adds a companion sysfs file (/sys/power/pm_test_delay) that
allows user-space to configure how long the system waits in this test
state before resuming. It also updates the PM debugging documentation to
mention the new file.
Signed-off-by: Brian Norris
---
Documentation/power/basic-pm-debugging.txt | 14 --
kernel/power/main.c| 27 +++
kernel/power/power.h | 5 +
kernel/power/suspend.c | 8 ++--
4 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/Documentation/power/basic-pm-debugging.txt
b/Documentation/power/basic-pm-debugging.txt
index edeecd447d23..bd9f27ae99fe 100644
--- a/Documentation/power/basic-pm-debugging.txt
+++ b/Documentation/power/basic-pm-debugging.txt
@@ -75,12 +75,14 @@ you should do the following:
# echo platform > /sys/power/disk
# echo disk > /sys/power/state
-Then, the kernel will try to freeze processes, suspend devices, wait 5 seconds,
-resume devices and thaw processes. If "platform" is written to
-/sys/power/pm_test , then after suspending devices the kernel will additionally
-invoke the global control methods (eg. ACPI global control methods) used to
-prepare the platform firmware for hibernation. Next, it will wait 5 seconds
and
-invoke the platform (eg. ACPI) global methods used to cancel hibernation etc.
+Then, the kernel will try to freeze processes, suspend devices, wait a few
+seconds (5 by default, but configurable via /sys/power/pm_test_delay), resume
+devices and thaw processes. If "platform" is written to /sys/power/pm_test,
+then after suspending devices the kernel will additionally invoke the global
+control methods (eg. ACPI global control methods) used to prepare the platform
+firmware for hibernation. Next, it will wait a configurable number of seconds
+and invoke the platform (eg. ACPI) global methods used to cancel hibernation
+etc.
Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal
hibernation/suspend operations. Also, when open for reading,
/sys/power/pm_test
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 9a59d042ea84..4d242c8b43a0 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -73,6 +73,7 @@ power_attr(pm_async);
#ifdef CONFIG_PM_DEBUG
int pm_test_level = TEST_NONE;
+int pm_test_seconds = PM_TEST_DELAY_DEFAULT;
static const char * const pm_tests[__TEST_AFTER_LAST] = {
[TEST_NONE] = "none",
@@ -132,6 +133,31 @@ static ssize_t pm_test_store(struct kobject *kobj, struct
kobj_attribute *attr,
}
power_attr(pm_test);
+
+static ssize_t pm_test_delay_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", pm_test_seconds);
+}
+
+static ssize_t pm_test_delay_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t n)
+{
+ int val;
+
+ if (kstrtoint(buf, 10, ))
+ return -EINVAL;
+
+ if (val < 0)
+ return -EINVAL;
+
+ pm_test_seconds = val;
+
+ return n;
+}
+
+power_attr(pm_test_delay);
#endif /* CONFIG_PM_DEBUG */
#ifdef CONFIG_DEBUG_FS
@@ -601,6 +627,7 @@ static struct attribute * g[] = {
#endif
#ifdef CONFIG_PM_DEBUG
_test_attr.attr,
+ _test_delay_attr.attr,
#endif
#ifdef CONFIG_PM_SLEEP_DEBUG
_print_times_attr.attr,
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 5d49dcac2537..28111795da71 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -230,6 +230,11 @@ enum {
extern int pm_test_level;
+/* Default to 5 second delay */
+#define PM_TEST_DELAY_DEFAULT 5
+
+extern int pm_test_seconds;
+
#ifdef CONFIG_SUSPEND_FREEZER
static inline int suspend_freeze_processes(void)
{
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 6dadb25cb0d8..2372a99d4356 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -196,8 +196,12 @@ static int suspend_test(int level)
{
#ifdef CONFIG_PM_DEBUG
if (pm_test_level == level) {
- printk(KERN_INFO "suspend debug: Waiting for 5 seconds.\n");
- mdelay(5000);
+ int i;
+
+ pr_info("suspend debug:
RE: [PATCH] staging: comedi: hwdrv_apci1500: use dev->class_dev in calls to dev_warn()
On Wednesday, September 03, 2014 4:59 PM, Chase Southwood wrote:
> git-grep reveals that hwdrv_apci1500.c is the only file in comedi that uses
> dev->hw_dev in calls to dev_{err,warn}(). The rest of the drivers pass
> dev->class_dev to these macros instead. Switch the dev_warn() calls in
> this driver to use dev->class_dev as well, for consistency.
>
> Signed-off-by: Chase Southwood
> Cc: Ian Abbott
> Cc: H Hartley Sweeten
Hmm.. I thought I caught all of these.
Thanks
Reviewed-by: H Hartley Sweeten
--
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] staging: comedi: hwdrv_apci1500: use dev->class_dev in calls to dev_warn()
git-grep reveals that hwdrv_apci1500.c is the only file in comedi that uses
dev->hw_dev in calls to dev_{err,warn}(). The rest of the drivers pass
dev->class_dev to these macros instead. Switch the dev_warn() calls in
this driver to use dev->class_dev as well, for consistency.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
As an aside, it looks like lots of these cases are actually error
conditions that might be more appropriate use cases for dev_err(). But
they could be changed in a follow on patch, this is enough for this one.
.../comedi/drivers/addi-data/hwdrv_apci1500.c | 104 ++---
1 file changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
index e637be1..0ea081e 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
@@ -176,7 +176,7 @@ static int apci1500_di_config(struct comedi_device *dev,
if (data[0] == 2) {
i_MaxChannel = 6;
} else {
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"The specified port event does not exist\n");
return -EINVAL;
}
@@ -192,7 +192,7 @@ static int apci1500_di_config(struct comedi_device *dev,
data[1] = APCI1500_OR_PRIORITY;
break;
default:
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"The specified interrupt logic does not exist\n");
return -EINVAL;
}
@@ -237,7 +237,7 @@ static int apci1500_di_config(struct comedi_device *dev,
case 5:
break;
default:
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"The option indicated in the event mask does
not exist\n");
return -EINVAL;
}
@@ -254,7 +254,7 @@ static int apci1500_di_config(struct comedi_device *dev,
if (data[1] == APCI1500_OR_PRIORITY
&& i_PatternTransition != 0) {
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"Transition error on an OR PRIORITY
logic\n");
return -EINVAL;
}
@@ -272,7 +272,7 @@ static int apci1500_di_config(struct comedi_device *dev,
}
if (i_PatternTransitionCount > 1) {
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"Transition error on an AND
logic\n");
return -EINVAL;
}
@@ -346,7 +346,7 @@ static int apci1500_di_config(struct comedi_device *dev,
APCI1500_Z8536_CONTROL_REGISTER);
} else {
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"The choice for interrupt logic does not
exist\n");
return -EINVAL;
}
@@ -446,7 +446,7 @@ static int apci1500_di_config(struct comedi_device *dev,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
} else {
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"The choice for interrupt logic does not
exist\n");
return -EINVAL;
}
@@ -515,7 +515,7 @@ static int apci1500_di_write(struct comedi_device *dev,
APCI1500_Z8536_CONTROL_REGISTER);
} else {
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"Event 1 not initialised\n");
return -EINVAL;
}
@@ -551,13 +551,13 @@ static int apci1500_di_write(struct comedi_device *dev,
APCI1500_Z8536_CONTROL_REGISTER);
i_Event2InterruptStatus = 1;
} else {
- dev_warn(dev->hw_dev,
+ dev_warn(dev->class_dev,
"Event 2 not initialised\n");
[PATCH 3.10 03/55] HID: fix a couple of off-by-ones
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Kosina
commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream.
There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.
Reported-by: Ben Hawkes
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/hid-cherry.c |2 +-
drivers/hid/hid-kye.c |2 +-
drivers/hid/hid-lg.c |4 ++--
drivers/hid/hid-monterey.c |2 +-
drivers/hid/hid-petalynx.c |2 +-
drivers/hid/hid-sunplus.c |2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/hid/hid-cherry.c
+++ b/drivers/hid/hid-cherry.c
@@ -28,7 +28,7 @@
static __u8 *ch_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 17 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
+ if (*rsize >= 18 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
hid_info(hdev, "fixing up Cherry Cymotion report descriptor\n");
rdesc[11] = rdesc[16] = 0xff;
rdesc[12] = rdesc[17] = 0x03;
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -280,7 +280,7 @@ static __u8 *kye_report_fixup(struct hid
* - change the button usage range to 4-7 for the extra
* buttons
*/
- if (*rsize >= 74 &&
+ if (*rsize >= 75 &&
rdesc[61] == 0x05 && rdesc[62] == 0x08 &&
rdesc[63] == 0x19 && rdesc[64] == 0x08 &&
rdesc[65] == 0x29 && rdesc[66] == 0x0f &&
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -345,14 +345,14 @@ static __u8 *lg_report_fixup(struct hid_
struct usb_device_descriptor *udesc;
__u16 bcdDevice, rev_maj, rev_min;
- if ((drv_data->quirks & LG_RDESC) && *rsize >= 90 && rdesc[83] == 0x26
&&
+ if ((drv_data->quirks & LG_RDESC) && *rsize >= 91 && rdesc[83] == 0x26
&&
rdesc[84] == 0x8c && rdesc[85] == 0x02) {
hid_info(hdev,
"fixing up Logitech keyboard report descriptor\n");
rdesc[84] = rdesc[89] = 0x4d;
rdesc[85] = rdesc[90] = 0x10;
}
- if ((drv_data->quirks & LG_RDESC_REL_ABS) && *rsize >= 50 &&
+ if ((drv_data->quirks & LG_RDESC_REL_ABS) && *rsize >= 51 &&
rdesc[32] == 0x81 && rdesc[33] == 0x06 &&
rdesc[49] == 0x81 && rdesc[50] == 0x06) {
hid_info(hdev,
--- a/drivers/hid/hid-monterey.c
+++ b/drivers/hid/hid-monterey.c
@@ -24,7 +24,7 @@
static __u8 *mr_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 30 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
+ if (*rsize >= 31 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
hid_info(hdev, "fixing up button/consumer in HID report
descriptor\n");
rdesc[30] = 0x0c;
}
--- a/drivers/hid/hid-petalynx.c
+++ b/drivers/hid/hid-petalynx.c
@@ -25,7 +25,7 @@
static __u8 *pl_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 60 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
+ if (*rsize >= 62 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
rdesc[41] == 0x00 && rdesc[59] == 0x26 &&
rdesc[60] == 0xf9 && rdesc[61] == 0x00) {
hid_info(hdev, "fixing up Petalynx Maxter Remote report
descriptor\n");
--- a/drivers/hid/hid-sunplus.c
+++ b/drivers/hid/hid-sunplus.c
@@ -24,7 +24,7 @@
static __u8 *sp_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 107 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
+ if (*rsize >= 112 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
rdesc[106] == 0x03) {
hid_info(hdev, "fixing up Sunplus Wireless Desktop report
descriptor\n");
rdesc[105] = rdesc[110] = 0x03;
--
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 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 2, 2014 at 5:50 PM, David Daney wrote:
> On 09/02/2014 12:36 PM, Andrew Bresticker wrote:
>>
>> On Tue, Sep 2, 2014 at 10:27 AM, David Daney
>> wrote:
>>>
>>> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
The Global Interrupt Controller (GIC) present on certain MIPS systems
can be used to route external interrupts to individual VPEs and CPU
interrupt vectors. It also supports a timer and software-generated
interrupts.
Signed-off-by: Andrew Bresticker
---
Documentation/devicetree/bindings/mips/gic.txt | 50
++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
diff --git a/Documentation/devicetree/bindings/mips/gic.txt
b/Documentation/devicetree/bindings/mips/gic.txt
new file mode 100644
index 000..725f1ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/gic.txt
@@ -0,0 +1,50 @@
+MIPS Global Interrupt Controller (GIC)
+
+The MIPS GIC routes external interrupts to individual VPEs and IRQ
pins.
+It also supports a timer and software-generated interrupts which can be
+used as IPIs.
+
+Required properties:
+- compatible : Should be "mti,global-interrupt-controller"
+- reg : Base address and length of the GIC registers.
+- interrupts : Core interrupts to which the GIC may route external
interrupts.
>>>
>>>
>>>
>>> This doesn't make sense to me. The GIC can, and does, route interrupts
>>> to
>>> all CPU cores in a SMP system. How can there be a concept of only
>>> associating it with several interrupt lines on a single CPU in the
>>> system?
>>> That is not what the GIC does, is it? It is a Global interrupts
>>> controller,
>>> not local. So specifying device tree bindings that don't show its Global
>>> nature seems wrong.
>>
>>
>> While the GIC can route external interrupts to any HW interrupt vector
>> it may not make sense to actually use all those vectors. For example,
>> the CP0 timer is usually hooked up to HW vector 5 (it could be treated
>> as a GIC local interrupt, though it may still be fixed to HW vector
>> 5). BTW, the Malta example about the i8259 I gave before was wrong -
>> it appears that it actually gets chained with the GIC.
>
>
> Your comments don't really make sense to me in the context of my knowledge
> of the GIC.
>
> Of course all the CP0 timer and performance counter interrupts are per-CPU
> and routed directly to the corresponding CP0_Cause[IP7..IP2] bits. We are
> don't need to give them further consideration.
>
>
> Here is the scenario you should consider:
>
> o 16 CPU cores.
> o 1 GIC routing interrupts from external sources to the 16 CPUs.
> o 2 network controllers each with an interrupt line routed to the GIC.
>
> Q: What would the GIC "interrupts" property look like?
>
> Note that the GIC doesn't have a single "interrupt-parent", as it can route
> interrupts to *all* 16 CPUs.
>
> I propose that the GIC have neither an "interrupt-parent", nor "interrupts".
> The fact that it is an "mti,global-interrupt-controller", means that the
> software drivers for the GIC already know how to route interrupts, and any
> information the device tree could contain is redundant.
Ok, I misunderstood your opposition to the binding.
My intention for the "interrupt-parent" and "interrupts" property of
the GIC was to express that GIC interrupts are routed to the CPU
interrupt vectors and that a certain set of these vectors are
available for use by the GIC. I would agree that these are mostly
redundant (obviously the GIC routes interrupts to CPU interrupt
vecotrs) and that it is not the most accurate description of the
GIC-CPU relationship (the CPU interrupt controller are per-CPU, not
global, and the GIC can route interrupts to any of them), though I'm
not sure that there's a better way of describing it in DT.
So that leaves us with something like this:
interrupt-controller@1bdc {
compatible = "mti,global-interrupt-controller";
interrupt-controller;
#interrupt-cells = <2>;
available-cpu-vectors = <2>, <3>, ...
};
DT folks, thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10 06/55] USB: serial: ftdi_sio: Annotate the current Xsens PID assignments
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Patrick Riphagen commit 9273b8a270878906540349422ab24558b9d65716 upstream. The converters are used in specific products. It can be useful to know which they are exactly. Signed-off-by: Patrick Riphagen Signed-off-by: Frans Klaver Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman --- drivers/usb/serial/ftdi_sio_ids.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/usb/serial/ftdi_sio_ids.h +++ b/drivers/usb/serial/ftdi_sio_ids.h @@ -140,12 +140,12 @@ /* * Xsens Technologies BV products (http://www.xsens.com). */ -#define XSENS_CONVERTER_0_PID 0xD388 -#define XSENS_CONVERTER_1_PID 0xD389 +#define XSENS_CONVERTER_0_PID 0xD388 /* Xsens USB converter */ +#define XSENS_CONVERTER_1_PID 0xD389 /* Xsens Wireless Receiver */ #define XSENS_CONVERTER_2_PID 0xD38A -#define XSENS_CONVERTER_3_PID 0xD38B -#define XSENS_CONVERTER_4_PID 0xD38C -#define XSENS_CONVERTER_5_PID 0xD38D +#define XSENS_CONVERTER_3_PID 0xD38B /* Xsens USB-serial converter */ +#define XSENS_CONVERTER_4_PID 0xD38C /* Xsens Wireless Receiver */ +#define XSENS_CONVERTER_5_PID 0xD38D /* Xsens Awinda Station */ #define XSENS_CONVERTER_6_PID 0xD38E #define XSENS_CONVERTER_7_PID 0xD38F -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10 08/55] USB: ehci-pci: USB host controller support for Intel Quark X1000
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Bryan O'Donoghue
commit 6e693739e9b603b3ca9ce0d4f4178f0633458465 upstream.
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when isochronous/interrupt transactions are not initiated by the USB
host controller. This patch is to reconfigure the packet buffer in/out
threshold as maximal as possible to maximize the performance, and 0x7F dwords
(508 Bytes) should be used because the USB host controller initiates
isochronous/interrupt transactions.
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Alvin (Weike) Chen
Acked-by: Alan Stern
Reviewed-by: Jingoo Han
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ehci-pci.c | 25 +
1 file changed, 25 insertions(+)
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -35,6 +35,21 @@ static const char hcd_name[] = "ehci-pci
#define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
/*-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
+static inline bool is_intel_quark_x1000(struct pci_dev *pdev)
+{
+ return pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
+}
+
+/*
+ * 0x84 is the offset of in/out threshold register,
+ * and it is the same offset as the register of 'hostpc'.
+ */
+#defineintel_quark_x1000_insnreg01 hostpc
+
+/* Maximum usable threshold value is 0x7f dwords for both IN and OUT */
+#define INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD 0x007f007f
/* called after powerup, by probe or system-pm "wakeup" */
static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
@@ -50,6 +65,16 @@ static int ehci_pci_reinit(struct ehci_h
if (!retval)
ehci_dbg(ehci, "MWI active\n");
+ /* Reset the threshold limit */
+ if (is_intel_quark_x1000(pdev)) {
+ /*
+* For the Intel QUARK X1000, raise the I/O threshold to the
+* maximum usable value in order to improve performance.
+*/
+ ehci_writel(ehci, INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD,
+ ehci->regs->intel_quark_x1000_insnreg01);
+ }
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10 04/55] isofs: Fix unbounded recursion when processing relocated directories
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit 410dd3cf4c9b36f27ed4542ee18b1af5e68645a4 upstream.
We did not check relocated directory in any way when processing Rock
Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL
entry pointing to another CL entry leading to possibly unbounded
recursion in kernel code and thus stack overflow or deadlocks (if there
is a loop created from CL entries).
Fix the problem by not allowing CL entry to point to a directory entry
with CL entry (such use makes no good sense anyway) and by checking
whether CL entry doesn't point to itself.
Reported-by: Chris Evans
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman
---
fs/isofs/inode.c | 15 ---
fs/isofs/isofs.h | 23 +++
fs/isofs/rock.c | 39 ---
3 files changed, 55 insertions(+), 22 deletions(-)
--- a/fs/isofs/inode.c
+++ b/fs/isofs/inode.c
@@ -69,7 +69,7 @@ static void isofs_put_super(struct super
return;
}
-static int isofs_read_inode(struct inode *);
+static int isofs_read_inode(struct inode *, int relocated);
static int isofs_statfs (struct dentry *, struct kstatfs *);
static struct kmem_cache *isofs_inode_cachep;
@@ -1274,7 +1274,7 @@ out_toomany:
goto out;
}
-static int isofs_read_inode(struct inode *inode)
+static int isofs_read_inode(struct inode *inode, int relocated)
{
struct super_block *sb = inode->i_sb;
struct isofs_sb_info *sbi = ISOFS_SB(sb);
@@ -1419,7 +1419,7 @@ static int isofs_read_inode(struct inode
*/
if (!high_sierra) {
- parse_rock_ridge_inode(de, inode);
+ parse_rock_ridge_inode(de, inode, relocated);
/* if we want uid/gid set, override the rock ridge setting */
if (sbi->s_uid_set)
inode->i_uid = sbi->s_uid;
@@ -1498,9 +1498,10 @@ static int isofs_iget5_set(struct inode
* offset that point to the underlying meta-data for the inode. The
* code below is otherwise similar to the iget() code in
* include/linux/fs.h */
-struct inode *isofs_iget(struct super_block *sb,
-unsigned long block,
-unsigned long offset)
+struct inode *__isofs_iget(struct super_block *sb,
+ unsigned long block,
+ unsigned long offset,
+ int relocated)
{
unsigned long hashval;
struct inode *inode;
@@ -1522,7 +1523,7 @@ struct inode *isofs_iget(struct super_bl
return ERR_PTR(-ENOMEM);
if (inode->i_state & I_NEW) {
- ret = isofs_read_inode(inode);
+ ret = isofs_read_inode(inode, relocated);
if (ret < 0) {
iget_failed(inode);
inode = ERR_PTR(ret);
--- a/fs/isofs/isofs.h
+++ b/fs/isofs/isofs.h
@@ -107,7 +107,7 @@ extern int iso_date(char *, int);
struct inode; /* To make gcc happy */
-extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode
*);
+extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode
*, int relocated);
extern int get_rock_ridge_filename(struct iso_directory_record *, char *,
struct inode *);
extern int isofs_name_translate(struct iso_directory_record *, char *, struct
inode *);
@@ -118,9 +118,24 @@ extern struct dentry *isofs_lookup(struc
extern struct buffer_head *isofs_bread(struct inode *, sector_t);
extern int isofs_get_blocks(struct inode *, sector_t, struct buffer_head **,
unsigned long);
-extern struct inode *isofs_iget(struct super_block *sb,
-unsigned long block,
-unsigned long offset);
+struct inode *__isofs_iget(struct super_block *sb,
+ unsigned long block,
+ unsigned long offset,
+ int relocated);
+
+static inline struct inode *isofs_iget(struct super_block *sb,
+ unsigned long block,
+ unsigned long offset)
+{
+ return __isofs_iget(sb, block, offset, 0);
+}
+
+static inline struct inode *isofs_iget_reloc(struct super_block *sb,
+unsigned long block,
+unsigned long offset)
+{
+ return __isofs_iget(sb, block, offset, 1);
+}
/* Because the inode number is no longer relevant to finding the
* underlying meta-data for an inode, we are free to choose a more
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -288,12 +288,16 @@ eio:
goto out;
}
+#define RR_REGARD_XA 1
+#define RR_RELOC_DE 2
+
static int
parse_rock_ridge_inode_internal(struct iso_directory_record *de,
- struct inode *inode, int regard_xa)
+
[PATCH 3.10 36/55] x86_64/vsyscall: Fix warn_bad_vsyscall log output
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit 53b884ac3745353de220d92ef792515c3ae692f0 upstream.
This commit in Linux 3.6:
commit c767a54ba0657e52e6edaa97cbe0b0a8bf1c1655
Author: Joe Perches
Date: Mon May 21 19:50:07 2012 -0700
x86/debug: Add KERN_ to bare printks, convert printks to
pr_
caused warn_bad_vsyscall to output garbage in the middle of the
line. Revert the bad part of it.
The printk in question isn't actually bare; the level is "%s".
The bug this fixes is purely cosmetic; backports are optional.
Signed-off-by: Andy Lutomirski
Link:
http://lkml.kernel.org/r/03eac1f24110bbe496ecc12a4df467e0d88466d4.1406330947.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/vsyscall_64.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -125,10 +125,10 @@ static void warn_bad_vsyscall(const char
if (!show_unhandled_signals)
return;
- pr_notice_ratelimited("%s%s[%d] %s ip:%lx cs:%lx sp:%lx ax:%lx si:%lx
di:%lx\n",
- level, current->comm, task_pid_nr(current),
- message, regs->ip, regs->cs,
- regs->sp, regs->ax, regs->si, regs->di);
+ printk_ratelimited("%s%s[%d] %s ip:%lx cs:%lx sp:%lx ax:%lx si:%lx
di:%lx\n",
+ level, current->comm, task_pid_nr(current),
+ message, regs->ip, regs->cs,
+ regs->sp, regs->ax, regs->si, regs->di);
}
static int addr_to_vsyscall_nr(unsigned long 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/
[PATCH 3.10 12/55] ALSA: hda/ca0132 - Dont try loading firmware at resume when already failed
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit e24aa0a4c5ac92a171d9dd74a8d3dbf652990d36 upstream. CA0132 driver tries to reload the firmware at resume. Usually this works since the firmware loader core caches the firmware contents by itself. However, if the driver failed to load the firmwares (e.g. missing files), reloading the firmware at resume goes through the actual file loading code path, and triggers a kernel WARNING like: WARNING: CPU: 10 PID:11371 at drivers/base/firmware_class.c:1105 _request_firmware+0x9ab/0x9d0() For avoiding this situation, this patch makes CA0132 skipping the f/w loading at resume when it failed at probe time. Reported-and-tested-by: Janek Kozicki Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/hda/patch_ca0132.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -4379,6 +4379,9 @@ static void ca0132_download_dsp(struct h return; /* NOP */ #endif + if (spec->dsp_state == DSP_DOWNLOAD_FAILED) + return; /* don't retry failures */ + chipio_enable_clocks(codec); spec->dsp_state = DSP_DOWNLOADING; if (!ca0132_download_dsp_images(codec)) @@ -4555,7 +4558,8 @@ static int ca0132_init(struct hda_codec struct auto_pin_cfg *cfg = >autocfg; int i; - spec->dsp_state = DSP_DOWNLOAD_INIT; + if (spec->dsp_state != DSP_DOWNLOAD_FAILED) + spec->dsp_state = DSP_DOWNLOAD_INIT; spec->curr_chip_addx = INVALID_CHIP_ADDRESS; snd_hda_power_up(codec); @@ -4666,6 +4670,7 @@ static int patch_ca0132(struct hda_codec codec->spec = spec; spec->codec = codec; + spec->dsp_state = DSP_DOWNLOAD_INIT; spec->num_mixers = 1; spec->mixers[0] = ca0132_mixer; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10 20/55] hwmon: (ads1015) Fix off-by-one for valid channel index checking
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Axel Lin
commit 56de1377ad92f72ee4e5cb0faf7a9b6048fdf0bf upstream.
Current code uses channel as array index, so the valid channel value is
0 .. ADS1015_CHANNELS - 1.
Signed-off-by: Axel Lin
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwmon/ads1015.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwmon/ads1015.c
+++ b/drivers/hwmon/ads1015.c
@@ -184,7 +184,7 @@ static int ads1015_get_channels_config_o
}
channel = be32_to_cpup(property);
- if (channel > ADS1015_CHANNELS) {
+ if (channel >= ADS1015_CHANNELS) {
dev_err(>dev,
"invalid channel index %d on %s\n",
channel, node->full_name);
--
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 v9 5/6] clk: Add floor and ceiling constraints to clock rates
On 09/03/14 08:33, Tomeu Vizoso wrote:
> Adds a way for clock consumers to set maximum and minimum rates. This can be
> used for thermal drivers to set ceiling rates, or by misc. drivers to set
> floor rates to assure a minimum performance level.
>
> Signed-off-by: Tomeu Vizoso
> Tested-by: Heiko Stuebner
>
> ---
>
> v9: * Apply first all the floor constraints, then the ceiling constraints.
> * WARN on ceiling constraints below the current floor, for a given user
> clk
>
> v5: * Move the storage of constraints to the per-user clk struct, as suggested
> by Stephen Warren.
> ---
> drivers/clk/clk.c | 43 +++
> drivers/clk/clk.h | 1 +
> drivers/clk/clkdev.c| 2 +-
> include/linux/clk-private.h | 5 +
> include/linux/clk.h | 18 ++
> 5 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 61a3492..3a961c6 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -560,6 +560,8 @@ struct clk *__clk_create_clk(struct clk_core *clk_core,
> const char *dev,
> clk->dev_id = dev;
> clk->con_id = con;
>
> + hlist_add_head(>child_node, _core->per_user_clks);
> +
How is this safe with another thread that may be traversing the list? Or
even two threads calling clk_get_parent() at the same time?
> return clk;
> }
>
> @@ -1625,6 +1627,7 @@ static void clk_change_rate(struct clk_core *clk)
> int clk_provider_set_rate(struct clk_core *clk, unsigned long rate)
> {
> struct clk_core *top, *fail_clk;
> + struct clk *clk_user;
> int ret = 0;
>
> if (!clk)
> @@ -1633,6 +1636,15 @@ int clk_provider_set_rate(struct clk_core *clk,
> unsigned long rate)
> /* prevent racing with updates to the clock topology */
> clk_prepare_lock();
>
> + hlist_for_each_entry(clk_user, >per_user_clks, child_node) {
> + rate = max(rate, clk_user->floor_constraint);
> + }
> +
> + hlist_for_each_entry(clk_user, >per_user_clks, child_node) {
> + if (clk_user->ceiling_constraint > 0)
> + rate = min(rate, clk_user->ceiling_constraint);
> + }
> +
> /* bail early if nothing to do */
> if (rate == clk_provider_get_rate(clk))
> goto out;
> @@ -1699,6 +1711,29 @@ int clk_set_rate(struct clk *clk_user, unsigned long
> rate)
> }
> EXPORT_SYMBOL_GPL(clk_set_rate);
>
> +int clk_set_floor_rate(struct clk *clk_user, unsigned long rate)
> +{
> + struct clk_core *clk = clk_to_clk_core(clk_user);
> +
> + clk_user->floor_constraint = rate;
> + return clk_provider_set_rate(clk, clk_provider_get_rate(clk));
It would be nice if this was also locked around so that the
floor_constraint or ceiling_constraint doesn't change while another
thread is iterating the list. I guess we'll get by though because
eventually things will settle and either this thread here will set the
"final" rate, or the other thread in clk_provider_set_rate() will have
already set the final rate. It just seems wrong to not hold the lock
while updating what is supposed to be protected by the prepare lock.
> +}
> +EXPORT_SYMBOL_GPL(clk_set_floor_rate);
> +
> +int clk_set_ceiling_rate(struct clk *clk_user, unsigned long rate)
> +{
> + struct clk_core *clk = clk_to_clk_core(clk_user);
> +
> + WARN(rate > 0 && rate < clk_user->floor_constraint,
> + "clk %s dev %s con %s: new ceiling %lu lower than existing floor
> %lu\n",
> + __clk_get_name(clk), clk_user->dev_id, clk_user->con_id, rate,
> + clk_user->floor_constraint);
> +
> + clk_user->ceiling_constraint = rate;
> + return clk_provider_set_rate(clk, clk_provider_get_rate(clk));
> +}
> +EXPORT_SYMBOL_GPL(clk_set_ceiling_rate);
Maybe I'm late to this patch series given that Mike applied it, but I
wonder why we wouldn't just have one API that takes a min and a max,
i.e. clk_set_rate_range(clk, min, max)? Then clk_set_rate() is a small
wrapper on top that just sets min and max to the same value.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10 23/55] hwmon: (dme1737) Prevent overflow problem when writing large limits
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Axel Lin
commit d58e47d787c09fe5c61af3c6ce7d784762f29c3d upstream.
On platforms with sizeof(int) < sizeof(long), writing a temperature
limit larger than MAXINT will result in unpredictable limit values
written to the chip. Avoid auto-conversion from long to int to fix
the problem.
Voltage limits, fan minimum speed, pwm frequency, pwm ramp rate, and
other attributes have the same problem, fix them as well.
Zone temperature limits are signed, but were cached as u8, causing
unepected values to be reported for negative temperatures. Cache as
s8 to fix the problem.
vrm is an u8, so the written value needs to be limited to [0, 255].
Signed-off-by: Axel Lin
[Guenter Roeck: Fix zone temperature cache]
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwmon/dme1737.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
--- a/drivers/hwmon/dme1737.c
+++ b/drivers/hwmon/dme1737.c
@@ -247,8 +247,8 @@ struct dme1737_data {
u8 pwm_acz[3];
u8 pwm_freq[6];
u8 pwm_rr[2];
- u8 zone_low[3];
- u8 zone_abs[3];
+ s8 zone_low[3];
+ s8 zone_abs[3];
u8 zone_hyst[2];
u32 alarms;
};
@@ -277,7 +277,7 @@ static inline int IN_FROM_REG(int reg, i
return (reg * nominal + (3 << (res - 3))) / (3 << (res - 2));
}
-static inline int IN_TO_REG(int val, int nominal)
+static inline int IN_TO_REG(long val, int nominal)
{
return clamp_val((val * 192 + nominal / 2) / nominal, 0, 255);
}
@@ -293,7 +293,7 @@ static inline int TEMP_FROM_REG(int reg,
return (reg * 1000) >> (res - 8);
}
-static inline int TEMP_TO_REG(int val)
+static inline int TEMP_TO_REG(long val)
{
return clamp_val((val < 0 ? val - 500 : val + 500) / 1000, -128, 127);
}
@@ -308,7 +308,7 @@ static inline int TEMP_RANGE_FROM_REG(in
return TEMP_RANGE[(reg >> 4) & 0x0f];
}
-static int TEMP_RANGE_TO_REG(int val, int reg)
+static int TEMP_RANGE_TO_REG(long val, int reg)
{
int i;
@@ -331,7 +331,7 @@ static inline int TEMP_HYST_FROM_REG(int
return (((ix == 1) ? reg : reg >> 4) & 0x0f) * 1000;
}
-static inline int TEMP_HYST_TO_REG(int val, int ix, int reg)
+static inline int TEMP_HYST_TO_REG(long val, int ix, int reg)
{
int hyst = clamp_val((val + 500) / 1000, 0, 15);
@@ -347,7 +347,7 @@ static inline int FAN_FROM_REG(int reg,
return (reg == 0 || reg == 0x) ? 0 : 9 * 60 / reg;
}
-static inline int FAN_TO_REG(int val, int tpc)
+static inline int FAN_TO_REG(long val, int tpc)
{
if (tpc) {
return clamp_val(val / tpc, 0, 0x);
@@ -379,7 +379,7 @@ static inline int FAN_TYPE_FROM_REG(int
return (edge > 0) ? 1 << (edge - 1) : 0;
}
-static inline int FAN_TYPE_TO_REG(int val, int reg)
+static inline int FAN_TYPE_TO_REG(long val, int reg)
{
int edge = (val == 4) ? 3 : val;
@@ -402,7 +402,7 @@ static int FAN_MAX_FROM_REG(int reg)
return 1000 + i * 500;
}
-static int FAN_MAX_TO_REG(int val)
+static int FAN_MAX_TO_REG(long val)
{
int i;
@@ -460,7 +460,7 @@ static inline int PWM_ACZ_FROM_REG(int r
return acz[(reg >> 5) & 0x07];
}
-static inline int PWM_ACZ_TO_REG(int val, int reg)
+static inline int PWM_ACZ_TO_REG(long val, int reg)
{
int acz = (val == 4) ? 2 : val - 1;
@@ -476,7 +476,7 @@ static inline int PWM_FREQ_FROM_REG(int
return PWM_FREQ[reg & 0x0f];
}
-static int PWM_FREQ_TO_REG(int val, int reg)
+static int PWM_FREQ_TO_REG(long val, int reg)
{
int i;
@@ -510,7 +510,7 @@ static inline int PWM_RR_FROM_REG(int re
return (rr & 0x08) ? PWM_RR[rr & 0x07] : 0;
}
-static int PWM_RR_TO_REG(int val, int ix, int reg)
+static int PWM_RR_TO_REG(long val, int ix, int reg)
{
int i;
@@ -528,7 +528,7 @@ static inline int PWM_RR_EN_FROM_REG(int
return PWM_RR_FROM_REG(reg, ix) ? 1 : 0;
}
-static inline int PWM_RR_EN_TO_REG(int val, int ix, int reg)
+static inline int PWM_RR_EN_TO_REG(long val, int ix, int reg)
{
int en = (ix == 1) ? 0x80 : 0x08;
@@ -1481,13 +1481,16 @@ static ssize_t set_vrm(struct device *de
const char *buf, size_t count)
{
struct dme1737_data *data = dev_get_drvdata(dev);
- long val;
+ unsigned long val;
int err;
- err = kstrtol(buf, 10, );
+ err = kstrtoul(buf, 10, );
if (err)
return err;
+ if (val > 255)
+ return -EINVAL;
+
data->vrm = val;
return count;
}
--
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/
