Re: [PATCH 6/6] pwm: imx: Introduce "polarity_supported" flag to PWMv2 driver
Hi Boris,
> Hi Lukasz,
>
> On Mon, 24 Oct 2016 23:14:58 +0200
> Lukasz Majewski wrote:
>
> > Hi Boris,
> >
> > > On Mon, 24 Oct 2016 17:28:52 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Sun, 23 Oct 2016 23:45:46 +0200
> > > > Lukasz Majewski wrote:
> > > >
> > > > > The need for set_polarity() function has been removed by
> > > > > implementing PWM atomic support (apply() callback).
> > > > >
> > > > > To indicate that the PWMv2 supports polarity inversion, new
> > > > > flag - "polarity_supported" has been introduced.
> > > > >
> > > > > Signed-off-by: Lukasz Majewski
> > > > > ---
> > > > > drivers/pwm/pwm-imx.c | 4 +++-
> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > > > > index 02d3dfd..be3034d 100644
> > > > > --- a/drivers/pwm/pwm-imx.c
> > > > > +++ b/drivers/pwm/pwm-imx.c
> > > > > @@ -258,6 +258,7 @@ static struct pwm_ops imx_pwm_ops_v2 = {
> > > > > };
> > > > >
> > > > > struct imx_pwm_data {
> > > > > + bool polarity_supported;
> > > > > struct pwm_ops *pwm_ops;
> > > > > };
> > > > >
> > > > > @@ -266,6 +267,7 @@ static struct imx_pwm_data
> > > > > imx_pwm_data_v1 = { };
> > > > >
> > > > > static struct imx_pwm_data imx_pwm_data_v2 = {
> > > > > + .polarity_supported = true,
> > > > > .pwm_ops = &imx_pwm_ops_v2,
> > > > > };
> > > > >
> > > > > @@ -313,7 +315,7 @@ static int imx_pwm_probe(struct
> > > > > platform_device *pdev) imx->chip.base = -1;
> > > > > imx->chip.npwm = 1;
> > > > > imx->chip.can_sleep = true;
> > > > > - if (data->pwm_ops->set_polarity) {
> > > > > + if (data->polarity_supported) {
> > > >
> > > > You're still breaking backward compatibility with DTs defining
> > > > #pwm-cells = 2.
> > > >
> > > > Please test the #pwm-cells value before deciding which of_xlate
> > > > should be used.
> > >
> > > Nevermind, I didn't look at [1] and [2].
> >
> > Yes, some patches are required to make this code work. Especially, I
> > wanted to explicitly reuse and credit work already done by
> > Bhuvanchandra.
> >
> > > But still, your series is not bisectable: this change should be
> > > part of patch 5 where you remove the ->set_polarity
> > > implementation. Otherwise, this means you don't support polarity
> > > setting between patch 5 and 6.
> >
> > Frankly speaking, I did it on purpose, to have operations in commits
> > logically separated.
> >
> > I personally, do detest commits which blur the picture and are not
> > corresponding to one single logical change - for example remove some
> > large chunk of code and also add some tiny, new flag.
> >
> > For me it is not a problem to have polarity disabled between
> > patches 5 and 6, since at the end of the day we have it enabled.
>
> It's really simple to make this series bisectable, all you have to do
> is move patch 6 before patch 5.
Hmm... You are right, I do wonder why I didn't get this idea from the
very beginning.
> This being said, I really think you
> should follow Stefan's recommendation: base your changes on mainline
> and switch to the atomic hook before supporting polarity setting.
I will do my best :-)
Best regards,
Łukasz Majewski
>
> Regards,
>
> Boris
pgp9D40rsGCjE.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/6] pwm: imx: Provide atomic operation for IMX PWM driver
Hi Stefan, > Hi Lukasz, > > Thanks for your work, great to see this coming along! :-) > > On 2016-10-24 23:26, Lukasz Majewski wrote: > > Hi Boris, > > > >> On Sun, 23 Oct 2016 23:45:40 +0200 > >> Lukasz Majewski wrote: > >> > >> > This patch set brings atomic operation to i.MX's PWMv2 driver. > >> > > >> > This work has been supported and suggested by Boris Brezillon [1] > >> > and Stefan Agner, by showing how simple the transition could > >> > be :-). > >> > > >> > It has been divided into several steps: > >> > - Separate PWMv1 commits from "generic" and non atomic PWM code. > >> > > >> > NOTE: Since I do not have board with PWMv1, I would like to ask > >> > somebody for testing > >> > > >> > - Move some imx_config_v2 code to separate functions > >> > > >> > - Provide PWM atomic implementation (the ->apply() driver) in a > >> > single patch for better readability. > >> > > >> > - Remove redundant PWM code (disable, enable, config callbacks) > >> > > >> > - Clean up the driver infrastructure > >> > > >> > - Provide "polarity_supported" flag to indicate support for > >> > polarity inversion > >> > > >> > This work should be applied on top of following commits: > >> > > >> > http://patchwork.ozlabs.org/patch/679706/ > > [2] > > > >> > http://patchwork.ozlabs.org/patch/679707/ > > [3] > > > >> > http://patchwork.ozlabs.org/patch/679680/ > >> > >> I'm not sure I follow the logic here. Has patch [1] already been > >> applied? If that's not the case, then you should just drop it and > >> put your changes on top of mainline. > >> > >> [1]http://patchwork.ozlabs.org/patch/679680/ > > > > Patches [2] and [3] have been developed initially by Lothar and > > subsequently picked up by Bhuvanchandra. There is no issue with > > them. > > As such none of this will get merged since all patchset have known > flaws... > > Generally, it is ok to refer to other patchset being a prerequisite, > but that only makes sense if those patch set are still actively > worked on (by somebody other than you). > > In this case I really recommend to create a new, complete patchset. > > > > > The patch [1] is a bit more tricky. The work has been done by > > Bhuvanchandra, which adds DTS and core support for polarity > > inversion. > > > > This code works and utilizes the "old" PWM API with enable, disable > > and config. However, Stefan had some comments about the placement > > for the polarity setting (in the .config_v2()) and proposed switch > > to atomic API. > > Part of the reason I advocated for the atomic API is to make adding > the polarity functionality easier. It does not archive this goal if > we add the "flawed" code first and then transition to the atomic API. > > > > > To make things easier and cleaner, I decided to put my atomic API > > rework on top of those patches. In this way I can credit the > > previous work and avoid rewriting DTS polarity inversion code > > already developed and validated by Bhuvanchandra. > > When you apply the patches using git apply, the authorship and > signoffs will stay. There is no problem in including other peoples > work into your patchset, credit will still be given. If you have to > change another persons patch, you typically also add your signoff to > show that you worked on it too. I do wanted to reuse as much work as possible (especially that the code was working). > > Here is how I would do it: > > 1. Start a new branch from mainline (or even -next). With the newest mainline 4.9-rcX SHA:0c2b6dc4fd4fa13796b319aae969a009f03222c6 the i.MX6q is not booting. Apparently I do need to wait for things to calm down. The last working version is v4.8, which PWM's code is the same as v4.7. > 2. Implement the transition to the new atomic API and test it as such > alone (this way we have no polarity support influence yet, just clean > transition to a new API) I _just_ needed to add polarity support (by setting one bit) to the driver, so I ended up with rewriting the whole PWM i.MX driver :-). > 3. Cherry pick the PWM core changes for the optional 2/3 args driver > support (they should apply cleanly) > 4. Cherry pick (they likely will fail to merge) or reimplement the PWM > polarity driver changes on top of atomic API > 5. Cherry pick device tree changes > > With this approach we'll end up with a nice history where we should > end up with a fully functional PWM system between every patch. I'm fine with proposed approach. I will prepare v2 of patches soon. > > Btw, past perfect tense is not really usual in commit messages. > SubmittingPatches chapter 2 has some tips on writing good commit > messages: > https://www.kernel.org/doc/Documentation/SubmittingPatches OK. Thanks you for your support, Best regards, Łukasz Majewski > > -- > Stefan pgp9TqZEuI37I.pgp Description: OpenPGP digital signature
Re: [PATCH 3/3] clk: keystone: Fix missing iounmap calls in an error handling path
Am 24.10.2016 22:43, schrieb Christophe JAILLET:
> Factorize 'iounmap()' calls in the error handling path.
> The main goal is to add these calls if 'clk_register_pll()' fails.
>
> Add an error message if an 'of_iomap' call fails to be consistent.
>
> Signed-off-by: Christophe JAILLET
> ---
> Un-compiled & un-tested
> ---
> drivers/clk/keystone/pll.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
> index 35c0e2b011d1..73a2558b29c0 100644
> --- a/drivers/clk/keystone/pll.c
> +++ b/drivers/clk/keystone/pll.c
> @@ -191,7 +191,6 @@ static void __init _of_pll_clk_init(struct device_node
> *node, bool pllctrl)
> pll_data->pll_ctl0 = of_iomap(node, i);
> if (!pll_data->pll_ctl0) {
> pr_err("%s: ioremap failed\n", __func__);
> - iounmap(pll_data->pllod);
> goto out;
> }
>
> @@ -206,8 +205,7 @@ static void __init _of_pll_clk_init(struct device_node
> *node, bool pllctrl)
> i = of_property_match_string(node, "reg-names", "multiplier");
> pll_data->pllm = of_iomap(node, i);
> if (!pll_data->pllm) {
> - iounmap(pll_data->pll_ctl0);
> - iounmap(pll_data->pllod);
> + pr_err("%s: ioremap failed\n", __func__);
> goto out;
> }
> }
> @@ -220,6 +218,12 @@ static void __init _of_pll_clk_init(struct device_node
> *node, bool pllctrl)
>
> out:
> pr_err("%s: error initializing pll %s\n", __func__, node->name);
> + if (pll_data->pllm)
> + iounmap(pll_data->pllm);
> + if (pll_data->pll_ctl0)
> + iounmap(pll_data->pll_ctl0);
> + if (pll_data->pllod)
> + iounmap(pll_data->pllod);
> kfree(pll_data);
> }
>
IMHO calles the iounmap() need no check for NULL.
re,
wh
[GIT PULL] s390 patches for 4.9-rc3
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
A few more s390 patches for 4.9:
- A fix for an overflow in the dasd driver reported by UBSAN
- Fix a regression and add hotplug memory to the zone movable again
- Add ignore defines for the pkey system calls
- Fix the ouput of the merged stack tracer
- Replace printk with pr_cont in arch/s390 where appropriate
- Remove the arch specific return_address function again
- Ignore reserved channel paths at boot time
- Add a missing hugetlb_bad_size call to the arch backend
Christian Borntraeger (1):
s390/dasd: avoid undefined behaviour
Gerald Schaefer (1):
s390/mm: fix zone calculation in arch_add_memory()
Heiko Carstens (6):
s390: ignore pkey system calls
s390/dumpstack: restore reliable indicator for call traces
s390/dumpstack: use pr_cont where appropriate
s390/disassambler: use pr_cont where appropriate
s390/dumpstack: get rid of return_address again
s390/dumpstack: use pr_cont within show_stack and die
Sebastian Ott (1):
s390/cio: don't register chpids in reserved state
Shyam Saini (1):
s390/mm: use hugetlb_bad_size()
arch/s390/include/asm/ftrace.h| 4 +--
arch/s390/include/asm/processor.h | 2 +-
arch/s390/include/asm/unistd.h| 3 ++
arch/s390/kernel/dis.c| 4 +--
arch/s390/kernel/dumpstack.c | 63 ++-
arch/s390/kernel/perf_event.c | 2 +-
arch/s390/kernel/stacktrace.c | 4 +--
arch/s390/mm/hugetlbpage.c| 1 +
arch/s390/mm/init.c | 38 ---
arch/s390/oprofile/init.c | 2 +-
drivers/s390/block/dasd_eckd.c| 4 +--
drivers/s390/cio/chp.c| 6 ++--
12 files changed, 61 insertions(+), 72 deletions(-)
diff --git a/arch/s390/include/asm/ftrace.h b/arch/s390/include/asm/ftrace.h
index 64053d9..836c562 100644
--- a/arch/s390/include/asm/ftrace.h
+++ b/arch/s390/include/asm/ftrace.h
@@ -12,9 +12,7 @@
#ifndef __ASSEMBLY__
-unsigned long return_address(int depth);
-
-#define ftrace_return_address(n) return_address(n)
+#define ftrace_return_address(n) __builtin_return_address(n)
void _mcount(void);
void ftrace_caller(void);
diff --git a/arch/s390/include/asm/processor.h
b/arch/s390/include/asm/processor.h
index 0332317..602af69 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -192,7 +192,7 @@ struct stack_frame {
struct mm_struct;
struct seq_file;
-typedef int (*dump_trace_func_t)(void *data, unsigned long address);
+typedef int (*dump_trace_func_t)(void *data, unsigned long address, int
reliable);
void dump_trace(dump_trace_func_t func, void *data,
struct task_struct *task, unsigned long sp);
diff --git a/arch/s390/include/asm/unistd.h b/arch/s390/include/asm/unistd.h
index 02613ba..3066031 100644
--- a/arch/s390/include/asm/unistd.h
+++ b/arch/s390/include/asm/unistd.h
@@ -9,6 +9,9 @@
#include
#define __IGNORE_time
+#define __IGNORE_pkey_mprotect
+#define __IGNORE_pkey_alloc
+#define __IGNORE_pkey_free
#define __ARCH_WANT_OLD_READDIR
#define __ARCH_WANT_SYS_ALARM
diff --git a/arch/s390/kernel/dis.c b/arch/s390/kernel/dis.c
index 43446fa..c74c592 100644
--- a/arch/s390/kernel/dis.c
+++ b/arch/s390/kernel/dis.c
@@ -2014,12 +2014,12 @@ void show_code(struct pt_regs *regs)
*ptr++ = '\t';
ptr += print_insn(ptr, code + start, addr);
start += opsize;
- printk("%s", buffer);
+ pr_cont("%s", buffer);
ptr = buffer;
ptr += sprintf(ptr, "\n ");
hops++;
}
- printk("\n");
+ pr_cont("\n");
}
void print_fn_code(unsigned char *code, unsigned long len)
diff --git a/arch/s390/kernel/dumpstack.c b/arch/s390/kernel/dumpstack.c
index 6693383..55d4fe1 100644
--- a/arch/s390/kernel/dumpstack.c
+++ b/arch/s390/kernel/dumpstack.c
@@ -38,10 +38,10 @@
if (sp < low || sp > high - sizeof(*sf))
return sp;
sf = (struct stack_frame *) sp;
+ if (func(data, sf->gprs[8], 0))
+ return sp;
/* Follow the backchain. */
while (1) {
- if (func(data, sf->gprs[8]))
- return sp;
low = sp;
sp = sf->back_chain;
if (!sp)
@@ -49,6 +49,8 @@
if (sp <= low || sp > high - sizeof(*sf))
return sp;
sf = (struct stack_frame *) sp;
+ if (func(data, sf->gprs[8], 1))
+ return sp;
}
/* Zero backchain detected, check for interrupt frame. */
Re: [PATCH] drm/amd/powerplay: mark symbols static where possible
Am 25.10.2016 um 08:41 schrieb Daniel Vetter: On Mon, Oct 24, 2016 at 10:41:16PM +0200, Arnd Bergmann wrote: On Monday, October 24, 2016 8:07:16 PM CEST Deucher, Alexander wrote: In fact, these functions are only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. Signed-off-by: Baoyou Xie This was already applied the last time you sent it out. Sorry if I didn't mention that previously. For some reason the patch hasn't made it into linux-next, so I can see why Baoyou was getting confused here. Can you clarify what the timeline is for the AMD DRM driver patches from between they get applied to the AMD tree to when they make it into linux-next? It came in late enough last cycle that it didn't make it into 4.9 (this is just a clean up not a critical bug fix), so I queued it for 4.10. I try to reply when I apply a patch, but sometimes I miss one here and there. Once Dave starts the drm-next tree for 4.10, it will be included in my pull request. Pending -next patches are in my drm-next--wip tree until I send Dave a formal request. I've occasionally had a hard time with DRM (and a few other subsystems) with bugfix patches trying to find out whether they got lost or whether they just haven't made it into -next but are in some other tree. For bug fixes we usually send Dave ~weekly pull requests for each -rc as necessary. For -next stuff, each driver usually sends at least one, sometimes several pull requests for the next merge window. Ok, got it. Thanks for the detailed reply! Do you think it would be appropriate to include your drm-next-wip tree in linux-next? I think this is how a lot of the multi-level maintainer setups work as it give faster feedback about when things break. tbh I think all drm drivers should be in linux-next. The early head-ups about conflicts are really useful. Same for nouveau, but given that nouveau is developed in a userspace git repo that's harder to pull off. Mhm, in general I agree that seeing merge conflicts and getting a bit more testing earlier would be a good idea. But Alex has the practice of regenerating his -wip branches multiple times. That is usually not a problem because the only one occasionally basing work on that branch is me, but it would be if you start to merge it somewhere. Christian. -Daniel
RE: [PATCH V1] mfd: pv88080: Expand driver for GPIO function support.
On Tuesday, October 25, 2016 3:41 PM, Lee Jones wrote: > On Tue, 25 Oct 2016, Eric Jeong wrote: > > > > > From: Eric Jeong > > > > This patch adds support for the PV88080 PMIC. > > > > This pathch is done as part of the existing PV88080 regulator driver > > by expanding the driver for GPIO function support. > > > > The MFD core driver provides communication through the I2C interface. > > and contains the following components: > > > > - Regulators > > - Configurable GPIOs > > > > Kconfig and Makefile are updated to reflect support for PV88080 PMIC. > > > > Signed-off-by: Eric Jeong > > > > --- > > This patch applies against linux-next and next-20161024 > > > > Hi, > > > > This change is made as a single patch. Because, to ensure that kernel > > builds and runs properly after this patch. > > > > The regulator device driver for PV88080 IC is submitted to Linux kernel. > > And now, GPIO function is required. In order to add GPIO driver, MFD > > driver is also required. > > > > Changes > > - Add MFD driver. > > - Add GPIO driver. > > - Update regulator driver to reflect the support. > > - Delete pv88080-regulator.h file. > > - Move binding document to mfd directory. > > > > Regards, > > Eric Jeong, Dialog Semiconductor Ltd. > > > > > > Documentation/devicetree/bindings/mfd/pv88080.txt | 63 + > > .../devicetree/bindings/regulator/pv88080.txt | 62 - > > drivers/gpio/Kconfig | 11 + > > drivers/gpio/Makefile |1 + > > drivers/gpio/gpio-pv88080.c| 195 ++ > > drivers/mfd/Kconfig| 12 + > > drivers/mfd/Makefile |2 + > > drivers/mfd/pv88080-core.c | 270 > > > > drivers/mfd/pv88080-i2c.c | 99 +++ > > drivers/regulator/Kconfig |5 +- > > drivers/regulator/pv88080-regulator.c | 202 ++- > > drivers/regulator/pv88080-regulator.h | 118 - > > include/linux/mfd/pv88080.h| 236 + > > 13 files changed, 970 insertions(+), 306 deletions(-) create mode > > 100644 Documentation/devicetree/bindings/mfd/pv88080.txt > > delete mode 100644 > > Documentation/devicetree/bindings/regulator/pv88080.txt > > create mode 100644 drivers/gpio/gpio-pv88080.c create mode 100644 > > drivers/mfd/pv88080-core.c create mode 100644 > > drivers/mfd/pv88080-i2c.c delete mode 100644 > > drivers/regulator/pv88080-regulator.h > > create mode 100644 include/linux/mfd/pv88080.h > > You're going to need to split this patch up as much as possible. > > No one is going to want to review a 1200 line patch. > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source > software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog Sorry for inconvenience. I will separate the patch and send again. Regards Eric
Re: [PATCH] leds: leds-pca963x: workaround group blink scaling issue
Hi Matt,
Patch applied.
Thanks,
Jacek Anaszewski
On 10/13/2016 03:16 PM, Matt Ranostay wrote:
PCA9632TK part seems to incorrectly blink at ~1.3x of the programmed
rate. This patchset add a nxp,period-scale devicetree property to
adjust for this misconfiguration.
Cc: Tony Lindgren
Cc: Jacek Anaszewski
Signed-off-by: Matt Ranostay
---
Documentation/devicetree/bindings/leds/pca963x.txt | 3 +++
drivers/leds/leds-pca963x.c| 18 +++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt
b/Documentation/devicetree/bindings/leds/pca963x.txt
index dafbe9931c2b..dfbdb123a9bf 100644
--- a/Documentation/devicetree/bindings/leds/pca963x.txt
+++ b/Documentation/devicetree/bindings/leds/pca963x.txt
@@ -7,6 +7,9 @@ Optional properties:
- nxp,totem-pole : use totem pole (push-pull) instead of open-drain (pca9632
defaults
to open-drain, newer chips to totem pole)
- nxp,hw-blink : use hardware blinking instead of software blinking
+- nxp,period-scale : In some configurations, the chip blinks faster than
expected.
+This parameter provides a scaling ratio (fixed point,
decimal divided
+by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
Each led is represented as a sub-node of the nxp,pca963x device.
diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
index 407eba11e187..b6ce1f2ec33e 100644
--- a/drivers/leds/leds-pca963x.c
+++ b/drivers/leds/leds-pca963x.c
@@ -59,6 +59,7 @@ struct pca963x_chipdef {
u8 grpfreq;
u8 ledout_base;
int n_leds;
+ unsigned intscaling;
};
static struct pca963x_chipdef pca963x_chipdefs[] = {
@@ -189,6 +190,14 @@ static int pca963x_led_set(struct led_classdev *led_cdev,
return pca963x_brightness(pca963x, value);
}
+static unsigned int pca963x_period_scale(struct pca963x_led *pca963x,
+ unsigned int val)
+{
+ unsigned int scaling = pca963x->chip->chipdef->scaling;
+
+ return scaling ? DIV_ROUND_CLOSEST(val * scaling, 1000) : val;
+}
+
static int pca963x_blink_set(struct led_classdev *led_cdev,
unsigned long *delay_on, unsigned long *delay_off)
{
@@ -207,14 +216,14 @@ static int pca963x_blink_set(struct led_classdev
*led_cdev,
time_off = 500;
}
- period = time_on + time_off;
+ period = pca963x_period_scale(pca963x, time_on + time_off);
/* If period not supported by hardware, default to someting sane. */
if ((period < PCA963X_BLINK_PERIOD_MIN) ||
(period > PCA963X_BLINK_PERIOD_MAX)) {
time_on = 500;
time_off = 500;
- period = time_on + time_off;
+ period = pca963x_period_scale(pca963x, 1000);
}
/*
@@ -222,7 +231,7 @@ static int pca963x_blink_set(struct led_classdev *led_cdev,
* (time_on / period) = (GDC / 256) ->
* GDC = ((time_on * 256) / period)
*/
- gdc = (time_on * 256) / period;
+ gdc = (pca963x_period_scale(pca963x, time_on) * 256) / period;
/*
* From manual: period = ((GFRQ + 1) / 24) in seconds.
@@ -294,6 +303,9 @@ pca963x_dt_init(struct i2c_client *client, struct
pca963x_chipdef *chip)
else
pdata->blink_type = PCA963X_SW_BLINK;
+ if (of_property_read_u32(np, "nxp,period-scale", &chip->scaling))
+ chip->scaling = 1000;
+
return pdata;
}
--
Best regards,
Jacek Anaszewski
Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
On Tue, 25 Oct 2016 07:38:55 +0200 LABBE Corentin wrote: > > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote: > > > Since SID's content is constant over reboot, > > > > That's not true, at least not across all the Allwinner SoCs, and > > especially not on the A10 and A20 that this driver supports. > > > > On my cubieboard2 (A20) > hexdump -C > /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem > 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0200 > cubiedev ~ # reboot > cubiedev ~ # hexdump -C > /sys/devices/platform/soc\@01c0/1c23800.eeprom/sunxi-sid0/nvmem > 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur| > 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0200 > > So clearly for me its constant. Even after power off/power on? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
Re: [RFC 3/8] mm: Isolate coherent device memory nodes from HugeTLB allocation paths
On 25/10/16 15:15, Aneesh Kumar K.V wrote: > Dave Hansen writes: > >> On 10/23/2016 09:31 PM, Anshuman Khandual wrote: >>> This change is part of the isolation requiring coherent device memory nodes >>> implementation. >>> >>> Isolation seeking coherent device memory node requires allocation isolation >>> from implicit memory allocations from user space. Towards that effect, the >>> memory should not be used for generic HugeTLB page pool allocations. This >>> modifies relevant functions to skip all coherent memory nodes present on >>> the system during allocation, freeing and auditing for HugeTLB pages. >> >> This seems really fragile. You had to hit, what, 18 call sites? What >> are the odds that this is going to stay working? > > > I guess a better approach is to introduce new node_states entry such > that we have one that excludes coherent device memory numa nodes. One > possibility is to add N_SYSTEM_MEMORY and N_MEMORY. > > Current N_MEMORY becomes N_SYSTEM_MEMORY and N_MEMORY includes > system and device/any other memory which is coherent. > I thought of this as well, but I would rather see N_COHERENT_MEMORY as a flag. The idea being that some device memory is a part of N_MEMORY, but N_COHERENT_MEMORY gives it additional attributes > All the isolation can then be achieved based on the nodemask_t used for > allocation. So for allocations we want to avoid from coherent device we > use N_SYSTEM_MEMORY mask or a derivative of that and where we are ok to > allocate from CDM with fallbacks we use N_MEMORY. > I suspect its going to be easier to exclude N_COHERENT_MEMORY. > All nodes zonelist will have zones from the coherent device nodes but we > will not end up allocating from coherent device node zone due to the > node mask used. > > > This will also make sure we end up allocating from the correct coherent > device numa node in the presence of multiple of them based on the > distance of the coherent device node from the current executing numa > node. > The idea is good overall, but I think its going to be good to document the exclusions with the flags Balbir Singh.
Re: [PATCH] virtio: console: Unlock vqs while freeing buffers
On (Tue) 11 Oct 2016 [12:05:15], Matt Redfearn wrote:
> Commit c6017e793b93 ("virtio: console: add locks around buffer removal
> in port unplug path") added locking around the freeing of buffers in the
> vq. However, when free_buf() is called with can_sleep = true and rproc
> is enabled, it calls dma_free_coherent() directly, requiring interrupts
> to be enabled. Currently a WARNING is triggered due to the spin locking
> around free_buf, with a call stack like this:
>
> WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
> free_buf+0x1a8/0x288
> Call Trace:
> [<8040c538>] show_stack+0x74/0xc0
> [<80757240>] dump_stack+0xd0/0x110
> [<80430d98>] __warn+0xfc/0x130
> [<80430ee0>] warn_slowpath_null+0x2c/0x3c
> [<807e7c6c>] free_buf+0x1a8/0x288
> [<807ea590>] remove_port_data+0x50/0xac
> [<807ea6a0>] unplug_port+0xb4/0x1bc
> [<807ea858>] virtcons_remove+0xb0/0xfc
> [<807b6734>] virtio_dev_remove+0x58/0xc0
> [<807f918c>] __device_release_driver+0xac/0x134
> [<807f924c>] device_release_driver+0x38/0x50
> [<807f7edc>] bus_remove_device+0xfc/0x130
> [<807f4b74>] device_del+0x17c/0x21c
> [<807f4c38>] device_unregister+0x24/0x38
> [<807b6b50>] unregister_virtio_device+0x28/0x44
>
> Fix this by restructuring the loops to allow the locks to only be taken
> where it is necessary to protect the vqs, and release it while the
> buffer is being freed.
>
> Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in
> port unplug path")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Matt Redfearn
Reviewed-by: Amit Shah
Michael, can you pick this up?
Thanks,
Amit
Re: [PATCHv4 18/43] block: define BIO_MAX_PAGES to HPAGE_PMD_NR if huge page cache enabled
On Tue, Oct 25, 2016 at 03:13:17AM +0300, Kirill A. Shutemov wrote: > We are going to do IO a huge page a time. So we need BIO_MAX_PAGES to be > at least HPAGE_PMD_NR. For x86-64, it's 512 pages. NAK. The maximum bio size should not depend on an obscure vm config, please send a standalone patch increasing the size to the block list, with a much long explanation. Also you can't simply increase the size of the largers pool, we'll probably need more pools instead, or maybe even implement a similar chaining scheme as we do for struct scatterlist.
Re: [RFC 8/8] mm: Add N_COHERENT_DEVICE node type into node_states[]
On 24/10/16 15:31, Anshuman Khandual wrote:
> Add a new member N_COHERENT_DEVICE into node_states[] nodemask array to
> enlist all those nodes which contain only coherent device memory. Also
> creates a new sysfs interface /sys/devices/system/node/is_coherent_device
> to list down all those nodes which has coherent device memory.
>
> Signed-off-by: Anshuman Khandual
> ---
> Documentation/ABI/stable/sysfs-devices-node | 7 +++
> drivers/base/node.c | 6 ++
> include/linux/nodemask.h| 3 +++
> mm/memory_hotplug.c | 10 ++
> 4 files changed, 26 insertions(+)
>
> diff --git a/Documentation/ABI/stable/sysfs-devices-node
> b/Documentation/ABI/stable/sysfs-devices-node
> index 5b2d0f0..5538791 100644
> --- a/Documentation/ABI/stable/sysfs-devices-node
> +++ b/Documentation/ABI/stable/sysfs-devices-node
> @@ -29,6 +29,13 @@ Description:
> Nodes that have regular or high memory.
> Depends on CONFIG_HIGHMEM.
>
> +What:/sys/devices/system/node/is_coherent_device
> +Date:October 2016
> +Contact: Linux Memory Management list
> +Description:
> + Lists the nodemask of nodes that have coherent memory.
> + Depends on CONFIG_COHERENT_DEVICE.
> +
> What:/sys/devices/system/node/nodeX
> Date:October 2002
> Contact: Linux Memory Management list
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index 5548f96..5b5dd89 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -661,6 +661,9 @@ static struct node_attr node_state_attr[] = {
> [N_MEMORY] = _NODE_ATTR(has_memory, N_MEMORY),
> #endif
> [N_CPU] = _NODE_ATTR(has_cpu, N_CPU),
> +#ifdef CONFIG_COHERENT_DEVICE
> + [N_COHERENT_DEVICE] = _NODE_ATTR(is_coherent_device, N_COHERENT_DEVICE),
> +#endif
> };
>
> static struct attribute *node_state_attrs[] = {
> @@ -674,6 +677,9 @@ static struct attribute *node_state_attrs[] = {
> &node_state_attr[N_MEMORY].attr.attr,
> #endif
> &node_state_attr[N_CPU].attr.attr,
> +#ifdef CONFIG_COHERENT_DEVICE
> + &node_state_attr[N_COHERENT_DEVICE].attr.attr,
> +#endif
> NULL
> };
>
> diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
> index f746e44..605cb0d 100644
> --- a/include/linux/nodemask.h
> +++ b/include/linux/nodemask.h
> @@ -393,6 +393,9 @@ enum node_states {
> N_MEMORY = N_HIGH_MEMORY,
> #endif
> N_CPU, /* The node has one or more cpus */
> +#ifdef CONFIG_COHERENT_DEVICE
> + N_COHERENT_DEVICE, /* The node has coherent device memory */
> +#endif
> NR_NODE_STATES
> };
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 9629273..8f03962 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1044,6 +1044,11 @@ static void node_states_set_node(int node, struct
> memory_notify *arg)
> if (arg->status_change_nid_high >= 0)
> node_set_state(node, N_HIGH_MEMORY);
>
> +#ifdef CONFIG_COHERENT_DEVICE
> + if (isolated_cdm_node(node))
> + node_set_state(node, N_COHERENT_DEVICE);
> +#endif
> +
#ifdef not required, see below
> node_set_state(node, N_MEMORY);
> }
>
> @@ -1858,6 +1863,11 @@ static void node_states_clear_node(int node, struct
> memory_notify *arg)
> if ((N_MEMORY != N_HIGH_MEMORY) &&
> (arg->status_change_nid >= 0))
> node_clear_state(node, N_MEMORY);
> +
> +#ifdef CONFIG_COHERENT_DEVICE
> + if (isolated_cdm_node(node))
> + node_clear_state(node, N_COHERENT_DEVICE);
> +#endif
> }
>
I think the #ifdefs are not needed if isolated_cdm_node
is defined for both with and without CONFIG_COHERENT_DEVICE.
I think this patch needs to move up in the series so that
node state can be examined by other core algorithms
Balbir
RE: UBIFS with dma on 4.6 kernel is not working
Hi, Thanks everybody for your valuable information. I am not aware of all these dma related APIs but where to handle these dma stuff? Is it in UBI/UBIFS(at the time of vmalloc allocations)? Or in controller driver? And also is there a way to know the memory allocated using vmalloc is contiguous or not? Based on that I can switch my driver to work in dma or non-dma mode for ubifs use. Thanks, Naga Sureshkumar Relli -Original Message- From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Friday, October 21, 2016 6:45 PM To: Richard Weinberger Cc: Christoph Hellwig ; Naga Sureshkumar Relli ; dw...@infradead.org; computersforpe...@gmail.com; dedeki...@gmail.com; adrian.hun...@intel.com; michal.si...@xilinx.com; Punnaiah Choudary Kalluri ; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; Boris Brezillon Subject: Re: UBIFS with dma on 4.6 kernel is not working On Fri, Oct 21, 2016 at 03:07:57PM +0200, Richard Weinberger wrote: > Hmm, thought this is still problematic on VIVT architectures. > Boris tried to provide a solution for that some time ago: > http://www.spinics.net/lists/arm-kernel/msg494025.html Things have been working fine for approx 10 years when using flush_kernel_vmap_range before doing I/O using the physical addresses and then invalidate_kernel_vmap_range when completing the I/O and going back to using the virtual mapping for XFS. Of course all this assumes at least the higher level that did the vm_map_ram operation knows about this dance between virtually mapped and physiscal addresses.
Re: [RFC 3/8] mm: Isolate coherent device memory nodes from HugeTLB allocation paths
On 25/10/16 18:17, Balbir Singh wrote: > > > On 25/10/16 15:15, Aneesh Kumar K.V wrote: >> Dave Hansen writes: >> >>> On 10/23/2016 09:31 PM, Anshuman Khandual wrote: This change is part of the isolation requiring coherent device memory nodes implementation. Isolation seeking coherent device memory node requires allocation isolation from implicit memory allocations from user space. Towards that effect, the memory should not be used for generic HugeTLB page pool allocations. This modifies relevant functions to skip all coherent memory nodes present on the system during allocation, freeing and auditing for HugeTLB pages. >>> >>> This seems really fragile. You had to hit, what, 18 call sites? What >>> are the odds that this is going to stay working? >> >> >> I guess a better approach is to introduce new node_states entry such >> that we have one that excludes coherent device memory numa nodes. One >> possibility is to add N_SYSTEM_MEMORY and N_MEMORY. >> >> Current N_MEMORY becomes N_SYSTEM_MEMORY and N_MEMORY includes >> system and device/any other memory which is coherent. >> > > I thought of this as well, but I would rather see N_COHERENT_MEMORY > as a flag. The idea being that some device memory is a part of > N_MEMORY, but N_COHERENT_MEMORY gives it additional attributes > >> All the isolation can then be achieved based on the nodemask_t used for >> allocation. So for allocations we want to avoid from coherent device we >> use N_SYSTEM_MEMORY mask or a derivative of that and where we are ok to >> allocate from CDM with fallbacks we use N_MEMORY. >> > > I suspect its going to be easier to exclude N_COHERENT_MEMORY. > >> All nodes zonelist will have zones from the coherent device nodes but we >> will not end up allocating from coherent device node zone due to the >> node mask used. >> >> >> This will also make sure we end up allocating from the correct coherent >> device numa node in the presence of multiple of them based on the >> distance of the coherent device node from the current executing numa >> node. >> > > The idea is good overall, but I think its going to be good to document > the exclusions with the flags > FWIW,, some of this is present in 8/8 Balbir
Re: [patch] zfcp: spin_lock_irqsave() is not nestable
On 10/24/2016 10:18 AM, Christian Borntraeger wrote: > On 10/14/2016 10:21 PM, Martin K. Petersen wrote: >>> "Steffen" == Steffen Maier writes: >> >> Steffen> could you please queue this as fix for one of my patches that >> Steffen> went into the 4.9 merge window, so for 4.9-rc I guess? >> >> Applied to 4.9/scsi-fixes. >> > > FWIW, I do see rcu stall errors with 4.9-rc1 from time to time, so I assume > that this fix is not only theoretical but fixes a real life issue. Yes, with that patch the rcu stalls are gone, I assume its already on a branch that does not rebase, otherwise feel free to add Tested-by: Christian Borntraeger
[PATCH v4 0/3] Make core_pattern support namespace
This patchset includes following function points: 1: Let usermodehelper function possible to set pid namespace done by: [PATCH v4 1/3] Make call_usermodehelper_exec possible to set pid namespace. 2: Let pipe_type core_pattern write dump into container's rootfs done by: [PATCH v4 2/3] Limit dump_pipe program's permission to init for container. 2: Make separate core_pattern setting for each container done by: [PATCH v4 3/3] Make core_pattern support namespace 3: Compatibility with current system also included in: [PATCH v4 3/3] Make core_pattern support namespace If container hadn't change core_pattern setting, it will keep same setting with host. Test: 1: Pass a test script for each function of this patchset ## TEST IN HOST ## [root@kerneldev dumptest]# ./test_host Set file core_pattern: OK ./test_host: line 41: 2366 Segmentation fault (core dumped) "$SCRI= PT_BASE_DIR"/make_dump Checking dumpfile: OK Set file core_pattern: OK ./test_host: line 41: 2369 Segmentation fault (core dumped) "$SCRI= PT_BASE_DIR"/make_dump Checking dump_pipe triggered: OK Checking rootfs: OK Checking dumpfile: OK Checking namespace: OK Checking process list: OK Checking capabilities: OK ## TEST IN GUEST ## # ./test Segmentation fault (core dumped) Checking dump_pipe triggered: OK Checking rootfs: OK Checking dumpfile: OK Checking namespace: OK Checking process list: OK Checking cg pids: OK Checking capabilities: OK [ 64.940734] make_dump[2432]: segfault at 0 ip 0040049d sp 000= 07ffc4af025f0 error 6 in make_dump[40+a6000] # 2: Pass other test(which is not easy to do in script) by hand. Changelog v3.1-v4: 1. remove extra fork pointed out by: Andrei Vagin Changelog v3-v3.1: 1. Switch "pwd" of pipe program to container's root fs. 2. Rebase on top of v4.9-rc1 Changelog v2->v3: 1: Fix problem of setting pid namespace, pointed out by: Andrei Vagin Changelog v1(RFC)->v2: 1: Add [PATCH 2/2] which was todo in [RFC v1]. 2: Pass a test script for each function. 3: Rebase on top of v4.7. Suggested-by: Eric W. Biederman Suggested-by: KOSAKI Motohiro Signed-off-by: Zhao Lei Signed-off-by: Cao Shufeng Cao Shufeng (2): Make call_usermodehelper_exec possible to set namespaces Limit dump_pipe program's permission to init for container Zhao Lei (1): Make core_pattern support namespace fs/coredump.c | 150 +++--- include/linux/binfmts.h | 2 + include/linux/kmod.h | 4 ++ include/linux/pid_namespace.h | 3 + init/do_mounts_initrd.c | 3 +- kernel/kmod.c | 43 +--- kernel/pid.c | 2 + kernel/pid_namespace.c| 2 + kernel/sysctl.c | 50 -- lib/kobject_uevent.c | 3 +- security/keys/request_key.c | 4 +- 11 files changed, 241 insertions(+), 25 deletions(-) -- 2.7.4
Re: [RFC PATCH] kbuild: add -fno-PIE
On 2016-10-24 19:32:30 [+0200], Sven Joachim wrote: > On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote: > > > On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote: > >> > >> But make still fails with it. :-( > > > > try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if > > the resulting kernel built with v3.2 gcc boots & works. > > Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces > assembler errors in arch/x86/entry/entry_32.S. Maybe binutils 2.15 is > not recent enough anymore? so we use stone age gcc but take latest binutils and kernel? What about lifting the limit of gcc 3.2? Is there any use case in 2016 to use gcc 3.2 on a recent kernel except whether it still compiles or not? Sebastian
[PATCH v4 3/3] Make core_pattern support namespace
From: Zhao Lei
Currently, each container shared one copy of coredump setting
with the host system, if host system changed the setting, each
running containers will be affected.
Same story happened when container changed core_pattern, both
host and other container will be affected.
For container based on namespace design, it is good to allow
each container keeping their own coredump setting.
It will bring us following benefit:
1: Each container can change their own coredump setting
based on operation on /proc/sys/kernel/core_pattern
2: Coredump setting changed in host will not affect
running containers.
3: Support both case of "putting coredump in guest" and
"putting curedump in host".
Each namespace-based software(lxc, docker, ..) can use this function
to custom their dump setting.
And this function makes each continer working as separate system,
it fit for design goal of namespace.
Test(in lxc):
# In the host
#
# echo host_core >/proc/sys/kernel/core_pattern
# cat /proc/sys/kernel/core_pattern
host_core
# ulimit -c 1024000
# ./make_dump
Segmentation fault (core dumped)
# ls -l
-rw--- 1 root root 331776 Feb 4 18:02 host_core.2175
-rwxr-xr-x 1 root root 759731 Feb 4 18:01 make_dump
#
# In the container
#
# cat /proc/sys/kernel/core_pattern
host_core
# echo container_core >/proc/sys/kernel/core_pattern
# ./make_dump
Segmentation fault (core dumped)
# ls -l
-rwxr-xr-x1 root root 759731 Feb 4 10:45 make_dump
-rw---1 root root 331776 Feb 4 10:45 container_core.16
#
# Return to host
#
# cat /proc/sys/kernel/core_pattern
host_core
# ls
host_core.2175 make_dump make_dump.c
# rm -f host_core.2175
# ./make_dump
Segmentation fault (core dumped)
# ls -l
-rw--- 1 root root 331776 Feb 4 18:49 host_core.2351
-rwxr-xr-x 1 root root 759731 Feb 4 18:01 make_dump
#
Signed-off-by: Zhao Lei
---
fs/coredump.c | 25 --
include/linux/pid_namespace.h | 3 +++
kernel/pid.c | 2 ++
kernel/pid_namespace.c| 2 ++
kernel/sysctl.c | 50 ++-
5 files changed, 70 insertions(+), 12 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index aa2ef6c..f97a987 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -49,7 +49,6 @@
int core_uses_pid;
unsigned int core_pipe_limit;
-char core_pattern[CORENAME_MAX_SIZE] = "core";
static int core_name_size = CORENAME_MAX_SIZE;
struct core_name {
@@ -57,8 +56,6 @@ struct core_name {
int used, size;
};
-/* The maximal length of core_pattern is also specified in sysctl.c */
-
static int expand_corename(struct core_name *cn, int size)
{
char *corename = krealloc(cn->corename, size, GFP_KERNEL);
@@ -183,10 +180,10 @@ static int cn_print_exe_file(struct core_name *cn)
* name into corename, which must have space for at least
* CORENAME_MAX_SIZE bytes plus one byte for the zero terminator.
*/
-static int format_corename(struct core_name *cn, struct coredump_params *cprm)
+static int format_corename(struct core_name *cn, const char *pat_ptr,
+ struct coredump_params *cprm)
{
const struct cred *cred = current_cred();
- const char *pat_ptr = core_pattern;
int ispipe = (*pat_ptr == '|');
int pid_in_pattern = 0;
int err = 0;
@@ -663,6 +660,8 @@ void do_coredump(const siginfo_t *siginfo)
*/
.mm_flags = mm->flags,
};
+ struct pid_namespace *pid_ns;
+ char core_pattern[CORENAME_MAX_SIZE];
audit_core_dumps(siginfo->si_signo);
@@ -672,6 +671,18 @@ void do_coredump(const siginfo_t *siginfo)
if (!__get_dumpable(cprm.mm_flags))
goto fail;
+ pid_ns = task_active_pid_ns(current);
+ spin_lock(&pid_ns->core_pattern_lock);
+ while (pid_ns != &init_pid_ns) {
+ if (pid_ns->core_pattern[0])
+ break;
+ spin_unlock(&pid_ns->core_pattern_lock);
+ pid_ns = pid_ns->parent,
+ spin_lock(&pid_ns->core_pattern_lock);
+ }
+ strcpy(core_pattern, pid_ns->core_pattern);
+ spin_unlock(&pid_ns->core_pattern_lock);
+
cred = prepare_creds();
if (!cred)
goto fail;
@@ -693,7 +704,7 @@ void do_coredump(const siginfo_t *siginfo)
old_cred = override_creds(cred);
- ispipe = format_corename(&cn, &cprm);
+ ispipe = format_corename(&cn, core_pattern, &cprm);
if (ispipe) {
int dump_count;
@@ -740,7 +751,7 @@ void do_coredump(const siginfo_t *siginfo)
}
rcu_read_lock();
- vinit_task = find_task_by_vpid(1);
+ vinit_task = find_task_by_pid_ns(1, pid_ns);
rcu_read_unlock();
if (!vinit_task) {
print
[PATCH v4 1/3] Make call_usermodehelper_exec possible to set namespaces
Current call_usermodehelper_work() can not set namespaces for
the executed program.
This patch add above function for call_usermodehelper_work().
The init_intermediate is introduced for init works which should
be done before fork(). So that we get a method to set namespaces
for children. The cleanup_intermediate is introduced for cleaning
up what we have done in init_intermediate, like switching back
the namespace.
This function is helpful for coredump to run pipe_program in
specific container environment.
Signed-off-by: Cao Shufeng
Co-author-by: Zhao Lei
---
fs/coredump.c | 3 ++-
include/linux/kmod.h| 4
init/do_mounts_initrd.c | 3 ++-
kernel/kmod.c | 43 +++
lib/kobject_uevent.c| 3 ++-
security/keys/request_key.c | 4 ++--
6 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 281b768..52f2ed6 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -641,7 +641,8 @@ void do_coredump(const siginfo_t *siginfo)
retval = -ENOMEM;
sub_info = call_usermodehelper_setup(helper_argv[0],
helper_argv, NULL, GFP_KERNEL,
- umh_pipe_setup, NULL, &cprm);
+ NULL, NULL, umh_pipe_setup,
+ NULL, &cprm);
if (sub_info)
retval = call_usermodehelper_exec(sub_info,
UMH_WAIT_EXEC);
diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index fcfd2bf..994e429 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -61,6 +61,8 @@ struct subprocess_info {
char **envp;
int wait;
int retval;
+ void (*init_intermediate)(struct subprocess_info *info);
+ void (*cleanup_intermediate)(struct subprocess_info *info);
int (*init)(struct subprocess_info *info, struct cred *new);
void (*cleanup)(struct subprocess_info *info);
void *data;
@@ -71,6 +73,8 @@ call_usermodehelper(char *path, char **argv, char **envp, int
wait);
extern struct subprocess_info *
call_usermodehelper_setup(char *path, char **argv, char **envp, gfp_t gfp_mask,
+ void (*init_intermediate)(struct subprocess_info
*info),
+ void (*cleanup_intermediate)(struct subprocess_info
*info),
int (*init)(struct subprocess_info *info, struct cred
*new),
void (*cleanup)(struct subprocess_info *), void
*data);
diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
index a1000ca..59d11c9 100644
--- a/init/do_mounts_initrd.c
+++ b/init/do_mounts_initrd.c
@@ -72,7 +72,8 @@ static void __init handle_initrd(void)
current->flags |= PF_FREEZER_SKIP;
info = call_usermodehelper_setup("/linuxrc", argv, envp_init,
-GFP_KERNEL, init_linuxrc, NULL, NULL);
+GFP_KERNEL, NULL, NULL, init_linuxrc,
+NULL, NULL);
if (!info)
return;
call_usermodehelper_exec(info, UMH_WAIT_PROC);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 0277d12..42f5a74 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -91,7 +91,8 @@ static int call_modprobe(char *module_name, int wait)
argv[4] = NULL;
info = call_usermodehelper_setup(modprobe_path, argv, envp, GFP_KERNEL,
-NULL, free_modprobe_argv, NULL);
+NULL, NULL, NULL, free_modprobe_argv,
+ NULL);
if (!info)
goto free_module_name;
@@ -301,6 +302,9 @@ static void call_usermodehelper_exec_sync(struct
subprocess_info *sub_info)
/* Restore default kernel sig handler */
kernel_sigaction(SIGCHLD, SIG_IGN);
+ if(sub_info->cleanup_intermediate) {
+ sub_info->cleanup_intermediate(sub_info);
+ }
umh_complete(sub_info);
}
@@ -322,6 +326,9 @@ static void call_usermodehelper_exec_work(struct
work_struct *work)
{
struct subprocess_info *sub_info =
container_of(work, struct subprocess_info, work);
+ if(sub_info->init_intermediate) {
+ sub_info->init_intermediate(sub_info);
+ }
if (sub_info->wait & UMH_WAIT_PROC) {
call_usermodehelper_exec_sync(sub_info);
@@ -334,6 +341,11 @@ static void call_usermodehelper_exec_work(struct
work_struct *work)
*/
pid = kernel_thread(call_usermodehelper_exec_async, sub_info,
CLONE_PARENT | SIGCHLD);
+
+ if(sub_info->cleanup_intermediate) {
+ sub_info->cleanup_i
[PATCH v4 2/3] Limit dump_pipe program's permission to init for container
Currently when we set core_pattern to a pipe, the pipe program is
forked by kthread running with root's permission, and write dumpfile
into host's filesystem.
Same thing happened for container, the dumper and dumpfile are also
in host(not in container).
It have following program:
1: Not consistent with file_type core_pattern
When we set core_pattern to a file, the container will write dump
into container's filesystem instead of host.
2: Not safe for privileged container
In a privileged container, user can destroy host system by following
command:
# # In a container
# echo "|/bin/dd of=/boot/vmlinuz" >/proc/sys/kernel/core_pattern
# make_dump
This patch switch dumper program's environment to init task, so, for
container, dumper program have same environment with init task in
container, which make dumper program put in container's filesystem, and
write coredump into container's filesystem.
The dumper's permission is also limited into subset of container's init
process.
Suggested-by: Eric W. Biederman
Suggested-by: KOSAKI Motohiro
Signed-off-by: Cao ShuFeng
---
fs/coredump.c | 126 +++-
include/linux/binfmts.h | 2 +
2 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 52f2ed6..aa2ef6c 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -502,6 +502,45 @@ static void wait_for_dump_helpers(struct file *file)
}
/*
+ * umh_ns_setup
+ * set the namesapces to the bask task of a container.
+ * we need to switch back to the original namespaces
+ * so that the thread of workqueue is not influlenced.
+ *
+ * this method runs in workqueue kernel thread.
+ */
+static void umh_ns_setup(struct subprocess_info *info)
+{
+ struct coredump_params *cp = (struct coredump_params *)info->data;
+ struct task_struct *base_task = cp->base_task;
+
+ if (base_task) {
+ cp->current_task_nsproxy = current->nsproxy;
+ //prevent current namespace from being freed
+ get_nsproxy(current->nsproxy);
+ /* Set namespaces to base_task */
+ get_nsproxy(base_task->nsproxy);
+ switch_task_namespaces(current, base_task->nsproxy);
+ }
+}
+
+/*
+ * umh_ns_cleanup
+ * cleanup what we have done in umh_ns_setup.
+ *
+ * this method runs in workqueue kernel thread.
+ */
+static void umh_ns_cleanup(struct subprocess_info *info)
+{
+ struct coredump_params *cp = (struct coredump_params *)info->data;
+ struct nsproxy *current_task_nsproxy = cp->current_task_nsproxy;
+ if (current_task_nsproxy) {
+ /* switch workqueue's original namespace back */
+ switch_task_namespaces(current, current_task_nsproxy);
+ }
+}
+
+/*
* umh_pipe_setup
* helper function to customize the process used
* to collect the core in userspace. Specifically
@@ -516,6 +555,8 @@ static int umh_pipe_setup(struct subprocess_info *info,
struct cred *new)
{
struct file *files[2];
struct coredump_params *cp = (struct coredump_params *)info->data;
+ struct task_struct *base_task;
+
int err = create_pipe_files(files, 0);
if (err)
return err;
@@ -524,10 +565,76 @@ static int umh_pipe_setup(struct subprocess_info *info,
struct cred *new)
err = replace_fd(0, files[0], 0);
fput(files[0]);
+ if (err)
+ return err;
+
/* and disallow core files too */
current->signal->rlim[RLIMIT_CORE] = (struct rlimit){1, 1};
- return err;
+ base_task = cp->base_task;
+ if (base_task) {
+ const struct cred *base_cred;
+
+ /* Set fs_root to base_task */
+ spin_lock(&base_task->fs->lock);
+ set_fs_root(current->fs, &base_task->fs->root);
+ set_fs_pwd(current->fs, &base_task->fs->pwd);
+ spin_unlock(&base_task->fs->lock);
+
+ /* Set cgroup to base_task */
+ current->flags &= ~PF_NO_SETAFFINITY;
+ err = cgroup_attach_task_all(base_task, current);
+ if (err < 0)
+ return err;
+
+ /* Set cred to base_task */
+ base_cred = get_task_cred(base_task);
+
+ new->uid = base_cred->uid;
+ new->gid = base_cred->gid;
+ new->suid = base_cred->suid;
+ new->sgid = base_cred->sgid;
+ new->euid = base_cred->euid;
+ new->egid = base_cred->egid;
+ new->fsuid = base_cred->fsuid;
+ new->fsgid = base_cred->fsgid;
+
+ new->securebits = base_cred->securebits;
+
+ new->cap_inheritable = base_cred->cap_inheritable;
+ new->cap_permitted = base_cred->cap_permitted;
+ new->cap_effective = base_cred->cap_effective;
+ new->cap_bset= base_cred->cap_
[PATCH 3/3] ovl: redirect on rename-dir
Current code returns EXDEV when a directory would need to be copied up to
move. We could copy up the directory tree in this case, but there's
another solution: point to old lower directory from moved upper directory.
This is achieved with a "trusted.overlay.redirect" xattr storing the path
relative to the root of the overlay. After such attribute has been set,
the directory can be moved without further actions required.
This is a backward incompatible feature, old kernels won't be able to
correctly mount an overlay containing redirected directories.
Signed-off-by: Miklos Szeredi
---
Documentation/filesystems/overlayfs.txt | 21 ++-
fs/overlayfs/copy_up.c | 20 ++-
fs/overlayfs/dir.c | 86 +++-
fs/overlayfs/namei.c| 99 ++---
fs/overlayfs/overlayfs.h| 4 ++
fs/overlayfs/ovl_entry.h| 4 ++
fs/overlayfs/super.c| 25 +
fs/overlayfs/util.c | 19 +++
8 files changed, 217 insertions(+), 61 deletions(-)
diff --git a/Documentation/filesystems/overlayfs.txt
b/Documentation/filesystems/overlayfs.txt
index 5108425157ac..fae48ab3b36b 100644
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -130,6 +130,23 @@ directory.
Readdir on directories that are not merged is simply handled by the
underlying directory (upper or lower).
+renaming directories
+
+
+When renaming a directory that is on the lower layer or merged (i.e. the
+directory was not created on the upper layer to start with) overlayfs can
+handle it in two different ways:
+
+1) return EXDEV error: this error is returned by rename(2) when trying to
+ move a file or directory across filesystem boundaries. Hence
+ applications are usually prepared to hande this error (mv(1) for example
+ recursively copies the directory tree). This is the default behavior.
+
+2) If the "redirect_dir" feature is enabled, then the directory will be
+ copied up (but not the contents). Then the "trusted.overlay.redirect"
+ extended attribute is set to the path of the original location from the
+ root of the overlay. Finally the directory is moved to the new
+ location.
Non-directories
---
@@ -201,8 +218,8 @@ If a file with multiple hard links is copied up, then this
will
"break" the link. Changes will not be propagated to other names
referring to the same inode.
-Directory trees are not copied up. If rename(2) is performed on a directory
-which is on the lower layer or is merged, then -EXDEV will be returned.
+Unless "redirect_dir" feature is enabled, rename(2) on a lower or merged
+directory will fail with EXDEV.
Changes to underlying filesystems
-
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 49f6158bb04c..0d7075208099 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -323,17 +323,11 @@ static int ovl_copy_up_locked(struct dentry *workdir,
struct dentry *upperdir,
/*
* Copy up a single dentry
*
- * Directory renames only allowed on "pure upper" (already created on
- * upper filesystem, never copied up). Directories which are on lower or
- * are merged may not be renamed. For these -EXDEV is returned and
- * userspace has to deal with it. This means, when copying up a
- * directory we can rely on it and ancestors being stable.
- *
- * Non-directory renames start with copy up of source if necessary. The
- * actual rename will only proceed once the copy up was successful. Copy
- * up uses upper parent i_mutex for exclusion. Since rename can change
- * d_parent it is possible that the copy up will lock the old parent. At
- * that point the file will have already been copied up anyway.
+ * All renames start with copy up of source if necessary. The actual
+ * rename will only proceed once the copy up was successful. Copy up uses
+ * upper parent i_mutex for exclusion. Since rename can change d_parent it
+ * is possible that the copy up will lock the old parent. At that point
+ * the file will have already been copied up anyway.
*/
int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
struct path *lowerpath, struct kstat *stat)
@@ -345,7 +339,6 @@ int ovl_copy_up_one(struct dentry *parent, struct dentry
*dentry,
struct path parentpath;
struct dentry *lowerdentry = lowerpath->dentry;
struct dentry *upperdir;
- struct dentry *upperdentry;
const char *link = NULL;
if (WARN_ON(!workdir))
@@ -371,8 +364,7 @@ int ovl_copy_up_one(struct dentry *parent, struct dentry
*dentry,
pr_err("overlayfs: failed to lock workdir+upperdir\n");
goto out_unlock;
}
- upperdentry = ovl_dentry_upper(dentry);
- if (upperdentry) {
+ if (ovl_dentry_upper(dentry)) {
[PATCH 0/3] overlayfs: allow moving directory trees
This allows overlayfs to move directory trees (residing on lower layer) without having to recursively copy up the whole tree first. This series is available in git at: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git#redirect And is on top of the overlayfs-next branch. --- Miklos Szeredi (3): ovl: check fs features vfs: export vfs_path_lookup() ovl: redirect on rename-dir Documentation/filesystems/overlayfs.txt | 33 ++- fs/internal.h | 2 - fs/overlayfs/copy_up.c | 20 ++- fs/overlayfs/dir.c | 86 +++- fs/overlayfs/namei.c| 99 ++--- fs/overlayfs/overlayfs.h| 5 ++ fs/overlayfs/ovl_entry.h| 4 ++ fs/overlayfs/super.c| 56 +-- fs/overlayfs/util.c | 19 +++ include/linux/namei.h | 2 + 10 files changed, 268 insertions(+), 58 deletions(-) -- 2.5.5
[PATCH 2/3] vfs: export vfs_path_lookup()
Exported to modules, but currently residing in fs/internal.h due to commit
197df04c749a ("rename user_path_umountat() to user_path_mountpoint_at()").
Move back to so that overlayfs can make use of it.
Signed-off-by: Miklos Szeredi
---
fs/internal.h | 2 --
include/linux/namei.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/internal.h b/fs/internal.h
index f4da3341b4a3..800319d11291 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -53,8 +53,6 @@ extern void __init chrdev_init(void);
* namei.c
*/
extern int user_path_mountpoint_at(int, const char __user *, unsigned int,
struct path *);
-extern int vfs_path_lookup(struct dentry *, struct vfsmount *,
- const char *, unsigned int, struct path *);
/*
* namespace.c
diff --git a/include/linux/namei.h b/include/linux/namei.h
index f29abda31e6d..2375bc50a9d3 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -78,6 +78,8 @@ extern struct dentry *user_path_create(int, const char __user
*, struct path *,
extern void done_path_create(struct path *, struct dentry *);
extern struct dentry *kern_path_locked(const char *, struct path *);
extern int kern_path_mountpoint(int, const char *, struct path *, unsigned
int);
+extern int vfs_path_lookup(struct dentry *, struct vfsmount *,
+ const char *, unsigned int, struct path *);
extern struct dentry *lookup_one_len(const char *, struct dentry *, int);
extern struct dentry *lookup_one_len_unlocked(const char *, struct dentry *,
int);
--
2.5.5
[PATCH 1/3] ovl: check fs features
To allow adding new, backward incompatible features to overlayfs, we need a
way to store the list of features in the overlay. This is done via
"trusted.overlay.features" xattr on the root of the upper layer (or one of
the lower layers, that previously acted as an upper layer). It's a comma
separated list of case sensitive strings.
If an overlay has an unknown feature, mount shall return an error. So
mechanism should only be used for backward incompatible features.
This patch doesn't add any features. If the "trusted.overlay.features"
xattr contains a non-empty list, then return EINVAL error for the mount.
Signed-off-by: Miklos Szeredi
Cc:
---
Documentation/filesystems/overlayfs.txt | 12 ++
fs/overlayfs/overlayfs.h| 1 +
fs/overlayfs/super.c| 41 +
3 files changed, 54 insertions(+)
diff --git a/Documentation/filesystems/overlayfs.txt
b/Documentation/filesystems/overlayfs.txt
index 7aeb8e8d80cf..5108425157ac 100644
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -175,6 +175,18 @@ The specified lower directories will be stacked beginning
from the
rightmost one and going left. In the above example lower1 will be the
top, lower2 the middle and lower3 the bottom layer.
+Filesystem features
+---
+
+Features are enabled via "trusted.overlay.features" xattr on the root of the
+upper layer. E.g. the following command can be used to enable features "foo"
+and "bar" on the overlay:
+
+ setfattr -n "trusted.overlay.features" -v "foo,bar" /upper
+ mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
+workdir=/work /merged
+
+If an overlay has an unknown feature, mount shall return an error.
Non-standard behavior
-
diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h
index f6e4d3539a25..d61d5b9d0d91 100644
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -19,6 +19,7 @@ enum ovl_path_type {
#define OVL_XATTR_PREFIX XATTR_TRUSTED_PREFIX "overlay."
#define OVL_XATTR_OPAQUE OVL_XATTR_PREFIX "opaque"
+#define OVL_XATTR_FEATURES OVL_XATTR_PREFIX "features"
#define OVL_ISUPPER_MASK 1UL
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 30263a541fd5..d6dc8d905d00 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -397,6 +397,39 @@ static struct dentry *ovl_workdir_create(struct vfsmount
*mnt,
goto out_unlock;
}
+static int ovl_check_features(struct dentry *root)
+{
+ int res;
+ char *buf, *tmp, *p;
+
+ res = vfs_getxattr(root, OVL_XATTR_FEATURES, NULL, 0);
+ if (res <= 0) {
+ if (res == -EOPNOTSUPP || res == -ENODATA)
+ res = 0;
+ return res;
+ }
+
+ buf = kmalloc(res + 1, GFP_TEMPORARY);
+ if (!buf)
+ return -ENOMEM;
+
+ res = vfs_getxattr(root, OVL_XATTR_FEATURES, buf, res);
+ if (res <= 0)
+ goto out_free;
+
+ buf[res] = '\0';
+ res = 0;
+ tmp = buf;
+ while ((p = strsep(&tmp, ",")) != NULL) {
+ res = -EINVAL;
+ pr_err("overlayfs: feature '%s' not supported\n", p);
+ }
+out_free:
+ kfree(buf);
+
+ return res;
+}
+
static void ovl_unescape(char *s)
{
char *d = s;
@@ -471,6 +504,10 @@ static int ovl_lower_dir(const char *name, struct path
*path, long *namelen,
if (err)
goto out;
+ err = ovl_check_features(path->dentry);
+ if (err)
+ goto out_put;
+
err = vfs_statfs(path, &statfs);
if (err) {
pr_err("overlayfs: statfs failed on '%s'\n", name);
@@ -693,6 +730,10 @@ static int ovl_fill_super(struct super_block *sb, void
*data, int silent)
goto out_put_upperpath;
}
+ err = ovl_check_features(upperpath.dentry);
+ if (err)
+ goto out_put_upperpath;
+
err = ovl_mount_dir(ufs->config.workdir, &workpath);
if (err)
goto out_put_upperpath;
--
2.5.5
Re: [PATCH/RFT v2 11/17] USB: OHCI: make ohci-da8xx a separate driver
On Tue, Oct 25, 2016 at 2:38 AM, David Lechner wrote:
> On 10/24/2016 11:46 AM, ahas...@baylibre.com wrote:
>>
>> From: Manjunath Goudar
>>
>> Separate the Davinci OHCI host controller driver from ohci-hcd
>> host code so that it can be built as a separate driver module.
>> This work is part of enabling multi-platform kernels on ARM;
>> it would be nice to have in 3.11.
>
>
> No need for comment about kernel 3.11.
yes, ok.
>
>>
>> Signed-off-by: Manjunath Goudar
>> ---
>> drivers/usb/host/Kconfig | 2 +-
>> drivers/usb/host/Makefile | 1 +
>> drivers/usb/host/ohci-da8xx.c | 185
>> +-
>> drivers/usb/host/ohci-hcd.c | 18
>> 4 files changed, 76 insertions(+), 130 deletions(-)
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 83b6cec..642c6fe8 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -479,7 +479,7 @@ config USB_OHCI_HCD_OMAP3
>> OMAP3 and later chips.
>>
>> config USB_OHCI_HCD_DAVINCI
>> - bool "OHCI support for TI DaVinci DA8xx"
>> + tristate "OHCI support for TI DaVinci DA8xx"
>> depends on ARCH_DAVINCI_DA8XX
>> depends on USB_OHCI_HCD=y
>
>
> Need to drop the "=y" here, otherwise you still can't compile this as a
> module.
Im able to complile it as a module, but ok ill remove it.
>
>> select PHY_DA8XX_USB
>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
>> index 6ef785b..2644537 100644
>> --- a/drivers/usb/host/Makefile
>> +++ b/drivers/usb/host/Makefile
>> @@ -61,6 +61,7 @@ obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o
>> obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o
>> obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o
>> obj-$(CONFIG_USB_OHCI_HCD_PXA27X) += ohci-pxa27x.o
>> +obj-$(CONFIG_USB_OHCI_HCD_DAVINCI) += ohci-da8xx.o
>>
>> obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
>> obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
>> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
>> index e98066d..5585d9e 100644
>> --- a/drivers/usb/host/ohci-da8xx.c
>> +++ b/drivers/usb/host/ohci-da8xx.c
>> @@ -11,16 +11,31 @@
>> * kind, whether express or implied.
>> */
>>
>> +#include
>> +#include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> -#include
>> #include
>> #include
>> +#include
>
>
> linux/platform_device.h is listed twice
>
>> +#include
>> +#include
>> +#include
>>
>> -#ifndef CONFIG_ARCH_DAVINCI_DA8XX
>> -#error "This file is DA8xx bus glue. Define CONFIG_ARCH_DAVINCI_DA8XX."
>> -#endif
>> +#include "ohci.h"
>> +
>> +#define DRIVER_DESC "OHCI DA8XX driver"
>> +
>> +static const char hcd_name[] = "ohci-da8xx";
>
>
> why static const char instead of #define? This is only used one time in a
> pr_info, so it seems kind of pointless anyway.
Other drivers are using static const for the same variable.
i think static const is preferred over #define because #define doet give a type.
If you dont mind ill keep it static const.
>
>> +
>> +static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
>> +
>> +static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
>> + u16 wValue, u16 wIndex, char *buf, u16 wLength);
>> +static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
>>
>> static struct clk *usb11_clk;
>> static struct phy *usb11_phy;
>> @@ -73,7 +88,7 @@ static void ohci_da8xx_ocic_handler(struct
>> da8xx_ohci_root_hub *hub)
>> hub->set_power(0);
>> }
>>
>> -static int ohci_da8xx_init(struct usb_hcd *hcd)
>> +static int ohci_da8xx_reset(struct usb_hcd *hcd)
>> {
>> struct device *dev = hcd->self.controller;
>> struct da8xx_ohci_root_hub *hub = dev_get_platdata(dev);
>> @@ -93,7 +108,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
>> */
>> ohci->num_ports = 1;
>>
>> - result = ohci_init(ohci);
>> + result = ohci_setup(hcd);
>> if (result < 0) {
>> ohci_da8xx_disable();
>> return result;
>> @@ -121,30 +136,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
>> return result;
>> }
>>
>> -static void ohci_da8xx_stop(struct usb_hcd *hcd)
>> -{
>> - ohci_stop(hcd);
>> - ohci_da8xx_disable();
>> -}
>> -
>> -static int ohci_da8xx_start(struct usb_hcd *hcd)
>> -{
>> - struct ohci_hcd *ohci = hcd_to_ohci(hcd);
>> - int result;
>> -
>> - result = ohci_run(ohci);
>> - if (result < 0)
>> - ohci_da8xx_stop(hcd);
>> -
>> - return result;
>> -}
>> -
>> /*
>> * Update the status data from the hub with the over-current indicator
>> change.
>> */
>> static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
>> {
>> - int length = ohci_hub_status_data(hcd, buf);
>> + int length = orig_ohci_hub_status_data(hcd, buf);
>>
>>
Re: [PATCH v4] [media] vb2: Add support for capture_dma_bidirectional queue flag
Hi Thierry,
On Mon, Oct 24, 2016 at 09:30:21AM +0200, Thierry Escande wrote:
...
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -433,6 +433,9 @@ struct vb2_buf_ops {
> * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when
> QBUF
> * has not been called. This is a vb1 idiom that has been
> adopted
> * also by vb2.
> + * @capture_dma_bidirectional: use DMA_BIDIRECTIONAL for CAPTURE
> buffers; this
> + * allows HW to read from the CAPTURE buffers in
> + * addition to writing; ignored for OUTPUT queues.
> * @lock:pointer to a mutex that protects the vb2_queue struct. The
> * driver can set this to a mutex to let the v4l2 core serialize
> * the queuing ioctls. If the driver wants to handle locking
> @@ -499,6 +502,7 @@ struct vb2_queue {
> unsignedfileio_write_immediately:1;
> unsignedallow_zero_bytesused:1;
> unsigned quirk_poll_must_check_waiting_for_buffers:1;
> + unsignedcapture_dma_bidirectional:1;
>
> struct mutex*lock;
> void*owner;
> @@ -554,6 +558,26 @@ struct vb2_queue {
> #endif
> };
>
> +/*
> + * Returns the corresponding DMA direction given the vb2_queue type (capture
> or
> + * output). Returns DMA_BIDIRECTIONAL for capture buffers if the vb2_queue
> field
> + * capture_dma_bidirectional is set by the driver.
> + */
> +#define VB2_DMA_DIR(q) (V4L2_TYPE_IS_OUTPUT((q)->type) \
q->is_output is assigned in vb2_queue_init():
q->is_output = V4L2_TYPE_IS_OUTPUT(q->type);
Could you use that instead?
With that changed,
Acked-by: Sakari Ailus
> + ? DMA_TO_DEVICE \
> + : (q)->capture_dma_bidirectional \
> + ? DMA_BIDIRECTIONAL\
> + : DMA_FROM_DEVICE)
> +
> +/*
> + * Returns true if the DMA direction passed as parameter refers to a capture
> + * buffer as capture buffers allow both FROM_DEVICE and BIDIRECTIONAL DMA
> + * direction. This test is used to map virtual addresses for writing and to
> mark
> + * pages as dirty.
> + */
> +#define VB2_DMA_DIR_CAPTURE(d) \
> + ((d) == DMA_FROM_DEVICE || (d) == DMA_BIDIRECTIONAL)
> +
> /**
> * vb2_plane_vaddr() - Return a kernel virtual address of a given plane
> * @vb: vb2_buffer to which the plane in question belongs to
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
On Mon, 24 Oct 2016, Peter Griffin wrote:
> Hi Lee,
>
> On Mon, 24 Oct 2016, Lee Jones wrote:
> > On Tue, 18 Oct 2016, Peter Griffin wrote:
> >
> > > Once the ST frontend demux HW IP has been enabled, the clock can't
> > > be disabled otherwise the system will hang and the board will
> > > be unserviceable.
> > >
> > > To allow balanced clock enable/disable calls in the driver we use
> > > the critical clock infrastructure to take an extra reference on the
> > > clock so the clock will never actually be disabled.
> >
> > This is an abuse of the critical-clocks framework, and is exactly the
> > type of hack I promised the clk guys I'd try to prevent.
>
> I expect the best way to do this would be to write some documentation on the
> clock-critical DT binding and/or CRITICAL_CLK flag. The only documentation I
> can
> find currently is with the initial patch series [1] and the comment in
> clk-provider.h of
>
> #define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */
>
> Or the patch decription
>
> "Critical clocks are those which must not be gated, else undefined
> or catastrophic failure would occur. Here we have chosen to
> ensure the prepare/enable counts are correctly incremented, so as
> not to confuse users with enabled clocks with no visible users."
>
> Which is the functionality I want for this clock.
No, that's not the functionality you want. You want for the clock not
to be RE-gated (big difference). Currently, the STFE clock will never
be gated, even when a) it's not used and b) can actually be disabled.
You're needlessly wasting power here.
Also, in your use-case there is a visible user, and the prepare/enable
counts will be correct.
> > If this, or
> > any other IP has some quirks (i.e. once enabled, if this clock is
> > subsequently disabled it will have a catastrophic effect on the
> > platform), then they should be worked around in the driver.
> >
> > The correct thing to do here is craft a clk-keep-on flag and ensure it
> > is set to true for the effected platform(s)' platform data.
>
> I'm always wary of creating a driver specific flag, especially when its
> purpose is to do the same thing as an existing mechanism provided by the
> subsystem of not gating the clock.
Using existing sub-system supplied mechanisms in the way they were not
intended is sub-optimal (read "hacky").
> I can see a couple of problems with what you propose:
>
> 1) You have to put the clk-keep-on flag in every driver which consumes the
> clock. IMO it is much better to have this knowledge in the SoC's
> clock driver so every consumer of the clock automatically benefits.
That would also be fine(ish). The issue is that this problem is
board specific, so the platform clock driver would have to contain
board level knowledge. Also, if you were to implement this, it would
too mess up reference counting in the core.
> 2) You don't benefit from the CLK_IS_CRITICAL reference counting logic in
> clk.c. So then each driver has to also work around that to get sensible
> reference
> counts. e.g.
>
> if (!__clk_is_enabled(clk) && pdata->clk-keep-on)
>clk_enable(clk)
>
> Which seems to me to be fighting against the subsystem. Given that the only
> use of
> _clk_is_enabled() outside drivers/clk is in an old
> arch/arm/mach-omap2/pm24xx.c
> driver I suspect its use is frowned upon, and it shouldn't really be an
> EXPORTED_SYMBOL.
In this instance, since the STFE clock is only used by this IP, I
would choose to handle it in the driver. This can be done using a
single flag stored in pdata which should be fetched using
of_match_device(). This way there is no need for any more API abuse;
either by incorrectly identifying the STFE clock as critical OR
invoking any internal __clk_*() calls.
Enable the clock once in .probe(), which you already do.
Then, whenever you do any power saving do:
suspend()
{
if (!ddata->enable_clk_once)
clk_disable(clk);
}
resume()
{
if (!ddata->enable_clk_once)
clk_enable(clk);
}
However, looking at your driver, I think this point might even be
moot, since you don't have any power saving. The only time you
disable the clock is in the error path. Just replace that with a
comment about the platform's unfortunate errata.
> [1] https://lkml.org/lkml/2016/1/18/272
I'm glad you mentioned this. Let's take a look:
> Some platforms contain clocks which if gated, will cause undefined or
> catastrophic behaviours. As such they are not to be turned off, ever.
Not the case here.
This clock *can* be gated and can be turned off *sometimes*.
> Many of these such clocks do not have devices, thus device drivers
> where clocks may be enabled and references taken to ensure they stay
> enabled do not exist. Therefore, we must handle these such cases in
> the core.
This clock *does* have a driver and correct references *can* be
taken.
[...]
All I'm saying is, and it's the same thing I've said many times; these
types of issue
Re: [PATCH v3 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly
On Fri, Oct 14, 2016 at 09:38:21AM +0200, Johannes Thumshirn wrote:
> On Thu, Oct 13, 2016 at 05:55:11PM +0200, Steffen Maier wrote:
> > Hm, still behaves for me like I reported for v2:
> > http://marc.info/?l=linux-scsi&m=147637177902937&w=2
>
> Hi Steffen,
>
> Can you please try the following on top of 2/16?
>
> diff --git a/drivers/scsi/scsi_transport_fc.c
> b/drivers/scsi/scsi_transport_fc.c
> index 4149dac..baebaab 100644
> --- a/drivers/scsi/scsi_transport_fc.c
> +++ b/drivers/scsi/scsi_transport_fc.c
> @@ -3786,6 +3786,12 @@ enum fc_dispatch_result {
> int cmdlen = sizeof(uint32_t); /* start with length of msgcode */
> int ret;
>
> + /* check if we really have all the request data needed */
> + if (job->request_len < cmdlen) {
> + ret = -ENOMSG;
> + goto fail_host_msg;
> + }
> +
> /* Validate the host command */
> switch (bsg_request->msgcode) {
> case FC_BSG_HST_ADD_RPORT:
> @@ -3831,12 +3837,6 @@ enum fc_dispatch_result {
> goto fail_host_msg;
> }
>
> - /* check if we really have all the request data needed */
> - if (job->request_len < cmdlen) {
> - ret = -ENOMSG;
> - goto fail_host_msg;
> - }
> -
> ret = i->f->bsg_request(job);
> if (!ret)
> return FC_DISPATCH_UNLOCKED;
> @@ -3887,6 +3887,12 @@ enum fc_dispatch_result {
> int cmdlen = sizeof(uint32_t); /* start with length of msgcode */
> int ret;
>
> + /* check if we really have all the request data needed */
> + if (job->request_len < cmdlen) {
> + ret = -ENOMSG;
> + goto fail_rport_msg;
> + }
> +
> /* Validate the rport command */
> switch (bsg_request->msgcode) {
> case FC_BSG_RPT_ELS:
>
>
>
> The rational behind this is, in fc_req_to_bsgjob() we're assigning
> job->request as req->cmd and job->request_len = req->cmd_len. But without
> checkinf job->request_len we don't know whether we're save to touch
> job->request (a.k.a. bsg_request).
Hi Steffen,
Did you have any chance testing this? I hacked fcping to work with non-FCoE
and rports as well and tested with FCoE and lpfc. No problems seen from my
side. I've also pused the series (With this change folded in) to my git
tree at [1] if this helps you in any way.
[1]
https://git.kernel.org/cgit/linux/kernel/git/jth/linux.git/log/?h=scsi-bsg-rewrite-v4
Thanks a lot,
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 05/14] staging: fsl-mc: update MAINTAINERS
On Mon, Oct 17, 2016 at 01:42:47PM -0500, Stuart Yoder wrote: > -German has moved on to other things and wished to be > removed as a maintainer > -cleanup the driver description to use the proper name > of the driver (i.e. the fsl-mc bus driver) and remove incorrect > references to Freescale > > Signed-off-by: Stuart Yoder > Acked-by: J. German Rivera > --- > MAINTAINERS | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1cd38a7..797a08a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5091,8 +5091,7 @@ F: sound/soc/fsl/fsl* > F: sound/soc/fsl/imx* > F: sound/soc/fsl/mpc8610_hpcd.c > > -FREESCALE QORIQ MANAGEMENT COMPLEX DRIVER > -M: "J. German Rivera" > +QORIQ DPAA2 FSL-MC BUS DRIVER > M: Stuart Yoder > L: linux-kernel@vger.kernel.org > S: Maintained This is now not sorted properly, right? Please resend it and place it in the correct location in the file. thanks, greg k-h
Re: [PATCH 09/14] staging: fsl-mc: misc whitespace cleanup
On Mon, Oct 17, 2016 at 01:43:16PM -0500, Stuart Yoder wrote: > From: Ioana Ciornei > > Make whitespace consistent with other fsl-mc source files. > -delete extraneous tabs > -align start of function arguments properly > -for structs and function definitions, separate type and >variable name by a single space > -remove multiple blank lines in comments That's a lot of different types of whitespace cleanups to do all at once, can I get some sort of verification that this produces the same .o files? I wouldn't accept a patch like this from anyone else, why should it be ok for you to send it? thanks, greg k-h
Re: [PATCH 11/14] staging: fsl-mc: message cleanup
On Mon, Oct 17, 2016 at 01:43:39PM -0500, Stuart Yoder wrote: > Cleanup and clarify messages > -use "fsl-mc" prefix for all messages that don't come from dev_* >functions Nope, please use the proper pr_fmt() #define at the top of the file, that way you don't have to put the string into all pr_* calls. > -remove unnecessary verbosity to make things clearer > -use explicit __func__ arguments to clarify some error messages > -improve misc wording for clarity That's alot of different things. Again, if you have to list the different things you do in a patch, that means you should break it up into smaller ones. Yes, this is a "tiny" patch, but I can't take it because of the above problem, while if you had broken it up into smaller ones, I could have taken all but the pr_* changes :( thanks, greg k-h
Re: [PATCH 14/14] staging: fsl-mc: uprev binary interface to match MC v10.x
On Mon, Oct 17, 2016 at 01:43:58PM -0500, Stuart Yoder wrote: > From: Ioana Ciornei > > DPAA2 will not support MC firmware versions prior to MC v10.x. > Update the MC interface code and drivers to reflect this. >-update the object .h files and code that builds commands to include > the new command version in the command header >-object versions are no longer available in the object attributes, > so remove references to them and instead get the version from the > new get_api_version() command >-create/destroy commands for all objects have new arguments >-dpmng_get_container_id() is replaced by dprc_get_container_id() Again, that's a lot of different things to do all at once, can you break this up? thanks, greg k-h
Re: [PATCH 00/14] staging: fsl-mc: cleanup and uprev to MC v10.x
On Mon, Oct 17, 2016 at 01:42:09PM -0500, Stuart Yoder wrote: > This patch does miscellaneous minor cleanup and uprevs the supported > MC firmware version to 10.x. > > I believe with this series the TODO items on our list are complete, > with the exception of "Add at least one device driver for a DPAA2 > object", which I expect to send a patch for very soon. I plan to > do that in conjunction with a request to move the fsl-mc bus > driver out of staging. I applied some of these patches, can you rebase and fix up and resend the remaining ones? thanks, greg k-h
[PATCH stable 4.4 3/4] mm: filemap: fix mapping->nrpages double accounting in fuse
From: Johannes Weiner
Commit 3ddf40e8c31964b744ff10abb48c8e36a83ec6e7 upstream.
Commit 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker
caused by replace_page_cache_page()") switched replace_page_cache() from
raw radix tree operations to page_cache_tree_insert() but didn't take
into account that the latter function, unlike the raw radix tree op,
handles mapping->nrpages. As a result, that counter is bumped for each
page replacement rather than balanced out even.
The mapping->nrpages counter is used to skip needless radix tree walks
when invalidating, truncating, syncing inodes without pages, as well as
statistics for userspace. Since the error is positive, we'll do more
page cache tree walks than necessary; we won't miss a necessary one.
And we'll report more buffer pages to userspace than there are. The
error is limited to fuse inodes.
Fixes: 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused
by replace_page_cache_page()")
Signed-off-by: Johannes Weiner
Cc: Andrew Morton
Cc: Miklos Szeredi
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Michal Hocko
---
mm/filemap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 7ad648c9780c..c588d1222b2a 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -590,7 +590,6 @@ int replace_page_cache_page(struct page *old, struct page
*new, gfp_t gfp_mask)
__delete_from_page_cache(old, NULL, memcg);
error = page_cache_tree_insert(mapping, new, NULL);
BUG_ON(error);
- mapping->nrpages++;
/*
* hugetlb pages do not participate in page cache accounting.
--
2.9.3
[PATCH stable 4.4 0/4] mm: workingset backports
Hi,
here is the backport of (hopefully) all workingset related fixes for
4.4 kernel. The series has been reviewed by Johannes [1]. The main
motivation for the backport is 22f2ac51b6d6 ("mm: workingset: fix crash
in shadow node shrinker caused by replace_page_cache_page()") which is
a fix for a triggered BUG_ON. This is not sufficient because there are
follow up fixes which were introduced later.
[PATCH stable 4.4 4/4] Using BUG_ON() as an assert() is _never_ acceptable
From: Linus Torvalds
Commit 21f54ddae449f4bdd9f1498124901d67202243d9 upstream.
That just generally kills the machine, and makes debugging only much
harder, since the traces may long be gone.
Debugging by assert() is a disease. Don't do it. If you can continue,
you're much better off doing so with a live machine where you have a
much higher chance that the report actually makes it to the system logs,
rather than result in a machine that is just completely dead.
The only valid situation for BUG_ON() is when continuing is not an
option, because there is massive corruption. But if you are just
verifying that something is true, you warn about your broken assumptions
(preferably just once), and limp on.
Fixes: 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused
by replace_page_cache_page()")
Cc: Johannes Weiner
Cc: Miklos Szeredi
Cc: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Michal Hocko
---
include/linux/swap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index b28de19aadbf..d8ca2eaa3a8b 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -266,7 +266,7 @@ static inline void workingset_node_pages_inc(struct
radix_tree_node *node)
static inline void workingset_node_pages_dec(struct radix_tree_node *node)
{
- VM_BUG_ON(!workingset_node_pages(node));
+ VM_WARN_ON_ONCE(!workingset_node_pages(node));
node->count--;
}
@@ -282,7 +282,7 @@ static inline void workingset_node_shadows_inc(struct
radix_tree_node *node)
static inline void workingset_node_shadows_dec(struct radix_tree_node *node)
{
- VM_BUG_ON(!workingset_node_shadows(node));
+ VM_WARN_ON_ONCE(!workingset_node_shadows(node));
node->count -= 1U << RADIX_TREE_COUNT_SHIFT;
}
--
2.9.3
[PATCH stable 4.4 2/4] mm: filemap: don't plant shadow entries without radix tree node
From: Johannes Weiner
commit d3798ae8c6f3767c726403c2ca6ecc317752c9dd upstream.
When the underflow checks were added to workingset_node_shadow_dec(),
they triggered immediately:
kernel BUG at ./include/linux/swap.h:276!
invalid opcode: [#1] SMP
Modules linked in: isofs usb_storage fuse xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast
ip6t_REJECT nf_reject_ipv6
soundcore wmi acpi_als pinctrl_sunrisepoint kfifo_buf tpm_tis industrialio
acpi_pad pinctrl_intel tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace
sunrpc dm_crypt
CPU: 0 PID: 20929 Comm: blkid Not tainted 4.8.0-rc8-00087-gbe67d60ba944 #1
Hardware name: System manufacturer System Product Name/Z170-K, BIOS 1803
05/06/2016
task: 8faa93ecd940 task.stack: 8faa7f478000
RIP: page_cache_tree_insert+0xf1/0x100
Call Trace:
__add_to_page_cache_locked+0x12e/0x270
add_to_page_cache_lru+0x4e/0xe0
mpage_readpages+0x112/0x1d0
blkdev_readpages+0x1d/0x20
__do_page_cache_readahead+0x1ad/0x290
force_page_cache_readahead+0xaa/0x100
page_cache_sync_readahead+0x3f/0x50
generic_file_read_iter+0x5af/0x740
blkdev_read_iter+0x35/0x40
__vfs_read+0xe1/0x130
vfs_read+0x96/0x130
SyS_read+0x55/0xc0
entry_SYSCALL_64_fastpath+0x13/0x8f
Code: 03 00 48 8b 5d d8 65 48 33 1c 25 28 00 00 00 44 89 e8 75 19 48 83 c4 18
5b 41 5c 41 5d 41 5e 5d c3 0f 0b 41 bd ef ff ff ff eb d7 <0f> 0b e8 88 68 ef ff
0f 1f 84 00
RIP page_cache_tree_insert+0xf1/0x100
This is a long-standing bug in the way shadow entries are accounted in
the radix tree nodes. The shrinker needs to know when radix tree nodes
contain only shadow entries, no pages, so node->count is split in half
to count shadows in the upper bits and pages in the lower bits.
Unfortunately, the radix tree implementation doesn't know of this and
assumes all entries are in node->count. When there is a shadow entry
directly in root->rnode and the tree is later extended, the radix tree
implementation will copy that entry into the new node and and bump its
node->count, i.e. increases the page count bits. Once the shadow gets
removed and we subtract from the upper counter, node->count underflows
and triggers the warning. Afterwards, without node->count reaching 0
again, the radix tree node is leaked.
Limit shadow entries to when we have actual radix tree nodes and can
count them properly. That means we lose the ability to detect refaults
from files that had only the first page faulted in at eviction time.
[han...@cmpxchg.org: backport for 4.4 stable]
Fixes: 449dd6984d0e ("mm: keep page cache radix tree nodes in check")
Signed-off-by: Johannes Weiner
Reported-and-tested-by: Linus Torvalds
Reviewed-by: Jan Kara
Cc: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Michal Hocko
---
mm/filemap.c | 8
1 file changed, 8 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index 4cfe423d3e8a..7ad648c9780c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -164,6 +164,14 @@ static void page_cache_tree_delete(struct address_space
*mapping,
__radix_tree_lookup(&mapping->page_tree, page->index, &node, &slot);
+ if (!node) {
+ /*
+* We need a node to properly account shadow
+* entries. Don't plant any without. XXX
+*/
+ shadow = NULL;
+ }
+
if (shadow) {
mapping->nrshadows++;
/*
--
2.9.3
[PATCH stable 4.4 1/4] mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()
From: Johannes Weiner
Commit 22f2ac51b6d643666f4db093f13144f773ff3f3a upstream.
Antonio reports the following crash when using fuse under memory pressure:
kernel BUG at /build/linux-a2WvEb/linux-4.4.0/mm/workingset.c:346!
invalid opcode: [#1] SMP
Modules linked in: all of them
CPU: 2 PID: 63 Comm: kswapd0 Not tainted 4.4.0-36-generic #55-Ubuntu
Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904
04/27/2013
task: 88040cae6040 ti: 880407488000 task.ti: 880407488000
RIP: shadow_lru_isolate+0x181/0x190
Call Trace:
__list_lru_walk_one.isra.3+0x8f/0x130
list_lru_walk_one+0x23/0x30
scan_shadow_nodes+0x34/0x50
shrink_slab.part.40+0x1ed/0x3d0
shrink_zone+0x2ca/0x2e0
kswapd+0x51e/0x990
kthread+0xd8/0xf0
ret_from_fork+0x3f/0x70
which corresponds to the following sanity check in the shadow node
tracking:
BUG_ON(node->count & RADIX_TREE_COUNT_MASK);
The workingset code tracks radix tree nodes that exclusively contain
shadow entries of evicted pages in them, and this (somewhat obscure)
line checks whether there are real pages left that would interfere with
reclaim of the radix tree node under memory pressure.
While discussing ways how fuse might sneak pages into the radix tree
past the workingset code, Miklos pointed to replace_page_cache_page(),
and indeed there is a problem there: it properly accounts for the old
page being removed - __delete_from_page_cache() does that - but then
does a raw raw radix_tree_insert(), not accounting for the replacement
page. Eventually the page count bits in node->count underflow while
leaving the node incorrectly linked to the shadow node LRU.
To address this, make sure replace_page_cache_page() uses the tracked
page insertion code, page_cache_tree_insert(). This fixes the page
accounting and makes sure page-containing nodes are properly unlinked
from the shadow node LRU again.
Also, make the sanity checks a bit less obscure by using the helpers for
checking the number of pages and shadows in a radix tree node.
[mho...@suse.com: backport for 4.4]
Fixes: 449dd6984d0e ("mm: keep page cache radix tree nodes in check")
Link: http://lkml.kernel.org/r/20160919155822.29498-1-han...@cmpxchg.org
Signed-off-by: Johannes Weiner
Reported-by: Antonio SJ Musumeci
Debugged-by: Miklos Szeredi
Cc: [3.15+]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Michal Hocko
---
include/linux/swap.h | 2 ++
mm/filemap.c | 86 ++--
mm/workingset.c | 10 +++---
3 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 7ba7dccaf0e7..b28de19aadbf 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -266,6 +266,7 @@ static inline void workingset_node_pages_inc(struct
radix_tree_node *node)
static inline void workingset_node_pages_dec(struct radix_tree_node *node)
{
+ VM_BUG_ON(!workingset_node_pages(node));
node->count--;
}
@@ -281,6 +282,7 @@ static inline void workingset_node_shadows_inc(struct
radix_tree_node *node)
static inline void workingset_node_shadows_dec(struct radix_tree_node *node)
{
+ VM_BUG_ON(!workingset_node_shadows(node));
node->count -= 1U << RADIX_TREE_COUNT_SHIFT;
}
diff --git a/mm/filemap.c b/mm/filemap.c
index 1bb007624b53..4cfe423d3e8a 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -109,6 +109,48 @@
* ->tasklist_lock(memory_failure, collect_procs_ao)
*/
+static int page_cache_tree_insert(struct address_space *mapping,
+ struct page *page, void **shadowp)
+{
+ struct radix_tree_node *node;
+ void **slot;
+ int error;
+
+ error = __radix_tree_create(&mapping->page_tree, page->index,
+ &node, &slot);
+ if (error)
+ return error;
+ if (*slot) {
+ void *p;
+
+ p = radix_tree_deref_slot_protected(slot, &mapping->tree_lock);
+ if (!radix_tree_exceptional_entry(p))
+ return -EEXIST;
+ if (shadowp)
+ *shadowp = p;
+ mapping->nrshadows--;
+ if (node)
+ workingset_node_shadows_dec(node);
+ }
+ radix_tree_replace_slot(slot, page);
+ mapping->nrpages++;
+ if (node) {
+ workingset_node_pages_inc(node);
+ /*
+* Don't track node that contains actual pages.
+*
+* Avoid acquiring the list_lru lock if already
+* untracked. The list_empty() test is safe as
+* node->private_list is protected by
+* mapping->tree_lock.
+*/
+ if (!list_empty(&node->private_list))
+ list_lru_del(&workingset_shadow_nodes,
+
Re: [PATCH 3/5] staging/vchi: Fix some pointer math for 64-bit.
On Mon, Oct 17, 2016 at 12:44:04PM -0700, Eric Anholt wrote: > These were throwing warnings on aarch64, and all are trivially > converted to longs. > > Signed-off-by: Eric Anholt > --- > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 6 +++--- > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 5 +++-- > 2 files changed, 6 insertions(+), 5 deletions(-) This didnt apply anymore as I think I took the other fixups, sorry. greg k-h
Re: [PATCH stable 4.4 0/4] mm: workingset backports
On Tue 25-10-16 09:51:44, Michal Hocko wrote:
> Hi,
> here is the backport of (hopefully) all workingset related fixes for
> 4.4 kernel. The series has been reviewed by Johannes [1]. The main
> motivation for the backport is 22f2ac51b6d6 ("mm: workingset: fix crash
> in shadow node shrinker caused by replace_page_cache_page()") which is
> a fix for a triggered BUG_ON. This is not sufficient because there are
> follow up fixes which were introduced later.
Ups, forgot to add
[1] http://lkml.kernel.org/r/20161024152605.11707-1-mho...@kernel.org
--
Michal Hocko
SUSE Labs
Re: [PATCH v1] I2C Designware Core Supports SMBUS BLOCK
Hi On 10/25/2016 07:35 AM, tnhu...@apm.com wrote: --- a/drivers/i2c/busses/i2c-designware-platdrv.c +++ b/drivers/i2c/busses/i2c-designware-platdrv.c @@ -220,6 +220,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev) I2C_FUNC_SMBUS_BYTE | I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA | + I2C_FUNC_SMBUS_BLOCK_DATA | I2C_FUNC_SMBUS_I2C_BLOCK; I guess you need to add the same to DW_DEFAULT_FUNCTIONALITY in drivers/i2c/busses/i2c-designware-pcidrv.c too. -- Jarkko
Re: [PATCH][V2] drm/amd/powerplay: fix spelling mistake and add KERN_WARNING to printks
Am 25.10.2016 um 01:14 schrieb Colin King:
From: Colin Ian King
Fix trivial spelling mistake cant't -> can't and add KERN_WARNING to
printk messages. Remove redundant spaces before \n too (thanks to
Joe Perches for spotting those).
Signed-off-by: Colin Ian King
Reviewed-by: Christian König .
---
drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c | 4 ++--
drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 4 ++--
drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 ++--
drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
index 76310ac..62e99d7 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
@@ -2125,7 +2125,7 @@ uint32_t fiji_get_offsetof(uint32_t type, uint32_t member)
return offsetof(SMU73_Discrete_DpmTable,
LowSclkInterruptThreshold);
}
}
- printk("cant't get the offset of type %x member %x \n", type, member);
+ printk(KERN_WARNING "can't get the offset of type %x member %x\n",
type, member);
return 0;
}
@@ -2150,7 +2150,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
return SMU73_MAX_LEVELS_MVDD;
}
- printk("cant't get the mac of %x \n", value);
+ printk(KERN_WARNING "can't get the mac of %x\n", value);
return 0;
}
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
index 8c889ca..0cc20a8 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
@@ -2140,7 +2140,7 @@ uint32_t iceland_get_offsetof(uint32_t type, uint32_t
member)
return offsetof(SMU71_Discrete_DpmTable,
LowSclkInterruptThreshold);
}
}
- printk("cant't get the offset of type %x member %x \n", type, member);
+ printk(KERN_WARNING "can't get the offset of type %x member %x\n",
type, member);
return 0;
}
@@ -2163,7 +2163,7 @@ uint32_t iceland_get_mac_definition(uint32_t value)
return SMU71_MAX_LEVELS_MVDD;
}
- printk("cant't get the mac of %x \n", value);
+ printk(KERN_WARNING "can't get the mac of %x\n", value);
return 0;
}
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
index 4ccc0b7..7236c51 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
@@ -2174,7 +2174,7 @@ uint32_t polaris10_get_offsetof(uint32_t type, uint32_t
member)
return offsetof(SMU74_Discrete_DpmTable,
LowSclkInterruptThreshold);
}
}
- printk("cant't get the offset of type %x member %x \n", type, member);
+ printk(KERN_WARNING "can't get the offset of type %x member %x\n",
type, member);
return 0;
}
@@ -2201,7 +2201,7 @@ uint32_t polaris10_get_mac_definition(uint32_t value)
return SMU7_UVD_MCLK_HANDSHAKE_DISABLE;
}
- printk("cant't get the mac of %x \n", value);
+ printk(KERN_WARNING "can't get the mac of %x\n", value);
return 0;
}
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
index de2a24d..d08f6f1 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
@@ -2651,7 +2651,7 @@ uint32_t tonga_get_offsetof(uint32_t type, uint32_t
member)
return offsetof(SMU72_Discrete_DpmTable,
LowSclkInterruptThreshold);
}
}
- printk("cant't get the offset of type %x member %x\n", type, member);
+ printk(KERN_WARNING "can't get the offset of type %x member %x\n",
type, member);
return 0;
}
@@ -2675,7 +2675,7 @@ uint32_t tonga_get_mac_definition(uint32_t value)
case SMU_MAX_LEVELS_MVDD:
return SMU72_MAX_LEVELS_MVDD;
}
- printk("cant't get the mac value %x\n", value);
+ printk(KERN_WARNING "can't get the mac value %x\n", value);
return 0;
}
Re: [PATCH 5/7] ASoC: constify snd_soc_ops structures
On Tue, 2016-10-25 at 07:55 +0200, Julia Lawall wrote: > On Mon, 24 Oct 2016, Mark Brown wrote: > > On Sat, Oct 15, 2016 at 04:55:49PM +0200, Julia Lawall wrote: > > > --- > > > sound/soc/generic/simple-card.c |2 +- [...] > > > sound/soc/mxs/mxs-sgtl5000.c|2 +- > > > 16 files changed, 28 insertions(+), 28 deletions(-) > > > > You split out a few drivers as separate patches but not these ones - > > what's special about these ones? > > If it's preferred, I could send them all one file at a time, or when the > maintainers are very similar just send one patch to all the maintainers. Whatever works. There's no single style appropriate for the entire kernel.
Re: [PATCH/RFT v2 17/17] ARM: dts: da850: add usb device node
On Tue, Oct 25, 2016 at 2:48 AM, David Lechner wrote:
> On 10/24/2016 11:46 AM, ahas...@baylibre.com wrote:
>>
>> From: Axel Haslam
>>
>> This adds the usb (ohci) device node for the da850 soc.
>> Also it enables it for the lcdk board
>>
>> Signed-off-by: Axel Haslam
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 8
>> arch/arm/boot/dts/da850.dtsi | 8
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts
>> index 7b8ab21..fa91339 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -86,6 +86,14 @@
>> };
>> };
>>
>> +&usb_phy {
>> + status = "okay";
>> +};
>> +
>> +&usb {
>> + status = "okay";
>
>
> Don't you need to specify a regulator here using the vbus-supply property?
its is not mandatory, the regulator framework is giving a dummy supply
on regulator_get if it does not find a regulator on device tree. That is
what i could understand from: _regulator_get in regulator/core.c
Also, in the case of platform based boot, if the board init calls
regulator_has_full_constraints which is anyways needed for the phy to probe
correctly it will also return a dummy regulator.
>
>> +};
>> +
>> &serial2 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&serial2_rxtx_pins>;
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 33fcdce..ec2cec3 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -381,6 +381,14 @@
>> #phy-cells = <1>;
>> status = "disabled";
>> };
>> + usb: usb@0225000 {
>
>
> Don't need the leading 0 on usb@225000
>
> The alias (usb:) might need to be more specific since there is a second usb
> device that will be added later for musb. (The comments in the previous
> review only referred to the "usb" in "usb@", not the alias.)
ok.
>
>> + compatible = "ti,da830-ohci";
>> + reg = <0x225000 0x1000>;
>> + interrupts = <59>;
>> + phys = <&usb_phy 1>;
>> + phy-names = "usb-phy";
>> + status = "disabled";
>> + };
>> gpio: gpio@226000 {
>> compatible = "ti,dm6441-gpio";
>> gpio-controller;
>>
>
Re: [PATCH v2] drm/fb-helper: Don't call dirty callback for untouched clips
On Tue, Oct 25, 2016 at 08:46:28AM +0200, Takashi Iwai wrote:
> On Fri, 21 Oct 2016 14:52:07 +0200,
> Ville Syrjälä wrote:
> >
> > On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wrote:
> > > Since 4.7 kernel, we've seen the error messages like
> > >
> > > kernel: [TTM] Buffer eviction failed
> > > kernel: qxl :00:02.0: object_init failed for (4026540032, 0x0001)
> > > kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate
> > > VRAM BO
> > >
> > > on QXL when switching and accessing on VT. The culprit was the
> > > generic deferred_io code (qxl driver switched to it since 4.7).
> > > There is a race between the dirty clip update and the call of
> > > callback.
> > >
> > > In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
> > > while it kicks off the update worker outside the spinlock. Meanwhile
> > > the update worker clears the dirty clip in the spinlock, too. Thus,
> > > when drm_fb_helper_dirty() is called concurrently, schedule_work() is
> > > called after the clip is cleared in the first worker call.
> > >
> > > This patch addresses it by validating the clip before calling the
> > > dirty fb callback.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
> > > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
> > > Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support')
> > > Cc:
> > > Signed-off-by: Takashi Iwai
> >
> > Reviewed-by: Ville Syrjälä
>
> Daniel, could you pick this if it's OK as a quick fix? Currently
> qxl driver is utterly broken, and we should recover it ASAP. On top
> of this, we can put a more comprehensive fix covering both this and
> dirtyfb ioctl code paths.
I thought I've pinged Dave already to pick up, I'll poke him again.
-Daniel
>
>
> thanks,
>
> Takashi
>
> >
> > > ---
> > > v1->v2: simplified the code as suggested by Ville
> > >
> > > drivers/gpu/drm/drm_fb_helper.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 03414bde1f15..aae7df01864d 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -644,7 +644,9 @@ static void drm_fb_helper_dirty_work(struct
> > > work_struct *work)
> > > clip->x2 = clip->y2 = 0;
> > > spin_unlock_irqrestore(&helper->dirty_lock, flags);
> > >
> > > - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> > > + /* call dirty callback only when it has been really touched */
> > > + if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2)
> > > + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> > > }
> > >
> > > /**
> > > --
> > > 2.10.1
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
Hi,
On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
Some rgb-to-vga bridges have an enable GPIO, either directly tied to
an enable pin on the bridge IC, or indirectly controlling a power
switch.
Add support for it.
Does the bridge on your platform have an active/passive DAC, or is it a
smarter encoder chip that is capable of doing more? If so, it might be
good to have a separate DT compatible string to it, like what's done
in the patch titled:
drm: bridge: vga-dac: Add adi,adv7123 compatible string
so that we can switch to a different driver later if needed.
Thanks,
Archit
Signed-off-by: Chen-Yu Tsai
---
.../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
drivers/gpu/drm/bridge/dumb-vga-dac.c | 28 ++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
index 003bc246a270..d3484822bf77 100644
--- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
@@ -16,6 +16,8 @@ graph bindings specified in
Documentation/devicetree/bindings/graph.txt.
- Video port 0 for RGB input
- Video port 1 for VGA output
+Optional properties:
+- enable-gpios: GPIO pin to enable or disable the bridge
Example
---
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..b487e5e9b56d 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -10,6 +10,7 @@
* the License, or (at your option) any later version.
*/
+#include
#include
#include
@@ -23,6 +24,7 @@ struct dumb_vga {
struct drm_connectorconnector;
struct i2c_adapter *ddc;
+ struct gpio_desc*enable_gpio;
};
static inline struct dumb_vga *
@@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
return 0;
}
+static void dumb_vga_enable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+ if (vga->enable_gpio)
+ gpiod_set_value_cansleep(vga->enable_gpio, 1);
+}
+
+static void dumb_vga_disable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+ if (vga->enable_gpio)
+ gpiod_set_value_cansleep(vga->enable_gpio, 0);
+}
+
static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
.attach = dumb_vga_attach,
+ .enable = dumb_vga_enable,
+ .disable= dumb_vga_disable,
};
static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
@@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, vga);
+ vga->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(vga->enable_gpio)) {
+ ret = PTR_ERR(vga->enable_gpio);
+ dev_err(&pdev->dev, "failed to request GPIO: %d\n", ret);
+ return ret;
+ }
+
vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
if (IS_ERR(vga->ddc)) {
if (PTR_ERR(vga->ddc) == -ENODEV) {
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH/RFT v2 16/17] USB: ohci-da8xx: Allow probing from DT
On Tue, Oct 25, 2016 at 2:53 AM, David Lechner wrote:
> On 10/24/2016 11:46 AM, ahas...@baylibre.com wrote:
>>
>> From: Axel Haslam
>>
>> This adds the compatible string to the ohci driver
>> to be able to probe from DT
>>
>> Signed-off-by: Axel Haslam
>> ---
>> drivers/usb/host/ohci-da8xx.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
>> index bebc3f0..1a8db25 100644
>> --- a/drivers/usb/host/ohci-da8xx.c
>> +++ b/drivers/usb/host/ohci-da8xx.c
>> @@ -273,6 +273,13 @@ static int ohci_da8xx_hub_control(struct usb_hcd
>> *hcd, u16 typeReq, u16 wValue,
>> }
>>
>>
>> /*-*/
>> +#ifdef CONFIG_OF
>
>
> #ifdef CONFIG_OF is probably not needed here...
>
>> +static const struct of_device_id da8xx_ohci_ids[] = {
>> + { .compatible = "ti,da830-ohci" },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, da8xx_ohci_ids);
>> +#endif
>>
>> static int ohci_da8xx_probe(struct platform_device *pdev)
>> {
>> @@ -421,6 +428,7 @@ static int ohci_da8xx_resume(struct platform_device
>> *dev)
>> #endif
>> .driver = {
>> .name = "ohci",
>> + .of_match_table = da8xx_ohci_ids,
>
>
> ...otherwise, da8xx_ohci_ids will not be defined here
this should be .of_match_table = of_match_ptr(da8xx_ohci_ids),
will fix.
>
>> },
>> };
>>
>>
>
Re: [PATCH v3 net] flow_dissector: fix vlan tag handling
Mon, Oct 24, 2016 at 11:40:30PM CEST, a...@arndb.de wrote:
>gcc warns about an uninitialized pointer dereference in the vlan
>priority handling:
>
>net/core/flow_dissector.c: In function '__skb_flow_dissect':
>net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in
>this function [-Werror=maybe-uninitialized]
>
>As pointed out by Jiri Pirko, the variable is never actually used
>without being initialized first as the only way it end up uninitialized
>is with skb_vlan_tag_present(skb)==true, and that means it does not
>get accessed.
>
>However, the warning hints at some related issues that I'm addressing
>here:
>
>- the second check for the vlan tag is different from the first one
> that tests the skb for being NULL first, causing both the warning
> and a possible NULL pointer dereference that was not entirely fixed.
>- The same patch that introduced the NULL pointer check dropped an
> earlier optimization that skipped the repeated check of the
> protocol type
>- The local '_vlan' variable is referenced through the 'vlan' pointer
> but the variable has gone out of scope by the time that it is
> accessed, causing undefined behavior
>
>Caching the result of the 'skb && skb_vlan_tag_present(skb)' check
>in a local variable allows the compiler to further optimize the
>later check. With those changes, the warning also disappears.
>
>Fixes: 3805a938a6c2 ("flow_dissector: Check skb for VLAN only if skb
>specified.")
>Fixes: d5709f7ab776 ("flow_dissector: For stripped vlan, get vlan info from
>skb->vlan_tci")
>Signed-off-by: Arnd Bergmann
Acked-by: Jiri Pirko
Re: [PATCH] drm/amd/powerplay: mark symbols static where possible
On Tue, Oct 25, 2016 at 09:09:01AM +0200, Christian König wrote: > Am 25.10.2016 um 08:41 schrieb Daniel Vetter: > > On Mon, Oct 24, 2016 at 10:41:16PM +0200, Arnd Bergmann wrote: > > > On Monday, October 24, 2016 8:07:16 PM CEST Deucher, Alexander wrote: > > > > > > > In fact, these functions are only used in the file in which they > > > > > > > are > > > > > > > declared and don't need a declaration, but can be made static. > > > > > > > So this patch marks these functions with 'static'. > > > > > > > > > > > > > > Signed-off-by: Baoyou Xie > > > > > > This was already applied the last time you sent it out. Sorry if I > > > > > > didn't mention that previously. > > > > > For some reason the patch hasn't made it into linux-next, so I can see > > > > > why Baoyou was getting confused here. Can you clarify what the > > > > > timeline > > > > > is for the AMD DRM driver patches from between they get applied to the > > > > > AMD tree to when they make it into linux-next? > > > > > > > > > It came in late enough last cycle that it didn't make it into 4.9 (this > > > > is just a clean up not a critical bug fix), so I queued it for 4.10. I > > > > try to reply when I apply a patch, but sometimes I miss one here and > > > > there. Once Dave starts the drm-next tree for 4.10, it will be > > > > included in my pull request. Pending -next patches are in my > > > > drm-next--wip tree until I send Dave a formal request. > > > > > > > > > I've occasionally had a hard time with DRM (and a few other > > > > > subsystems) > > > > > with bugfix patches trying to find out whether they got lost or > > > > > whether they just haven't made it into -next but are in some other > > > > > tree. > > > > > > > > > For bug fixes we usually send Dave ~weekly pull requests for each -rc > > > > as necessary. For -next stuff, each driver usually sends at least one, > > > > sometimes several pull requests for the next merge window. > > > Ok, got it. Thanks for the detailed reply! > > > > > > Do you think it would be appropriate to include your drm-next-wip tree in > > > linux-next? I think this is how a lot of the multi-level maintainer > > > setups work as it give faster feedback about when things break. > > tbh I think all drm drivers should be in linux-next. The early head-ups > > about conflicts are really useful. Same for nouveau, but given that > > nouveau is developed in a userspace git repo that's harder to pull off. > > Mhm, in general I agree that seeing merge conflicts and getting a bit more > testing earlier would be a good idea. > > But Alex has the practice of regenerating his -wip branches multiple times. > That is usually not a problem because the only one occasionally basing work > on that branch is me, but it would be if you start to merge it somewhere. linux-next is fine with rebasing branches. drm-intel is in there since years, and we've only very recently stopped rebasing our main branch. What Alex might need to change is switching the branch name for each kernel release, i.e. amd-wip instead of amd-4.10-wip. And be more careful with making sure only stuff heading for the current merge window shows up in there. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2] mfd: do not assign already already assigned compatible of_nodes
If 2 similar cells have the same of_compatible (2 instances of the same
functionality), they both are assigned the first found of_node with this
compatible. In the below example, the pdev of both cells get the child@0
of_node.
parent@0 { /* MFD devices with 2 cells
reg = <0>;
child@0 {
reg = <0>;
compatible = "child-driver";
};
child@1 {
reg = <1>;
compatible = "child-driver";
};
};
To avoid this, the found of_nodes are checked to see if they are already
assigned in the children of the parent dev and are only assigned if
still "available" (not assigned to a child).
This allows the 2nd cell's pdev to get the child@1 of_node.
Signed-off-by: Valentin Longchamp
---
drivers/mfd/mfd-core.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 3ac486a..a684ce5 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -137,6 +137,19 @@ static inline void mfd_acpi_add_device(const struct
mfd_cell *cell,
}
#endif
+static inline int mfd_check_node_callback(struct device *dev, void *data)
+{
+ struct device_node *np = data;
+
+ return dev->of_node == np;
+}
+
+static inline int mfd_is_node_allocated_to_dev(struct device *dev,
+ struct device_node *node)
+{
+ return device_for_each_child(dev, node, mfd_check_node_callback);
+}
+
static int mfd_add_device(struct device *parent, int id,
const struct mfd_cell *cell, atomic_t *usage_count,
struct resource *mem_base,
@@ -178,8 +191,10 @@ static int mfd_add_device(struct device *parent, int id,
if (parent->of_node && cell->of_compatible) {
for_each_child_of_node(parent->of_node, np) {
if (of_device_is_compatible(np, cell->of_compatible)) {
- pdev->dev.of_node = np;
- break;
+ if (!mfd_is_node_allocated_to_dev(parent, np)) {
+ pdev->dev.of_node = np;
+ break;
+ }
}
}
}
--
1.8.3.1
Re: [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.
On Monday 24 October 2016 10:16 PM, ahas...@baylibre.com wrote: > From: David Lechner > > The CFGCHIP registers are used by a number of devices, so using a syscon > device to share them. The first consumer of this will by the phy-da8xx-usb > driver. > > Signed-off-by: David Lechner > [Axel: minor fix: change id to -1] Can you please clarify this change? There could be other syscon devices on the chip for other common registers. Why use the singular device-id? > Signed-off-by: Axel Haslam Thanks, Sekhar
Re: [PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB
output from the LCD interface to VGA signals.
Enable this part of the display pipeline.
I couldn't find the enable-gpios binding for the bridge that you
introduced in the previous patch. Is that intentional?
Thanks,
Archit
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 +
1 file changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 9a74637f677f..05a49b2147f1 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -63,6 +63,49 @@
stdout-path = "serial0:115200n8";
};
+ bridge {
+ compatible = "dumb-vga-dac";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
@@ -245,6 +288,19 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb888_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_vga: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] drm/amd/powerplay: mark symbols static where possible
On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote: > On 25 October 2016 at 04:51, Arnd Bergmann wrote: > > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote: > > The function has no callers, so the easiest way would be to remove it > > entirely, but it's possible that there are plans to add users soon. > > > > It was assumed that this function will be used soon, so this patch remains > it. > if it still not be used in 4.10, then we can remove it. > is it right? There is no such rule in general, it's up to the maintainer and it depends on the specific reason for why the function ended up being unused in the first place. However, we can expect the maintainer to come up with some solution to address the warning. Possible options include: - calling the function from where it was meant to be used - removing the function - adding __maybe_unused - adding an #if 0 I have not looked at this specific example and do not know which of them would be appropriate here. If you look at the output of 'git log -p drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c' you might find it out yourself. Arnd
Re: [PATCH v2] drm/fb-helper: Don't call dirty callback for untouched clips
On Tue, 25 Oct 2016 10:09:30 +0200,
Daniel Vetter wrote:
>
> On Tue, Oct 25, 2016 at 08:46:28AM +0200, Takashi Iwai wrote:
> > On Fri, 21 Oct 2016 14:52:07 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wrote:
> > > > Since 4.7 kernel, we've seen the error messages like
> > > >
> > > > kernel: [TTM] Buffer eviction failed
> > > > kernel: qxl :00:02.0: object_init failed for (4026540032,
> > > > 0x0001)
> > > > kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate
> > > > VRAM BO
> > > >
> > > > on QXL when switching and accessing on VT. The culprit was the
> > > > generic deferred_io code (qxl driver switched to it since 4.7).
> > > > There is a race between the dirty clip update and the call of
> > > > callback.
> > > >
> > > > In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
> > > > while it kicks off the update worker outside the spinlock. Meanwhile
> > > > the update worker clears the dirty clip in the spinlock, too. Thus,
> > > > when drm_fb_helper_dirty() is called concurrently, schedule_work() is
> > > > called after the clip is cleared in the first worker call.
> > > >
> > > > This patch addresses it by validating the clip before calling the
> > > > dirty fb callback.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
> > > > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
> > > > Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support')
> > > > Cc:
> > > > Signed-off-by: Takashi Iwai
> > >
> > > Reviewed-by: Ville Syrjälä
> >
> > Daniel, could you pick this if it's OK as a quick fix? Currently
> > qxl driver is utterly broken, and we should recover it ASAP. On top
> > of this, we can put a more comprehensive fix covering both this and
> > dirtyfb ioctl code paths.
>
> I thought I've pinged Dave already to pick up, I'll poke him again.
Thanks!
Takashi
[PATCH v5] [media] vb2: Add support for capture_dma_bidirectional queue flag
From: Pawel Osciak
When this flag is set for CAPTURE queues by the driver on calling
vb2_queue_init(), it forces the buffers on the queue to be
allocated/mapped with DMA_BIDIRECTIONAL direction flag instead of
DMA_FROM_DEVICE. This allows the device not only to write to the
buffers, but also read out from them. This may be useful e.g. for codec
hardware which may be using CAPTURE buffers as reference to decode
other buffers.
This flag is ignored for OUTPUT queues as we don't want to allow HW to
be able to write to OUTPUT buffers.
This patch introduces 2 macros:
VB2_DMA_DIR(q) returns the corresponding dma_dir for the passed queue
type, tanking care of the capture_dma_birectional flag.
VB2_DMA_DIR_CAPTURE(d) is a test macro returning true if the passed DMA
direction refers to a capture buffer. This test is used to map virtual
addresses for writing and to mark pages as dirty.
Signed-off-by: Pawel Osciak
Tested-by: Pawel Osciak
Signed-off-by: Thierry Escande
---
Changes in v2:
- Renamed use_dma_bidirectional field as capture_dma_bidirectional
- Added a VB2_DMA_DIR() macro
Changes in v3:
- Get rid of dma_dir field and therefore squashed the previous patch
Changes in v4:
- Fixed typos in include/media/videobuf2-core.h
- Added VB2_DMA_DIR_CAPTURE() test macro
Changes in v5:
- Use is_output queue field in VB2_DMA_DIR() macro
drivers/media/v4l2-core/videobuf2-core.c | 9 +++--
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-sg.c | 5 +++--
drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 ++--
include/media/videobuf2-core.h | 23 +++
5 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 21900202..22d6105 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -194,8 +194,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb->vb2_queue;
- enum dma_data_direction dma_dir =
- q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+ enum dma_data_direction dma_dir = VB2_DMA_DIR(q);
void *mem_priv;
int plane;
int ret = -ENOMEM;
@@ -978,8 +977,7 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const void
*pb)
void *mem_priv;
unsigned int plane;
int ret = 0;
- enum dma_data_direction dma_dir =
- q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+ enum dma_data_direction dma_dir = VB2_DMA_DIR(q);
bool reacquired = vb->planes[0].mem_priv == NULL;
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
@@ -1096,8 +1094,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
void *pb)
void *mem_priv;
unsigned int plane;
int ret = 0;
- enum dma_data_direction dma_dir =
- q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+ enum dma_data_direction dma_dir = VB2_DMA_DIR(q);
bool reacquired = vb->planes[0].mem_priv == NULL;
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index fb6a177..a44e383 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -507,7 +507,7 @@ static void *vb2_dc_get_userptr(struct device *dev,
unsigned long vaddr,
buf->dma_dir = dma_dir;
offset = vaddr & ~PAGE_MASK;
- vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
+ vec = vb2_create_framevec(vaddr, size, VB2_DMA_DIR_CAPTURE(dma_dir));
if (IS_ERR(vec)) {
ret = PTR_ERR(vec);
goto fail_buf;
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index ecff8f49..51c98f6 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -238,7 +238,8 @@ static void *vb2_dma_sg_get_userptr(struct device *dev,
unsigned long vaddr,
buf->offset = vaddr & ~PAGE_MASK;
buf->size = size;
buf->dma_sgt = &buf->sg_table;
- vec = vb2_create_framevec(vaddr, size, buf->dma_dir == DMA_FROM_DEVICE);
+ vec = vb2_create_framevec(vaddr, size,
+ VB2_DMA_DIR_CAPTURE(buf->dma_dir));
if (IS_ERR(vec))
goto userptr_fail_pfnvec;
buf->vec = vec;
@@ -291,7 +292,7 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
vm_unmap_ram(buf->vaddr, buf->num_pages);
sg_free_table(buf->dma_sgt);
while (--i >= 0) {
- if (buf->dma_dir == DMA_FROM_DEVICE)
+ if (VB2_DMA_DIR_CAPTURE(buf->dma_dir))
set_page_dirty_lock(buf->pages[i]);
Re: [PATCH/RFT v2 12/17] USB: ochi-da8xx: Use a regulator for vbus/overcurrent
On Tue, Oct 25, 2016 at 3:39 AM, David Lechner wrote:
> On 10/24/2016 11:46 AM, ahas...@baylibre.com wrote:
>>
>> From: Axel Haslam
>>
>> Currently, the da8xx ohci driver uses a set of gpios and callbacks in
>> board files to handle vbus and overcurrent irqs form the power supply.
>> However, this does not play nice when moving to a DT based boot were
>> we wont have board files.
>>
>> Instead of requesting and handling the gpio, use the regulator framework
>> to take care of enabling and disabling vbus power.
>> This has the benefit
>> that we dont need to pass any more platform data to the driver:
>>
>> These will be handled by the regulator framework:
>> set_power -> regulator_enable/regulator_disable
>> get_power -> regulator_is_enabled
>> get_oci -> regulator_get_mode
>> ocic_notify -> regulator notification
>>
>> We can keep the default potpgt and use the regulator start delay instead:
>> potpgt -> regulator startup delay time
>>
>> The hawk board does not have a GPIO/OVERCURRENT gpio to control vbus,
>> (they should not have been decleared/reserved) so, just remove those
>> definitions from the hwk board file.
>>
>> Signed-off-by: Axel Haslam
>> ---
>
>
>
> How do you recover after an overcurrent event?
>
> I have configured a fixed-regulator using device-tree, but similar to the
> configuration in the board files here. However, when I shorted out the VBUS
> and caused an overcurrent event, I see nothing in the kernel log saying that
> there was an overcurrent event and after I remove the short, the regulator
> is never turned back on.
>
>
You should have the patch to fix gpiolib, and you should declare the
over current gpio on the regulator as such:
(if the pin is enabled high you should add oc-active-high);
vbus_fixed: fixed-regulator-vbus {
compatible = "regulator-fixed";
gpio = <&gpio 109 0>;
oc-gpio = <&gpio 36 0>;
regulator-boot-on;
enable-active-high;
regulator-name = "vbus";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
Question: Do you see that the over current gpio was requested
in debugfs/gpio? and, do you see the interrupt in /proc/interrupts?
If you unplug and plug in back the usb device it should work again.
also you can unbind and bind it should also start to work:
something like:
echo usb1 >/sys/bus/usb/drivers/usb/unbind
echo usb1 >/sys/bus/usb/drivers/usb/bind
>
>> @@ -163,7 +198,6 @@ static int ohci_da8xx_hub_control(struct usb_hcd *hcd,
>> u16 typeReq, u16 wValue,
>> u16 wIndex, char *buf, u16 wLength)
>> {
>> struct device *dev = hcd->self.controller;
>> - struct da8xx_ohci_root_hub *hub = dev_get_platdata(dev);
>
>
> nit: unnecessary whitespace change
>
>> int temp;
>>
>> switch (typeReq) {
>
>
[no subject]
ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti informazioni qui di seguito: nome: Nome utente: Password: Conferma Password: E-mail: telefono: Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi posta sarà disabilitato! Ci dispiace per l'inconvenienza. Codice di verifica: en:0085362LK.0.2016 Mail Technical Support ©2016 grazie Sistemi amministratore.
Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
On Mon, 24 Oct 2016 17:05:26 +0200
Arnd Bergmann wrote:
> This adds an asm/asm-prototypes.h header for ARM to fix the
> broken symbol versioning for symbols exported from assembler
> files.
>
> In addition to the header, we have to do these other small
> changes:
>
> - move the exports from bitops.h to {change,clear,set,...}bit.S
> - move the exports from csumpartialgeneric.S into the files
> including it
>
> I couldn't find the correct prototypes for the compiler builtins,
> so I went with the fake 'void f(void)' prototypes that we had
> before.
>
> This leaves the mmioset/mmiocpy function for now, as it's not
> obvious how to best handle them.
This looks nicer. I like variant B because it keeps the GENKSYMS cruft to
a single location, but either one isn't too bad.
I'd like to get moving on this, so let's at least get the generic kbuild
change merged. In the end, the kbuild code does not prevent a maintainer
from putting their EXPORT_SYMBOL in whatever location they like, so there
is no reason not to merge it (certainly there will be archs that do use
it).
Michal, what's your thoughts? If you merge my patch 2/2 and skip 1/2, it
should not give any new build warnings or errors, so then arch patches can
go via arch trees. 1/2 could go in after everyone is up to date.
Thanks,
Nick
Re: Disabling an interrupt in the handler locks the system up
On 25/10/2016 10:29, Sebastian Frias wrote: > On 10/24/2016 06:55 PM, Thomas Gleixner wrote: > >> On Mon, 24 Oct 2016, Mason wrote: >> >>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device >>> makes the system lock-up disappear. >> >> The way how lazy irq disabling works is: >> >> 1) Interrupt is marked disabled in software, but the hardware is not masked >> >> 2) If the interrupt fires befor the interrupt is reenabled, then it's >>masked at the hardware level in the low level interrupt flow handler. > > Would you mind explaining what is the intention behind? > Because it does not seem obvious why there isn't a direct map between > "disable_irq*()" and "mask_irq()" I had a similar, but slightly different question: What is the difference between struct irq_chip's * @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL) * @irq_disable:disable the interrupt * @irq_mask: mask an interrupt source (enable seems to default to unmask, but disable does not default to mask) Regards.
Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On Mon, 24 Oct 2016, Paul Bolle wrote:
> [Detailed post, but please give it a quick scan.]
Please file the information in the bug you filed. Please attach dmesg
(again, on the bug) with drm.debug=14 and running your patch.
BR,
Jani.
>
> On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
>> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> > start.
>>
>> That would be between v4.7 and v4.8. (I guess my report was
>> ambiguous.)
>>
>> That might take some time. Because bisecting always takes a long time
>> and especially since hitting this WARNING sometimes takes over an hour.
>> Anyhow, please prod me if I stay silent for too long.
>
> 0) So I've lost my courage to do a bisect when my first attempt landed
> me in v4.6-rc3. This is about for issue popping up between v4.7 and
> v4.8-rc1.
>
> 1) So I used the most reliable debugging tool that I actually
> understand: printk():
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fbcfed63a76e..791de414cf1e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct
> intel_crtc_state *crtc_state
> return DRM_PLANE_HELPER_NO_SCALING;
>
> crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
> - cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> + if (WARN_ON_ONCE(!crtc_clock))
> + return DRM_PLANE_HELPER_NO_SCALING;
>
> - if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
> + cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> + if (WARN_ON_ONCE(cdclk < crtc_clock)) {
> + printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n",
> cdclk, crtc_clock);
> return DRM_PLANE_HELPER_NO_SCALING;
> + }
> +
> + printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >=
> %d\n", cdclk, crtc_clock);
>
> /*
> * skl max scale is lower of:
>
> 2) This taught me that crtc_clock always is 373250 on my machine. cdclk
> mostly is 45, but every now and then it briefly is 337500.
>
> 3) Now the interesting pattern is that cdclk drops to 337500 only after
> two quick calls of skl_max_scale() with cdclk set to 45, and a
> roughly 300ms pause before the third call of that function. Example:
>
> <7>[23758.501933] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.515211] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
>
> This pattern of cdclk being 337500 after roughly 300ms is surprisingly
> stable.
>
> 4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
> that sets cdclk to 337500 and triggers this issue. Ideas?
>
> To be continued,
>
>
> Paul Bolle
--
Jani Nikula, Intel Open Source Technology Center
Re: [PATCH] clk: fix link error for rcar-gen2
Hi Arnd,
On Fri, Oct 21, 2016 at 11:07 PM, Arnd Bergmann wrote:
> On Friday, October 21, 2016 8:01:49 PM CEST Geert Uytterhoeven wrote:
>> > diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
>> > index 90dd0db7d9c6..762d122eddec 100644
>> > --- a/drivers/clk/renesas/Makefile
>> > +++ b/drivers/clk/renesas/Makefile
>> > @@ -4,11 +4,7 @@ obj-$(CONFIG_ARCH_R8A73A4) += clk-r8a73a4.o
>> > clk-div6.o
>> > obj-$(CONFIG_ARCH_R8A7740) += clk-r8a7740.o clk-div6.o
>> > obj-$(CONFIG_ARCH_R8A7778) += clk-r8a7778.o
>> > obj-$(CONFIG_ARCH_R8A7779) += clk-r8a7779.o
>> > -obj-$(CONFIG_ARCH_R8A7790) += clk-rcar-gen2.o clk-div6.o
>> > -obj-$(CONFIG_ARCH_R8A7791) += clk-rcar-gen2.o clk-div6.o
>> > -obj-$(CONFIG_ARCH_R8A7792) += clk-rcar-gen2.o clk-div6.o
>> > -obj-$(CONFIG_ARCH_R8A7793) += clk-rcar-gen2.o clk-div6.o
>> > -obj-$(CONFIG_ARCH_R8A7794) += clk-rcar-gen2.o clk-div6.o
>> > +obj-$(CONFIG_ARCH_RCAR_GEN2) += clk-rcar-gen2.o clk-div6.o
>> > obj-$(CONFIG_ARCH_R8A7795) += r8a7795-cpg-mssr.o
>> > rcar-gen3-cpg.o
>> > obj-$(CONFIG_ARCH_R8A7796) += r8a7796-cpg-mssr.o
>> > rcar-gen3-cpg.o
>> > obj-$(CONFIG_ARCH_SH73A0) += clk-sh73a0.o clk-div6.o
>>
>> Please don't fix it this way, as it will make it _harder_ to convert the
>> R-Car
>> Gen2 SoCs to the modern CPG/MSSR driver later.
>
> Ok, I see. How about just adding another line for r8a7743 and
> dropping that again after the timer_init has been converted?
That's an option, but it touches a different subsystem ;-)
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
Re: [PATCH 5/7] ASoC: constify snd_soc_ops structures
On Tue, 25 Oct 2016, Joe Perches wrote: > On Tue, 2016-10-25 at 07:55 +0200, Julia Lawall wrote: > > On Mon, 24 Oct 2016, Mark Brown wrote: > > > On Sat, Oct 15, 2016 at 04:55:49PM +0200, Julia Lawall wrote: > > > > --- > > > > sound/soc/generic/simple-card.c |2 +- > [...] > > > > sound/soc/mxs/mxs-sgtl5000.c|2 +- > > > > 16 files changed, 28 insertions(+), 28 deletions(-) > > > > > > You split out a few drivers as separate patches but not these ones - > > > what's special about these ones? > > >u > If it's preferred, I could send them all one file at a time, or when the > > maintainers are very similar just send one patch to all the maintainers. > > Whatever works. > There's no single style appropriate for the entire kernel. Actually, I was wondering for this kind of patch specifically. thanks, julia
Re: [PATCH 1/3] [media] au0828-video: Use kcalloc() in au0828_init_isoc()
On Mon, Oct 24, 2016 at 10:59:24PM +0200, SF Markus Elfring wrote: > + dev->isoc_ctl.transfer_buffer = kcalloc(num_bufs, > + sizeof(*dev->isoc_ctl > +.transfer_buffer), This is ugly. regards, dan carpenter
Re: [PATCH] Staging:wlan-ng:hfa384x: fixed 80 character line limit coding style issue
On Fri, Oct 21, 2016 at 06:12:32PM +0530, Nadim Almas wrote:
> Fixed coding style issue
>
> Signed-off-by: Nadim Almas
> ---
> drivers/staging/wlan-ng/hfa384x.h | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wlan-ng/hfa384x.h
> b/drivers/staging/wlan-ng/hfa384x.h
> index 6337b1d..cca2652 100644
> --- a/drivers/staging/wlan-ng/hfa384x.h
> +++ b/drivers/staging/wlan-ng/hfa384x.h
> @@ -1349,7 +1349,9 @@ struct hfa384x {
> * interface
> */
>
> - struct hfa384x_caplevel cap_act_sta_mfi; /* sta f/w to modem interface
> */
> + struct hfa384x_caplevel cap_act_sta_mfi; /*
> + * sta f/w to modem interface
> + */
>
> struct hfa384x_caplevel cap_act_ap_cfi; /*
>* ap f/w to controller
> @@ -1371,7 +1373,9 @@ struct hfa384x {
>
> struct hfa384x_inf_frame *scanresults;
>
> - struct prism2sta_authlist authlist; /* Authenticated station list.
> */
> + struct prism2sta_authlist authlist; /*
> + * Authenticated station list
> + */
These changes really don't make things more readable, do they? Put the
comment above the variable if you really care, or just don't worry about
the 1 or 2 characters over the line-length limit here.
thanks,
greg k-h
Re: Disabling an interrupt in the handler locks the system up
Hi Thomas, On 10/24/2016 06:55 PM, Thomas Gleixner wrote: > On Mon, 24 Oct 2016, Mason wrote: >> >> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device >> makes the system lock-up disappear. > > The way how lazy irq disabling works is: > > 1) Interrupt is marked disabled in software, but the hardware is not masked > > 2) If the interrupt fires befor the interrupt is reenabled, then it's >masked at the hardware level in the low level interrupt flow handler. > Would you mind explaining what is the intention behind? Because it does not seem obvious why there isn't a direct map between "disable_irq*()" and "mask_irq()" Thanks in advance. Best regards, Sebastian
Re: [PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
On Tue, Oct 25, 2016 at 4:13 PM, Archit Taneja wrote:
>
>
> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>
>> The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB
>> output from the LCD interface to VGA signals.
>>
>> Enable this part of the display pipeline.
>
>
> I couldn't find the enable-gpios binding for the bridge that you
> introduced in the previous patch. Is that intentional?
Error on my part. Thanks for spotting that.
ChenYu
>
> Thanks,
> Archit
>
>
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56
>> +
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> index 9a74637f677f..05a49b2147f1 100644
>> --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> @@ -63,6 +63,49 @@
>> stdout-path = "serial0:115200n8";
>> };
>>
>> + bridge {
>> + compatible = "dumb-vga-dac";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + vga_bridge_in: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint =
>> <&tcon0_out_vga>;
>> + };
>> + };
>> +
>> + port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + vga_bridge_out: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_con_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + vga {
>> + compatible = "vga-connector";
>> +
>> + port {
>> + vga_con_in: endpoint {
>> + remote-endpoint = <&vga_bridge_out>;
>> + };
>> + };
>> + };
>> +
>> wifi_pwrseq: wifi_pwrseq {
>> compatible = "mmc-pwrseq-simple";
>> reset-gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
>> @@ -245,6 +288,19 @@
>> status = "okay";
>> };
>>
>> +&tcon0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&lcd0_rgb888_pins>;
>> + status = "okay";
>> +};
>> +
>> +&tcon0_out {
>> + tcon0_out_vga: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_bridge_in>;
>> + };
>> +};
>> +
>> &uart0 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&uart0_pins_a>;
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
Re: [PATCH 02/37] staging:r8188eu: remove device assignment after netdev_alloc_skb call
On Thu, Oct 20, 2016 at 07:16:20PM +0700, Ivan Safonov wrote: > Andy, > thank you for reviewing patches and tips. Please redo this series based on these responses and resend. thanks, greg k-h
Re: [PATCH v3 1/9] mtd: spi-nor: improve macronix_quad_enable()
Hi Marek, Le 25/10/2016 à 00:00, Marek Vasut a écrit : > On 10/24/2016 06:34 PM, Cyrille Pitchen wrote: >> The patch checks whether the Quad Enable bit is already set in the Status >> Register. If so, the function exits immediately with a successful return >> code. Otherwise, a message is now printed telling we're setting the >> non-volatile bit. >> >> Signed-off-by: Cyrille Pitchen >> Reviewed-by: Jagan Teki >> --- >> drivers/mtd/spi-nor/spi-nor.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index d0fc165d7d66..5c87b2d99507 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -1211,6 +1211,11 @@ static int macronix_quad_enable(struct spi_nor *nor) >> val = read_sr(nor); >> if (val < 0) >> return val; >> +if (val & SR_QUAD_EN_MX) >> +return 0; >> + >> +/* Update the Quad Enable bit. */ >> +dev_info(nor->dev, "setting Macronix Quad Enable (non-volatile) bit\n"); > > Should probably be dev_dbg(), since this is just churn in the kernel > log. The user doesn't care and the developer can just up the debug level > or add his own printk . > The Quad Enable bit is non-volatile so this trace should be printed only once but I'm perfectly fine with using dev_dbg(). I'll change it in the next version. Best regards, Cyrille >> write_enable(nor); >> >> write_sr(nor, val | SR_QUAD_EN_MX); >> > >
Re: [PATCH 4/4] MIPS/kernel/proc: Combine four seq_printf() calls into one call in show_cpuinfo()
On Mon, Oct 24, 2016 at 2:30 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Mon, 24 Oct 2016 13:54:58 +0200
>
> Some data were printed into a sequence by four separate function calls.
> Print the same data by one function call instead.
>
> Signed-off-by: Markus Elfring
> ---
> arch/mips/kernel/proc.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
> index 07480a9..1047a03 100644
> --- a/arch/mips/kernel/proc.c
> +++ b/arch/mips/kernel/proc.c
> @@ -142,12 +142,15 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> seq_printf(m, "micromips kernel\t: %s\n",
> (read_c0_config3() & MIPS_CONF3_ISA_OE) ? "yes" :
> "no");
> }
> - seq_printf(m, "shadow register sets\t: %d\n",
> - cpu_data[n].srsets);
> - seq_printf(m, "kscratch registers\t: %d\n",
> - hweight8(cpu_data[n].kscratch_mask));
> - seq_printf(m, "package\t\t\t: %d\n", cpu_data[n].package);
> - seq_printf(m, "core\t\t\t: %d\n", cpu_data[n].core);
> + seq_printf(m,
> + "shadow register sets\t: %d\n"
> + "kscratch registers\t: %d\n"
> + "package\t\t\t: %d\n"
> + "core\t\t\t: %d\n",
> + cpu_data[n].srsets,
> + hweight8(cpu_data[n].kscratch_mask),
> + cpu_data[n].package,
> + cpu_data[n].core);
I think the code is much easier to read with separate seq_printf()s for
each line printed.
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
Re: [PATCH] Staging:board:board: fix Block comments should align the * on each line
On Mon, Oct 24, 2016 at 09:18:04PM +0530, Nadim Almas wrote: > Block comments should align the * on each line as reported by checkpatch.pl > > Signed-off-by: Nadim Almas > --- > > drivers/staging/dgnc/dgnc_tty.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Your subject: does not reflect what file you changed :(
Re: [PATCH v2] shmem: avoid maybe-uninitialized warning
On 10/24/2016 10:57 PM, Arnd Bergmann wrote:
After enabling -Wmaybe-uninitialized warnings, we get a false-postive
warning for shmem:
mm/shmem.c: In function ‘shmem_getpage_gfp’:
include/linux/spinlock.h:332:21: error: ‘info’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
This can be easily avoided, since the correct 'info' pointer is known
at the time we first enter the function, so we can simply move the
initialization up. Moving it before the first label avoids the
warning and lets us remove two later initializations.
Note that the function is so hard to read that it not only confuses
the compiler, but also most readers and without this patch it could\
easily break if one of the 'goto's changed.
Link: https://www.spinics.net/lists/kernel/msg2368133.html
Acked-by: Michal Hocko
Signed-off-by: Arnd Bergmann
Acked-by: Vlastimil Babka
---
mm/shmem.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index ad7813d73ea7..95c4bb690f98 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1537,7 +1537,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t
index,
struct mm_struct *fault_mm, int *fault_type)
{
struct address_space *mapping = inode->i_mapping;
- struct shmem_inode_info *info;
+ struct shmem_inode_info *info = SHMEM_I(inode);
struct shmem_sb_info *sbinfo;
struct mm_struct *charge_mm;
struct mem_cgroup *memcg;
@@ -1587,7 +1587,6 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t
index,
* Fast cache lookup did not find it:
* bring it back from swap or allocate.
*/
- info = SHMEM_I(inode);
sbinfo = SHMEM_SB(inode->i_sb);
charge_mm = fault_mm ? : current->mm;
@@ -1835,7 +1834,6 @@ alloc_nohuge: page =
shmem_alloc_and_acct_page(gfp, info, sbinfo,
put_page(page);
}
if (error == -ENOSPC && !once++) {
- info = SHMEM_I(inode);
spin_lock_irq(&info->lock);
shmem_recalc_inode(inode);
spin_unlock_irq(&info->lock);
Re: [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
On Tue, Oct 25, 2016 at 4:09 PM, Archit Taneja wrote:
> Hi,
>
> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:
>>
>> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
>> an enable pin on the bridge IC, or indirectly controlling a power
>> switch.
>>
>> Add support for it.
>
>
> Does the bridge on your platform have an active/passive DAC, or is it a
> smarter encoder chip that is capable of doing more? If so, it might be
> good to have a separate DT compatible string to it, like what's done
> in the patch titled:
>
> drm: bridge: vga-dac: Add adi,adv7123 compatible string
>
> so that we can switch to a different driver later if needed.
The chip is GM7123. It is not configurable. It just takes the LCD RGB/SYNC
signals and converts them to analog. The only things you can change are
putting it into sleep mode and tweaking the output drive strength by
changing the external reference resistor. The latter would be a hardware
design decision. I would say this qualifies as "dumb".
I revisited the board schematics, and the enable GPIO actually toggles
an external LDO regulator. So this might be better modeled as a regulator
supply?
Thanks
ChenYu
>
> Thanks,
> Archit
>
>
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 28
>> ++
>> 2 files changed, 30 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..d3484822bf77 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in
>> Documentation/devicetree/bindings/graph.txt.
>> - Video port 0 for RGB input
>> - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- enable-gpios: GPIO pin to enable or disable the bridge
>>
>> Example
>> ---
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..b487e5e9b56d 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -10,6 +10,7 @@
>> * the License, or (at your option) any later version.
>> */
>>
>> +#include
>> #include
>> #include
>>
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connectorconnector;
>>
>> struct i2c_adapter *ddc;
>> + struct gpio_desc*enable_gpio;
>> };
>>
>> static inline struct dumb_vga *
>> @@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>> }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (vga->enable_gpio)
>> + gpiod_set_value_cansleep(vga->enable_gpio, 1);
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (vga->enable_gpio)
>> + gpiod_set_value_cansleep(vga->enable_gpio, 0);
>> +}
>> +
>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> + .enable = dumb_vga_enable,
>> + .disable= dumb_vga_disable,
>> };
>>
>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> + vga->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(vga->enable_gpio)) {
>> + ret = PTR_ERR(vga->enable_gpio);
>> + dev_err(&pdev->dev, "failed to request GPIO: %d\n", ret);
>> + return ret;
>> + }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
Re: [ISSUE] mm: Add a user_ns owner to mm_struct and fix ptrace_may_access
On Mon, Oct 24, 2016 at 06:11:04PM -0500, Eric W. Biederman wrote: > Kees Cook writes: > > > On Mon, Oct 24, 2016 at 1:29 PM, Cyrill Gorcunov wrote: > >> On Mon, Oct 24, 2016 at 02:01:30PM -0500, Eric W. Biederman wrote: > >>> So I am probably going to tweak the !mm case so that instead of failing > >>> we perform the old capable check in that case. That seems the mot > >>> certain way to avoid regressions. With that said, why is exit_code > >>> behind a ptrace_may_access permission check? > >> > >> Yes, this would be great! And as to @exit_code I think better ask > >> Kees, CC'ed. > > > > My concern was that this was an exposure in the sense that it is > > internal program state that isn't visible through other means (without > > being the parent, for example). Under the ptrace check, it has an > > equivalency that seemed correct at the time. > > > > As already covered, I'd agree: it looks like ce99dd5fd5f6 accidentally > > added a dependency on task->mm where it didn't before. That section of > > logic was entirely around dumpability, not an mm existing. It should > > be "EPERM if mm and dumpable != SUID_DUMP_USER". > > > > That said, I'd also agree that ptrace against no mm is crazy (though I > > suppose that should return EINVAL or ESRCH or something), so perhaps a > > better access control on @exit_code is needed here. > > I traced down the original logic of why we had that dumpable > variable, and it was ancient conservative on my part when we started > using the ptrace permission checks for proc files. > > That same conservatism has resulted in the regression under > discussion. > > Given that we already have a very full set of permission checks > separate from dumpable in ptrace_may_access I think it makes sense > to simply ignore dumpable when there is no mm. > AKA: > mm = task->mm; > if (mm && > ((get_dumpable(mm) != SUID_DUMP_USER) && >!ptrace_has_cap(mm->user_ns, mode))) > return -EPERM; > > Because while it has been used for other things dumpable is > fundamentally about do you have permission to read the mm. > So there is no real point in permission checks that protect > the mm if the mm has gone away. > > It also looks like I may need to update the check that sets > PT_PTRACE_CAP to look at mm->user_ns as well. Thanks a lot for informative explanations, Eric and Kees! Eric, if you make some patch please ping me to test it.
[GIT PULL v2 5/5] processor.h: remove cpu_relax_lowlatency
As there are no users left, we can remove cpu_relax_lowlatency.
Signed-off-by: Christian Borntraeger
---
arch/alpha/include/asm/processor.h | 1 -
arch/arc/include/asm/processor.h| 2 --
arch/arm/include/asm/processor.h| 1 -
arch/arm64/include/asm/processor.h | 1 -
arch/avr32/include/asm/processor.h | 1 -
arch/blackfin/include/asm/processor.h | 1 -
arch/c6x/include/asm/processor.h| 1 -
arch/cris/include/asm/processor.h | 1 -
arch/frv/include/asm/processor.h| 1 -
arch/h8300/include/asm/processor.h | 1 -
arch/hexagon/include/asm/processor.h| 1 -
arch/ia64/include/asm/processor.h | 1 -
arch/m32r/include/asm/processor.h | 1 -
arch/m68k/include/asm/processor.h | 1 -
arch/metag/include/asm/processor.h | 1 -
arch/microblaze/include/asm/processor.h | 1 -
arch/mips/include/asm/processor.h | 1 -
arch/mn10300/include/asm/processor.h| 1 -
arch/nios2/include/asm/processor.h | 1 -
arch/openrisc/include/asm/processor.h | 1 -
arch/parisc/include/asm/processor.h | 1 -
arch/powerpc/include/asm/processor.h| 1 -
arch/s390/include/asm/processor.h | 1 -
arch/score/include/asm/processor.h | 1 -
arch/sh/include/asm/processor.h | 1 -
arch/sparc/include/asm/processor_32.h | 1 -
arch/sparc/include/asm/processor_64.h | 1 -
arch/tile/include/asm/processor.h | 1 -
arch/unicore32/include/asm/processor.h | 1 -
arch/x86/include/asm/processor.h| 1 -
arch/x86/um/asm/processor.h | 1 -
arch/xtensa/include/asm/processor.h | 1 -
32 files changed, 33 deletions(-)
diff --git a/arch/alpha/include/asm/processor.h
b/arch/alpha/include/asm/processor.h
index 0556fda..31e8dbe 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -59,7 +59,6 @@ unsigned long get_wchan(struct task_struct *p);
#define cpu_relax()barrier()
#define cpu_relax_yield() cpu_relax()
-#define cpu_relax_lowlatency() cpu_relax()
#define ARCH_HAS_PREFETCH
#define ARCH_HAS_PREFETCHW
diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index 6c158d5..d102a49 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -61,7 +61,6 @@ struct task_struct;
#define cpu_relax()barrier()
#define cpu_relax_yield() cpu_relax()
-#define cpu_relax_lowlatency() cpu_relax()
#else
@@ -69,7 +68,6 @@ struct task_struct;
__asm__ __volatile__ (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
#define cpu_relax_yield() cpu_relax()
-#define cpu_relax_lowlatency() barrier()
#endif
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index db660e0..9e71c58b 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -83,7 +83,6 @@ unsigned long get_wchan(struct task_struct *p);
#endif
#define cpu_relax_yield()cpu_relax()
-#define cpu_relax_lowlatency()cpu_relax()
#define task_pt_regs(p) \
((struct pt_regs *)(THREAD_START_SP + task_stack_page(p)) - 1)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index 3f9b0e5..6132f64 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -150,7 +150,6 @@ static inline void cpu_relax(void)
}
#define cpu_relax_yield() cpu_relax()
-#define cpu_relax_lowlatency()cpu_relax()
/* Thread switching */
extern struct task_struct *cpu_switch_to(struct task_struct *prev,
diff --git a/arch/avr32/include/asm/processor.h
b/arch/avr32/include/asm/processor.h
index e412e8b..ee62365 100644
--- a/arch/avr32/include/asm/processor.h
+++ b/arch/avr32/include/asm/processor.h
@@ -93,7 +93,6 @@ extern struct avr32_cpuinfo boot_cpu_data;
#define cpu_relax()barrier()
#define cpu_relax_yield() cpu_relax()
-#define cpu_relax_lowlatency()cpu_relax()
#define cpu_sync_pipeline()asm volatile("sub pc, -2" : : : "memory")
struct cpu_context {
diff --git a/arch/blackfin/include/asm/processor.h
b/arch/blackfin/include/asm/processor.h
index 8b8704a..57acfb1 100644
--- a/arch/blackfin/include/asm/processor.h
+++ b/arch/blackfin/include/asm/processor.h
@@ -93,7 +93,6 @@ unsigned long get_wchan(struct task_struct *p);
#define cpu_relax()smp_mb()
#define cpu_relax_yield() cpu_relax()
-#define cpu_relax_lowlatency() cpu_relax()
/* Get the Silicon Revision of the chip */
static inline uint32_t __pure bfin_revid(void)
diff --git a/arch/c6x/include/asm/processor.h b/arch/c6x/include/asm/processor.h
index 914d730..1fd22e7 100644
--- a/arch/c6x/include/asm/processor.h
+++ b/arch/c6x/include/asm/processor.h
@@ -122,7 +122,6 @@ extern unsigned long get_wchan(struct task_struct *p);
#define cpu_relax()do { } while (0)
#define cpu_relax_yield() cpu_relax()
-#defin
[GIT PULL v2 3/5] s390: make cpu_relax a barrier again
stop_machine seemed to be the only important place for yielding during cpu_relax. This was fixed by using cpu_relax_yield. Therefore, we can now redefine cpu_relax to be a barrier instead on s390, making s390 identical to all other architectures. Signed-off-by: Christian Borntraeger --- arch/s390/include/asm/processor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h index d05965b..5d262cf 100644 --- a/arch/s390/include/asm/processor.h +++ b/arch/s390/include/asm/processor.h @@ -236,7 +236,7 @@ static inline unsigned short stap(void) */ void cpu_relax_yield(void); -#define cpu_relax() cpu_relax_yield() +#define cpu_relax() barrier() #define cpu_relax_lowlatency() barrier() #define ECAG_CACHE_ATTRIBUTE 0 -- 2.5.5
[GIT PULL v2 2/5] stop_machine: yield CPU during stop machine
Some time ago commit 57f2ffe14fd125c2 ("s390: remove diag 44 calls
from cpu_relax()") did stop cpu_relax on s390 yielding to the
hypervisor.
As it turns out this made stop_machine run really slow on virtualized
overcommited systems. For example the kprobes test during bootup took
several seconds instead of just running unnoticed with large guests.
Therefore, the yielding was reintroduced with commit 4d92f50249eb
("s390: reintroduce diag 44 calls for cpu_relax()"), but in fact the
stop machine code seems to be the only place where this yielding
was really necessary. This place is probably the most important one
as it makes all but one guest CPUs wait for one guest CPU.
As we now have cpu_relax_yield, we can use this in multi_cpu_stop.
For now lets only add it here. We can add it later in other places
when necessary.
Signed-off-by: Christian Borntraeger
---
kernel/stop_machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index ec9ab2f..1eb8266 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -194,7 +194,7 @@ static int multi_cpu_stop(void *data)
/* Simple state machine */
do {
/* Chill out and ensure we re-read multi_stop_state. */
- cpu_relax();
+ cpu_relax_yield();
if (msdata->state != curstate) {
curstate = msdata->state;
switch (curstate) {
--
2.5.5
[GIT PULL v2 4/5] processor.h: Remove cpu_relax_lowlatency users
With the s390 special case of a yielding cpu_relax implementation gone,
we can now remove all users of cpu_relax_lowlatency and replace them
with cpu_relax.
Signed-off-by: Christian Borntraeger
---
drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
drivers/vhost/net.c | 4 ++--
kernel/locking/mcs_spinlock.h | 4 ++--
kernel/locking/mutex.c | 4 ++--
kernel/locking/osq_lock.c | 6 +++---
kernel/locking/qrwlock.c| 6 +++---
kernel/locking/rwsem-xadd.c | 4 ++--
lib/lockref.c | 2 +-
8 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index 8832f8e..383d134 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -723,7 +723,7 @@ bool __i915_spin_request(const struct drm_i915_gem_request
*req,
if (busywait_stop(timeout_us, cpu))
break;
- cpu_relax_lowlatency();
+ cpu_relax();
} while (!need_resched());
return false;
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 5dc128a..5dc3465 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -342,7 +342,7 @@ static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
endtime = busy_clock() + vq->busyloop_timeout;
while (vhost_can_busy_poll(vq->dev, endtime) &&
vhost_vq_avail_empty(vq->dev, vq))
- cpu_relax_lowlatency();
+ cpu_relax();
preempt_enable();
r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
out_num, in_num, NULL, NULL);
@@ -533,7 +533,7 @@ static int vhost_net_rx_peek_head_len(struct vhost_net
*net, struct sock *sk)
while (vhost_can_busy_poll(&net->dev, endtime) &&
!sk_has_rx_data(sk) &&
vhost_vq_avail_empty(&net->dev, vq))
- cpu_relax_lowlatency();
+ cpu_relax();
preempt_enable();
diff --git a/kernel/locking/mcs_spinlock.h b/kernel/locking/mcs_spinlock.h
index c835270..6a385aa 100644
--- a/kernel/locking/mcs_spinlock.h
+++ b/kernel/locking/mcs_spinlock.h
@@ -28,7 +28,7 @@ struct mcs_spinlock {
#define arch_mcs_spin_lock_contended(l)
\
do { \
while (!(smp_load_acquire(l))) \
- cpu_relax_lowlatency(); \
+ cpu_relax();\
} while (0)
#endif
@@ -108,7 +108,7 @@ void mcs_spin_unlock(struct mcs_spinlock **lock, struct
mcs_spinlock *node)
return;
/* Wait until the next pointer is set */
while (!(next = READ_ONCE(node->next)))
- cpu_relax_lowlatency();
+ cpu_relax();
}
/* Pass lock to next waiter. */
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index a70b90d..4463405 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -241,7 +241,7 @@ bool mutex_spin_on_owner(struct mutex *lock, struct
task_struct *owner)
break;
}
- cpu_relax_lowlatency();
+ cpu_relax();
}
rcu_read_unlock();
@@ -377,7 +377,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
* memory barriers as we'll eventually observe the right
* values at the cost of a few extra spins.
*/
- cpu_relax_lowlatency();
+ cpu_relax();
}
osq_unlock(&lock->osq);
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a3785..4ea2710 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -75,7 +75,7 @@ osq_wait_next(struct optimistic_spin_queue *lock,
break;
}
- cpu_relax_lowlatency();
+ cpu_relax();
}
return next;
@@ -122,7 +122,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
if (need_resched())
goto unqueue;
- cpu_relax_lowlatency();
+ cpu_relax();
}
return true;
@@ -148,7 +148,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
if (smp_load_acquire(&node->locked))
return true;
- cpu_relax_lowlatency();
+ cpu_relax();
/*
* Or we race against a concurrent unqueue()'s step-B, in which
diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
i
[GIT PULL v2 1/5] processor.h: introduce cpu_relax_yield
For spinning loops people do often use barrier() or cpu_relax().
For most architectures cpu_relax and barrier are the same, but on
some architectures cpu_relax can add some latency.
For example on power,sparc64 and arc, cpu_relax can shift the CPU
towards other hardware threads in an SMT environment.
On s390 cpu_relax does even more, it uses an hypercall to the
hypervisor to give up the timeslice.
In contrast to the SMT yielding this can result in larger latencies.
In some places this latency is unwanted, so another variant
"cpu_relax_lowlatency" was introduced. Before this is used in more
and more places, lets revert the logic and provide a cpu_relax_yield
that can be called in places where yielding is more important than
latency. By default this is the same as cpu_relax on all architectures.
Signed-off-by: Christian Borntraeger
---
arch/alpha/include/asm/processor.h | 1 +
arch/arc/include/asm/processor.h| 2 ++
arch/arm/include/asm/processor.h| 1 +
arch/arm64/include/asm/processor.h | 1 +
arch/avr32/include/asm/processor.h | 1 +
arch/blackfin/include/asm/processor.h | 1 +
arch/c6x/include/asm/processor.h| 1 +
arch/cris/include/asm/processor.h | 1 +
arch/frv/include/asm/processor.h| 1 +
arch/h8300/include/asm/processor.h | 1 +
arch/hexagon/include/asm/processor.h| 1 +
arch/ia64/include/asm/processor.h | 1 +
arch/m32r/include/asm/processor.h | 1 +
arch/m68k/include/asm/processor.h | 1 +
arch/metag/include/asm/processor.h | 1 +
arch/microblaze/include/asm/processor.h | 1 +
arch/mips/include/asm/processor.h | 1 +
arch/mn10300/include/asm/processor.h| 1 +
arch/nios2/include/asm/processor.h | 1 +
arch/openrisc/include/asm/processor.h | 1 +
arch/parisc/include/asm/processor.h | 1 +
arch/powerpc/include/asm/processor.h| 1 +
arch/s390/include/asm/processor.h | 3 ++-
arch/s390/kernel/processor.c| 4 ++--
arch/score/include/asm/processor.h | 1 +
arch/sh/include/asm/processor.h | 1 +
arch/sparc/include/asm/processor_32.h | 1 +
arch/sparc/include/asm/processor_64.h | 1 +
arch/tile/include/asm/processor.h | 1 +
arch/unicore32/include/asm/processor.h | 1 +
arch/x86/include/asm/processor.h| 1 +
arch/x86/um/asm/processor.h | 1 +
arch/xtensa/include/asm/processor.h | 1 +
33 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/alpha/include/asm/processor.h
b/arch/alpha/include/asm/processor.h
index 43a7559..0556fda 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -58,6 +58,7 @@ unsigned long get_wchan(struct task_struct *p);
((tsk) == current ? rdusp() : task_thread_info(tsk)->pcb.usp)
#define cpu_relax()barrier()
+#define cpu_relax_yield() cpu_relax()
#define cpu_relax_lowlatency() cpu_relax()
#define ARCH_HAS_PREFETCH
diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index 16b630f..6c158d5 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -60,6 +60,7 @@ struct task_struct;
#ifndef CONFIG_EZNPS_MTM_EXT
#define cpu_relax()barrier()
+#define cpu_relax_yield() cpu_relax()
#define cpu_relax_lowlatency() cpu_relax()
#else
@@ -67,6 +68,7 @@ struct task_struct;
#define cpu_relax() \
__asm__ __volatile__ (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
+#define cpu_relax_yield() cpu_relax()
#define cpu_relax_lowlatency() barrier()
#endif
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 8a1e8e9..db660e0 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -82,6 +82,7 @@ unsigned long get_wchan(struct task_struct *p);
#define cpu_relax()barrier()
#endif
+#define cpu_relax_yield()cpu_relax()
#define cpu_relax_lowlatency()cpu_relax()
#define task_pt_regs(p) \
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index 60e3482..3f9b0e5 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -149,6 +149,7 @@ static inline void cpu_relax(void)
asm volatile("yield" ::: "memory");
}
+#define cpu_relax_yield() cpu_relax()
#define cpu_relax_lowlatency()cpu_relax()
/* Thread switching */
diff --git a/arch/avr32/include/asm/processor.h
b/arch/avr32/include/asm/processor.h
index 941593c..e412e8b 100644
--- a/arch/avr32/include/asm/processor.h
+++ b/arch/avr32/include/asm/processor.h
@@ -92,6 +92,7 @@ extern struct avr32_cpuinfo boot_cpu_data;
#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 3))
#define cpu_relax()barrier()
+#define cpu_relax_yield() cpu_relax()
#define cpu_relax_lowlatency()cpu_relax()
#define cpu_sync_pipeline()asm volatile("sub pc, -2"
[GIT PULL v2 0/5] cpu_relax: drop lowlatency, introduce yield
Peter, here is v2 with some improved patch descriptions and some fixes. The previous version has survived one day of linux-next and I only changed small parts. So unless there is some other issue, feel free to pull (or to apply the patches) to tip/locking. The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69: Linux 4.9-rc2 (2016-10-23 17:10:14 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git tags/cpurelax for you to fetch changes up to dcc37f9044436438360402714b7544a8e8779b07: processor.h: remove cpu_relax_lowlatency (2016-10-25 09:49:57 +0200) cpu_relax: drop lowlatency, introduce yield For spinning loops people do often use barrier() or cpu_relax(). For most architectures cpu_relax and barrier are the same, but on some architectures cpu_relax can add some latency. For example on power,sparc64 and arc, cpu_relax can shift the CPU towards other hardware threads in an SMT environment. On s390 cpu_relax does even more, it uses an hypercall to the hypervisor to give up the timeslice. In contrast to the SMT yielding this can result in larger latencies. In some places this latency is unwanted, so another variant "cpu_relax_lowlatency" was introduced. Before this is used in more and more places, lets revert the logic and provide a cpu_relax_yield that can be called in places where yielding is more important than latency. By default this is the same as cpu_relax on all architectures. So my proposal boils down to: - lowest latency: use barrier() or mb() if necessary - low latency: use cpu_relax (e.g. might give up some cpu for the other _hardware_ threads) - really give up CPU: use cpu_relax_yield PS: In the long run I would also try to provide for s390 something like cpu_relax_yield_to with a cpu number (or just add that to cpu_relax_yield), since a yield_to is always better than a yield as long as we know the waiter. Christian Borntraeger (5): processor.h: introduce cpu_relax_yield stop_machine: yield CPU during stop machine s390: make cpu_relax a barrier again processor.h: Remove cpu_relax_lowlatency users processor.h: remove cpu_relax_lowlatency arch/alpha/include/asm/processor.h | 2 +- arch/arc/include/asm/processor.h| 4 ++-- arch/arm/include/asm/processor.h| 2 +- arch/arm64/include/asm/processor.h | 2 +- arch/avr32/include/asm/processor.h | 2 +- arch/blackfin/include/asm/processor.h | 2 +- arch/c6x/include/asm/processor.h| 2 +- arch/cris/include/asm/processor.h | 2 +- arch/frv/include/asm/processor.h| 2 +- arch/h8300/include/asm/processor.h | 2 +- arch/hexagon/include/asm/processor.h| 2 +- arch/ia64/include/asm/processor.h | 2 +- arch/m32r/include/asm/processor.h | 2 +- arch/m68k/include/asm/processor.h | 2 +- arch/metag/include/asm/processor.h | 2 +- arch/microblaze/include/asm/processor.h | 2 +- arch/mips/include/asm/processor.h | 2 +- arch/mn10300/include/asm/processor.h| 2 +- arch/nios2/include/asm/processor.h | 2 +- arch/openrisc/include/asm/processor.h | 2 +- arch/parisc/include/asm/processor.h | 2 +- arch/powerpc/include/asm/processor.h| 2 +- arch/s390/include/asm/processor.h | 4 ++-- arch/s390/kernel/processor.c| 4 ++-- arch/score/include/asm/processor.h | 2 +- arch/sh/include/asm/processor.h | 2 +- arch/sparc/include/asm/processor_32.h | 2 +- arch/sparc/include/asm/processor_64.h | 2 +- arch/tile/include/asm/processor.h | 2 +- arch/unicore32/include/asm/processor.h | 2 +- arch/x86/include/asm/processor.h| 2 +- arch/x86/um/asm/processor.h | 2 +- arch/xtensa/include/asm/processor.h | 2 +- drivers/gpu/drm/i915/i915_gem_request.c | 2 +- drivers/vhost/net.c | 4 ++-- kernel/locking/mcs_spinlock.h | 4 ++-- kernel/locking/mutex.c | 4 ++-- kernel/locking/osq_lock.c | 6 +++--- kernel/locking/qrwlock.c| 6 +++--- kernel/locking/rwsem-xadd.c | 4 ++-- kernel/stop_machine.c | 2 +- lib/lockref.c | 2 +- 42 files changed, 53 insertions(+), 53 deletions(-)
Re: [lkp] [perf powerpc] 18d1796d0b: [No primary change]
On Tue, Oct 25, 2016 at 02:40:13PM +0800, kernel test robot wrote:
> [will-it-scale] perf-stat.branch-miss-rate +7.4% regression
> Reply-To: kernel test robot
> User-Agent: Heirloom mailx 12.5 6/20/10
>
>
> FYI, we noticed a +7.4% regression of perf-stat.branch-miss-rate due to
> commit:
>
> commit 18d1796d0b45762ec6f58c5ed2ad3f7510ffbaa9 ("perf powerpc: Don't call
> perf_event_disable from atomic context")
> https://github.com/0day-ci/linux
> Jiri-Olsa/perf-powerpc-Don-t-call-perf_event_disable-from-atomic-context/20161006-203500
>
> in testcase: will-it-scale
> on test machine: 32 threads Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz with 64G
> memory
> with following parameters:
>
> test: poll2
> cpufreq_governor: performance
>
> Will It Scale takes a testcase and runs it from 1 through to n parallel
> copies to see if the testcase will scale. It builds both a process and
> threads based test in order to see any differences between the two.
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
>
> gcc-6/performance/x86_64-rhel-7.2/debian-x86_64-2016-08-31.cgz/lkp-sb03/poll2/will-it-scale
>
> commit:
> 41aad2a6d4 (" perf/core improvements and fixes:")
> 18d1796d0b ("perf powerpc: Don't call perf_event_disable from atomic
> context")
>
> 41aad2a6d4fcdda8 18d1796d0b45762ec6f58c5ed2
> --
>fail:runs %reproductionfail:runs
>| | |
> %stddev %change %stddev
> \ |\
> 0.19 ± 0% +7.4% 0.21 ± 0% perf-stat.branch-miss-rate%
> 9.591e+09 ± 1% +9.1% 1.047e+10 ± 0% perf-stat.branch-misses
> 1.962e+09 ± 0% +2.3% 2.008e+09 ± 1% perf-stat.cache-references
> 51.18 ± 2% +5.6% 54.06 ± 1% perf-stat.iTLB-load-miss-rate%
> 46430577 ± 5% -6.9% 43241506 ± 2% perf-stat.iTLB-loads
> 9.90 ± 4% +9.3% 10.82 ± 4% turbostat.Pkg%pc2
> 62066 ± 24% +34.7% 83582 ± 11% numa-meminfo.node1.Active
> 49531 ± 30% +42.9% 70778 ± 13% numa-meminfo.node1.Active(anon)
> 27883 ±100%-100.0% 0.00 ± -1%
> latency_stats.avg.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.do_syscall_64.return_from_SYSCALL_64
> 27883 ±100%-100.0% 0.00 ± -1%
> latency_stats.max.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.do_syscall_64.return_from_SYSCALL_64
> 32685 ± 38% +88.5% 61603 ±147%
> latency_stats.sum.call_rwsem_down_write_failed.path_openat.do_filp_open.do_sys_open.SyS_open.entry_SYSCALL_64_fastpath
> 27883 ±100%-100.0% 0.00 ± -1%
> latency_stats.sum.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.do_syscall_64.return_from_SYSCALL_64
> 92795 ± 4% -8.6% 84853 ± 6% numa-vmstat.node0.numa_hit
> 92782 ± 4% -8.5% 84851 ± 6% numa-vmstat.node0.numa_local
> 12381 ± 30% +42.9% 17694 ± 13% numa-vmstat.node1.nr_active_anon
> 12381 ± 30% +42.9% 17694 ± 13%
> numa-vmstat.node1.nr_zone_active_anon
> 21.80 ± 59% -69.8% 6.58 ± 83% sched_debug.cpu.clock.stddev
> 21.80 ± 59% -69.8% 6.58 ± 83%
> sched_debug.cpu.clock_task.stddev
> 0.00 ± 23% -34.3% 0.00 ± 20%
> sched_debug.cpu.next_balance.stddev
> 35829 ± 9% -18.4% 29221 ± 6% sched_debug.cpu.nr_switches.max
> 8361 ± 6% -13.4% 7243 ± 7%
> sched_debug.cpu.nr_switches.stddev
> 8.43 ± 11% -25.2% 6.30 ± 12%
> sched_debug.cpu.nr_uninterruptible.stddev
> 18057 ± 6% -14.3% 15482 ± 8%
> sched_debug.cpu.sched_count.stddev
>
ARGH... so what is the normal metric for this test and did that change?
And why can't I still find that? These reports suck!
The result doesn't make sense, my gcc inlines the function call, the
emitted code is very similar to the old code, with exception of one
extra symbol.
Are you sure this isn't simple run to run variation?
Re: [PATCH] mm: memcontrol: do not recurse in direct reclaim
On Mon 24-10-16 16:30:05, Johannes Weiner wrote: > On 4.0, we saw a stack corruption from a page fault entering direct > memory cgroup reclaim, calling into btrfs_releasepage(), which then > tried to allocate an extent and recursed back into a kmem charge ad > nauseam: > > [...] > [] btrfs_releasepage+0x2c/0x30 > [] try_to_release_page+0x32/0x50 > [] shrink_page_list+0x6da/0x7a0 > [] shrink_inactive_list+0x1e5/0x510 > [] shrink_lruvec+0x605/0x7f0 > [] shrink_zone+0xee/0x320 > [] do_try_to_free_pages+0x174/0x440 > [] try_to_free_mem_cgroup_pages+0xa7/0x130 > [] try_charge+0x17b/0x830 > [] memcg_charge_kmem+0x40/0x80 > [] new_slab+0x2d9/0x5a0 > [] __slab_alloc+0x2fd/0x44f > [] kmem_cache_alloc+0x193/0x1e0 > [] alloc_extent_state+0x21/0xc0 > [] __clear_extent_bit+0x2b5/0x400 > [] try_release_extent_mapping+0x1a3/0x220 > [] __btrfs_releasepage+0x31/0x70 > [] btrfs_releasepage+0x2c/0x30 > [] try_to_release_page+0x32/0x50 > [] shrink_page_list+0x6da/0x7a0 > [] shrink_inactive_list+0x1e5/0x510 > [] shrink_lruvec+0x605/0x7f0 > [] shrink_zone+0xee/0x320 > [] do_try_to_free_pages+0x174/0x440 > [] try_to_free_mem_cgroup_pages+0xa7/0x130 > [] try_charge+0x17b/0x830 > [] mem_cgroup_try_charge+0x65/0x1c0 > [] handle_mm_fault+0x117f/0x1510 > [] __do_page_fault+0x177/0x420 > [] do_page_fault+0xc/0x10 > [] page_fault+0x22/0x30 > > On later kernels, kmem charging is opt-in rather than opt-out, and > that particular kmem allocation in btrfs_releasepage() is no longer > being charged and won't recurse and overrun the stack anymore. But > it's not impossible for an accounted allocation to happen from the > memcg direct reclaim context, and we needed to reproduce this crash > many times before we even got a useful stack trace out of it. I agree that stack overruns are really nasty to debug. Been there done that, hate it... I would argue that we shouldn't account arbitrary objects and most of them should be directly related to a user visible API which shouldn't happen from the reclaim path. But the reality is that we reuse the code and we can easily end up in the situation similat to the one above so I agree that being more careful is definitely worth it. > Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC > to avoid recursing into any other form of direct reclaim. Then let > recursive charges from PF_MEMALLOC contexts bypass the cgroup limit. Yes, as long as the allocation is still properly accounted then this is the right way to go. We can breach the limit already. The outer reclaim loop would push back to the limit anyway. > Signed-off-by: Johannes Weiner Acked-by: Michal Hocko One nit below > --- > mm/memcontrol.c | 9 + > mm/vmscan.c | 2 ++ > 2 files changed, 7 insertions(+), 4 deletions(-) > > Hey guys, can anyone think of a reason why this might not be a good > idea? We've never really needed this in the past because page reclaim > doesn't recurse into instantiating another LRU page, especially with > GFP_NOFS. But with a wider variety of tracked allocations, it's no > longer that obvious. It seems like a risky hole to leave around. > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index ae052b5e3315..3dac6f4ba4cf 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -1908,13 +1908,14 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t > gfp_mask, > > /* >* Unlike in global OOM situations, memcg is not in a physical > - * memory shortage. Allow dying and OOM-killed tasks to > - * bypass the last charges so that they can exit quickly and > - * free their memory. > + * memory shortage. Allow dying and OOM-killed tasks to bypass > + * the last charges so that they can exit quickly and free > + * their memory. The same applies for recursing reclaimers. >*/ > if (unlikely(test_thread_flag(TIF_MEMDIE) || >fatal_signal_pending(current) || > - current->flags & PF_EXITING)) > + current->flags & PF_EXITING || > + current->flags & PF_MEMALLOC)) > goto force; I would prefer to have the PF_MEMALLOC condition in a check on its own with a short explanation that we really do not want to recurse to the reclaim due to stack overflows. > if (unlikely(task_in_memcg_oom(current))) > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 744f926af442..76fda2268148 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3043,7 +3043,9 @@ unsigned long try_to_free_mem_cgroup_pages(struct > mem_cgroup *memcg, > sc.gfp_mask, > sc.reclaim_idx); > > + current->flags |= PF_MEMALLOC; > nr_reclaimed = do_try_to_free_pages(zonelist, &sc); > + current->flags &= ~PF_MEMALLOC; > > trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed); > > -- > 2.10.0 -- Michal Hocko SUSE Labs
Re: [PATCH 3/3] [media] au0828-video: Move two assignments in au0828_init_isoc()
This patch introduces bugs. It's my policy to not explain the Markus's bugs because otherwise he will just resend the patchset and I have asked him many times to stop. I will happily review bug fix patches but I really think he should stop sending these cleanup patches. regards, dan carpenter
Re: [PATCH 4/4] MIPS/kernel/proc: Combine four seq_printf() calls into one call in show_cpuinfo()
On Tue, Oct 25, 2016 at 10:55:42AM +0200, Geert Uytterhoeven wrote: > > - seq_printf(m, "shadow register sets\t: %d\n", > > - cpu_data[n].srsets); > > - seq_printf(m, "kscratch registers\t: %d\n", > > - hweight8(cpu_data[n].kscratch_mask)); > > - seq_printf(m, "package\t\t\t: %d\n", cpu_data[n].package); > > - seq_printf(m, "core\t\t\t: %d\n", cpu_data[n].core); > > + seq_printf(m, > > + "shadow register sets\t: %d\n" > > + "kscratch registers\t: %d\n" > > + "package\t\t\t: %d\n" > > + "core\t\t\t: %d\n", > > + cpu_data[n].srsets, > > + hweight8(cpu_data[n].kscratch_mask), > > + cpu_data[n].package, > > + cpu_data[n].core); > > I think the code is much easier to read with separate seq_printf()s for > each line printed. Which is why I originally implemented this as separate function calls. Code size and performance are hardly an argument for /proc/cpuinfo. Ralf
Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories
On Mon, Oct 24, 2016 at 7:37 PM, Cyrille Pitchen wrote: > Le 24/10/2016 à 14:09, Cyrille Pitchen a écrit : >> Hi Jagan, >> >> Le 24/10/2016 à 09:41, Jagan Teki a écrit : >>> On Sun, Oct 23, 2016 at 2:03 AM, Marek Vasut wrote: On 10/22/2016 01:00 PM, Jagan Teki wrote: > On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen > wrote: >> Hi all, >> >> This series extends support of SPI protocols to new protocols such as >> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the >> right >> op codes, timing parameters (number of mode and dummy cycles) and erase >> sector size by parsing the Serial Flash Discoverable Parameter (SFDP) >> tables, when available, as defined in the JEDEC JESD216 specifications. >> >> When SFDP tables are not available, legacy settings are still used for >> backward compatibility (SPI and earlier QSPI memories). >> >> Support of SPI memories >128Mbits is also improved by using the 4byte >> address instruction set, when available. Using those dedicated op codes >> is stateless as opposed to enter the 4byte address mode, hence a better >> compatibility with some boot loaders which expect to use 3byte address >> op codes. > > The memories which are > 128Mbits should have 4-bytes addressing > support based on my experience, do you think BAR is also required > atleast from spi-nor side? Yes, I believe BAR is still required for broken/dumb flash chips. Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-( >>> >>> Do you have list for those broken chips? because I never find any >>> chips which has > 16 MiB with not support of 4-byte address opcodes >>> and I've seen the controller has dependable with BAR though it can >>> access > 16MiB ex: zynq qspi/ >>> >>> thanks! >>> >> >> Let's take the case of Micron n25q256* memories. Depending of the part >> number, >> the 12h op code is associated with either 4-byte address Page Program 1-1-1 >> or 3-byte address Page Program 1-4-4. >> Then considering parts where the 12h op code is used for 3-byte address Page >> Program 1-4-4, there is no op code for a 4-byte address Page Program 1-1-1. >> >> Note 15, extracted from the Micron n25q_256mb_3v_65nm.pdf datasheet, about >> the 3-byte address Page Program 1-4-4 (Extended Quad Input Fast Program): >> The code 38h is valid only for part numbers N25Q256A83ESF40x, >> N25Q256A83E1240x >> and N25Q256A83ESFA0F; the code 12h is valid for the other part numbers. >> >> Hence most of the Micron n25q256* memories has no op code for 4-byte address >> Page Program 1-1-1. >> Then we could use the 34h op code instead to perform 4-byte address Page >> Program 1-1-4 but some SPI controllers might not support the SPI 1-1-4 >> protocol >> for Page Program operations. Sp entering the 4-byte address mode or using >> the BAR might still be the only solutions in those cases. >> >> Also, I'm pretty sure some other SPI NOR memories support 4-byte address Fast >> Read op codes but only 3-byte address op codes for Page Program and Sector >> Erase. I will look at the datasheets I have to find and provide an example. >> >> > > Even worse, let's take the example for Macronix MX25L25635* and MX25L25673*: > they both share the very same JEDEC ID. The older part (35) doesn't support > the 4-byte address instruction set at all whereas the newer part (73) does. So, though we have a support of 4-byte opcode, few of the reads will still way back to use 3-byte opcode is it? If ie the case may be we can directly rely on 4-byte opcode page program or reads instead of creating check for which opcode support which bytes address, IMHO. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.
Re: [RFC v3 1/6] Track the active utilisation
Il 24/10/2016 16:06, Luca Abeni ha scritto:
> The active utilisation here is defined as the total utilisation of the
> active (TASK_RUNNING) tasks queued on a runqueue. Hence, it is increased
> when a task wakes up and is decreased when a task blocks.
>
> When a task is migrated from CPUi to CPUj, immediately subtract the task's
> utilisation from CPUi and add it to CPUj. This mechanism is implemented by
> modifying the pull and push functions.
> Note: this is not fully correct from the theoretical point of view
> (the utilisation should be removed from CPUi only at the 0 lag time),
> but doing the right thing would be _MUCH_ more complex (leaving the
> timer armed when the task is on a different CPU... Inactive timers should
> be moved from per-task timers to per-runqueue lists of timers! Bah...)
>
> The utilisation tracking mechanism implemented in this commit can be
> fixed / improved by decreasing the active utilisation at the so-called
> "0-lag time" instead of when the task blocks.
>
> Signed-off-by: Juri Lelli
> Signed-off-by: Luca Abeni
> ---
> kernel/sched/deadline.c | 39 ++-
> kernel/sched/sched.h| 6 ++
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 37e2449..3d95c1d 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -43,6 +43,22 @@ static inline int on_dl_rq(struct sched_dl_entity *dl_se)
> return !RB_EMPTY_NODE(&dl_se->rb_node);
> }
>
> +static void add_running_bw(struct sched_dl_entity *dl_se, struct dl_rq
> *dl_rq)
> +{
> + u64 se_bw = dl_se->dl_bw;
> +
> + dl_rq->running_bw += se_bw;
> +}
why not...
static *inline*
void add_running_bw(struct sched_dl_entity *dl_se, struct dl_rq *dl_rq)
{
dl_rq->running_bw += dl_se->dl_bw;
}
am I missing something?
> +static void sub_running_bw(struct sched_dl_entity *dl_se, struct dl_rq
> *dl_rq)
> +{
> + u64 se_bw = dl_se->dl_bw;
> +
> + dl_rq->running_bw -= se_bw;
> + if (WARN_ON(dl_rq->running_bw < 0))
> + dl_rq->running_bw = 0;
> +}
(if I am not missing anything...)
the same in the above function: use inline and remove the se_bw variable.
-- Daniel
Re: [PATCH] pinctrl: imx: reset group index on probe
On Tue, Oct 18, 2016 at 11:09 PM, Stefan Agner wrote: > Group index is incremented on every new group parsed. Since the > field is part of struct imx_pinctrl_soc_info, which is typically > a global variable passed by the individual pinctrl-imx.c based > driver, it does not get cleared automatically when re-probing the > driver. This lead imx_pinctrl_parse_functions passing a group > pointer which is outside of the allocated group space on second > probe and onwards. Typically this ended up in a NULL pointer > dereference when accessing the name field like this: > Unable to handle kernel NULL pointer dereference at virtual address > ... > PC is at strcmp+0x18/0x44 > LR is at imx_dt_node_to_map+0xc4/0x290 > > Avoid this by setting group_index to 0 on probe. > > This has been observed when using DEBUG_TEST_DRIVER_REMOVE. > > Signed-off-by: Stefan Agner Patch applied for fixes. Should it be tagged for stable too? Yours, Linus Walleij
Re: [PATCH] i2c: hix5hd2: allow build with ARCH_HISI
On Mon, Oct 24, 2016 at 04:39:49PM +0800, Ruqiang Ju wrote: > This driver should be buildable with ARCH_HISI, > because some of other HiSilicon SoCs also use it. > > Signed-off-by: Ruqiang Ju Applied to for-current, thanks! signature.asc Description: PGP signature
Re: [PATCH] pinctrl: imx: reset group index on probe
On Wed, Oct 19, 2016 at 12:40 AM, Vladimir Zapolskiy wrote: > I've recently developed a pinctrl driver for the last remaining > i.MX31 platform from the SoC series (not published yet), it does > not fit well under any of the 3 existing drivers, and instead > of adding 1.5K lines of code with half of them almost copy-pasted > from the rest drivers I started to work on generalization of the > i.MX/Vybrid pinctrl/pinmux drivers. That is a noble task. > This task is large and I'm not sure when I complete and share > the results, but your change conflicts with one of the changes > in my backlog... Let me share it with you right now, because it > deals with info->group_index from another point of view and it > (unlikely) may have an impact on Vybrid platform, which I can not > test. I have to merge this patch to fix an upstream regression (I guess? No response from mantainers) so I guee you'll have to rebase your series onto whatever release candidate has it. Shouldn't be too hard I guess. Yours, Linus Walleij
Re: [PATCH 13/37] staging:r8188eu: remove debug messages after memory allocation failed
On Wed, Oct 19, 2016 at 10:07:41PM +0700, Ivan Safonov wrote: > These messages are redundant. > Also break rtw_usb_if1_init function if HalData allocation failed. > > Signed-off-by: Ivan Safonov Since you're redoing this anyway, please split this one into two patches. We really frown on mixing bugfixes with cleanups. I wasn't frowning on it enough to ask you to redo the series but since you're already doing that... regards, dan carpenter
Re: [PATCH] i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings
On Sat, Oct 22, 2016 at 04:43:42PM +0800, David Wu wrote: > We found a bug that i2c transfer sometimes failed on 3066a board with > stabel-4.8, the con register would be updated by uninitialized tuning > value, it made the i2c transfer failed. > > So give the tuning value to be zero during rk3x_i2c_v0_calc_timings. > > Signed-off-by: David Wu Added stable and applied to for-current, thanks! signature.asc Description: PGP signature
Re: [PATCH 4/9] pinctrl: meson: allow gpio to request irq
On Fri, Oct 21, 2016 at 11:06 AM, Jerome Brunet wrote: >> Isn't this usecase (also as described in the cover letter) a textbook >> example of when you should be using hierarchical irqdomain? >> >> Please check with Marc et al on hierarchical irqdomains. > > Linus, > Do you mean I should create a new hierarchical irqdomains in each of > the two pinctrl instances we have in these SoC, these domains being > stacked on the one I just added for controller in irqchip ? > > I did not understand this is what you meant when I asked you the > question at ELCE. Honestly, I do not understand when and where to properly use hierarchical irqdomain, even after Marc's talk at ELC-E. Which is problematic since quite a few GPIO drivers now need to use them. I will review his slides, in the meantime I would say: whatever Marc ACKs is fine with me. I trust this guy 100%. So I guess I could ask that he ACK the entire chain of patches from GIC->specialchip->GPIO. Yours, Linus Walleij
[PATCH] kbuild/mkspec: avoid using brace expansion
Brace expansion might not work properly if _buildshell RPM macro
points to a shell other than bash. Particularly, with _bulidshell
defined to /bin/dash it leads to broken build and source symlinks.
Signed-off-by: Anton Tikhomirov
---
scripts/package/mkspec | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index 57673ba..bb43f15 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/mkspec
@@ -116,7 +116,8 @@ echo 'mv vmlinux.bz2
$RPM_BUILD_ROOT'"/boot/vmlinux-$KERNELRELEASE.bz2"
echo "%endif"
if ! $PREBUILT; then
-echo 'rm -f $RPM_BUILD_ROOT'"/lib/modules/$KERNELRELEASE/{build,source}"
+echo 'rm -f $RPM_BUILD_ROOT'"/lib/modules/$KERNELRELEASE/build"
+echo 'rm -f $RPM_BUILD_ROOT'"/lib/modules/$KERNELRELEASE/source"
echo "mkdir -p "'$RPM_BUILD_ROOT'"/usr/src/kernels/$KERNELRELEASE"
echo "EXCLUDES=\"$RCS_TAR_IGNORE --exclude .tmp_versions --exclude=*vmlinux*
--exclude=*.o --exclude=*.ko --exclude=*.cmd --exclude=Documentation
--exclude=firmware --exclude .config.old --exclude .missing-syscalls.d\""
echo "tar "'$EXCLUDES'" -cf- . | (cd
"'$RPM_BUILD_ROOT'"/usr/src/kernels/$KERNELRELEASE;tar xvf -)"
--
2.7.4
Re: [PATCH] gpio: mpc8xxx: Correct irq handler function
On Mon, Oct 24, 2016 at 5:46 AM, Gang Liu wrote: >> On Fri, Oct 21, 2016 at 9:31 AM, Liu Gang wrote: >> >> > From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq" >> > has being used to handle GPIO interrupts in the PowerPC/Layerscape >> > platforms. But actually, almost all PowerPC/Layerscape platforms >> > assert an interrupt request upon either a high-to-low change or any >> > change on the state of the signal. >> > >> > So the "handle_level_irq" is not reasonable for PowerPC/Layerscape >> > GPIO interrupt, it should be "handle_edge_irq". Otherwise the system >> > may lost some interrupts from the PIN's state changes. >> > >> > Signed-off-by: Liu Gang >> >> Yes and especially so since this irqchip implements .irq_ack() and unless you >> use the edge handler it will never be called. >> >> Patch applied for fixes, tell me if it also needs to go into stable. >> > [Liu Gang] yes, please also put it into stable. Thanks! Ooops too late. Will tell Greg to pick this separately. Yours, Linus Walleij
Re: [PATCH v3 2/9] mtd: spi-nor: add an alternative method to support memory >16MiB
Le 25/10/2016 à 00:10, Marek Vasut a écrit :
> On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
>> This patch provides an alternative mean to support memory above 16MiB
>> (128Mib) by replacing 3byte address op codes by their associated 4byte
>> address versions.
>>
>> Using the dedicated 4byte address op codes doesn't change the internal
>> state of the SPI NOR memory as opposed to using other means such as
>> updating a Base Address Register (BAR) and sending command to enter/leave
>> the 4byte mode.
>>
>> Hence when a CPU reset occurs, early bootloaders don't need to be aware
>> of BAR value or 4byte mode being enabled: they can still access the first
>> 16MiB of the SPI NOR memory using the regular 3byte address op codes.
>>
>> Signed-off-by: Cyrille Pitchen
>> Tested-by: Vignesh R
>> ---
>> drivers/mtd/devices/serial_flash_cmds.h | 7 ---
>> drivers/mtd/devices/st_spi_fsm.c| 28 -
>> drivers/mtd/spi-nor/spi-nor.c | 104
>> +---
>> include/linux/mtd/spi-nor.h | 22 +--
>> 4 files changed, 113 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/mtd/devices/serial_flash_cmds.h
>> b/drivers/mtd/devices/serial_flash_cmds.h
>> index f59a125295d0..8b81e15105dd 100644
>> --- a/drivers/mtd/devices/serial_flash_cmds.h
>> +++ b/drivers/mtd/devices/serial_flash_cmds.h
>> @@ -18,19 +18,12 @@
>> #define SPINOR_OP_RDVCR 0x85
>>
>> /* JEDEC Standard - Serial Flash Discoverable Parmeters (SFDP) Commands */
>> -#define SPINOR_OP_READ_1_2_20xbb/* DUAL I/O READ */
>> -#define SPINOR_OP_READ_1_4_40xeb/* QUAD I/O READ */
>> -
>> #define SPINOR_OP_WRITE 0x02/* PAGE PROGRAM */
>> #define SPINOR_OP_WRITE_1_1_2 0xa2/* DUAL INPUT PROGRAM */
>> #define SPINOR_OP_WRITE_1_2_2 0xd2/* DUAL INPUT EXT PROGRAM */
>> #define SPINOR_OP_WRITE_1_1_4 0x32/* QUAD INPUT PROGRAM */
>> #define SPINOR_OP_WRITE_1_4_4 0x12/* QUAD INPUT EXT PROGRAM */
>>
>> -/* READ commands with 32-bit addressing */
>> -#define SPINOR_OP_READ4_1_2_2 0xbc
>> -#define SPINOR_OP_READ4_1_4_4 0xec
>> -
>
> It'd be nice to have this move/rename bit factored out into a separate
> patch.
>
OK, I will try to do this. Anyway, this rename seems to break the freshly
merged drivers/spi/spi-bcm-qspi.c, which uses the SPINOR_OP_READ4_* macro so
I have to do something about this driver. IMHO, the broadcom driver should not
select its own op code but use the one provided by read_opcode member of the
struct spi_flash_read_message.
>> /* Configuration flags */
>> #define FLASH_FLAG_SINGLE 0x00ff
>> #define FLASH_FLAG_READ_WRITE 0x0001
>> diff --git a/drivers/mtd/devices/st_spi_fsm.c
>> b/drivers/mtd/devices/st_spi_fsm.c
>> index 5454b4113589..804313a33f2b 100644
>
> [...]
>
>> +static u8 spi_nor_convert_opcode(u8 opcode,
>> + const struct spi_nor_address_entry *entries,
>> + size_t num_entries)
>> +{
>> +int min, max;
>> +
>> +min = 0;
>> +max = num_entries - 1;
>> +while (min <= max) {
>
> It's really not clear at all what this function does, so please add a
> comment.
>
This is just a dichotomic search to reduce the number of comparisons: it
assumes the entries[] array is sorted by ascending src_opcode.
I will add a comment to clarify this point.
>> +int mid = (min + max) >> 1;
>> +const struct spi_nor_address_entry *entry = &entries[mid];
>> +
>> +if (opcode == entry->src_opcode)
>> +return entry->dst_opcode;
>> +
>> +if (opcode < entry->src_opcode)
>> +max = mid - 1;
>> +else
>> +min = mid + 1;
>> +}
>> +
>> +/* No conversion found */
>> +return opcode;
>> +}
>> +
>> +static u8 spi_nor_3to4_opcode(u8 opcode)
>> +{
>> +/* MUST be sorted by 3byte opcode */
>
> Because ... why ?
>
As explained above, the dichotomic search implemented in
spi_nor_convert_opcode() assumes that the input array is sorted by src_opcode.
>> +#define ENTRY_3TO4(_opcode) { _opcode, _opcode##_4B }
>
> Will this break/be unflexible for flashes with some different 4B opcodes ?
>
Of course I cannot provide any guarantee that it will never happen but
currently it seems that all manufacturers use the same op codes. Besides,
the 4-byte address instruction set is part the of JESD216B specification,
so there is a standard for these op codes and new SPI NOR memories tend
to match this specification by providing the SFDP tables.
Indeed this instruction set is maybe one of the few things where all
manufacturers seem to agree :)
>> +static const struct spi_nor_address_entry spi_nor_3to4_table[] = {
>> +ENTRY_3TO4(SPINOR_OP_PP), /* 0x02 */
>> +ENTRY_3TO4(SPINOR_OP_READ), /* 0x03 */
>> +ENTRY_3TO4(SPINOR_OP_READ_FAST)
Re: [PATCH/RFT v2 03/17] ARM: davinci: da8xx: Add USB PHY platform declaration
On Monday 24 October 2016 10:16 PM, ahas...@baylibre.com wrote:
> +static struct platform_device da8xx_usb_phy = {
> + .name = "da8xx-usb-phy",
> + .id = 0,
There is a single phy control in the system for both 1.1 and 2.0 PHYs.
so this can be a singular device (id -1).
Thanks,
Sekhar
Re: [PATCH 03/10] mpt3sas: Implement device_remove_in_progress check in IOCTL path
Hi Hannes,
Please give us little more info on the third comment. It ll help us to
understand better and
incorporate required changes.
Comment is "Why don't you need to check for the size of the bitmap here?"
i have taken care of other two comments in this patch.
> /* check if device is present */
> @@ -5467,6 +5482,7 @@ _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16
> handle, u8 phy_num,
> sas_device = mpt3sas_get_sdev_by_addr(ioc,
> sas_address);
> if (sas_device) {
> + clear_bit(handle, ioc->pend_os_device_add);
> sas_device_put(sas_device);
> return -1;
> }
Why don't you need to check for the size of the bitmap here?
Thanks,
Suganath Prabu S
On Mon, Oct 24, 2016 at 8:17 PM, Hannes Reinecke wrote:
> On 10/20/2016 02:20 PM, Suganath Prabu S wrote:
>>
>> When device missing event arrives, device_remove_in_progress bit will be
>> set and hence driver has to stop sending IOCTL commands.Now the check has
>> been added in IOCTL path to test device_remove_in_progress bit is set, if
>> so then IOCTL will be failed printing failure message.
>>
>> Signed-off-by: Chaitra P B
>> Signed-off-by: Sathya Prakash
>> Signed-off-by: Suganath Prabu S
>> ---
>> drivers/scsi/mpt3sas/mpt3sas_base.c | 19 +++
>> drivers/scsi/mpt3sas/mpt3sas_base.h | 5
>> drivers/scsi/mpt3sas/mpt3sas_ctl.c | 46
>> ++--
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 24 ++-
>> 4 files changed, 86 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> index 4ea81e1..9ad7f7c 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> @@ -5334,6 +5334,21 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
>> goto out_free_resources;
>> }
>>
>> + /* allocate memory for pending OS device add list */
>> + ioc->pend_os_device_add_sz = (ioc->facts.MaxDevHandle / 8);
>> + if (ioc->facts.MaxDevHandle % 8)
>> + ioc->pend_os_device_add_sz++;
>> + ioc->pend_os_device_add = kzalloc(ioc->pend_os_device_add_sz,
>> + GFP_KERNEL);
>> + if (!ioc->pend_os_device_add)
>> + goto out_free_resources;
>> +
>> + ioc->device_remove_in_progress_sz = ioc->pend_os_device_add_sz;
>> + ioc->device_remove_in_progress =
>> + kzalloc(ioc->device_remove_in_progress_sz, GFP_KERNEL);
>> + if (!ioc->device_remove_in_progress)
>> + goto out_free_resources;
>> +
>> ioc->fwfault_debug = mpt3sas_fwfault_debug;
>>
>> /* base internal command bits */
>> @@ -5416,6 +5431,8 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
>> kfree(ioc->reply_post_host_index);
>> kfree(ioc->pd_handles);
>> kfree(ioc->blocking_handles);
>> + kfree(ioc->device_remove_in_progress);
>> + kfree(ioc->pend_os_device_add);
>> kfree(ioc->tm_cmds.reply);
>> kfree(ioc->transport_cmds.reply);
>> kfree(ioc->scsih_cmds.reply);
>> @@ -5457,6 +5474,8 @@ mpt3sas_base_detach(struct MPT3SAS_ADAPTER *ioc)
>> kfree(ioc->reply_post_host_index);
>> kfree(ioc->pd_handles);
>> kfree(ioc->blocking_handles);
>> + kfree(ioc->device_remove_in_progress);
>> + kfree(ioc->pend_os_device_add);
>> kfree(ioc->pfacts);
>> kfree(ioc->ctl_cmds.reply);
>> kfree(ioc->ctl_cmds.sense);
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
>> b/drivers/scsi/mpt3sas/mpt3sas_base.h
>> index 3e71bc1..4221a4d 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
>> @@ -1079,6 +1079,9 @@ struct MPT3SAS_ADAPTER {
>> void*pd_handles;
>> u16 pd_handles_sz;
>>
>> + void*pend_os_device_add;
>> + u16 pend_os_device_add_sz;
>> +
>> /* config page */
>> u16 config_page_sz;
>> void*config_page;
>> @@ -1187,6 +1190,8 @@ struct MPT3SAS_ADAPTER {
>> struct SL_WH_EVENT_TRIGGERS_T diag_trigger_event;
>> struct SL_WH_SCSI_TRIGGERS_T diag_trigger_scsi;
>> struct SL_WH_MPI_TRIGGERS_T diag_trigger_mpi;
>> + void*device_remove_in_progress;
>> + u16 device_remove_in_progress_sz;
>> };
>>
>> typedef u8 (*MPT_CALLBACK)(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8
>> msix_index,
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
>> b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
>> index 26cdc12..f204ce1 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
>> @@ -654,6 +654,7 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc,
>> struct mpt3_ioctl_command karg,
>> size_t data_in_sz = 0;
>> long ret;
>> u16 wa
Re: [PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation
On Mon, Oct 17, 2016 at 03:59:57PM +0200, Ralf Ramsauer wrote:
> Instantiated I2C device nodes are marked with OF_POPULATE. This was
> introduced in 4f001fd. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
>
> If a I2C driver module is unloaded and reloaded, it will skip nodes that
> failed before.
>
> Skip device nodes that are already populated and mark them only in case
> of success.
>
> Note that the same issue exists for SPI.
>
> Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer
Applied to for-current, thanks!
signature.asc
Description: PGP signature
Re: Disabling an interrupt in the handler locks the system up
On Tue, 25 Oct 2016, Sebastian Frias wrote: > On 10/24/2016 06:55 PM, Thomas Gleixner wrote: > > On Mon, 24 Oct 2016, Mason wrote: > >> > >> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device > >> makes the system lock-up disappear. > > > > The way how lazy irq disabling works is: > > > > 1) Interrupt is marked disabled in software, but the hardware is not masked > > > > 2) If the interrupt fires befor the interrupt is reenabled, then it's > >masked at the hardware level in the low level interrupt flow handler. > > > Would you mind explaining what is the intention behind? > Because it does not seem obvious why there isn't a direct map between > "disable_irq*()" and "mask_irq()" Two reasons for this: 1) If you mask edge type interrupts then you might race with an incoming interrupt which then gets lost and eventually you won't get another interrupt from that device. Even if there is no race, then on many irq chips edge type interrupts are not latched when the interrupt line is masked. That also can result in a stale interrupt line. With the lazy disabling we mask only if an interrupt fires while it's disabled in software. We note that it is pending and resend it when the interrupt gets reenabled. 2) Accessing irq chip hardware can be slow and we have situations where interrupts are disabled/enabled fast. So it's an optimization to avoid the hardware access, which is sensible as we do not expect an interrupt to fire in most cases. If it fires then we mask it when the interrupt handler sees the disabled flag. That should really work on any hardware and the IRQ_DISABLE_UNLAZY flag is just there to deal with devices which are known to keep the (level based) irq line active. In that case we know that we always take an interrupt to mask it right away, so we can avoid the overhead. Though you should not set that flag on edge type interrupts, unless your hardware guarantees to avoid the issues described in #1. Hope that helps. Thanks, tglx
[PATCH v2] Staging:dgnc:dgnc_tty: fix Block comments should align the * on each line
Block comments should align the * on each line as reported by checkpatch.pl Signed-off-by: Nadim Almas --- Changes in v2: - Made subject better drivers/staging/dgnc/dgnc_tty.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c index cf8aefd..94c4840 100644 --- a/drivers/staging/dgnc/dgnc_tty.c +++ b/drivers/staging/dgnc/dgnc_tty.c @@ -2707,7 +2707,7 @@ static int dgnc_tty_ioctl(struct tty_struct *tty, unsigned int cmd, uint loopback = 0; /* Let go of locks when accessing user space, * could sleep - */ +*/ spin_unlock_irqrestore(&ch->ch_lock, flags); rc = get_user(loopback, (unsigned int __user *)arg); if (rc) -- 2.7.4
Re: [RFC PATCH] sched/deadline: show leftover runtime and abs deadline in /proc/-/sched
On Tue, Oct 25, 2016 at 12:32:53AM +0200, Tommaso Cucinotta wrote: > Hi all, > > this is a tiny patch providing readings of the current (leftover) > runtime and absolute deadline in /proc/*/sched. Mostly useful for > debugging, I heard others playing with SCHED_DEADLINE had some need > for similar patches as well. > > In addition to debugging, reading the leftover runtime is generally > useful for adaptive/incremental RT logics that need to check whether > there's enough runtime left for refining the computed result, or just > use what we've computed so far and block till the next instance. > Also, knowing what the absolute scheduling deadline is (along with > what clock it refers to) might be useful for synchronization purposes. > (albeit, for real production code, I wouldn't like to parse /proc anyway, > rather I'd prefer to retrieve those params via eg sched_getscheduler()?) So for programmatic use, this interface is not recommended. For debugging this is fine. Not sure what form the programmatic interface should take, we have precedence in sys_sched_rr_get_interval() for a syscall (we could even abuse this one). Anybody any ideas?
