Re: [PATCH -mm 1/2] mm: vmscan: account slab pages on memcg reclaim
On Mon 12-01-15 12:30:37, Vladimir Davydov wrote:
> Since try_to_free_mem_cgroup_pages() can now call slab shrinkers, we
> should initialize reclaim_state and account reclaimed slab pages in
> scan_control->nr_reclaimed.
I am sorry, I didn't get to this one yet. As pointed out in othere email
(http://marc.info/?l=linux-mm=142132670609578=2) reclaim_state might
catch unrelated pages freed from slab. I do not like expanding its usage
for memcg.
> Signed-off-by: Vladimir Davydov
> ---
> mm/vmscan.c | 33 ++---
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 16f3e45742d6..b2c041139a51 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -367,13 +367,16 @@ static unsigned long do_shrink_slab(struct
> shrink_control *shrinkctl,
> * the ->seeks setting of the shrink function, which indicates the
> * cost to recreate an object relative to that of an LRU page.
> *
> - * Returns the number of reclaimed slab objects.
> + * Returns the number of reclaimed slab objects. The number of reclaimed
> + * pages is added to *@ret_nr_reclaimed.
> */
> static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>struct mem_cgroup *memcg,
>unsigned long nr_scanned,
> - unsigned long nr_eligible)
> + unsigned long nr_eligible,
> + unsigned long *ret_nr_reclaimed)
> {
> + struct reclaim_state *reclaim_state = current->reclaim_state;
> struct shrinker *shrinker;
> unsigned long freed = 0;
>
> @@ -412,6 +415,10 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>
> up_read(_rwsem);
> out:
> + if (reclaim_state) {
> + *ret_nr_reclaimed += reclaim_state->reclaimed_slab;
> + reclaim_state->reclaimed_slab = 0;
> + }
> cond_resched();
> return freed;
> }
> @@ -419,6 +426,7 @@ out:
> void drop_slab_node(int nid)
> {
> unsigned long freed;
> + unsigned long nr_reclaimed = 0;
>
> do {
> struct mem_cgroup *memcg = NULL;
> @@ -426,7 +434,7 @@ void drop_slab_node(int nid)
> freed = 0;
> do {
> freed += shrink_slab(GFP_KERNEL, nid, memcg,
> - 1000, 1000);
> + 1000, 1000, _reclaimed);
> } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
> } while (freed > 10);
> }
> @@ -2339,7 +2347,6 @@ static inline bool should_continue_reclaim(struct zone
> *zone,
> static bool shrink_zone(struct zone *zone, struct scan_control *sc,
> bool is_classzone)
> {
> - struct reclaim_state *reclaim_state = current->reclaim_state;
> unsigned long nr_reclaimed, nr_scanned;
> bool reclaimable = false;
>
> @@ -2371,7 +2378,7 @@ static bool shrink_zone(struct zone *zone, struct
> scan_control *sc,
> if (memcg && is_classzone)
> shrink_slab(sc->gfp_mask, zone_to_nid(zone),
> memcg, sc->nr_scanned - scanned,
> - lru_pages);
> + lru_pages, >nr_reclaimed);
>
> /*
>* Direct reclaim and kswapd have to scan all memory
> @@ -2398,12 +2405,7 @@ static bool shrink_zone(struct zone *zone, struct
> scan_control *sc,
> if (global_reclaim(sc) && is_classzone)
> shrink_slab(sc->gfp_mask, zone_to_nid(zone), NULL,
> sc->nr_scanned - nr_scanned,
> - zone_lru_pages);
> -
> - if (reclaim_state) {
> - sc->nr_reclaimed += reclaim_state->reclaimed_slab;
> - reclaim_state->reclaimed_slab = 0;
> - }
> + zone_lru_pages, >nr_reclaimed);
>
> vmpressure(sc->gfp_mask, sc->target_mem_cgroup,
> sc->nr_scanned - nr_scanned,
> @@ -2865,6 +2867,9 @@ unsigned long try_to_free_mem_cgroup_pages(struct
> mem_cgroup *memcg,
> .may_unmap = 1,
> .may_swap = may_swap,
> };
> + struct reclaim_state reclaim_state = {
> + .reclaimed_slab = 0,
> + };
>
> /*
>* Unlike direct reclaim via alloc_pages(), memcg's reclaim doesn't
> @@ -2875,6 +2880,9 @@ unsigned long try_to_free_mem_cgroup_pages(struct
> mem_cgroup *memcg,
>
> zonelist = NODE_DATA(nid)->node_zonelists;
>
> + lockdep_set_current_reclaim_state(gfp_mask);
> + current->reclaim_state = _state;
> +
> trace_mm_vmscan_memcg_reclaim_begin(0,
> sc.may_writepage,
>
[PATCH 01/36] tools build: Add new build support
Adding new build framework into 'tools/build' to be used by tools. There's no change for actual building at this point, it comes in the next patches. The idea and more details are explained in the 'tools/build/Documentation/Build' file. I stole everything from the kernel build system, with some changes to allow for multiple binaries build definitions. While the kernel's build output is single image (forget modules) we need to be able to build several binaries/libraries. The basic idea is that sser provides 'Build' files with objects definitions like: perf-y += a.o perf-y += b.o libperf-y += c.o libperf-y += d.o and the build framework outputs files: perf-in.o# a.o, b.o compiled in libperf-in.o # c.o, d.o compiled in Signed-off-by: Jiri Olsa Cc: Alexis Berlemont Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian --- tools/build/Build.include | 75 ++ tools/build/Documentation/Build.txt | 75 ++ tools/build/Makefile.build | 91 + tools/perf/MANIFEST | 1 + 4 files changed, 242 insertions(+) create mode 100644 tools/build/Build.include create mode 100644 tools/build/Documentation/Build.txt create mode 100644 tools/build/Makefile.build diff --git a/tools/build/Build.include b/tools/build/Build.include new file mode 100644 index ..6a990b018e6d --- /dev/null +++ b/tools/build/Build.include @@ -0,0 +1,75 @@ +### +# build: Generic definitions + +### +# Convenient variables +comma := , +squote := ' + +### +# Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o +dot-target = $(dir $@).$(notdir $@) + +### +# filename of target with directory and extension stripped +basetarget = $(basename $(notdir $@)) + +### +# The temporary file to save gcc -MD generated dependencies must not +# contain a comma +depfile = $(subst $(comma),_,$(dot-target).d) + +### +# Check if both arguments has same arguments. Result is empty string if equal. +arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \ +$(filter-out $(cmd_$@), $(cmd_$(1))) ) + +### +# Escape single quote for use in echo statements +escsq = $(subst $(squote),'\$(squote)',$1) + +# Echo command +# Short version is used, if $(quiet) equals `quiet_', otherwise full one. +echo-cmd = $(if $($(quiet)cmd_$(1)),\ + echo ' $(call escsq,$($(quiet)cmd_$(1)))';) + +### +# Replace >$< with >$$< to preserve $ when reloading the .cmd file +# (needed for make) +# Replace >#< with >\#< to avoid starting a comment in the .cmd file +# (needed for make) +# Replace >'< with >'\''< to be able to enclose the whole string in '...' +# (needed for the shell) +make-cmd = $(call escsq,$(subst \#,\\\#,$(subst $$,,$(cmd_$(1) + +### +# Find any prerequisites that is newer than target or that does not exist. +# PHONY targets skipped in both cases. +any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^) + +### +# if_changed_dep - execute command if any prerequisite is newer than +# target, or command line has changed and update +# dependencies in the cmd file +if_changed_dep = $(if $(strip $(any-prereq) $(arg-check)), \ + @set -e; \ + $(echo-cmd) $(cmd_$(1)); \ + cat $(depfile) > $(dot-target).cmd;\ + printf '%s\n' 'cmd_$@ := $(make-cmd)' >> $(dot-target).cmd) + +### +# if_changed - execute command if any prerequisite is newer than +# target, or command line has changed +if_changed = $(if $(strip $(any-prereq) $(arg-check)), \ + @set -e; \ + $(echo-cmd) $(cmd_$(1)); \ + printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd) + +### +# C flags to be used in rule definitions, includes: +# - depfile generation +# - global $(CFLAGS) +# - per target C flags +# - per object C flags +# - BUILD_STR macro to allow '-D"$(variable)"' constructs +c_flags = -Wp,-MD,$(depfile),-MT,$@ $(CFLAGS) -D"BUILD_STR(s)=\#s" $(CFLAGS_$(basetarget).o) $(CFLAGS_$(obj)) diff --git a/tools/build/Documentation/Build.txt b/tools/build/Documentation/Build.txt new file mode 100644 index ..8a11facc1838 --- /dev/null +++ b/tools/build/Documentation/Build.txt @@ -0,0 +1,75 @@ +build framework +== +The perf build framework is stolen from kernel build system, +so the idea and the way how objects are built is the same. + + +a) Build makefiles +-- +User supplies 'Build' makefiles that contains objects summary, +like for example following 'krava/Build' file: + + perf-y += a.o
[tip:x86/apic] iommu/vt-d: Prepare for killing function irq_remapping_supported()
Commit-ID: 2966d9566beb39c53477c96525820b9415de7a7d
Gitweb: http://git.kernel.org/tip/2966d9566beb39c53477c96525820b9415de7a7d
Author: Jiang Liu
AuthorDate: Wed, 7 Jan 2015 15:31:35 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 15 Jan 2015 11:24:23 +0100
iommu/vt-d: Prepare for killing function irq_remapping_supported()
Prepare for killing function irq_remapping_supported() by moving code
from intel_irq_remapping_supported() into intel_prepare_irq_remapping().
Combined with patch from Joerg at https://lkml.org/lkml/2014/12/15/487,
so assume an signed-off from Joerg.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
Tested-by: Joerg Roedel
Cc: Tony Luck
Cc: io...@lists.linux-foundation.org
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Link:
http://lkml.kernel.org/r/1420615903-28253-9-git-send-email-jiang@linux.intel.com
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel_irq_remapping.c | 58 -
1 file changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 1e7e093..8ccc7aa 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -568,30 +568,6 @@ static int __init dmar_x2apic_optout(void)
static int __init intel_irq_remapping_supported(void)
{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
-
- if (disable_irq_remap)
- return 0;
- if (irq_remap_broken) {
- printk(KERN_WARNING
- "This system BIOS has enabled interrupt remapping\n"
- "on a chipset that contains an erratum making that\n"
- "feature unstable. To maintain system stability\n"
- "interrupt remapping is being disabled. Please\n"
- "contact your BIOS vendor for an update\n");
- add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
- disable_irq_remap = 1;
- return 0;
- }
-
- if (!dmar_ir_support())
- return 0;
-
- for_each_iommu(iommu, drhd)
- if (!ecap_ir_support(iommu->ecap))
- return 0;
-
return 1;
}
@@ -616,26 +592,42 @@ static int __init intel_prepare_irq_remapping(void)
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu;
+ /* First check whether IRQ remapping should be enabled */
+ if (disable_irq_remap)
+ return -ENODEV;
+
+ if (irq_remap_broken) {
+ printk(KERN_WARNING
+ "This system BIOS has enabled interrupt remapping\n"
+ "on a chipset that contains an erratum making that\n"
+ "feature unstable. To maintain system stability\n"
+ "interrupt remapping is being disabled. Please\n"
+ "contact your BIOS vendor for an update\n");
+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
+ disable_irq_remap = 1;
+ return -ENODEV;
+ }
+
if (dmar_table_init() < 0)
- return -1;
+ return -ENODEV;
+
+ if (!dmar_ir_support())
+ return -ENODEV;
if (parse_ioapics_under_ir() != 1) {
printk(KERN_INFO "Not enabling interrupt remapping\n");
goto error;
}
- for_each_iommu(iommu, drhd) {
- if (!ecap_ir_support(iommu->ecap))
- continue;
-
- /* Do the allocations early */
- if (intel_setup_irq_remapping(iommu))
+ for_each_iommu(iommu, drhd)
+ if (!ecap_ir_support(iommu->ecap) ||
+ intel_setup_irq_remapping(iommu))
goto error;
- }
return 0;
+
error:
intel_cleanup_irq_remapping();
- return -1;
+ return -ENODEV;
}
static int __init intel_enable_irq_remapping(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] pxa_timer: fix session missmatch warning
Dmitry Eremin-Solenikov writes: > Fix the following warning: > > WARNING: drivers/clocksource/built-in.o(.text.unlikely+0x70): Section > mismatch in reference from the function pxa_timer_common_init() to the > function .init.text:clocksource_mmio_init() > The function pxa_timer_common_init() references > the function __init clocksource_mmio_init(). > This is often because pxa_timer_common_init lacks a __init > annotation or the annotation of clocksource_mmio_init is wrong. > > Signed-off-by: Dmitry Eremin-Solenikov Acked-by: Robert Jarzmik On a side note, I never get this warning in my builds, either on linux-next or linus tree, probably because pxa_timer_common_init() is always inlined in my builds. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: tegra20: cpuidle: remove unnecessary "resettable" status clear
15.01.2015 15:49, Dmitry Osipenko пишет: CPU1 "resettable" status is already cleared by final suspend function in case of suspend abortion and by reset handler in case of completed CPU powergate, no point to do it again. Signed-off-by: Dmitry Osipenko --- arch/arm/mach-tegra/cpuidle-tegra20.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c b/arch/arm/mach-tegra/cpuidle-tegra20.c index b30bf5c..ad6158e 100644 --- a/arch/arm/mach-tegra/cpuidle-tegra20.c +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c @@ -158,8 +158,6 @@ static bool tegra20_idle_enter_lp2_cpu_1(struct cpuidle_device *dev, cpu_suspend(0, tegra20_sleep_cpu_secondary_finish); - tegra20_cpu_clear_resettable(); - clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, >cpu); return true; Completely forgot to remove it also from 'sleep.h' and 'sleep-tegra20.S'. Please ignore this patch, I'll include it in ASM -> C conversion series. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND 2/2] wlcore: align member-assigns in a structure-copy block
Eliad Peller writes: > On Fri, Jan 9, 2015 at 7:03 PM, Kalle Valo wrote: >> Giel van Schijndel writes: >> >>> This highlights the differences (e.g. the bug fixed in the previous >>> commit). >>> >>> Signed-off-by: Giel van Schijndel >>> --- >>> drivers/net/wireless/ti/wlcore/acx.c | 22 +++--- >>> 1 file changed, 11 insertions(+), 11 deletions(-) >>> >>> diff --git a/drivers/net/wireless/ti/wlcore/acx.c >>> b/drivers/net/wireless/ti/wlcore/acx.c >>> index f28fa3b..93a2fa8 100644 >>> --- a/drivers/net/wireless/ti/wlcore/acx.c >>> +++ b/drivers/net/wireless/ti/wlcore/acx.c >>> @@ -1715,17 +1715,17 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl) >>> goto out; >>> } >>> >>> - acx->recover_time = cpu_to_le32(conf->recover_time); >>> - acx->hangover_period = conf->hangover_period; >>> - acx->dynamic_mode = conf->dynamic_mode; >>> - acx->early_termination_mode = conf->early_termination_mode; >>> - acx->max_period = conf->max_period; >>> - acx->min_period = conf->min_period; >>> - acx->increase_delta = conf->increase_delta; >>> - acx->decrease_delta = conf->decrease_delta; >>> - acx->quiet_time = conf->quiet_time; >>> - acx->increase_time = conf->increase_time; >>> - acx->window_size = conf->window_size; >>> + acx->recover_time = cpu_to_le32(conf->recover_time); >>> + acx->hangover_period= conf->hangover_period; >>> + acx->dynamic_mode = conf->dynamic_mode; >>> + acx->early_termination_mode = conf->early_termination_mode; >>> + acx->max_period = conf->max_period; >>> + acx->min_period = conf->min_period; >>> + acx->increase_delta = conf->increase_delta; >>> + acx->decrease_delta = conf->decrease_delta; >>> + acx->quiet_time = conf->quiet_time; >>> + acx->increase_time = conf->increase_time; >>> + acx->window_size= conf->window_size; >> >> I would like to get an ACK from one of the wlcore developers if I should >> apply this (or not). > > I don't have a strong opinion here. However, it looks pretty much > redundant to take a random blob (which was just fixed by a correct > patch) and re-indent it. The rest of the file doesn't follow this > style, so i don't see a good reason to apply it here. Yeah, this should be a driver decision and not just a single change in one function. Hence I'm dropping patch 2. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm v2] vmscan: move reclaim_state handling to shrink_slab
On Thu, Jan 15, 2015 at 01:58:20PM +0100, Michal Hocko wrote:
> On Thu 15-01-15 11:37:53, Vladimir Davydov wrote:
> > current->reclaim_state is only used to count the number of slab pages
> > reclaimed by shrink_slab(). So instead of initializing it before we are
> >
> > Note that after this patch try_to_free_mem_cgroup_pages() will count not
> > only reclaimed user pages, but also slab pages, which is expected,
> > because it can reclaim kmem from kmem-active sub cgroups.
>
> Except that reclaim_state counts all freed slab objects that have
> current->reclaim_state != NULL AFAIR. This includes also kfreed pages
> from interrupt context and who knows what else and those pages might be
> from a different memcgs, no?
Hmm, true, good point. Can an interrupt handler free a lot of memory
though? Does RCU free objects from irq or soft irq context?
> Besides that I am not sure this makes any difference in the end. No
> try_to_free_mem_cgroup_pages caller really cares about the exact
> number of reclaimed pages. We care only about whether there was any
> progress done - and even that not exactly (e.g. try_charge checks
> mem_cgroup_margin before retry/oom so if sufficient kmem pages were
> uncharged then we will notice that).
Frankly, I thought exactly the same initially, that's why I dropped
reclaim_state handling from the initial memcg shrinkers patch set.
However, then Hillf noticed that nr_reclaimed is checked right after
calling shrink_slab() in the memcg iteration loop in shrink_zone():
memcg = mem_cgroup_iter(root, NULL, );
do {
[...]
if (memcg && is_classzone)
shrink_slab(sc->gfp_mask, zone_to_nid(zone),
memcg, sc->nr_scanned - scanned,
lru_pages);
/*
* Direct reclaim and kswapd have to scan all memory
* cgroups to fulfill the overall scan target for the
* zone.
*
* Limit reclaim, on the other hand, only cares about
* nr_to_reclaim pages to be reclaimed and it will
* retry with decreasing priority if one round over the
* whole hierarchy is not sufficient.
*/
if (!global_reclaim(sc) &&
sc->nr_reclaimed >= sc->nr_to_reclaim) {
mem_cgroup_iter_break(root, memcg);
break;
}
memcg = mem_cgroup_iter(root, memcg, );
} while (memcg);
If we can ignore reclaimed slab pages here (?), let's drop this patch.
Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] Atmel matrix, SMC and UDC rework
Le 14/01/2015 17:21, Alexandre Belloni a écrit : > Hi Felipe, > > The following series replace the previous series sent by Boris named: > - [PATCH v5 00/11] memory: add Atmel EBI (External Bus Interface) driver > - [PATCH 00/11] usb: gadget: at91_udc: Rework for multi-platform support > > The patches I left out are less urgent and will be resent later, probably for > 3.21. > > Because of the dependancy between the syscon addition and the at91_udc series, > this can go through the AT91 tree if you giv your ack on the udc patches. > > The first 4 patches introduce 2 syscon devices needed to configure the > matrix and SMC. > The following patches rework the at91_udc driver to prepare at91 for > multi-platform support. > > It also include several fixes: > - fix clock names to be consistent with other USB drivers > - document clocks and clock-names properties in atmel-usb DT bindings doc > > and some cleanup changes: > - remove useless usb_clk > - allocate at91_udc instance instead of using the statically defined one > - simplify the probe and remove functions by using devm_ helpers > - remove !DT specific code > > Changes from the previous series: > - rebased on 3.19-rc1 > > Boris Brezillon (12): > mfd: syscon: Add atmel-matrix registers definition > mfd: syscon: Add Atmel Matrix bus DT binding documentation > mfd: syscon: Add atmel-smc registers definition > mfd: syscon: Add Atmel SMC binding doc I already acknowledged these 4 patches as part of another series. > usb: gadget: at91_udc: Fix clock names > usb: gadget: at91_udc: Drop uclk clock > usb: gadget: at91_udc: Document DT clocks and clock-names property > usb: gadget: at91_udc: Remove non-DT handling code > usb: gadget: at91_udc: Simplify probe and remove functions > usb: gadget: at91_udc: Rework for multi-platform kernel support > usb: gadget: at91_udc: Update DT binding documentation > usb: gadget: at91_udc: Allocate udc instance I'm fine with all this: Acked-by: Nicolas Ferre Great, I plan to add them all to the at91-3.20-drivers branch now. Thanks, best regards. > .../devicetree/bindings/mfd/atmel-matrix.txt | 24 + > .../devicetree/bindings/mfd/atmel-smc.txt | 19 + > .../devicetree/bindings/usb/atmel-usb.txt | 10 +- > drivers/usb/gadget/udc/Kconfig | 1 + > drivers/usb/gadget/udc/at91_udc.c | 525 > +++-- > drivers/usb/gadget/udc/at91_udc.h | 9 +- > include/linux/mfd/syscon/atmel-matrix.h| 117 + > include/linux/mfd/syscon/atmel-smc.h | 173 +++ > 8 files changed, 623 insertions(+), 255 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mfd/atmel-matrix.txt > create mode 100644 Documentation/devicetree/bindings/mfd/atmel-smc.txt > create mode 100644 include/linux/mfd/syscon/atmel-matrix.h > create mode 100644 include/linux/mfd/syscon/atmel-smc.h > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On Thu, Jan 15, 2015 at 12:52:38PM +, Chanwoo Choi wrote: > On Thu, Jan 15, 2015 at 9:46 PM, Chanwoo Choi wrote: > > Hi Mark, > > > > On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland wrote: > >> On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: > >>> Hi Kukjin, > >>> > >>> On 01/15/2015 01:02 AM, Daniel Lezcano wrote: > >>> > On 01/14/2015 04:51 PM, Kukjin Kim wrote: > >>> >> On 01/14/15 14:33, Chanwoo Choi wrote: > >>> >> > >>> >> Hi, > >>> >> > >>> >> + Doug, Olof > >>> >> > >>> >>> This patch adds the support for Exynos 64bit SoC. The delay_timer is > >>> >>> only used > >>> >>> for Exynos 32bit SoC. > >>> >>> > >>> >> Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is > >>> >> available > >>> >> on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture > >>> >> is > >>> >> including ARM ARCH timer (ARM Generic Timer) and exynos7 also has > >>> >> implemented it and additionally its access is faster than using memory > >>> >> mapped register called SFR for MCT...so Doug submitted patch to use MCT > >>> >> on 32bit exynos SoCs before. > >>> > >>> I know arch_timer. As you comment, ARCH timer would be used for system > >>> timer for ARMv8. > >>> But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I > >>> checked it on > >>> Exynos5433/EXynos7 User-manaual and tested it. > >>> > >>> I think that exynos_mct.c should support the Exynos 64-bit SoC > >>> because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. > >>> > >>> Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos > >>> User-manual never includes > >>> the detailed information about for ARCH timer(e.g, clock for ARCH timer). > >>> I knew that > >>> I can get the document of ARCH timer for ARM official site but I think it > >>> is insufficient > >>> to implement ARCH timer on Exynos SoC. > >> > >> What do you mean by "insufficient to implement ARCH timer"? > > > > As I knew, timer must need the source clock. The clock for ARCH timer > > has dependency on Exynos SoC, But I cannot find > > I'm so sorry about this mistake. I pressed the send button before > completing reply. > > As I knew, timer must need the source clock. The clock for ARCH timer > has dependency on Exynos SoC, But I cannot find the clock information > for ARCH timer on Exynos SoC user-manual. > > When I tried to use ARCH timer on Exynos3250, It is not working. We > can check this ARCH timer issue of Exynos3250 > on following patch[1]: > [1] http://www.spinics.net/lists/arm-kernel/msg322943.html Hmm. That is annoying. Your boot code should have been initialising this already. > >> The architected timer is mandatory in ARMv8, and required by the arm64 > >> kernel. > >> > >> Additional timers may be requried if you want to put all CPUs into low > >> power states where the timer logic may be disabled and/or lose state, > >> but regardless the architected timers are necessary. > > I agree that ARCH timer is mandatory. > > I just think that existing exynos-mct.c driver should support the Exynos5/7 > SoC > because released Exynos5/7 SoC includes already MCT IP for system timer. I'm not opposed to the MCT. My only concern is that a configured and enabled architected timer is mandated by the boot protocol, and is a prerequisite for a functioning kernel. Your initial response made it sound like you expected the MCT alone to be sufficient. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Another SCHED_DEADLINE bug (with bisection and possible fix)
Hi Peter, On 01/15/2015 01:23 PM, Peter Zijlstra wrote: On Thu, Jan 15, 2015 at 12:23:43PM +0100, Luca Abeni wrote: There are some parts of the patch that I do not understand (for example: if I understand well, if the task is not throttled you set dl_new to 1... And if it is throttled you change its current runtime and scheduling deadline... Why?) Anyway, I tested the patch and I confirm that it fixes the hang I originally reported. I'll go look at the patch in a wee bit. But Juri, Luca, could you describe the correct behaviour? From what I understand we should either modify the tasks run/sleep stats when we change its parameters or we should schedule a delayed release of the bandwidth delta (when it reaches its 0-lag point, if thats in the future). I suspect the correct behaviour can be difficult to implement: - When a SCHED_DEADLINE task ends (or changes its scheduling policy to something different), its bandwidth cannot be released immediately, but should be released at the "0-lag time" (which reminds me about the GRUB patches... I had to implement a similar behaviour in those patches :) - The same applies when the task changes its scheduling parameters decreasing its bandwidth. In this case, we also need to update the current runtime (if it is larger than the new runtime, set it to the new maximum value - I think this is the safest thing to do) - When a task changes its parameters to increase its bandwidth, be do not have such problems. As far as I can see, if we apply the runtime / deadline changes starting from the next reservation period we are safe (because the "0-lag time" is always smaller than the current scheduling deadline). This might cause some transient overloads (because if I change the parameters of a task at time t, the update takes action a little bit later - at the next scheduling deadline), but guarantees that a task never consumes more than expected (for example: if a task continuously changes its bandwidth between 0.4 and 0.3, it will never consume more than 0.4. I suspect that if we immediately update dl_se->deadline and dl_se->runtime a task can arrive to consume much more CPU time). Luca Doing neither will allow one to game the reservation system afaict. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] e100: Don't enable WoL by default on Toshiba devices
On Thursday 13 November 2014, Jeff Kirsher wrote: > On Wed, 2014-11-12 at 18:18 -0500, David Miller wrote: > > From: Ondrej Zary > > Date: Wed, 12 Nov 2014 23:47:25 +0100 > > > > > Enabling WoL on some Toshiba laptops (such as Portege R100) causes > > > battery drain after shutdown (WoL is active even on battery). These > > > laptops have the WoL bit set in EEPROM ID, causing e100 driver to > > > enable WoL by default. > > > > > > Check subsystem vendor ID and if it's Toshiba, don't enable WoL by > > > default from EEPROM settings. > > > > > > Fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784 > > > > > > Signed-off-by: Ondrej Zary > > > > Jeff, are you gonna pick this up? > > Yes, sorry I did not catch it earlier. What happened to this patch? I don't see it in net.git or net-next.git (checked both davem's and jkirsher's) -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6 1/4] phy: qcom-ufs: add support for 20nm phy
> Hi,
>
> On Sunday 11 January 2015 06:08 PM, Yaniv Gardi wrote:
>> This change adds a support for a 20nm qcom-ufs phy that is required in
>> platforms that use ufs-qcom controller.
>>
>> Signed-off-by: Yaniv Gardi
>>
>> ---
>> drivers/phy/Kconfig | 7 +
>> drivers/phy/Makefile| 2 +
>> drivers/phy/phy-qcom-ufs-i.h| 159
>> drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257 +
>> drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235
>> drivers/phy/phy-qcom-ufs.c | 745
>>
>> include/linux/phy/phy-qcom-ufs.h| 59 +++
>> 7 files changed, 1464 insertions(+)
>> create mode 100644 drivers/phy/phy-qcom-ufs-i.h
>> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c
>> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h
>> create mode 100644 drivers/phy/phy-qcom-ufs.c
>> create mode 100644 include/linux/phy/phy-qcom-ufs.h
>
> I think a single header file should be sufficient here.
>
I believe 2 header files is a better design in this case.
one header file is internal, and should serve internally the phy drivers.
the other one that exposes APIs.
One header file compels us to expose our internal macros, and definitions
in include\linux\phy which is not recommended and not necessary.
the advantage of 2 header files will be more visible if you pick the 14nm
phy code as well. (change#3 in V6, or change#4 in V7)
thanks for your comment.
> It would be helpful if you can split this patch further. First add only
> the
> core ufs layer (Include a documentation on how this layer should be used
> in
> Documentation/phy/) and then use it to add the 14nm and 20nm PHYs.
thanks Kishon for your comment.
I accept the first comment, and in V7, the first change is divided into
2 patches as suggested:
one that adds common support for Qualcomm Technologies UFS Phys
and the other one adds the specific implementation of 20nm phy.
at this point i decided not to add a Documentation, as the
Qualcomm UFS PHY uses the generic PHY framework, and currently we don't
think any further documentation is needed in addition to the Generic Phy
documentation that is presented already in Documentation/phy.txt
thanks for reviewing the change.
>
> Thanks
> Kishon
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index ccad880..26a7623 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -277,4 +277,11 @@ config PHY_STIH41X_USB
>>Enable this to support the USB transceiver that is part of
>>STMicroelectronics STiH41x SoC series.
>>
>> +config PHY_QCOM_UFS
>> +tristate "Qualcomm UFS PHY driver"
>> +depends on OF && ARCH_MSM
>> +select GENERIC_PHY
>> +help
>> + Support for UFS PHY on QCOM chipsets.
>> +
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index aa74f96..781b2fa 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -34,3 +34,5 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) +=
>> phy-spear1340-miphy.o
>> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>> obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
>> obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
>> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
>> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
>> diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
>> new file mode 100644
>> index 000..a175069
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-ufs-i.h
>> @@ -0,0 +1,159 @@
>> +/*
>> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that 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.
>> + *
>> + */
>> +
>> +#ifndef UFS_QCOM_PHY_I_H_
>> +#define UFS_QCOM_PHY_I_H_
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
>> +({ \
>> +ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
>> +might_sleep_if(timeout_us); \
>> +for (;;) { \
>> +(val) = readl(addr); \
>> +if (cond) \
>> +break; \
>> +if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
>> +(val) = readl(addr); \
>> +break; \
>> +} \
>> +if (sleep_us) \
>> +usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us); \
>> +} \
>> +(cond) ? 0 : -ETIMEDOUT; \
>> +})
>> +
Re: [PATCH] virtio_balloon: coding style fixes
On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote:
> On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:
> > Most of our code has
> > struct foo {
> > }
> >
> > Fix two instances where balloon is inconsistent.
>
> I hate to complain but is it really necessary to post such patches to
> linux-api?
Well it's human to err, so it seems wise to copy parties
interested in the ABI/API whenever we are changing files under include/uapi.
Whitespace changes should mostly be safe, but it's not unknown
e.g. to include unrelated changes in the same commit by mistake.
> I thought the list was primarily for API related discussions.
Basically this line in MAINTAINERS
ABI/API
L: linux-...@vger.kernel.org
F: Documentation/ABI/
F: include/linux/syscalls.h
F: include/uapi/
F: kernel/sys_ni.c
normally means "send all patches affecting files under include/uapi/ to
this list", does it not?
Wasn't this the intent?
> This is not the only mail sent here which doesn't fall into that
> category IMO. It is far from low volume list for quite some time.
>
> Please let's get back low volume and API only discussion!
Maybe send patch dropping include/uapi/ from there,
should help drive the volumes down?
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > include/uapi/linux/virtio_balloon.h | 3 +--
> > drivers/virtio/virtio_balloon.c | 3 +--
> > 2 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/uapi/linux/virtio_balloon.h
> > b/include/uapi/linux/virtio_balloon.h
> > index be40f70..4b0488f 100644
> > --- a/include/uapi/linux/virtio_balloon.h
> > +++ b/include/uapi/linux/virtio_balloon.h
> > @@ -36,8 +36,7 @@
> > /* Size of a PFN in the balloon interface. */
> > #define VIRTIO_BALLOON_PFN_SHIFT 12
> >
> > -struct virtio_balloon_config
> > -{
> > +struct virtio_balloon_config {
> > /* Number of pages host wants Guest to give up. */
> > __le32 num_pages;
> > /* Number of pages we've actually got in balloon. */
> > diff --git a/drivers/virtio/virtio_balloon.c
> > b/drivers/virtio/virtio_balloon.c
> > index 3176ea4..0413157 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -44,8 +44,7 @@ static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
> > module_param(oom_pages, int, S_IRUSR | S_IWUSR);
> > MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
> >
> > -struct virtio_balloon
> > -{
> > +struct virtio_balloon {
> > struct virtio_device *vdev;
> > struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> >
> > --
> > MST
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Michal Hocko
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND V2 1/2] power: gpio-charger: balance enable/disable_irq_wake calls
Hi, On Thu, Jan 15, 2015 at 05:00:37AM +0300, Dmitry Eremin-Solenikov wrote: > enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to > generate the wakeup event (and thus resume should call disable_irq_wake). > Currently gpio-charger driver has this logic inverted. Correct that thus > correcting enable/disable_irq_wake() calls balance. Thanks, applied: http://git.infradead.org/battery-2.6.git/commit/9a2fb8ac9677ab9cf17ab336e06b59d93a57f4a4 -- Sebastian signature.asc Description: Digital signature
Re: [PATCH RESEND V2 2/2] power: collie_battery: support generating wakeup event
Hi, On Thu, Jan 15, 2015 at 05:00:38AM +0300, Dmitry Eremin-Solenikov wrote: > Teach collie_battery driver to communicate to the kernel that it can > generate wakeup events. Handle enabling/disabling wakeup on battery full > event in suspend/resume callbacks. Thanks, applied: http://git.infradead.org/battery-2.6.git/commit/a465005643a4c1e02681b02075082fc6c7fa076a -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 2/2] drm/msm/mdp5: Add hardware cursor support
On Wed, Jan 14, 2015 at 7:55 PM, Daniel Vetter wrote:
> On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote:
>> From: Beeresh Gopal
>>
>> This patch implements the hardware accelarated cursor
>> support for MDP5 platforms.
>>
>> Signed-off-by: Beeresh Gopal
>> Signed-off-by: Wentao Xu
>> Signed-off-by: Stephane Viau
>
> Imo implementing legacy cursor support instead of with universal planes
> makes no sense. Especially since msm is converted to atomic already, and
> you can't move the cursor with atomic when it's legacy only. See the
> cursor argument for the drm_crtc_init_with_planes function and how it's
> used in e.g. i915.
>
well, I'm still not 100% convinced about going through the whole
atomic mechanism for cursors.. in particular stuff that tries to
enable/disable the cursor at 1000fps, goes *really* badly when things
start waiting for vsync.
I'll probably try some experiments with it at some point, but at this
point something that works with x11 is a lot more interesting for me
(since every time I switch from mdp4 device to mdp5 device I forget to
disable hw cursor the first time I start x)
BR,
-R
> Cheers, Daniel
>
>> ---
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 164
>> +++
>> 1 file changed, 164 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> index f021f96..2021f09 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> @@ -24,6 +24,9 @@
>> #include "drm_crtc_helper.h"
>> #include "drm_flip_work.h"
>>
>> +#define CURSOR_WIDTH 64
>> +#define CURSOR_HEIGHT 64
>> +
>> #define SSPP_MAX (SSPP_RGB3 + 1) /* TODO: Add SSPP_MAX in mdp5.xml.h */
>>
>> struct mdp5_crtc {
>> @@ -47,8 +50,21 @@ struct mdp5_crtc {
>> #define PENDING_FLIP 0x2
>> atomic_t pending;
>>
>> + /* for unref'ing cursor bo's after scanout completes: */
>> + struct drm_flip_work unref_cursor_work;
>> +
>> struct mdp_irq vblank;
>> struct mdp_irq err;
>> +
>> + struct {
>> + /* protect REG_MDP5_LM_CURSOR* registers and cursor scanout_bo*/
>> + spinlock_t lock;
>> +
>> + /* current cursor being scanned out: */
>> + struct drm_gem_object *scanout_bo;
>> + uint32_t width;
>> + uint32_t height;
>> + } cursor;
>> };
>> #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
>>
>> @@ -129,11 +145,22 @@ static void complete_flip(struct drm_crtc *crtc,
>> struct drm_file *file)
>> }
>> }
>>
>> +static void unref_cursor_worker(struct drm_flip_work *work, void *val)
>> +{
>> + struct mdp5_crtc *mdp5_crtc =
>> + container_of(work, struct mdp5_crtc, unref_cursor_work);
>> + struct mdp5_kms *mdp5_kms = get_kms(_crtc->base);
>> +
>> + msm_gem_put_iova(val, mdp5_kms->id);
>> + drm_gem_object_unreference_unlocked(val);
>> +}
>> +
>> static void mdp5_crtc_destroy(struct drm_crtc *crtc)
>> {
>> struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
>>
>> drm_crtc_cleanup(crtc);
>> + drm_flip_work_cleanup(_crtc->unref_cursor_work);
>>
>> kfree(mdp5_crtc);
>> }
>> @@ -384,6 +411,132 @@ static int mdp5_crtc_set_property(struct drm_crtc
>> *crtc,
>> return -EINVAL;
>> }
>>
>> +static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
>> + struct drm_file *file, uint32_t handle,
>> + uint32_t width, uint32_t height)
>> +{
>> + struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
>> + struct drm_device *dev = crtc->dev;
>> + struct mdp5_kms *mdp5_kms = get_kms(crtc);
>> + struct drm_gem_object *cursor_bo, *old_bo;
>> + uint32_t blendcfg, cursor_addr, stride;
>> + int ret, bpp, lm;
>> + unsigned int depth;
>> + enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
>> + uint32_t flush_mask = mdp_ctl_flush_mask_cursor(0);
>> + unsigned long flags;
>> +
>> + if ((width > CURSOR_WIDTH) || (height > CURSOR_HEIGHT)) {
>> + dev_err(dev->dev, "bad cursor size: %dx%d\n", width, height);
>> + return -EINVAL;
>> + }
>> +
>> + if (NULL == mdp5_crtc->ctl)
>> + return -EINVAL;
>> +
>> + if (!handle) {
>> + DBG("Cursor off");
>> + return mdp5_ctl_set_cursor(mdp5_crtc->ctl, false);
>> + }
>> +
>> + cursor_bo = drm_gem_object_lookup(dev, file, handle);
>> + if (!cursor_bo)
>> + return -ENOENT;
>> +
>> + ret = msm_gem_get_iova(cursor_bo, mdp5_kms->id, _addr);
>> + if (ret)
>> + return -EINVAL;
>> +
>> + lm = mdp5_crtc->lm;
>> + drm_fb_get_bpp_depth(DRM_FORMAT_ARGB, , );
>> + stride = width * (bpp >> 3);
>> +
>> + spin_lock_irqsave(_crtc->cursor.lock, flags);
>> + old_bo = mdp5_crtc->cursor.scanout_bo;
>> +
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
>> + MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_IMG_SIZE(lm),
>> + MDP5_LM_CURSOR_IMG_SIZE_SRC_H(height) |
>> + MDP5_LM_CURSOR_IMG_SIZE_SRC_W(width));
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_SIZE(lm),
>> + MDP5_LM_CURSOR_SIZE_ROI_H(height) |
>> + MDP5_LM_CURSOR_SIZE_ROI_W(width));
Re: [PATCH 1/3] rtlwifi: btcoexist: Remove some unused functions
Larry Finger writes: > On 01/10/2015 10:24 AM, Rickard Strandqvist wrote: >> Removes some functions that are not used anywhere: >> ex_halbtc8821a1ant_periodical() ex_halbtc8821a1ant_pnp_notify() >> ex_halbtc8821a1ant_halt_notify() ex_halbtc8821a1ant_bt_info_notify() >> ex_halbtc8821a1ant_special_packet_notify() >> ex_halbtc8821a1ant_connect_notify() >> ex_halbtc8821a1ant_scan_notify() ex_halbtc8821a1ant_lps_notify() >> ex_halbtc8821a1ant_ips_notify() ex_halbtc8821a1ant_display_coex_info() >> ex_halbtc8821a1ant_init_coex_dm() ex_halbtc8821a1ant_init_hwconfig() >> >> This was partially found by using a static code analysis program called >> cppcheck. >> >> Signed-off-by: Rickard Strandqvist > > NACK! > > I told you to stay away from these routines until I finish my update. > Not only might you remove some functions that I will be needing later, > but you run the risk of merge complications. > > Kalle: Please ignore EVERYTHING from this person. Obviously, he is > incapable of understanding even the simplest instructions. Yeah, I have to agree with that. I think he is just too fixated creating the patches automatically. I have dropped the patches. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] fuse bugfix for 3.19
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus This fixes a regression in the latest fuse update plus a fix for a rather theoretical memory ordering issue. Thanks, Miklos --- Miklos Szeredi (2): fuse: fix LOOKUP vs INIT compat handling fuse: add memory barrier to INIT --- fs/fuse/dev.c| 51 +-- fs/fuse/dir.c| 31 +++ fs/fuse/fuse_i.h | 2 ++ fs/fuse/inode.c | 5 ++--- 4 files changed, 60 insertions(+), 29 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote:
> This patch adds the generic common bindings used to represent
> a hwlock device and use/request locks in a device-tree build.
>
> All the platform-specific hwlock driver implementations need the
> number of locks and associated base id for registering the locks
> present within the device with the driver core. This base id
> needs to be unique across multiple IP instances of a hwspinlock
> device, so that each hwlock can be represented uniquely in a
> system.
>
> The number of locks is represented by 'hwlock-num-locks' property,
> and the base id is represented by the 'hwlock-base-id' property.
> The args specifier length is dependent on each vendor-specific
> implementation and is represented through the '#hwlock-cells'
> property. Client users need to use the property 'hwlocks' for
> requesting specific lock(s).
>
> Note that the document is named hwlock.txt deliberately to keep
> it a bit more generic.
>
> Cc: Rob Herring
> Signed-off-by: Suman Anna
> ---
> v7: Revised binding info for hwlock-base-id, it is mandatory now
>
> .../devicetree/bindings/hwlock/hwlock.txt | 55
> ++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> new file mode 100644
> index ..8de7aaf878f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -0,0 +1,55 @@
> +Generic hwlock bindings
> +===
> +
> +Generic bindings that are common to all the hwlock platform specific driver
> +implementations.
> +
> +The validity and need of these common properties may vary from one platform
> +implementation to another. The platform specific bindings should explicitly
> +state if an optional property is used. Please also look through the
> individual
> +platform specific hwlock binding documentations for identifying the
> applicable
> +properties.
> +
> +Common properties:
> +- #hwlock-cells: Specifies the number of cells needed to represent a
> + specific lock. This property is mandatory for all
> + platform implementations.
> +- hwlock-num-locks: Number of locks present in a hwlock device. This
> + property is needed on hwlock devices, where the number
> + of supported locks within a hwlock device cannot be
> + read from a register.
> +- hwlock-base-id:An unique base Id for the locks for a particular hwlock
> + device. This property is mandatory for all platform
> + implementations.
This property makes no sense. The ID encoded in the hwlock cells is
relative to the instance (identified by phandle), not global. So the DT
has no global ID space.
Why do you think you need this?
The definition here isn't sufficient, and the example is incomplete
(lacking provider nodes and hence this property), which is unhelpful.
Thanks,
Mark.
> +
> +Hwlock Users:
> +=
> +
> +Nodes that require specific hwlock(s) should specify them using the property
> +"hwlocks", each containing a phandle to the hwlock node and an args specifier
> +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
> +an array of the phandle and hwlock number specifier tuple.
> +
> +1. Example of a node using a single specific hwlock:
> +
> +The following example has a node requesting a hwlock in the bank defined by
> +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
> +of length 1.
> +
> + node {
> + ...
> + hwlocks = < 2>;
> + ...
> + };
> +
> +2. Example of a node using multiple specific hwlocks:
> +
> +The following example has a node requesting two hwlocks, a hwlock within
> +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
> +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
> +
> + node {
> + ...
> + hwlocks = < 2>, < 0 3>;
> + ...
> + };
> --
> 2.2.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Thu, Jan 15, 2015 at 01:52:01PM +, Mark Rutland wrote: > On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote: > > This patch adds the generic common bindings used to represent > > a hwlock device and use/request locks in a device-tree build. > > > > All the platform-specific hwlock driver implementations need the > > number of locks and associated base id for registering the locks > > present within the device with the driver core. This base id > > needs to be unique across multiple IP instances of a hwspinlock > > device, so that each hwlock can be represented uniquely in a > > system. > > > > The number of locks is represented by 'hwlock-num-locks' property, > > and the base id is represented by the 'hwlock-base-id' property. > > The args specifier length is dependent on each vendor-specific > > implementation and is represented through the '#hwlock-cells' > > property. Client users need to use the property 'hwlocks' for > > requesting specific lock(s). > > > > Note that the document is named hwlock.txt deliberately to keep > > it a bit more generic. > > > > Cc: Rob Herring > > Signed-off-by: Suman Anna > > --- > > v7: Revised binding info for hwlock-base-id, it is mandatory now > > > > .../devicetree/bindings/hwlock/hwlock.txt | 55 > > ++ > > 1 file changed, 55 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt > > > > diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt > > b/Documentation/devicetree/bindings/hwlock/hwlock.txt > > new file mode 100644 > > index ..8de7aaf878f9 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt > > @@ -0,0 +1,55 @@ > > +Generic hwlock bindings > > +=== > > + > > +Generic bindings that are common to all the hwlock platform specific driver > > +implementations. > > + > > +The validity and need of these common properties may vary from one platform > > +implementation to another. The platform specific bindings should explicitly > > +state if an optional property is used. Please also look through the > > individual > > +platform specific hwlock binding documentations for identifying the > > applicable > > +properties. > > + > > +Common properties: > > +- #hwlock-cells: Specifies the number of cells needed to represent a > > + specific lock. This property is mandatory for all > > + platform implementations. > > +- hwlock-num-locks:Number of locks present in a hwlock device. This > > + property is needed on hwlock devices, where the number > > + of supported locks within a hwlock device cannot be > > + read from a register. > > +- hwlock-base-id: An unique base Id for the locks for a particular hwlock > > + device. This property is mandatory for all platform > > + implementations. > > This property makes no sense. The ID encoded in the hwlock cells is > relative to the instance (identified by phandle), not global. So the DT > has no global ID space. > > Why do you think you need this? Having looked at the way this proeprty is used, NAK. If you need to carve up a Linux-internal ID space, do that dynamically. There is no need for this property. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tracing: Allow raw_syscall tracepoints to work from boot
On Thu, 15 Jan 2015 17:10:40 +1100 Michael Ellerman wrote: > > > > I don't like setting the swap task flag for syscall tracing, as > > nothing will unset it. > > We could unset it in the unregfunc(), I did that in my original patch > but took it out because I wasn't sure it was necessary. Yes we could but that shows the issue with this approach. We can not just use for_each_process_thread(). swapper is special, and we really shouldn't touch it for this special case (cmdline usage). > > Actually I thought it was neat, basically everything else comes from > init_task via copy_process(). Yes, but only at boot up. After that, the swapper is not part of the game. That's why its not part of for_each_process_thread(). > > > Try my patch and let me know if it works for you? > > Sure. It works. > > I can still see the first syscalls in the trace: > > # entries-in-buffer/entries-written: 1021354/1021354 #P:8 > # > # _-=> irqs-off > # / _=> need-resched > #| / _---=> hardirq/softirq > #|| / _--=> preempt-depth > #||| / delay > # TASK-PID CPU# TIMESTAMP FUNCTION > # | | | | | > init-1 [000] 3.706370: sys_exit: NR -1 = > 0 init-1 [000] 3.706394: sys_enter: NR 45 (0, 0, > 3fffa2e2, 3fffcfd4eac2, 80, 3fffa2e61820) init-1 > [000] 3.706395: sys_exit: NR 45 = 70367490932736 init-1 > [000] 3.706409: sys_enter: NR 33 (3fffa2e694d0, 0, > 3fffa2e7be20, 0, 1, e000) init-1 [000] > 3.713325: sys_exit: NR 33 = -2 > > I like my version better, but your call. Of course you do :-) I thought about it a bit, and both versions are really hacks. But in the end, I'd rather not touch the swapper task because that might give us some unwanted side effects. I don't really like my approach where I need to disable and re-enable all tracepoints. I was thinking of only enabling and disabling just the syscall ones, but I could imagine another tracepoint with a reg that could be affected by early boot as well, so I left it touching all events. My patch is fine for mainline, but I could make a patch for 3.20 that will only restart a tracepoint if it has its own reg/unreg functions and does not use the default ones. Your patch fixes syscall events. I wanted something that will fix any event with its own special registration that might also use for_each_process_thread() or some other call that does not work before init is created. Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: gpio: fix bindings document
Hi Yamada-san, Thank you for the patch. On Thursday 15 January 2015 17:52:40 Masahiro Yamada wrote: > Signed-off-by: Masahiro Yamada Acked-by: Laurent Pinchart > --- > > Documentation/devicetree/bindings/gpio/gpio.txt | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt > b/Documentation/devicetree/bindings/gpio/gpio.txt index b9bd1d6..f7a158d > 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio.txt > @@ -69,7 +69,8 @@ GPIO pin number, and GPIO flags as accepted by the > "qe_pio_e" gpio-controller. -- > > A gpio-specifier should contain a flag indicating the GPIO polarity; > active- -high or active-low. If it does, the follow best practices should > be followed: +high or active-low. If it does, the following best practices > should be +followed: > > The gpio-specifier's polarity flag should represent the physical level at > the GPIO controller that achieves (or represents, for inputs) a logically > asserted @@ -147,7 +148,7 @@ contains information structures as follows: > numeric-gpio-range ::= > > named-gpio-range ::= '<0 0>' > - gpio-phandle : phandle to pin controller node. > + pinctrl-phandle : phandle to pin controller node > gpio-base : Base GPIO ID in the GPIO controller > pinctrl-base : Base pinctrl pin ID in the pin controller > count : The number of GPIOs/pins in this range -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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:x86/apic] x86/apic: Kill useless variable x2apic_enabled in function enable_IR_x2apic()
Commit-ID: 7f530a2771fe7ea6a068340c9e22f814edfcc3c4
Gitweb: http://git.kernel.org/tip/7f530a2771fe7ea6a068340c9e22f814edfcc3c4
Author: Jiang Liu
AuthorDate: Wed, 7 Jan 2015 15:31:32 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 15 Jan 2015 11:24:22 +0100
x86/apic: Kill useless variable x2apic_enabled in function enable_IR_x2apic()
Local variable x2apic_enabled has been assigned to but never referred,
so kill it.
Signed-off-by: Jiang Liu
Cc: Tony Luck
Cc: io...@lists.linux-foundation.org
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Benjamin Herrenschmidt
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: David Rientjes
Cc: HATAYAMA Daisuke
Cc: Jan Beulich
Cc: Richard Weinberger
Cc: Oren Twaig
Link:
http://lkml.kernel.org/r/1420615903-28253-6-git-send-email-jiang@linux.intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 5446733..2dbd3a0 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1595,7 +1595,7 @@ int __init enable_IR(void)
void __init enable_IR_x2apic(void)
{
unsigned long flags;
- int ret, x2apic_enabled = 0;
+ int ret;
int hardware_init_ret;
if (!IS_ENABLED(CONFIG_X86_X2APIC)) {
@@ -1653,8 +1653,6 @@ void __init enable_IR_x2apic(void)
goto skip_x2apic;
}
- x2apic_enabled = 1;
-
if (x2apic_supported() && !x2apic_mode) {
x2apic_mode = 1;
enable_x2apic();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] ftrace: Check both notrace and filter for old hash
On Thu, 15 Jan 2015 19:59:36 +0900
Masami Hiramatsu wrote:
> > @@ -3637,6 +3639,7 @@ int
> > register_ftrace_function_probe(char *glob, struct ftrace_probe_ops
> > *ops, void *data)
> > {
> > + struct ftrace_ops_hash old_hash_ops;
>
> Would it be better to be old_ops_hash? since it's not an ops.
Probably. I'll fix it for 3.20. I ran this through 9 hours of testing
and I don't want to change anything unless I need to (if something else
needs to change, I'll make this fix). Even a comment fix needs to go
through my testing before I send to Linus (I was burnt by a comment
fix that wasn't tested a long time ago, you never know what you might
accidentally change).
>
> Other parts are OK for me :)
>
> Reviewed-by: Masami Hiramatsu
>
Thanks!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8] ASoC: dapm: add code to configure dai link parameters
dai-link params for codec-codec links were fixed. The fixed
link between codec and another chip which may be another codec,
baseband, bluetooth codec etc may require run time configuaration
changes. This change provides an optional alsa control to select
one of the params from a list of params.
Signed-off-by: Nikesh Oswal
---
include/sound/soc-dapm.h |3 +
include/sound/soc.h |1 +
sound/soc/soc-core.c |6 +-
sound/soc/soc-dapm.c | 155 --
4 files changed, 157 insertions(+), 8 deletions(-)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index 5c0a798..a2098e4 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -378,6 +378,7 @@ int snd_soc_dapm_link_dai_widgets(struct snd_soc_card
*card);
void snd_soc_dapm_connect_dai_link_widgets(struct snd_soc_card *card);
int snd_soc_dapm_new_pcm(struct snd_soc_card *card,
const struct snd_soc_pcm_stream *params,
+unsigned int num_params,
struct snd_soc_dapm_widget *source,
struct snd_soc_dapm_widget *sink);
@@ -531,6 +532,8 @@ struct snd_soc_dapm_widget {
void *priv; /* widget specific data */
struct regulator *regulator;/* attached regulator */
const struct snd_soc_pcm_stream *params; /* params for dai links */
+ unsigned int num_params; /* number of params for dai links */
+ unsigned int params_select; /* currently selected param for dai link */
/* dapm control */
int reg;/* negative reg = no direct
dapm */
diff --git a/include/sound/soc.h b/include/sound/soc.h
index edd4a0a..7556885 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -940,6 +940,7 @@ struct snd_soc_dai_link {
int be_id; /* optional ID for machine driver BE identification */
const struct snd_soc_pcm_stream *params;
+ unsigned int num_params;
unsigned int dai_fmt; /* format to set on init */
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index ededb97..893a6e5 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1230,7 +1230,8 @@ static int soc_link_dai_widgets(struct snd_soc_card *card,
capture_w = cpu_dai->capture_widget;
if (play_w && capture_w) {
ret = snd_soc_dapm_new_pcm(card, dai_link->params,
- capture_w, play_w);
+ dai_link->num_params, capture_w,
+ play_w);
if (ret != 0) {
dev_err(card->dev, "ASoC: Can't link %s to %s: %d\n",
play_w->name, capture_w->name, ret);
@@ -1242,7 +1243,8 @@ static int soc_link_dai_widgets(struct snd_soc_card *card,
capture_w = codec_dai->capture_widget;
if (play_w && capture_w) {
ret = snd_soc_dapm_new_pcm(card, dai_link->params,
- capture_w, play_w);
+ dai_link->num_params, capture_w,
+ play_w);
if (ret != 0) {
dev_err(card->dev, "ASoC: Can't link %s to %s: %d\n",
play_w->name, capture_w->name, ret);
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index bc2d7a0..286413b 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -853,6 +853,36 @@ static int dapm_new_pga(struct snd_soc_dapm_widget *w)
return 0;
}
+/* create new dapm dai link control */
+static int dapm_new_dai_link(struct snd_soc_dapm_widget *w)
+{
+ int i, ret;
+ struct snd_kcontrol *kcontrol;
+ struct snd_soc_dapm_context *dapm = w->dapm;
+ struct snd_card *card = dapm->card->snd_card;
+
+ /* create control for links with > 1 config */
+ if (w->num_params <= 1)
+ return 0;
+
+ /* add kcontrol */
+ for (i = 0; i < w->num_kcontrols; i++) {
+ kcontrol = snd_soc_cnew(>kcontrol_news[i], w,
+ w->name, NULL);
+ ret = snd_ctl_add(card, kcontrol);
+ if (ret < 0) {
+ dev_err(dapm->dev,
+ "ASoC: failed to add widget %s dapm kcontrol
%s: %d\n",
+ w->name, w->kcontrol_news[i].name, ret);
+ return ret;
+ }
+ kcontrol->private_data = w;
+ w->kcontrols[i] = kcontrol;
+ }
+
+ return 0;
+}
+
/* We implement power down on suspend by checking the power state of
* the ALSA card - when we are suspending the ALSA state for the card
* is set to D3.
@@ -2724,6 +2754,9 @@ int snd_soc_dapm_new_widgets(struct snd_soc_card *card)
Re: [PATCH] Documentation: gpio: fix bindings document
On Thu, Jan 15, 2015 at 2:52 AM, Masahiro Yamada wrote: > Signed-off-by: Masahiro Yamada Perhaps some explanation. You can't just remove properties. Please explain to what extent the old/wrong name is used. This patch is only okay if there are no users of gpio-phandle. Rob > --- > > Documentation/devicetree/bindings/gpio/gpio.txt | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt > b/Documentation/devicetree/bindings/gpio/gpio.txt > index b9bd1d6..f7a158d 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio.txt > @@ -69,7 +69,8 @@ GPIO pin number, and GPIO flags as accepted by the > "qe_pio_e" gpio-controller. > -- > > A gpio-specifier should contain a flag indicating the GPIO polarity; active- > -high or active-low. If it does, the follow best practices should be followed: > +high or active-low. If it does, the following best practices should be > +followed: > > The gpio-specifier's polarity flag should represent the physical level at the > GPIO controller that achieves (or represents, for inputs) a logically > asserted > @@ -147,7 +148,7 @@ contains information structures as follows: > numeric-gpio-range ::= > > named-gpio-range ::= '<0 0>' > - gpio-phandle : phandle to pin controller node. > + pinctrl-phandle : phandle to pin controller node > gpio-base : Base GPIO ID in the GPIO controller > pinctrl-base : Base pinctrl pin ID in the pin controller > count : The number of GPIOs/pins in this range > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel][PATCH v2 2/2] ASoC: wm8960: Let wm8960 driver configure its bit clock and frame clock
On Wed, Jan 14, 2015 at 07:27:03PM +, Mark Brown wrote:
> On Wed, Jan 07, 2015 at 03:31:45PM +0800, Zidan Wang wrote:
>
> > + for (i = 0; i < ARRAY_SIZE(dac_divs); ++i) {
> > + if (wm8960->sysclk == lrclk * dac_divs[i]) {
> > + for (j = 0; j < ARRAY_SIZE(bclk_divs); ++j) {
> > + if (wm8960->sysclk == wm8960->bclk *
> > + bclk_divs[j] / 10) {
> > + goto config_clock;
> > + }
> > + }
> > + }
> > + }
> > +
> > + dev_err(codec->dev, "Unsupported sysclk %d\n", wm8960->sysclk);
> > + return;
>
> It's a bit awkward using the goto like this. A more common way of
> writing this is to change the above block to be
>
> if (i == ARRAY_SIZE(dac_divs))
> /* return error */
>
> rather than skipping over the error. Otherwise this looks good.
Hi Mark,
I found it can't generate bclk for S20_3LE data format.
For 2 channel S20_3LE data format:
bclk = fs * 20 * 2
Sysclk = BCLKDIV * bclk = BCLKDIV * fs * 40
Sysclk = DACDIV * fs * 256
BCLKDIV/DACDIV = 256/40 = 32/5
But BCLKDIV/DACDIV can't be 32/5. So I want to support tdm slot.
bclk = fs * slot_width * slots * channal.
Do you think it make sense, or any other ideas?
Best Regards,
Zidan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio_pci: add an option to disable legacy driver
Useful for testing device virtio 1 compatibility.
Based on patch by Rusty - couldn't resist putting
that flying car joke in there!
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_pci_common.h | 10 ++
drivers/virtio/Kconfig | 19 +++
drivers/virtio/Makefile| 3 ++-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index d391805..28ee4e5 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -147,8 +147,18 @@ const char *vp_bus_name(struct virtio_device *vdev);
*/
int vp_set_vq_affinity(struct virtqueue *vq, int cpu);
+#if IS_ENABLED(CONFIG_VIRTIO_PCI_LEGACY)
int virtio_pci_legacy_probe(struct virtio_pci_device *);
void virtio_pci_legacy_remove(struct virtio_pci_device *);
+#else
+static inline int virtio_pci_legacy_probe(struct virtio_pci_device *vp_dev)
+{
+ return -ENODEV;
+}
+static inline void virtio_pci_legacy_remove(struct virtio_pci_device *vp_dev)
+{
+}
+#endif
int virtio_pci_modern_probe(struct virtio_pci_device *);
void virtio_pci_modern_remove(struct virtio_pci_device *);
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 083fb45..b546da5 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -19,6 +19,25 @@ config VIRTIO_PCI
If unsure, say M.
+config VIRTIO_PCI_LEGACY
+ bool "Support for legacy virtio draft 0.9.X and older devices"
+ default y
+ depends on VIRTIO_PCI
+ ---help---
+ Virtio PCI Card 0.9.X Draft (circa 2014) and older device support.
+
+ This option enables building a transitional driver, supporting
+ both devices conforming to Virtio 1 specification, and legacy devices.
+ If disabled, you get a slightly smaller, non-transitional driver,
+ with no legacy compatibility.
+
+ So look out into your driveway. Do you have a flying car? If
+ so, you can happily disable this option and virtio will not
+ break. Otherwise, leave it set. Unless you're testing what
+ life will be like in The Future.
+
+ If unsure, say Y.
+
config VIRTIO_BALLOON
tristate "Virtio balloon driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index bd230d1..a7fa9a5 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
-virtio_pci-y := virtio_pci_modern.o virtio_pci_legacy.o virtio_pci_common.o
+virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
+virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) := virtio_pci_legacy.o
obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: gpio: fix bindings document
Hi Rob, On Thursday 15 January 2015 08:07:18 Rob Herring wrote: > On Thu, Jan 15, 2015 at 2:52 AM, Masahiro Yamada > > wrote: > > Signed-off-by: Masahiro Yamada > > Perhaps some explanation. You can't just remove properties. Please > explain to what extent the old/wrong name is used. This patch is only > okay if there are no users of gpio-phandle. As far as I understand the patch just fixes a typo. There has never been a gpio-phandle for GPIO controllers, only for GPIO consumers. > > --- > > > > Documentation/devicetree/bindings/gpio/gpio.txt | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt > > b/Documentation/devicetree/bindings/gpio/gpio.txt index b9bd1d6..f7a158d > > 100644 > > --- a/Documentation/devicetree/bindings/gpio/gpio.txt > > +++ b/Documentation/devicetree/bindings/gpio/gpio.txt > > @@ -69,7 +69,8 @@ GPIO pin number, and GPIO flags as accepted by the > > "qe_pio_e" gpio-controller.> > > -- > > > > A gpio-specifier should contain a flag indicating the GPIO polarity; > > active-> > > -high or active-low. If it does, the follow best practices should be > > followed: +high or active-low. If it does, the following best practices > > should be> > > +followed: > > The gpio-specifier's polarity flag should represent the physical level at > > the GPIO controller that achieves (or represents, for inputs) a > > logically asserted> > > @@ -147,7 +148,7 @@ contains information structures as follows: > > numeric-gpio-range ::= > > > > > > > > > > named-gpio-range ::= '<0 0>' > > > > - gpio-phandle : phandle to pin controller node. > > + pinctrl-phandle : phandle to pin controller node > > > > gpio-base : Base GPIO ID in the GPIO controller > > pinctrl-base : Base pinctrl pin ID in the pin controller > > count : The number of GPIOs/pins in this range -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64
On Tue, Jan 6, 2015 at 1:59 PM, Arnd Bergmann wrote: > On Tuesday 06 January 2015 11:20:01 Catalin Marinas wrote: >> On Mon, Jan 05, 2015 at 08:16:30PM +, Arnd Bergmann wrote: >> > On Monday 05 January 2015 13:13:02 Catalin Marinas wrote: >> > > > since passing no DT tables to OS but >> > > > acpi=force is missing is a corner case, we can do a follow up patch to >> > > > fix that, does it make sense? >> > > >> > > Not entirely. Why would no dtb and no acpi=force be a corner case? I >> > > thought this should be the default when only ACPI tables are passed, no >> > > need for an additional acpi=force argument. >> > >> > We don't really support the case of only ACPI tables for now. The >> > expectation >> > is that you always have working DT support, at least for the next few years >> > as ACPI features are ramping up, and without acpi=force it should not try >> > to use ACPI at all. >> >> So if both DT and ACPI are present, just use DT unless acpi=force is >> passed. So far I think we agree but what I want to avoid is always >> mandating acpi=force even when the DT tables are missing (in the long >> run). >> >> Now, what's preventing a vendor firmware from providing only ACPI >> tables? Do we enforce it in some way (arm-acpi.txt, kernel warning etc.) >> that both DT and ACPI are supported, or at least that dts files are >> merged in the kernel first? > > We have no way of enforcing what a board vendor ships, so if they want > to have ACPI-only machines for MS Windows, they just won't work by > default on Linux. Once ACPI support is mature enough, we can also > have a whitelist or a different default for using it automatically > when no DT is present. > > For drivers merged upstream, I would insist that every driver merged > for an ARM64 platform has a documented DT binding that is used in the > driver. That's a dumb rule. It will result in untested DT code paths being thrown into drivers just too meet the rules rather than on whether or not they will actually be used. It's fine to allow driver authors to only implement the ACPI code path if that is what they are working with. We can *always* add a DT path to the driver when it is needed. As you say, wecannot insist that vendors implement DT as well as ACPI. The most we can do is offer the recommendation that DT works now, but ACPI is immature for ARM. If they choose to do ACPI only, that is absolutely fine and they do so with the understanding that it will take time to stabilize to the point that we're comfortable guaranteeing support in mainline. However, that doesn't even remotely block getting each of their drivers merged as they become ready. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 12 (build failures: m68k, ppc)
On 01/15/2015 02:12 AM, Geert Uytterhoeven wrote: On Mon, Jan 12, 2015 at 6:59 PM, Guenter Roeck wrote: Build failures, seen since next-20150109: m68k:allmodconfig powerpc:ppc6xx_defconfig It looks like parisc is also suffering: http://kisskb.ellerman.id.au/kisskb/buildresult/12343847/ Due to: ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined! make[1]: *** [__modpost] Error 1 Caused by commit d34f20d6e2f (drm: Atomic modeset ioctl). Yeah, it needs a get_user() that supports 64-bit data. Hi Geert, I assume you mean m68k, where 64 bit support for get_user has been disabled. The problem on powerpc is different though: __get_user_nocheck() and __get_user_check() use unsigned long __gu_val; followed by __get_user_size(__gu_val, __gu_addr, (size), __gu_err); __get_user_size() fails in if (size > sizeof(x)) (x) = __get_user_bad(); Presumably "unsigned long" is 32 bit on 32 bit powerpc, not 64 bit. Overall, the explicit 64-bit use of get_user() seems to be quite unusual. I noticed you've sent a fix for DRM. Doh, and I was just fixing m68k... Sorry, should have Cc:'d you. 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 0/4] ata: libahci: Allow using a regulator for each port
The current implementation of the libahci allows using one PHY per port but we still have one single regulator for the whole controller. This series adds the support of multiple regulators. This is the forth version of the series. The improvement of this version is the use of ahci_platform_put_resources to put the reference to the regulators. Thanks, Gr??gory Changelog: v3 -> v4 - Moved putting the reference to the regulators into the ahci_platform_put_resources function. - Tested the port_dev pointer before dereferencing. v2 -> v3: - put back the regulator inside the sub-node ports - made the ports platform devices when the device tree is used - released the regulator in case of error in the probe function v1 -> v2: - Kept the case when no child node are present under the ahci node - Fix the test done under the label disable_target_pwrs - No more use an of_ version of the regulator framework and instead associate each regulator of a port with an unique name. - Added the acked-by on the clean-up patch Gregory CLEMENT (4): ata: libahci: Clean-up the ahci_platform_en/disable_phys functions Documentation: bindings: Add the regulator property to the sub-nodes AHCI bindings ata: libahci: Allow using multiple regulators ARM: mvebu: Armada 385 GP: Add regulators to the SATA port .../devicetree/bindings/ata/ahci-platform.txt | 9 +- arch/arm/boot/dts/armada-388-gp.dts| 126 +++ drivers/ata/ahci.h | 2 +- drivers/ata/ahci_imx.c | 14 +- drivers/ata/libahci_platform.c | 236 ++--- include/linux/ahci_platform.h | 2 + 6 files changed, 305 insertions(+), 84 deletions(-) -- 1.9.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 0/7] AT91 cleanup for 3.20 #1
Le 12/01/2015 20:26, Boris Brezillon a écrit :
> Hi Alexandre,
>
> On Mon, 12 Jan 2015 19:42:09 +0100
> Alexandre Belloni wrote:
>
>> Hi,
>>
>> This patch set cleans a lot of remaining header, config options and functions
>> that are not used anymore since the switch to DT only.
>>
>> Patch 5 is moving mach/debug-macro.S to include/debug/at91.S to prepare the
>> upcoming switch to multiplatform.
>>
>
> Thanks for those cleanup changes.
>
> To the whole series:
>
> Acked-by: Boris Brezillon
Acked-by: Nicolas Ferre
With the change noted in patch 6/7, all queued on at91-3.20-at91. Thanks.
>> Alexandre Belloni (7):
>> ARM: at91: remove unused mach/memory.h
>> ARM: at91: remove useless config MACH_AT91RM9200_DT
>> ARM: at91: remove useless config MACH_AT91SAM9_DT
>> ARM: at91: remove useless at91_sysirq_mask_rtx
>> ARM: at91: move debug-macro.S into the common space
>> ARM: at91: remove useless at91rm9200_dt_initialize()
>> ARM: at91: remove useless at91rm9200_set_type()
>>
>> MAINTAINERS| 1 +
>> arch/arm/Kconfig.debug | 9 ++-
>> .../mach/debug-macro.S => include/debug/at91.S}| 19 +++---
>> arch/arm/mach-at91/Kconfig | 8 ---
>> arch/arm/mach-at91/Makefile| 6 +-
>> arch/arm/mach-at91/at91sam9260.c | 2 -
>> arch/arm/mach-at91/at91sam9261.c | 2 -
>> arch/arm/mach-at91/at91sam9263.c | 3 -
>> arch/arm/mach-at91/at91sam9g45.c | 3 -
>> arch/arm/mach-at91/at91sam9n12.c | 6 --
>> arch/arm/mach-at91/at91sam9rl.c| 3 -
>> arch/arm/mach-at91/at91sam9x5.c| 10 ---
>> arch/arm/mach-at91/board-dt-rm9200.c | 2 +-
>> arch/arm/mach-at91/generic.h | 6 --
>> arch/arm/mach-at91/include/mach/at91_rtt.h | 35 --
>> arch/arm/mach-at91/include/mach/memory.h | 26
>> arch/arm/mach-at91/sama5d3.c | 6 --
>> arch/arm/mach-at91/setup.c | 18 --
>> arch/arm/mach-at91/sysirq_mask.c | 75
>> --
>> 19 files changed, 23 insertions(+), 217 deletions(-)
>> rename arch/arm/{mach-at91/include/mach/debug-macro.S =>
>> include/debug/at91.S} (68%)
>> delete mode 100644 arch/arm/mach-at91/include/mach/at91_rtt.h
>> delete mode 100644 arch/arm/mach-at91/include/mach/memory.h
>> delete mode 100644 arch/arm/mach-at91/sysirq_mask.c
>>
>
>
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] Documentation: bindings: Add the regulator property to the sub-nodes AHCI bindings
It is now possible to use a regulator property for each port of the
AHCI controller.
Signed-off-by: Gregory CLEMENT
---
Documentation/devicetree/bindings/ata/ahci-platform.txt | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 4ab09f2202d4..c2340eeeb97f 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -37,9 +37,10 @@ Required properties when using sub-nodes:
Sub-nodes required properties:
-- reg : the port number
-- phys : reference to the SATA PHY node
-
+- reg : the port number
+And at least one of the following properties:
+- phys : reference to the SATA PHY node
+- target-supply: regulator for SATA target power
Examples:
sata@ffe08000 {
@@ -68,10 +69,12 @@ With sub-nodes:
sata0: sata-port@0 {
reg = <0>;
phys = <_phy 0>;
+ target-supply = <_sata0>;
};
sata1: sata-port@1 {
reg = <1>;
phys = <_phy 1>;
+ target-supply = <_sata1>;;
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/4] ARM: mvebu: Armada 385 GP: Add regulators to the SATA port
Add the regulators to each SATA port.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-388-gp.dts | 126
1 file changed, 126 insertions(+)
diff --git a/arch/arm/boot/dts/armada-388-gp.dts
b/arch/arm/boot/dts/armada-388-gp.dts
index 4df22bf91683..590b383db323 100644
--- a/arch/arm/boot/dts/armada-388-gp.dts
+++ b/arch/arm/boot/dts/armada-388-gp.dts
@@ -173,6 +173,16 @@
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
+
+ sata0: sata-port@0 {
+ reg = <0>;
+ target-supply = <_5v_sata0>;
+ };
+
+ sata1: sata-port@1 {
+ reg = <1>;
+ target-supply = <_5v_sata1>;
+ };
};
sata@e {
@@ -181,6 +191,16 @@
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
+
+ sata2: sata-port@0 {
+ reg = <0>;
+ target-supply = <_5v_sata2>;
+ };
+
+ sata3: sata-port@1 {
+ reg = <1>;
+ target-supply = <_5v_sata3>;
+ };
};
sdhci@d8000 {
@@ -278,6 +298,112 @@
regulator-always-on;
gpio = < 4 GPIO_ACTIVE_HIGH>;
};
+
+ reg_sata0: pwr-sata0 {
+ compatible = "regulator-fixed";
+ regulator-name = "pwr_en_sata0";
+ enable-active-high;
+ regulator-always-on;
+
+ };
+
+ reg_5v_sata0: v5-sata0 {
+ compatible = "regulator-fixed";
+ regulator-name = "v5.0-sata0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <_sata0>;
+ };
+
+ reg_12v_sata0: v12-sata0 {
+ compatible = "regulator-fixed";
+ regulator-name = "v12.0-sata0";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ vin-supply = <_sata0>;
+ };
+
+ reg_sata1: pwr-sata1 {
+ regulator-name = "pwr_en_sata1";
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ enable-active-high;
+ regulator-always-on;
+ gpio = < 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_5v_sata1: v5-sata1 {
+ compatible = "regulator-fixed";
+ regulator-name = "v5.0-sata1";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <_sata1>;
+ };
+
+ reg_12v_sata1: v12-sata1 {
+ compatible = "regulator-fixed";
+ regulator-name = "v12.0-sata1";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ vin-supply = <_sata1>;
+ };
+
+ reg_sata2: pwr-sata2 {
+ compatible = "regulator-fixed";
+ regulator-name = "pwr_en_sata2";
+ enable-active-high;
+ regulator-always-on;
+ gpio = < 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_5v_sata2: v5-sata2 {
+ compatible = "regulator-fixed";
+ regulator-name = "v5.0-sata2";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <_sata2>;
+ };
+
+ reg_12v_sata2: v12-sata2 {
+ compatible = "regulator-fixed";
+ regulator-name = "v12.0-sata2";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ vin-supply = <_sata2>;
+ };
+
+ reg_sata3: pwr-sata3 {
+ compatible = "regulator-fixed";
+ regulator-name = "pwr_en_sata3";
+ enable-active-high;
+ regulator-always-on;
+ gpio = < 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_5v_sata3: v5-sata3 {
+ compatible = "regulator-fixed";
+
[PATCH v4 3/4] ata: libahci: Allow using multiple regulators
The current implementation of the libahci allows using multiple PHYs
but not multiple regulators. This patch adds the support of multiple
regulators. Until now it was mandatory to have a PHY under a subnode,
now a port subnode can contain either a regulator or a PHY (or both).
In order to be able to asociate a port with a regulator the port are
now a platform device in the device tree case.
There was only one driver which used directly the regulator field of
the ahci_host_priv structure. To preserve the bisectability the change
in the ahci_imx driver was done in the same patch.
Signed-off-by: Gregory CLEMENT
---
drivers/ata/ahci.h | 2 +-
drivers/ata/ahci_imx.c | 14 +--
drivers/ata/libahci_platform.c | 230 +
include/linux/ahci_platform.h | 2 +
4 files changed, 173 insertions(+), 75 deletions(-)
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 40f0e34f17af..275358ae0b3f 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -333,7 +333,7 @@ struct ahci_host_priv {
u32 em_msg_type;/* EM message type */
boolgot_runtime_pm; /* Did we do pm_runtime_get? */
struct clk *clks[AHCI_MAX_CLKS]; /* Optional */
- struct regulator*target_pwr;/* Optional */
+ struct regulator**target_pwrs; /* Optional */
/*
* If platform uses PHYs. There is a 1:1 relation between the port
number and
* the PHY position in this array.
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 35d51c59a370..41632e57d46f 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -221,11 +221,9 @@ static int imx_sata_enable(struct ahci_host_priv *hpriv)
if (imxpriv->no_device)
return 0;
- if (hpriv->target_pwr) {
- ret = regulator_enable(hpriv->target_pwr);
- if (ret)
- return ret;
- }
+ ret = ahci_platform_enable_regulators(hpriv);
+ if (ret)
+ return ret;
ret = clk_prepare_enable(imxpriv->sata_ref_clk);
if (ret < 0)
@@ -270,8 +268,7 @@ static int imx_sata_enable(struct ahci_host_priv *hpriv)
disable_clk:
clk_disable_unprepare(imxpriv->sata_ref_clk);
disable_regulator:
- if (hpriv->target_pwr)
- regulator_disable(hpriv->target_pwr);
+ ahci_platform_disable_regulators(hpriv);
return ret;
}
@@ -291,8 +288,7 @@ static void imx_sata_disable(struct ahci_host_priv *hpriv)
clk_disable_unprepare(imxpriv->sata_ref_clk);
- if (hpriv->target_pwr)
- regulator_disable(hpriv->target_pwr);
+ ahci_platform_disable_regulators(hpriv);
}
static void ahci_imx_error_handler(struct ata_port *ap)
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index a147aaadca85..73a086664ee7 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "ahci.h"
static void ahci_host_stop(struct ata_host *host);
@@ -138,6 +139,59 @@ void ahci_platform_disable_clks(struct ahci_host_priv
*hpriv)
EXPORT_SYMBOL_GPL(ahci_platform_disable_clks);
/**
+ * ahci_platform_enable_regulators - Enable regulators
+ * @hpriv: host private area to store config values
+ *
+ * This function enables all the regulators found in
+ * hpriv->target_pwrs, if any. If a regulator fails to be enabled, it
+ * disables all the regulators already enabled in reverse order and
+ * returns an error.
+ *
+ * RETURNS:
+ * 0 on success otherwise a negative error code
+ */
+int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv)
+{
+ int rc, i;
+
+ for (i = 0; i < hpriv->nports; i++) {
+ if (!hpriv->target_pwrs[i])
+ continue;
+
+ rc = regulator_enable(hpriv->target_pwrs[i]);
+ if (rc)
+ goto disable_target_pwrs;
+ }
+
+ return 0;
+
+disable_target_pwrs:
+ while (--i >= 0)
+ if (hpriv->target_pwrs[i])
+ regulator_disable(hpriv->target_pwrs[i]);
+
+ return rc;
+}
+EXPORT_SYMBOL_GPL(ahci_platform_enable_regulators);
+
+/**
+ * ahci_platform_disable_regulators - Disable regulators
+ * @hpriv: host private area to store config values
+ *
+ * This function disables all regulators found in hpriv->target_pwrs.
+ */
+void ahci_platform_disable_regulators(struct ahci_host_priv *hpriv)
+{
+ int i;
+
+ for (i = 0; i < hpriv->nports; i++) {
+ if (!hpriv->target_pwrs[i])
+ continue;
+ regulator_disable(hpriv->target_pwrs[i]);
+ }
+}
+EXPORT_SYMBOL_GPL(ahci_platform_disable_regulators);
+/**
* ahci_platform_enable_resources - Enable platform resources
* @hpriv: host private area to store config values
*
@@
[PATCH v4 1/4] ata: libahci: Clean-up the ahci_platform_en/disable_phys functions
The phy_ functions handle the NULL pointer case, so there is no need
to skip them if there is a NULL pointer. Moreover, after the error
label there is already no check on the pointer. This patch removes the
unnecessary tests and brings some consistency.
Signed-off-by: Gregory CLEMENT
Acked-by: Hans de Goede
---
drivers/ata/libahci_platform.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 0b03f9056692..a147aaadca85 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -54,9 +54,6 @@ static int ahci_platform_enable_phys(struct ahci_host_priv
*hpriv)
int rc, i;
for (i = 0; i < hpriv->nports; i++) {
- if (!hpriv->phys[i])
- continue;
-
rc = phy_init(hpriv->phys[i]);
if (rc)
goto disable_phys;
@@ -89,9 +86,6 @@ static void ahci_platform_disable_phys(struct ahci_host_priv
*hpriv)
int i;
for (i = 0; i < hpriv->nports; i++) {
- if (!hpriv->phys[i])
- continue;
-
phy_power_off(hpriv->phys[i]);
phy_exit(hpriv->phys[i]);
}
--
1.9.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] virtio_balloon: coding style fixes
On Thu 15-01-15 15:44:12, Michael S. Tsirkin wrote:
> On Thu, Jan 15, 2015 at 02:06:42PM +0100, Michal Hocko wrote:
> > On Thu 15-01-15 13:39:06, Michael S. Tsirkin wrote:
> > > Most of our code has
> > > struct foo {
> > > }
> > >
> > > Fix two instances where balloon is inconsistent.
> >
> > I hate to complain but is it really necessary to post such patches to
> > linux-api?
>
> Well it's human to err, so it seems wise to copy parties
> interested in the ABI/API whenever we are changing files under include/uapi.
> Whitespace changes should mostly be safe, but it's not unknown
> e.g. to include unrelated changes in the same commit by mistake.
>
> > I thought the list was primarily for API related discussions.
>
> Basically this line in MAINTAINERS
>
> ABI/API
> L: linux-...@vger.kernel.org
> F: Documentation/ABI/
> F: include/linux/syscalls.h
> F: include/uapi/
> F: kernel/sys_ni.c
>
> normally means "send all patches affecting files under include/uapi/ to
> this list", does it not?
Well, this should always be taken as a hint not a hard rule. So if there
is a change which is adding/removing or changing signature then sure but
not everything falls into that category.
> Wasn't this the intent?
>
> > This is not the only mail sent here which doesn't fall into that
> > category IMO. It is far from low volume list for quite some time.
> >
> > Please let's get back low volume and API only discussion!
>
> Maybe send patch dropping include/uapi/ from there,
> should help drive the volumes down?
This would be an overkill IMO. It would be much more preferable if
people actually think about who from the suggested list (either from
MAINTAINERS or ./scripts/get_maintainer.pl) should be really added.
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next v5 1/4] netns: add rtnl cmd to add and get peer netns ids
With this patch, a user can define an id for a peer netns by providing a FD or a
PID. These ids are local to the netns where it is added (ie valid only into this
netns).
The main function (ie the one exported to other module), peernet2id(), allows to
get the id of a peer netns. If no id has been assigned by the user, this
function allocates one.
These ids will be used in netlink messages to point to a peer netns, for example
in case of a x-netns interface.
Signed-off-by: Nicolas Dichtel
---
MAINTAINERS| 1 +
include/net/net_namespace.h| 4 +
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/net_namespace.h | 23
include/uapi/linux/rtnetlink.h | 5 +
net/core/net_namespace.c | 210 +
6 files changed, 244 insertions(+)
create mode 100644 include/uapi/linux/net_namespace.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 9de900572633..9b91d9f0257e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6578,6 +6578,7 @@ F:include/linux/netdevice.h
F: include/uapi/linux/in.h
F: include/uapi/linux/net.h
F: include/uapi/linux/netdevice.h
+F: include/uapi/linux/net_namespace.h
F: tools/net/
F: tools/testing/selftests/net/
F: lib/random32.c
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 2e8756b8c775..36faf4990c4b 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -60,6 +60,7 @@ struct net {
struct list_headexit_list; /* Use only net_mutex */
struct user_namespace *user_ns; /* Owning user namespace */
+ struct idr netns_ids;
struct ns_commonns;
@@ -290,6 +291,9 @@ static inline struct net *read_pnet(struct net * const
*pnet)
#define __net_initconst__initconst
#endif
+int peernet2id(struct net *net, struct net *peer);
+struct net *get_net_ns_by_id(struct net *net, int id);
+
struct pernet_operations {
struct list_head list;
int (*init)(struct net *net);
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 00b100023c47..14b7b6e44c77 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -283,6 +283,7 @@ header-y += net.h
header-y += netlink_diag.h
header-y += netlink.h
header-y += netrom.h
+header-y += net_namespace.h
header-y += net_tstamp.h
header-y += nfc.h
header-y += nfs2.h
diff --git a/include/uapi/linux/net_namespace.h
b/include/uapi/linux/net_namespace.h
new file mode 100644
index ..778cd2c3ebf4
--- /dev/null
+++ b/include/uapi/linux/net_namespace.h
@@ -0,0 +1,23 @@
+/* Copyright (c) 2015 6WIND S.A.
+ * Author: Nicolas Dichtel
+ *
+ * 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.
+ */
+#ifndef _UAPI_LINUX_NET_NAMESPACE_H_
+#define _UAPI_LINUX_NET_NAMESPACE_H_
+
+/* Attributes of RTM_NEWNSID/RTM_GETNSID messages */
+enum {
+ NETNSA_NONE,
+#define NETNSA_NSID_NOT_ASSIGNED -1
+ NETNSA_NSID,
+ NETNSA_PID,
+ NETNSA_FD,
+ __NETNSA_MAX,
+};
+
+#define NETNSA_MAX (__NETNSA_MAX - 1)
+
+#endif /* _UAPI_LINUX_NET_NAMESPACE_H_ */
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index a1d18593f41e..5cc5d66bf519 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -132,6 +132,11 @@ enum {
RTM_GETMDB = 86,
#define RTM_GETMDB RTM_GETMDB
+ RTM_NEWNSID = 88,
+#define RTM_NEWNSID RTM_NEWNSID
+ RTM_GETNSID = 90,
+#define RTM_GETNSID RTM_GETNSID
+
__RTM_MAX,
#define RTM_MAX(((__RTM_MAX + 3) & ~3) - 1)
};
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index ce780c722e48..edf089dd792a 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -15,6 +15,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -144,6 +148,77 @@ static void ops_free_list(const struct pernet_operations
*ops,
}
}
+static int alloc_netid(struct net *net, struct net *peer, int reqid)
+{
+ int min = 0, max = 0;
+
+ ASSERT_RTNL();
+
+ if (reqid >= 0) {
+ min = reqid;
+ max = reqid + 1;
+ }
+
+ return idr_alloc(>netns_ids, peer, min, max, GFP_KERNEL);
+}
+
+/* This function is used by idr_for_each(). If net is equal to peer, the
+ * function returns the id so that idr_for_each() stops. Because we cannot
+ * returns the id 0 (idr_for_each() will not stop), we return the magic value
+ * NET_ID_ZERO (-1) for it.
+ */
+#define NET_ID_ZERO -1
+static int net_eq_idr(int id, void *net, void *peer)
+{
+ if (net_eq(net, peer))
+ return id ? : NET_ID_ZERO;
+ return 0;
+}
+
+static int __peernet2id(struct net *net, struct net
[PATCH net-next v5 2/4] rtnl: add link netns id to interface messages
This patch adds a new attribute (IFLA_LINK_NETNSID) which contains the 'link'
netns id when this netns is different from the netns where the interface
stands (for example for x-net interfaces like ip tunnels).
With this attribute, it's possible to interpret correctly all advertised
information (like IFLA_LINK, etc.).
Signed-off-by: Nicolas Dichtel
---
include/net/rtnetlink.h | 2 ++
include/uapi/linux/if_link.h | 1 +
net/core/rtnetlink.c | 13 +
3 files changed, 16 insertions(+)
diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
index e21b9f9653c0..6c6d5393fc34 100644
--- a/include/net/rtnetlink.h
+++ b/include/net/rtnetlink.h
@@ -46,6 +46,7 @@ static inline int rtnl_msg_family(const struct nlmsghdr *nlh)
* to create when creating a new device.
* @get_num_rx_queues: Function to determine number of receive queues
* to create when creating a new device.
+ * @get_link_net: Function to get the i/o netns of the device
*/
struct rtnl_link_ops {
struct list_headlist;
@@ -93,6 +94,7 @@ struct rtnl_link_ops {
int (*fill_slave_info)(struct sk_buff *skb,
const struct net_device *dev,
const struct net_device
*slave_dev);
+ struct net *(*get_link_net)(const struct net_device *dev);
};
int __rtnl_link_register(struct rtnl_link_ops *ops);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 2a8380edbb7e..0deee3eeddbf 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -146,6 +146,7 @@ enum {
IFLA_PHYS_PORT_ID,
IFLA_CARRIER_CHANGES,
IFLA_PHYS_SWITCH_ID,
+ IFLA_LINK_NETNSID,
__IFLA_MAX
};
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 6a6cdade1676..ab78ba9a34e8 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -875,6 +875,7 @@ static noinline size_t if_nlmsg_size(const struct
net_device *dev,
+ nla_total_size(1) /* IFLA_OPERSTATE */
+ nla_total_size(1) /* IFLA_LINKMODE */
+ nla_total_size(4) /* IFLA_CARRIER_CHANGES */
+ + nla_total_size(4) /* IFLA_LINK_NETNSID */
+ nla_total_size(ext_filter_mask
& RTEXT_FILTER_VF ? 4 : 0) /* IFLA_NUM_VF */
+ rtnl_vfinfo_size(dev, ext_filter_mask) /* IFLA_VFINFO_LIST */
@@ -1169,6 +1170,18 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct
net_device *dev,
goto nla_put_failure;
}
+ if (dev->rtnl_link_ops &&
+ dev->rtnl_link_ops->get_link_net) {
+ struct net *link_net = dev->rtnl_link_ops->get_link_net(dev);
+
+ if (!net_eq(dev_net(dev), link_net)) {
+ int id = peernet2id(dev_net(dev), link_net);
+
+ if (nla_put_s32(skb, IFLA_LINK_NETNSID, id))
+ goto nla_put_failure;
+ }
+ }
+
if (!(af_spec = nla_nest_start(skb, IFLA_AF_SPEC)))
goto nla_put_failure;
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation/acpi: add the missing '='
Signed-off-by: Yaowei Bai --- Documentation/acpi/enumeration.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index b60d2ab..9b121a5 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -243,7 +243,7 @@ input driver: .owner = THIS_MODULE, .pm = _pm, .of_match_table = mpu3050_of_match, - .acpi_match_table ACPI_PTR(mpu3050_acpi_match), + .acpi_match_table = ACPI_PTR(mpu3050_acpi_match), }, .probe = mpu3050_probe, .remove = mpu3050_remove, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v5 3/4] tunnels: advertise link netns via netlink
Implement rtnl_link_ops->get_link_net() callback so that IFLA_LINK_NETNSID is
added to rtnetlink messages.
Signed-off-by: Nicolas Dichtel
---
drivers/net/vxlan.c | 8
include/net/ip6_tunnel.h | 1 +
include/net/ip_tunnels.h | 1 +
net/ipv4/ip_gre.c| 2 ++
net/ipv4/ip_tunnel.c | 8
net/ipv4/ip_vti.c| 1 +
net/ipv4/ipip.c | 1 +
net/ipv6/ip6_gre.c | 1 +
net/ipv6/ip6_tunnel.c| 9 +
net/ipv6/ip6_vti.c | 1 +
net/ipv6/sit.c | 1 +
11 files changed, 34 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 6b6b45622a0a..88dbb1edea6e 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2922,6 +2922,13 @@ nla_put_failure:
return -EMSGSIZE;
}
+static struct net *vxlan_get_link_net(const struct net_device *dev)
+{
+ struct vxlan_dev *vxlan = netdev_priv(dev);
+
+ return vxlan->net;
+}
+
static struct rtnl_link_ops vxlan_link_ops __read_mostly = {
.kind = "vxlan",
.maxtype= IFLA_VXLAN_MAX,
@@ -2933,6 +2940,7 @@ static struct rtnl_link_ops vxlan_link_ops __read_mostly
= {
.dellink= vxlan_dellink,
.get_size = vxlan_get_size,
.fill_info = vxlan_fill_info,
+ .get_link_net = vxlan_get_link_net,
};
static void vxlan_handle_lowerdev_unregister(struct vxlan_net *vn,
diff --git a/include/net/ip6_tunnel.h b/include/net/ip6_tunnel.h
index 9326c41c2d7f..76c091b53dae 100644
--- a/include/net/ip6_tunnel.h
+++ b/include/net/ip6_tunnel.h
@@ -70,6 +70,7 @@ int ip6_tnl_xmit_ctl(struct ip6_tnl *t, const struct in6_addr
*laddr,
__u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw);
__u32 ip6_tnl_get_cap(struct ip6_tnl *t, const struct in6_addr *laddr,
const struct in6_addr *raddr);
+struct net *ip6_tnl_get_link_net(const struct net_device *dev);
static inline void ip6tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
{
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index ce4db3cc5647..2c47061a6954 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -141,6 +141,7 @@ int ip_tunnel_encap_del_ops(const struct
ip_tunnel_encap_ops *op,
int ip_tunnel_init(struct net_device *dev);
void ip_tunnel_uninit(struct net_device *dev);
void ip_tunnel_dellink(struct net_device *dev, struct list_head *head);
+struct net *ip_tunnel_get_link_net(const struct net_device *dev);
int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
struct rtnl_link_ops *ops, char *devname);
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 942576e27df1..6e7727f27393 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -829,6 +829,7 @@ static struct rtnl_link_ops ipgre_link_ops __read_mostly = {
.dellink= ip_tunnel_dellink,
.get_size = ipgre_get_size,
.fill_info = ipgre_fill_info,
+ .get_link_net = ip_tunnel_get_link_net,
};
static struct rtnl_link_ops ipgre_tap_ops __read_mostly = {
@@ -843,6 +844,7 @@ static struct rtnl_link_ops ipgre_tap_ops __read_mostly = {
.dellink= ip_tunnel_dellink,
.get_size = ipgre_get_size,
.fill_info = ipgre_fill_info,
+ .get_link_net = ip_tunnel_get_link_net,
};
static int __net_init ipgre_tap_init_net(struct net *net)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index d3e447936720..2cd08280c77b 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -972,6 +972,14 @@ void ip_tunnel_dellink(struct net_device *dev, struct
list_head *head)
}
EXPORT_SYMBOL_GPL(ip_tunnel_dellink);
+struct net *ip_tunnel_get_link_net(const struct net_device *dev)
+{
+ struct ip_tunnel *tunnel = netdev_priv(dev);
+
+ return tunnel->net;
+}
+EXPORT_SYMBOL(ip_tunnel_get_link_net);
+
int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
struct rtnl_link_ops *ops, char *devname)
{
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 1a7e979e80ba..94efe148181c 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -531,6 +531,7 @@ static struct rtnl_link_ops vti_link_ops __read_mostly = {
.dellink= ip_tunnel_dellink,
.get_size = vti_get_size,
.fill_info = vti_fill_info,
+ .get_link_net = ip_tunnel_get_link_net,
};
static int __init vti_init(void)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 40403114f00a..b58d6689874c 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -498,6 +498,7 @@ static struct rtnl_link_ops ipip_link_ops __read_mostly = {
.dellink= ip_tunnel_dellink,
.get_size = ipip_get_size,
.fill_info = ipip_fill_info,
+ .get_link_net = ip_tunnel_get_link_net,
};
static struct xfrm_tunnel ipip_handler __read_mostly = {
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index
Re: [PATCH] pseries/le: Fix endiannes issue in RTAS call from xmon
On 15/01/2015 05:25, Michael Ellerman wrote:
> On Mon, 2014-11-24 at 15:07 +0100, Laurent Dufour wrote:
>> On pseries system (LPAR) xmon failed to enter when running in LE mode, system
>> is hunging. Inititating xmon will lead to such an output on the console:
>>
>> SysRq : Entering xmon
>> cpu 0x15: Vector: 0 at [c003f39ffb10]
>> pc: c007ed7c: sysrq_handle_xmon+0x5c/0x70
>> lr: c007ed7c: sysrq_handle_xmon+0x5c/0x70
>> sp: c003f39ffc70
>>msr: 80009033
>> current = 0xc003fafa7180
>> paca= 0xc7d75e80softe: 0irq_happened: 0x01
>> pid = 14617, comm = bash
>> Bad kernel stack pointer fafb4b0 at eca7cc4
>> cpu 0x15: Vector: 300 (Data Access) at [c7f07d40]
>> pc: 0eca7cc4
>> lr: 0eca7c44
>> sp: fafb4b0
>>msr: 80001000
>>dar: 1000
>> dsisr: 4200
>> current = 0xc003fafa7180
>> paca= 0xc7d75e80softe: 0irq_happened: 0x01
>> pid = 14617, comm = bash
>> cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
>> xmon: WARNING: bad recursive fault on cpu 0x15
>>
>> The root cause is that xmon is calling RTAS to turn off the surveillance
>> when entering xmon, and RTAS is requiring big endian parameters.
>>
>> This patch is byte swapping the RTAS arguments when running in LE mode.
>>
>> Signed-off-by: Laurent Dufour
>> ---
>> arch/powerpc/xmon/xmon.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>> index b988b5addf86..c8efbb37d6e0 100644
>> --- a/arch/powerpc/xmon/xmon.c
>> +++ b/arch/powerpc/xmon/xmon.c
>> @@ -293,10 +293,10 @@ static inline void disable_surveillance(void)
>> args.token = rtas_token("set-indicator");
>> if (args.token == RTAS_UNKNOWN_SERVICE)
>> return;
>
> I just noticed we're not handling the token correctly here. It is be32 also.
Ouch, my mistake :(
I will drop a new patch to complete this one.
Cheers.
> cheers
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next v5 0/4] netns: allow to identify peer netns
The goal of this serie is to be able to multicast netlink messages with an attribute that identify a peer netns. This is needed by the userland to interpret some information contained in netlink messages (like IFLA_LINK value, but also some other attributes in case of x-netns netdevice (see also http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)). Ids of peer netns can be set by userland via a new rtnl cmd RTM_NEWNSID. When the kernel needs an id for a peer (for example when advertising a new x-netns interface via netlink), if the user didn't allocate an id, one will be automatically allocated. These ids are stored per netns and are local (ie only valid in the netns where they are set). To avoid allocating an int for each peer netns, I use idr_for_each() to retrieve the id of a peer netns. Note that it will be possible to add a table (struct net -> id) later to optimize this lookup if needed. Patch 1/4 introduces the rtnetlink API mechanism to set and get these ids. Patch 2/4 and 3/4 implements an example of how to use these ids when advertising information about a x-netns interface. And patch 4/4 shows that the netlink messages can be symetric between a GET and a SET. iproute2 patches are available, I can send them on demand. Here is a small screenshot to show how it can be used by userland. # Initialization: $ ip netns add foo $ ip netns del foo $ ip netns $ touch /var/run/netns/init_net $ mount --bind /proc/1/ns/net /var/run/netns/init_net $ ip netns add foo $ ip -n foo netns foo init_net $ ip -n foo netns set init_net 0 $ ip -n foo netns set foo 1 # Only netns seen from foo have an id: $ ip netns foo init_net $ ip -n foo netns foo (id: 1) init_net (id: 0) # Add a 4in4 x-netns interface with a link-netnsid option and check the dump: $ ip -n foo link add ipip1 link-netnsid 0 type ipip remote 10.16.0.121 local 10.16.0.249 $ ip -n foo link ls ipip1 6: ipip1@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default link/ipip 10.16.0.249 peer 10.16.0.121 link-netnsid 0 # The parameter link-netnsid shows us where the interface sends and receives # packets (and thus we know where encapsulated addresses are set). # Add a 4in4 x-netns interface without a link-netnsid option and check that an # id is allocated in init_net for foo $ ip netns foo init_net $ ip -n foo link add ipip2 type ipip remote 10.16.0.121 local 10.16.0.249 $ ip -n foo link set ipip2 netns init_net $ ip link ls ipip2 7: ipip2@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default link/ipip 10.16.0.249 peer 10.16.0.121 link-netnsid 0 $ ip netns foo (id: 0) init_net v4 -> v5: use rtnetlink instead of genetlink allocate automatically an id if user didn't assign one rename include/uapi/linux/netns.h to include/uapi/linux/net_namespace.h add vxlan in patch #3 RFCv3 -> v4: rebase on net-next add copyright text in the new netns.h file RFCv2 -> RFCv3: ids are now defined by userland (via netlink). Ids are stored in each netns (and they are local to this netns). add get_link_net support for ip6 tunnels netnsid is now a s32 instead of a u32 RFCv1 -> RFCv2: remove useless () ids are now stored in the user ns. It's possible to get an id for a peer netns only if the current netns and the peer netns have the same user ns parent. MAINTAINERS| 1 + drivers/net/vxlan.c| 8 ++ include/net/ip6_tunnel.h | 1 + include/net/ip_tunnels.h | 1 + include/net/net_namespace.h| 4 + include/net/rtnetlink.h| 2 + include/uapi/linux/Kbuild | 1 + include/uapi/linux/if_link.h | 1 + include/uapi/linux/net_namespace.h | 23 include/uapi/linux/rtnetlink.h | 5 + net/core/net_namespace.c | 210 + net/core/rtnetlink.c | 38 ++- net/ipv4/ip_gre.c | 2 + net/ipv4/ip_tunnel.c | 8 ++ net/ipv4/ip_vti.c | 1 + net/ipv4/ipip.c| 1 + net/ipv6/ip6_gre.c | 1 + net/ipv6/ip6_tunnel.c | 9 ++ net/ipv6/ip6_vti.c | 1 + net/ipv6/sit.c | 1 + 20 files changed, 316 insertions(+), 3 deletions(-) Comments are welcome. Regards, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing
On Thu, 15 Jan 2015 20:57:29 +0900 Masami Hiramatsu wrote: > > > If the function tracer traces the jprobe handler, the hook function > > for that handler will not be called, and its saved return address > > will be used for the next function. This will result in a kernel > > crash. > > Actually, both jprobe (user-defined) handler and jprobe_return() > doesn't execute "ret". Yep I new that. But a notrace on jprobe_return isn't that big of a deal. It's not a function we really need to trace, as it really doesn't do anything but being a 'hack' for jprobes to return properly. > So, right after run out the jprobe handler with function-graph tracer, > on the top of its hidden stack, there are at least 2(*) unused return > addresses, one is for jprobe handler (this should be same as the > probed function's return address) and other is jprobe_return()'s > return address. (*: this can be more than 2 if jprobe_return is > called from a function which is called from jprobe handler) > > So, the hidden stack may be as below; > > [jprobe_return() return address] > [probed function return address] > [probed function return address] > > After jumping back to the probed function, the function return is > trapped by the function-graph tracer, and it uses jprobe_return()'s > return address. Since usually jprobe_return() is called at the end of > the function, CPU will execute "ret" soon again(if someone puts a BUG > right after jprobe_return(), the kernel will show that BUG), and it > returns to the caller of the probed function. > However, there still be the probed function return address on the > hidden stack! This means that the next "ret" will go back to the same > address but with modified register and stacks. Yep, I discovered all this with my patch that allows function tracing with jprobes. > > > To solve this, pause function tracing before the jprobe handler is > > called and unpause it before it returns back to the function it > > probed. > > Agreed, but it also could drop some NMI events. That is downside. > > > Some other updates: > > > > Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes > > the code look a bit cleaner and easier to understand (various tries > > to fix this bug required this change). > > OK. > > > Note, if fentry is being used, jprobes will change the ip address > > before the function graph tracer runs and it will not be able to > > trace the function that the jprobe is probing. > > yes, it should be fixed. > > BTW, my last part of IPMODIFY patches (which is not yet merged) > can solve this a different way. It sets IPMODIFY flag only to jprobe. > So, if function-graph tracer sets IPMODIFY flag, user can not enable > function-graph tracer when jprobe is used. Nah, I don't want to stop jprobes due to function graph tracing or vice versa. function graph tracer doesn't change the regs->ip, so it doesn't need the flag. But I sent out a patch that fixes this for this case. Let me know what you think of that one. > > https://lkml.org/lkml/2014/10/9/210 > > Anyway, this patch is better to go stable trees. > > Acked-by: Masami Hiramatsu > Thanks! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v5 4/4] rtnl: allow to create device with IFLA_LINK_NETNSID set
This patch adds the ability to create a netdevice in a specified netns and
then move it into the final netns. In fact, it allows to have a symetry between
get and set rtnl messages.
Signed-off-by: Nicolas Dichtel
---
net/core/rtnetlink.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ab78ba9a34e8..b2f6d8285a24 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1247,6 +1247,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
[IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len =
MAX_PHYS_ITEM_ID_LEN },
[IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
[IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len =
MAX_PHYS_ITEM_ID_LEN },
+ [IFLA_LINK_NETNSID] = { .type = NLA_S32 },
};
static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
@@ -2020,7 +2021,7 @@ replay:
struct nlattr *slave_attr[m_ops ? m_ops->slave_maxtype + 1 : 0];
struct nlattr **data = NULL;
struct nlattr **slave_data = NULL;
- struct net *dest_net;
+ struct net *dest_net, *link_net = NULL;
if (ops) {
if (ops->maxtype && linkinfo[IFLA_INFO_DATA]) {
@@ -2126,7 +2127,18 @@ replay:
if (IS_ERR(dest_net))
return PTR_ERR(dest_net);
- dev = rtnl_create_link(dest_net, ifname, name_assign_type, ops,
tb);
+ if (tb[IFLA_LINK_NETNSID]) {
+ int id = nla_get_s32(tb[IFLA_LINK_NETNSID]);
+
+ link_net = get_net_ns_by_id(dest_net, id);
+ if (!link_net) {
+ err = -EINVAL;
+ goto out;
+ }
+ }
+
+ dev = rtnl_create_link(link_net ? : dest_net, ifname,
+ name_assign_type, ops, tb);
if (IS_ERR(dev)) {
err = PTR_ERR(dev);
goto out;
@@ -2154,9 +2166,16 @@ replay:
}
}
err = rtnl_configure_link(dev, ifm);
- if (err < 0)
+ if (err < 0) {
unregister_netdevice(dev);
+ goto out;
+ }
+
+ if (link_net)
+ err = dev_change_net_namespace(dev, dest_net, ifname);
out:
+ if (link_net)
+ put_net(link_net);
put_net(dest_net);
return err;
}
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix v4 0/2] Fix xen IRQ allocation failure caused by commit b81975eade8c
Thursday, January 15, 2015, 2:04:34 PM, you wrote: > With more knowledge of Xen interrupt manangement subsytem, I realized > previous three versions to fix https://lkml.org/lkml/2014/12/19/178 are > just plainly wrong. Those patches try to fix the issue by creating > irqdomain for IOAPICs for PV domains, which effectively let native > IOAPIC driver and Xen PV interrupt management subsystem to manage > IOAPIC irqs concurrently, sounds unpredictable. > Sorry for those wrong fixes. The good news is that the new fix does > make code simpler and easier to maintain. > I have tested the patchset on Intel platform with bare metal and Dom0 > kernels. > Hi Sander, > Could you please help to test it again? > Regards! > Gerry Hi Gerry, These patches fix the first symptom of the powerbutton not working. Unfortunately it doesn't fix the second symptoms with pci-passthrough, the device still doesn't receive irq's on intel and the video device still haas issues on AMD. What i have tested extensively and works stable for me is: david's patch + revert of cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 "x86, irq: Keep balance of IOAPIC pin reference count" Hope that helps in finding the solution. -- Sander > Jiang Liu (2): > xen/pci: Kill function xen_setup_acpi_sci() > xen/pci: Simplify x86/pci/xen.c by killing gsi_override related code > arch/x86/kernel/acpi/boot.c | 26 - > arch/x86/pci/xen.c | 68 > --- > 2 files changed, 19 insertions(+), 75 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski wrote: > On 01/12/2015 05:55 PM, Rob Herring wrote: >> >> Adding Mark B and Liam... >> >> On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski >> wrote: >>> >>> On 01/12/2015 02:52 PM, Rob Herring wrote: On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski wrote: > > On 01/09/2015 07:33 PM, Rob Herring wrote: >> >> On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski >> wrote: >>> >>> Add a property for defining the device outputs the LED >>> represented by the DT child node is connected to. >> >> >> [...] >> >>> b/Documentation/devicetree/bindings/leds/common.txt >>> index a2c3f7a..29295bf 100644 >>> --- a/Documentation/devicetree/bindings/leds/common.txt >>> +++ b/Documentation/devicetree/bindings/leds/common.txt >>> @@ -1,6 +1,10 @@ >>> Common leds properties. >>> >>> Optional properties for child nodes: >>> +- led-sources : Array of bits signifying the LED current regulator >>> outputs the >>> + LED represented by the child node is connected to (1 >>> - >>> the LED >>> + is connected to the output, 0 - the LED isn't >>> connected >>> to the >>> + output). >> >> >> >> >> Sorry, I just don't understand this. > > > > > In some Flash LED devices one LED can be connected to one or more > electric current outputs, which allows for multiplying the maximum > current allowed for the LED. Each sub-LED is represented by a child > node in the DT binding of the Flash LED device and it needs to declare > which outputs it is connected to. In the example below the led-sources > property is a two element array, which means that the flash LED device > has two current outputs, and the bits signify if the LED is connected > to the output. Sounds like a regulator for which we already have bindings for and we have a driver for regulator based LEDs (but no binding for it). >>> >>> >>> >>> Do you think of drivers/leds/leds-regulator.c driver? This driver just >>> allows for registering an arbitrary regulator device as a LED subsystem >>> device. >>> >>> There are however devices that don't fall into this category, i.e. they >>> have many outputs, that can be connected to a single LED or to many LEDs >>> and the driver has to know what is the actual arrangement. >> >> >> We may need to extend the regulator binding slightly and allow for >> multiple phandles on a supply property, but wouldn't something like >> this work: >> >> led-supply = <>, <>, <>, <>; >> >> The shared source is already supported by the regulator binding. > > > I think that we shouldn't split the LED devices into power supply > providers and consumers as in case of generic regulators. From this > point of view a LED device current output is a provider and a discrete > LED element is a consumer. In this approach each discrete LED element > should have a related driver which is not how LED devices are being > handled in the LED subsystem, where there is a single binding for a LED > device and there is a single driver for it which creates separate LED > class devices for each LED connected to the LED device output. Each > discrete LED is represented by a child node in the LED device binding. > > I am aware that it may be tempting to treat LED devices as common > regulators, but they have their specific features which gave a > reason for introducing LED class for them. Besides, there is already > drivers/leds/leds-regulator.c driver for LED devices which support only > turning on/off and setting brightness level. > > In your proposition a separate regulator provider binding would have > to be created for each current output and a separate binding for > each discrete LED connected to the LED device. It would create > unnecessary noise in a dts file. > > Moreover, using regulator binding implies that we want to treat it > as a sheer power supply for our device (which would be a discrete LED > element in this case), whereas LED devices provide more features like > blinking pattern and for flash LED devices - flash timeout, external > strobe and flash faults. Okay, fair enough. Please include some of this explanation in the binding description. I do still have some concerns about led-sources and whether it can support other scenarios. It is very much tied to the parent node. Are there any cases where we don't want the LEDs to be sub nodes? Perhaps the LEDs are on a separate daughterboard from the driver/supply and we can have different drivers. It's a stretch maybe. Or are there cases where you need more information than just the connection? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [PATCH] ARM: at91/Documentation: add a README for Atmel SoCs
Le 09/01/2015 14:20, Nicolas Ferre a écrit : > Add a README file to describe Atmel SoCs (aka AT91) support in Mainline Linux: > - SoC list + datasheet web links > - Basic but useful information > - Device Tree conventions and Work In Progress statement. > > Signed-off-by: Nicolas Ferre > Cc: ARM Maintainers With corrections by Alexandre and myself, pushed in at91-3.20-cleanup Bye. > --- > Documentation/arm/Atmel/README | 120 > + > 1 file changed, 120 insertions(+) > create mode 100644 Documentation/arm/Atmel/README > > diff --git a/Documentation/arm/Atmel/README b/Documentation/arm/Atmel/README > new file mode 100644 > index ..538f8a556277 > --- /dev/null > +++ b/Documentation/arm/Atmel/README > @@ -0,0 +1,120 @@ > +ARM Atmel SoCs (aka AT91) > += > + > + > +Introduction > + > +This document gives useful information about the ARM Atmel SoCs that are > +currently supported in Linux Mainline (you know, the one on kernel.org). > + > +It is important to note that the Atmel | SMART ARM-based MPU product line is > +historically named "AT91" or "at91" throughout the Linux kernel development > +process even if this product prefix has completely disappeared from the > +official Atmel product name. Anyway, files, directories, git trees, > +git branches/tags and email subject always contain this "at91" sub-string. > + > + > +AT91 SoCs > +- > +Documentation and detailled datasheet for each product are available on > +the Atmel website: http://www.atmel.com. > + > + Flavors: > +* ARM 920 based SoC > + - at91rm9200 > ++ Datasheet > + http://www.atmel.com/Images/doc1768.pdf > + > +* ARM 926 based SoCs > + - at91sam9260 > ++ Datasheet > + http://www.atmel.com/Images/doc6221.pdf > + > + - at91sam9261 > ++ Datasheet > + http://www.atmel.com/Images/doc6062.pdf > + > + - at91sam9263 > ++ Datasheet > + > http://www.atmel.com/Images/Atmel_6249_32-bit-ARM926EJ-S-Microcontroller_SAM9263_Datasheet.pdf > + > + - at91sam9rl > ++ Datasheet > + http://www.atmel.com/Images/doc6289.pdf > + > + - at91sam9g20 > ++ Datasheet > + http://www.atmel.com/Images/doc6384.pdf > + > + - at91sam9g45 family > +- at91sam9g45 > +- at91sam9g46 > +- at91sam9m10 > +- at91sam9m11 (device superset) > ++ Datasheet > + > http://www.atmel.com/Images/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf > + > + - at91sam9x5 family (aka "The 5 series") > +- at91sam9g15 > +- at91sam9g25 > +- at91sam9g35 > +- at91sam9x25 > +- at91sam9x35 > ++ Datasheet (can be considered as covering the whole family) > + > http://www.atmel.com/Images/Atmel_11055_32-bit-ARM926EJ-S-Microcontroller_SAM9X35_Datasheet.pdf > + > + - at91sam9n12 > ++ Datasheet > + > http://www.atmel.com/Images/Atmel_11063_32-bit-ARM926EJ-S-Microcontroller_SAM9N12CN11CN12_Datasheet.pdf > + > +* ARM Cortex-A5 based SoCs > + - sama5d3 family > +- sama5d31 > +- sama5d33 > +- sama5d34 > +- sama5d35 > +- sama5d36 (device superset) > ++ Datasheet > + > http://www.atmel.com/Images/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet.pdf > + > +* ARM Cortex-A5 + NEON based SoCs > + - sama5d4 family > +- sama5d41 > +- sama5d42 > +- sama5d43 > +- sama5d44 (device superset) > ++ Datasheet > + > http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf > + > + > +Linux kernel information > + > +Linux kernel mach directory: arch/arm/mach-at91 > +MAINTAINERS entry is: "ARM/ATMEL AT91RM9200 AND AT91SAM ARM ARCHITECTURES" > + > + > +Device Tree for AT91 SoCs and boards > + > +All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products > +must use this method to boot the Linux kernel. > + > +Work In Progress statement: > +Device Tree files and Device Tree bindings that apply to AT91 SoCs and > boards are > +considered as "Unstable". To be completely clear, any at91 binding can > change at > +any time. So, be sure to use a Device Tree Binary and a Kernel Image > generated from > +the same source tree. > +Please refer to the Documentation/devicetree/bindings/ABI.txt file for a > +definition of a "Stable" binding/ABI. > +This statement will be removed by AT91 MAINTAINERS when appropriated. > + > +Naming conventions and best practice: > +- SoCs Device Tree Source Include files are named after the official name of > + the product (at91sam9g20.dtsi or sama5d33.dtsi for instance). > +- Device Tree Source Include files (.dtsi) are used to collect common nodes > that can be > +
[PATCH v7 0/5] phy: qcom-ufs: add support for QUALCOMM
Changes from V6: - change#1 in the V6 series: 0001-phy-qcom-ufs-add-support-for-20nm-phy has been divided into 2 patches: A: phy: qcom-ufs: add support for QUALCOMM Technologies UFS PHY drivers B: phy: qcom-ufs: add support for 20nm phy in order to seperate the common code of the Qualcomm Technologies UFS PHYs and the specific UFS PHYs that will be added. Yaniv Gardi (5): phy: qcom-ufs: add support for QUALCOMM Technologies UFS PHY drivers phy: qcom-ufs: add support for 20nm phy scsi: ufs-qcom: add support for Qualcomm Technologies Inc platforms phy: qcom-ufs: add support for 14nm phy scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS drivers/phy/Kconfig |7 + drivers/phy/Makefile|3 + drivers/phy/phy-qcom-ufs-i.h| 159 ++ drivers/phy/phy-qcom-ufs-qmp-14nm.c | 201 +++ drivers/phy/phy-qcom-ufs-qmp-14nm.h | 177 ++ drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257 + drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235 drivers/phy/phy-qcom-ufs.c | 745 drivers/scsi/ufs/Kconfig| 25 + drivers/scsi/ufs/Makefile |2 + drivers/scsi/ufs/ufs-qcom-ice.c | 520 + drivers/scsi/ufs/ufs-qcom-ice.h | 113 drivers/scsi/ufs/ufs-qcom.c | 1058 +++ drivers/scsi/ufs/ufs-qcom.h | 195 +++ include/linux/phy/phy-qcom-ufs.h| 59 ++ 15 files changed, 3756 insertions(+) create mode 100644 drivers/phy/phy-qcom-ufs-i.h create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.c create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.h create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h create mode 100644 drivers/phy/phy-qcom-ufs.c create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.h create mode 100644 drivers/scsi/ufs/ufs-qcom.c create mode 100644 drivers/scsi/ufs/ufs-qcom.h create mode 100644 include/linux/phy/phy-qcom-ufs.h -- 1.8.5.2 -- QUALCOMM ISRAEL, on behalf of 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 v7 3/5] scsi: ufs-qcom: add support for Qualcomm Technologies Inc platforms
This change adds support for Qualcomm Technologies Inc platforms that
use UFS driver. for example, it adds :
- PM specific operations during hibern8, suspend, resume, clock setup
- qcom-ufs generic phy driver initialization, calibration,
power-on/off sequence, etc.
- UFS Controller specific configuration
- Rate, Gear, Mode negotiation between device and controller
Signed-off-by: Yaniv Gardi
---
drivers/scsi/ufs/Kconfig| 13 +
drivers/scsi/ufs/Makefile |1 +
drivers/scsi/ufs/ufs-qcom.c | 1004 +++
drivers/scsi/ufs/ufs-qcom.h | 170
4 files changed, 1188 insertions(+)
create mode 100644 drivers/scsi/ufs/ufs-qcom.c
create mode 100644 drivers/scsi/ufs/ufs-qcom.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 6e07b2a..8a1f4b3 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -70,3 +70,16 @@ config SCSI_UFSHCD_PLATFORM
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config SCSI_UFS_QCOM
+ bool "QCOM specific hooks to UFS controller platform driver"
+ depends on SCSI_UFSHCD_PLATFORM && ARCH_MSM
+ select PHY_QCOM_UFS
+ help
+ This selects the QCOM specific additions to UFSHCD platform driver.
+ UFS host on QCOM needs some vendor specific configuration before
+ accessing the hardware which includes PHY configuration and vendor
+ specific registers.
+
+ Select this if you have UFS controller on QCOM chipset.
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 1e5bd48..8303bcc 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,4 +1,5 @@
# UFSHCD makefile
+obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
new file mode 100644
index 000..9217af9
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -0,0 +1,1004 @@
+/*
+ * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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 "ufshcd.h"
+#include "unipro.h"
+#include "ufs-qcom.h"
+#include "ufshci.h"
+
+static struct ufs_qcom_host *ufs_qcom_hosts[MAX_UFS_QCOM_HOSTS];
+
+static void ufs_qcom_get_speed_mode(struct ufs_pa_layer_attr *p, char *result);
+static int ufs_qcom_get_bus_vote(struct ufs_qcom_host *host,
+ const char *speed_mode);
+static int ufs_qcom_set_bus_vote(struct ufs_qcom_host *host, int vote);
+
+static int ufs_qcom_get_connected_tx_lanes(struct ufs_hba *hba, u32 *tx_lanes)
+{
+ int err = 0;
+
+ err = ufshcd_dme_get(hba,
+ UIC_ARG_MIB(PA_CONNECTEDTXDATALANES), tx_lanes);
+ if (err)
+ dev_err(hba->dev, "%s: couldn't read PA_CONNECTEDTXDATALANES
%d\n",
+ __func__, err);
+
+ return err;
+}
+
+static int ufs_qcom_host_clk_get(struct device *dev,
+ const char *name, struct clk **clk_out)
+{
+ struct clk *clk;
+ int err = 0;
+
+ clk = devm_clk_get(dev, name);
+ if (IS_ERR(clk)) {
+ err = PTR_ERR(clk);
+ dev_err(dev, "%s: failed to get %s err %d",
+ __func__, name, err);
+ } else {
+ *clk_out = clk;
+ }
+
+ return err;
+}
+
+static int ufs_qcom_host_clk_enable(struct device *dev,
+ const char *name, struct clk *clk)
+{
+ int err = 0;
+
+ err = clk_prepare_enable(clk);
+ if (err)
+ dev_err(dev, "%s: %s enable failed %d\n", __func__, name, err);
+
+ return err;
+}
+
+static void ufs_qcom_disable_lane_clks(struct ufs_qcom_host *host)
+{
+ if (!host->is_lane_clks_enabled)
+ return;
+
+ clk_disable_unprepare(host->tx_l1_sync_clk);
+ clk_disable_unprepare(host->tx_l0_sync_clk);
+ clk_disable_unprepare(host->rx_l1_sync_clk);
+ clk_disable_unprepare(host->rx_l0_sync_clk);
+
+ host->is_lane_clks_enabled = false;
+}
+
+static int ufs_qcom_enable_lane_clks(struct ufs_qcom_host *host)
+{
+ int err = 0;
+ struct device *dev = host->hba->dev;
+
+ if (host->is_lane_clks_enabled)
+ return 0;
+
+ err = ufs_qcom_host_clk_enable(dev, "rx_lane0_sync_clk",
+
[PATCH v7 2/5] phy: qcom-ufs: add support for 20nm phy
This change adds a support for a 20nm qcom-ufs phy that is required in
platforms that use ufs-qcom controller.
Signed-off-by: Yaniv Gardi
---
drivers/phy/Makefile| 1 +
drivers/phy/phy-qcom-ufs-i.h| 43 +-
drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257
drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235 +
include/linux/phy/phy-qcom-ufs.h| 59 +
5 files changed, 594 insertions(+), 1 deletion(-)
create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c
create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h
create mode 100644 include/linux/phy/phy-qcom-ufs.h
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 335965d..781b2fa 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
+obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
index dac200f..591a391 100644
--- a/drivers/phy/phy-qcom-ufs-i.h
+++ b/drivers/phy/phy-qcom-ufs-i.h
@@ -15,15 +15,56 @@
#ifndef UFS_QCOM_PHY_I_H_
#define UFS_QCOM_PHY_I_H_
+#include
#include
+#include
#include
-#include
+#include
#include
#include
#include
+#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ might_sleep_if(timeout_us); \
+ for (;;) { \
+ (val) = readl(addr); \
+ if (cond) \
+ break; \
+ if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+ (val) = readl(addr); \
+ break; \
+ } \
+ if (sleep_us) \
+ usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us); \
+ } \
+ (cond) ? 0 : -ETIMEDOUT; \
+})
+
+#define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
+ { \
+ .reg_offset = reg, \
+ .cfg_value = val, \
+ }
+
#define UFS_QCOM_PHY_NAME_LEN 30
+enum {
+ MASK_SERDES_START = 0x1,
+ MASK_PCS_READY = 0x1,
+};
+
+enum {
+ OFFSET_SERDES_START = 0x0,
+};
+
+struct ufs_qcom_phy_stored_attributes {
+ u32 att;
+ u32 value;
+};
+
+
struct ufs_qcom_phy_calibration {
u32 reg_offset;
u32 cfg_value;
diff --git a/drivers/phy/phy-qcom-ufs-qmp-20nm.c
b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
new file mode 100644
index 000..8332f96
--- /dev/null
+++ b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
@@ -0,0 +1,257 @@
+/*
+ * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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 "phy-qcom-ufs-qmp-20nm.h"
+
+#define UFS_PHY_NAME "ufs_phy_qmp_20nm"
+
+static
+int ufs_qcom_phy_qmp_20nm_phy_calibrate(struct ufs_qcom_phy *ufs_qcom_phy,
+ bool is_rate_B)
+{
+ struct ufs_qcom_phy_calibration *tbl_A, *tbl_B;
+ int tbl_size_A, tbl_size_B;
+ u8 major = ufs_qcom_phy->host_ctrl_rev_major;
+ u16 minor = ufs_qcom_phy->host_ctrl_rev_minor;
+ u16 step = ufs_qcom_phy->host_ctrl_rev_step;
+ int err;
+
+ if ((major == 0x1) && (minor == 0x002) && (step == 0x)) {
+ tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A_1_2_0);
+ tbl_A = phy_cal_table_rate_A_1_2_0;
+ } else if ((major == 0x1) && (minor == 0x003) && (step == 0x)) {
+ tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A_1_3_0);
+ tbl_A = phy_cal_table_rate_A_1_3_0;
+ } else {
+ dev_err(ufs_qcom_phy->dev, "%s: Unknown UFS-PHY version, no
calibration values\n",
+ __func__);
+ err = -ENODEV;
+ goto out;
+ }
+
+ tbl_size_B = ARRAY_SIZE(phy_cal_table_rate_B);
+ tbl_B = phy_cal_table_rate_B;
+
+ err = ufs_qcom_phy_calibrate(ufs_qcom_phy, tbl_A, tbl_size_A,
+ tbl_B, tbl_size_B, is_rate_B);
+
+ if (err)
+ dev_err(ufs_qcom_phy->dev, "%s: ufs_qcom_phy_calibrate() failed
%d\n",
+ __func__, err);
+
+out:
+ return err;
+}
+
+static
+void ufs_qcom_phy_qmp_20nm_advertise_quirks(struct
[PATCH v7 4/5] phy: qcom-ufs: add support for 14nm phy
This change adds a support for a 14nm qcom-ufs phy that is
required in platforms that use ufs-qcom controller.
Signed-off-by: Yaniv Gardi
---
drivers/phy/Makefile| 1 +
drivers/phy/phy-qcom-ufs-qmp-14nm.c | 201
drivers/phy/phy-qcom-ufs-qmp-14nm.h | 177 +++
3 files changed, 379 insertions(+)
create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.c
create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.h
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 781b2fa..cfbb720 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
+obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-ufs-qmp-14nm.c
b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
new file mode 100644
index 000..f5fc50a
--- /dev/null
+++ b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
@@ -0,0 +1,201 @@
+/*
+ * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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 "phy-qcom-ufs-qmp-14nm.h"
+
+#define UFS_PHY_NAME "ufs_phy_qmp_14nm"
+#define UFS_PHY_VDDA_PHY_UV(925000)
+
+static
+int ufs_qcom_phy_qmp_14nm_phy_calibrate(struct ufs_qcom_phy *ufs_qcom_phy,
+ bool is_rate_B)
+{
+ int tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A);
+ int tbl_size_B = ARRAY_SIZE(phy_cal_table_rate_B);
+ int err;
+
+ err = ufs_qcom_phy_calibrate(ufs_qcom_phy, phy_cal_table_rate_A,
+ tbl_size_A, phy_cal_table_rate_B, tbl_size_B, is_rate_B);
+
+ if (err)
+ dev_err(ufs_qcom_phy->dev,
+ "%s: ufs_qcom_phy_calibrate() failed %d\n",
+ __func__, err);
+ return err;
+}
+
+static
+void ufs_qcom_phy_qmp_14nm_advertise_quirks(struct ufs_qcom_phy *phy_common)
+{
+ phy_common->quirks =
+ UFS_QCOM_PHY_QUIRK_HIBERN8_EXIT_AFTER_PHY_PWR_COLLAPSE;
+}
+
+static int ufs_qcom_phy_qmp_14nm_init(struct phy *generic_phy)
+{
+ struct ufs_qcom_phy_qmp_14nm *phy = phy_get_drvdata(generic_phy);
+ struct ufs_qcom_phy *phy_common = >common_cfg;
+ int err;
+
+ err = ufs_qcom_phy_init_clks(generic_phy, phy_common);
+ if (err) {
+ dev_err(phy_common->dev, "%s: ufs_qcom_phy_init_clks() failed
%d\n",
+ __func__, err);
+ goto out;
+ }
+
+ err = ufs_qcom_phy_init_vregulators(generic_phy, phy_common);
+ if (err) {
+ dev_err(phy_common->dev, "%s: ufs_qcom_phy_init_vregulators()
failed %d\n",
+ __func__, err);
+ goto out;
+ }
+ phy_common->vdda_phy.max_uV = UFS_PHY_VDDA_PHY_UV;
+ phy_common->vdda_phy.min_uV = UFS_PHY_VDDA_PHY_UV;
+
+ ufs_qcom_phy_qmp_14nm_advertise_quirks(phy_common);
+
+out:
+ return err;
+}
+
+static
+void ufs_qcom_phy_qmp_14nm_power_control(struct ufs_qcom_phy *phy, bool val)
+{
+ writel_relaxed(val ? 0x1 : 0x0, phy->mmio + UFS_PHY_POWER_DOWN_CONTROL);
+ /*
+* Before any transactions involving PHY, ensure PHY knows
+* that it's analog rail is powered ON (or OFF).
+*/
+ mb();
+}
+
+static inline
+void ufs_qcom_phy_qmp_14nm_set_tx_lane_enable(struct ufs_qcom_phy *phy, u32
val)
+{
+ /*
+* 14nm PHY does not have TX_LANE_ENABLE register.
+* Implement this function so as not to propagate error to caller.
+*/
+}
+
+static inline void ufs_qcom_phy_qmp_14nm_start_serdes(struct ufs_qcom_phy *phy)
+{
+ u32 tmp;
+
+ tmp = readl_relaxed(phy->mmio + UFS_PHY_PHY_START);
+ tmp &= ~MASK_SERDES_START;
+ tmp |= (1 << OFFSET_SERDES_START);
+ writel_relaxed(tmp, phy->mmio + UFS_PHY_PHY_START);
+ /* Ensure register value is committed */
+ mb();
+}
+
+static int ufs_qcom_phy_qmp_14nm_is_pcs_ready(struct ufs_qcom_phy *phy_common)
+{
+ int err = 0;
+ u32 val;
+
+ err = readl_poll_timeout(phy_common->mmio + UFS_PHY_PCS_READY_STATUS,
+ val, (val & MASK_PCS_READY), 10, 100);
+ if (err)
+ dev_err(phy_common->dev, "%s: poll for pcs failed err = %d\n",
+ __func__, err);
+ return err;
+}
+
+static struct phy_ops
[PATCH v7 5/5] scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS
From: Yaniv Gardi
In-order to enhance storage encryption performance,
an Inline Cryptographic Engine is introduced to UFS.
This patch adds in-line encryption capabilities to the UFS
driver.
Signed-off-by: Yaniv Gardi
---
drivers/scsi/ufs/Kconfig| 12 +
drivers/scsi/ufs/Makefile | 1 +
drivers/scsi/ufs/ufs-qcom-ice.c | 520
drivers/scsi/ufs/ufs-qcom-ice.h | 113 +
drivers/scsi/ufs/ufs-qcom.c | 56 -
drivers/scsi/ufs/ufs-qcom.h | 25 ++
6 files changed, 726 insertions(+), 1 deletion(-)
create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 8a1f4b3..ecf34ed 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,15 @@ config SCSI_UFS_QCOM
Select this if you have UFS controller on QCOM chipset.
If unsure, say N.
+
+config SCSI_UFS_QCOM_ICE
+ bool "QCOM specific hooks to Inline Crypto Engine for UFS driver"
+ depends on SCSI_UFS_QCOM && CRYPTO_DEV_QCOM_ICE
+ help
+ This selects the QCOM specific additions to support Inline Crypto
+ Engine (ICE).
+ ICE accelerates the crypto operations and maintains the high UFS
+ performance.
+
+ Select this if you have ICE supported for UFS on QCOM chipset.
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 8303bcc..31adca5 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,5 +1,6 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
+obj-$(CONFIG_SCSI_UFS_QCOM_ICE) += ufs-qcom-ice.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c b/drivers/scsi/ufs/ufs-qcom-ice.c
new file mode 100644
index 000..9202b73
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-qcom-ice.c
@@ -0,0 +1,520 @@
+/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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 "ufs-qcom-ice.h"
+#include "ufshcd.h"
+
+#define UFS_QCOM_CRYPTO_LABEL "ufs-qcom-crypto"
+/* Timeout waiting for ICE initialization, that requires TZ access */
+#define UFS_QCOM_ICE_COMPLETION_TIMEOUT_MS 500
+
+static void ufs_qcom_ice_success_cb(void *host_ctrl,
+ enum ice_event_completion evt)
+{
+ struct ufs_qcom_host *qcom_host = (struct ufs_qcom_host *)host_ctrl;
+
+ if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_DISABLED &&
+ evt == ICE_INIT_COMPLETION)
+ qcom_host->ice.state = UFS_QCOM_ICE_STATE_ACTIVE;
+else if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_SUSPENDED &&
+ evt == ICE_RESUME_COMPLETION)
+ qcom_host->ice.state = UFS_QCOM_ICE_STATE_ACTIVE;
+
+ complete(_host->ice.async_done);
+}
+
+static void ufs_qcom_ice_error_cb(void *host_ctrl, enum ice_error_code evt)
+{
+ struct ufs_qcom_host *qcom_host = (struct ufs_qcom_host *)host_ctrl;
+
+ dev_err(qcom_host->hba->dev, "%s: Error in ice operation %d",
+ __func__, evt);
+
+ if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_ACTIVE)
+ qcom_host->ice.state = UFS_QCOM_ICE_STATE_DISABLED;
+
+ complete(_host->ice.async_done);
+}
+
+static struct platform_device *ufs_qcom_ice_get_pdevice(struct device *ufs_dev)
+{
+ struct device_node *node;
+ struct platform_device *ice_pdev = NULL;
+
+ node = of_parse_phandle(ufs_dev->of_node, UFS_QCOM_CRYPTO_LABEL, 0);
+
+ if (!node) {
+ dev_err(ufs_dev, "%s: ufs-qcom-crypto property not specified\n",
+ __func__);
+ goto out;
+ }
+
+ ice_pdev = qcom_ice_get_pdevice(node);
+out:
+ return ice_pdev;
+}
+
+static
+struct qcom_ice_variant_ops *ufs_qcom_ice_get_vops(struct device *ufs_dev)
+{
+ struct qcom_ice_variant_ops *ice_vops = NULL;
+ struct device_node *node;
+
+ node = of_parse_phandle(ufs_dev->of_node, UFS_QCOM_CRYPTO_LABEL, 0);
+
+ if (!node) {
+ dev_err(ufs_dev, "%s: ufs-qcom-crypto property not specified\n",
+ __func__);
+ goto out;
+ }
+
+ ice_vops = qcom_ice_get_variant_ops(node);
+
+ if (!ice_vops)
+ dev_err(ufs_dev, "%s: invalid
Re: [PATCH v3 0/6] AT91 DT for 3.20 #1
Le 13/01/2015 19:12, Alexandre Belloni a écrit : > This series enables RTC on the at91sam9n12 and at91rm9200. > It also adds nodes for the SRAM availabe on at91 SoCs. > > Finally it adds a dtsi for the at91sam9xe and uses it for the ethernut5 dts. > > Changes in v3: > - corrected the 9260 and 9g20 reg properties of the SRAM node > > Changes in v2: > - remove the 9x5 errata for the n12 rtc > > Alexandre Belloni (6): > ARM: at91/dt: at91sam9n12: Add RTC node > ARM: at91/dt: rm9200: add RTC node > ARM: at91/dt: at91rm9200ek: enable RTC > ARM: at91/dt: add SRAM nodes > ARM: at91/dt: Add a dtsi for at91sam9xe > ARM: at91/dt: ethernut5: use at91sam9xe.dtsi Acked-by: Nicolas Ferre With the corrected at91sam9rl sram size (0x1), whole series stacked on top of at91-3.20-dt. Thanks. > .../devicetree/bindings/arm/atmel-at91.txt | 1 + > arch/arm/boot/dts/at91rm9200.dtsi | 12 + > arch/arm/boot/dts/at91rm9200ek.dts | 4 ++ > arch/arm/boot/dts/at91sam9260.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9261.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9263.dtsi | 10 > arch/arm/boot/dts/at91sam9g20.dtsi | 9 > arch/arm/boot/dts/at91sam9g45.dtsi | 7 ++- > arch/arm/boot/dts/at91sam9n12.dtsi | 12 + > arch/arm/boot/dts/at91sam9rl.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9x5.dtsi | 5 ++ > arch/arm/boot/dts/at91sam9xe.dtsi | 60 > ++ > arch/arm/boot/dts/ethernut5.dts| 2 +- > arch/arm/boot/dts/sama5d3.dtsi | 5 ++ > arch/arm/boot/dts/sama5d4.dtsi | 5 ++ > 15 files changed, 144 insertions(+), 3 deletions(-) > create mode 100644 arch/arm/boot/dts/at91sam9xe.dtsi > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/5] phy: qcom-ufs: add support for QUALCOMM Technologies UFS PHY drivers
This change adds a generic and common API support for ufs phy QUALCOMM
Technologies. This support provides common code and also points
to specific phy callbacks to differentiate between different behaviors
of frequent use-cases (like power on, power off, phy calibration etc).
Signed-off-by: Yaniv Gardi
---
drivers/phy/Kconfig | 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-qcom-ufs-i.h | 118 +++
drivers/phy/phy-qcom-ufs.c | 745 +++
4 files changed, 871 insertions(+)
create mode 100644 drivers/phy/phy-qcom-ufs-i.h
create mode 100644 drivers/phy/phy-qcom-ufs.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..26a7623 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -277,4 +277,11 @@ config PHY_STIH41X_USB
Enable this to support the USB transceiver that is part of
STMicroelectronics STiH41x SoC series.
+config PHY_QCOM_UFS
+ tristate "Qualcomm UFS PHY driver"
+ depends on OF && ARCH_MSM
+ select GENERIC_PHY
+ help
+ Support for UFS PHY on QCOM chipsets.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..335965d 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
+obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
new file mode 100644
index 000..dac200f
--- /dev/null
+++ b/drivers/phy/phy-qcom-ufs-i.h
@@ -0,0 +1,118 @@
+/*
+ * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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.
+ *
+ */
+
+#ifndef UFS_QCOM_PHY_I_H_
+#define UFS_QCOM_PHY_I_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UFS_QCOM_PHY_NAME_LEN 30
+
+struct ufs_qcom_phy_calibration {
+ u32 reg_offset;
+ u32 cfg_value;
+};
+
+struct ufs_qcom_phy_vreg {
+ const char *name;
+ struct regulator *reg;
+ int max_uA;
+ int min_uV;
+ int max_uV;
+ bool enabled;
+ bool is_always_on;
+};
+
+struct ufs_qcom_phy {
+ struct list_head list;
+ struct device *dev;
+ void __iomem *mmio;
+ void __iomem *dev_ref_clk_ctrl_mmio;
+ struct clk *tx_iface_clk;
+ struct clk *rx_iface_clk;
+ bool is_iface_clk_enabled;
+ struct clk *ref_clk_src;
+ struct clk *ref_clk_parent;
+ struct clk *ref_clk;
+ bool is_ref_clk_enabled;
+ bool is_dev_ref_clk_enabled;
+ struct ufs_qcom_phy_vreg vdda_pll;
+ struct ufs_qcom_phy_vreg vdda_phy;
+ struct ufs_qcom_phy_vreg vddp_ref_clk;
+ unsigned int quirks;
+
+ /*
+ * If UFS link is put into Hibern8 and if UFS PHY analog hardware is
+ * power collapsed (by clearing UFS_PHY_POWER_DOWN_CONTROL), Hibern8
+ * exit might fail even after powering on UFS PHY analog hardware.
+ * Enabling this quirk will help to solve above issue by doing
+ * custom PHY settings just before PHY analog power collapse.
+ */
+ #define UFS_QCOM_PHY_QUIRK_HIBERN8_EXIT_AFTER_PHY_PWR_COLLAPSE BIT(0)
+
+ u8 host_ctrl_rev_major;
+ u16 host_ctrl_rev_minor;
+ u16 host_ctrl_rev_step;
+
+ char name[UFS_QCOM_PHY_NAME_LEN];
+ struct ufs_qcom_phy_calibration *cached_regs;
+ int cached_regs_table_size;
+ bool is_powered_on;
+ struct ufs_qcom_phy_specific_ops *phy_spec_ops;
+};
+
+/**
+ * struct ufs_qcom_phy_specific_ops - set of pointers to functions which have a
+ * specific implementation per phy. Each UFS phy, should implement
+ * those functions according to its spec and requirements
+ * @calibrate_phy: pointer to a function that calibrate the phy
+ * @start_serdes: pointer to a function that starts the serdes
+ * @is_physical_coding_sublayer_ready: pointer to a function that
+ * checks pcs readiness. returns 0 for success and non-zero for error.
+ * @set_tx_lane_enable: pointer to a function that enable tx lanes
+ * @power_control: pointer to a function that controls analog rail of phy
+ * and writes to QSERDES_RX_SIGDET_CNTRL attribute
+ */
+struct ufs_qcom_phy_specific_ops {
+ int (*calibrate_phy)(struct ufs_qcom_phy *phy, bool is_rate_B);
+ void (*start_serdes)(struct ufs_qcom_phy
Re: [Bugfix v4 0/2] Fix xen IRQ allocation failure caused by commit b81975eade8c
On 2015/1/15 22:22, Sander Eikelenboom wrote: > > Thursday, January 15, 2015, 2:04:34 PM, you wrote: > >> With more knowledge of Xen interrupt manangement subsytem, I realized >> previous three versions to fix https://lkml.org/lkml/2014/12/19/178 are >> just plainly wrong. Those patches try to fix the issue by creating >> irqdomain for IOAPICs for PV domains, which effectively let native >> IOAPIC driver and Xen PV interrupt management subsystem to manage >> IOAPIC irqs concurrently, sounds unpredictable. > >> Sorry for those wrong fixes. The good news is that the new fix does >> make code simpler and easier to maintain. > >> I have tested the patchset on Intel platform with bare metal and Dom0 >> kernels. > >> Hi Sander, >> Could you please help to test it again? > >> Regards! >> Gerry > > Hi Gerry, > > These patches fix the first symptom of the powerbutton not working. > > Unfortunately it doesn't fix the second symptoms with pci-passthrough, > the device still doesn't receive irq's on intel and the video device still > haas > issues on AMD. > > What i have tested extensively and works stable for me is: > david's patch + revert of cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 "x86, irq: > Keep balance of IOAPIC pin reference count" > > Hope that helps in finding the solution. Hi Sander, Yes, this is only a fix for power button(ACPI SCI allocation). I'm still reading xen-pciback code to figure out the possible cause and fix for the second issue. Thanks! Gerry. > > -- > Sander > > >> Jiang Liu (2): >> xen/pci: Kill function xen_setup_acpi_sci() >> xen/pci: Simplify x86/pci/xen.c by killing gsi_override related code > >> arch/x86/kernel/acpi/boot.c | 26 - >> arch/x86/pci/xen.c | 68 >> --- >> 2 files changed, 19 insertions(+), 75 deletions(-) > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Thu, Jan 15, 2015 at 6:33 AM, Sylwester Nawrocki
wrote:
> On 12/01/15 18:06, Mark Brown wrote:
>> On Mon, Jan 12, 2015 at 10:55:29AM -0600, Rob Herring wrote:
>>> > On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski
> > There are however devices that don't fall into this category, i.e. they
> > have many outputs, that can be connected to a single LED or to many
> > LEDs
> > and the driver has to know what is the actual arrangement.
>>> >
>>> > We may need to extend the regulator binding slightly and allow for
>>> > multiple phandles on a supply property, but wouldn't something like
>>> > this work:
>>> > led-supply = <>, <>, <>, <>;
>>> > The shared source is already supported by the regulator binding.
>>
>> What is the reasoning for this? If a single supply is being supplied by
>> multiple regulators then in general those regulators will all know about
>> each other at a hardware level and so from a functional and software
>> point of view will effectively be one regulator. If they don't/aren't
>> then they tend to interfere with each other.
>
> For LED current regulators like this one [1] we want to be able to
> communicate to the software the hardware wiring, e.g. if a single LED is
> connected to only one or both the current regulators. The device needs
> to be programmed differently for each configuration, as shown on page 36
> of the datasheet [2].
>
> Now, the LED DT binding describes the LEDs (current consumers) as child
> nodes of the LED driver IC (current supplier), e.g. (from [3]):
>
> pca9632@62 {
> compatible = "nxp,pca9632";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x62>;
>
> red@0 {
> label = "red";
> reg = <0>;
This only works if you don't have sub blocks or different functions to
describe. I suppose you could add yet another level of nodes. This
feels like abuse of the reg property even though to use the reg
property is a frequent review comment.
OTOH, we don't need 2 ways to describe this.
> linux,default-trigger = "none";
> };
> green@1 {
> label = "green";
> reg = <1>;
> linux,default-trigger = "none";
> };
> ...
> };
>
> What is missing in this binding is the ability to tell that a single LED
> is connected to more than one current source.
>
> We could, for example adopt the multiple phandle in the supply property
> scheme, but not use the kernel regulator API, e.g.
>
> flash-led {
> compatible = "maxim,max77387";
>
> current-reg1 { // FLED1
> led-output-id = <0>;
> };
>
> current-reg2 { // FLED2
> led-output-id = <1>;
> };
>
> red_led {
> led-supply = <>, <>;
> };
> };
>
> However my feeling is that it is unnecessarily complicated that way.
This example is not so complicated, but I already agreed on not using
regulators on the basis there are other properties of the driver
unique to LEDs.
> Perhaps we could use the 'reg' property to describe actual connections,
> I'm not sure if it's better than a LED specific property, e.g.
>
> max77387@52 {
> compatible = "nxp,max77387";
> #address-cells = <2>;
> #size-cells = <0>;
> reg = <0x52>;
>
> flash_led {
> reg = <1 1>;
Don't you mean <0 1> as the values are the "address" which in this
case are the LED driver output indexes.
Rob
> ...
> };
> };
>
> [1] http://www.maximintegrated.com/en/products/power/led-drivers/MAX77387.html
> [2] http://datasheets.maximintegrated.com/en/ds/MAX77387.pdf
> [3] Documentation/devicetree/bindings/leds/pca963x.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] input: tsc2007: Add pre-calibration, flipping and rotation
Hi, On Thu, Jan 15, 2015 at 08:36:44AM +0100, Dr. H. Nikolaus Schaller wrote: > > 1. Perform conversion in input core rather than individual drivers. I > > think we should allocate a new bitmaps for some transformations and have > > the code do X/Y flip/clip of the coordinates. > > Do you have a suggestion where this should be (I have no clue how > the input system works or is structured - we just know how to extend a > driver that uses it)? > > > 2. Standardize on bindings. We already have of-touchscreen.c doing > > rudimentary parsing, we shoudl look into extending it rather than > > creating myriad of driver-specific bindings. > > Ok, looks reasonable. Documentation is in Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > > Also, do we need swap and flip or do we simply need rotation (like the > > proposed Broadcom iproc driver has)? > > Well, since the DT should describe hardware, there are 3 sets of wires which > can have a cross-over: X+ and X-, Y+ and Y-, X and Y. > > So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an > interpretation of the result of these connections in combination with some > panel the touch is glued to and should therefore not be represented in the DT. > > As a result we have proposed a scheme without explicit rotation. We specify > what > coordinates X- and X+ should report at their ends (min, max) because the DT > programmer has to specify them anyways. Flipping is a result of defining these > coordinates in an ascending or descending way. Only swapping of the X and Y > wires can’t be implicitly defined so it has its own property. So the scheme we > have proposed tries to optimize the efforts needed to adapt new boards and > write > DTs and focus the DT on hardware description. > > As a bonus we also specify the min and max value to be reported for the touch > pressure (Z axis) using the same basic principle. > > And it is a pure add-on on top of the existing driver so that it attempts not > to break existing device trees. from what I can see there are no in-tree-users using any of the new properties. > Maybe could you accept it as a first step for this specific driver (and let’s > do > the big standardization work later on)? That does not work, since you create an ABI. -- Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] Documentation: dt: add common bindings for hwspinlock
On Thu, Jan 15, 2015 at 7:55 AM, Mark Rutland wrote: > On Thu, Jan 15, 2015 at 01:52:01PM +, Mark Rutland wrote: >> On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote: >> > This patch adds the generic common bindings used to represent >> > a hwlock device and use/request locks in a device-tree build. >> > >> > All the platform-specific hwlock driver implementations need the >> > number of locks and associated base id for registering the locks >> > present within the device with the driver core. This base id >> > needs to be unique across multiple IP instances of a hwspinlock >> > device, so that each hwlock can be represented uniquely in a >> > system. >> > >> > The number of locks is represented by 'hwlock-num-locks' property, >> > and the base id is represented by the 'hwlock-base-id' property. >> > The args specifier length is dependent on each vendor-specific >> > implementation and is represented through the '#hwlock-cells' >> > property. Client users need to use the property 'hwlocks' for >> > requesting specific lock(s). >> > >> > Note that the document is named hwlock.txt deliberately to keep >> > it a bit more generic. >> > >> > Cc: Rob Herring >> > Signed-off-by: Suman Anna >> > --- >> > v7: Revised binding info for hwlock-base-id, it is mandatory now >> > >> > .../devicetree/bindings/hwlock/hwlock.txt | 55 >> > ++ >> > 1 file changed, 55 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt >> > >> > diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt >> > b/Documentation/devicetree/bindings/hwlock/hwlock.txt >> > new file mode 100644 >> > index ..8de7aaf878f9 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt >> > @@ -0,0 +1,55 @@ >> > +Generic hwlock bindings >> > +=== >> > + >> > +Generic bindings that are common to all the hwlock platform specific >> > driver >> > +implementations. >> > + >> > +The validity and need of these common properties may vary from one >> > platform >> > +implementation to another. The platform specific bindings should >> > explicitly >> > +state if an optional property is used. Please also look through the >> > individual >> > +platform specific hwlock binding documentations for identifying the >> > applicable >> > +properties. >> > + >> > +Common properties: >> > +- #hwlock-cells: Specifies the number of cells needed to represent a >> > + specific lock. This property is mandatory for all >> > + platform implementations. >> > +- hwlock-num-locks:Number of locks present in a hwlock device. >> > This >> > + property is needed on hwlock devices, where the number >> > + of supported locks within a hwlock device cannot be >> > + read from a register. >> > +- hwlock-base-id: An unique base Id for the locks for a particular hwlock >> > + device. This property is mandatory for all platform >> > + implementations. >> >> This property makes no sense. The ID encoded in the hwlock cells is >> relative to the instance (identified by phandle), not global. So the DT >> has no global ID space. >> >> Why do you think you need this? > > Having looked at the way this proeprty is used, NAK. > > If you need to carve up a Linux-internal ID space, do that dynamically. > There is no need for this property. Better yet, don't create a Linux ID space for this. Everywhere we have one, we want to get rid of it. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] init/main.c: prevent increase of console_loglevel by 'quiet' kernel parameter (inline now, sorry for previous attachment)
From: Sergey Popov < popov_ser...@ukr.net >
Prevent increase of console_loglevel by 'quiet'
'quiet' kernel option that follows the 'loglevel=N' should
not blindly overwrite console_loglevel, instead it should
respect and keep lower 'loglevel'.
Signed-off-by: Sergey Popov < popov_ser...@ukr.net >
---
init/main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Some drivers tend to print error messages (ex: 'drm/i810 does not support SMP')
to the console
that we at our company don't want to show to people. We use 'quiet' kernel
option to hide kernel decompressing progress and other messages not related to
printk. But to hide error messages from drivers we use 'loglevel=3' parameter
as well. But when it's _before_ the quiet, then quiet overrides loglevel=3 and
set it to be 4.
I think that's a bug, and here's simple solution for it. The only way to live
without this patch is to pass 'loglevel=3' after the 'quiet'. This issue is
known to the community, but everyone is using workaround (ex:
https://wiki.archlinux.org/index.php/Silent_boot ).
diff --git a/init/main.c b/init/main.c
index 61b99376..91fc78b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -211,7 +211,12 @@ static int __init debug_kernel(char *str)
static int __init quiet_kernel(char *str)
{
- console_loglevel = CONSOLE_LOGLEVEL_QUIET;
+ /*
+* 'quiet' option should not raise console_loglevel, it's only
+* allowed to lower it
+*/
+ if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
+ console_loglevel = CONSOLE_LOGLEVEL_QUIET;
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/
Re: [PATCH] watchdog: Remove .owner field from cadence driver
On 01/15/2015 04:42 AM, Michal Simek wrote: .owner files is filled by module_platform_driver(). Signed-off-by: Michal Simek --- Reviewed-by: Guenter Roeck -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2] vmscan: move reclaim_state handling to shrink_slab
On Thu 15-01-15 16:25:16, Vladimir Davydov wrote:
> On Thu, Jan 15, 2015 at 01:58:20PM +0100, Michal Hocko wrote:
> > On Thu 15-01-15 11:37:53, Vladimir Davydov wrote:
> > > current->reclaim_state is only used to count the number of slab pages
> > > reclaimed by shrink_slab(). So instead of initializing it before we are
> > >
> > > Note that after this patch try_to_free_mem_cgroup_pages() will count not
> > > only reclaimed user pages, but also slab pages, which is expected,
> > > because it can reclaim kmem from kmem-active sub cgroups.
> >
> > Except that reclaim_state counts all freed slab objects that have
> > current->reclaim_state != NULL AFAIR. This includes also kfreed pages
> > from interrupt context and who knows what else and those pages might be
> > from a different memcgs, no?
>
> Hmm, true, good point. Can an interrupt handler free a lot of memory
> though?
it is drivers so who knows...
> Does RCU free objects from irq or soft irq context?
and this is another part which I didn't consider at all. RCU callbacks
are normally processed from kthread context but rcu_init also does
open_softirq(RCU_SOFTIRQ, rcu_process_callbacks)
so something is clearly processed from softirq as well. I am not
familiar with RCU details enough to tell how many callbacks are
processed this way. Tiny RCU, on the other hand, seem to be processing
all callbacks via __rcu_process_callbacks and that seems to be processed
from softirq only.
> > Besides that I am not sure this makes any difference in the end. No
> > try_to_free_mem_cgroup_pages caller really cares about the exact
> > number of reclaimed pages. We care only about whether there was any
> > progress done - and even that not exactly (e.g. try_charge checks
> > mem_cgroup_margin before retry/oom so if sufficient kmem pages were
> > uncharged then we will notice that).
>
> Frankly, I thought exactly the same initially, that's why I dropped
> reclaim_state handling from the initial memcg shrinkers patch set.
> However, then Hillf noticed that nr_reclaimed is checked right after
> calling shrink_slab() in the memcg iteration loop in shrink_zone():
>
>
> memcg = mem_cgroup_iter(root, NULL, );
> do {
> [...]
> if (memcg && is_classzone)
> shrink_slab(sc->gfp_mask, zone_to_nid(zone),
> memcg, sc->nr_scanned - scanned,
> lru_pages);
>
> /*
>* Direct reclaim and kswapd have to scan all memory
>* cgroups to fulfill the overall scan target for the
>* zone.
>*
>* Limit reclaim, on the other hand, only cares about
>* nr_to_reclaim pages to be reclaimed and it will
>* retry with decreasing priority if one round over the
>* whole hierarchy is not sufficient.
>*/
> if (!global_reclaim(sc) &&
> sc->nr_reclaimed >= sc->nr_to_reclaim) {
> mem_cgroup_iter_break(root, memcg);
> break;
> }
> memcg = mem_cgroup_iter(root, memcg, );
> } while (memcg);
>
>
> If we can ignore reclaimed slab pages here (?), let's drop this patch.
I see what you are trying to achieve but can this lead to a serious
over-reclaim? We should be reclaiming mostly user pages and kmem should
be only a small portion I would expect.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/4] KVM: introduce kvm_arch_intc_initialized and use it in irqfd
Introduce __KVM_HAVE_ARCH_INTC_INITIALIZED define and
associated kvm_arch_intc_initialized function. This latter
allows to test whether the virtual interrupt controller is initialized
and ready to accept virtual IRQ injection. On some architectures,
the virtual interrupt controller is dynamically instantiated, justifying
that kind of check.
The new function can now be used by irqfd to check whether the
virtual interrupt controller is ready on KVM_IRQFD request. If not,
KVM_IRQFD returns -EAGAIN.
Signed-off-by: Eric Auger
Acked-by: Christoffer Dall
---
v6 -> v7:
- From now on, kvm_irqfd_assign calls kvm_arch_intc_initialized
(previously introduced in subsequent patch file).
- add Christoffer's ack
v5 -> v6:
- rename function name and macro
- add kvm_arch_intc_initialized declaration in case the archi defines
the macro
---
include/linux/kvm_host.h | 14 ++
virt/kvm/eventfd.c | 3 +++
2 files changed, 17 insertions(+)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 26f1060..702036a 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -706,6 +706,20 @@ static inline wait_queue_head_t *kvm_arch_vcpu_wq(struct
kvm_vcpu *vcpu)
#endif
}
+#ifdef __KVM_HAVE_ARCH_INTC_INITIALIZED
+/*
+ * returns trues if the virtual interrupt controller is initialized and
+ * ready to accept virtual IRQ. On some architectures the virtual interrupt
+ * controller is dynamically instantiated and this is not always true.
+ */
+bool kvm_arch_intc_initialized(struct kvm *kvm);
+#else
+static inline bool kvm_arch_intc_initialized(struct kvm *kvm)
+{
+ return true;
+}
+#endif
+
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type);
void kvm_arch_destroy_vm(struct kvm *kvm);
void kvm_arch_sync_events(struct kvm *kvm);
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 148b239..fc5f43e 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -311,6 +311,9 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
unsigned int events;
int idx;
+ if (!kvm_arch_intc_initialized(kvm))
+ return -EAGAIN;
+
irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
if (!irqfd)
return -ENOMEM;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 3/4] KVM: arm/arm64: implement kvm_arch_intc_initialized
On arm/arm64 the VGIC is dynamically instantiated and it is useful
to expose its state, especially for irqfd setup.
This patch defines __KVM_HAVE_ARCH_INTC_INITIALIZED and
implements kvm_arch_intc_initialized.
Signed-off-by: Eric Auger
Acked-by: Christoffer Dall
---
v6 -> v7:
- usage of the new function in irqfd is introduced in previous patch
file.
- Changed the title and the commit message accordingly
v5 -> v6:
- remove kvm_arch_intc_initialized declaration from
architecture specific kvm_host.h since it is now in
generic kvm_host.h
- squash v5 patch files 3 & 4
---
arch/arm/include/asm/kvm_host.h | 2 ++
arch/arm/kvm/arm.c| 5 +
arch/arm64/include/asm/kvm_host.h | 2 ++
3 files changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 254e065..8f87259 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -27,6 +27,8 @@
#include
#include
+#define __KVM_HAVE_ARCH_INTC_INITIALIZED
+
#if defined(CONFIG_KVM_ARM_MAX_VCPUS)
#define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
#else
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 2d6d910..9c905b4 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -454,6 +454,11 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
return 0;
}
+bool kvm_arch_intc_initialized(struct kvm *kvm)
+{
+ return vgic_initialized(kvm);
+}
+
static void vcpu_pause(struct kvm_vcpu *vcpu)
{
wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 0b7dfdb..dfb6135 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -28,6 +28,8 @@
#include
#include
+#define __KVM_HAVE_ARCH_INTC_INITIALIZED
+
#if defined(CONFIG_KVM_ARM_MAX_VCPUS)
#define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
#else
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 4/4] KVM: arm/arm64: add irqfd support
This patch enables irqfd on arm/arm64.
Both irqfd and resamplefd are supported. Injection is implemented
in vgic.c without routing.
This patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD.
KVM_CAP_IRQFD is now advertised. KVM_CAP_IRQFD_RESAMPLE capability
automatically is advertised as soon as CONFIG_HAVE_KVM_IRQFD is set.
Irqfd injection is restricted to SPI. The rationale behind not
supporting PPI irqfd injection is that any device using a PPI would
be a private-to-the-CPU device (timer for instance), so its state
would have to be context-switched along with the VCPU and would
require in-kernel wiring anyhow. It is not a relevant use case for
irqfds.
Signed-off-by: Eric Auger
Reviewed-by: Christoffer Dall
---
v5 -> v6:
- KVM_CAP_IRQFD support depends on vgic_present
- add Christoffer's Reviewed-by
v4 -> v5:
- squash [PATCH v4 3/3] KVM: arm64: add irqfd support into this patch
- some rewording in Documentation/virtual/kvm/api.txt and in vgic
vgic_process_maintenance unlock comment.
- move explanation of why not supporting PPI into commit message
- in case of injection before gic readiness, -ENODEV is returned. It is
up to the user space to avoid this situation.
v3 -> v4:
- reword commit message
- explain why we unlock the distributor before calling kvm_notify_acked_irq
- rename is_assigned_irq into has_notifier
- change EOI and injection kvm_debug format string
- remove error local variable in kvm_set_irq
- Move HAVE_KVM_IRQCHIP unset in a separate patch
- handle case were the irqfd injection is attempted before the vgic is ready.
in such a case the notifier, if any, is called immediatly
- use nr_irqs to test spi is within correct range
v2 -> v3:
- removal of irq.h from eventfd.c put in a separate patch to increase
visibility
- properly expose KVM_CAP_IRQFD capability in arm.c
- remove CONFIG_HAVE_KVM_IRQCHIP meaningfull only if irq_comm.c is used
v1 -> v2:
- rebase on 3.17rc1
- move of the dist unlock in process_maintenance
- remove of dist lock in __kvm_vgic_sync_hwstate
- rewording of the commit message (add resamplefd reference)
- remove irq.h
---
Documentation/virtual/kvm/api.txt | 6 +++-
arch/arm/include/uapi/asm/kvm.h | 3 ++
arch/arm/kvm/Kconfig | 2 ++
arch/arm/kvm/Makefile | 2 +-
arch/arm/kvm/arm.c| 5
arch/arm64/include/uapi/asm/kvm.h | 3 ++
arch/arm64/kvm/Kconfig| 2 ++
arch/arm64/kvm/Makefile | 2 +-
virt/kvm/arm/vgic.c | 63 ---
9 files changed, 81 insertions(+), 7 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 0007fef..5ed8088 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2231,7 +2231,7 @@ into the hash PTE second double word).
4.75 KVM_IRQFD
Capability: KVM_CAP_IRQFD
-Architectures: x86 s390
+Architectures: x86 s390 arm arm64
Type: vm ioctl
Parameters: struct kvm_irqfd (in)
Returns: 0 on success, -1 on error
@@ -2257,6 +2257,10 @@ Note that closing the resamplefd is not sufficient to
disable the
irqfd. The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
+On ARM/ARM64, the gsi field in the kvm_irqfd struct specifies the Shared
+Peripheral Interrupt (SPI) index, such that the GIC interrupt ID is
+given by gsi + 32.
+
4.76 KVM_PPC_ALLOCATE_HTAB
Capability: KVM_CAP_PPC_ALLOC_HTAB
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index 09ee408..77547bb 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -196,6 +196,9 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX127
+/* One single KVM irqchip, ie. the VGIC */
+#define KVM_NR_IRQCHIPS 1
+
/* PSCI interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 9f581b1..e519a40 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -24,6 +24,7 @@ config KVM
select KVM_MMIO
select KVM_ARM_HOST
depends on ARM_VIRT_EXT && ARM_LPAE
+ select HAVE_KVM_EVENTFD
---help---
Support hosting virtualized guest machines. You will also
need to select one or more of the processor modules below.
@@ -55,6 +56,7 @@ config KVM_ARM_MAX_VCPUS
config KVM_ARM_VGIC
bool "KVM support for Virtual GIC"
depends on KVM_ARM_HOST && OF
+ select HAVE_KVM_IRQFD
default y
---help---
Adds support for a hardware assisted, in-kernel GIC emulation.
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index f7057ed..859db09 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -15,7 +15,7 @@ AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt)
[PATCH v7 1/4] KVM: arm/arm64: unset CONFIG_HAVE_KVM_IRQCHIP
CONFIG_HAVE_KVM_IRQCHIP is needed to support IRQ routing (along with irq_comm.c and irqchip.c usage). This is not the case for arm/arm64 currently. This patch unsets the flag for both arm and arm64. Signed-off-by: Eric Auger Acked-by: Christoffer Dall Acked-by: Will Deacon --- arch/arm/kvm/Kconfig | 2 -- arch/arm64/kvm/Kconfig | 1 - 2 files changed, 3 deletions(-) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 466bd29..9f581b1 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -55,7 +55,6 @@ config KVM_ARM_MAX_VCPUS config KVM_ARM_VGIC bool "KVM support for Virtual GIC" depends on KVM_ARM_HOST && OF - select HAVE_KVM_IRQCHIP default y ---help--- Adds support for a hardware assisted, in-kernel GIC emulation. @@ -63,7 +62,6 @@ config KVM_ARM_VGIC config KVM_ARM_TIMER bool "KVM support for Architected Timers" depends on KVM_ARM_VGIC && ARM_ARCH_TIMER - select HAVE_KVM_IRQCHIP default y ---help--- Adds support for the Architected Timers in virtual machines diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 8ba85e9..279e1a0 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -50,7 +50,6 @@ config KVM_ARM_MAX_VCPUS config KVM_ARM_VGIC bool depends on KVM_ARM_HOST && OF - select HAVE_KVM_IRQCHIP ---help--- Adds support for a hardware assisted, in-kernel GIC emulation. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/4] irqfd support for arm/arm64
This patch series enables irqfd on arm and arm64. Irqfd framework enables to inject a virtual IRQ into a guest upon an eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with a kvm_irqfd struct that associates a VM, an eventfd, a virtual IRQ number (aka. the gsi). When an actor signals the eventfd (typically a VFIO platform driver), the kvm irqfd subsystem injects the gsi into the VM. Resamplefd also is supported for level sensitive interrupts, ie. the user can provide another eventfd that is triggered when the completion of the virtual IRQ (gsi) is detected by the GIC. The gsi must correspond to a shared peripheral interrupt (SPI), ie the GIC interrupt ID is gsi + 32. The rationale behind not supporting PPI irqfd injection is that any device using a PPI would be a private-to-the-CPU device (timer for instance), so its state would have to be context-switched along with the VCPU and would require in-kernel wiring anyhow. It is not a relevant use case for irqfds. This patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD. No IRQ routing table is used, enabling to remove CONFIG_HAVE_KVM_IRQCHIP The ARM virtual interrupt controller, the VGIC, is dynamically instantiated. The user-space may attempt to assign an irqfd before the virtual interrupt controller is ready. For that reason a check is added in the generic irqfd code to test whether the virtual interrupt controller is ready. This work was tested with Calxeda Midway xgmac main interrupt with qemu-system-arm and QEMU VFIO platform device. Also irqfd was proven functional on several vhost-net prototypes. Available on ssh://git.linaro.org/people/eric.auger/linux.git branch irqfd_v7_stdalone_official_release v6 -> v7: - kvm_arch_intc_initialized call introduced in first patch file related to kvm_arch_intc_initialized (generic part) - add Christoffer's acks v5 -> v6: - take into account Christoffer's comments: - rename macro and function enabling to check the state of virtual interrupt controller (kvm_arch_intc_initialized) - kvm_arch_intc_initialized is declared in kvm_host.h whatever the archi support. - squash v5 patch files 3 & 4 - KVM_CAP_IRQFD support depends on vgic_present - add Christoffer's Reviewed-by on last patch file v4 -> v5: - add the capability to check whether vgic is initialized when assigning an irqfd. objective is to avoid injecting IRQ before this vgic is ready: this corresponds to new patch files 2, 3, 4. - do not specifically handle early virtual IRQ injections in kvm_set_irq. In case of injection when vgic is not yet ready, simply return an error. User-space now has means to force vgic init and get notified if irqfd assign takes place too early. - squash [PATCH v4 2/3] KVM: arm: add irqfd support and [PATCH v4 3/3] KVM: arm64: add irqfd support - add Acked-by's in KVM: arm/arm64: unset CONFIG_HAVE_KVM_IRQCHIP - some comment rewording in vgic v3 -> v4: - rebase on 3.18rc5 - vgic dynamic instantiation brought new challenges: handling of irqfd injection when vgic is not ready - unset of CONFIG_HAVE_KVM_IRQCHIP in a separate patch - add arm64 enable - vgic.c style modifications according to Christoffer comments v2 -> v3: - removal of irq.h from eventfd.c put in a separate patch to increase visibility - properly expose KVM_CAP_IRQFD capability in arm.c - remove CONFIG_HAVE_KVM_IRQCHIP meaningfull only if irq_comm.c is used v1 -> v2: - rebase on 3.17rc1 - move of the dist unlock in process_maintenance - remove of dist lock in __kvm_vgic_sync_hwstate - rewording of the commit message (add resamplefd reference) - remove irq.h Eric Auger (4): KVM: arm/arm64: unset CONFIG_HAVE_KVM_IRQCHIP KVM: introduce kvm_arch_intc_initialized and use it in irqfd KVM: arm/arm64: implement kvm_arch_intc_initialized KVM: arm/arm64: add irqfd support Documentation/virtual/kvm/api.txt | 6 +++- arch/arm/include/asm/kvm_host.h | 2 ++ arch/arm/include/uapi/asm/kvm.h | 3 ++ arch/arm/kvm/Kconfig | 4 +-- arch/arm/kvm/Makefile | 2 +- arch/arm/kvm/arm.c| 10 +++ arch/arm64/include/asm/kvm_host.h | 2 ++ arch/arm64/include/uapi/asm/kvm.h | 3 ++ arch/arm64/kvm/Kconfig| 3 +- arch/arm64/kvm/Makefile | 2 +- include/linux/kvm_host.h | 14 + virt/kvm/arm/vgic.c | 63 --- virt/kvm/eventfd.c| 3 ++ 13 files changed, 107 insertions(+), 10 deletions(-) -- 1.9.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] watchdog: Remove .owner field from cadence driver
On 01/15/2015 04:42 AM, Michal Simek wrote: .owner files is filled by module_platform_driver(). Signed-off-by: Michal Simek --- Big cleanup was done and this new driver was missed. Actually, it was included in 'watchdog: drop owner assignment from platform_drivers' by Wolfram Sang. It just hasn't been applied yet. 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] e100: Don't enable WoL by default on Toshiba devices
On Thu, 2015-01-15 at 14:40 +0100, Ondrej Zary wrote: > On Thursday 13 November 2014, Jeff Kirsher wrote: > > On Wed, 2014-11-12 at 18:18 -0500, David Miller wrote: > > > From: Ondrej Zary > > > Date: Wed, 12 Nov 2014 23:47:25 +0100 > > > > > > > Enabling WoL on some Toshiba laptops (such as Portege R100) > causes > > > > battery drain after shutdown (WoL is active even on battery). > These > > > > laptops have the WoL bit set in EEPROM ID, causing e100 driver > to > > > > enable WoL by default. > > > > > > > > Check subsystem vendor ID and if it's Toshiba, don't enable WoL > by > > > > default from EEPROM settings. > > > > > > > > Fixes > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784 > > > > > > > > Signed-off-by: Ondrej Zary > > > > > > Jeff, are you gonna pick this up? > > > > Yes, sorry I did not catch it earlier. > > What happened to this patch? I don't see it in net.git or > net-next.git > (checked both davem's and jkirsher's) Sorry, I thought I had replied with a NAK on this patch after further review of the changes. We don't fix BIOS issues in the driver especially regarding feature enablement like WoL. We would end up with dozens of these kinds of fixes if we to allow this. You should go back to the OEM and ask for a BIOS update to resolve this or configure udev so that ethtool disables WoL. signature.asc Description: This is a digitally signed message part
[PATCH 1/2] tty: serial: 8250_core: Remove trailing whitespaces
No functional changes. Signed-off-by: Michal Simek --- drivers/tty/serial/8250/8250_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 11c66856ba2f..65e52c9109e2 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -884,7 +884,7 @@ static int broken_efr(struct uart_8250_port *up) /* * Exar ST16C2550 "A2" devices incorrectly detect as * having an EFR, and report an ID of 0x0201. See -* http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-11/4812.html +* http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-11/4812.html */ if (autoconfig_read_divisor_id(up) == 0x0201 && size_fifo(up) == 16) return 1; @@ -1239,7 +1239,7 @@ static void autoconfig(struct uart_8250_port *up, unsigned int probeflags) serial_out(up, UART_LCR, save_lcr); port->fifosize = uart_config[up->port.type].fifo_size; - old_capabilities = up->capabilities; + old_capabilities = up->capabilities; up->capabilities = uart_config[port->type].flags; up->tx_loadsz = uart_config[port->type].tx_loadsz; -- 1.8.2.3 pgpo1MExxATmR.pgp Description: PGP signature
[PATCH] openrisc: Remove unnecessary KERN_INFO in time.c
This patch remove unnecessary KERN_INFO in time.c
Signed-off-by: Masanari Iida
---
arch/openrisc/kernel/time.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/openrisc/kernel/time.c b/arch/openrisc/kernel/time.c
index 7c52e94..3b50ffd 100644
--- a/arch/openrisc/kernel/time.c
+++ b/arch/openrisc/kernel/time.c
@@ -53,20 +53,20 @@ static void openrisc_timer_set_mode(enum clock_event_mode
mode,
{
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
- pr_debug(KERN_INFO "%s: periodic\n", __func__);
+ pr_debug("%s: periodic\n", __func__);
BUG();
break;
case CLOCK_EVT_MODE_ONESHOT:
- pr_debug(KERN_INFO "%s: oneshot\n", __func__);
+ pr_debug("%s: oneshot\n", __func__);
break;
case CLOCK_EVT_MODE_UNUSED:
- pr_debug(KERN_INFO "%s: unused\n", __func__);
+ pr_debug("%s: unused\n", __func__);
break;
case CLOCK_EVT_MODE_SHUTDOWN:
- pr_debug(KERN_INFO "%s: shutdown\n", __func__);
+ pr_debug("%s: shutdown\n", __func__);
break;
case CLOCK_EVT_MODE_RESUME:
- pr_debug(KERN_INFO "%s: resume\n", __func__);
+ pr_debug("%s: resume\n", __func__);
break;
}
}
--
2.3.0.rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] tty: serial: 8250_core: Check that port->line is >=0
This patch should be the part of: "tty: serial: 8250_core: use the ->line argument as a hint in serial8250_find_match_or_unused()" (sha1: 59b3e898ddfc81a65975043b5eb44103cc29ff6e) port->line can be setup by DT driver to -1 which needs to be also checked. Signed-off-by: Michal Simek --- I have similar patch to 59b3e898ddfc81a65975043b5eb44103cc29ff6e in xilinx tree for a while and port->line can be -1. The second part of this also should be (what other drivers do) reading aliases via of_alias_get_id() in of_serial.c:of_platform_serial_probe() which setup port.line. --- drivers/tty/serial/8250/8250_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 65e52c9109e2..aab765177763 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -3512,7 +3512,8 @@ static struct uart_8250_port *serial8250_find_match_or_unused(struct uart_port * /* try line number first if still available */ i = port->line; - if (i < nr_uarts && serial8250_ports[i].port.type == PORT_UNKNOWN && + if (i >= 0 && i < nr_uarts && + serial8250_ports[i].port.type == PORT_UNKNOWN && serial8250_ports[i].port.iobase == 0) return _ports[i]; /* -- 1.8.2.3 pgp_2Fh4J93gV.pgp Description: PGP signature
[PATCH v2 8/8] ARM: at91: move at91rm9200_idle() to clk/at91/pmc.c
Move at91rm9200_idle() along with at91sam9_idle() in clk/at91/pmc.c.
Signed-off-by: Alexandre Belloni
Acked-by: Michael Turquette
---
arch/arm/mach-at91/at91rm9200.c | 9 -
arch/arm/mach-at91/generic.h| 1 +
drivers/clk/at91/pmc.c | 9 +
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index fc7c26138037..3be1963f5c56 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -21,14 +21,6 @@
#include "soc.h"
#include "generic.h"
-static void at91rm9200_idle(void)
-{
- /*
-* Disable the processor clock. The processor will be automatically
-* re-enabled by an interrupt or by a reset.
-*/
- at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
-}
static void at91rm9200_restart(enum reboot_mode reboot_mode, const char *cmd)
{
@@ -49,7 +41,6 @@ static void __init at91rm9200_initialize(void)
arm_pm_restart = at91rm9200_restart;
}
-
AT91_SOC_START(at91rm9200)
.init = at91rm9200_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 1823a779182d..44fc725edcf1 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -25,6 +25,7 @@ extern void __init at91_dt_initialize(void);
extern void at91rm9200_timer_init(void);
/* idle */
+extern void at91rm9200_idle(void);
extern void at91sam9_idle(void);
/* Matrix */
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 386999b4f8eb..f07c8152e5cc 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -27,6 +27,15 @@
void __iomem *at91_pmc_base;
EXPORT_SYMBOL_GPL(at91_pmc_base);
+void at91rm9200_idle(void)
+{
+ /*
+* Disable the processor clock. The processor will be automatically
+* re-enabled by an interrupt or by a reset.
+*/
+ at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
+}
+
void at91sam9_idle(void)
{
at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
--
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/
[PATCH v2 3/8] ARM: at91: pm: add UDP and UHP checks to newer SoCs
Check UDP and UHP on sam9x5, sam9n12 and the sama5 series.
Check UHP on the sam9g45.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/pm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 515791edcc60..71cc845263dc 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -275,6 +275,7 @@ static int __init at91_pm_init(void)
pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
+ at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP;
if (of_machine_is_compatible("atmel,at91rm9200")) {
/*
@@ -286,14 +287,8 @@ static int __init at91_pm_init(void)
at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
AT91RM9200_PMC_UDP;
at91_pm_data.memctrl = AT91_MEMCTRL_MC;
- } else if (of_machine_is_compatible("atmel,at91sam9260") ||
- of_machine_is_compatible("atmel,at91sam9g20") ||
- of_machine_is_compatible("atmel,at91sam9261") ||
- of_machine_is_compatible("atmel,at91sam9g10") ||
- of_machine_is_compatible("atmel,at91sam9263")) {
- at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP |
- AT91SAM926x_PMC_UDP;
} else if (of_machine_is_compatible("atmel,at91sam9g45")) {
+ at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP;
at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
}
--
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/
[PATCH v2 6/8] ARM: at91: sama5d4: remove useless call to at91_init_sram
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/sama5d4.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-at91/sama5d4.c b/arch/arm/mach-at91/sama5d4.c
index 7638509639f4..fa127fb79221 100644
--- a/arch/arm/mach-at91/sama5d4.c
+++ b/arch/arm/mach-at91/sama5d4.c
@@ -56,7 +56,6 @@ static struct map_desc at91_io_desc[] __initdata = {
static void __init sama5d4_map_io(void)
{
iotable_init(at91_io_desc, ARRAY_SIZE(at91_io_desc));
- at91_init_sram(0, SAMA5D4_NS_SRAM_BASE, SAMA5D4_NS_SRAM_SIZE);
}
AT91_SOC_START(sama5d4)
--
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/
[PATCH v2 7/8] ARM: at91: remove unused at91_init_sram
SRAM initialization is now done through the mmio-sram driver and
at91_init_sram() is not called anymore, remove it.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/generic.h | 2 --
arch/arm/mach-at91/setup.c | 20
2 files changed, 22 deletions(-)
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index fae7a703813c..1823a779182d 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -17,8 +17,6 @@
/* Map io */
extern void __init at91_map_io(void);
extern void __init at91_alt_map_io(void);
-extern void __init at91_init_sram(int bank, unsigned long base,
- unsigned int length);
/* Processors */
extern void __init at91_dt_initialize(void);
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index e3c21b458bb8..4c184285d38f 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -34,26 +34,6 @@ EXPORT_SYMBOL(at91_soc_initdata);
void __iomem *at91_ramc_base[2];
EXPORT_SYMBOL_GPL(at91_ramc_base);
-static struct map_desc sram_desc[2] __initdata;
-
-void __init at91_init_sram(int bank, unsigned long base, unsigned int length)
-{
- struct map_desc *desc = _desc[bank];
-
- desc->virtual = (unsigned long)AT91_IO_VIRT_BASE - length;
- if (bank > 0)
- desc->virtual -= sram_desc[bank - 1].length;
-
- desc->pfn = __phys_to_pfn(base);
- desc->length = length;
- desc->type = MT_MEMORY_RWX_NONCACHED;
-
- pr_info("sram at 0x%lx of 0x%x mapped at 0x%lx\n",
- base, length, desc->virtual);
-
- iotable_init(desc, 1);
-}
-
static struct map_desc at91_io_desc __initdata __maybe_unused = {
.virtual= (unsigned long)AT91_VA_BASE_SYS,
.pfn= __phys_to_pfn(AT91_BASE_SYS),
--
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/
[PATCH v2 4/8] ARM: at91: pm: prepare for multiplatform
Split at91_pm_init() in three variants that are called by the respective SoCs
.init_machine. This allows to remove the of_machine_is_compatible() calls and
move at91_pm_init() out of arch_initcall() which is required for multiplatform.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/board-dt-rm9200.c | 11
arch/arm/mach-at91/board-dt-sam9.c | 27
arch/arm/mach-at91/board-dt-sama5.c | 1 +
arch/arm/mach-at91/generic.h | 12 +
arch/arm/mach-at91/pm.c | 49
5 files changed, 79 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-at91/board-dt-rm9200.c
b/arch/arm/mach-at91/board-dt-rm9200.c
index a15ab6f8de00..5f82a65153e1 100644
--- a/arch/arm/mach-at91/board-dt-rm9200.c
+++ b/arch/arm/mach-at91/board-dt-rm9200.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,6 +31,15 @@ static void __init at91rm9200_dt_timer_init(void)
at91rm9200_timer_init();
}
+static void __init rm9200_dt_device_init(void)
+{
+ at91_rm9200_pm_init();
+
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+
+
static const char *at91rm9200_dt_board_compat[] __initdata = {
"atmel,at91rm9200",
NULL
@@ -39,5 +49,6 @@ DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200 (Device
Tree)")
.init_time = at91rm9200_dt_timer_init,
.map_io = at91_map_io,
.init_early = at91_dt_initialize,
+ .init_machine = rm9200_dt_device_init,
.dt_compat = at91rm9200_dt_board_compat,
MACHINE_END
diff --git a/arch/arm/mach-at91/board-dt-sam9.c
b/arch/arm/mach-at91/board-dt-sam9.c
index f99246aa9b38..0fe1ced608c5 100644
--- a/arch/arm/mach-at91/board-dt-sam9.c
+++ b/arch/arm/mach-at91/board-dt-sam9.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -23,6 +24,12 @@
#include "generic.h"
+static void __init sam9_dt_device_init(void)
+{
+ at91_sam9260_pm_init();
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
static const char *at91_dt_board_compat[] __initdata = {
"atmel,at91sam9",
NULL
@@ -32,5 +39,25 @@ DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM (Device Tree)")
/* Maintainer: Atmel */
.map_io = at91_map_io,
.init_early = at91_dt_initialize,
+ .init_machine = sam9_dt_device_init,
.dt_compat = at91_dt_board_compat,
MACHINE_END
+
+static void __init sam9g45_dt_device_init(void)
+{
+ at91_sam9g45_pm_init();
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *at91_9g45_board_compat[] __initconst = {
+ "atmel,at91sam9g45",
+ NULL
+};
+
+DT_MACHINE_START(at91sam9g45_dt, "Atmel AT91SAM9G45")
+ /* Maintainer: Atmel */
+ .map_io = at91_map_io,
+ .init_early = at91_dt_initialize,
+ .init_machine = sam9g45_dt_device_init,
+ .dt_compat = at91_9g45_board_compat,
+MACHINE_END
diff --git a/arch/arm/mach-at91/board-dt-sama5.c
b/arch/arm/mach-at91/board-dt-sama5.c
index 8fb9ef5333f1..44d372a22a29 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -28,6 +28,7 @@
static void __init sama5_dt_device_init(void)
{
+ at91_sam9260_pm_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 54f3837a0a4d..fae7a703813c 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -31,4 +31,16 @@ extern void at91sam9_idle(void);
/* Matrix */
extern void at91_ioremap_matrix(u32 base_addr);
+
+
+#ifdef CONFIG_PM
+extern void __init at91_rm9200_pm_init(void);
+extern void __init at91_sam9260_pm_init(void);
+extern void __init at91_sam9g45_pm_init(void);
+#else
+void __init at91_rm9200_pm_init(void) { }
+void __init at91_sam9260_pm_init(void) { }
+void __init at91_sam9g45_pm_init(void) { }
+#endif
+
#endif /* _AT91_GENERIC_H */
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 71cc845263dc..778f11132b31 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -266,7 +266,7 @@ put_node:
#endif
-static int __init at91_pm_init(void)
+static void __init at91_pm_init(void)
{
#ifdef CONFIG_AT91_SLOW_CLOCK
at91_pm_sram_init();
@@ -274,29 +274,36 @@ static int __init at91_pm_init(void)
pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
- at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
- at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP;
-
- if (of_machine_is_compatible("atmel,at91rm9200")) {
- /*
-* AT91RM9200 SDRAM low-power mode cannot be used with
-* self-refresh.
-*/
-
[PATCH v2 1/8] ARM: at91: pm: rework cpu detection
Store SoC differences in a struct to remove cpu_is_* usage.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/pm.c | 54 ++---
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9b15169a1c62..79aa793d1f00 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,11 @@
#include "generic.h"
#include "pm.h"
+static struct {
+ unsigned long uhp_udp_mask;
+ int memctrl;
+} at91_pm_data;
+
static void (*at91_pm_standby)(void);
static int at91_pm_valid_state(suspend_state_t state)
@@ -71,17 +77,9 @@ static int at91_pm_verify_clocks(void)
scsr = at91_pmc_read(AT91_PMC_SCSR);
/* USB must not be using PLLB */
- if (cpu_is_at91rm9200()) {
- if ((scsr & (AT91RM9200_PMC_UHP | AT91RM9200_PMC_UDP)) != 0) {
- pr_err("AT91: PM - Suspend-to-RAM with USB still
active\n");
- return 0;
- }
- } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() ||
cpu_is_at91sam9263()
- || cpu_is_at91sam9g20() || cpu_is_at91sam9g10()) {
- if ((scsr & (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) {
- pr_err("AT91: PM - Suspend-to-RAM with USB still
active\n");
- return 0;
- }
+ if ((scsr & at91_pm_data.uhp_udp_mask) != 0) {
+ pr_err("AT91: PM - Suspend-to-RAM with USB still active\n");
+ return 0;
}
/* PCK0..PCK3 must be disabled, or configured to use clk32k */
@@ -149,18 +147,13 @@ static int at91_pm_enter(suspend_state_t state)
* turning off the main oscillator; reverse on wakeup.
*/
if (slow_clock) {
- int memctrl = AT91_MEMCTRL_SDRAMC;
-
- if (cpu_is_at91rm9200())
- memctrl = AT91_MEMCTRL_MC;
- else if (cpu_is_at91sam9g45())
- memctrl = AT91_MEMCTRL_DDRSDR;
#ifdef CONFIG_AT91_SLOW_CLOCK
/* copy slow_clock handler to SRAM, and call it
*/
memcpy(slow_clock, at91_slow_clock,
at91_slow_clock_sz);
#endif
slow_clock(at91_pmc_base, at91_ramc_base[0],
- at91_ramc_base[1], memctrl);
+ at91_ramc_base[1],
+ at91_pm_data.memctrl);
break;
} else {
pr_info("AT91: PM - no slow clock mode enabled
...\n");
@@ -237,10 +230,29 @@ static int __init at91_pm_init(void)
pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
- /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
- if (cpu_is_at91rm9200())
+ at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
+
+ if (of_machine_is_compatible("atmel,at91rm9200")) {
+ /*
+* AT91RM9200 SDRAM low-power mode cannot be used with
+* self-refresh.
+*/
at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
-
+
+ at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
+ AT91RM9200_PMC_UDP;
+ at91_pm_data.memctrl = AT91_MEMCTRL_MC;
+ } else if (of_machine_is_compatible("atmel,at91sam9260") ||
+ of_machine_is_compatible("atmel,at91sam9g20") ||
+ of_machine_is_compatible("atmel,at91sam9261") ||
+ of_machine_is_compatible("atmel,at91sam9g10") ||
+ of_machine_is_compatible("atmel,at91sam9263")) {
+ at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP |
+ AT91SAM926x_PMC_UDP;
+ } else if (of_machine_is_compatible("atmel,at91sam9g45")) {
+ at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
+ }
+
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(_cpuidle_device);
--
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/
[PATCH v2 5/8] ARM: at91: remove useless map_io
Now that the SRAM is initialized by the mmio-sram driver, .map_io is useless.
remove it.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/at91rm9200.c | 6 --
arch/arm/mach-at91/at91sam9260.c | 27 ---
arch/arm/mach-at91/at91sam9261.c | 9 -
arch/arm/mach-at91/at91sam9263.c | 7 ---
arch/arm/mach-at91/at91sam9g45.c | 7 ---
arch/arm/mach-at91/at91sam9n12.c | 6 --
arch/arm/mach-at91/at91sam9rl.c | 18 --
arch/arm/mach-at91/at91sam9x5.c | 6 --
arch/arm/mach-at91/sama5d3.c | 6 --
9 files changed, 92 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index b52916947535..fc7c26138037 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -42,11 +42,6 @@ static void at91rm9200_restart(enum reboot_mode reboot_mode,
const char *cmd)
/*
* AT91RM9200 processor initialization
* */
-static void __init at91rm9200_map_io(void)
-{
- /* Map peripherals */
- at91_init_sram(0, AT91RM9200_SRAM_BASE, AT91RM9200_SRAM_SIZE);
-}
static void __init at91rm9200_initialize(void)
{
@@ -56,6 +51,5 @@ static void __init at91rm9200_initialize(void)
AT91_SOC_START(at91rm9200)
- .map_io = at91rm9200_map_io,
.init = at91rm9200_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index 34e2abe82ae4..ab9841c8b0d5 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -22,38 +22,11 @@
* AT91SAM9260 processor initialization
* */
-static void __init at91sam9xe_map_io(void)
-{
- unsigned long sram_size;
-
- switch (at91_soc_initdata.cidr & AT91_CIDR_SRAMSIZ) {
- case AT91_CIDR_SRAMSIZ_32K:
- sram_size = 2 * SZ_16K;
- break;
- case AT91_CIDR_SRAMSIZ_16K:
- default:
- sram_size = SZ_16K;
- }
-
- at91_init_sram(0, AT91SAM9XE_SRAM_BASE, sram_size);
-}
-
-static void __init at91sam9260_map_io(void)
-{
- if (cpu_is_at91sam9xe())
- at91sam9xe_map_io();
- else if (cpu_is_at91sam9g20())
- at91_init_sram(0, AT91SAM9G20_SRAM_BASE, AT91SAM9G20_SRAM_SIZE);
- else
- at91_init_sram(0, AT91SAM9260_SRAM_BASE, AT91SAM9260_SRAM_SIZE);
-}
-
static void __init at91sam9260_initialize(void)
{
arm_pm_idle = at91sam9_idle;
}
AT91_SOC_START(at91sam9260)
- .map_io = at91sam9260_map_io,
.init = at91sam9260_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 47878b849975..2029096b93fa 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -21,20 +21,11 @@
* AT91SAM9261 processor initialization
* */
-static void __init at91sam9261_map_io(void)
-{
- if (cpu_is_at91sam9g10())
- at91_init_sram(0, AT91SAM9G10_SRAM_BASE, AT91SAM9G10_SRAM_SIZE);
- else
- at91_init_sram(0, AT91SAM9261_SRAM_BASE, AT91SAM9261_SRAM_SIZE);
-}
-
static void __init at91sam9261_initialize(void)
{
arm_pm_idle = at91sam9_idle;
}
AT91_SOC_START(at91sam9261)
- .map_io = at91sam9261_map_io,
.init = at91sam9261_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index aabcb66145d0..1fe672a05513 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -20,18 +20,11 @@
* AT91SAM9263 processor initialization
* */
-static void __init at91sam9263_map_io(void)
-{
- at91_init_sram(0, AT91SAM9263_SRAM0_BASE, AT91SAM9263_SRAM0_SIZE);
- at91_init_sram(1, AT91SAM9263_SRAM1_BASE, AT91SAM9263_SRAM1_SIZE);
-}
-
static void __init at91sam9263_initialize(void)
{
arm_pm_idle = at91sam9_idle;
}
AT91_SOC_START(at91sam9263)
- .map_io = at91sam9263_map_io,
.init = at91sam9263_initialize,
AT91_SOC_END
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index b044dbcc0dcc..f3130501fa75 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -20,18 +20,11 @@
/*
* AT91SAM9G45 processor initialization
* */
-
-static void __init at91sam9g45_map_io(void)
-{
- at91_init_sram(0, AT91SAM9G45_SRAM_BASE, AT91SAM9G45_SRAM_SIZE);
-}
-
static void __init at91sam9g45_initialize(void)
RE: [PATCH v7 0/5] phy: qcom-ufs: add support for QUALCOMM
Reviewed-by: Dov Levenglick Dov Levenglick QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Yaniv Gardi > Sent: Thursday, January 15, 2015 4:33 PM > To: james.bottom...@hansenpartnership.com; h...@infradead.org > Cc: linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org; linux-arm- > m...@vger.kernel.org; santos...@gmail.com; linux-scsi- > ow...@vger.kernel.org; subha...@codeaurora.org; > yga...@codeaurora.org; n...@codeaurora.org; dra...@codeaurora.org > Subject: [PATCH v7 0/5] phy: qcom-ufs: add support for QUALCOMM > > Changes from V6: > - change#1 in the V6 series: 0001-phy-qcom-ufs-add-support-for-20nm-phy > has been divided into 2 patches: > A: phy: qcom-ufs: add support for QUALCOMM Technologies UFS PHY > drivers > B: phy: qcom-ufs: add support for 20nm phy > in order to seperate the common code of the Qualcomm Technologies > UFS PHYs and the specific UFS PHYs that will be added. > > Yaniv Gardi (5): > phy: qcom-ufs: add support for QUALCOMM Technologies UFS PHY drivers > phy: qcom-ufs: add support for 20nm phy > scsi: ufs-qcom: add support for Qualcomm Technologies Inc platforms > phy: qcom-ufs: add support for 14nm phy > scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS > > drivers/phy/Kconfig |7 + > drivers/phy/Makefile|3 + > drivers/phy/phy-qcom-ufs-i.h| 159 ++ > drivers/phy/phy-qcom-ufs-qmp-14nm.c | 201 +++ > drivers/phy/phy-qcom-ufs-qmp-14nm.h | 177 ++ > drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257 + > drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235 > drivers/phy/phy-qcom-ufs.c | 745 > drivers/scsi/ufs/Kconfig| 25 + > drivers/scsi/ufs/Makefile |2 + > drivers/scsi/ufs/ufs-qcom-ice.c | 520 + > drivers/scsi/ufs/ufs-qcom-ice.h | 113 > drivers/scsi/ufs/ufs-qcom.c | 1058 > +++ > drivers/scsi/ufs/ufs-qcom.h | 195 +++ > include/linux/phy/phy-qcom-ufs.h| 59 ++ > 15 files changed, 3756 insertions(+) > create mode 100644 drivers/phy/phy-qcom-ufs-i.h > create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.c > create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.h > create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c > create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h > create mode 100644 drivers/phy/phy-qcom-ufs.c > create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c > create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.h > create mode 100644 drivers/scsi/ufs/ufs-qcom.c > create mode 100644 drivers/scsi/ufs/ufs-qcom.h > create mode 100644 include/linux/phy/phy-qcom-ufs.h > > -- > 1.8.5.2 > > -- > QUALCOMM ISRAEL, on behalf of 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-scsi" 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 v2 2/8] ARM: at91: pm: use the mmio-sram pool to access SRAM
Now that the SRAM is part of a genpool, use it to allocate memory to use for the
slowclock implementation.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/Kconfig | 1 +
arch/arm/mach-at91/pm.c| 46 +-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index cec0fb5d621a..b7dcef50db23 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -178,6 +178,7 @@ comment "AT91 Feature Selections"
config AT91_SLOW_CLOCK
bool "Suspend-to-RAM disables main oscillator"
+ select SRAM
depends on SUSPEND
help
Select this if you want Suspend-to-RAM to save the most power
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 79aa793d1f00..515791edcc60 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -14,10 +14,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -222,10 +224,52 @@ void at91_pm_set_standby(void (*at91_standby)(void))
}
}
+#ifdef CONFIG_AT91_SLOW_CLOCK
+static void __init at91_pm_sram_init(void)
+{
+ struct gen_pool *sram_pool;
+ phys_addr_t sram_pbase;
+ unsigned long sram_base;
+ struct device_node *node;
+ struct platform_device *pdev;
+
+ node = of_find_compatible_node(NULL, NULL, "mmio-sram");
+ if (!node) {
+ pr_warn("%s: failed to find sram node!\n", __func__);
+ return;
+ }
+
+ pdev = of_find_device_by_node(node);
+ if (!pdev) {
+ pr_warn("%s: failed to find sram device!\n", __func__);
+ goto put_node;
+ }
+
+ sram_pool = dev_get_gen_pool(>dev);
+ if (!sram_pool) {
+ pr_warn("%s: sram pool unavailable!\n", __func__);
+ goto put_node;
+ }
+
+ sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
+ if (!sram_base) {
+ pr_warn("%s: unable to alloc ocram!\n", __func__);
+ goto put_node;
+ }
+
+ sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
+ slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
+
+put_node:
+ of_node_put(node);
+}
+#endif
+
+
static int __init at91_pm_init(void)
{
#ifdef CONFIG_AT91_SLOW_CLOCK
- slow_clock = (void *) (AT91_IO_VIRT_BASE - at91_slow_clock_sz);
+ at91_pm_sram_init();
#endif
pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
--
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/
[PATCH v2 0/8] AT91 cleanup for 3.20 #2
This patch sets is based on AT91 cleanup for 3.20 #1 and depends on AT91 DT for 3.20 #1 because it uses the added SRAM nodes. The first two patches rework the pm code to get rid of cpu_is_xxx (they will be dropped soon) and use the SRAM from the genpool instead of relying on the remap done by at91_init_sram. The 3rd and 4th patches a reworking the pm code further to move at91_pm_init in the .init_machine of the SoCs instead of arch_initcall, to get ready for multiplatform. Then the following patches get rid of at91_init_sram, taking .map_io for almost all SoCs but the sama5d4 (more cleanups coming soon for that part). The final patch moves at91rm9200_idle to clk/at91/pmc.c and allows to almost empty arch/arm/mach-at91/at91rm9200.c (It is actually empty once "Atmel System Timer cleanups" is applied). Changes in v2: - added patch 3 and 4 to remove the calls to of_machine_is_compatible() Alexandre Belloni (8): ARM: at91: pm: rework cpu detection ARM: at91: pm: use the mmio-sram pool to access SRAM ARM: at91: pm: add UDP and UHP checks to newer SoCs ARM: at91: pm: prepare for multiplatform ARM: at91: remove useless map_io ARM: at91: sama5d4: remove useless call to at91_init_sram ARM: at91: remove unused at91_init_sram ARM: at91: move at91rm9200_idle() to clk/at91/pmc.c arch/arm/mach-at91/Kconfig | 1 + arch/arm/mach-at91/at91rm9200.c | 15 - arch/arm/mach-at91/at91sam9260.c | 27 - arch/arm/mach-at91/at91sam9261.c | 9 --- arch/arm/mach-at91/at91sam9263.c | 7 --- arch/arm/mach-at91/at91sam9g45.c | 7 --- arch/arm/mach-at91/at91sam9n12.c | 6 -- arch/arm/mach-at91/at91sam9rl.c | 18 -- arch/arm/mach-at91/at91sam9x5.c | 6 -- arch/arm/mach-at91/board-dt-rm9200.c | 11 arch/arm/mach-at91/board-dt-sam9.c | 27 + arch/arm/mach-at91/board-dt-sama5.c | 1 + arch/arm/mach-at91/generic.h | 15 - arch/arm/mach-at91/pm.c | 110 ++- arch/arm/mach-at91/sama5d3.c | 6 -- arch/arm/mach-at91/sama5d4.c | 1 - arch/arm/mach-at91/setup.c | 20 --- drivers/clk/at91/pmc.c | 9 +++ 18 files changed, 146 insertions(+), 150 deletions(-) -- 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 1/3] input: tsc2007: Add pre-calibration, flipping and rotation
Hi, Am 15.01.2015 um 15:38 schrieb Sebastian Reichel : > Hi, > > On Thu, Jan 15, 2015 at 08:36:44AM +0100, Dr. H. Nikolaus Schaller wrote: >>> 1. Perform conversion in input core rather than individual drivers. I >>> think we should allocate a new bitmaps for some transformations and have >>> the code do X/Y flip/clip of the coordinates. >> >> Do you have a suggestion where this should be (I have no clue how >> the input system works or is structured - we just know how to extend a >> driver that uses it)? >> >>> 2. Standardize on bindings. We already have of-touchscreen.c doing >>> rudimentary parsing, we shoudl look into extending it rather than >>> creating myriad of driver-specific bindings. >> >> Ok, looks reasonable. > > Documentation is in > > Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > >>> Also, do we need swap and flip or do we simply need rotation (like the >>> proposed Broadcom iproc driver has)? >> >> Well, since the DT should describe hardware, there are 3 sets of wires which >> can have a cross-over: X+ and X-, Y+ and Y-, X and Y. >> >> So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an >> interpretation of the result of these connections in combination with some >> panel the touch is glued to and should therefore not be represented in the >> DT. >> >> As a result we have proposed a scheme without explicit rotation. We specify >> what >> coordinates X- and X+ should report at their ends (min, max) because the DT >> programmer has to specify them anyways. Flipping is a result of defining >> these >> coordinates in an ascending or descending way. Only swapping of the X and Y >> wires can’t be implicitly defined so it has its own property. So the scheme >> we >> have proposed tries to optimize the efforts needed to adapt new boards and >> write >> DTs and focus the DT on hardware description. >> >> As a bonus we also specify the min and max value to be reported for the touch >> pressure (Z axis) using the same basic principle. >> >> And it is a pure add-on on top of the existing driver so that it attempts not >> to break existing device trees. > > from what I can see there are no in-tree-users using any of the > new properties. Not yet. But our [patch 2/3] of this series defines the DT entry for the GTA04 devices: https://lkml.org/lkml/2014/9/30/663 > >> Maybe could you accept it as a first step for this specific driver (and >> let’s do >> the big standardization work later on)? > > That does not work, since you create an ABI. Hm. I don’t understand what you mean with creating an ABI? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] init/main.c: prevent increase of console_loglevel by 'quiet' kernel parameter
From: Sergey Popov
Prevent increase of console_loglevel by 'quiet'
'quiet' kernel option that follows the 'loglevel=N' should
not blindly overwrite console_loglevel, instead it should
respect and keep lower 'loglevel'.
Signed-off-by: Sergey Popov
---
init/main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Some drivers tend to print error messages (ex: 'drm/i810 does not support SMP')
to the console
that we at our company don't want to show to people. We use 'quiet' kernel
option to hide kernel decompressing progress and other messages not related to
printk. But to hide error messages from drivers we use 'loglevel=3' parameter
as well. But when it's _before_ the quiet, then quiet overrides loglevel=3 and
set it to be 4.
I think that's a bug, and here's simple solution for it. The only way to live
without this patch is to pass 'loglevel=3' after the 'quiet'. This issue is
known to the community, but everyone is using workaround (ex:
https://wiki.archlinux.org/index.php/Silent_boot).
I had enough inspiration to dive into the linux code and fix it.
--
with best regards,
Sergey Popov
phone: +380687507707
skype: uazure
vk.com/uazure
fb.com/uazurediff --git a/init/main.c b/init/main.c
index 61b99376..91fc78b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -211,7 +211,12 @@ static int __init debug_kernel(char *str)
static int __init quiet_kernel(char *str)
{
- console_loglevel = CONSOLE_LOGLEVEL_QUIET;
+ /*
+ * 'quiet' option should not raise console_loglevel, it's only
+ * allowed to lower it
+ */
+ if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
+ console_loglevel = CONSOLE_LOGLEVEL_QUIET;
return 0;
}
Re: futex(2) man page update help request
[Adding a few people to CC that have expressed interest in the progress of the updates of this page, or who may be able to provide review feedback. Eventually, you'll all get CCed on the new draft of the page.] Hello Thomas, On 05/15/2014 04:14 PM, Thomas Gleixner wrote: > On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote: >> And that universe would love to have your documentation of >> FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-), > > I give you almost the full treatment, but I leave REQUEUE_PI to > Darren and FUTEX_WAKE_OP to Jakub. :) Thank you for the great effort you put into compiling the text below, and apologies for my long delay in following up. I've integrated almost all of your suggestions into the manual page. I will shortly send out a new draft of the page that contains various FIXMEs for points that remain unclear. Most of the rest of this mail is just a checklist noting what I did with your comments. No response is needed in most cases, but there are a very few open questions in this mail that, to help you find them, I have marked with "???". If you (or someone else) could reply to those, I would be grateful. In the next day or two, I hope to send out the new version of the futex(2) page for review. The new draft is a bit bigger (okay -- 4 x bigger) than the current page. And there are a quite number of FIXMEs that I've placed in the page for various points--some minor, but a few major--that need to be checked or fixed. Would you have some time to review that page? For that matter, if anyone else would have time for reviewing the page, could they shout out now. It's perhaps unlikely, but I am worried about getting a thundering herd of comments, and bringing the page to the state where I have it now has already been a fairly demanding task. == > FUTEX_WAIT > > < Existing blurb seems ok > > > Related return values > > [EFAULT] Kernel was unable to access the futex value at uaddr. Added/reworked. > [EINVAL] The supplied uaddr argument does not pouint to a valid > object, i.e. pointer is not 4 byte aligned Added. > [EINVAL] The supplied timeout argument is not normalized. Added, but with more detail. > [EWOULDBLOCK] The atomic enqueueing failed. Added. Note, however, that for consistency, I'll use EAGAIN throughout the page. > User space value at uaddr > is not equal val argument. Was already present. > [ETIMEDOUT] timeout expired Was present, but I have now added more detail. == > FUTEX_WAKE > > < Existing blurb seems ok > > > Related return values > > [EFAULT] Kernel was unable to access the futex value at uaddr. Added/reworked. > [EINVAL] The supplied uaddr argument does not point to a valid > object, i.e. pointer is not 4 byte aligned Added. > [EINVAL] The kernel detected inconsistent state between the user > space state at uaddr and the kernel state, i.e. it detected a waiter > which waits in FUTEX_LOCK_PI Added. == > FUTEX_REQUEUE > > Existing blurb seems ok , except for this: > > The argument val contains the number of waiters on uaddr which are > immediately woken up. > The timeout argument is abused to transport the number of waiters > which are requeued to the futex at uaddr2. The pointer is typecasted > to u32. What I've actually done with the main text for FUTEX_REQUEUE is defer to the (now-expanded) discussion of FUTEX_CMP_REQUEUE. > [EFAULT] Kernel was unable to access the futex value at uaddr or > uaddr2 Added/reworked. > [EINVAL] The supplied uaddr/uaddr2 arguments do not point to a valid > object, i.e. pointer is not 4 byte aligned Added. > [EINVAL] The kernel detected inconsistent state between the user > space state at uaddr and the kernel state, i.e. it detected a waiter > which waits in FUTEX_LOCK_PI on uaddr Added. > [EINVAL] uaddr equal uaddr2. Requeue to same futex. ??? I added this, but does this error not occur only for PI requeues? == > FUTEX_REQUEUE_CMP > > Existing blurb seems ok , except for this: [[ > The argument val is contains the number of waiters on uaddr which are > immediately woken up. > > The timeout argument is abused to transport the number of waiters > which are requeued to the futex at uaddr2. The pointer is typecasted > to u32. ]] Covered now (in more detail). > Related return values > > [EFAULT] Kernel was unable to access the futex value at uaddr or > uaddr2 Added/reworked. > [EINVAL] The supplied uaddr/uaddr2 arguments do not point to a valid > object, i.e. pointer is not 4 byte aligned Added. > [EINVAL] uaddr equal uaddr2. Requeue to same futex. Added. > [EINVAL] The kernel detected inconsistent state between the user > space state at uaddr and the kernel state, i.e. it detected a waiter > which waits in FUTEX_LOCK_PI on uaddr Added > [EAGAIN] uaddr1 readout is not equal the compare value in argument > val3 Was already present. == > FUTEX_WAKE_OP > > > Jakub, can you please explain it? I'm lost :) I had a read of
Re: futex(2) man page update help request
Hello Darren, I give you the same apology as to Thomas for the long-delayed response to your mail. And I repeat my note to Thomas: In the next day or two, I hope to send out the new version of the futex(2) page for review. The new draft is a bit bigger (okay -- 4 x bigger) than the current page. And there are a quite number of FIXMEs that I've placed in the page for various points--some minor, but a few major--that need to be checked or fixed. Would you have some time to review that page? In the meantime, I have a couple of questions, which, if you could answer them, I would work some changes into the page before sending. 1. In various places, distinction is made between non-PI futexs and PI futexes. But what determines that distinction? From the kernel's perspective, hat make a futex one type or another? I presume it is to do with the types of blocking waiters on the futex, but it would be good to have a formal definition. 2. Can you say something about the pairing requirements of FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI. What is the requirement and why do we need it? Most of the rest of this mail is just a checklist noting what I did with your comments. No response is needed in most cases, but there is one that I have marked with "???". If you could reply to that. I'd be grateful. On 05/15/2014 10:35 PM, Darren Hart wrote: > On 5/15/14, 7:14, "Thomas Gleixner" wrote: > > Wow Thomas, I planned to do exactly this and you beat me to it. Again. > Thanks for getting this started. > > Michael, I imagine you want something more condensed, and I'll add to what > tglx posted (inline below) to try and get you that, but if you have > questions and need to fill in the gap, the paper I presented at RTLWS11 in > '09 covers this particularly nasty OPCODE in detail: > > http://lwn.net/images/conf/rtlws11/papers/proc/p10.pdf > > I believe Michael is looking for some higher level documentation, like how > to use these and what they are intended for. Yes, that would be good. > Probably something more like > Ulrich's Futexes are Tricky paper - but let's start with getting the op > codes, arguments, and return codes fleshed out. Okay. > For all the PI opcodes, we should probably mention something about the > futex value scheme (TID), whereas the other opcodes do not require any > specific value scheme. > > No Owner: 0 > Owner:TID > Waiters: TID | FUTEX_WAITERS > > This is the relevant section from the referenced paper: > > The PI futex operations diverge from the oth- > ers in that they impose a policy describing how > the futex value is to be used. If the lock is un- > owned, the futex value shall be 0. If owned, it > shall be the thread id (tid) of the owning thread. > If there are threads contending for the lock, then > the FUTEX_WAITERS flag is set. With this policy in > place, userspace can atomically acquire an unowned > lock or release an uncontended lock using an atomic > instruction and their own tid. A non-zero futex > value will force waiters into the kernel to lock. The > FUTEX_WAITERS flag forces the owner into the kernel > to unlock. If the callers are forced into the kernel, > they then deal directly with an underlying rt_mutex > which implements the priority inheritance semantics. > After the rt_mutex is acquired, the futex value is up- > dated accordingly, before the calling thread returns > to userspace. > > It is important to note that the kernel will update the futex value prior > to returning to userspace. Unlike other futex op codes, > FUTEX_CMP_REUQUE_PI (and FUTEX_WAIT_REQUEUE_PI, FUTEX_LOCK_PI are designed > for the implementation of very specific IPC mechanisms). ??? Great text. May I presume that I can take this text and freely adapt it for the man page? (Actually, this is a request for forgiveness, rather than permission :-).) >> FUTEX_CMP_REQUEUE_PI >> >> PI aware variant of FUTEX_CMP_REQUEUE. Inner futex at uaddr is >> a non PI futex. Outer futex to which is requeued is a PI futex >> at uaddr2. > > Inner/outer terminology applies specifically to the glibc pthread > condition variable and mutex use case, but is overly specific for the man > page. Consider: > > PI aware variant for FUTEX_CMP_REQUEUE. Requeue tasks blocked on uaddr via > FUTEX_WAIT_REQUEUE_PI from a non-PI source futex (uaddr) to a PI target > futex (uaddr2). Thanks for that text. It is easier to grasp. >> >> The waiters on uaddr must wait in FUTEX_WAIT_REQUEUE_PI. >> >> The argument val is contains the number of waiters on uaddr >> which are immediately woken up. Must be 1 for this opcode. > > Because the point is to avoid the thundering herd in the first place, and > other nasty little races and faulting corner cases... I added the piece about "thundering herd". >> The timeout argument is abused to transport the number of >> waiters which are requeued on to the futex at
Re: [PATCH v7 1/5] phy: qcom-ufs: add support for QUALCOMM Technologies UFS PHY drivers
Reviewed-by: Dov Levenglick
> This change adds a generic and common API support for ufs phy QUALCOMM
> Technologies. This support provides common code and also points
> to specific phy callbacks to differentiate between different behaviors
> of frequent use-cases (like power on, power off, phy calibration etc).
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/phy/Kconfig | 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-qcom-ufs-i.h | 118 +++
> drivers/phy/phy-qcom-ufs.c | 745
> +++
> 4 files changed, 871 insertions(+)
> create mode 100644 drivers/phy/phy-qcom-ufs-i.h
> create mode 100644 drivers/phy/phy-qcom-ufs.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..26a7623 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -277,4 +277,11 @@ config PHY_STIH41X_USB
> Enable this to support the USB transceiver that is part of
> STMicroelectronics STiH41x SoC series.
>
> +config PHY_QCOM_UFS
> + tristate "Qualcomm UFS PHY driver"
> + depends on OF && ARCH_MSM
> + select GENERIC_PHY
> + help
> + Support for UFS PHY on QCOM chipsets.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..335965d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,3 +34,4 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)+=
> phy-spear1340-miphy.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
> obj-$(CONFIG_PHY_STIH407_USB)+= phy-stih407-usb.o
> obj-$(CONFIG_PHY_STIH41X_USB)+= phy-stih41x-usb.o
> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
> new file mode 100644
> index 000..dac200f
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-ufs-i.h
> @@ -0,0 +1,118 @@
> +/*
> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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.
> + *
> + */
> +
> +#ifndef UFS_QCOM_PHY_I_H_
> +#define UFS_QCOM_PHY_I_H_
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define UFS_QCOM_PHY_NAME_LEN30
> +
> +struct ufs_qcom_phy_calibration {
> + u32 reg_offset;
> + u32 cfg_value;
> +};
> +
> +struct ufs_qcom_phy_vreg {
> + const char *name;
> + struct regulator *reg;
> + int max_uA;
> + int min_uV;
> + int max_uV;
> + bool enabled;
> + bool is_always_on;
> +};
> +
> +struct ufs_qcom_phy {
> + struct list_head list;
> + struct device *dev;
> + void __iomem *mmio;
> + void __iomem *dev_ref_clk_ctrl_mmio;
> + struct clk *tx_iface_clk;
> + struct clk *rx_iface_clk;
> + bool is_iface_clk_enabled;
> + struct clk *ref_clk_src;
> + struct clk *ref_clk_parent;
> + struct clk *ref_clk;
> + bool is_ref_clk_enabled;
> + bool is_dev_ref_clk_enabled;
> + struct ufs_qcom_phy_vreg vdda_pll;
> + struct ufs_qcom_phy_vreg vdda_phy;
> + struct ufs_qcom_phy_vreg vddp_ref_clk;
> + unsigned int quirks;
> +
> + /*
> + * If UFS link is put into Hibern8 and if UFS PHY analog hardware
> is
> + * power collapsed (by clearing UFS_PHY_POWER_DOWN_CONTROL),
> Hibern8
> + * exit might fail even after powering on UFS PHY analog hardware.
> + * Enabling this quirk will help to solve above issue by doing
> + * custom PHY settings just before PHY analog power collapse.
> + */
> + #define UFS_QCOM_PHY_QUIRK_HIBERN8_EXIT_AFTER_PHY_PWR_COLLAPSE
> BIT(0)
> +
> + u8 host_ctrl_rev_major;
> + u16 host_ctrl_rev_minor;
> + u16 host_ctrl_rev_step;
> +
> + char name[UFS_QCOM_PHY_NAME_LEN];
> + struct ufs_qcom_phy_calibration *cached_regs;
> + int cached_regs_table_size;
> + bool is_powered_on;
> + struct ufs_qcom_phy_specific_ops *phy_spec_ops;
> +};
> +
> +/**
> + * struct ufs_qcom_phy_specific_ops - set of pointers to functions which
> have a
> + * specific implementation per phy. Each UFS phy, should implement
> + * those functions according to its spec and requirements
> + * @calibrate_phy: pointer to a function that calibrate the phy
> + * @start_serdes: pointer to a function that starts the serdes
> + * @is_physical_coding_sublayer_ready: pointer to a function that
> + * checks pcs readiness. returns 0 for success and non-zero for error.
> + * @set_tx_lane_enable: pointer to a function that enable tx lanes
> + * @power_control: pointer to a function that controls
Re: [PATCH v7 2/5] phy: qcom-ufs: add support for 20nm phy
Reviewed-by: Dov Levenglick
> This change adds a support for a 20nm qcom-ufs phy that is required in
> platforms that use ufs-qcom controller.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/phy/Makefile| 1 +
> drivers/phy/phy-qcom-ufs-i.h| 43 +-
> drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257
>
> drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235
> +
> include/linux/phy/phy-qcom-ufs.h| 59 +
> 5 files changed, 594 insertions(+), 1 deletion(-)
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h
> create mode 100644 include/linux/phy/phy-qcom-ufs.h
>
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 335965d..781b2fa 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -35,3 +35,4 @@ obj-$(CONFIG_PHY_XGENE) +=
> phy-xgene.o
> obj-$(CONFIG_PHY_STIH407_USB)+= phy-stih407-usb.o
> obj-$(CONFIG_PHY_STIH41X_USB)+= phy-stih41x-usb.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
> diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
> index dac200f..591a391 100644
> --- a/drivers/phy/phy-qcom-ufs-i.h
> +++ b/drivers/phy/phy-qcom-ufs-i.h
> @@ -15,15 +15,56 @@
> #ifndef UFS_QCOM_PHY_I_H_
> #define UFS_QCOM_PHY_I_H_
>
> +#include
> #include
> +#include
> #include
> -#include
> +#include
> #include
> #include
> #include
>
> +#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> +({ \
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> + might_sleep_if(timeout_us); \
> + for (;;) { \
> + (val) = readl(addr); \
> + if (cond) \
> + break; \
> + if (timeout_us && ktime_compare(ktime_get(), timeout) > 0)
> { \
> + (val) = readl(addr); \
> + break; \
> + } \
> + if (sleep_us) \
> + usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us);
> \
> + } \
> + (cond) ? 0 : -ETIMEDOUT; \
> +})
> +
> +#define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
> + { \
> + .reg_offset = reg, \
> + .cfg_value = val, \
> + }
> +
> #define UFS_QCOM_PHY_NAME_LEN30
>
> +enum {
> + MASK_SERDES_START = 0x1,
> + MASK_PCS_READY = 0x1,
> +};
> +
> +enum {
> + OFFSET_SERDES_START = 0x0,
> +};
> +
> +struct ufs_qcom_phy_stored_attributes {
> + u32 att;
> + u32 value;
> +};
> +
> +
> struct ufs_qcom_phy_calibration {
> u32 reg_offset;
> u32 cfg_value;
> diff --git a/drivers/phy/phy-qcom-ufs-qmp-20nm.c
> b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
> new file mode 100644
> index 000..8332f96
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
> @@ -0,0 +1,257 @@
> +/*
> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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 "phy-qcom-ufs-qmp-20nm.h"
> +
> +#define UFS_PHY_NAME "ufs_phy_qmp_20nm"
> +
> +static
> +int ufs_qcom_phy_qmp_20nm_phy_calibrate(struct ufs_qcom_phy
> *ufs_qcom_phy,
> + bool is_rate_B)
> +{
> + struct ufs_qcom_phy_calibration *tbl_A, *tbl_B;
> + int tbl_size_A, tbl_size_B;
> + u8 major = ufs_qcom_phy->host_ctrl_rev_major;
> + u16 minor = ufs_qcom_phy->host_ctrl_rev_minor;
> + u16 step = ufs_qcom_phy->host_ctrl_rev_step;
> + int err;
> +
> + if ((major == 0x1) && (minor == 0x002) && (step == 0x)) {
> + tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A_1_2_0);
> + tbl_A = phy_cal_table_rate_A_1_2_0;
> + } else if ((major == 0x1) && (minor == 0x003) && (step == 0x))
> {
> + tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A_1_3_0);
> + tbl_A = phy_cal_table_rate_A_1_3_0;
> + } else {
> + dev_err(ufs_qcom_phy->dev, "%s: Unknown UFS-PHY version,
> no calibration values\n",
> + __func__);
> + err = -ENODEV;
> + goto out;
> + }
> +
> + tbl_size_B = ARRAY_SIZE(phy_cal_table_rate_B);
> + tbl_B = phy_cal_table_rate_B;
> +
> + err = ufs_qcom_phy_calibrate(ufs_qcom_phy, tbl_A, tbl_size_A,
> + tbl_B, tbl_size_B,
> is_rate_B);
> +
> +
Re: [PATCH v7 4/5] phy: qcom-ufs: add support for 14nm phy
Reviewed-by: Dov Levenglick
> This change adds a support for a 14nm qcom-ufs phy that is
> required in platforms that use ufs-qcom controller.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/phy/Makefile| 1 +
> drivers/phy/phy-qcom-ufs-qmp-14nm.c | 201
>
> drivers/phy/phy-qcom-ufs-qmp-14nm.h | 177 +++
> 3 files changed, 379 insertions(+)
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.c
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-14nm.h
>
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 781b2fa..cfbb720 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -36,3 +36,4 @@ obj-$(CONFIG_PHY_STIH407_USB) +=
> phy-stih407-usb.o
> obj-$(CONFIG_PHY_STIH41X_USB)+= phy-stih41x-usb.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
> diff --git a/drivers/phy/phy-qcom-ufs-qmp-14nm.c
> b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
> new file mode 100644
> index 000..f5fc50a
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
> @@ -0,0 +1,201 @@
> +/*
> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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 "phy-qcom-ufs-qmp-14nm.h"
> +
> +#define UFS_PHY_NAME "ufs_phy_qmp_14nm"
> +#define UFS_PHY_VDDA_PHY_UV (925000)
> +
> +static
> +int ufs_qcom_phy_qmp_14nm_phy_calibrate(struct ufs_qcom_phy
> *ufs_qcom_phy,
> + bool is_rate_B)
> +{
> + int tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A);
> + int tbl_size_B = ARRAY_SIZE(phy_cal_table_rate_B);
> + int err;
> +
> + err = ufs_qcom_phy_calibrate(ufs_qcom_phy, phy_cal_table_rate_A,
> + tbl_size_A, phy_cal_table_rate_B, tbl_size_B, is_rate_B);
> +
> + if (err)
> + dev_err(ufs_qcom_phy->dev,
> + "%s: ufs_qcom_phy_calibrate() failed %d\n",
> + __func__, err);
> + return err;
> +}
> +
> +static
> +void ufs_qcom_phy_qmp_14nm_advertise_quirks(struct ufs_qcom_phy
> *phy_common)
> +{
> + phy_common->quirks =
> + UFS_QCOM_PHY_QUIRK_HIBERN8_EXIT_AFTER_PHY_PWR_COLLAPSE;
> +}
> +
> +static int ufs_qcom_phy_qmp_14nm_init(struct phy *generic_phy)
> +{
> + struct ufs_qcom_phy_qmp_14nm *phy = phy_get_drvdata(generic_phy);
> + struct ufs_qcom_phy *phy_common = >common_cfg;
> + int err;
> +
> + err = ufs_qcom_phy_init_clks(generic_phy, phy_common);
> + if (err) {
> + dev_err(phy_common->dev, "%s: ufs_qcom_phy_init_clks()
> failed %d\n",
> + __func__, err);
> + goto out;
> + }
> +
> + err = ufs_qcom_phy_init_vregulators(generic_phy, phy_common);
> + if (err) {
> + dev_err(phy_common->dev, "%s:
> ufs_qcom_phy_init_vregulators() failed %d\n",
> + __func__, err);
> + goto out;
> + }
> + phy_common->vdda_phy.max_uV = UFS_PHY_VDDA_PHY_UV;
> + phy_common->vdda_phy.min_uV = UFS_PHY_VDDA_PHY_UV;
> +
> + ufs_qcom_phy_qmp_14nm_advertise_quirks(phy_common);
> +
> +out:
> + return err;
> +}
> +
> +static
> +void ufs_qcom_phy_qmp_14nm_power_control(struct ufs_qcom_phy *phy, bool
> val)
> +{
> + writel_relaxed(val ? 0x1 : 0x0, phy->mmio +
> UFS_PHY_POWER_DOWN_CONTROL);
> + /*
> + * Before any transactions involving PHY, ensure PHY knows
> + * that it's analog rail is powered ON (or OFF).
> + */
> + mb();
> +}
> +
> +static inline
> +void ufs_qcom_phy_qmp_14nm_set_tx_lane_enable(struct ufs_qcom_phy *phy,
> u32 val)
> +{
> + /*
> + * 14nm PHY does not have TX_LANE_ENABLE register.
> + * Implement this function so as not to propagate error to caller.
> + */
> +}
> +
> +static inline void ufs_qcom_phy_qmp_14nm_start_serdes(struct ufs_qcom_phy
> *phy)
> +{
> + u32 tmp;
> +
> + tmp = readl_relaxed(phy->mmio + UFS_PHY_PHY_START);
> + tmp &= ~MASK_SERDES_START;
> + tmp |= (1 << OFFSET_SERDES_START);
> + writel_relaxed(tmp, phy->mmio + UFS_PHY_PHY_START);
> + /* Ensure register value is committed */
> + mb();
> +}
> +
> +static int ufs_qcom_phy_qmp_14nm_is_pcs_ready(struct ufs_qcom_phy
> *phy_common)
> +{
> + int err = 0;
> + u32 val;
> +
> + err = readl_poll_timeout(phy_common->mmio +
> UFS_PHY_PCS_READY_STATUS,
> + val, (val &
Re: [PATCH v7 2/5] phy: qcom-ufs: add support for 20nm phy
Reviewed-by: Dov Levenglick
> This change adds a support for a 20nm qcom-ufs phy that is required in
> platforms that use ufs-qcom controller.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/phy/Makefile| 1 +
> drivers/phy/phy-qcom-ufs-i.h| 43 +-
> drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257
>
> drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235
> +
> include/linux/phy/phy-qcom-ufs.h| 59 +
> 5 files changed, 594 insertions(+), 1 deletion(-)
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h
> create mode 100644 include/linux/phy/phy-qcom-ufs.h
>
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 335965d..781b2fa 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -35,3 +35,4 @@ obj-$(CONFIG_PHY_XGENE) +=
> phy-xgene.o
> obj-$(CONFIG_PHY_STIH407_USB)+= phy-stih407-usb.o
> obj-$(CONFIG_PHY_STIH41X_USB)+= phy-stih41x-usb.o
> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
> diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
> index dac200f..591a391 100644
> --- a/drivers/phy/phy-qcom-ufs-i.h
> +++ b/drivers/phy/phy-qcom-ufs-i.h
> @@ -15,15 +15,56 @@
> #ifndef UFS_QCOM_PHY_I_H_
> #define UFS_QCOM_PHY_I_H_
>
> +#include
> #include
> +#include
> #include
> -#include
> +#include
> #include
> #include
> #include
>
> +#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> +({ \
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> + might_sleep_if(timeout_us); \
> + for (;;) { \
> + (val) = readl(addr); \
> + if (cond) \
> + break; \
> + if (timeout_us && ktime_compare(ktime_get(), timeout) > 0)
> { \
> + (val) = readl(addr); \
> + break; \
> + } \
> + if (sleep_us) \
> + usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us);
> \
> + } \
> + (cond) ? 0 : -ETIMEDOUT; \
> +})
> +
> +#define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
> + { \
> + .reg_offset = reg, \
> + .cfg_value = val, \
> + }
> +
> #define UFS_QCOM_PHY_NAME_LEN30
>
> +enum {
> + MASK_SERDES_START = 0x1,
> + MASK_PCS_READY = 0x1,
> +};
> +
> +enum {
> + OFFSET_SERDES_START = 0x0,
> +};
> +
> +struct ufs_qcom_phy_stored_attributes {
> + u32 att;
> + u32 value;
> +};
> +
> +
> struct ufs_qcom_phy_calibration {
> u32 reg_offset;
> u32 cfg_value;
> diff --git a/drivers/phy/phy-qcom-ufs-qmp-20nm.c
> b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
> new file mode 100644
> index 000..8332f96
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
> @@ -0,0 +1,257 @@
> +/*
> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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 "phy-qcom-ufs-qmp-20nm.h"
> +
> +#define UFS_PHY_NAME "ufs_phy_qmp_20nm"
> +
> +static
> +int ufs_qcom_phy_qmp_20nm_phy_calibrate(struct ufs_qcom_phy
> *ufs_qcom_phy,
> + bool is_rate_B)
> +{
> + struct ufs_qcom_phy_calibration *tbl_A, *tbl_B;
> + int tbl_size_A, tbl_size_B;
> + u8 major = ufs_qcom_phy->host_ctrl_rev_major;
> + u16 minor = ufs_qcom_phy->host_ctrl_rev_minor;
> + u16 step = ufs_qcom_phy->host_ctrl_rev_step;
> + int err;
> +
> + if ((major == 0x1) && (minor == 0x002) && (step == 0x)) {
> + tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A_1_2_0);
> + tbl_A = phy_cal_table_rate_A_1_2_0;
> + } else if ((major == 0x1) && (minor == 0x003) && (step == 0x))
> {
> + tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A_1_3_0);
> + tbl_A = phy_cal_table_rate_A_1_3_0;
> + } else {
> + dev_err(ufs_qcom_phy->dev, "%s: Unknown UFS-PHY version,
> no calibration values\n",
> + __func__);
> + err = -ENODEV;
> + goto out;
> + }
> +
> + tbl_size_B = ARRAY_SIZE(phy_cal_table_rate_B);
> + tbl_B = phy_cal_table_rate_B;
> +
> + err = ufs_qcom_phy_calibrate(ufs_qcom_phy, tbl_A, tbl_size_A,
> + tbl_B, tbl_size_B,
> is_rate_B);
> +
> +
Re: [PATCH] e100: Don't enable WoL by default on Toshiba devices
On Thursday 15 January 2015, Jeff Kirsher wrote: > On Thu, 2015-01-15 at 14:40 +0100, Ondrej Zary wrote: > > On Thursday 13 November 2014, Jeff Kirsher wrote: > > > On Wed, 2014-11-12 at 18:18 -0500, David Miller wrote: > > > > From: Ondrej Zary > > > > Date: Wed, 12 Nov 2014 23:47:25 +0100 > > > > > > > > > Enabling WoL on some Toshiba laptops (such as Portege R100) > > > > causes > > > > > > > battery drain after shutdown (WoL is active even on battery). > > > > These > > > > > > > laptops have the WoL bit set in EEPROM ID, causing e100 driver > > > > to > > > > > > > enable WoL by default. > > > > > > > > > > Check subsystem vendor ID and if it's Toshiba, don't enable WoL > > > > by > > > > > > > default from EEPROM settings. > > > > > > > > > > Fixes > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784 > > > > > > > Signed-off-by: Ondrej Zary > > > > > > > > Jeff, are you gonna pick this up? > > > > > > Yes, sorry I did not catch it earlier. > > > > What happened to this patch? I don't see it in net.git or > > net-next.git > > (checked both davem's and jkirsher's) > > Sorry, I thought I had replied with a NAK on this patch after further > review of the changes. > > We don't fix BIOS issues in the driver especially regarding feature > enablement like WoL. We would end up with dozens of these kinds of fixes > if we to allow this. > > You should go back to the OEM and ask for a BIOS update to resolve this or > configure udev so that ethtool disables WoL. This is not a BIOS bug. When the machine is powered off in BIOS (or GRUB), everything is OK. The bug is that e100 driver enables WoL based on some bit in EEPROM that happens to be set on at least some Toshiba laptops and user has no way to change it. Windows driver does not do this. Other Linux ethernet drivers don't do this. When user wants WoL, (s)he enables it in BIOS and OS. Maybe this (mis)feature should be removed from the driver. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fs: file freeze support
Namjae Jeon writes:
> We introduce per-file freeze feature for unifying defrag ext4 and xfs
> as first ingredient. We get the idea courtesy of Dave Chinner
> (https://lkml.org/lkml/2014/7/14/759)
> per-file freeze will be used to avoid that file is not modified while
> userspace is doing the defrag.
>
> This patch tries to implement file write freeze functionality.
> Introduce new inode state, I_WRITE_FREEZED.
> When this state is set, any process which tries to modify the file's address
> space, either by pagefault mmap writes or using write(2), will block until
> the this state is cleared. I_WRITE_FREEZED is set by calling FS_IOC_FWFREEZE
> ioctl and clear by FS_IOC_FWTHAW ioctl.
>
> File write freeze functionality, when used in conjunction with
> inode's immutable flag can be used for creating truly stable file snapshots
> wherein write freeze will prevent any modification to the file from already
> open file descriptors and immutable flag will prevent any new modification
> to the file. One of the intended uses for stable file snapshots would be in
> the defragmentation applications which defrags single file.
>
> For implementation purpose, initially we tried to keep percpu usage counters
> inside struct inode just like there is struct sb_writers in super_block.
> But considering that it will significantly bloat up struct inode when actually
> the usage of file write freeze will be infrequent, we dropped this idea.
> Instead we have tried to use already present filesystem freezing
> infrastructure.
> Current approach makes it possible for implementing file write freeze without
> bloating any of struct super_block/inode.
> In FS_IOC_FWFREEZE, we wait for complete fs to be frozen, set I_WRITE_FREEZED
> to
> inode's state and unfreeze the fs.
Looks interesting. I have added some comments below.
>
> TODO : prevent inode eviction when I_WRITE_FREEZED state is set.
> TODO : xfstests testcase for file freeze.
>
> Signed-off-by: Namjae Jeon
> Signed-off-by: Ashish Sangwan
> ---
> fs/btrfs/inode.c| 1 +
> fs/buffer.c | 1 +
> fs/ext4/inode.c | 1 +
> fs/f2fs/file.c | 1 +
> fs/gfs2/file.c | 1 +
> fs/inode.c | 19 ++
> fs/ioctl.c | 30 +
> fs/nilfs2/file.c| 1 +
> fs/ocfs2/mmap.c | 1 +
> fs/super.c | 51
> +
> include/linux/fs.h | 13 +
> include/uapi/linux/fs.h | 2 ++
> mm/filemap.c| 1 +
> 13 files changed, 123 insertions(+)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index e687bb0..357c749 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -8262,6 +8262,7 @@ int btrfs_page_mkwrite(struct vm_area_struct *vma,
> struct vm_fault *vmf)
> u64 page_start;
> u64 page_end;
>
> + inode_start_write(inode);
> sb_start_pagefault(inode->i_sb);
> ret = btrfs_delalloc_reserve_space(inode, PAGE_CACHE_SIZE);
> if (!ret) {
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 20805db..966d50b 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -2444,6 +2444,7 @@ int block_page_mkwrite(struct vm_area_struct *vma,
> struct vm_fault *vmf,
> int ret;
> struct super_block *sb = file_inode(vma->vm_file)->i_sb;
>
> + inode_start_write(file_inode(vma->vm_file));
> sb_start_pagefault(sb);
>
> /*
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 5653fa4..7e1e41e 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4981,6 +4981,7 @@ int ext4_page_mkwrite(struct vm_area_struct *vma,
> struct vm_fault *vmf)
> get_block_t *get_block;
> int retries = 0;
>
> + inode_start_write(inode);
> sb_start_pagefault(inode->i_sb);
> file_update_time(vma->vm_file);
> /* Delalloc case is easy... */
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index f172ddc4..9e23f8d 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -40,6 +40,7 @@ static int f2fs_vm_page_mkwrite(struct vm_area_struct *vma,
>
> f2fs_balance_fs(sbi);
>
> + inode_start_write(inode);
> sb_start_pagefault(inode->i_sb);
IMHO it is reasonable to fold sb_start_{write,pagefault}, to
inode_start_{write,pagefault}
>
> f2fs_bug_on(sbi, f2fs_has_inline_data(inode));
> diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
> index 6e600ab..bddf66b 100644
> --- a/fs/gfs2/file.c
> +++ b/fs/gfs2/file.c
> @@ -393,6 +393,7 @@ static int gfs2_page_mkwrite(struct vm_area_struct *vma,
> struct vm_fault *vmf)
> loff_t size;
> int ret;
>
> + inode_start_write(inode);
> sb_start_pagefault(inode->i_sb);
>
> /* Update file times before taking page lock */
> diff --git a/fs/inode.c b/fs/inode.c
> index aa149e7..82a96d0 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1929,3 +1929,22 @@ void inode_set_flags(struct inode *inode, unsigned int
> flags,
>
Re: [PATCH v7 3/5] scsi: ufs-qcom: add support for Qualcomm Technologies Inc platforms
Reviewed-by: Dov Levenglick
> This change adds support for Qualcomm Technologies Inc platforms that
> use UFS driver. for example, it adds :
> - PM specific operations during hibern8, suspend, resume, clock setup
> - qcom-ufs generic phy driver initialization, calibration,
> power-on/off sequence, etc.
> - UFS Controller specific configuration
> - Rate, Gear, Mode negotiation between device and controller
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/scsi/ufs/Kconfig| 13 +
> drivers/scsi/ufs/Makefile |1 +
> drivers/scsi/ufs/ufs-qcom.c | 1004
> +++
> drivers/scsi/ufs/ufs-qcom.h | 170
> 4 files changed, 1188 insertions(+)
> create mode 100644 drivers/scsi/ufs/ufs-qcom.c
> create mode 100644 drivers/scsi/ufs/ufs-qcom.h
>
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 6e07b2a..8a1f4b3 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -70,3 +70,16 @@ config SCSI_UFSHCD_PLATFORM
> If you have a controller with this interface, say Y or M here.
>
> If unsure, say N.
> +
> +config SCSI_UFS_QCOM
> + bool "QCOM specific hooks to UFS controller platform driver"
> + depends on SCSI_UFSHCD_PLATFORM && ARCH_MSM
> + select PHY_QCOM_UFS
> + help
> + This selects the QCOM specific additions to UFSHCD platform
> driver.
> + UFS host on QCOM needs some vendor specific configuration before
> + accessing the hardware which includes PHY configuration and
> vendor
> + specific registers.
> +
> + Select this if you have UFS controller on QCOM chipset.
> + If unsure, say N.
> diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
> index 1e5bd48..8303bcc 100644
> --- a/drivers/scsi/ufs/Makefile
> +++ b/drivers/scsi/ufs/Makefile
> @@ -1,4 +1,5 @@
> # UFSHCD makefile
> +obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
> obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
> obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
> obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> new file mode 100644
> index 000..9217af9
> --- /dev/null
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -0,0 +1,1004 @@
> +/*
> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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 "ufshcd.h"
> +#include "unipro.h"
> +#include "ufs-qcom.h"
> +#include "ufshci.h"
> +
> +static struct ufs_qcom_host *ufs_qcom_hosts[MAX_UFS_QCOM_HOSTS];
> +
> +static void ufs_qcom_get_speed_mode(struct ufs_pa_layer_attr *p, char
> *result);
> +static int ufs_qcom_get_bus_vote(struct ufs_qcom_host *host,
> + const char *speed_mode);
> +static int ufs_qcom_set_bus_vote(struct ufs_qcom_host *host, int vote);
> +
> +static int ufs_qcom_get_connected_tx_lanes(struct ufs_hba *hba, u32
> *tx_lanes)
> +{
> + int err = 0;
> +
> + err = ufshcd_dme_get(hba,
> + UIC_ARG_MIB(PA_CONNECTEDTXDATALANES), tx_lanes);
> + if (err)
> + dev_err(hba->dev, "%s: couldn't read
> PA_CONNECTEDTXDATALANES %d\n",
> + __func__, err);
> +
> + return err;
> +}
> +
> +static int ufs_qcom_host_clk_get(struct device *dev,
> + const char *name, struct clk **clk_out)
> +{
> + struct clk *clk;
> + int err = 0;
> +
> + clk = devm_clk_get(dev, name);
> + if (IS_ERR(clk)) {
> + err = PTR_ERR(clk);
> + dev_err(dev, "%s: failed to get %s err %d",
> + __func__, name, err);
> + } else {
> + *clk_out = clk;
> + }
> +
> + return err;
> +}
> +
> +static int ufs_qcom_host_clk_enable(struct device *dev,
> + const char *name, struct clk *clk)
> +{
> + int err = 0;
> +
> + err = clk_prepare_enable(clk);
> + if (err)
> + dev_err(dev, "%s: %s enable failed %d\n", __func__, name,
> err);
> +
> + return err;
> +}
> +
> +static void ufs_qcom_disable_lane_clks(struct ufs_qcom_host *host)
> +{
> + if (!host->is_lane_clks_enabled)
> + return;
> +
> + clk_disable_unprepare(host->tx_l1_sync_clk);
> + clk_disable_unprepare(host->tx_l0_sync_clk);
> + clk_disable_unprepare(host->rx_l1_sync_clk);
> + clk_disable_unprepare(host->rx_l0_sync_clk);
> +
> + host->is_lane_clks_enabled = false;
> +}
> +
> +static int
Re: [PATCH v7 5/5] scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS
Reviewed-by: Dov Levenglick
> From: Yaniv Gardi
>
> In-order to enhance storage encryption performance,
> an Inline Cryptographic Engine is introduced to UFS.
> This patch adds in-line encryption capabilities to the UFS
> driver.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/scsi/ufs/Kconfig| 12 +
> drivers/scsi/ufs/Makefile | 1 +
> drivers/scsi/ufs/ufs-qcom-ice.c | 520
>
> drivers/scsi/ufs/ufs-qcom-ice.h | 113 +
> drivers/scsi/ufs/ufs-qcom.c | 56 -
> drivers/scsi/ufs/ufs-qcom.h | 25 ++
> 6 files changed, 726 insertions(+), 1 deletion(-)
> create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
> create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.h
>
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 8a1f4b3..ecf34ed 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -83,3 +83,15 @@ config SCSI_UFS_QCOM
>
> Select this if you have UFS controller on QCOM chipset.
> If unsure, say N.
> +
> +config SCSI_UFS_QCOM_ICE
> + bool "QCOM specific hooks to Inline Crypto Engine for UFS driver"
> + depends on SCSI_UFS_QCOM && CRYPTO_DEV_QCOM_ICE
> + help
> + This selects the QCOM specific additions to support Inline
> Crypto
> + Engine (ICE).
> + ICE accelerates the crypto operations and maintains the high UFS
> + performance.
> +
> + Select this if you have ICE supported for UFS on QCOM chipset.
> + If unsure, say N.
> diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
> index 8303bcc..31adca5 100644
> --- a/drivers/scsi/ufs/Makefile
> +++ b/drivers/scsi/ufs/Makefile
> @@ -1,5 +1,6 @@
> # UFSHCD makefile
> obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
> +obj-$(CONFIG_SCSI_UFS_QCOM_ICE) += ufs-qcom-ice.o
> obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
> obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
> obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
> diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c
> b/drivers/scsi/ufs/ufs-qcom-ice.c
> new file mode 100644
> index 000..9202b73
> --- /dev/null
> +++ b/drivers/scsi/ufs/ufs-qcom-ice.c
> @@ -0,0 +1,520 @@
> +/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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 "ufs-qcom-ice.h"
> +#include "ufshcd.h"
> +
> +#define UFS_QCOM_CRYPTO_LABEL "ufs-qcom-crypto"
> +/* Timeout waiting for ICE initialization, that requires TZ access */
> +#define UFS_QCOM_ICE_COMPLETION_TIMEOUT_MS 500
> +
> +static void ufs_qcom_ice_success_cb(void *host_ctrl,
> + enum ice_event_completion evt)
> +{
> + struct ufs_qcom_host *qcom_host = (struct ufs_qcom_host
> *)host_ctrl;
> +
> + if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_DISABLED &&
> + evt == ICE_INIT_COMPLETION)
> + qcom_host->ice.state = UFS_QCOM_ICE_STATE_ACTIVE;
> + else if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_SUSPENDED &&
> +evt == ICE_RESUME_COMPLETION)
> + qcom_host->ice.state = UFS_QCOM_ICE_STATE_ACTIVE;
> +
> + complete(_host->ice.async_done);
> +}
> +
> +static void ufs_qcom_ice_error_cb(void *host_ctrl, enum ice_error_code
> evt)
> +{
> + struct ufs_qcom_host *qcom_host = (struct ufs_qcom_host
> *)host_ctrl;
> +
> + dev_err(qcom_host->hba->dev, "%s: Error in ice operation %d",
> + __func__, evt);
> +
> + if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_ACTIVE)
> + qcom_host->ice.state = UFS_QCOM_ICE_STATE_DISABLED;
> +
> + complete(_host->ice.async_done);
> +}
> +
> +static struct platform_device *ufs_qcom_ice_get_pdevice(struct device
> *ufs_dev)
> +{
> + struct device_node *node;
> + struct platform_device *ice_pdev = NULL;
> +
> + node = of_parse_phandle(ufs_dev->of_node, UFS_QCOM_CRYPTO_LABEL,
> 0);
> +
> + if (!node) {
> + dev_err(ufs_dev, "%s: ufs-qcom-crypto property not
> specified\n",
> + __func__);
> + goto out;
> + }
> +
> + ice_pdev = qcom_ice_get_pdevice(node);
> +out:
> + return ice_pdev;
> +}
> +
> +static
> +struct qcom_ice_variant_ops *ufs_qcom_ice_get_vops(struct device
> *ufs_dev)
> +{
> + struct qcom_ice_variant_ops *ice_vops = NULL;
> + struct device_node *node;
> +
> + node = of_parse_phandle(ufs_dev->of_node, UFS_QCOM_CRYPTO_LABEL,
> 0);
> +
> + if (!node) {
> + dev_err(ufs_dev, "%s:
[PATCH] cpumask: kill loop in cpumask_next_and()
cpumask_next_and() does cpumask_next() src1 in a loop and tests if found
cpu is alsop present in src2. remove that loop and perform cpumask_and()
of src1 and src2 first and use to find cpumask_next() intead.
Signed-off-by: Sergey Senozhatsky
---
lib/cpumask.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib/cpumask.c b/lib/cpumask.c
index b6513a9..5ab1553 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -37,10 +37,11 @@ EXPORT_SYMBOL(__next_cpu_nr);
int cpumask_next_and(int n, const struct cpumask *src1p,
const struct cpumask *src2p)
{
- while ((n = cpumask_next(n, src1p)) < nr_cpu_ids)
- if (cpumask_test_cpu(n, src2p))
- break;
- return n;
+ struct cpumask tmp;
+
+ if (cpumask_and(, src1p, src2p))
+ return cpumask_next(n, );
+ return nr_cpu_ids;
}
EXPORT_SYMBOL(cpumask_next_and);
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.19 v4 2/2] x86: Enforce maximum instruction size in the instruction decoder
On Jan 15, 2015 4:37 AM, "Masami Hiramatsu"
wrote:
>
> (2015/01/14 6:49), Andy Lutomirski wrote:
> > x86 instructions cannot exceed 15 bytes, and the instruction decoder
> > should enforce that. Prior to 6ba48ff46f76, the instruction length
> > limit was implicitly set to 16, which was an approximation of 15,
> > but there is currently no limit at all.
> >
> > Fix the decoder to reject instructions that exceed 15 bytes.
> > A subsequent patch (targetted for 3.20) will fix MAX_INSN_SIZE.
>
> Hmm, is there any problem to just change MAX_INSN_SIZE to 15?
I don't want to do that for 3.19. It's kind of late.
>
> > Other than potentially confusing some of the decoder sanity checks,
> > I'm not aware of any actual problems that omitting this check would
> > cause.
> >
> > Fixes: 6ba48ff46f76 x86: Remove arbitrary instruction size limit in
> > instruction decoder
> > Signed-off-by: Andy Lutomirski
> > ---
> > arch/x86/lib/insn.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
> > index 2480978b31cc..7b80745d2c5a 100644
> > --- a/arch/x86/lib/insn.c
> > +++ b/arch/x86/lib/insn.c
> > @@ -52,6 +52,13 @@
> > */
> > void insn_init(struct insn *insn, const void *kaddr, int buf_len, int
> > x86_64)
> > {
> > + /*
> > + * Instructions longer than 15 bytes are invalid even if the
> > + * input buffer is long enough to hold them.
> > + */
> > + if (buf_len > 15)
> > + buf_len = 15;
> > +
>
> Without changing the MAX_INSN_SIZE, this looks very odd, since all other
> code suppose that the max length of an instruction is 16 (MAX_INSN_SIZE)
> except here.
I thought this was your suggestion. Did I misunderstand?
If you think the current code is okay for 3.19, I can fold the two
patches together and send for 3.20.
--Andy
>
> Thank you,
>
> > memset(insn, 0, sizeof(*insn));
> > insn->kaddr = kaddr;
> > insn->end_kaddr = kaddr + buf_len;
> >
>
>
> --
> 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: [RFC 0/3] mmc: Add dynamic frequency scaling
On 12 January 2015 at 10:23, Krzysztof Kozlowski wrote: > Hi, > > > I would like to hear some comments about idea of scaling MMC clock > frequency. The basic idea is to lower the clock when device is > completely idle or not busy enough. > > The patchset adds MMC card as a devfreq device and uses simple_ondemand > as governor. In idle this gave benefits (less energy consumed during > idle): > 1. Trats2 (Exynos4412): 2.6% > 2. Rinato (Exynos3250): 1% > > but (especially on Rinato) it had impact on performance (probably > because ondemand triggering a little to late). What is interesting > manually changing the clock (without this patchset) gave slightly > bigger benefits. Maybe the devfreq introduces noticeable overhead? Could it be because of the polling interval being too long thus it being too slow to ramp up? That's a problem with all polling devfreq drivers, it has been proposed before using pm_qos to to reduce the polling interval when some event indicates that the utilization may grow abruptly in the near future. I don't think pm_qos is the best mechanism for that, maybe something new needs to be devised. Regards, Tomeu > > Comments are welcomed. Maybe on other platforms this has bigger impact? > > Best regards, > Krzysztof > > > Krzysztof Kozlowski (3): > mmc: Add dynamic frequency scaling > ARM: dts: Specify MSHC realistic clocks and use frequency scaling > ARM: dts: Use frequency scaling for MSHC > > Documentation/devicetree/bindings/mmc/mmc.txt | 2 + > arch/arm/boot/dts/exynos3250-rinato.dts | 1 + > arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- > drivers/mmc/card/block.c | 247 > ++ > drivers/mmc/core/Kconfig | 16 ++ > drivers/mmc/core/core.h | 1 - > drivers/mmc/core/host.c | 2 + > include/linux/mmc/card.h | 8 + > include/linux/mmc/host.h | 3 + > 9 files changed, 282 insertions(+), 2 deletions(-) > > -- > 1.9.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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] tracing: Fix enabling of syscall events on the command line
From: "Steven Rostedt (Red Hat)"
Commit 5f893b2639b2 "tracing: Move enabling tracepoints to just after
rcu_init()" broke the enabling of system call events from the command
line. The reason was that the enabling of command line trace events
was moved before PID 1 started, and the syscall tracepoints require
that all tasks have the TIF_SYSCALL_TRACEPOINT flag set. But the
swapper task (pid 0) is not part of that. Since the swapper task is the
only task that is running at this early in boot, no task gets the
flag set, and the tracepoint never gets reached.
Instead of setting the swapper task flag (there should be no reason to
do that), re-enabled trace events again after the init thread (PID 1)
has been started. It requires disabling all command line events and
re-enabling them, as just enabling them again will not reset the logic
to set the TIF_SYSCALL_TRACEPOINT flag, as the syscall tracepoint will
be fooled into thinking that it was already set, and wont try setting
it again. For this reason, we must first disable it and re-enable it.
Link:
http://lkml.kernel.org/r/1421188517-18312-1-git-send-email-...@ellerman.id.au
Link: http://lkml.kernel.org/r/20150115040506.216066...@goodmis.org
Reported-by: Michael Ellerman
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c | 69 -
1 file changed, 55 insertions(+), 14 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 366a78a3e61e..b03a0ea77b99 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2429,12 +2429,39 @@ static __init int event_trace_memsetup(void)
return 0;
}
+static __init void
+early_enable_events(struct trace_array *tr, bool disable_first)
+{
+ char *buf = bootup_event_buf;
+ char *token;
+ int ret;
+
+ while (true) {
+ token = strsep(, ",");
+
+ if (!token)
+ break;
+ if (!*token)
+ continue;
+
+ /* Restarting syscalls requires that we stop them first */
+ if (disable_first)
+ ftrace_set_clr_event(tr, token, 0);
+
+ ret = ftrace_set_clr_event(tr, token, 1);
+ if (ret)
+ pr_warn("Failed to enable trace event: %s\n", token);
+
+ /* Put back the comma to allow this to be called again */
+ if (buf)
+ *(buf - 1) = ',';
+ }
+}
+
static __init int event_trace_enable(void)
{
struct trace_array *tr = top_trace_array();
struct ftrace_event_call **iter, *call;
- char *buf = bootup_event_buf;
- char *token;
int ret;
if (!tr)
@@ -2456,18 +2483,7 @@ static __init int event_trace_enable(void)
*/
__trace_early_add_events(tr);
- while (true) {
- token = strsep(, ",");
-
- if (!token)
- break;
- if (!*token)
- continue;
-
- ret = ftrace_set_clr_event(tr, token, 1);
- if (ret)
- pr_warn("Failed to enable trace event: %s\n", token);
- }
+ early_enable_events(tr, false);
trace_printk_start_comm();
@@ -2478,6 +2494,31 @@ static __init int event_trace_enable(void)
return 0;
}
+/*
+ * event_trace_enable() is called from trace_event_init() first to
+ * initialize events and perhaps start any events that are on the
+ * command line. Unfortunately, there are some events that will not
+ * start this early, like the system call tracepoints that need
+ * to set the TIF_SYSCALL_TRACEPOINT flag of pid 1. But event_trace_enable()
+ * is called before pid 1 starts, and this flag is never set, making
+ * the syscall tracepoint never get reached, but the event is enabled
+ * regardless (and not doing anything).
+ */
+static __init int event_trace_enable_again(void)
+{
+ struct trace_array *tr;
+
+ tr = top_trace_array();
+ if (!tr)
+ return -ENODEV;
+
+ early_enable_events(tr, true);
+
+ return 0;
+}
+
+early_initcall(event_trace_enable_again);
+
static __init int event_trace_init(void)
{
struct trace_array *tr;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] [GIT PULL] ftrace: jprobe, syscall and other fixes
Linus, This holds a few fixes to the ftrace infrastructure as well as the mixture of function graph tracing and kprobes. When jprobes and function graph tracing is enabled at the same time it will crash the system. # modprobe jprobe_example # echo function_graph > /sys/kernel/debug/tracing/current_tracer After the first fork (jprobe_example probes it), the system will crash. This is due to the way jprobes copies the stack frame and does not do a normal function return. This messes up with the function graph tracing accounting which hijacks the return address from the stack and replaces it with a hook function. It saves the return addresses in a separate stack to put back the correct return address when done. But because the jprobe functions do not do a normal return, their stack addresses are not put back until the function they probe is called, which means that the probed function will get the return address of the jprobe handler instead of its own. The simple fix here was to disable function graph tracing while the jprobe handler is being called. While debugging this I found two minor bugs with the function graph tracing. The first was about the function graph tracer sharing its function hash with the function tracer (they both get filtered by the same input). The changing of the set_ftrace_filter would not sync the function recording records after a change if the function tracer was disabled but the function graph tracer was enabled. This was due to the update only checking one of the ops instead of the shared ops to see if they were enabled and should perform the sync. This caused the ftrace accounting to break and a ftrace_bug() would be triggered, disabling ftrace until a reboot. The second was that the check to update records only checked one of the filter hashes. It needs to test both the "filter" and "notrace" hashes. The "filter" hash determines what functions to trace where as the "notrace" hash determines what functions not to trace (trace all but these). Both hashes need to be passed to the update code to find out what change is being done during the update. This also broke the ftrace record accounting and triggered a ftrace_bug(). This patch set also include two more fixes that were reported separately from the kprobe issue. One was that init_ftrace_syscalls() was called twice at boot up. This is not a major bug, but that call performed a rather large kmalloc (NR_syscalls * sizeof(*syscalls_metadata)). The second call made the first one a memory leak, and wastes memory. The other fix is a regression caused by an update in the v3.19 merge window. The moving to enable events early, moved the enabling before PID 1 was created. The syscall events require setting the TIF_SYSCALL_TRACEPOINT for all tasks. But for_each_process_thread() does not include the swapper task (PID 0), and ended up being a nop. A suggested fix was to add the init_task() to have its flag set, but I didn't really want to mess with PID 0 for this minor bug. Instead I disable and re-enable events again at early_initcall() where it use to be enabled. This also handles any other event that might have its own reg function that could break at early boot up. Please pull the latest trace-fixes-v3.19-rc3 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-fixes-v3.19-rc3 Tag SHA1: 73a577e76939fb74bc8de1e2a816b3d8a0fe850d Head SHA1: ce1039bd3a89e99e4f624e75fb1777fc92d76eb3 Steven Rostedt (Red Hat) (5): ftrace: Fix updating of filters for shared global_ops filters ftrace: Check both notrace and filter for old hash ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing tracing: Remove extra call to init_ftrace_syscalls() tracing: Fix enabling of syscall events on the command line arch/x86/kernel/kprobes/core.c | 20 +--- kernel/trace/ftrace.c | 53 +++- kernel/trace/trace.c | 1 - kernel/trace/trace_events.c| 69 +- 4 files changed, 115 insertions(+), 28 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/
