Re: [PATCH] misc: add CS2000 Fractional-N driver
On Thursday 10 September 2015 06:36:14 Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This patch adds CS2000 Fractional-N driver as clock provider. > It is useful if it supports runtime clock setting, but it supports > fixed clock rate at this point. > > Signed-off-by: Kuninori Morimoto > --- > .../devicetree/bindings/misc/cs2000-cp.txt | 20 ++ > drivers/misc/Kconfig | 6 + > drivers/misc/Makefile | 1 + > drivers/misc/cs2000-cp.c | 341 > + > 4 files changed, 368 insertions(+) > create mode 100644 Documentation/devicetree/bindings/misc/cs2000-cp.txt > create mode 100644 drivers/misc/cs2000-cp.c I think the driver should be in drivers/clk/ if it provides a clk to other devices. Please also split out the binding document into a separate patch and Cc the devicetree mailing list. > + > + ret = cs2000_get_clk(client, &rate_in, &rate_out); > + if (ret < 0) > + return ret; > + > + ret = cs2000_enable_dev_config(client); > + if (ret < 0) > + return ret; > + > + ret = cs2000_clk_in_bound_rate(client, rate_in); > + if (ret < 0) > + return ret; > + > + ret = cs2000_ratio_set(client, ch, rate_in, rate_out); > + if (ret < 0) > + return ret; The probe function lacks unwinding if anything goes wrong, so you end up with clocks that are registered but the driver being absent. For most things, you can use the devm_*() interfaces here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 07/13] usb: otg: add OTG core
On Wed, Sep 09, 2015 at 01:21:50PM +0300, Roger Quadros wrote:
> On 09/09/15 11:45, Peter Chen wrote:
> > On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
> >> On 09/09/15 11:13, Peter Chen wrote:
> >>> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
> On 09/09/15 05:21, Peter Chen wrote:
> > On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> >>
> >>
> >> On 08/09/15 11:31, Peter Chen wrote:
> >>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> On 07/09/15 04:23, Peter Chen wrote:
> > On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> >> + * This is used by the USB Host stack to register the Host
> >> controller
> >> + * to the OTG core. Host controller must not be started by the
> >> + * caller as it is left upto the OTG state machine to do so.
> >> + *
> >> + * Returns: 0 on success, error value otherwise.
> >> + */
> >> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
> >> + unsigned long irqflags, struct otg_hcd_ops
> >> *ops)
> >> +{
> >> + struct usb_otg *otgd;
> >> + struct device *hcd_dev = hcd->self.controller;
> >> + struct device *otg_dev = usb_otg_get_device(hcd_dev);
> >> +
> >
> > One big problem here is: there are two designs for current (IP)
> > driver
> > code, one creates dedicated hcd device as roothub's parent, like
> > dwc3.
> > Another one doesn't do this, roothub's parent is core device (or
> > otg device
> > in your patch), like chipidea and dwc2.
> >
> > Then, otg_dev will be glue layer device for chipidea after that.
>
> OK. Let's add a way for the otg controller driver to provide the
> host and gadget
> information to the otg core for such devices like chipidea and dwc2.
>
> >>>
> >>> Roger, not only chipidea and dwc2, I think the musb uses the same
> >>> hierarchy. If the host, device, and otg share the same register
> >>> region, host part can't be a platform driver since we don't want
> >>> to remap the same register region again.
> >>>
> >>> So, in the design, we may need to consider both situations, one
> >>> is otg/host/device has its own register region, and host is a
> >>> separate platform device (A), the other is three parts share the
> >>> same register region, there is only one platform driver (B).
> >>>
> >>> A:
> >>>
> >>> IP core device
> >>> |
> >>> |
> >>> |-|-|
> >>> gadget host platform device
> >>> |
> >>> roothub
> >>>
> >>> B:
> >>>
> >>> IP core device
> >>> |
> >>> |
> >>> |-|-|
> >>> gadget roothub
> >>>
> >>>
> This API must be called before the hcd/gadget-driver is added so
> that the otg
> core knows it's linked to an OTG controller.
>
> Any better idea?
>
> >>>
> >>> A flag stands for this hcd controller is the same with otg controller
> >>> can be used, this flag can be stored at struct usb_otg_config.
> >>
> >> What if there is another architecture like so?
> >>
> >> C:
> >>[Parent]
> >> |
> >> |
> >>|--|--|
> >>[OTG core] [gadget][host]
> >>
> >> We need a more flexible mechanism to link the gadget and
> >> host device to the otg core for non DT case.
> >>
> >> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> >>
> >> e.g.
> >> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> >>
> >> If otg is NULL it will try DT otg-controller property or parent to
> >> get the otg controller.
> >
> > How usb_otg_register_hcd get struct usb_otg, from where?
>
> This only works when the parent driver creating the hcd has registered
> the
> otg controller too.
>
> >>>
> >>> Sorry? So we need to find another way to solve this issue, right?
> >>
> >> For existing cases this is sufficient.
> >> The otg device is either the one supplied during usb_otg_register_hcd
> >> (cases B and C) or it is the parent device (case A).
> >
> > How we differentiate case A and case B at usb_otg_register_hcd?
> > Would you show me the sample code?
>
> Case A:
>
Re: incoming
On Thu, Sep 10 2015, Linus Torvalds wrote:
> The VERY FIRST conversion patch I looked at was buggy. That makes me
> angry. The whole *AND*ONLY* point of this whole thing was to get rid
> of bugs, and be a obviously safe interface, and then the first
> conversion patch proves it wrong.
>
> Let me show you:
>
> if (isdigit(*str)) {
> - io_tlb_nslabs = simple_strtoul(str, &str, 0);
> + str += parse_integer(str, 0, &io_tlb_nslabs);
>
> and obviously nobody spent even a *second* asking themselves "what if
> parse_integer returns an error".
[This is going to sound awfully self-glorifying. Oh well.] I did point
that out in another instance (memparse), which I think then got somewhat
fixed in a later version. Since Alexey and I seemed to disagree on what
guiding principles to use when doing the conversions and a number of
other points, I didn't have the energy to go through the entire series,
and the discussion died out.
http://thread.gmane.org/gmane.linux.kernel/1942623/focus=1944193
> I liked the automatic type-based templating it does, but I *don't*
> like the breakage that seems to be inevitable in any large-scale
> conversion from a previously used historical interface.
My words exactly.
Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 1/5] perf probe: Split add_perf_probe_events()
Hi Masami,
On Thu, Sep 10, 2015 at 05:00:07AM +, 平松雅巳 / HIRAMATU，MASAMI wrote:
> >From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim
> >The del_perf_probe_events() uses strfilter, but I think it can be
> >problematic if other instances or users are using similar events at
> >the same time.
>
> Yeah, since perf probe doesn't lock the ftrace, there should be a
> timing bug, but it can be fixed easily by ignoring -ENOENT. :)
By ignoring -ENOENT? Are you saying that there's a race between two
deleters? Yes, of course, but I think that the bug will hit an adder
and a deleter especially if automatic probing is used (by eBPF and/or
SDT recording).
What about this?
>From 45dba35cb0f5fa1b2e78fec8c05faf5e9a1b200e Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Thu, 10 Sep 2015 15:25:28 +0900
Subject: [PATCH] perf probe: Support deleting trace events directly
Currently del_perf_probe_events() deletes events which match to a given
filter. But it might have a timing bug when other users also set probes
with similar names. So it'd be better deleting our events directly
rather than pattern matching.
Since the del_perf_probe_events() has no user at this time, change it to
receive perf_probe_event's. It is more consistent to other APIs as well.
Cc: Masami Hiramatsu
Cc: Wang Nan
Signed-off-by: Namhyung Kim
---
tools/perf/util/probe-event.c | 30 +++---
tools/perf/util/probe-event.h | 2 +-
tools/perf/util/probe-file.c | 24
tools/perf/util/probe-file.h | 1 +
4 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 2b78e8f19b45..88d7ef87ab99 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2810,37 +2810,29 @@ int add_perf_probe_events(struct perf_probe_event
*pevs, int npevs)
return ret;
}
-int del_perf_probe_events(struct strfilter *filter)
+int del_perf_probe_events(struct perf_probe_event *pevs, int npevs)
{
- int ret, ret2, ufd = -1, kfd = -1;
- char *str = strfilter__string(filter);
+ int i, j, ret, ret2;
+ int ufd = -1, kfd = -1;
- if (!str)
- return -EINVAL;
-
- /* Get current event names */
ret = probe_file__open_both(&kfd, &ufd, PF_FL_RW);
if (ret < 0)
- goto out;
+ return ret;
- ret = probe_file__del_events(kfd, filter);
- if (ret < 0 && ret != -ENOENT)
- goto error;
+ for (i = 0; i < npevs; i++) {
+ int fd = pevs[i].uprobes ? ufd : kfd;
- ret2 = probe_file__del_events(ufd, filter);
- if (ret2 < 0 && ret2 != -ENOENT) {
- ret = ret2;
- goto error;
+ for (j = 0; j < pevs[i].ntevs; j++) {
+ ret2 = probe_file__del_trace_event(fd,
&pevs[i].tevs[j]);
+ if (ret == 0)
+ ret = ret2;
+ }
}
- ret = 0;
-error:
if (kfd >= 0)
close(kfd);
if (ufd >= 0)
close(ufd);
-out:
- free(str);
return ret;
}
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index ba926c30f8cd..cb58b981cc92 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -145,7 +145,7 @@ extern int add_perf_probe_events(struct perf_probe_event
*pevs, int npevs);
extern int convert_perf_probe_events(struct perf_probe_event *pevs, int npevs);
extern int apply_perf_probe_events(struct perf_probe_event *pevs, int npevs);
extern void cleanup_perf_probe_events(struct perf_probe_event *pevs, int
npevs);
-extern int del_perf_probe_events(struct strfilter *filter);
+extern int del_perf_probe_events(struct perf_probe_event *pevs, int npevs);
extern int show_perf_probe_event(const char *group, const char *event,
struct perf_probe_event *pev,
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 89dbeb92c68e..334b7b75b55b 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -319,3 +319,27 @@ int probe_file__del_events(int fd, struct strfilter
*filter)
return ret;
}
+
+int probe_file__del_trace_event(int fd, struct probe_trace_event *tev)
+{
+ char buf[128];
+ int ret;
+
+ /* Convert from perf-probe event to trace-probe event */
+ ret = e_snprintf(buf, 128, "-:%s/%s", tev->group, tev->event);
+ if (ret < 0)
+ goto error;
+
+ pr_debug("Writing event: %s\n", buf);
+ ret = write(fd, buf, strlen(buf));
+ if (ret < 0) {
+ ret = -errno;
+ goto error;
+ }
+
+ return 0;
+error:
+ pr_warning("Failed to delete event: %s\n",
+ strerror_r(-ret, buf, sizeof(buf)));
+ return ret;
+}
diff --git a/tools/perf/util/probe-file.h b/too
[PATCH v2] powerpc32: memcpy/memset: only use dcbz once cache is enabled
memcpy() and memset() uses instruction dcbz to speed up copy by not
wasting time loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
can therefore not use memcpy(). Allthough no part of the code
explicitly uses memcpy(), GCC makes calls to it.
This patch implements fixups linked to the cache.
At startup, the functions implement code that does not use dcbz:
* For memcpy(), dcbz is replaced by dcbtst which is harmless when
cache is not enabled, and which helps a bit (allthough not as much
as dcbz) if cache is already enabled.
* For memset(), it branches inconditionnally to the alternative part
normally used only when setting non-zero value. That part doesn't
use dcbz
Once the initial MMU is set up, in machine_init() we call
do_feature_fixups() which replaces the temporary instructions with
the final ones.
Reported-by: Michal Sojka
Signed-off-by: Christophe Leroy
---
changes in v2:
Using feature-fixups instead of hardcoded call to patch_instruction()
Handling of memset() added
arch/powerpc/include/asm/cache.h | 8
arch/powerpc/include/asm/feature-fixups.h | 30 ++
arch/powerpc/kernel/setup_32.c| 3 +++
arch/powerpc/kernel/vmlinux.lds.S | 8
arch/powerpc/lib/copy_32.S| 16
5 files changed, 65 insertions(+)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index a2de4f0..4d51010 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -48,6 +48,10 @@ static inline void logmpp(u64 x)
#endif /* __powerpc64__ && ! __ASSEMBLY__ */
+#ifdef CONFIG_PPC32
+#define CACHE_NOW_ON 1
+#endif
+
#if defined(__ASSEMBLY__)
/*
* For a snooping icache, we still need a dummy icbi to purge all the
@@ -64,6 +68,10 @@ static inline void logmpp(u64 x)
#else
#define __read_mostly __attribute__((__section__(".data..read_mostly")))
+#ifdef CONFIG_PPC32
+extern unsigned int __start___cache_fixup, __stop___cache_fixup;
+#endif
+
#ifdef CONFIG_6xx
extern long _get_L2CR(void);
extern long _get_L3CR(void);
diff --git a/arch/powerpc/include/asm/feature-fixups.h
b/arch/powerpc/include/asm/feature-fixups.h
index 9a67a38..7f351cd 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -184,4 +184,34 @@ label##3: \
FTR_ENTRY_OFFSET label##1b-label##3b; \
.popsection;
+/* Cache related sections */
+#define BEGIN_CACHE_SECTION_NESTED(label) START_FTR_SECTION(label)
+#define BEGIN_CACHE_SECTIONSTART_FTR_SECTION(97)
+
+#define END_CACHE_SECTION_NESTED(msk, val, label) \
+ FTR_SECTION_ELSE_NESTED(label) \
+ MAKE_FTR_SECTION_ENTRY(msk, val, label, __cache_fixup)
+
+#define END_CACHE_SECTION(msk, val)\
+ END_CACHE_SECTION_NESTED(msk, val, 97)
+
+#define END_CACHE_SECTION_IFSET(msk) END_CACHE_SECTION((msk), (msk))
+#define END_CACHE_SECTION_IFCLR(msk) END_CACHE_SECTION((msk), 0)
+
+/* CACHE feature sections with alternatives, use BEGIN_FTR_SECTION to start */
+#define CACHE_SECTION_ELSE_NESTED(label) FTR_SECTION_ELSE_NESTED(label)
+#define CACHE_SECTION_ELSE CACHE_SECTION_ELSE_NESTED(97)
+#define ALT_CACHE_SECTION_END_NESTED(msk, val, label) \
+ MAKE_FTR_SECTION_ENTRY(msk, val, label, __cache_fixup)
+#define ALT_CACHE_SECTION_END_NESTED_IFSET(msk, label) \
+ ALT_CACHE_SECTION_END_NESTED(msk, msk, label)
+#define ALT_CACHE_SECTION_END_NESTED_IFCLR(msk, label) \
+ ALT_CACHE_SECTION_END_NESTED(msk, 0, label)
+#define ALT_CACHE_SECTION_END(msk, val)\
+ ALT_CACHE_SECTION_END_NESTED(msk, val, 97)
+#define ALT_CACHE_SECTION_END_IFSET(msk) \
+ ALT_CACHE_SECTION_END_NESTED_IFSET(msk, 97)
+#define ALT_CACHE_SECTION_END_IFCLR(msk) \
+ ALT_CACHE_SECTION_END_NESTED_IFCLR(msk, 97)
+
#endif /* __ASM_POWERPC_FEATURE_FIXUPS_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 07831ed..41d39da 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -122,6 +122,9 @@ notrace void __init machine_init(u64 dt_ptr)
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
+ do_feature_fixups(CACHE_NOW_ON, &__start___cache_fixup,
+ &__stop___cache_fixup);
+
/* Do some early initialization based on the flat device tree */
early_init_devtree(__va(dt_ptr));
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 1db6851..3c7dcab 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -148,6 +148,14 @@ SECTIONS
__stop___fw_ftr_fixup = .;
}
#endif
+#ifdef CONFIG_PPC32
+ . = ALIGN(8);
+ __c
Re: [PATCH/RFC] mm: do not regard CMA pages as free on watermark check
[CC Joonsoo, Mel]
On 09/09/2015 08:31 PM, Vitaly Wool wrote:
> Hi Laura,
>
> On Wed, Sep 9, 2015 at 7:56 PM, Laura Abbott wrote:
>
>> (cc-ing linux-mm)
>> On 09/09/2015 07:44 AM, Vitaly Wool wrote:
>>
>>> __zone_watermark_ok() does not corrrectly take high-order
>>> CMA pageblocks into account: high-order CMA blocks are not
>>> removed from the watermark check. Moreover, CMA pageblocks
>>> may suddenly vanish through CMA allocation, so let's not
>>> regard these pages as free in __zone_watermark_ok().
>>>
>>> This patch also adds some primitive testing for the method
>>> implemented which has proven that it works as it should.
>>>
>>>
>> The choice to include CMA as part of watermarks was pretty deliberate.
>> Do you have a description of the problem you are facing with
>> the watermark code as is? Any performance numbers?
>>
>>
> let's start with facing the fact that the calculation in
> __zone_watermark_ok() is done incorrectly for the case when ALLOC_CMA is
> not set. While going through pages by order it is implicitly considered
You're not the first who tried to fix it, I think Joonsoo tried as well?
I think the main objection was against further polluting fastpaths due to CMA.
Note that Mel has a patchset removing high-order watermark checks (in the last
patch of https://lwn.net/Articles/655406/ ) so this will be moot afterwards.
> that CMA pages can be used and this impacts the result of the function.
>
> This can be solved in a slightly different way compared to what I proposed
> but it needs per-order CMA pages accounting anyway. Then it would have
> looked like:
>
> for (o = 0; o < order; o++) {
> /* At the next order, this order's pages become unavailable
> */
> free_pages -= z->free_area[o].nr_free << o;
> #ifdef CONFIG_CMA
> if (!(alloc_flags & ALLOC_CMA))
> free_pages -= z->free_area[o].nr_free_cma << o;
> /* Require fewer higher order pages to be free */
> min >>= 1;
> ...
>
> But what we have also seen is that CMA pages may suddenly disappear due to
> CMA allocator work so the whole watermark checking was still unreliable,
> causing compaction to not run when it ought to and thus leading to
Well, watermark checking is inherently racy. CMA pages disappearing is no
exception, non-CMA pages may disappear as well.
> (otherwise redundant) low memory killer operations, so I decided to propose
> a safer method instead.
>
> Best regards,
>Vitaly
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/17] thermal: tegra: allow compile test
On Thu, Sep 10, 2015 at 6:11 AM, Eduardo Valentin wrote:
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -242,7 +242,7 @@ config ARMADA_THERMAL
>
> config TEGRA_SOCTHERM
> tristate "Tegra SOCTHERM thermal management"
> - depends on ARCH_TEGRA
> + depends on ARCH_TEGRA || COMPILE_TEST
ERROR: "tegra_fuse_readl" [drivers/thermal/tegra_soctherm.ko] undefined!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL REQUEST] watchdog - v4.3-rc1 merge window
Hi Wim, On Thu, 10 Sep 2015 08:20:07 +0200 Wim Van Sebroeck wrote: > > > > Please pull from 'master' branch of > > > git://www.linux-watchdog.org/linux-watchdog.git > > > > I have not been able to fetch from that tree for the past couple of > > days. It connects and then hangs for some time and then I get: > > > > fatal: read error: Connection reset by peer > > > > Sorry for not mentioning it earlier. > > The tree hasn't changed since 1.5 weeks, so on content level nothing has > changed. OK, I managed to refetch your tree (it was still very slow - you might want to consider moving it to git.kernel.org). The patches appear identical to what I last fetched (and what has been in linux-next since Aug 31), but it has all been recommitted in the last day. The end result and the base are exactly the same, so it should not be a problem, I guess. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] misc: add CS2000 Fractional-N driver
From: Kuninori Morimoto
This patch adds CS2000 Fractional-N driver as clock provider.
It is useful if it supports runtime clock setting, but it supports
fixed clock rate at this point.
Signed-off-by: Kuninori Morimoto
---
.../devicetree/bindings/misc/cs2000-cp.txt | 20 ++
drivers/misc/Kconfig | 6 +
drivers/misc/Makefile | 1 +
drivers/misc/cs2000-cp.c | 341 +
4 files changed, 368 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/cs2000-cp.txt
create mode 100644 drivers/misc/cs2000-cp.c
diff --git a/Documentation/devicetree/bindings/misc/cs2000-cp.txt
b/Documentation/devicetree/bindings/misc/cs2000-cp.txt
new file mode 100644
index 000..e79cf10
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/cs2000-cp.txt
@@ -0,0 +1,20 @@
+CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+
+Required properties:
+
+- compatible: "cirrus,cs2000-cp"
+- reg: The chip select number on the I2C bus
+- clocks: common clock binding for CLK_IN, XTI/REF_CLK
+- clock-frequency: clock frequency of CLK_OUT
+
+Example:
+
+&i2c2 {
+ ...
+ cs2000: clk_multiplier@0x4f {
+ compatible = "cirrus,cs2000-cp";
+ reg = <0x4f>;
+ clocks = <&rcar_sound 0>, <&x12_clk>;
+ clock-frequency = <24576000>; /* 1/1 divide */
+ };
+};
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c29..deec03e 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -224,6 +224,12 @@ config SGI_XP
this feature will allow for direct communication between SSIs
based on a network adapter and DMA messaging.
+config CS2000_CP
+ tristate "CS2000 Fractional-N Clock Synthesizer & Clock Multiplier"
+ depends on I2C
+ help
+ If you say yes here you get support for the CS2000 clock multiplier
+
config CS5535_MFGPT
tristate "CS5535/CS5536 Geode Multi-Function General Purpose Timer
(MFGPT) support"
depends on MFD_CS5535
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 537d7f3b..36491e6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o
obj-$(CONFIG_KGDB_TESTS) += kgdbts.o
obj-$(CONFIG_SGI_XP) += sgi-xp/
obj-$(CONFIG_SGI_GRU) += sgi-gru/
+obj-$(CONFIG_CS2000_CP)+= cs2000-cp.o
obj-$(CONFIG_CS5535_MFGPT) += cs5535-mfgpt.o
obj-$(CONFIG_HP_ILO) += hpilo.o
obj-$(CONFIG_APDS9802ALS) += apds9802als.o
diff --git a/drivers/misc/cs2000-cp.c b/drivers/misc/cs2000-cp.c
new file mode 100644
index 000..be639e3
--- /dev/null
+++ b/drivers/misc/cs2000-cp.c
@@ -0,0 +1,341 @@
+/*
+ * CS2000 -- CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ * Kuninori Morimoto
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CLK_MAIN 0 /* CLK_IN on datasheet */
+#define CLK_IN 1 /* REF_CLK on datasheet */
+
+#define CH_MAX 4
+
+#define DEVICE_ID 0x1
+#define DEVICE_CTRL0x2
+#define DEVICE_CFG10x3
+#define DEVICE_CFG20x4
+#define GLOBAL_CFG 0x5
+#define Ratio_Add(x, nth) (6 + (x * 4) + (nth))
+#define Ratio_Val(x, nth) ((x >> (24 - (8 * nth))) & 0xFF)
+#define FUNC_CFG1 0x16
+#define FUNC_CFG2 0x17
+
+/* DEVICE_CTRL */
+#define PLL_UNLOCK (1 << 7)
+
+/* DEVICE_CFG1 */
+#define RSEL(x)(((x) & 0x3) << 3)
+#define RSEL_MASK RSEL(0x3)
+#define ENDEV1 (0x1)
+
+/* GLOBAL_CFG */
+#define ENDEV2 (0x1)
+
+
+#define CH_ERR(ch) ((ch < 0) || (ch >= CH_MAX))
+
+struct cs2000_priv {
+ struct clk *clk_main;
+ struct clk *clk_in;
+ struct clk *clk_out;
+};
+
+static const struct of_device_id cs2000_of_match[] = {
+ { .compatible = "cirrus,cs2000-cp", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cs2000_of_match);
+
+static const struct i2c_device_id cs2000_id[] = {
+ { "cs2000-cp", },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, cs2000_id);
+
+#define cs2000_read(c, addr) i2c_smbus_read_byte_data(c, addr)
+static void cs2000_write(struct i2c_client *client, u8 addr, u8 val)
+{
+ struct device *dev = &client->dev;
+
+ dev_dbg(dev, "0x%02x : 0x%02x\n", addr, val);
+
+ i2c_smbus_write_byte_data(client, addr, val);
+}
+
+static void cs2000_bset(struct i2c_client *client, u8 addr, u8 mask, u8 val)
+{
+ u32 data;
+
+ data = cs2000_read(client, addr);
+
+ data &= ~mask;
+ data |= (val & mask);
+
+ cs2000_write(client,
Re: [PATCH 06/17] thermal: u8500: allow compile test
On Thu, Sep 10, 2015 at 6:11 AM, Eduardo Valentin wrote:
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -224,7 +224,7 @@ config DOVE_THERMAL
>
> config DB8500_THERMAL
> bool "DB8500 thermal management"
> - depends on ARCH_U8500
> + depends on ARCH_U8500 || COMPILE_TEST
In file included from drivers/thermal/db8500_thermal.c:23:
include/linux/mfd/dbx500-prcmu.h:437: error: redefinition of ‘prcmu_abb_read’
include/linux/mfd/db8500-prcmu.h:648: error: previous definition of
‘prcmu_abb_read’ was here
include/linux/mfd/dbx500-prcmu.h:442: error: redefinition of ‘prcmu_abb_write’
include/linux/mfd/db8500-prcmu.h:653: error: previous definition of
‘prcmu_abb_write’ was here
include/linux/mfd/dbx500-prcmu.h:453: error: redefinition of
‘prcmu_config_clkout’
include/linux/mfd/db8500-prcmu.h:618: error: previous definition of
‘prcmu_config_clkout’ was here
include/linux/mfd/dbx500-prcmu.h:520: error: redefinition of ‘prcmu_ac_wake_req’
include/linux/mfd/db8500-prcmu.h:658: error: previous definition of
‘prcmu_ac_wake_req’ was here
include/linux/mfd/dbx500-prcmu.h:524: error: redefinition of
‘prcmu_ac_sleep_req’
include/linux/mfd/db8500-prcmu.h:662: error: previous definition of
‘prcmu_ac_sleep_req’ was here
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/17] thermal: int340x: allow compile test
On Thu, Sep 10, 2015 at 6:11 AM, Eduardo Valentin wrote:
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -317,7 +317,7 @@ config INTEL_QUARK_DTS_THERMAL
>
> config INT340X_THERMAL
> tristate "ACPI INT340X thermal drivers"
> - depends on X86 && ACPI
> + depends on (X86 && ACPI) || COMPILE_TEST
> select THERMAL_GOV_USER_SPACE
> select ACPI_THERMAL_REL
> select ACPI_FAN
This driver selects INTEL_SOC_DTS_IOSF_CORE, which uses an x86-specific
header file.
drivers/thermal/int340x_thermal/int3400_thermal.c: In function
‘int3400_thermal_get_uuids’:
drivers/thermal/int340x_thermal/int3400_thermal.c:120: error:
dereferencing pointer to incomplete type
Missing #include
drivers/thermal/int340x_thermal/acpi_thermal_rel.c: In function
‘acpi_parse_trt’:
drivers/thermal/int340x_thermal/acpi_thermal_rel.c:85: error: implicit
declaration of function ‘acpi_has_method’
Missing #include
drivers/thermal/int340x_thermal/acpi_thermal_rel.c: In function
‘acpi_parse_trt’:
drivers/thermal/int340x_thermal/acpi_thermal_rel.c:125: error:
implicit declaration of function ‘acpi_bus_get_device’
Definition depends on CONFIG_ACPI
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/17] thermal: intel_soc_dts: allow compile test
On Thu, Sep 10, 2015 at 6:11 AM, Eduardo Valentin wrote:
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -294,7 +294,7 @@ config INTEL_SOC_DTS_IOSF_CORE
>
> config INTEL_SOC_DTS_THERMAL
> tristate "Intel SoCs DTS thermal driver"
> - depends on X86
> + depends on X86 || COMPILE_TEST
drivers/thermal/intel_soc_dts_thermal.c:20:31: error:
asm/cpu_device_id.h: No such file or directory
x86-only header file
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/17] thermal: intel_quark: allow compile test
On Thu, Sep 10, 2015 at 6:11 AM, Eduardo Valentin wrote:
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -307,7 +307,7 @@ config INTEL_SOC_DTS_THERMAL
>
> config INTEL_QUARK_DTS_THERMAL
> tristate "Intel Quark DTS thermal driver"
> - depends on X86_INTEL_QUARK
> + depends on X86_INTEL_QUARK || COMPILE_TEST
drivers/thermal/intel_quark_dts_thermal.c:64:31: error:
asm/cpu_device_id.h: No such file or directory
drivers/thermal/intel_quark_dts_thermal.c:65:26: error:
asm/iosf_mbi.h: No such file or directory
x86-only header files
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/17] thermal: intel_soc_dts_iosf: allow compile test
On Thu, Sep 10, 2015 at 6:11 AM, Eduardo Valentin wrote:
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -284,7 +284,7 @@ config X86_PKG_TEMP_THERMAL
>
> config INTEL_SOC_DTS_IOSF_CORE
> tristate
> - depends on X86
> + depends on X86 || COMPILE_TEST
drivers/thermal/intel_soc_dts_iosf.c:21:26: error: asm/iosf_mbi.h: No
such file or directory
x86-only header file
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/17] thermal: add COMPILE_TEST (on drivers)
Hi Eduardo,
On Thu, Sep 10, 2015 at 6:10 AM, Eduardo Valentin wrote:
> This is a simple series to add the COMPILE_TEST on thermal drivers.
> The idea is to help compiling and maintaining.
Thanks, good idea!
> Split into smaller patches so people can have their own voices on their
> drivers.
>
> Let me know if this is a problem.
Have you compile-tested this?
I'm seeing too many failures.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] infiniband:mlx4:Fix assumation that ib_get_cached_pkey runs successfully in build_mlx_header
On 9/10/2015 2:04 AM, Nicholas Krause wrote: This fixes a incorrect assumation that ib_get_cached_pkey always runs successfully in the function build_mlx_header by checking if the calls to this particular function return the error code, -EINVAL in order to signal they failed to grap the public key for the device structure pointer passed to this function and if so return immediately to the caller of mlx_header with the error code -EINVAL to signal a error has occurred when calling this particular function that the caller must handle in its own intended error paths. I am totally breathless, put 2-3 periods somewhere along this crazingly long sentence. Does this fixes some specific commit? if yes, please add Fixes: tag @ before your S.O.B linewith the offending commit short ID (--abbrev=12) run speller (e.g assumation --> assumption), use IB/mlx4: prefix, add space between the ":" to the 1st word of the title, e.g: IB/mlx4: Fix assumption that ib_get_cached_pkey runs successfully in build_mlx_header Or. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL REQUEST] watchdog - v4.3-rc1 merge window
Hi Stephen, > > > > Please pull from 'master' branch of > > git://www.linux-watchdog.org/linux-watchdog.git > > I have not been able to fetch from that tree for the past couple of > days. It connects and then hangs for some time and then I get: > > fatal: read error: Connection reset by peer > > Sorry for not mentioning it earlier. The tree hasn't changed since 1.5 weeks, so on content level nothing has changed. Thanks, Wim. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ahci: qoriq: fixed using uninitialized variable warnings
> -Original Message- > From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo > Sent: Wednesday, September 09, 2015 10:02 PM > To: Tang Yuantian-B29983 > Cc: hdego...@redhat.com; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings > > On Wed, Sep 09, 2015 at 05:16:22PM +0800, yuantian.t...@freescale.com > wrote: > > From: Tang Yuantian > > > > kbuild test robot reports the warnings: > > drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset': > > >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used > > >> uninitialized in this function [-Wuninitialized] > > drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here > > >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used > > >> uninitialized in this function [-Wuninitialized] > > drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here > > > > This patch fixed it by assigning 0 to px_is and px_cmd variables. > > This patch also remove line 'struct ccsr_ahci *reg_base' which is not > > referred by any other codes and thus a dead one. > > Hmm... I think the problem here is that the complier can't know whether > qoriq_priv->type would change across intervening function calls. Maybe a > better solution is caching the type in a local variable so that the compiler > can > tell that those two tests will always move together? It generally isn't a > good > idea to clear variables unnecessarily as that can hide actual bugs that > compiler > can detect. > I am not sure if the warning can be removed this way. But I will send the patch as your suggestion. Unfortunately, I can't produce this warning no matter if I add -Wuninitialized. So please let me know if the new patch is working. Regards, Yuantian > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus
On 09/08/2015 03:57 PM, Andrzej Hajda wrote:
On 09/07/2015 01:46 PM, Archit Taneja wrote:
Thierry,
On 08/21/2015 11:39 AM, Archit Taneja wrote:
On 08/20/2015 05:18 PM, Thierry Reding wrote:
On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
Hi Thierry, Lucas,
On 08/19/2015 08:32 PM, Thierry Reding wrote:
On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
Hi Thierry, Archit,
[...]
Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:
i2c@... {
...
dsi-device@... {
...
dsi-bus = <&dsi>;
...
};
...
};
dsi@... {
...
};
Inversing the relationship would become something like this:
i2c@... {
...
};
dsi@... {
...
peripheral@... {
...
i2c-bus = <&i2c>;
...
};
...
};
Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).
So how about we create two devices in the device tree and fuse
them at
the driver level:
i2c@... {
...
i2cdsi: dsi-device@... {
...
};
...
};
dsi@... {
...
peripheral@... {
...
control = <&i2cdsi>;
...
};
...
};
This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.
I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.
Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.
I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.
Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?
The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.
If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)
The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two logical devices to DT (one for each bus interface), you don't
have
anything to glue together with an OF graph.
I see that the having dummy device is the least desirable solution.
But
if there is only one control bus to the device I think it should be
one
device sitting beneath the control bus.
You can then use of-graph to model the data path between the DSI
encoder
and device.
But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to
Thanks for the review.
I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.
There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:
i2c_adap@.. {
adv7533@.. {
port {
adv_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
};
};
dsi_host@.. {
...
...
port {
dsi_out: endpoint {
remote-endpoint = <&adv_in>;
}
};
};
It's the i2c driver's job to parse the graph and retrieve the
phandle to the dsi host. Using this, it can proceed with
registering itself to this host using the new dsi funcs. This
patch does the same for the adv7533 i2c driver:
http://www.spinics.net/lists/dri-devel/msg86840.html
hook up with a control
Re: Kernel 4.1.6 Panic due to slab corruption
On 09/09/2015 05:01 PM, Christoph Lameter wrote: > On Wed, 9 Sep 2015, Nikolay Borisov wrote: > >> [root@kernighan vm]# ./slabinfo -da kmalloc-32 >> Cannot write to dma-kmalloc-32/sanity >> [root@kernighan vm]# ./slabinfo -dF kmalloc-32 >> Cannot write to dma-kmalloc-32/sanity >> [root@kernighan vm]# ./slabinfo -dz kmalloc-32 >> kmalloc-32 not empty cannot enable redzoning >> [root@kernighan vm]# ./slabinfo -dp kmalloc-32 >> kmalloc-32 not empty cannot enable poisoning >> [root@kernighan vm]# ./slabinfo -du kmalloc-32 >> kmalloc-32 not empty cannot enable tracking >> [root@kernighan vm]# ./slabinfo -dt ^kmalloc-32$ >> kmalloc-32 can only enable trace for one slab at a time > > > H.. Whats the problem here? > > christoph@gentwo:/sys/kernel/slab/kmalloc-32$ ls -l > total 0 > -r 1 root root 4096 Sep 9 08:57 aliases > -r 1 root root 4096 Sep 9 08:57 align > -r 1 root root 4096 Sep 9 08:57 alloc_calls > -r 1 root root 4096 Sep 9 08:57 cache_dma > -rw--- 1 root root 4096 Sep 9 08:57 cpu_partial > -r 1 root root 4096 Sep 9 08:57 cpu_slabs > -r 1 root root 4096 Sep 9 08:57 ctor > -r 1 root root 4096 Sep 9 08:57 destroy_by_rcu > -r 1 root root 4096 Sep 9 08:57 free_calls > -r 1 root root 4096 Sep 9 08:57 hwcache_align > -rw--- 1 root root 4096 Sep 9 08:57 min_partial > -r 1 root root 4096 Sep 9 08:57 objects > -r 1 root root 4096 Sep 9 08:57 object_size > -r 1 root root 4096 Sep 9 08:57 objects_partial > -r 1 root root 4096 Sep 9 08:57 objs_per_slab > -rw--- 1 root root 4096 Sep 9 08:57 order > -r 1 root root 4096 Sep 9 08:57 partial > -rw--- 1 root root 4096 Sep 9 08:57 poison > -rw--- 1 root root 4096 Sep 9 08:57 reclaim_account > -rw--- 1 root root 4096 Sep 9 08:57 red_zone > -rw--- 1 root root 4096 Sep 9 08:57 remote_node_defrag_ratio > -r 1 root root 4096 Sep 9 08:57 reserved > -rw--- 1 root root 4096 Sep 9 08:57 sanity_checks > -rw--- 1 root root 4096 Sep 9 08:57 shrink > -r 1 root root 4096 Sep 9 08:57 slabs > -r 1 root root 4096 Sep 9 08:57 slabs_cpu_partial > -r 1 root root 4096 Sep 9 08:57 slab_size > -rw--- 1 root root 4096 Sep 9 08:57 store_user > -r 1 root root 4096 Sep 9 08:57 total_objects > -rw--- 1 root root 4096 Sep 9 08:57 trace > -rw--- 1 root root 4096 Sep 9 08:57 validate > > Try > > echo 1 >santy_checks [root@kernighan linux-stable]# cd /sys/kernel/slab/kmalloc-32/ [root@kernighan kmalloc-32]# echo 1 > sanity_checks [root@kernighan kmalloc-32]# cat sanity_checks 1 So this works as expected when set by echo. Just for testing I then tried the following: [root@kernighan kmalloc-32]# slabinfo -d- kmalloc-32 kmalloc-32 not empty cannot disable sanity checks [root@kernighan kmalloc-32]# echo 0 > sanity_checks [root@kernighan kmalloc-32]# slabinfo -d- kmalloc-32 So turns out slabinfo fails where the raw sys interface succeeds, strange? > > >> >> I did however had success with enabling tracing but couldn't see where >> the output is produced - tried dmesg and the ftrace buffer but nothing >> turned up. > > dmesg is the output channel for tracing. > > What does: > > echo 1 >trace > > do? Could crash the sysem due to overload of messages. Didn't have that much luck with this one: [root@kernighan kmalloc-32]# dmesg -c > /dev/null [root@kernighan kmalloc-32]# echo 1 > trace -bash: echo: write error: Invalid argument > >> But it seems it is not possible to enable any debugging whatsoever, so I >> will restor to doing it at boot time. In this case can you advice which >> options might not result in very high performance degradation - I'm >> thinking of sanity checking and maybe redzoning? > > Sanity checking is ok. But I would think you should be fine with enabling > full debugging on the particular caches of interest. I was just thinking that if enabling debug options disables merging this means it won't be sufficient to enable debugging on kmalloc-32 but rather before enabling debugging I do need to check which caches were aliased and enable debugging on those as well, correct? Regards, Nikolay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC
Add reset driver for hi6220-hikey board,this driver supply deassert
of IP. on hi6220 SoC.
Signed-off-by: Chen Feng
---
drivers/reset/Kconfig | 1 +
drivers/reset/Makefile | 1 +
drivers/reset/hisilicon/Kconfig| 5 +++
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/hi6220_reset.c | 74 ++
5 files changed, 82 insertions(+)
create mode 100644 drivers/reset/hisilicon/Kconfig
create mode 100644 drivers/reset/hisilicon/Makefile
create mode 100644 drivers/reset/hisilicon/hi6220_reset.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..df37212 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
source "drivers/reset/sti/Kconfig"
+source "drivers/reset/hisilicon/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..331d7b2 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
new file mode 100644
index 000..bceed14
--- /dev/null
+++ b/drivers/reset/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_RESET_HI6220
+ tristate "Hi6220 Clock Driver"
+ depends on (ARCH_HISI && RESET_CONTROLLER)
+ help
+ Build the Hisilicon Hi6220 reset driver.
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
new file mode 100644
index 000..c932f86
--- /dev/null
+++ b/drivers/reset/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
diff --git a/drivers/reset/hisilicon/hi6220_reset.c
b/drivers/reset/hisilicon/hi6220_reset.c
new file mode 100644
index 000..a88fc57
--- /dev/null
+++ b/drivers/reset/hisilicon/hi6220_reset.c
@@ -0,0 +1,74 @@
+/*
+ * Hisilicon Hi6220 reset controller driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Feng Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void __iomem *src_base;
+static DEFINE_SPINLOCK(reset_lock);
+
+static int hi6220_reset_module(struct reset_controller_dev *rc_dev,
+ unsigned long idx)
+{
+ unsigned long timeout;
+ unsigned long flags;
+ int bit;
+ u32 val;
+
+ int bank = idx >> 8;
+ int offset = idx & 0xff;
+
+ spin_lock_irqsave(&reset_lock, flags);
+
+ val = readl(src_base + (bank * 0x10));
+ writel(val | BIT(offset), src_base + (bank * 0x10));
+
+ spin_unlock_irqrestore(&reset_lock, flags);
+
+ return 0;
+
+}
+
+static struct reset_control_ops hi6220_reset_ops = {
+ .deassert = hi6220_reset_module,
+};
+
+static struct reset_controller_dev hi6220_reset_dev = {
+ .ops = &hi6220_reset_ops,
+ .nr_resets = 0x,
+};
+
+static void __init hi6220_reset_init(void)
+{
+ struct device_node *np;
+ struct reset_control *test = NULL;
+
+ np = of_find_compatible_node(NULL, NULL, "hisilicon,hisi_reset_ctl");
+ if (!np) {
+ pr_err("find reset node in dts error!\n");
+ return;
+ }
+ src_base = of_iomap(np, 0);
+ WARN_ON(!src_base);
+
+ hi6220_reset_dev.of_node = np;
+ if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
+ reset_controller_register(&hi6220_reset_dev);
+}
+
+postcore_initcall(hi6220_reset_init);
+
--
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/
[RESEND PATCH 2/3] reset: hisilicon: document hisi-hi6220 reset controllers bindings
Add DT bindings documentation for hi6220 SoC reset controller.
Signed-off-by: Chen Feng
---
.../bindings/reset/hisilicon,hi6220-reset.txt | 97 ++
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
2 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
new file mode 100644
index 000..8a23f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
@@ -0,0 +1,97 @@
+Hisilicon System Reset Controller
+==
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller node must be a sub-node of the chip controller
+node on SoCs.
+
+Required properties:
+- compatible: may be "hisilicon,hisi_reset_ctl"
+- reg: should be register base and length as documented in the
+ datasheet
+- #reset-cells: 1, see below
+
+Example:
+
+ reset_ctrl: reset_ctrl@f7030304 {
+ compatible = "hisilicon,hi6220_reset_ctl";
+ reg = <0x0 0xf7030304 0x0 0x1000>;
+ #reset-cells = <1>;
+ };
+
+Specifying reset lines connected to IP modules
+==
+example:
+
+uart1: uart1@. {
+ ...
+resets = <&reset_ctrl 0x305>;
+ ...
+};
+
+The following RESET_INDEX values are valid for hi6220 SoC:
+ PERIPH_RSTDIS0_MMC0 = 0x000,
+ PERIPH_RSTDIS0_MMC1 = 0x001,
+ PERIPH_RSTDIS0_MMC2 = 0x002,
+ PERIPH_RSTDIS0_NANDC= 0x003,
+ PERIPH_RSTDIS0_USBOTG_BUS = 0x004,
+ PERIPH_RSTDIS0_POR_PICOPHY = 0x005,
+ PERIPH_RSTDIS0_USBOTG = 0x006,
+ PERIPH_RSTDIS0_USBOTG_32K = 0x007,
+
+ PERIPH_RSTDIS1_HIFI = 0x100,
+ PERIPH_RSTDIS1_DIGACODEC= 0x105,
+
+ PERIPH_RSTEN2_IPF = 0x200,
+ PERIPH_RSTEN2_SOCP = 0x201,
+ PERIPH_RSTEN2_DMAC = 0x202,
+ PERIPH_RSTEN2_SECENG= 0x203,
+ PERIPH_RSTEN2_ABB = 0x204,
+ PERIPH_RSTEN2_HPM0 = 0x205,
+ PERIPH_RSTEN2_HPM1 = 0x206,
+ PERIPH_RSTEN2_HPM2 = 0x207,
+ PERIPH_RSTEN2_HPM3 = 0x208,
+
+ PERIPH_RSTEN3_CSSYS = 0x300,
+ PERIPH_RSTEN3_I2C0 = 0x301,
+ PERIPH_RSTEN3_I2C1 = 0x302,
+ PERIPH_RSTEN3_I2C2 = 0x303,
+ PERIPH_RSTEN3_I2C3 = 0x304,
+ PERIPH_RSTEN3_UART1 = 0x305,
+ PERIPH_RSTEN3_UART2 = 0x306,
+ PERIPH_RSTEN3_UART3 = 0x307,
+ PERIPH_RSTEN3_UART4 = 0x308,
+ PERIPH_RSTEN3_SSP = 0x309,
+ PERIPH_RSTEN3_PWM = 0x30a,
+ PERIPH_RSTEN3_BLPWM = 0x30b,
+ PERIPH_RSTEN3_TSENSOR = 0x30c,
+ PERIPH_RSTEN3_DAPB = 0x312,
+ PERIPH_RSTEN3_HKADC = 0x313,
+ PERIPH_RSTEN3_CODEC_SSI = 0x314,
+ PERIPH_RSTEN3_PMUSSI1 = 0x316,
+
+ PERIPH_RSTEN8_RS0 = 0x400,
+ PERIPH_RSTEN8_RS2 = 0x401,
+ PERIPH_RSTEN8_RS3 = 0x402,
+ PERIPH_RSTEN8_MS0 = 0x403,
+ PERIPH_RSTEN8_MS2 = 0x405,
+ PERIPH_RSTEN8_XG2RAM0 = 0x406,
+ PERIPH_RSTEN8_X2SRAM_TZMA = 0x407,
+ PERIPH_RSTEN8_SRAM = 0x408,
+ PERIPH_RSTEN8_HARQ = 0x40a,
+ PERIPH_RSTEN8_DDRC = 0x40c,
+ PERIPH_RSTEN8_DDRC_APB = 0x40d,
+ PERIPH_RSTEN8_DDRPACK_APB = 0x40e,
+ PERIPH_RSTEN8_DDRT = 0x411,
+
+ PERIPH_RSDIST9_CARM_DAP = 0x500,
+ PERIPH_RSDIST9_CARM_ATB = 0x501,
+ PERIPH_RSDIST9_CARM_LBUS= 0x502,
+ PERIPH_RSDIST9_CARM_POR = 0x503,
+ PERIPH_RSDIST9_CARM_CORE= 0x504,
+ PERIPH_RSDIST9_CARM_DBG = 0x505,
+ PERIPH_RSDIST9_CARM_L2 = 0x506,
+ PERIPH_RSDIST9_CARM_SOCDBG = 0x507,
+ PERIPH_RSDIST9_CARM_ETM = 0x508,
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 09bb9d1..111537a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -169,7 +169,7 @@
};
reset_ctrl: reset_ctrl@f7030304 {
- compatible = "hisilicon,hisi_reset_ctl";
+ compatible = "hisilicon,hi6220_reset_ctl";
reg = <0x0 0xf7030304 0x0 0x1000>;
[RESEND PATCH 1/3] arm64: dts: Add reset dts config for Hisilicon Hi6220 SoC
Add reset controller for hi6220 hikey-board.
Signed-off-by: Chen Feng
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..09bb9d1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,12 @@
clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+ reset_ctrl: reset_ctrl@f7030304 {
+ compatible = "hisilicon,hisi_reset_ctl";
+ reg = <0x0 0xf7030304 0x0 0x1000>;
+ #reset-cells = <1>;
+ };
+
};
};
--
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 2/3] net: irda: pxaficp_ir: convert to readl and writel
Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a): > Petr Cvek writes: > >> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a): >>> >>> Did you defined resources somewhere? Actual resources are in >>> "pxa_ir_resources" variable at: > I have them in patch [1], which is exactly the patch you have made yourself. Is there a mailing list for this specific patch? It seems I did not get any mail with it. > >> I tried to add following patch for new resources, but now it fails with: >> >> [ 141.534545] pxa2xx-ir pxa2xx-ir: can't request region for resource [mem >> 0x4070-0x40700100] >> [ 141.534574] pxa2xx-ir pxa2xx-ir: resource stuart not defined >> [ 141.534656] pxa2xx-ir: probe of pxa2xx-ir failed with error -16 >> >> That's because STUART is allocated by normal UART driver at: >> >> http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L244 >> >> So somehow there must be configuration for STUART used with FICP and STUART >> alone (probably can be used for normal UART). > That's because you have to remove from magician.c: > pxa_set_stuart_info(NULL); > Thanks, I missed that. BTW This patch required update of my kernel repo. It seems that my: magician.c patches + ficp patch + new dma engine does not work for me at all. Kernel throws some panic about interrupts and then it ends in an infinite stack dumping loop. Fault occurs before rootfs is mounted, so probably around MMC init (with removed SD card it fails normally with no rootfs found error). Is it required to change something in the mach-pxa machine specific files? Which hardware was used for testing new dma engine implementation? Notably MMC driver part, probably commit: 6464b71409511939efce1ae4fb4ec6e3483b11b2 Best regards, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] reset: hisilicon: document hisi-hi6220 reset controllers bindings
Add DT bindings documentation for hi6220 SoC reset controller.
Signed-off-by: Chen Feng
---
.../bindings/reset/hisilicon,hi6220-reset.txt | 97 ++
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
2 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
new file mode 100644
index 000..8a23f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
@@ -0,0 +1,97 @@
+Hisilicon System Reset Controller
+==
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller node must be a sub-node of the chip controller
+node on SoCs.
+
+Required properties:
+- compatible: may be "hisilicon,hisi_reset_ctl"
+- reg: should be register base and length as documented in the
+ datasheet
+- #reset-cells: 1, see below
+
+Example:
+
+ reset_ctrl: reset_ctrl@f7030304 {
+ compatible = "hisilicon,hi6220_reset_ctl";
+ reg = <0x0 0xf7030304 0x0 0x1000>;
+ #reset-cells = <1>;
+ };
+
+Specifying reset lines connected to IP modules
+==
+example:
+
+uart1: uart1@. {
+ ...
+resets = <&reset_ctrl 0x305>;
+ ...
+};
+
+The following RESET_INDEX values are valid for hi6220 SoC:
+ PERIPH_RSTDIS0_MMC0 = 0x000,
+ PERIPH_RSTDIS0_MMC1 = 0x001,
+ PERIPH_RSTDIS0_MMC2 = 0x002,
+ PERIPH_RSTDIS0_NANDC= 0x003,
+ PERIPH_RSTDIS0_USBOTG_BUS = 0x004,
+ PERIPH_RSTDIS0_POR_PICOPHY = 0x005,
+ PERIPH_RSTDIS0_USBOTG = 0x006,
+ PERIPH_RSTDIS0_USBOTG_32K = 0x007,
+
+ PERIPH_RSTDIS1_HIFI = 0x100,
+ PERIPH_RSTDIS1_DIGACODEC= 0x105,
+
+ PERIPH_RSTEN2_IPF = 0x200,
+ PERIPH_RSTEN2_SOCP = 0x201,
+ PERIPH_RSTEN2_DMAC = 0x202,
+ PERIPH_RSTEN2_SECENG= 0x203,
+ PERIPH_RSTEN2_ABB = 0x204,
+ PERIPH_RSTEN2_HPM0 = 0x205,
+ PERIPH_RSTEN2_HPM1 = 0x206,
+ PERIPH_RSTEN2_HPM2 = 0x207,
+ PERIPH_RSTEN2_HPM3 = 0x208,
+
+ PERIPH_RSTEN3_CSSYS = 0x300,
+ PERIPH_RSTEN3_I2C0 = 0x301,
+ PERIPH_RSTEN3_I2C1 = 0x302,
+ PERIPH_RSTEN3_I2C2 = 0x303,
+ PERIPH_RSTEN3_I2C3 = 0x304,
+ PERIPH_RSTEN3_UART1 = 0x305,
+ PERIPH_RSTEN3_UART2 = 0x306,
+ PERIPH_RSTEN3_UART3 = 0x307,
+ PERIPH_RSTEN3_UART4 = 0x308,
+ PERIPH_RSTEN3_SSP = 0x309,
+ PERIPH_RSTEN3_PWM = 0x30a,
+ PERIPH_RSTEN3_BLPWM = 0x30b,
+ PERIPH_RSTEN3_TSENSOR = 0x30c,
+ PERIPH_RSTEN3_DAPB = 0x312,
+ PERIPH_RSTEN3_HKADC = 0x313,
+ PERIPH_RSTEN3_CODEC_SSI = 0x314,
+ PERIPH_RSTEN3_PMUSSI1 = 0x316,
+
+ PERIPH_RSTEN8_RS0 = 0x400,
+ PERIPH_RSTEN8_RS2 = 0x401,
+ PERIPH_RSTEN8_RS3 = 0x402,
+ PERIPH_RSTEN8_MS0 = 0x403,
+ PERIPH_RSTEN8_MS2 = 0x405,
+ PERIPH_RSTEN8_XG2RAM0 = 0x406,
+ PERIPH_RSTEN8_X2SRAM_TZMA = 0x407,
+ PERIPH_RSTEN8_SRAM = 0x408,
+ PERIPH_RSTEN8_HARQ = 0x40a,
+ PERIPH_RSTEN8_DDRC = 0x40c,
+ PERIPH_RSTEN8_DDRC_APB = 0x40d,
+ PERIPH_RSTEN8_DDRPACK_APB = 0x40e,
+ PERIPH_RSTEN8_DDRT = 0x411,
+
+ PERIPH_RSDIST9_CARM_DAP = 0x500,
+ PERIPH_RSDIST9_CARM_ATB = 0x501,
+ PERIPH_RSDIST9_CARM_LBUS= 0x502,
+ PERIPH_RSDIST9_CARM_POR = 0x503,
+ PERIPH_RSDIST9_CARM_CORE= 0x504,
+ PERIPH_RSDIST9_CARM_DBG = 0x505,
+ PERIPH_RSDIST9_CARM_L2 = 0x506,
+ PERIPH_RSDIST9_CARM_SOCDBG = 0x507,
+ PERIPH_RSDIST9_CARM_ETM = 0x508,
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 09bb9d1..111537a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -169,7 +169,7 @@
};
reset_ctrl: reset_ctrl@f7030304 {
- compatible = "hisilicon,hisi_reset_ctl";
+ compatible = "hisilicon,hi6220_reset_ctl";
reg = <0x0 0xf7030304 0x0 0x1000>;
[PATCH 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC
Add reset driver for hi6220-hikey board,this driver supply deassert
of IP. on hi6220 SoC.
Signed-off-by: Chen Feng
---
drivers/reset/Kconfig | 1 +
drivers/reset/Makefile | 1 +
drivers/reset/hisilicon/Kconfig| 5 +++
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/hi6220_reset.c | 74 ++
5 files changed, 82 insertions(+)
create mode 100644 drivers/reset/hisilicon/Kconfig
create mode 100644 drivers/reset/hisilicon/Makefile
create mode 100644 drivers/reset/hisilicon/hi6220_reset.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..df37212 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
source "drivers/reset/sti/Kconfig"
+source "drivers/reset/hisilicon/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..331d7b2 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
new file mode 100644
index 000..bceed14
--- /dev/null
+++ b/drivers/reset/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_RESET_HI6220
+ tristate "Hi6220 Clock Driver"
+ depends on (ARCH_HISI && RESET_CONTROLLER)
+ help
+ Build the Hisilicon Hi6220 reset driver.
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
new file mode 100644
index 000..c932f86
--- /dev/null
+++ b/drivers/reset/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
diff --git a/drivers/reset/hisilicon/hi6220_reset.c
b/drivers/reset/hisilicon/hi6220_reset.c
new file mode 100644
index 000..a88fc57
--- /dev/null
+++ b/drivers/reset/hisilicon/hi6220_reset.c
@@ -0,0 +1,74 @@
+/*
+ * Hisilicon Hi6220 reset controller driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Feng Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void __iomem *src_base;
+static DEFINE_SPINLOCK(reset_lock);
+
+static int hi6220_reset_module(struct reset_controller_dev *rc_dev,
+ unsigned long idx)
+{
+ unsigned long timeout;
+ unsigned long flags;
+ int bit;
+ u32 val;
+
+ int bank = idx >> 8;
+ int offset = idx & 0xff;
+
+ spin_lock_irqsave(&reset_lock, flags);
+
+ val = readl(src_base + (bank * 0x10));
+ writel(val | BIT(offset), src_base + (bank * 0x10));
+
+ spin_unlock_irqrestore(&reset_lock, flags);
+
+ return 0;
+
+}
+
+static struct reset_control_ops hi6220_reset_ops = {
+ .deassert = hi6220_reset_module,
+};
+
+static struct reset_controller_dev hi6220_reset_dev = {
+ .ops = &hi6220_reset_ops,
+ .nr_resets = 0x,
+};
+
+static void __init hi6220_reset_init(void)
+{
+ struct device_node *np;
+ struct reset_control *test = NULL;
+
+ np = of_find_compatible_node(NULL, NULL, "hisilicon,hisi_reset_ctl");
+ if (!np) {
+ pr_err("find reset node in dts error!\n");
+ return;
+ }
+ src_base = of_iomap(np, 0);
+ WARN_ON(!src_base);
+
+ hi6220_reset_dev.of_node = np;
+ if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
+ reset_controller_register(&hi6220_reset_dev);
+}
+
+postcore_initcall(hi6220_reset_init);
+
--
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 1/3] arm64: dts: Add reset dts config for Hisilicon Hi6220 SoC
Add reset controller for hi6220 hikey-board.
Signed-off-by: Chen Feng
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..09bb9d1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,12 @@
clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+ reset_ctrl: reset_ctrl@f7030304 {
+ compatible = "hisilicon,hisi_reset_ctl";
+ reg = <0x0 0xf7030304 0x0 0x1000>;
+ #reset-cells = <1>;
+ };
+
};
};
--
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] hw_random: octeon-rng: Use devm_hwrng_register
Use resource managed function devm_hwrng_register instead of
hwrng_register to make the error-path simpler. Also, remove
octeon_rng_remove as it is now redundant.
Signed-off-by: Vaishali Thakkar
---
drivers/char/hw_random/octeon-rng.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/char/hw_random/octeon-rng.c
b/drivers/char/hw_random/octeon-rng.c
index 6234a4a..8c78aa0 100644
--- a/drivers/char/hw_random/octeon-rng.c
+++ b/drivers/char/hw_random/octeon-rng.c
@@ -96,7 +96,7 @@ static int octeon_rng_probe(struct platform_device *pdev)
rng->ops = ops;
platform_set_drvdata(pdev, &rng->ops);
- ret = hwrng_register(&rng->ops);
+ ret = devm_hwrng_register(&pdev->dev, &rng->ops);
if (ret)
return -ENOENT;
@@ -105,21 +105,11 @@ static int octeon_rng_probe(struct platform_device *pdev)
return 0;
}
-static int octeon_rng_remove(struct platform_device *pdev)
-{
- struct hwrng *rng = platform_get_drvdata(pdev);
-
- hwrng_unregister(rng);
-
- return 0;
-}
-
static struct platform_driver octeon_rng_driver = {
.driver = {
.name = "octeon_rng",
},
.probe = octeon_rng_probe,
- .remove = octeon_rng_remove,
};
module_platform_driver(octeon_rng_driver);
--
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: [GIT PULL REQUEST] watchdog - v4.3-rc1 merge window
Hi Stephen, Linus, > On Wed, Sep 9, 2015 at 2:40 PM, Stephen Rothwell > wrote: > > > > I have not been able to fetch from that tree for the past couple of > > days. It connects and then hangs for some time > > .. yup, that's what I got just when trying to pull. I just restarted the git-daemon. You should be able to pull again. Thanks for reporting it. Kind regards, Wim. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] Staging: iio: cdc: ad7152.c: Prefer using the BIT macro
On Thu, 10 Sep 2015, Shraddha Barke wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro > as it's extensively used by other function in this driver. Don't use BIT in the mixed cases. julia > > This was done with coccinelle: > @@ int g; @@ > > -(1 << g) > +BIT(g) > > Signed-off-by: Shraddha Barke > --- > drivers/staging/iio/cdc/ad7152.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/drivers/staging/iio/cdc/ad7152.c > b/drivers/staging/iio/cdc/ad7152.c > index 87110d9..ba44c0e 100644 > --- a/drivers/staging/iio/cdc/ad7152.c > +++ b/drivers/staging/iio/cdc/ad7152.c > @@ -41,30 +41,30 @@ > #define AD7152_REG_CFG2 26 > > /* Status Register Bit Designations (AD7152_REG_STATUS) */ > -#define AD7152_STATUS_RDY1 (1 << 0) > -#define AD7152_STATUS_RDY2 (1 << 1) > -#define AD7152_STATUS_C1C2 (1 << 2) > -#define AD7152_STATUS_PWDN (1 << 7) > +#define AD7152_STATUS_RDY1 BIT(0) > +#define AD7152_STATUS_RDY2 BIT(1) > +#define AD7152_STATUS_C1C2 BIT(2) > +#define AD7152_STATUS_PWDN BIT(7) > > /* Setup Register Bit Designations (AD7152_REG_CHx_SETUP) */ > -#define AD7152_SETUP_CAPDIFF (1 << 5) > +#define AD7152_SETUP_CAPDIFF BIT(5) > #define AD7152_SETUP_RANGE_2pF (0 << 6) > -#define AD7152_SETUP_RANGE_0_5pF (1 << 6) > +#define AD7152_SETUP_RANGE_0_5pF BIT(6) > #define AD7152_SETUP_RANGE_1pF (2 << 6) > #define AD7152_SETUP_RANGE_4pF (3 << 6) > #define AD7152_SETUP_RANGE(x)((x) << 6) > > /* Config Register Bit Designations (AD7152_REG_CFG) */ > -#define AD7152_CONF_CH2EN(1 << 3) > -#define AD7152_CONF_CH1EN(1 << 4) > +#define AD7152_CONF_CH2ENBIT(3) > +#define AD7152_CONF_CH1ENBIT(4) > #define AD7152_CONF_MODE_IDLE(0 << 0) > -#define AD7152_CONF_MODE_CONT_CONV (1 << 0) > +#define AD7152_CONF_MODE_CONT_CONV BIT(0) > #define AD7152_CONF_MODE_SINGLE_CONV (2 << 0) > #define AD7152_CONF_MODE_OFFS_CAL(5 << 0) > #define AD7152_CONF_MODE_GAIN_CAL(6 << 0) > > /* Capdac Register Bit Designations (AD7152_REG_CAPDAC_XXX) */ > -#define AD7152_CAPDAC_DACEN (1 << 7) > +#define AD7152_CAPDAC_DACEN BIT(7) > #define AD7152_CAPDAC_DACP(x)((x) & 0x1F) > > /* CFG2 Register Bit Designations (AD7152_REG_CFG2) */ > -- > 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/
Re: [PATCH 4/6] Staging: iio: cdc: ad7746.c: Prefer using the BIT macro
On Thu, 10 Sep 2015, Shraddha Barke wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro > as it's extensively used by other function in this driver. > > This was done with coccinelle: > @@ int g; @@ > > -(1 << g) > +BIT(g) > > Signed-off-by: Shraddha Barke > --- > drivers/staging/iio/cdc/ad7746.c | 42 > > 1 file changed, 21 insertions(+), 21 deletions(-) > > diff --git a/drivers/staging/iio/cdc/ad7746.c > b/drivers/staging/iio/cdc/ad7746.c > index e6e9eaa..e17d4e1 100644 > --- a/drivers/staging/iio/cdc/ad7746.c > +++ b/drivers/staging/iio/cdc/ad7746.c > @@ -46,48 +46,48 @@ > #define AD7746_REG_VOLT_GAINL18 > > /* Status Register Bit Designations (AD7746_REG_STATUS) */ > -#define AD7746_STATUS_EXCERR (1 << 3) > -#define AD7746_STATUS_RDY(1 << 2) > -#define AD7746_STATUS_RDYVT (1 << 1) > -#define AD7746_STATUS_RDYCAP (1 << 0) > +#define AD7746_STATUS_EXCERR BIT(3) > +#define AD7746_STATUS_RDYBIT(2) > +#define AD7746_STATUS_RDYVT BIT(1) > +#define AD7746_STATUS_RDYCAP BIT(0) > > /* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) > */ > -#define AD7746_CAPSETUP_CAPEN(1 << 7) > -#define AD7746_CAPSETUP_CIN2 (1 << 6) /* AD7746 only */ > -#define AD7746_CAPSETUP_CAPDIFF (1 << 5) > -#define AD7746_CAPSETUP_CACHOP (1 << 0) > +#define AD7746_CAPSETUP_CAPENBIT(7) > +#define AD7746_CAPSETUP_CIN2 BIT(6) /* AD7746 only */ > +#define AD7746_CAPSETUP_CAPDIFF BIT(5) > +#define AD7746_CAPSETUP_CACHOP BIT(0) You could harmonize the indentation in this bunch. > /* Voltage/Temperature Setup Register Bit Designations (AD7746_REG_VT_SETUP) > */ > -#define AD7746_VTSETUP_VTEN (1 << 7) > +#define AD7746_VTSETUP_VTEN BIT(7) > #define AD7746_VTSETUP_VTMD_INT_TEMP (0 << 5) > -#define AD7746_VTSETUP_VTMD_EXT_TEMP (1 << 5) > +#define AD7746_VTSETUP_VTMD_EXT_TEMP BIT(5) > #define AD7746_VTSETUP_VTMD_VDD_MON (2 << 5) > #define AD7746_VTSETUP_VTMD_EXT_VIN (3 << 5) > -#define AD7746_VTSETUP_EXTREF(1 << 4) > -#define AD7746_VTSETUP_VTSHORT (1 << 1) > -#define AD7746_VTSETUP_VTCHOP(1 << 0) > +#define AD7746_VTSETUP_EXTREFBIT(4) > +#define AD7746_VTSETUP_VTSHORT BIT(1) > +#define AD7746_VTSETUP_VTCHOPBIT(0) It doesn't look like a good idea to use BIT here, because it is mixed with other things. > /* Excitation Setup Register Bit Designations (AD7746_REG_EXC_SETUP) */ > -#define AD7746_EXCSETUP_CLKCTRL (1 << 7) > -#define AD7746_EXCSETUP_EXCON(1 << 6) > -#define AD7746_EXCSETUP_EXCB (1 << 5) > -#define AD7746_EXCSETUP_NEXCB(1 << 4) > -#define AD7746_EXCSETUP_EXCA (1 << 3) > -#define AD7746_EXCSETUP_NEXCA(1 << 2) > +#define AD7746_EXCSETUP_CLKCTRL BIT(7) > +#define AD7746_EXCSETUP_EXCONBIT(6) > +#define AD7746_EXCSETUP_EXCB BIT(5) > +#define AD7746_EXCSETUP_NEXCBBIT(4) > +#define AD7746_EXCSETUP_EXCA BIT(3) > +#define AD7746_EXCSETUP_NEXCABIT(2) > #define AD7746_EXCSETUP_EXCLVL(x)(((x) & 0x3) << 0) Fix the alignment. > /* Config Register Bit Designations (AD7746_REG_CFG) */ > #define AD7746_CONF_VTFS(x) ((x) << 6) > #define AD7746_CONF_CAPFS(x) ((x) << 3) > #define AD7746_CONF_MODE_IDLE(0 << 0) > -#define AD7746_CONF_MODE_CONT_CONV (1 << 0) > +#define AD7746_CONF_MODE_CONT_CONV BIT(0) > #define AD7746_CONF_MODE_SINGLE_CONV (2 << 0) > #define AD7746_CONF_MODE_PWRDN (3 << 0) > #define AD7746_CONF_MODE_OFFS_CAL(5 << 0) > #define AD7746_CONF_MODE_GAIN_CAL(6 << 0) Don't use BIT in this case. julia > /* CAPDAC Register Bit Designations (AD7746_REG_CAPDACx) */ > -#define AD7746_CAPDAC_DACEN (1 << 7) > +#define AD7746_CAPDAC_DACEN BIT(7) > #define AD7746_CAPDAC_DACP(x)((x) & 0x7F) > > /* > -- > 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/
Re: [PATCH 5/6] Staging: iio: impedance-analyzer: Prefer using the BIT macro
On Thu, 10 Sep 2015, Shraddha Barke wrote:
> This patch replaces bit shifting on 1 with the BIT(x) macro
> as it's extensively used by other function in this driver.
>
> This was done with coccinelle:
> @@ int g; @@
>
> -(1 << g)
> +BIT(g)
This doesn't look like a good idea here, since there is a mixture of uses
of BIT and other things for similar values.
julia
> Signed-off-by: Shraddha Barke
> ---
> drivers/staging/iio/impedance-analyzer/ad5933.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index c18109c..48acad0 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -39,7 +39,7 @@
> #define AD5933_REG_IMAG_DATA 0x96/* R, 2 bytes*/
>
> /* AD5933_REG_CONTROL_HB Bits */
> -#define AD5933_CTRL_INIT_START_FREQ (0x1 << 4)
> +#define AD5933_CTRL_INIT_START_FREQ BIT(4)
> #define AD5933_CTRL_START_SWEEP (0x2 << 4)
> #define AD5933_CTRL_INC_FREQ (0x3 << 4)
> #define AD5933_CTRL_REPEAT_FREQ (0x4 << 4)
> @@ -48,23 +48,23 @@
> #define AD5933_CTRL_STANDBY (0xB << 4)
>
> #define AD5933_CTRL_RANGE_2000mVpp (0x0 << 1)
> -#define AD5933_CTRL_RANGE_200mVpp(0x1 << 1)
> +#define AD5933_CTRL_RANGE_200mVppBIT(1)
> #define AD5933_CTRL_RANGE_400mVpp(0x2 << 1)
> #define AD5933_CTRL_RANGE_1000mVpp (0x3 << 1)
> #define AD5933_CTRL_RANGE(x) ((x) << 1)
>
> -#define AD5933_CTRL_PGA_GAIN_1 (0x1 << 0)
> +#define AD5933_CTRL_PGA_GAIN_1 BIT(0)
> #define AD5933_CTRL_PGA_GAIN_5 (0x0 << 0)
>
> /* AD5933_REG_CONTROL_LB Bits */
> -#define AD5933_CTRL_RESET(0x1 << 4)
> +#define AD5933_CTRL_RESETBIT(4)
> #define AD5933_CTRL_INT_SYSCLK (0x0 << 3)
> -#define AD5933_CTRL_EXT_SYSCLK (0x1 << 3)
> +#define AD5933_CTRL_EXT_SYSCLK BIT(3)
>
> /* AD5933_REG_STATUS Bits */
> -#define AD5933_STAT_TEMP_VALID (0x1 << 0)
> -#define AD5933_STAT_DATA_VALID (0x1 << 1)
> -#define AD5933_STAT_SWEEP_DONE (0x1 << 2)
> +#define AD5933_STAT_TEMP_VALID BIT(0)
> +#define AD5933_STAT_DATA_VALID BIT(1)
> +#define AD5933_STAT_SWEEP_DONE BIT(2)
>
> /* I2C Block Commands */
> #define AD5933_I2C_BLOCK_WRITE 0xA0
> @@ -222,7 +222,7 @@ static int ad5933_set_freq(struct ad5933_state *st,
> u8 d8[4];
> } dat;
>
> - freqreg = (u64) freq * (u64) (1 << 27);
> + freqreg = (u64) freq * (u64) BIT(27);
> do_div(freqreg, st->mclk_hz / 4);
>
> switch (reg) {
> @@ -308,7 +308,7 @@ static ssize_t ad5933_show_frequency(struct device *dev,
> freqreg = be32_to_cpu(dat.d32) & 0xFF;
>
> freqreg = (u64) freqreg * (u64) (st->mclk_hz / 4);
> - do_div(freqreg, 1 << 27);
> + do_div(freqreg, BIT(27));
>
> return sprintf(buf, "%d\n", (int) freqreg);
> }
> @@ -437,7 +437,7 @@ static ssize_t ad5933_store(struct device *dev,
>
> /* 2x, 4x handling, see datasheet */
> if (val > 511)
> - val = (val >> 1) | (1 << 9);
> + val = (val >> 1) | BIT(9);
> else if (val > 1022)
> val = (val >> 2) | (3 << 9);
>
> --
> 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/
Re: [PATCH 2/3] lib/kobject_uevent.c: add uevent forwarding function
On Thu, Sep 10, 2015 at 08:43:28AM +0300, Amir Goldstein wrote: > I fully agree with you that running unmodified distro inside a > container is not a justified > cause for kernel changes. Great, end of discussion :) > However, I would like to highlight the point that udev is not the only > consumer of uevents, so changing userspace, as you rightfully > suggested, may not be as simple as you imagine. But you have control over who consumes uevents, so if you really want to create such a "only send some uevents to some containers" you can do so from the "host" container today. Exactly like udev does this today if you look at how udevd works, udevd uses the kernel as the filter to only wake up processes that have subscribed to specific events. It's as if no one actually looks at how this works :( > For example, in our Android use case, we have no intention of running > unmodified Android > inside container and modifying Android's ueventd is not an issue for us. > Android userspace uses uevents extensively. For example, vold uses uevents to > be > notified of SDCARD insert event and that is just one example. > We can get around vold and maybe we can get around every other open > source Android tool > that make use of uevents, but phone vendors tend to use uevents to communicate > messages between their drivers and proprietary software and this is > were we must have > a way to filter those uevents in the kernel. If you are going to modify Android, just use udevd and filter things that way, you can do it today. Or just modify the tools that Android uses for listening to uevents. > You argue that "device is never bound to a namespace" (and that it > never will be) and I don't disagree with that. Great, end of discussion :) > However, as Eric said, the "broadcast everything" logic does not make > much sense. Only one thing is listening to these events, put your filter there (again, just like udevd does today...) > In a way, the broadcast logic is opposite to your suggestion to modify > userspace. Nope, see above. > In almost every existing implementation of containers, only the root namespace > owns responsibility for booting the machine and configuring devices, so if all > containers were running modified userspace, there would have been no need to > broadcast uevents to all namespaces. Wonderful, as you said you were going to modify the container applications, this isn't an issue :) > At the very least, you should be able to consent with the idea of > having the broadcast policy decided by userspace. But it already is, userspace can decide what it wants to do with every event today. Again, to sound like a broken record, just like udevd does. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zram: introduce comp algorithm fallback functionality
On Thu, Sep 10, 2015 at 02:33:19PM +0900, Sergey Senozhatsky wrote: > Hello, > > On (09/10/15 14:03), Minchan Kim wrote: > [..] > > > > I guess most of scripts have checked result of his doing so if we > > removes it, it will break them. > > to be honest, we never documented or required any of those. the only source > of information for the user space -- zram.txt documentation -- simply says > to do 'echo 3 > /sys/block/zram0/max_comp_streams' or any other bunch of > 'echo'-s. so, technically, a user is free to simply copy-paste what we do > in zram.txt to his zram.sh and call it a "recommended way of doing things > in zram". Agree. That's why we spend a lot discussion for this small change. > > besides, zram.txt is outdated. for example there is no mem_used_max > documentation. > > we need to do better job documenting. I'll try to take a look on this later > this week. Thanks. > > > > Given that, every success of "echo zzz > /sys/block/zram0/comp_algorithm" > > makes users to be confused that he might think to success to change > > algorithm > > in runtime. IOW, it should return error which is more intuitive forme. > > well, not quite like that. we return -EINVAL on invalid output since > d93435c3fba4a47b773693b0c8992470d38510d5. this patch does not change > anything from this pov. it does, however, change the behaviour of > disksize store that follows. I said like that you cut off. "Although we could change ABI of optional parameters into no failure smoothly" ^^ > > I'm fine when the motivation for this patch is to introduce the > "fallback" mechanism (like zswap fallbacks to default compressor, f.e.), > but it wasn't the case -- I rewrote the patch slightly, reworded the > commit message and put some reasoning to this patch. > > -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib/kobject_uevent.c: add uevent forwarding function
On Wed, Sep 9, 2015 at 11:11 PM, Greg KH wrote:
>
> On Wed, Sep 09, 2015 at 03:24:12PM -0400, Michael J Coss wrote:
> > On 9/8/2015 11:55 PM, Greg KH wrote:
> > > On Tue, Sep 08, 2015 at 10:10:29PM -0400, Michael J. Coss wrote:
> > >> Adds capability to allow userspace programs to forward a given event to
> > >> a specific network namespace as determined by the provided pid. In
> > >> addition, support for a per-namespace kobject_sequence counter was
> > >> added. Sysfs was modified to return the correct event counter based on
> > >> the current network namespace.
> > >>
> > >> Signed-off-by: Michael J. Coss
> > >> ---
> > >> include/linux/kobject.h | 3 ++
> > >> include/net/net_namespace.h | 3 ++
> > >> kernel/ksysfs.c | 12 ++
> > >> lib/kobject_uevent.c| 90
> > >> +
> > >> 4 files changed, 108 insertions(+)
> > >>
> > >> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> > >> index 637f670..d1bb509 100644
> > >> --- a/include/linux/kobject.h
> > >> +++ b/include/linux/kobject.h
> > >> @@ -215,6 +215,9 @@ extern struct kobject *firmware_kobj;
> > >> int kobject_uevent(struct kobject *kobj, enum kobject_action action);
> > >> int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
> > >>char *envp[]);
> > >> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> > >> +int kobject_uevent_forward(char *buf, size_t len, pid_t pid);
> > >> +#endif
> > >>
> > >> __printf(2, 3)
> > >> int add_uevent_var(struct kobj_uevent_env *env, const char *format,
> > >> ...);
> > >> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> > >> index e951453..a4013e5 100644
> > >> --- a/include/net/net_namespace.h
> > >> +++ b/include/net/net_namespace.h
> > >> @@ -134,6 +134,9 @@ struct net {
> > >> #if IS_ENABLED(CONFIG_MPLS)
> > >>struct netns_mpls mpls;
> > >> #endif
> > >> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> > >> + u64 kevent_seqnum;
> > >> +#endif
> > >>struct sock *diag_nlsk;
> > >>atomic_tfnhe_genid;
> > >> };
> > >> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > >> index 6683cce..4bc15fd 100644
> > >> --- a/kernel/ksysfs.c
> > >> +++ b/kernel/ksysfs.c
> > >> @@ -21,6 +21,9 @@
> > >> #include
> > >>
> > >> #include/* rcu_expedited */
> > >> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> > >> +#include
> > >> +#endif
> > > #if isn't needed here, right?
> > >
> > >>
> > >> #define KERNEL_ATTR_RO(_name) \
> > >> static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
> > >> @@ -33,6 +36,15 @@ static struct kobj_attribute _name##_attr = \
> > >> static ssize_t uevent_seqnum_show(struct kobject *kobj,
> > >> struct kobj_attribute *attr, char *buf)
> > >> {
> > >> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> > >> + pid_t p = task_pid_vnr(current);
> > >> + struct net *n = get_net_ns_by_pid(p);
> > >> +
> > >> + if (n != ERR_PTR(-ESRCH)) {
> > >> + if (!net_eq(n, &init_net))
> > >> + return sprintf(buf, "%llu\n", n->kevent_seqnum);
> > >> + }
> > >> +#endif
> > >>return sprintf(buf, "%llu\n", (unsigned long long)uevent_seqnum);
> > >> }
> > >> KERNEL_ATTR_RO(uevent_seqnum);
> > >> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> > >> index d791e33..7589745 100644
> > >> --- a/lib/kobject_uevent.c
> > >> +++ b/lib/kobject_uevent.c
> > >> @@ -379,6 +379,96 @@ int kobject_uevent(struct kobject *kobj, enum
> > >> kobject_action action)
> > >> }
> > >> EXPORT_SYMBOL_GPL(kobject_uevent);
> > >>
> > >> +#if defined(CONFIG_UDEVNS) || defined(CONFIG_UDEVNS_MODULE)
> > >> +/**
> > >> + * kobject_uevent_forward - forward event to specified network namespace
> > >> + *
> > >> + * @buf: event buffer
> > >> + * @len: event length
> > >> + * @pid: pid of network namespace
> > >> + *
> > >> + * Returns 0 if kobject_uevent_forward() is completed with success or
> > >> the
> > >> + * corresponding error when it fails.
> > >> + */
> > >> +int kobject_uevent_forward(char *buf, size_t len, pid_t pid)
> > >> +{
> > >> + int retval = 0;
> > >> +#if defined(CONFIG_NET)
> > >> + struct uevent_sock *ue_sk;
> > >> + struct net *pns;
> > >> + char *p;
> > >> + u64 num;
> > >> +
> > >> + /* grab the network namespace of the provided pid */
> > >> + pns = get_net_ns_by_pid(pid);
> > >> + if (pns == ERR_PTR(-ESRCH))
> > >> + return -ESRCH;
> > >> +
> > >> + /* find sequence number in buffer */
> > >> + p = buf;
> > >> + num = 0;
> > >> + while (p < (buf + len)) {
> > >> + if (strncmp(p, "SEQNUM=", 7) == 0) {
> > >> + int r;
> > >> +
> > >> + p += 7;
> > >> + r = kstrtoull(p, 10, &num);
> > >> + if (r) {
> > >> + put_net(pns);
> > >> +
Re: [PATCH] staging: ion: fix corruption of ion_import_dma_buf
On Wed, Sep 9, 2015 at 10:19 AM, Laura Abbott wrote:
> (adding Colin and John)
>
>
> On 09/09/2015 12:41 AM, Shawn Lin wrote:
>>
>> we found this issue but still exit in lastest kernel. Simply
>> keep ion_handle_create under mutex_lock to avoid this race.
>>
>> WARNING: CPU: 2 PID: 2648 at drivers/staging/android/ion/ion.c:512
>> ion_handle_add+0xb4/0xc0()
>> ion_handle_add: buffer already found.
>> Modules linked in: iwlmvm iwlwifi mac80211 cfg80211 compat
>> CPU: 2 PID: 2648 Comm: TimedEventQueue Tainted: GW3.14.0 #7
>> 9a3efd2c 80faf273 9a3efd6c 9a3efd5c 80935dc9 811d7fd3
>> 9a3efd88 0a58 812208a0 0200 80e128d4 80e128d4 8d4ae00c a8cd8600
>> a8cd8094 9a3efd74 80935e0e 0009 9a3efd6c 811d7fd3 9a3efd88 9a3efd9c
>> Call Trace:
>>[<80faf273>] dump_stack+0x48/0x69
>>[<80935dc9>] warn_slowpath_common+0x79/0x90
>>[<80e128d4>] ? ion_handle_add+0xb4/0xc0
>>[<80e128d4>] ? ion_handle_add+0xb4/0xc0
>>[<80935e0e>] warn_slowpath_fmt+0x2e/0x30
>>[<80e128d4>] ion_handle_add+0xb4/0xc0
>>[<80e144cc>] ion_import_dma_buf+0x8c/0x110
>>[<80c517c4>] reg_init+0x364/0x7d0
>>[<80993363>] ? futex_wait+0x123/0x210
>>[<80992e0e>] ? get_futex_key+0x16e/0x1e0
>>[<8099308f>] ? futex_wake+0x5f/0x120
>>[<80c51e19>] vpu_service_ioctl+0x1e9/0x500
>>[<80994aec>] ? do_futex+0xec/0x8e0
>>[<80971080>] ? prepare_to_wait_event+0xc0/0xc0
>>[<80c51c30>] ? reg_init+0x7d0/0x7d0
>>[<80a22562>] do_vfs_ioctl+0x2d2/0x4c0
>>[<80b198ad>] ? inode_has_perm.isra.41+0x2d/0x40
>>[<80b199cf>] ? file_has_perm+0x7f/0x90
>>[<80b1a5f7>] ? selinux_file_ioctl+0x47/0xf0
>>[<80a227a8>] SyS_ioctl+0x58/0x80
>>[<80fb45e8>] syscall_call+0x7/0x7
>>[<80fb>] ? mmc_do_calc_max_discard+0xab/0xe4
>>
>> Fixes: 83271f626 ("ion: hold reference to handle...")
>> Signed-off-by: Shawn Lin
>> ---
>>
>> drivers/staging/android/ion/ion.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index eec878e..32e7b5c 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -1179,13 +1179,13 @@ struct ion_handle *ion_import_dma_buf(struct
>> ion_client *client, int fd)
>> mutex_unlock(&client->lock);
>> goto end;
>> }
>> - mutex_unlock(&client->lock);
>>
>> handle = ion_handle_create(client, buffer);
>> - if (IS_ERR(handle))
>> + if (IS_ERR(handle)) {
>> + mutex_unlock(&client->lock);
>> goto end;
>> + }
>>
>> - mutex_lock(&client->lock);
>> ret = ion_handle_add(client, handle);
>> mutex_unlock(&client->lock);
>> if (ret) {
>>
>
> So the patch looks correct but the locking change there seems like it was
> added
> deliberately. Colin/John, do you remember why the locking for
> ion_import_dma_buf
> changed? Was there a deadlock condition somewhere?
>
> Thanks,
> Laura
I can't see any reason to not hold the mutex across ion_handle_create.
The patch that introduced the bug
(83271f6262c91a49df325c52bec8f00f4de294ca, ion: hold reference to
handle after ion_uhandle_get) required that the mutex not be held
around the call to ion_handle_put, but didn't affect
ion_handle_create.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] Staging: rtl8192u: r8192U_core.c: Replace "#include " with "#include "
On Thu, Sep 10, 2015 at 10:44:17AM +0530, Shraddha Barke wrote: > Oops! Should I send a version 2 of the series dropping this patch? Not required. I hope Greg will see these 3 mails and will not try to apply this patch. But just to be safe reply to the patch asking Greg not to apply that particular patch. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zram: introduce comp algorithm fallback functionality
Hello, On (09/10/15 14:03), Minchan Kim wrote: [..] > > I guess most of scripts have checked result of his doing so if we > removes it, it will break them. to be honest, we never documented or required any of those. the only source of information for the user space -- zram.txt documentation -- simply says to do 'echo 3 > /sys/block/zram0/max_comp_streams' or any other bunch of 'echo'-s. so, technically, a user is free to simply copy-paste what we do in zram.txt to his zram.sh and call it a "recommended way of doing things in zram". besides, zram.txt is outdated. for example there is no mem_used_max documentation. we need to do better job documenting. I'll try to take a look on this later this week. > Given that, every success of "echo zzz > /sys/block/zram0/comp_algorithm" > makes users to be confused that he might think to success to change algorithm > in runtime. IOW, it should return error which is more intuitive forme. well, not quite like that. we return -EINVAL on invalid output since d93435c3fba4a47b773693b0c8992470d38510d5. this patch does not change anything from this pov. it does, however, change the behaviour of disksize store that follows. I'm fine when the motivation for this patch is to introduce the "fallback" mechanism (like zswap fallbacks to default compressor, f.e.), but it wasn't the case -- I rewrote the patch slightly, reworded the commit message and put some reasoning to this patch. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [COMMERCIAL] Re: [PATCH 0/3] kobject: support namespace aware udev
On Wed, Sep 09, 2015 at 04:55:22PM -0400, Michael J Coss wrote: > On 9/9/2015 4:28 PM, Greg KH wrote: > > On Wed, Sep 09, 2015 at 04:16:49PM -0400, Michael J Coss wrote: > >> On 9/9/2015 4:09 PM, Greg KH wrote: > >>> On Wed, Sep 09, 2015 at 03:05:29PM -0400, Michael J Coss wrote: > On 9/8/2015 11:54 PM, Greg KH wrote: > > On Tue, Sep 08, 2015 at 10:10:27PM -0400, Michael J. Coss wrote: > >> Currently when a uevent occurs, the event is replicated and sent to > >> every > >> listener on the kernel netlink socket, ignoring network namespaces > >> boundaries, > >> forwarding events to every listener in every network namespace. > >> > >> With the expanded use of containers, it would be useful to be able to > >> regulate this flow of events to specific containers. By restricting > >> the events to only the host network namespace, it allows for a > >> userspace > >> program to provide a system wide policy on which events are routed > >> where. > > Interesting, but why do you need a container to get a uevent at all? > > What uevents do a container care about? > > > > thanks, > > > > greg k-h > > > In our use case, we run a full desktop inside the container, including > X. > >>> Ugh, I was worried you were going to say that :( > >>> > We run the Xserver in headless mode, and forward a uevent to the > container to allow binding/unbinding of remote keyboard, mice, and > displays. So I want the add/del keyboard events, add/del mouse events, > and add/del display events. This is just one use case, I could image > others. The bottom line is that the current behavior is to broadcast to > everyone all uevents, and I don't see that as correct as it crosses the > network namespace boundaries. It seems to me that you would want to > provide controls as to where you want to forward those uevents, and > that is not a policy that I believe should be in the kernel but rather > in user space. > >>> devices are not in namespaces, which is why we don't partition them off > >>> at all. And that's why I really don't want to add this type of > >>> filtering either. It's up to the "master" container/process/whatever to > >>> send uevents to child containers if it really wants to. If we were to > >>> ever have devices bound only to namespaces, then it would make sense to > >>> only send the uevents for those devices to that namespace. > >>> > >>> But as that's never going to happen, I don't want to give people a false > >>> sense of "separation" here that isn't really there at all. > >>> > >>> sorry, > >>> > >>> greg k-h > >>> > >> Agreed that devices are not in namespaces, but the events are, or at > >> least could be. > > No, there's no way to tell which event for which device goes to which > > namespace, as devices are not in a namespace. > Why? The host certainly can have a policy for what devices go to which > container. But that's a userspace thing, if at all, not a kernel thing. > And as such knows which events goes to which container. Userspace might know this, sure, so implement a version of udevd that does this all in userspace. > The container *is* a set on namespace, and control groups. But devices are not. They are global for the whole kernel. > So a user program reads the events on the master, looks in a database > and forwards it to that container. The uevents represent the device > add/del so it seems natural that it should be the mechanism by which > that communication happens. I just want to see it controlled by a > policy on the host. Then do so all in userspace, don't try to force namespaces on devices in the kernel that do not have them at all. You are adding code that is "pretending" that devices really are in namespaces, which is not true at all. > >> That master is the host, and to do that I want to > >> forward events that the host receives to those individual containers. > >> But since the kernel is broadcasting them, I can't have that policy on > >> the host, and would have to filter on each container. Or I can do as > >> you say and have the master forward events. I don't see this as putting > >> the devices into a namespace, but rather managing devices from the > >> outside and notifying the container of the event. Just like plugging in > >> a monitor to the container. > > But you can't "plug a monitor into a container". Nor can you "add a > > keyboard to a container". Or a tty device. Or anything else (except > > for network devices). Don't try to fake things out as that's not what > > is happening here. The kernel shouldn't be allowing things to be sent > > only to specific namespaces, as that's a lie, the devices are "global" > > and not in a namespace at all. > Again why? Why are network devices *different*? They just are :) Really, the layers behind a network device are set up for namespaces, and multiple processes access
Re: [PATCH 4/5] Staging: rtl8192u: r8192U_core.c: Replace "#include " with "#include "
On Thu, Sep 10, 2015 at 09:03:00AM +0530, Shraddha Barke wrote:
> Fix checkpatch.pl warning "Use #include
> instead of "
>
> Signed-off-by: Shraddha Barke
> ---
This has already been done by:
f05937c591aa ("staging: rtl8192u: r8192U_core: include linux/uaccess.h instead
of asm/uaccess.h")
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ipv6: fix ifnullfree.cocci warnings
On 9/9/15, 3:57 PM, kbuild test robot wrote: net/ipv6/route.c:2946:3-8: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values. NULL check before some freeing functions is not needed. Based on checkpatch warning "kfree(NULL) is safe this check is probably not required" and kfreeaddr.cocci by Julia Lawall. Generated by: scripts/coccinelle/free/ifnullfree.cocci CC: Roopa Prabhu Signed-off-by: Fengguang Wu FWIW, Acked-by: Roopa Prabhu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zram: introduce comp algorithm fallback functionality
On Tue, Sep 08, 2015 at 07:42:56PM +0100, Luis Henriques wrote: > When the user supplies an unsupported compression algorithm, keep the > previously selected one (knowingly supported) or the default one (if the > compression algorithm hasn't been changed yet). > > Note that previously this operation (i.e. setting an invalid algorithm) > would result in no algorithm being selected, which means that this > represents a small change in the default behaviour. It seems it is hard for Andrew to parse so I will add more. Before) # echo "super-lz4" > /sys/block/zram0/comp_algorithm bash: echo: write error: Invalid argument # echo $((200<<20)) > /sys/block/zram0/disksize bash: echo: write error: Invalid argument # dmesg | grep zram .. zram: Cannot initialise super-lz4 compressing backend # cat /sys/block/zram0/initstate 0 # cat /sys/block/zram0/comp_algorithm lzo lz4 After) # echo "super-lz4" > /sys/block/zram0/comp_algorithm bash: echo: write error: Invalid argument # echo $((200<<20)) > /sys/block/zram0/disksize # dmesg | grep zram root@bboxv:/home/barrios# dmesg | grep zram .. zram0: detected capacity change from 0 to 209715200 # cat /sys/block/zram0/initstate 1 # cat /sys/block/zram0/comp_algorithm [lzo] lz4 IOW, with the patch, if user pass a unsupported algorithm, zram will be initialized with default compressor while we didn't allow it old. As Sergey pointed out, it changes zRAM ABI slightly so if someone doesn't have checked result of algorithm selection but go with that to initialize, it could be initialized with default compressor rather than failing. Although it might be regression, I want to correct it in this chance. For initializing zram, there are some preparation steps but they are *optional* steps. Must step is only 'disksize setting' now. It means you could initialize zram with below one line enoughly. # echo $((200<<20)) > /sys/block/zram0/disksize If you feed woring input, it could be ignored and initialized with default values for optional parameters. # echo "aaa" > /sys/block/zram0/max_comp_streams bash: echo: write error: Invalid argument # echo $((200<<20)) > /sys/block/zram0/disksize # cat /sys/block/zram0/initstate 1 # cat /sys/block/zram0/max_comp_streams 1 Another example, # echo "aaa" > /sys/block/zram0/mem_limit bash: echo: write error: Invalid argument # echo $((200<<20)) > /sys/block/zram0/disksize # cat /sys/block/zram0/initstate 1 # cat /sys/block/zram0/mem_limit 0 But now only one exception with comp_algorithm. # echo "super-lz4" > /sys/block/zram0/comp_algorithm bash: echo: write error: Invalid argument # echo $((200<<20)) > /sys/block/zram0/disksize bash: echo: write error: Invalid argument # cat /sys/block/zram0/initstate 0 Why should we handle comp_algorithm is so special? With another approach: We could remove every error return code for all optional steps so user never fails to set option to zram and check them only where MUST step(ie, disksize set). It could be doable but the problem is as follows, 1. It makes hard for user to understand why it was failed. Only thing kernel can return is -EINVAL, I think. What is invalid? algorithm? mem_limit? streams? Maybe we should export some message via dmesg so user should rely on it. But dmesg should be just helper, not ABI. 2. It would break more scripts. IOW, ABI regression would be more severe. I guess most of scripts have checked result of his doing so if we removes it, it will break them. 3. Weired interface Although we could change ABI of optional parameters into no failure smoothly without no regressoin, it looks like strange. Currently, comp_algorithm couldn't be changed in runtime, at least. Given that, every success of "echo zzz > /sys/block/zram0/comp_algorithm" makes users to be confused that he might think to success to change algorithm in runtime. IOW, it should return error which is more intuitive forme. That's why I support this patch. Acked-by: Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch/microblaze changes for 4.3-rc1
Hi Linus, please pull this one patch to your tree. I have rebased the branch because there was a conflict with "tile: enable full SECCOMP support" (sha1: a0ddef81f4ac3326f6b6a255d8ea13b41908). Thanks, Michal The following changes since commit b8889c4fc6ba03e289cec6a4d692f6f080a55e53: Merge tag 'tty-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty (2015-09-09 11:27:01 -0700) are available in the git repository at: git://git.monstr.eu/linux-2.6-microblaze.git next for you to fetch changes up to b14132797d8041a42e03f4ffa1e722da1425adfb: elf-em.h: move EM_MICROBLAZE to the common header (2015-09-10 06:54:15 +0200) Mike Frysinger (1): elf-em.h: move EM_MICROBLAZE to the common header arch/microblaze/include/uapi/asm/elf.h | 3 ++- include/uapi/linux/elf-em.h| 1 + 2 files changed, 3 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Re: [PATCH v2 1/5] perf probe: Split add_perf_probe_events()
>From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim > >On Sun, Sep 06, 2015 at 03:47:37PM +0800, Wangnan (F) wrote: >> Hi Namhyung, > >Hi, > >> >> Thanks for this patchset. >> >> Could you plase have a look at patch 5/27 and 6/27 in my newest pull >> request? >> These 2 patches utilize new probing API to create probe point and collect >> probe_trace_events. I'm not very sure I fully understand your design >> principle, >> especially the cleanup part, because I can see different functions dealing >> with >> cleanup: >> >> cleanup_perf_probe_events This is for clearing an array of probe events. >> del_perf_probe_events This is not for cleanup, but for removing probes in the kernel. >> clear_perf_probe_event >> clear_probe_trace_event These are the cleanup each event. Ah, right, since now perf_probe_event has probe_trace_events, clear_perf_probe_event has to call clear_probe_trace_event. >> >> But non of them works perfectly for me. > >The cleanup_perf_probe_events() is just to keep the existing logic as >long as possible. But I think it needs to call >clear_perf_probe_event(). > >The del_perf_probe_events() uses strfilter, but I think it can be >problematic if other instances or users are using similar events at >the same time. Yeah, since perf probe doesn't lock the ftrace, there should be a timing bug, but it can be fixed easily by ignoring -ENOENT. :) >So for your case, IMHO it'd better keeping the perf/trace events after >probing and reusing the events for unprobing. I'll take a look at it. > > >> >> In bpf_prog_priv__clear() function of 6/27, I copied some code from >> cleanup_perf_probe_events(), because I think when destroying bpf programs, >> the probe_trace_events should also be cleanuped, but we don't need call >> exit_symbol_maps() many times, because we are in 'perf record', and not >> sure whether other parts of perf need symbol maps. Otherwise I think >> directly >> calling cleanup_perf_probe_events() sould be better. > >Yeah, I also think exit_symbol_maps() should not be a part of the >cleanup. I'll send a patch soon. OK. Thanks!
[PATCHv3 1/1] ti-soc-thermal: implement omap3 support
From: Pavel Machek
This adds support for OMAP3 chips to ti-soc-thermal. As requested by
TI people, it is marked unreliable and warning is printed.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Pavel Machek
Signed-off-by: Eduardo Valentin
---
.../devicetree/bindings/thermal/ti_soc_thermal.txt | 7 ++
drivers/thermal/ti-soc-thermal/Kconfig | 15 +++
drivers/thermal/ti-soc-thermal/Makefile| 1 +
.../thermal/ti-soc-thermal/omap3-thermal-data.c| 103 +
drivers/thermal/ti-soc-thermal/ti-bandgap.c| 10 ++
drivers/thermal/ti-soc-thermal/ti-bandgap.h| 9 ++
6 files changed, 145 insertions(+)
create mode 100644 drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
---
Just not leave Pavels work behind, I took his patch and amended a couple
of things:
(1) added the omap3 DT example
(2) improved the dev_warn message
(3) improved the code documentation
diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
index 0c9222d..d9a1b54 100644
--- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
@@ -10,6 +10,7 @@ to the silicon temperature.
Required properties:
- compatible : Should be:
+ - "ti,omap34xx-bandgap" : for OMAP34xx bandgap
- "ti,omap4430-bandgap" : for OMAP4430 bandgap
- "ti,omap4460-bandgap" : for OMAP4460 bandgap
- "ti,omap4470-bandgap" : for OMAP4470 bandgap
@@ -25,6 +26,12 @@ to each bandgap version, because the mapping may change from
soc to soc, apart of depending on available features.
Example:
+OMAP34xx:
+bandgap {
+ reg = <0x48002524 0x4>;
+ compatible = "ti,omap34xx-bandgap";
+};
+
OMAP4430:
bandgap {
reg = <0x4a002260 0x4 0x4a00232C 0x4>;
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig
b/drivers/thermal/ti-soc-thermal/Kconfig
index cb6686f..ea8283f 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -19,6 +19,21 @@ config TI_THERMAL
This includes trip points definitions, extrapolation rules and
CPU cooling device bindings.
+config OMAP3_THERMAL
+ bool "Texas Instruments OMAP3 thermal support"
+ depends on TI_SOC_THERMAL
+ depends on ARCH_OMAP3 || COMPILE_TEST
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP3 SoC family. The current chips supported are:
+ - OMAP3430
+
+ OMAP3 chips normally don't need thermal management, and sensors in
+ this generation are not accurate, nor they are very close to
+ the important hotspots.
+
+ Say 'N' here.
+
config OMAP4_THERMAL
bool "Texas Instruments OMAP4 thermal support"
depends on TI_SOC_THERMAL
diff --git a/drivers/thermal/ti-soc-thermal/Makefile
b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..0f89bdf 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal.o
ti-soc-thermal-y := ti-bandgap.o
ti-soc-thermal-$(CONFIG_TI_THERMAL)+= ti-thermal-common.o
ti-soc-thermal-$(CONFIG_DRA752_THERMAL)+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL) += omap3-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 000..8470225
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,103 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ * Note
+ * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
+ * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used"
+ *
+ * Also TI says:
+ * Just be careful when you try to make thermal policy like decisions
+ * based on this sensor. Placement of the sensor w.r.t the actual logic
+ * generating heat has to be a factor as well. If you are just looking
+ * for an approximation temperature (thermometerish kind), you might be
+ * ok with this. I am not sure we'd find any TI data around this.. just a
+ *
Re: [PATCH 3/3] staging: fbtft: use pr_fmt
On Wed, Sep 09, 2015 at 11:20:08PM +0200, Noralf Trønnes wrote: > > Den 09.09.2015 20:35, skrev Greg Kroah-Hartman: > >On Sat, Sep 05, 2015 at 07:13:45PM +0530, Sudip Mukherjee wrote: > >>Instead of defining DRVNAME and using it in all calls to pr_* family of > >>macros lets start using pr_fmt. > >> > >>Signed-off-by: Sudip Mukherjee > >>--- > >> drivers/staging/fbtft/fbtft_device.c | 79 > >> > >> 1 file changed, 35 insertions(+), 44 deletions(-) > > [...] > > >If a driver is working properly, nothing should show up in the kernel > >log at all, otherwise it's just noise that everyone ignores. > > This isn't a device driver, it's a module for adding "fbtft" devices > (spi/platform with pdata). When I created fbtft, the Raspberry Pi didn't > have Device Tree support, so I made this module as a way for the end user > to add devices without having to build a kernel. > I haven't seen any module like this in the kernel, so maybe it > really doesn't > belong here at all? Is this driver only for Raspberry Pi? I have seen someone submitted a drm driver for Raspberry Pi. And I guess that is already merged. Tomi (fbdev maintainer) said "Fremebuffer driver will be obsolete immediately when there's a DRM driver for that device". And if a drm driver is already there for Raspberry Pi then ? regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ether: add IEEE 1722 ethertype - TSN
From: Henrik Austad
Date: Wed, 9 Sep 2015 11:26:32 +0200
> IEEE 1722 describes AVB (later renamed to TSN - Time Sensitive
> Networking), a protocol, encapsualtion and synchronization to utilize
> standard networks for audio/video (and later other time-sensitive)
> streams.
>
> This standard uses ethertype 0x22F0.
>
> http://standards.ieee.org/develop/regauth/ethertype/eth.txt
>
> This is a respin of a previous patch ("ether: add AVB frame type
> ETH_P_AVB")
>
> CC: "David S. Miller"
> CC: net...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Henrik Austad
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] perf,x86: Fix event/group validation
Ping?
On 08/21/2015 04:31 PM, Sasha Levin wrote:
> On 05/21/2015 07:17 AM, Peter Zijlstra wrote:
>> --- a/arch/x86/kernel/cpu/perf_event_intel.c
>> +++ b/arch/x86/kernel/cpu/perf_event_intel.c
>> @@ -2106,7 +2106,7 @@ static struct event_constraint *
>> intel_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
>> struct perf_event *event)
>> {
>> -struct event_constraint *c1 = event->hw.constraint;
>> +struct event_constraint *c1 = cpuc->event_constraint[idx];
>> struct event_constraint *c2;
>
> Hey Peter,
>
> I was chasing a memory corruption in this area and I think I found
> a possible culprit:
>
> After this patch, In the code above, we'd access "cpuc->event_constraint[idx]"
> and read/change memory.
>
> The problem is that a valid value for idx is also -1, which isn't checked
> here, so we end up accessing and possibly corrupting memory that isn't ours.
>
>
> Thanks,
> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/17] staging: sm750fb: rename swI2CInit to sm750_sw_i2c_init
On Wed, Sep 09, 2015 at 01:07:04PM -0700, Greg Kroah-Hartman wrote: > On Wed, Sep 09, 2015 at 11:03:20PM +0300, Mike Rapoport wrote: > > On Wed, Sep 09, 2015 at 11:41:20AM -0700, Greg Kroah-Hartman wrote: > > > On Sun, Sep 06, 2015 at 09:17:56AM +0300, Mike Rapoport wrote: > > > > Fix the checkpatch warning about CamelCase. > > > > > > > > Signed-off-by: Mike Rapoport > > > > --- > > > > drivers/staging/sm750fb/ddk750_sii164.c | 2 +- > > > > drivers/staging/sm750fb/ddk750_swi2c.c | 2 +- > > > > drivers/staging/sm750fb/ddk750_swi2c.h | 2 +- > > > > drivers/staging/sm750fb/sm750_hw.c | 2 +- > > > > 4 files changed, 4 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/staging/sm750fb/ddk750_sii164.c > > > > b/drivers/staging/sm750fb/ddk750_sii164.c > > > > index 3d129aa..241b77b 100644 > > > > --- a/drivers/staging/sm750fb/ddk750_sii164.c > > > > +++ b/drivers/staging/sm750fb/ddk750_sii164.c > > > > @@ -132,7 +132,7 @@ long sii164InitChip( > > > > /* Use fast mode. */ > > > > sm750_hw_i2c_init(1); > > > > #else > > > > - swI2CInit(DEFAULT_I2C_SCL, DEFAULT_I2C_SDA); > > > > + sm750_sw_i2c_init(DEFAULT_I2C_SCL, DEFAULT_I2C_SDA); > > > > > > Hm, wait, "sw_"? what is the difference between the hw and sw versions? > > > > As far as I understood, the intention for HW is for using i2c > > controller, and SW is for using gpio bit-bang > > big-bang i2c? ick. :( Yes, there is a special version of SM750 which uses sw i2c. SM750LE is a special version which only Huawei uses. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Incorrect key code parsing in dell-wmi.c since 5ea2559
On Sat, Jul 04, 2015 at 07:06:48PM +0200, Pali Rohár wrote: > Hello, > > I found another problem in dell-wmi.c code which is still partially in > mainline kernel since commit 5ea2559726b786283236835dc2905c23b36ac91c: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5ea2559726b786283236835dc2905c23b36ac91c > > === > commit 5ea2559726b786283236835dc2905c23b36ac91c > Author: Rezwanul Kabir > Date: Mon Nov 2 12:00:42 2009 -0500 > > dell-wmi: Add support for new Dell systems > > Newer Dell systems support HotKey features differently from legacy > systems. A new vendor specifc HotKey SMBIOS table (Type 0xB2) is > defined. This table contains a mapping between scancode and the > corresponding predefined keyfunction ( i.e. keycode).. Also, a new > ACPI-WMI event type (called KeyIDList) with a value of 0x0010 is > defined. Any BIOS containing 0xB2 table will send hotkey notifications > using KeyIDList event. > > This is Rezwanul's patch, updated to ensure that brightness events are > not sent if the backlight is controlled via ACPI and with the default > keycode for the display output switching altered to match desktop > expectations. > > Signed-off-by: Rezwanul Kabir > Signed-off-by: Matthew Garrett > Signed-off-by: Len Brown > === > > Before this commit WMI event buffer was parsed as: > > int *buffer = (int *)obj->buffer.pointer; > key = dell_wmi_get_entry_by_scancode(buffer[1] & 0x); > > So basically 4th-7th bytes are parsed. > > After this commit WMI event buffer is parsed as: > > u16 *buffer_entry = (u16 *)obj->buffer.pointer; > reported_key = (int)buffer_entry[1] & 0x; > key = dell_wmi_get_entry_by_scancode(reported_key); > > Which means that 2nd and 3rd bytes are parsed. > > Apparently this commit changed what kernel parse as keycode. And I bet > this is some copy-paste error and not correct code. Variable buffer was > changed from (int*) to (u16*) and which change could be "hidden" at time > of code review. > > Next there is commit which somehow is trying to fix user problems: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d5164dbf1f651d1e955b158fb70a9c844cc91cd1 > > === > commit d5164dbf1f651d1e955b158fb70a9c844cc91cd1 > Author: Islam Amer > Date: Thu Jun 24 13:39:47 2010 -0400 > > dell-wmi: Add support for eject key on Dell Studio 1555 > > Fixes pressing the eject key on Dell Studio 1555 does not work and > produces > message : > > dell-wmi: Unknown key 0 pressed > > Signed-off-by: Islam Amer > === > > It changes parsing WMI event buffer to: > > u16 *buffer_entry = (u16 *)obj->buffer.pointer; > if (buffer_entry[1] == 0x0) > reported_key = (int)buffer_entry[2] & 0x; > else > reported_key = (int)buffer_entry[1] & 0x; > key = dell_wmi_get_entry_by_scancode(reported_key); > > My idea is that Islam Amer tried to fix problem introduced in commit > 5ea2559726b786283236835dc2905c23b36ac91c. > > According to some available very-very old Dell ACPI-WMI documentation at > > http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf > > and also from information from commit message 5ea2559 format of WMI is > (u16*)[length, type, data, ...]. > > Because type for hotkey is 0x then it expected that kernel reported > always key 0x... > > So I would propose to drop parsing "buffer_entry[1]" as key code and > rewrite dell_wmi_notify function to always process WMI buffer as > [length, type, data...]. > > What do you think about it? It also simplify notify code as there is one > branch for dell_new_hk_type and one for old parsing (with that entry[1]). > Without documentation for the older as well as newer laptops, it's possible the driver evolved to support newer ones while breaking older models. As you mentioned to me, getting some current documentation would be ideal. Without it, the best approach is a functional patch which we can ask users to help us test. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/7] x86, acpi, cpu-hotplug: Introduce apicid_to_cpuid[] array to store persistent cpuid <-> apicid mapping.
From: Gu Zheng
This patch finishes step2 mentioned in previous patch 4.
In this patch, we introduce a new static array named apicid_to_cpuid[],
which is large enough to store info for all possible cpus.
And then, we modify the cpuid calculation. In generic_processor_info(),
it simply finds the next unused cpuid. And it is also why the cpuid <-> nodeid
mapping changes with node hotplug.
After this patch, we find the next unused cpuid, map it to an apicid,
and store the mapping in apicid_to_cpuid[], so that cpuid <-> apicid
mapping will be persistent.
And finally we will use this array to make cpuid <-> nodeid persistent.
cpuid <-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/x86/include/asm/mpspec.h | 1 +
arch/x86/kernel/acpi/boot.c | 6 ++---
arch/x86/kernel/apic/apic.c | 53 ---
3 files changed, 53 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index b07233b..db902d8 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -86,6 +86,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
#endif
int generic_processor_info(int apicid, int version);
+int __generic_processor_info(int apicid, int version, bool enabled);
#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_LOCAL_APIC)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e49ee24..bcc85b2 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -174,15 +174,13 @@ static int acpi_register_lapic(int id, u8 enabled)
return -EINVAL;
}
- if (!enabled) {
+ if (!enabled)
++disabled_cpus;
- return -EINVAL;
- }
if (boot_cpu_physical_apicid != -1U)
ver = apic_version[boot_cpu_physical_apicid];
- return generic_processor_info(id, ver);
+ return __generic_processor_info(id, ver, enabled);
}
static int __init
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index a9c9830..42b2a9c 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1977,7 +1977,45 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
-static int __generic_processor_info(int apicid, int version, bool enabled)
+/*
+ * Current allocated max logical CPU ID plus 1.
+ * All allocated CPU ID should be in [0, max_logical_cpuid),
+ * so the maximum of max_logical_cpuid is nr_cpu_ids.
+ *
+ * NOTE: Reserve 0 for BSP.
+ */
+static int max_logical_cpuid = 1;
+
+static int cpuid_to_apicid[] = {
+ [0 ... NR_CPUS - 1] = -1,
+};
+
+static int allocate_logical_cpuid(int apicid)
+{
+ int i;
+
+ /*
+* cpuid <-> apicid mapping is persistent, so when a cpu is up,
+* check if the kernel has allocated a cpuid for it.
+*/
+ for (i = 0; i < max_logical_cpuid; i++) {
+ if (cpuid_to_apicid[i] == apicid)
+ return i;
+ }
+
+ /* Allocate a new cpuid. */
+ if (max_logical_cpuid >= nr_cpu_ids) {
+ WARN_ONCE(1, "Only %d processors supported."
+"Processor %d/0x%x and the rest are ignored.\n",
+nr_cpu_ids - 1, max_logical_cpuid, apicid);
+ return -1;
+ }
+
+ cpuid_to_apicid[max_logical_cpuid] = apicid;
+ return max_logical_cpuid++;
+}
+
+int __generic_processor_info(int apicid, int version, bool enabled)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
@@ -2058,8 +2096,17 @@ static int __generic_processor_info(int apicid, int
version, bool enabled)
* for BSP.
*/
cpu = 0;
- } else
- cpu = cpumask_next_zero(-1, cpu_present_mask);
+
+ /* Logical cpuid 0 is reserved for BSP. */
+ cpuid_to_apicid[0] = apicid;
+ } else {
+ cpu = allocate_logical_cpuid(apicid);
+ if (cpu < 0) {
+ if (enabled)
+ disabled_cpus++;
+ return -EINVAL;
+ }
+ }
/*
* Validate version
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/7] x86, gfp: Cache best near node for memory allocation.
From: Gu Zheng
In the current kernel, all possible cpus are mapped to the best near online
node if they reside in a memory-less node in init_cpu_to_node().
init_cpu_to_node()
{
..
for_each_possible_cpu(cpu) {
..
if (!node_online(node))
node = find_near_online_node(node);
numa_set_node(cpu, node);
}
}
The reason for doing this is to prevent memory allocation failure if the
cpu is online but there is no memory on that node.
But since cpuid <-> nodeid mapping is planed to be made static, doing
so in initialization pharse makes no sense any more.
The best near online node for each cpu has been cached in an array in previous
patch. And the reason for doing this is to avoid mapping CPUs on memory-less
nodes to other nodes.
So in this patch, we get best near online node for CPUs on memory-less nodes
inside alloc_pages_node() and alloc_pages_exact_node() to avoid memory
allocation
failure.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/x86/mm/numa.c | 3 +--
include/linux/gfp.h | 8 +++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 8bd7661..e89b9fb 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -151,6 +151,7 @@ void numa_set_node(int cpu, int node)
return;
}
#endif
+
per_cpu(x86_cpu_to_node_map, cpu) = node;
set_near_online_node(node);
@@ -787,8 +788,6 @@ void __init init_cpu_to_node(void)
if (node == NUMA_NO_NODE)
continue;
- if (!node_online(node))
- node = find_near_online_node(node);
numa_set_node(cpu, node);
}
}
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index ad35f30..1a1324f 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -307,13 +307,19 @@ static inline struct page *alloc_pages_node(int nid,
gfp_t gfp_mask,
if (nid < 0)
nid = numa_node_id();
+ if (!node_online(nid))
+ nid = get_near_online_node(nid);
+
return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
}
static inline struct page *alloc_pages_exact_node(int nid, gfp_t gfp_mask,
unsigned int order)
{
- VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
+ VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
+
+ if (!node_online(nid))
+ nid = get_near_online_node(nid);
return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/7] x86, numa: Introduce a node to node array to map a node to its best online node.
The whole patch-set aims at solving this problem:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.
So here is the problem:
Assume we have the following cpuid <-> nodeid in the beginning:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119
and we hot-remove node2 and node3, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
and we hot-add node4 and node5, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119
But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs){
...
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {
if (cpumask_subset(pool->attrs->cpumask,
wq_numa_possible_cpumask[node])) {
pool->node = node;
break;
}
}
}
Since wq_numa_possible_cpumask is not updated, it could be mapped to an offline
node,
which will lead to memory allocation failure:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
It happens here:
create_worker(struct worker_pool *pool)
|--> worker = alloc_worker(pool->node);
static struct worker *alloc_worker(int node)
{
struct worker *worker;
worker = kzalloc_node(sizeof(*worker), GFP_KERNEL, node); --> Here,
useing the wrong node.
..
return worker;
}
[Solution]
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <->
apicid
mapping. So the key point is obtaining all cpus' apicid.
apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
MADT (Multiple APIC Description Table). So we finish the job in the following
steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
This is done by introducing an extra parameter to generic_processor_info to
let the
caller control if disabled cpus are ignored.
2. Introduce a new array storing all possible cpuid <-> apicid mapping. And
also modify
the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping
when
registering local apic. Store the mapping in this array.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
But before that, we should make memory allocators be able to get best near
online node
at any time, because if node hotplug happens, the best near online node will
change.
In current kernel, CPUs on a memory-less node are all mapped to its best online
node to ensure the memory allocation on these CPUs successful. This is done
outside alloc_pa
[PATCH v2 4/7] x86, acpi, cpu-hotplug: Enable acpi to register all possible cpus at boot time.
From: Gu Zheng
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.
So here is the problem:
Assume we have the following cpuid <-> nodeid in the beginning:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119
and we hot-remove node2 and node3, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
and we hot-add node4 and node5, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119
But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs){
...
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {
if (cpumask_subset(pool->attrs->cpumask,
wq_numa_possible_cpumask[node])) {
pool->node = node;
break;
}
}
}
Since wq_numa_possible_cpumask is not updated, it could be mapped to an offline
node,
which will lead to memory allocation failure:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
It happens here:
create_worker(struct worker_pool *pool)
|--> worker = alloc_worker(pool->node);
static struct worker *alloc_worker(int node)
{
struct worker *worker;
worker = kzalloc_node(sizeof(*worker), GFP_KERNEL, node); --> Here,
useing the wrong node.
..
return worker;
}
[Solution]
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <->
apicid
mapping. So the key point is obtaining all cpus' apicid.
apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
MADT (Multiple APIC Description Table). So we finish the job in the following
steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
This is done by introducing an extra parameter to generic_processor_info to
let the
caller control if disabled cpus are ignored.
2. Introduce a new array storing all possible cpuid <-> apicid mapping. And
also modify
the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping
when
registering local apic. Store the mapping in this array.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished step 1.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/x86/kernel/apic/apic.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index dcb5285..a9c9830 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1977,7 +1977
[PATCH v2 1/7] x86, numa: Move definition of find_near_online_node() forward.
Will call this function earlier in next coming patches.
So simply move its definition forward. And also, add comments for it.
Signed-off-by: Tang Chen
---
arch/x86/mm/numa.c | 47 +--
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 4053bb5..fea387a 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -78,6 +78,35 @@ EXPORT_SYMBOL(node_to_cpumask_map);
DEFINE_EARLY_PER_CPU(int, x86_cpu_to_node_map, NUMA_NO_NODE);
EXPORT_EARLY_PER_CPU_SYMBOL(x86_cpu_to_node_map);
+/**
+ * find_near_online_node - Find the best near online node of a node.
+ * @node: NUMA node ID of the current node.
+ *
+ * Find the best near online node of @node, based on node_distance[] array.
+ * The best near online node is the backup node for memory allocation on
+ * one node.
+ *
+ * RETURNS:
+ * The best near online node ID on success, -1 on failure.
+ */
+static __init int find_near_online_node(int node)
+{
+ int n, val;
+ int min_val = INT_MAX;
+ int near_node = -1;
+
+ for_each_online_node(n) {
+ val = node_distance(node, n);
+
+ if (val < min_val) {
+ min_val = val;
+ near_node = n;
+ }
+ }
+
+ return near_node;
+}
+
void numa_set_node(int cpu, int node)
{
int *cpu_to_node_map = early_per_cpu_ptr(x86_cpu_to_node_map);
@@ -702,24 +731,6 @@ void __init x86_numa_init(void)
numa_init(dummy_numa_init);
}
-static __init int find_near_online_node(int node)
-{
- int n, val;
- int min_val = INT_MAX;
- int best_node = -1;
-
- for_each_online_node(n) {
- val = node_distance(node, n);
-
- if (val < min_val) {
- min_val = val;
- best_node = n;
- }
- }
-
- return best_node;
-}
-
/*
* Setup early cpu_to_node.
*
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/7] x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid.
From: Gu Zheng
This patch finishes step3 mentioned in previous patch 4.
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
So, in order to setup persistent cpuid <-> nodeid mapping for all possible CPUs,
we should:
1. Setup cpuid <-> apicid mapping for all possible CPUs, which has been done in
patch 4.
2. Setup cpuid <-> nodeid mapping for all possible CPUs. But before that, we
should
obtain all apicids from MADT.
All processors' apicids can be obtained by _MAT method or from MADT in ACPI.
The current code ignores disabled processors and returns -ENODEV.
After this patch, a new parameter will be added to MADT APIs so that caller
is able to control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40 insertions(+), 22 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 92a5f73..2deade1 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -282,8 +282,11 @@ static int acpi_processor_get_info(struct acpi_device
*device)
* Extra Processor objects may be enumerated on MP systems with
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
+*
+* NOTE: Even if the processor has a cpuid, it may be not present
+* because cpuid <-> apicid mapping is persistent.
*/
- if (invalid_logical_cpuid(pr->id)) {
+ if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
int ret = acpi_processor_hotadd_init(pr);
if (ret)
return ret;
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 33a38d6..824b98b 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -32,12 +32,12 @@ static struct acpi_table_madt *get_madt_table(void)
}
static int map_lapic_id(struct acpi_subtable_header *entry,
-u32 acpi_id, phys_cpuid_t *apic_id)
+u32 acpi_id, phys_cpuid_t *apic_id, bool ignore_disabled)
{
struct acpi_madt_local_apic *lapic =
container_of(entry, struct acpi_madt_local_apic, header);
- if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(lapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (lapic->processor_id != acpi_id)
@@ -48,12 +48,13 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
}
static int map_x2apic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
+ bool ignore_disabled)
{
struct acpi_madt_local_x2apic *apic =
container_of(entry, struct acpi_madt_local_x2apic, header);
- if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(apic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration && (apic->uid == acpi_id)) {
@@ -65,12 +66,13 @@ static int map_x2apic_id(struct acpi_subtable_header *entry,
}
static int map_lsapic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
+ bool ignore_disabled)
{
struct acpi_madt_local_sapic *lsapic =
container_of(entry, struct acpi_madt_local_sapic, header);
- if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(lsapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration) {
@@ -87,12 +89,13 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
* Retrieve the ARM CPU physical identifier (MPIDR)
*/
static int map_gicc_mpidr(struct acpi_subtable_header *entry,
-
[PATCH v2 7/7] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting.
From: Gu Zheng
This patch finishes step4 mentioned in previous patch 4.
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
So, in order to setup persistent cpuid <-> nodeid mapping for all possible CPUs,
we should:
1. Setup cpuid <-> apicid mapping for all possible CPUs, which has been done in
patch 4.
2. Setup cpuid <-> nodeid mapping for all possible CPUs.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/ia64/kernel/acpi.c | 2 +-
arch/x86/kernel/acpi/boot.c | 2 +-
drivers/acpi/bus.c| 3 ++
drivers/acpi/processor_core.c | 65 +++
include/linux/acpi.h | 2 ++
5 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index b1698bc..7db5563 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -796,7 +796,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
* ACPI based hotplug CPU support
*/
#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
/*
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index bcc85b2..b9a1aa1 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -695,7 +695,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 513e7230e..fd03885 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -700,6 +700,9 @@ static int __init acpi_init(void)
acpi_debugfs_init();
acpi_sleep_proc_init();
acpi_wakeup_device_init();
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+ acpi_set_processor_mapping();
+#endif
return 0;
}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 824b98b..45580ff 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -261,6 +261,71 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static bool map_processor(acpi_handle handle, int *phys_id, int *cpuid)
+{
+ int type;
+ u32 acpi_id;
+ acpi_status status;
+ acpi_object_type acpi_type;
+ unsigned long long tmp;
+ union acpi_object object = { 0 };
+ struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
+
+ status = acpi_get_type(handle, &acpi_type);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ switch (acpi_type) {
+ case ACPI_TYPE_PROCESSOR:
+ status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = object.processor.proc_id;
+ break;
+ case ACPI_TYPE_DEVICE:
+ status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = tmp;
+ break;
+ default:
+ return false;
+ }
+
+ type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
+
+ *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false);
+ *cpuid = acpi_map_cpuid(*phys_id, acpi_id);
+ if (*cpuid == -1)
+ return false;
+
+ return true;
+}
+
+static acpi_status __init
+set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context,
+ void **rv)
+{
+ u32 apic_id;
+ int cpu_id;
+
+ if (!map_processor(handle, &apic_id, &cpu_id))
+ return AE_ERROR;
+
+
[PATCH v2 0/7] Make cpuid <-> nodeid mapping persistent.
The whole patch-set aims at solving this problem:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.
So here is the problem:
Assume we have the following cpuid <-> nodeid in the beginning:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119
and we hot-remove node2 and node3, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
and we hot-add node4 and node5, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119
But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs){
...
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {
if (cpumask_subset(pool->attrs->cpumask,
wq_numa_possible_cpumask[node])) {
pool->node = node;
break;
}
}
}
Since wq_numa_possible_cpumask is not updated, it could be mapped to an offline
node,
which will lead to memory allocation failure:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
It happens here:
create_worker(struct worker_pool *pool)
|--> worker = alloc_worker(pool->node);
static struct worker *alloc_worker(int node)
{
struct worker *worker;
worker = kzalloc_node(sizeof(*worker), GFP_KERNEL, node); --> Here,
useing the wrong node.
..
return worker;
}
[Solution]
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <->
apicid
mapping. So the key point is obtaining all cpus' apicid.
apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
MADT (Multiple APIC Description Table). So we finish the job in the following
steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
This is done by introducing an extra parameter to generic_processor_info to
let the
caller control if disabled cpus are ignored.
2. Introduce a new array storing all possible cpuid <-> apicid mapping. And
also modify
the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping
when
registering local apic. Store the mapping in this array.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
Patch 1 ~ 3 are some prepare works.
Patch 4 ~ 7 finishes the 4 steps above.
For previous discussion, please refer to:
https://lkml.org/lkml/2015/2/27/145
https://lkml.org/lkml/2015/3/25/989
https://lkml.org/lkml/2015/5/14/244
https://lkml.org/lkml/2015/7/7/200
Change log v1 -> v2:
1. Split code movement and actual changes. Add patch 1.
2.
Re: [PATCH 6/6] Staging: iio: resolver: Prefer using the BIT macro
On Thu, 2015-09-10 at 09:43 +0530, Shraddha Barke wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro > as it's extensively used by other function in this driver. [] > diff --git a/drivers/staging/iio/resolver/ad2s1210.c > b/drivers/staging/iio/resolver/ad2s1210.c [] > @@ -149,7 +149,7 @@ int ad2s1210_update_frequency_control_word(struct > ad2s1210_state *st) > int ret; > unsigned char fcw; > > - fcw = (unsigned char)(st->fexcit * (1 << 15) / st->fclkin); > + fcw = (unsigned char)(st->fexcit * BIT(15) / st->fclkin); Multiplying by a bit isn't very obvious. Maybe just shift it. fcw = (unsigned char)((st->fexcit << 15) / st->fclkin); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/17] thermal: spear: allow compile test
On Thu, Sep 10, 2015 at 9:40 AM, Eduardo Valentin wrote: > Adding COMPILE_TEST flag to spear driver to facilitate > maintenance. > > Cc: Zhang Rui > Cc: linux...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Eduardo Valentin > --- > drivers/thermal/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index f2b1d31..0334886 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -182,7 +182,7 @@ config IMX_THERMAL > > config SPEAR_THERMAL > bool "SPEAr thermal sensor driver" > - depends on PLAT_SPEAR > + depends on PLAT_SPEAR || COMPILE_TEST > depends on OF > help > Enable this to plug the SPEAr thermal sensor driver into the Linux Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
We Give Out Loans For 3% Interest Rate And We Offer Loans From $5,000 To $50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A Truck Company or Buy A Truck Or Personal Loans, Email Us At j.funds2000...@inbox.lv With Amount Needed And Phone Number. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clocksource: exynos_mct: use container_of() instead of this_cpu_ptr()
On 04.09.2015 08:49, Alexey Klimov wrote:
> Since evt structure is embedded in per-CPU mevt structure it's
> definitely faster to use container_of() to get access to mevt
> if we have evt (for example as incoming function argument) instead
> of more expensive approach with this_cpu_ptr(&percpu_mct_tick).
> this_cpu_ptr() on per-CPU mevt structure leads to access to cp15
> to get cpu id and arithmetic operations.
> Container_of() is cheaper since it's just one asm instruction.
> This should work if used evt pointer is correct and owned by
> local mevt structure.
>
> For example, before this patch set_state_shutdown() looks like:
>
> 4a4: e92d4010push{r4, lr}
> 4a8: e3004000movwr4, #0
> 4ac: ebfebl 0
> 4b0: e3003000movwr3, #0
> 4b4: e3404000movtr4, #0
> 4b8: e3403000movtr3, #0
> 4bc: e7933100ldr r3, [r3, r0, lsl #2]
> 4c0: e0844003add r4, r4, r3
> 4c4: e59400c0ldr r0, [r4, #192] ; 0xc0
> 4c8: ebd4bl 420
> 4cc: e3a0mov r0, #0
> 4d0: e8bd8010pop {r4, pc}
>
> With this patch:
>
> 4a4: e92d4010push{r4, lr}
> 4a8: e59000c0ldr r0, [r0, #192] ; 0xc0
> 4ac: ebdbbl 420
> 4b0: e3a0mov r0, #0
> 4b4: e8bd8010pop {r4, pc}
>
> Also, for me size of exynos_mct.o decreased from 84588 bytes
> to 83956.
>
> Signed-off-by: Alexey Klimov
> ---
> drivers/clocksource/exynos_mct.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
Looks good and sensible. Why you called this RFC? You are not sure if
this is correct?
One minor nit-pick below, but I am fine without it anyway:
Reviewed-by: Krzysztof Kozlowski
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index 029f96a..ff44082 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -382,24 +382,28 @@ static void exynos4_mct_tick_start(unsigned long cycles,
> static int exynos4_tick_set_next_event(unsigned long cycles,
> struct clock_event_device *evt)
> {
> - struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
> + struct mct_clock_event_device *mevt;
>
> + mevt = container_of(evt, struct mct_clock_event_device, evt);
> exynos4_mct_tick_start(cycles, mevt);
> -
Actually I would prefer leaving the empty line here and add such in
function below. For me the code is more readable with
ending return separated by one line.
Best regards,
Krzysztof
> return 0;
> }
>
> static int set_state_shutdown(struct clock_event_device *evt)
> {
> - exynos4_mct_tick_stop(this_cpu_ptr(&percpu_mct_tick));
> + struct mct_clock_event_device *mevt;
> +
> + mevt = container_of(evt, struct mct_clock_event_device, evt);
> + exynos4_mct_tick_stop(mevt);
> return 0;
> }
>
> static int set_state_periodic(struct clock_event_device *evt)
> {
> - struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
> + struct mct_clock_event_device *mevt;
> unsigned long cycles_per_jiffy;
>
> + mevt = container_of(evt, struct mct_clock_event_device, evt);
> cycles_per_jiffy = (((unsigned long long)NSEC_PER_SEC / HZ * evt->mult)
> >> evt->shift);
> exynos4_mct_tick_stop(mevt);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal: ti-soc: Kconfig fix to avoid menu showing wrongly
Move the dependencies to menu, so we avoid showing it wrongly. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig| 1 + drivers/thermal/ti-soc-thermal/Kconfig | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) --- This depends on the compile test series. diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index a752bef..c5eb142 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -341,6 +341,7 @@ config ACPI_THERMAL_REL depends on ACPI menu "Texas Instruments thermal drivers" +depends on ARCH_HAS_BANDGAP || COMPILE_TEST source "drivers/thermal/ti-soc-thermal/Kconfig" endmenu diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig index 7a24018..cb6686f 100644 --- a/drivers/thermal/ti-soc-thermal/Kconfig +++ b/drivers/thermal/ti-soc-thermal/Kconfig @@ -1,7 +1,5 @@ config TI_SOC_THERMAL tristate "Texas Instruments SoCs temperature sensor driver" - depends on THERMAL - depends on ARCH_HAS_BANDGAP || COMPILE_TEST help If you say yes here you get support for the Texas Instruments OMAP4460+ on die bandgap temperature sensor support. The register -- 2.5.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 01/17] thermal: hisi: allow compile test
Adding COMPILE_TEST flag to hisi driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 118938e..f2b1d31 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -163,7 +163,7 @@ config THERMAL_EMULATION config HISI_THERMAL tristate "Hisilicon thermal driver" - depends on ARCH_HISI && CPU_THERMAL && OF + depends on (ARCH_HISI && CPU_THERMAL && OF) || COMPILE_TEST help Enable this to plug hisilicon's thermal sensor driver into the Linux thermal framework. cpufreq is used as the cooling device to throttle -- 2.5.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 04/17] thermal: kirkwood: allow compile test
Adding COMPILE_TEST flag to kirkwood driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 2e0aaee..f1da24e 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -208,7 +208,7 @@ config RCAR_THERMAL config KIRKWOOD_THERMAL tristate "Temperature sensor on Marvell Kirkwood SoCs" - depends on MACH_KIRKWOOD + depends on MACH_KIRKWOOD || COMPILE_TEST depends on OF help Support for the Kirkwood thermal sensor driver into the Linux thermal -- 2.5.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 03/17] thermal: rockchip: allow compile test
Adding COMPILE_TEST flag to rockchip driver to facilitate maintenance. Cc: Zhang Rui Cc: Heiko Stuebner Cc: linux...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-rockc...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 0334886..2e0aaee 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -190,7 +190,7 @@ config SPEAR_THERMAL config ROCKCHIP_THERMAL tristate "Rockchip thermal driver" - depends on ARCH_ROCKCHIP + depends on ARCH_ROCKCHIP || COMPILE_TEST depends on RESET_CONTROLLER help Rockchip thermal driver provides support for Temperature sensor -- 2.5.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 05/17] thermal: dove: allow compile test
Adding COMPILE_TEST flag to dove driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index f1da24e..b38ce41 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -216,7 +216,7 @@ config KIRKWOOD_THERMAL config DOVE_THERMAL tristate "Temperature sensor on Marvell Dove SoCs" - depends on ARCH_DOVE || MACH_DOVE + depends on ARCH_DOVE || MACH_DOVE || COMPILE_TEST depends on OF help Support for the Dove thermal sensor driver in the Linux thermal -- 2.5.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 07/17] thermal: armada: allow compile test
Adding COMPILE_TEST flag to armada driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index f810bad..0e0d0de 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -234,7 +234,7 @@ config DB8500_THERMAL config ARMADA_THERMAL tristate "Armada 370/XP thermal management" - depends on ARCH_MVEBU + depends on ARCH_MVEBU || COMPILE_TEST depends on OF help Enable this option if you want to have support for thermal management -- 2.5.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 09/17] thermal: powerclamp: allow compile test
Adding COMPILE_TEST flag to powerclamp driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index c94efd3..449508f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -264,7 +264,7 @@ config DB8500_CPUFREQ_COOLING config INTEL_POWERCLAMP tristate "Intel PowerClamp idle injection driver" depends on THERMAL - depends on X86 + depends on X86 || COMPILE_TEST depends on CPU_SUP_INTEL help Enable this to enable Intel PowerClamp idle injection driver. This -- 2.5.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 10/17] thermal: intel_soc_dts_iosf: allow compile test
Adding COMPILE_TEST flag to intel_soc_dts_iosf driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 449508f..eb2978d 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -284,7 +284,7 @@ config X86_PKG_TEMP_THERMAL config INTEL_SOC_DTS_IOSF_CORE tristate - depends on X86 + depends on X86 || COMPILE_TEST select IOSF_MBI help This is becoming a common feature for Intel SoCs to expose the additional -- 2.5.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 06/17] thermal: u8500: allow compile test
Adding COMPILE_TEST flag to u8500 driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index b38ce41..f810bad 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -224,7 +224,7 @@ config DOVE_THERMAL config DB8500_THERMAL bool "DB8500 thermal management" - depends on ARCH_U8500 + depends on ARCH_U8500 || COMPILE_TEST default y help Adds DB8500 thermal management implementation according to the thermal @@ -252,7 +252,7 @@ config TEGRA_SOCTHERM config DB8500_CPUFREQ_COOLING tristate "DB8500 cpufreq cooling" - depends on ARCH_U8500 + depends on ARCH_U8500 || COMPILE_TEST depends on CPU_THERMAL default y help -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] Staging: iio: meter: Prefer using the BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro as it's extensively used by other function in this driver. This was done with coccinelle: @@ int g; @@ -(1 << g) +BIT(g) Signed-off-by: Shraddha Barke --- drivers/staging/iio/meter/ade7753.c | 8 drivers/staging/iio/meter/ade7754.c | 6 +++--- drivers/staging/iio/meter/ade7758_core.c | 6 +++--- drivers/staging/iio/meter/ade7759.c | 8 drivers/staging/iio/meter/ade7854.c | 6 +++--- 5 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/staging/iio/meter/ade7753.c b/drivers/staging/iio/meter/ade7753.c index ffc7f0d..3d2e50c 100644 --- a/drivers/staging/iio/meter/ade7753.c +++ b/drivers/staging/iio/meter/ade7753.c @@ -219,7 +219,7 @@ static int ade7753_reset(struct device *dev) u16 val; ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val); - val |= 1 << 6; /* Software Chip Reset */ + val |= BIT(6); /* Software Chip Reset */ return ade7753_spi_write_reg_16(dev, ADE7753_MODE, val); } @@ -328,10 +328,10 @@ static int ade7753_set_irq(struct device *dev, bool enable) goto error_ret; if (enable) - irqen |= 1 << 3; /* Enables an interrupt when a data is + irqen |= BIT(3); /* Enables an interrupt when a data is present in the waveform register */ else - irqen &= ~(1 << 3); + irqen &= ~BIT(3); ret = ade7753_spi_write_reg_8(dev, ADE7753_IRQEN, irqen); @@ -345,7 +345,7 @@ static int ade7753_stop_device(struct device *dev) u16 val; ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val); - val |= 1 << 4; /* AD converters can be turned off */ + val |= BIT(4); /* AD converters can be turned off */ return ade7753_spi_write_reg_16(dev, ADE7753_MODE, val); } diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c index f12b2e5..8552c76 100644 --- a/drivers/staging/iio/meter/ade7754.c +++ b/drivers/staging/iio/meter/ade7754.c @@ -223,7 +223,7 @@ static int ade7754_reset(struct device *dev) if (ret < 0) return ret; - val |= 1 << 6; /* Software Chip Reset */ + val |= BIT(6); /* Software Chip Reset */ return ade7754_spi_write_reg_8(dev, ADE7754_OPMODE, val); } @@ -350,10 +350,10 @@ static int ade7754_set_irq(struct device *dev, bool enable) goto error_ret; if (enable) - irqen |= 1 << 14; /* Enables an interrupt when a data is + irqen |= BIT(14); /* Enables an interrupt when a data is present in the waveform register */ else - irqen &= ~(1 << 14); + irqen &= ~BIT(14); ret = ade7754_spi_write_reg_16(dev, ADE7754_IRQEN, irqen); if (ret) diff --git a/drivers/staging/iio/meter/ade7758_core.c b/drivers/staging/iio/meter/ade7758_core.c index 77141ae..3883808 100644 --- a/drivers/staging/iio/meter/ade7758_core.c +++ b/drivers/staging/iio/meter/ade7758_core.c @@ -308,7 +308,7 @@ static int ade7758_reset(struct device *dev) dev_err(dev, "Failed to read opmode reg\n"); return ret; } - val |= 1 << 6; /* Software Chip Reset */ + val |= BIT(6); /* Software Chip Reset */ ret = ade7758_spi_write_reg_8(dev, ADE7758_OPMODE, val); if (ret < 0) dev_err(dev, "Failed to write opmode reg\n"); @@ -426,10 +426,10 @@ int ade7758_set_irq(struct device *dev, bool enable) goto error_ret; if (enable) - irqen |= 1 << 16; /* Enables an interrupt when a data is + irqen |= BIT(16); /* Enables an interrupt when a data is present in the waveform register */ else - irqen &= ~(1 << 16); + irqen &= ~BIT(16); ret = ade7758_spi_write_reg_24(dev, ADE7758_MASK, irqen); if (ret) diff --git a/drivers/staging/iio/meter/ade7759.c b/drivers/staging/iio/meter/ade7759.c index dbceda1..23e7392 100644 --- a/drivers/staging/iio/meter/ade7759.c +++ b/drivers/staging/iio/meter/ade7759.c @@ -224,7 +224,7 @@ static int ade7759_reset(struct device *dev) if (ret < 0) return ret; - val |= 1 << 6; /* Software Chip Reset */ + val |= BIT(6); /* Software Chip Reset */ return ade7759_spi_write_reg_16(dev, ADE7759_MODE, val); @@ -288,10 +288,10 @@ static int ade7759_set_irq(struct device *dev, bool enable) goto error_ret; if (enable) - irqen |= 1 << 3; /* Enables an interrupt when a data is + irqen |= BIT(3); /* Enables an interrupt when a data is present in the waveform register */ else - irqen &= ~(1 << 3); +
[PATCH 4/6] Staging: iio: cdc: ad7746.c: Prefer using the BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro as it's extensively used by other function in this driver. This was done with coccinelle: @@ int g; @@ -(1 << g) +BIT(g) Signed-off-by: Shraddha Barke --- drivers/staging/iio/cdc/ad7746.c | 42 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c index e6e9eaa..e17d4e1 100644 --- a/drivers/staging/iio/cdc/ad7746.c +++ b/drivers/staging/iio/cdc/ad7746.c @@ -46,48 +46,48 @@ #define AD7746_REG_VOLT_GAINL 18 /* Status Register Bit Designations (AD7746_REG_STATUS) */ -#define AD7746_STATUS_EXCERR (1 << 3) -#define AD7746_STATUS_RDY (1 << 2) -#define AD7746_STATUS_RDYVT(1 << 1) -#define AD7746_STATUS_RDYCAP (1 << 0) +#define AD7746_STATUS_EXCERR BIT(3) +#define AD7746_STATUS_RDY BIT(2) +#define AD7746_STATUS_RDYVTBIT(1) +#define AD7746_STATUS_RDYCAP BIT(0) /* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) */ -#define AD7746_CAPSETUP_CAPEN (1 << 7) -#define AD7746_CAPSETUP_CIN2 (1 << 6) /* AD7746 only */ -#define AD7746_CAPSETUP_CAPDIFF(1 << 5) -#define AD7746_CAPSETUP_CACHOP (1 << 0) +#define AD7746_CAPSETUP_CAPEN BIT(7) +#define AD7746_CAPSETUP_CIN2 BIT(6) /* AD7746 only */ +#define AD7746_CAPSETUP_CAPDIFFBIT(5) +#define AD7746_CAPSETUP_CACHOP BIT(0) /* Voltage/Temperature Setup Register Bit Designations (AD7746_REG_VT_SETUP) */ -#define AD7746_VTSETUP_VTEN(1 << 7) +#define AD7746_VTSETUP_VTENBIT(7) #define AD7746_VTSETUP_VTMD_INT_TEMP (0 << 5) -#define AD7746_VTSETUP_VTMD_EXT_TEMP (1 << 5) +#define AD7746_VTSETUP_VTMD_EXT_TEMP BIT(5) #define AD7746_VTSETUP_VTMD_VDD_MON(2 << 5) #define AD7746_VTSETUP_VTMD_EXT_VIN(3 << 5) -#define AD7746_VTSETUP_EXTREF (1 << 4) -#define AD7746_VTSETUP_VTSHORT (1 << 1) -#define AD7746_VTSETUP_VTCHOP (1 << 0) +#define AD7746_VTSETUP_EXTREF BIT(4) +#define AD7746_VTSETUP_VTSHORT BIT(1) +#define AD7746_VTSETUP_VTCHOP BIT(0) /* Excitation Setup Register Bit Designations (AD7746_REG_EXC_SETUP) */ -#define AD7746_EXCSETUP_CLKCTRL(1 << 7) -#define AD7746_EXCSETUP_EXCON (1 << 6) -#define AD7746_EXCSETUP_EXCB (1 << 5) -#define AD7746_EXCSETUP_NEXCB (1 << 4) -#define AD7746_EXCSETUP_EXCA (1 << 3) -#define AD7746_EXCSETUP_NEXCA (1 << 2) +#define AD7746_EXCSETUP_CLKCTRLBIT(7) +#define AD7746_EXCSETUP_EXCON BIT(6) +#define AD7746_EXCSETUP_EXCB BIT(5) +#define AD7746_EXCSETUP_NEXCB BIT(4) +#define AD7746_EXCSETUP_EXCA BIT(3) +#define AD7746_EXCSETUP_NEXCA BIT(2) #define AD7746_EXCSETUP_EXCLVL(x) (((x) & 0x3) << 0) /* Config Register Bit Designations (AD7746_REG_CFG) */ #define AD7746_CONF_VTFS(x)((x) << 6) #define AD7746_CONF_CAPFS(x) ((x) << 3) #define AD7746_CONF_MODE_IDLE (0 << 0) -#define AD7746_CONF_MODE_CONT_CONV (1 << 0) +#define AD7746_CONF_MODE_CONT_CONV BIT(0) #define AD7746_CONF_MODE_SINGLE_CONV (2 << 0) #define AD7746_CONF_MODE_PWRDN (3 << 0) #define AD7746_CONF_MODE_OFFS_CAL (5 << 0) #define AD7746_CONF_MODE_GAIN_CAL (6 << 0) /* CAPDAC Register Bit Designations (AD7746_REG_CAPDACx) */ -#define AD7746_CAPDAC_DACEN(1 << 7) +#define AD7746_CAPDAC_DACENBIT(7) #define AD7746_CAPDAC_DACP(x) ((x) & 0x7F) /* -- 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 1/6] Staging: iio: addac: adt7316.c : Prefer using BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro as it's extensively used by other function in this driver. This was done with coccinelle: @@ int g; @@ -(1 << g) +BIT(g) Signed-off-by: Shraddha Barke --- drivers/staging/iio/addac/adt7316.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/staging/iio/addac/adt7316.c b/drivers/staging/iio/addac/adt7316.c index 5b11b42..a1dd745 100644 --- a/drivers/staging/iio/addac/adt7316.c +++ b/drivers/staging/iio/addac/adt7316.c @@ -1756,43 +1756,43 @@ static irqreturn_t adt7316_event_handler(int irq, void *private) stat1 &= 0x1F; time = iio_get_time_ns(); - if (stat1 & (1 << 0)) + if (stat1 & BIT(0)) iio_push_event(indio_dev, IIO_UNMOD_EVENT_CODE(IIO_TEMP, 0, IIO_EV_TYPE_THRESH, IIO_EV_DIR_RISING), time); - if (stat1 & (1 << 1)) + if (stat1 & BIT(1)) iio_push_event(indio_dev, IIO_UNMOD_EVENT_CODE(IIO_TEMP, 0, IIO_EV_TYPE_THRESH, IIO_EV_DIR_FALLING), time); - if (stat1 & (1 << 2)) + if (stat1 & BIT(2)) iio_push_event(indio_dev, IIO_UNMOD_EVENT_CODE(IIO_TEMP, 1, IIO_EV_TYPE_THRESH, IIO_EV_DIR_RISING), time); - if (stat1 & (1 << 3)) + if (stat1 & BIT(3)) iio_push_event(indio_dev, IIO_UNMOD_EVENT_CODE(IIO_TEMP, 1, IIO_EV_TYPE_THRESH, IIO_EV_DIR_FALLING), time); - if (stat1 & (1 << 5)) + if (stat1 & BIT(5)) iio_push_event(indio_dev, IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 1, IIO_EV_TYPE_THRESH, IIO_EV_DIR_EITHER), time); - if (stat1 & (1 << 6)) + if (stat1 & BIT(6)) iio_push_event(indio_dev, IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 2, IIO_EV_TYPE_THRESH, IIO_EV_DIR_EITHER), time); - if (stat1 & (1 << 7)) + if (stat1 & BIT(7)) iio_push_event(indio_dev, IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 3, IIO_EV_TYPE_THRESH, -- 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 5/6] Staging: iio: impedance-analyzer: Prefer using the BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro
as it's extensively used by other function in this driver.
This was done with coccinelle:
@@ int g; @@
-(1 << g)
+BIT(g)
Signed-off-by: Shraddha Barke
---
drivers/staging/iio/impedance-analyzer/ad5933.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
b/drivers/staging/iio/impedance-analyzer/ad5933.c
index c18109c..48acad0 100644
--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
+++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
@@ -39,7 +39,7 @@
#define AD5933_REG_IMAG_DATA 0x96/* R, 2 bytes*/
/* AD5933_REG_CONTROL_HB Bits */
-#define AD5933_CTRL_INIT_START_FREQ(0x1 << 4)
+#define AD5933_CTRL_INIT_START_FREQBIT(4)
#define AD5933_CTRL_START_SWEEP(0x2 << 4)
#define AD5933_CTRL_INC_FREQ (0x3 << 4)
#define AD5933_CTRL_REPEAT_FREQ(0x4 << 4)
@@ -48,23 +48,23 @@
#define AD5933_CTRL_STANDBY(0xB << 4)
#define AD5933_CTRL_RANGE_2000mVpp (0x0 << 1)
-#define AD5933_CTRL_RANGE_200mVpp (0x1 << 1)
+#define AD5933_CTRL_RANGE_200mVpp BIT(1)
#define AD5933_CTRL_RANGE_400mVpp (0x2 << 1)
#define AD5933_CTRL_RANGE_1000mVpp (0x3 << 1)
#define AD5933_CTRL_RANGE(x) ((x) << 1)
-#define AD5933_CTRL_PGA_GAIN_1 (0x1 << 0)
+#define AD5933_CTRL_PGA_GAIN_1 BIT(0)
#define AD5933_CTRL_PGA_GAIN_5 (0x0 << 0)
/* AD5933_REG_CONTROL_LB Bits */
-#define AD5933_CTRL_RESET (0x1 << 4)
+#define AD5933_CTRL_RESET BIT(4)
#define AD5933_CTRL_INT_SYSCLK (0x0 << 3)
-#define AD5933_CTRL_EXT_SYSCLK (0x1 << 3)
+#define AD5933_CTRL_EXT_SYSCLK BIT(3)
/* AD5933_REG_STATUS Bits */
-#define AD5933_STAT_TEMP_VALID (0x1 << 0)
-#define AD5933_STAT_DATA_VALID (0x1 << 1)
-#define AD5933_STAT_SWEEP_DONE (0x1 << 2)
+#define AD5933_STAT_TEMP_VALID BIT(0)
+#define AD5933_STAT_DATA_VALID BIT(1)
+#define AD5933_STAT_SWEEP_DONE BIT(2)
/* I2C Block Commands */
#define AD5933_I2C_BLOCK_WRITE 0xA0
@@ -222,7 +222,7 @@ static int ad5933_set_freq(struct ad5933_state *st,
u8 d8[4];
} dat;
- freqreg = (u64) freq * (u64) (1 << 27);
+ freqreg = (u64) freq * (u64) BIT(27);
do_div(freqreg, st->mclk_hz / 4);
switch (reg) {
@@ -308,7 +308,7 @@ static ssize_t ad5933_show_frequency(struct device *dev,
freqreg = be32_to_cpu(dat.d32) & 0xFF;
freqreg = (u64) freqreg * (u64) (st->mclk_hz / 4);
- do_div(freqreg, 1 << 27);
+ do_div(freqreg, BIT(27));
return sprintf(buf, "%d\n", (int) freqreg);
}
@@ -437,7 +437,7 @@ static ssize_t ad5933_store(struct device *dev,
/* 2x, 4x handling, see datasheet */
if (val > 511)
- val = (val >> 1) | (1 << 9);
+ val = (val >> 1) | BIT(9);
else if (val > 1022)
val = (val >> 2) | (3 << 9);
--
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 2/6] Staging: iio: cdc: ad7152.c: Prefer using the BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro as it's extensively used by other function in this driver. This was done with coccinelle: @@ int g; @@ -(1 << g) +BIT(g) Signed-off-by: Shraddha Barke --- drivers/staging/iio/cdc/ad7152.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/staging/iio/cdc/ad7152.c b/drivers/staging/iio/cdc/ad7152.c index 87110d9..ba44c0e 100644 --- a/drivers/staging/iio/cdc/ad7152.c +++ b/drivers/staging/iio/cdc/ad7152.c @@ -41,30 +41,30 @@ #define AD7152_REG_CFG226 /* Status Register Bit Designations (AD7152_REG_STATUS) */ -#define AD7152_STATUS_RDY1 (1 << 0) -#define AD7152_STATUS_RDY2 (1 << 1) -#define AD7152_STATUS_C1C2 (1 << 2) -#define AD7152_STATUS_PWDN (1 << 7) +#define AD7152_STATUS_RDY1 BIT(0) +#define AD7152_STATUS_RDY2 BIT(1) +#define AD7152_STATUS_C1C2 BIT(2) +#define AD7152_STATUS_PWDN BIT(7) /* Setup Register Bit Designations (AD7152_REG_CHx_SETUP) */ -#define AD7152_SETUP_CAPDIFF (1 << 5) +#define AD7152_SETUP_CAPDIFF BIT(5) #define AD7152_SETUP_RANGE_2pF (0 << 6) -#define AD7152_SETUP_RANGE_0_5pF (1 << 6) +#define AD7152_SETUP_RANGE_0_5pF BIT(6) #define AD7152_SETUP_RANGE_1pF (2 << 6) #define AD7152_SETUP_RANGE_4pF (3 << 6) #define AD7152_SETUP_RANGE(x) ((x) << 6) /* Config Register Bit Designations (AD7152_REG_CFG) */ -#define AD7152_CONF_CH2EN (1 << 3) -#define AD7152_CONF_CH1EN (1 << 4) +#define AD7152_CONF_CH2EN BIT(3) +#define AD7152_CONF_CH1EN BIT(4) #define AD7152_CONF_MODE_IDLE (0 << 0) -#define AD7152_CONF_MODE_CONT_CONV (1 << 0) +#define AD7152_CONF_MODE_CONT_CONV BIT(0) #define AD7152_CONF_MODE_SINGLE_CONV (2 << 0) #define AD7152_CONF_MODE_OFFS_CAL (5 << 0) #define AD7152_CONF_MODE_GAIN_CAL (6 << 0) /* Capdac Register Bit Designations (AD7152_REG_CAPDAC_XXX) */ -#define AD7152_CAPDAC_DACEN(1 << 7) +#define AD7152_CAPDAC_DACENBIT(7) #define AD7152_CAPDAC_DACP(x) ((x) & 0x1F) /* CFG2 Register Bit Designations (AD7152_REG_CFG2) */ -- 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 6/6] Staging: iio: resolver: Prefer using the BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro
as it's extensively used by other function in this driver.
This was done with coccinelle:
@@ int g; @@
-(1 << g)
+BIT(g)
Signed-off-by: Shraddha Barke
---
drivers/staging/iio/resolver/ad2s1210.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/resolver/ad2s1210.c
b/drivers/staging/iio/resolver/ad2s1210.c
index 7bc3e4a..1cf7134 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -149,7 +149,7 @@ int ad2s1210_update_frequency_control_word(struct
ad2s1210_state *st)
int ret;
unsigned char fcw;
- fcw = (unsigned char)(st->fexcit * (1 << 15) / st->fclkin);
+ fcw = (unsigned char)(st->fexcit * BIT(15) / st->fclkin);
if (fcw < AD2S1210_MIN_FCW || fcw > AD2S1210_MAX_FCW) {
dev_err(&st->sdev->dev, "ad2s1210: FCW out of range\n");
return -ERANGE;
--
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 11/17] thermal: intel_soc_dts: allow compile test
Adding COMPILE_TEST flag to intel_soc_dts driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index eb2978d..027b662 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -294,7 +294,7 @@ config INTEL_SOC_DTS_IOSF_CORE config INTEL_SOC_DTS_THERMAL tristate "Intel SoCs DTS thermal driver" - depends on X86 + depends on X86 || COMPILE_TEST select INTEL_SOC_DTS_IOSF_CORE help Enable this to register Intel SoCs (e.g. Bay Trail) platform digital -- 2.5.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 13/17] thermal: int340x: allow compile test
Adding COMPILE_TEST flag to int340x driver to facilitate maintenance. Cc: Zhang Rui Cc: Srinivas Pandruvada Cc: Jacob Pan Cc: "lan,Tianyu" Cc: Ilkka Koskinen Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index d0ff238..0fa5d20 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -317,7 +317,7 @@ config INTEL_QUARK_DTS_THERMAL config INT340X_THERMAL tristate "ACPI INT340X thermal drivers" - depends on X86 && ACPI + depends on (X86 && ACPI) || COMPILE_TEST select THERMAL_GOV_USER_SPACE select ACPI_THERMAL_REL select ACPI_FAN -- 2.5.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 12/17] thermal: intel_quark: allow compile test
Adding COMPILE_TEST flag to intel_quark driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 027b662..d0ff238 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -307,7 +307,7 @@ config INTEL_SOC_DTS_THERMAL config INTEL_QUARK_DTS_THERMAL tristate "Intel Quark DTS thermal driver" - depends on X86_INTEL_QUARK + depends on X86_INTEL_QUARK || COMPILE_TEST help Enable this to register Intel Quark SoC (e.g. X1000) platform digital temperature sensor (DTS). For X1000 SoC, it has one on-die DTS. -- 2.5.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 14/17] thermal: exynos: allow compile test
Adding COMPILE_TEST flag to exynos driver to facilitate maintenance. Cc: Lukasz Majewski Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 0fa5d20..9069cc7 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -345,7 +345,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig" endmenu menu "Samsung thermal drivers" -depends on ARCH_EXYNOS +depends on ARCH_EXYNOS || COMPILE_TEST source "drivers/thermal/samsung/Kconfig" endmenu -- 2.5.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 17/17] thermal: ti-soc: allow compile test
Adding COMPILE_TEST flag to ti-soc driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/ti-soc-thermal/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig index bd4c7be..7a24018 100644 --- a/drivers/thermal/ti-soc-thermal/Kconfig +++ b/drivers/thermal/ti-soc-thermal/Kconfig @@ -1,7 +1,7 @@ config TI_SOC_THERMAL tristate "Texas Instruments SoCs temperature sensor driver" depends on THERMAL - depends on ARCH_HAS_BANDGAP + depends on ARCH_HAS_BANDGAP || COMPILE_TEST help If you say yes here you get support for the Texas Instruments OMAP4460+ on die bandgap temperature sensor support. The register @@ -24,7 +24,7 @@ config TI_THERMAL config OMAP4_THERMAL bool "Texas Instruments OMAP4 thermal support" depends on TI_SOC_THERMAL - depends on ARCH_OMAP4 + depends on ARCH_OMAP4 || COMPILE_TEST help If you say yes here you get thermal support for the Texas Instruments OMAP4 SoC family. The current chip supported are: @@ -38,7 +38,7 @@ config OMAP4_THERMAL config OMAP5_THERMAL bool "Texas Instruments OMAP5 thermal support" depends on TI_SOC_THERMAL - depends on SOC_OMAP5 + depends on SOC_OMAP5 || COMPILE_TEST help If you say yes here you get thermal support for the Texas Instruments OMAP5 SoC family. The current chip supported are: @@ -50,7 +50,7 @@ config OMAP5_THERMAL config DRA752_THERMAL bool "Texas Instruments DRA752 thermal support" depends on TI_SOC_THERMAL - depends on SOC_DRA7XX + depends on SOC_DRA7XX || COMPILE_TEST help If you say yes here you get thermal support for the Texas Instruments DRA752 SoC family. The current chip supported are: -- 2.5.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 15/17] thermal: st: allow compile test
Adding COMPILE_TEST flag to st driver to facilitate maintenance. Cc: Zhang Rui Cc: Nicolas Boichat Cc: Mark Brown Cc: Fabian Frederick Cc: Wolfram Sang Cc: Lee Jones Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 9069cc7..d94b4e9 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -350,7 +350,7 @@ source "drivers/thermal/samsung/Kconfig" endmenu menu "STMicroelectronics thermal drivers" -depends on ARCH_STI && OF +depends on (ARCH_STI || COMPILE_TEST) && OF source "drivers/thermal/st/Kconfig" endmenu -- 2.5.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 08/17] thermal: tegra: allow compile test
Adding COMPILE_TEST flag to tegra driver to facilitate maintenance. Cc: Zhang Rui Cc: Stephen Warren Cc: Thierry Reding Cc: Alexandre Courbot Cc: linux...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 0e0d0de..c94efd3 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -242,7 +242,7 @@ config ARMADA_THERMAL config TEGRA_SOCTHERM tristate "Tegra SOCTHERM thermal management" - depends on ARCH_TEGRA + depends on ARCH_TEGRA || COMPILE_TEST help Enable this option for integrated thermal management support on NVIDIA Tegra124 systems-on-chip. The driver supports four thermal zones -- 2.5.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 16/17] thermal: qcom_spmi: allow compile test
Adding COMPILE_TEST flag to qcom_spmi driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index d94b4e9..a752bef 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -356,7 +356,7 @@ endmenu config QCOM_SPMI_TEMP_ALARM tristate "Qualcomm SPMI PMIC Temperature Alarm" - depends on OF && SPMI && IIO + depends on OF && (SPMI || COMPILE_TEST) && IIO select REGMAP_SPMI help This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP) -- 2.5.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 02/17] thermal: spear: allow compile test
Adding COMPILE_TEST flag to spear driver to facilitate maintenance. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index f2b1d31..0334886 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -182,7 +182,7 @@ config IMX_THERMAL config SPEAR_THERMAL bool "SPEAr thermal sensor driver" - depends on PLAT_SPEAR + depends on PLAT_SPEAR || COMPILE_TEST depends on OF help Enable this to plug the SPEAr thermal sensor driver into the Linux -- 2.5.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 00/17] thermal: add COMPILE_TEST (on drivers)
Hello all, This is a simple series to add the COMPILE_TEST on thermal drivers. The idea is to help compiling and maintaining. Split into smaller patches so people can have their own voices on their drivers. Let me know if this is a problem. BR, Eduardo Valentin (17): thermal: hisi: allow compile test thermal: spear: allow compile test thermal: rockchip: allow compile test thermal: kirkwood: allow compile test thermal: dove: allow compile test thermal: u8500: allow compile test thermal: armada: allow compile test thermal: tegra: allow compile test thermal: powerclamp: allow compile test thermal: intel_soc_dts_iosf: allow compile test thermal: intel_soc_dts: allow compile test thermal: intel_quark: allow compile test thermal: int340x: allow compile test thermal: exynos: allow compile test thermal: st: allow compile test thermal: qcom_spmi: allow compile test thermal: ti-soc: allow compile test drivers/thermal/Kconfig| 34 +- drivers/thermal/ti-soc-thermal/Kconfig | 8 2 files changed, 21 insertions(+), 21 deletions(-) -- 2.5.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] igb: don't unmap hw_addr if its NULL
I've got a startech thunderbolt dock someone loaned me, which among other things, has the following device in it: 08:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) This hotplugs just fine (kernel 4.2.0 plus a patch or two here): [ 863.020315] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.18-k [ 863.020316] igb: Copyright (c) 2007-2014 Intel Corporation. [ 863.028657] igb :08:00.0: enabling device ( -> 0002) [ 863.062089] igb :08:00.0: added PHC on eth0 [ 863.062090] igb :08:00.0: Intel(R) Gigabit Ethernet Network Connection [ 863.062091] igb :08:00.0: eth0: (PCIe:2.5Gb/s:Width x1) e8:ea:6a:00:1b:2a [ 863.062194] igb :08:00.0: eth0: PBA No: 000200-000 [ 863.062196] igb :08:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s) [ 863.064889] igb :08:00.0 enp8s0: renamed from eth0 But disconnecting it is another story: [ 1002.807932] igb :08:00.0: removed PHC on enp8s0 [ 1002.807944] igb :08:00.0 enp8s0: PCIe link lost, device now detached [ 1003.341141] [ cut here ] [ 1003.341148] WARNING: CPU: 0 PID: 199 at lib/iomap.c:43 bad_io_access+0x38/0x40() [ 1003.341149] Bad IO access at port 0x0 () [ 1003.342767] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi igb dca firewire_ohci firewire_core crc_itu_t rfcomm ctr ccm arc4 iwlmvm mac80211 fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter bnep dm_mirror dm_region_hash dm_log dm_mod coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel snd_hda_codec_hdmi kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg [ 1003.342793] ansi_cprng aesni_intel hp_wmi aes_x86_64 iTCO_wdt lrw iTCO_vendor_support ppdev gf128mul sparse_keymap glue_helper ablk_helper cryptd snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_intel uvcvideo iwlwifi snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hda_core videobuf2_core snd_hwdep btusb v4l2_common btrtl snd_seq btbcm btintel videodev cfg80211 snd_seq_device rtsx_pci_ms bluetooth pcspkr input_leds i2c_i801 media parport_pc memstick rfkill sg lpc_ich snd_pcm 8250_fintek parport joydev snd_timer snd soundcore hp_accel ie31200_edac mei_me lis3lv02d edac_core input_polldev mei hp_wireless shpchp tpm_infineon sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables autofs4 xfs libcrc32c sd_mod sr_mod cdrom rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci [ 1003.342822] nouveau ahci libahci mxm_wmi e1000e xhci_pci hwmon ptp drm_kms_helper pps_core xhci_hcd ttm wmi video ipv6 [ 1003.342839] CPU: 0 PID: 199 Comm: kworker/0:2 Not tainted 4.2.0-2.el7_UNSUPPORTED.x86_64 #1 [ 1003.342840] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS M70 Ver. 01.07 02/26/2015 [ 1003.342843] Workqueue: pciehp-3 pciehp_power_thread [ 1003.342844] 81a90655 8804866d3b48 8164763a [ 1003.342846] 8804866d3b98 8804866d3b88 8107134a 8804866d3b88 [ 1003.342847] 880486f46000 88046c8a8000 880486f46840 88046c8a8098 [ 1003.342848] Call Trace: [ 1003.342852] [] dump_stack+0x45/0x57 [ 1003.342855] [] warn_slowpath_common+0x8a/0xc0 [ 1003.342857] [] warn_slowpath_fmt+0x46/0x50 [ 1003.342859] [] ? pci_disable_msix+0x3e/0x50 [ 1003.342860] [] bad_io_access+0x38/0x40 [ 1003.342861] [] pci_iounmap+0x27/0x40 [ 1003.342865] [] igb_remove+0xc7/0x160 [igb] [ 1003.342867] [] pci_device_remove+0x3f/0xc0 [ 1003.342869] [] __device_release_driver+0x96/0x130 [ 1003.342870] [] device_release_driver+0x23/0x30 [ 1003.342871] [] pci_stop_bus_device+0x94/0xa0 [ 1003.342872] [] pci_stop_bus_device+0x3d/0xa0 [ 1003.342873] [] pci_stop_bus_device+0x3d/0xa0 [ 1003.342874] [] pci_stop_and_remove_bus_device+0x16/0x30 [ 1003.342876] [] pciehp_unconfigure_device+0x9b/0x180 [ 1003.342877] [] pciehp_disable_slot+0x43/0xb0 [ 1003.342878] [] pciehp_power_thread+0x8d/0xb0 [ 1003.342885] [] process_one_work+0x152/0x3d0 [ 1003.342886] [] worker_thread+0x11a/0x460 [ 1003.342887] [] ? process_one_work+0x3d0/0x3d0 [ 1003.342890] [] kthread+0xc9/0xe0 [ 1003.342891] [] ? kthread_create_on_node+0x180/0x180 [ 1003.342893] [] ret_from_fork+0x3f/0x70 [ 1003.342894] [] ? kthread_create_on_node+0x180/0x180 [ 1003.342895] ---[ end trace 65a77e06d5aa9358 ]--- Upon looking at the igb driver, I see that igb_rd32() attempted to read from hw_addr and failed, so it set hw->hw_addr to NULL and spit out the message in the log output above, "PCIe link lost, device now detached". Well, now that hw_addr
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig
On Tue, Sep 08, 2015 at 01:50:38PM +0100, Dietmar Eggemann wrote: > > It's both a unit and a SCALE/SHIFT problem, SCHED_LOAD_SHIFT and > > SCHED_CAPACITY_SHIFT are defined separately so we must be sure to > > scale the value in the right range. In the case of cpu_usage which > > returns sa->util_avg , it's the capacity range not the load range. > > Still don't understand why it's a unit problem. IMHO LOAD/UTIL and > CAPACITY have no unit. To be more accurate, probably, LOAD can be thought of as having unit, but UTIL has no unit. Anyway, those are my definitions: 1) unit, only for LOAD, and SCHED_LOAD_X is the unit (but SCHED_LOAD_RESOLUTION make it also some 2, see below) 2) range, aka, resolution or fix-point percentage (as Ben said) 3) timing ratio, LOAD_AVG_MAX etc, unralated with SCHED_LOAD_X > >> I always thought that scale_load_down() takes care of that. > > > > AFAIU, scale_load_down is a way to increase the resolution of the > > load not to move from load to capacity > > I tried to figure out why we have this issue when comparing UTIL w/ > CAPACITY and not LOAD w/ CAPACITY: > > Both are initialized like that: > > sa->load_avg = scale_load_down(se->load.weight); > sa->load_sum = sa->load_avg * LOAD_AVG_MAX; > sa->util_avg = scale_load_down(SCHED_LOAD_SCALE); > sa->util_sum = LOAD_AVG_MAX; > > and we use 'se->on_rq * scale_load_down(se->load.weight)' as 'unsigned > long weight' argument to call __update_load_avg() making sure the > scaling differences between LOAD and CAPACITY are respected while > updating sa->load_sum (and sa->load_avg). Yes, because we used SCHED_LOAD_X as both unit and range for LOAD. > OTAH, we don't apply a scale_load_down for sa->util_[sum/avg] only a '<< > SCHED_LOAD_SHIFT) / LOAD_AVG_MAX' on sa->util_avg. > So changing '<< SCHED_LOAD_SHIFT' to '* > scale_load_down(SCHED_LOAD_SCALE)' would be the logical thing to do. Actually, for UTIL, we only need range, so don't conflate with LOAD, what about we get all these clarified by redefining SCHED_LOAD_RESOLUTION as the resolution/range generic macro for LOAD, UTIL, and CAPACITY: #define SCHED_RESOLUTION_SHIFT 10 #define SCHED_RESOLUTION_SCALE (1L << SCHED_RESOLUTION_SHIFT) #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage under light load */ # define scale_load(w) ((w) << SCHED_RESOLUTION_SHIFT) # define scale_load_down(w) ((w) >> SCHED_RESOLUTION_SHIFT) # define SCHED_LOAD_SHIFT (10 + SCHED_RESOLUTION_SHIFT) #else # define scale_load(w) (w) # define scale_load_down(w) (w) # define SCHED_LOAD_SHIFT (10) #endif #define SCHED_LOAD_SCALE(1L << SCHED_LOAD_SHIFT) For UTIL, e.g., it will be initiated as: sa->util_avg = SCHED_RESOLUTION_SCALE; And for capacity, we just use SCHED_RESOLUTION_SHIFT (so SCHED_CAPACITY_SHIFT is not needed). Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sep 10
Hi all, Please do not add material for v4.4 until after v4.3-rc1 is out. Changes since 20150909: I used the h8300 tree from next-20150828 since the current tree has been rebased onto something very old :-( The kvm tree still had its build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 1380 1143 files changed, 73246 insertions(+), 15075 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 226 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (b8889c4fc6ba Merge tag 'tty-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (e21347a1c717 Merge branch 'uaccess' into fixes) Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather than duplicating its implementation) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (daebaabb5cfb powerpc/pseries: Release DRC when configure_connector fails) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (f53de1e9a4aa net: ipv6: use common fib_default_rule_pref) Merging ipsec/master (93efac3f2e03 ipv6: Fix IPsec pre-encap fragmentation check) Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal PCM order) Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses on PA-RISC) Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module parameter for MSI interrupts) Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging tty.current/tty-linus (b8889c4fc6ba Merge tag 'tty-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty) Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() call to error pathway) Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module) Merging staging.current/staging-linus (a794b4f32921 Merge tag 'for-linus-4.3' of git://git.code.sf.net/p/openipmi/linux-ipmi) Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging input-current/for-linus (01b944fe1cd4 Merge branch 'next' into for-linus) Merging crypto-current/master (71c6da846be4 crypto: ghash-clmulni: specify context size for ghash async algorithm) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix futex_cmp_requeue_pi() error handling) Merging backlight-fixes/for-backlight-fixes (68feaca
Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime
Hi,
On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
> >
> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't
> > boot without your patch.
>
> Awesome. Could you test the following patch instead?
>
> ---
Yes, as the first edition, this patch works on my S1200V3RPS machine.
Tested-by: Lee, Chun-Yi
Regards
Joey Lee
>
> >From 24d324b781a3b688dcc265995949a9cf4e8af687 Mon Sep 17 00:00:00 2001
> From: Matt Fleming
> Date: Thu, 3 Sep 2015 15:56:25 +0100
> Subject: [PATCH v2] x86/efi: Map EFI memmap entries in-order at runtime
>
> Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
> signals that the firmware PE/COFF loader supports splitting code and
> data sections of PE/COFF images into separate EFI memory map entries.
> This allows the kernel to map those regions with strict memory
> protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc.
>
> Unfortunately, an unwritten requirement of this new feature is that
> the regions need to be mapped with the same offsets relative to each
> other as observed in the EFI memory map. If this is not done crashes
> like this may occur,
>
> [0.006391] BUG: unable to handle kernel paging request at
> fffefe6086dd
> [0.006923] IP: [] 0xfffefe6086dd
> [0.007000] Call Trace:
> [0.007000] [] efi_call+0x7e/0x100
> [0.007000] [] ? virt_efi_set_variable+0x61/0x90
> [0.007000] [] efi_delete_dummy_variable+0x63/0x70
> [0.007000] [] efi_enter_virtual_mode+0x383/0x392
> [0.007000] [] start_kernel+0x38a/0x417
> [0.007000] [] x86_64_start_reservations+0x2a/0x2c
> [0.007000] [] x86_64_start_kernel+0xeb/0xef
>
> Here 0xfffefe6086dd refers to an address the firmware expects to
> be mapped but which the OS never claimed was mapped. The issue is that
> included in these regions are relative addresses to other regions
> which were emitted by the firmware toolchain before the "splitting" of
> sections occurred at runtime.
>
> Needless to say, we don't satisfy this unwritten requirement on x86_64
> and instead map the EFI memory map entries in reverse order. The above
> crash is almost certainly triggerable with any kernel newer than v3.13
> because that's when we rewrote the EFI runtime region mapping code, in
> commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). For
> kernel versions before v3.13 things may work by pure luck depending on
> the fragmentation of the kernel virtual address space at the time we
> map the EFI regions.
>
> Instead of mapping the EFI memory map entries in reverse order, where
> entry N has a higher virtual address than entry N+1, map them in the
> same order as they appear in the EFI memory map to preserve this
> relative offset between regions.
>
> This patch has been kept as small as possible with the intention that
> it should be applied aggressively to stable and distribution kernels.
> It is very much a bugfix rather than support for a new feature, since
> when EFI_PROPERTIES_TABLE is enabled we must map things as outlined
> above to even boot - we have no way of asking the firmware not to
> split the code/data regions.
>
> In fact, this patch doesn't even make use of the more strict memory
> protections available in UEFI v2.5. That will come later.
>
> Reported-by: Ard Biesheuvel
> Suggested-by: Ard Biesheuvel
> Cc: Lee, Chun-Yi
> Cc: Borislav Petkov
> Cc: Leif Lindholm
> Cc: Peter Jones
> Cc: James Bottomley
> Cc: Matthew Garrett
> Cc: H. Peter Anvin
> Cc: Dave Young
> Cc:
> Signed-off-by: Matt Fleming
> ---
>
> v2: Use Ard's reverse iteration scheme so that we can reuse the
> existing efi_map_region() implementation that maps things top-down.
>
> arch/x86/platform/efi/efi.c | 67
> -
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e4308fe6afe8..c6835bfad3a1 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -705,6 +705,70 @@ out:
> }
>
> /*
> + * Iterate the EFI memory map in reverse order because the regions
> + * will be mapped top-down. The end result is the same as if we had
> + * mapped things forward, but doesn't require us to change the
> + * existing implementation of efi_map_region().
> + */
> +static inline void *efi_map_next_entry_reverse(void *entry)
> +{
> + /* Initial call */
> + if (!entry)
> + return memmap.map_end - memmap.desc_size;
> +
> + entry -= memmap.desc_size;
> + if (entry < memmap.map)
> + return NULL;
> +
> + return entry;
> +}
> +
> +/*
> + * efi_map_next_entry - Return the next EFI memory map descriptor
> + * @entry: Previous EFI memory map descriptor
> + *
> + * This is a helper function to iterate over the EFI memory map, which
> + * we do in different orders depending on the current confi
Re: [PATCH] x86: wmi: Remove private %pUL implementation
On Thu, Sep 10, 2015 at 12:08:45AM +0200, Rasmus Villemoes wrote: > The work performed by wmi_gtoa is equivalent to simply sprintf(out, > "%pUL", in), so one could replace its body by this. However, most > users feed the result directly as a %s argument to some other function > which also understands the %p extensions (they all ultimately use > vsnprintf), so we can eliminate some stack buffers and quite a bit of > code by just using %pUL directly. > > In wmi_dev_uevent I'm not sure whether there's room for a > nul-terminator in env->buf, so I've just replaced wmi_gtoa with the > equivalent sprintf call. > > Signed-off-by: Rasmus Villemoes > --- > Resending, hoping to get it picked up this time. I appear to have dropped the ball on this, even after you sent me a reminder. My sincere apologies. I've re-reviewed, built myself, queued to testing, and it's now getting the 0-day treatment. Provided that comes back good - hopefully tonight, I'll push to for-next, and you'll see it in next in the morning, and to Linus on Friday before the close of the merge window for 4.3. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] Staging: rtl8192u: ieee80211: ieee80211_module.c: Replace "#include " with "#include "
Fix checkpatch.pl warning "Use #include instead of " Signed-off-by: Shraddha Barke --- drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c index 31233d8..425b2dd 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c @@ -48,7 +48,7 @@ #include #include #include -#include +#include #include #include "ieee80211.h" -- 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 2/5] Staging: rtl8192u: ieee80211: ieee80211_softmac.c: Replace "#include " with "#include "
Fix checkpatch.pl warning "Use #include instead of " Signed-off-by: Shraddha Barke --- drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c index 39e9892..e4624e8 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c @@ -19,7 +19,7 @@ #include #include #include -#include +#include #include #include "dot11d.h" -- 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 5/5] Staging: wilc1000: Replace "#include " with "#include "
Fix checkpatch.pl warning "Use #include instead of " Signed-off-by: Shraddha Barke --- drivers/staging/wilc1000/linux_wlan_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/linux_wlan_spi.c b/drivers/staging/wilc1000/linux_wlan_spi.c index 236669c..eef7633 100644 --- a/drivers/staging/wilc1000/linux_wlan_spi.c +++ b/drivers/staging/wilc1000/linux_wlan_spi.c @@ -5,7 +5,7 @@ #include #include #include -#include +#include #include #include -- 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 4/5] Staging: rtl8192u: r8192U_core.c: Replace "#include " with "#include "
Fix checkpatch.pl warning "Use #include instead of " Signed-off-by: Shraddha Barke --- drivers/staging/rtl8192u/r8192U_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c index 577d3a4..cfb0713 100644 --- a/drivers/staging/rtl8192u/r8192U_core.c +++ b/drivers/staging/rtl8192u/r8192U_core.c @@ -58,7 +58,7 @@ double __extendsfdf2(float a) #define CONFIG_RTL8192_IO_MAP -#include +#include #include "r8192U_hw.h" #include "r8192U.h" #include "r8190_rtl8256.h" /* RTL8225 Radio frontend */ -- 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 1/5] Staging: rtl8192u: ieee80211: Replace "#include " with "#include "
Fix checkpatch.pl warning "Use #include instead of " Signed-off-by: Shraddha Barke --- drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c index fff8d58..1ab0aea 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c @@ -48,7 +48,7 @@ #include #include #include -#include +#include #include #include "ieee80211.h" -- 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/
Re: [PATCH v2] r8169: Fix sleeping function called during get_stats64
From: Corinna Vinschen Date: Wed, 9 Sep 2015 23:16:40 +0200 > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104031 > Fixes: 6e85d5ad36a26debc23a9a865c029cbe242b2dc8 > > Based on the discussion starting at > http://www.spinics.net/lists/netdev/msg342193.html > > Tested locally on RTL8168evl/8111evl with various concurrent processes > accessing /proc/net/dev while changing the link state as well as > removing/reloading the r8169 module. > > Signed-off-by: Corinna Vinschen Please address Francois's minor feedback, camelcase drives me nuts too FWIW :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> -Original Message-
> From: Roman Bacik
> Sent: September-09-15 7:36 PM
> To: 'John Youn'; Scott Branden; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
> Subject: RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
>
> > -Original Message-
> > From: John Youn [mailto:john.y...@synopsys.com]
> > Sent: September-09-15 7:25 PM
> > To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> > u...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
> > Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > isochronous mode
> >
> > On 9/9/2015 7:16 PM, Roman Bacik wrote:
> > >> -Original Message-
> > >> From: John Youn [mailto:john.y...@synopsys.com]
> > >> Sent: September-09-15 7:11 PM
> > >> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman;
> > >> linux- u...@vger.kernel.org
> > >> Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
> > >> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > >> isochronous mode
> > >>
> > >> On 9/9/2015 11:16 AM, Roman Bacik wrote:
> > -Original Message-
> > From: John Youn [mailto:john.y...@synopsys.com]
> > Sent: September-03-15 11:53 PM
> > To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> > u...@vger.kernel.org; Roman Bacik
> > Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
> > Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > isochronous mode
> >
> > On 8/31/2015 9:17 AM, Scott Branden wrote:
> > > From: Roman Bacik
> > >
> > > USB OTG driver in isochronous mode has to set the parity of the
> > > receiving microframe. The parity is set to even by default. This
> > > causes problems for an audio gadget, if the host starts
> > > transmitting on odd
> > microframes.
> > >
> > > This fix uses Incomplete Periodic Transfer interrupt to toggle
> > > between even and odd parity until the Transfer Complete
> > > interrupt is
> > >> received.
> > >
> > > Signed-off-by: Roman Bacik
> > > Reviewed-by: Abhinav Ratna
> > > Reviewed-by: Srinath Mannam
> > > Signed-off-by: Scott Branden
> > > ---
> > > drivers/usb/dwc2/core.h | 1 +
> > > drivers/usb/dwc2/gadget.c | 51
> > ++-
> > > drivers/usb/dwc2/hw.h | 1 +
> > > 3 files changed, 52 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > > index 0ed87620..a5634fd 100644
> > > --- a/drivers/usb/dwc2/core.h
> > > +++ b/drivers/usb/dwc2/core.h
> > > @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> > > unsigned intperiodic:1;
> > > unsigned intisochronous:1;
> > > unsigned intsend_zlp:1;
> > > + unsigned inthas_correct_parity:1;
> > >
> > > charname[10];
> > > };
> > > diff --git a/drivers/usb/dwc2/gadget.c
> > > b/drivers/usb/dwc2/gadget.c index 4d47b7c..fac3e2f 100644
> > > --- a/drivers/usb/dwc2/gadget.c
> > > +++ b/drivers/usb/dwc2/gadget.c
> > > @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct
> > > dwc2_hsotg
> > *hsotg, unsigned int idx,
> > > ints &= ~DXEPINT_XFERCOMPL;
> > >
> > > if (ints & DXEPINT_XFERCOMPL) {
> > > + hs_ep->has_correct_parity = 1;
> > > if (hs_ep->isochronous && hs_ep->interval == 1) {
> > > if (ctrl & DXEPCTL_EOFRNUM)
> > > ctrl |= DXEPCTL_SETEVENFR;
> > > @@ -2316,7 +2317,8 @@ void
> > s3c_hsotg_core_init_disconnected(struct
> > dwc2_hsotg *hsotg,
> > > GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> > > GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> > > GINTSTS_OTGINT | GINTSTS_USBSUSP |
> > > - GINTSTS_WKUPINT,
> > > + GINTSTS_WKUPINT |
> > > + GINTSTS_INCOMPL_SOIN |
> > GINTSTS_INCOMPL_SOOUT,
> > > hsotg->regs + GINTMSK);
> > >
> > > if (using_dma(hsotg))
> > > @@ -2581,6 +2583,52 @@ irq_retry:
> > > s3c_hsotg_dump(hsotg);
> > > }
> > >
> > > + if (gintsts & GINTSTS_INCOMPL_SOIN) {
> > > + u32 idx, epctl_reg, ctrl;
> > > + struct s3c_hsotg_ep *hs_ep;
> > > +
> > > + dev_dbg(hsotg->dev, "%s:
> > GINTSTS_INCOMPL_SOIN\n",
> > __func__);
> > > + for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> >
> > Valid endpoints are only up to hsotg->num_of_eps so this might
> > crash on certain configurations.
> >
> > Also, have you tried to find the endpoint which caused the
>
Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by capacity_orig
On Tue, Sep 08, 2015 at 02:52:05PM +0200, Peter Zijlstra wrote: > > +#if (SCHED_LOAD_SHIFT - SCHED_LOAD_RESOLUTION) != 10 || SCHED_CAPACITY_SHIFT > != 10 > +#error "load tracking assumes 2^10 as unit" > +#endif > + Sorry for late response. I might already missed somthing. But I got a bit lost here, with: #define SCHED_LOAD_SHIFT(10 + SCHED_LOAD_RESOLUTION) #define SCHED_CAPACITY_SHIFT10 the #if is certainly false. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
