RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
> >> +
> >> +static int __init hisi_pcie_init(void)
> >> +{
> >> + return platform_driver_probe(&hisi_pcie_driver, hisi_pcie_probe);
> >> +}
> >> +subsys_initcall(hisi_pcie_init);
> >
> > Can you use module_platform_driver() or module_platform_driver_probe()
> > here instead of the subsys_initcall()? No, I don't really know what
> > the difference between module_platform_driver() and
> > module_platform_driver_probe() is, sorry :)
>
> In fact, I used module_platform_driver_probe in previous version, but
> A PCIe VGA card of HiSilicon will use Hip05 PCIe host, so we modified
> module_platform_driver_probe to subsys_initcall which will be called
> before module_platform_driver_probe.
>
> We will upstream the driver of above PCIe VGA card soon.
>
> Many thanks for your reviewing,
> Zhou
Hi Bjorn, firstly many thanks for looking at this.
About this last bit the reason why we use subsys_initcall() is that
our host bridge is embedded in the SoC and as such is not hot-pluggable
for instance see:
http://lxr.free-electrons.com/source/Documentation/driver-model/platform.txt#L59
Our approach is also used by Exynos:
http://lxr.free-electrons.com/source/drivers/pci/host/pci-exynos.c#L644
Cheers
Gab
>
> >
> > Bjorn
> >
> > .
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC V2 0/3] Input: goodix - add axis swapping and axis inversion support
> -Original Message- > From: Karsten Merker [mailto:mer...@debian.org] > Sent: 09 October, 2015 20:56 > To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin; > linux-in...@vger.kernel.org; Ian Campbell > Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai; > Karsten Merker > Subject: [PATCH RFC V2 0/3] Input: goodix - add axis swapping and axis > inversion support > > Hello, > > this is v2 of my "Input: goodix - add axis swapping and axis inversion > support" patchset. > The goodix touchscreen driver has gained device-tree support in kernel > 4.1, but doesn't currently support the touchscreen-swapped-x-y, > touchscreen-inverted-x and touchscreen-inverted-y properties. > > On systems which combine a portrait-mode display with a landscape-mode > touchscreen, such as e.g. the MSI Primo 81 tablet, support for these > features is necessary to have the touchscreen and the display use the > same coordinate system. > > With support for axis inversion, the "rotated_screen" flag in the > driver can also be removed, as "rotated_screen" is just a special case > of x/y axis inversion. > > This patchset sits on top of the "[PATCH v8 0/9] Goodix touchscreen > enhancements" series by Irina Tirdea: > https://www.spinics.net/lists/linux-input/msg41437.html > > I have successfully tested the axis swapping on an (arm-based) MSI > Primo 81 tablet, but I lack appropriate hardware to do a real-world > test of the "rotated_screen" code path, so I would appreciate very > much if somebody with appropriate hardware (WinBook TW100 or TW700) > could give it a try. > > Regards, > Karsten > Hi Karsten, I took a look at your patches and also did a quick test on my setup. Code looks good, I have just one comment I've mentioned on the first patch in the series. Thanks, Irina > Changelog: > > v1: * Initial version (based von v6 of Irina Tirdea's "Goodix > touchscreen enhancements" series). > Reviewed-by: Bastien Nocera > > v2: * Rebase against v8 of Irina Tirdea's "Goodix touchscreen > enhancements" series. > * Fix a typo in the commit message. > * Add an update for the goodix dt bindings documentation > (patch No. 3). > > > Karsten Merker (3): > Input: goodix - add dt axis swapping and axis inversion support > Input: goodix - use "inverted_[xy]" flags instead of "rotated_screen" > Input: goodix - update dt bindings documentation (axis > swapping/inversion) > > .../bindings/input/touchscreen/goodix.txt | 6 > drivers/input/touchscreen/goodix.c | 33 > ++ > 2 files changed, 34 insertions(+), 5 deletions(-) > > -- > 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC V2 2/3] Input: goodix - use "inverted_[xy]" flags instead of "rotated_screen"
> -Original Message-
> From: Karsten Merker [mailto:mer...@debian.org]
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai;
> Karsten Merker
> Subject: [PATCH RFC V2 2/3] Input: goodix - use "inverted_[xy]" flags instead
> of "rotated_screen"
>
> The goodix touchscreen driver uses a "rotated_screen" flag for
> systems on which the touchscreen is mounted rotated by 180
> degrees with respect to the display. With the addition of
> support for the dt properties "touchscreen-inverted-x" and
> "touchscreen-inverted-y", a separate "rotated_screen" flag
> is not necessary any more. This patch replaces it by setting
> the inverted_x and inverted_y flags instead.
>
> Signed-off-by: Karsten Merker
> ---
Reviewed-by: Irina Tirdea
> drivers/input/touchscreen/goodix.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index a05bdad..d910b27 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -40,7 +40,6 @@ struct goodix_ts_data {
> int abs_y_max;
> unsigned int max_touch_num;
> unsigned int int_trigger_type;
> - bool rotated_screen;
> int cfg_len;
> struct gpio_desc *gpiod_int;
> struct gpio_desc *gpiod_rst;
> @@ -270,11 +269,6 @@ static void goodix_ts_report_touch(struct goodix_ts_data
> *ts, u8 *coor_data)
> int input_y = get_unaligned_le16(&coor_data[3]);
> int input_w = get_unaligned_le16(&coor_data[5]);
>
> - if (ts->rotated_screen) {
> - input_x = ts->abs_x_max - input_x;
> - input_y = ts->abs_y_max - input_y;
> - }
> -
> /* Inversions have to happen before axis swapping */
> if (ts->inverted_x)
> input_x = ts->abs_x_max - input_x;
> @@ -701,10 +695,12 @@ static void goodix_read_config(struct goodix_ts_data
> *ts)
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> }
>
> - ts->rotated_screen = dmi_check_system(rotated_screen);
> - if (ts->rotated_screen)
> + if (dmi_check_system(rotated_screen)) {
> + ts->inverted_x = true;
> + ts->inverted_y = true;
> dev_dbg(&ts->client->dev,
>"Applying '180 degrees rotated screen' quirk\n");
> + }
> }
>
> /**
> --
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC V2 3/3] Input: goodix - update dt bindings documentation (axis swapping/inversion)
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Karsten Merker
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai;
> Karsten Merker
> Subject: [PATCH RFC V2 3/3] Input: goodix - update dt bindings documentation
> (axis swapping/inversion)
>
> The goodix touchscreen driver has gained support for the
> optional touchscreen-inverted-x, touchscreen-inverted-y
> and touchscreen-swapped-x-y properties as described in
> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt.
>
> Document these properties in the goodix bindings description.
>
> Signed-off-by: Karsten Merker
Reviewed-by: Irina Tirdea
> ---
> Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> index 4db3393..4ecd0e1 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> @@ -14,6 +14,7 @@ Required properties:
> - interrupts: Interrupt to which the chip is connected
> - irq-gpio : GPIO pin used for IRQ
> - reset-gpio: GPIO pin used for reset
> +
> Optional properties:
>
> - esd-recovery-timeout-ms : ESD poll time (in milli seconds) for the driver
> to
> @@ -21,6 +22,11 @@ Optional properties:
> device. ESD is disabled if this property is not
> set
> or is set to 0.
>
> + - touchscreen-inverted-x : X axis is inverted (boolean)
> + - touchscreen-inverted-y : Y axis is inverted (boolean)
> + - touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
> + (swapping is done after inverting the axis)
> +
> Example:
>
> i2c@ {
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] sched: consider missed ticks when updating global cpu load
On Mon, Oct 12, 2015 at 07:45:35PM +0200, Frederic Weisbecker wrote: > > I think it will take more than a single patch to rework all of > > update_process_times(). And we should also ask Thomas for his opinion, > > but I think we want: > > > > - make update_process_times() take a nr_ticks argument > > - fixup everything below it > > > > - fix tick_nohz_handler to not ignore the hrtimer_forward() > > return value and pass it into > > tick_sched_handle()/update_process_times(). > > > > (assuming this is the right oneshot tick part, tick-common > > seems to be about periodic timers which aren't used much ?!) > > this_nohz_handler() is the low res nohz handler. tick_sched_handle() > is the high res one (I should rename these). I think we should rather > find out the pending updates from update_process_times() itself and pass > it to scheduler_tick() which is the one interested in it. tick_nohz_handler() calls tick_sched_handler() ?! And tick_nohz_handler() actually computes the number of ticks -- which we then happily ignore. Why compute it again a few functions down? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers
On 2015/10/13 13:15, Alexei Starovoitov wrote:
On 10/12/15 9:34 PM, Wangnan (F) wrote:
On 2015/10/13 12:16, Alexei Starovoitov wrote:
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
to receive samples only within sys_write() syscall.
The example makes sense, but sys_write() is running on this cpu, so
just
disabling it on the current one is enough.
Our real use case is control of the system-wide sampling. For example,
we need sampling all CPUs when smartphone start refershing its
display.
We need all CPUs because in Android system there are plenty of threads
get involed into this behavior. We can't achieve this by controling
sampling on only one CPU. This is the reason we need 'set enable'
and 'set disable'.
ok, but that use case may have different enable/disable pattern.
In sys_write example ultra-fast enable/disable is must have, since
the whole syscall is fast and overhead should be minimal.
but for display refresh? we're talking milliseconds, no?
Can you just ioctl() it from user space?
If cost of enable/disable is high or the time range between toggling is
long, then doing it from the bpf program doesn't make sense. Instead
the program can do bpf_perf_event_output() to send a notification to
user space that condition is met and the user space can ioctl() events.
OK. I think I understand your design principle that, everything
inside BPF
should be as fast as possible.
Make userspace control events using ioctl make things harder. You
know that
'perf record' itself doesn't care too much about events it reveived. It
only
copies data to perf.data, but what we want is to use perf record simply
like
this:
# perf record -e evt=cycles -e control.o/pmu=evt/ -a sleep 100
And in control.o we create uprobe point to mark the start and finish of
a frame:
SEC("target=/a/b/c.o\nstartFrame=0x123456")
int startFrame(void *) {
bpf_pmu_enable(pmu);
return 1;
}
SEC("target=/a/b/c.o\nfinishFrame=0x234568")
int finishFrame(void *) {
bpf_pmu_disable(pmu);
return 1;
}
I think it is make sence also.
yes. that looks quite useful,
but did you consider re-entrant startFrame() ?
start << here sampling starts
start
finish << here all samples disabled?!
finish
and startFrame()/finishFrame() running on all cpus of that user app ?
One cpu entering into startFrame() while another cpu doing finishFrame
what behavior should be? sampling is still enabled on all cpus? or off?
Either case doesn't seem to work with simple enable/disable.
Few emails in this thread back, I mentioned inc/dec of a flag
to solve that.
Correct.
What about using similar
implementation
like PERF_EVENT_IOC_SET_OUTPUT, creating a new ioctl like
PERF_EVENT_IOC_SET_ENABLER,
then let perf to select an event as 'enabler', then BPF can still
control one atomic
variable to enable/disable a set of events.
you lost me on that last sentence. How this 'enabler' will work?
Like what we did in this patchset: add an atomic flag to perf_event,
make all perf_event connected to this enabler by PERF_EVENT_IOC_SET_ENABLER.
During running, check the enabler's atomic flag. So we use one atomic
variable to control a set of perf_event. Finally create a BPF helper
function to control that atomic variable.
Also I'm still missing what's wrong with perf doing ioctl() on
events on all cpus manually when bpf program tells it to do so.
Is it speed you concerned about or extra work in perf ?
I think both speed and extra work need be concerned.
Say we use perf to enable/disable sampling. Use the above example to
describe, when smartphone starting refresing display, we write something
into ringbuffer, then display refreshing start. We have to wait for
perf be scheduled in, parse event it get (perf record doesn't do this
currently), discover the trigger event then enable sampling perf events
on all cpus. We make trigger and action asynchronous. I'm not sure how
many ns or ms it need, and I believe asynchronization itself introduces
complexity, which I think need to be avoided except we can explain the
advantages asynchronization can bring.
But yes, perf based implementation can shut down the PMU completely, which
is better than current light-weight implementation.
In summary:
- In next version we will use counter based flag instead of current
0/1 switcher in considering of reentering problem.
- I think we both agree we need a light weight solution in which we can
enable/disable sampling in function level. This light-weight solution
can be applied to only one perf-event.
- Our disagreement is whether to introduce a heavy-weight solution based
on perf to enable/disable a group of perf event. For me, perf-based
solution can shut down PMU completly, which is good. However, it
introduces asynchronization and extra work on perf. I think we can
do it in a much simpler, fully BPF way. Enabler solution I mentioned
Re: [PATCH v2 2/3] mfd: rt5033: Add RT5033 Flash led sub device
On Mon, 12 Oct 2015, Ingi Kim wrote:
> This patch adds rt5033-led sub device to support it.
>
> Signed-off-by: Ingi Kim
> ---
> drivers/mfd/rt5033.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> index d60f916..b7f374b 100644
> --- a/drivers/mfd/rt5033.c
> +++ b/drivers/mfd/rt5033.c
> @@ -40,13 +40,17 @@ static const struct regmap_irq_chip rt5033_irq_chip = {
> };
>
> static const struct mfd_cell rt5033_devs[] = {
> - { .name = "rt5033-regulator", },
> {
> + .name = "rt5033-regulator",
> + }, {
There's no need for this change. Please remove it.
> .name = "rt5033-charger",
> .of_compatible = "richtek,rt5033-charger",
> }, {
> .name = "rt5033-battery",
> .of_compatible = "richtek,rt5033-battery",
> + }, {
> + .name = "rt5033-led",
> + .of_compatible = "richtek,rt5033-led",
For when you resubmit with the hunk above removed:
Acked-by: Lee Jones
> },
> };
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 2/9] Input: goodix - reset device at init
On Tue, Oct 13, 2015 at 06:38:23AM +, Tirdea, Irina wrote:
>
>
> > -Original Message-
> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > Sent: 12 October, 2015 19:48
> > To: Tirdea, Irina
> > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> >
> > On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > > After power on, it is recommended that the driver resets the device.
> > > The reset procedure timing is described in the datasheet and is used
> > > at device init (before writing device configuration) and
> > > for power management. It is a sequence of setting the interrupt
> > > and reset pins high/low at specific timing intervals. This procedure
> > > also includes setting the slave address to the one specified in the
> > > ACPI/device tree.
> > >
> > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > driver gt9xx.c for Android (publicly available in Android kernel
> > > trees for various devices).
> > >
> > > For reset the driver needs to control the interrupt and
> > > reset gpio pins (configured through ACPI/device tree). For devices
> > > that do not have the gpio pins properly declared, the functionality
> > > depending on these pins will not be available, but the device can still
> > > be used with basic functionality.
> > >
> > > For both device tree and ACPI, the interrupt gpio pin configuration is
> > > read from the "irq-gpio" property and the reset pin configuration is
> > > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > > can be specified using the _DSD section. This functionality will not be
> > > available for devices that use indexed gpio pins declared in the _CRS
> > > section (we need to provide backward compatibility with devices
> > > that do not support using the interrupt gpio pin as output).
> > >
> > > For ACPI, the pins can be specified using ACPI 5.1:
> > > Device (STAC)
> > > {
> > > Name (_HID, "GDIX1001")
> > > ...
> > >
> > > Method (_CRS, 0, Serialized)
> > > {
> > > Name (RBUF, ResourceTemplate ()
> > > {
> > > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > > AddressingMode7Bit, "\\I2C0",
> > > 0x00, ResourceConsumer, ,
> > > )
> > >
> > > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > > "\\I2C0", 0x00, ResourceConsumer, ,
> > > )
> > > { // Pin list
> > > 0
> > > }
> > >
> > > GpioIo (Exclusive, PullDown, 0x, 0x,
> > > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > > ResourceConsumer, ,
> > > )
> > > {
> > > 1
> > > }
> > > })
> > > Return (RBUF)
> > > }
> > >
> > > Name (_DSD, Package ()
> > > {
> > > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > Package ()
> > > {
> > > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > > ...
> > > }
> > > }
> > >
> > > Signed-off-by: Octavian Purdila
> > > Signed-off-by: Irina Tirdea
> > > Acked-by: Bastien Nocera
> > > Tested-by: Bastien Nocera
> > > Tested-by: Aleksei Mamlin
> > > ---
> > > .../bindings/input/touchscreen/goodix.txt | 5 +
> > > drivers/input/touchscreen/Kconfig | 1 +
> > > drivers/input/touchscreen/goodix.c | 101
> > > +
> > > 3 files changed, 107 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > index 8ba98ee..7137881 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > @@ -12,6 +12,8 @@ Required properties:
> > > - reg : I2C address of the chip. Should be 0x5d or
> > > 0x14
> > > - interrupt-parent : Interrupt controller to which the chip is
> > > connected
> > > - interrupts: Interrupt to which the chip is connected
> > > + - irq-gpio : GPIO pin used for IRQ
> > > + - reset-gpio: GPIO pin used for reset
> > >
> > > Example:
> > >
> > > @@ -23,6 +25,9 @@ Example:
> > > reg = <0x5d>;
> > > interrupt-parent = <&gpio>;
> > > interrupts = <0 0>;
> > > +
> > > + irq-gpio = <&gpio1 0 0>;
> > > + reset-gpio = <&gpio1 1 0>;
> > > };
> > >
> > >
[PATCH 1/4] perf: add PERF_SAMPLE_BRANCH_CALL
Add a new branch sample type to cover only call branches (function calls).
The current ANY_CALL included direct, indirect calls and far jumps.
We want to be able to differentiate indirect from direct calls. Therefore
we introduce PERF_SAMPLE_BRANCH_CALL. The implementation is up to each
architecture.
Signed-off-by: Stephane Eranian
---
include/uapi/linux/perf_event.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 2881145..e6c1b47 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -168,6 +168,7 @@ enum perf_branch_sample_type_shift {
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT = 11, /* call/ret stack */
PERF_SAMPLE_BRANCH_IND_JUMP_SHIFT = 12, /* indirect jumps */
+ PERF_SAMPLE_BRANCH_CALL_SHIFT = 13, /* direct call */
PERF_SAMPLE_BRANCH_MAX_SHIFT/* non-ABI */
};
@@ -188,6 +189,7 @@ enum perf_branch_sample_type {
PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
PERF_SAMPLE_BRANCH_IND_JUMP = 1U <<
PERF_SAMPLE_BRANCH_IND_JUMP_SHIFT,
+ PERF_SAMPLE_BRANCH_CALL = 1U << PERF_SAMPLE_BRANCH_CALL_SHIFT,
PERF_SAMPLE_BRANCH_MAX = 1U << PERF_SAMPLE_BRANCH_MAX_SHIFT,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties
Hi,
On 13-10-15 04:22, Chen-Yu Tsai wrote:
On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland wrote:
On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Work around this by adding a "num-supplies"
property to communicate the number of supplies, and a list of 0 ~ N
"vinN-supply" properties for the actual regulator supply.
This is getting more complicated by the minute...
Yeah...
I considered "backlight" and "panel" properties, but that seems to need
more effort to parse. Regulators seemed easier.
Signed-off-by: Chen-Yu Tsai
---
.../devicetree/bindings/video/simple-framebuffer.txt | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..0cc43e1be8b5 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- num-supplies : The number of regulators used by the framebuffer.
+- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
I don't see why you need num-supplies. Why not just try probing
vin${N}-supply until such a property isn't present in the DT?
+1 for this.
That's doable. Though I'd add a hard limit on it. Does 16 seem reasonable?
I would not add a hard limit to the binding, you can use a fixed array in
the code to make the code simpler. I would say 8 should be sufficient, since
the limit will only be in the code we can always bump it when we need to.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] perf: add ability to sample direct call branches
This short patch series improves the perf_events interface by providing a new branch_sample_type bit to sample only direct call branches. Up until now, you could specify PERF_SAMPLE_BRANCH_ANY_CALL (any calls) or PERF_SAMPLE_BRANCH_IND_CALL (indirect calls). But there was no way to sample only direct calls. This series adds PERF_SAMPLE_BRANCH_CALL. This covers direct function calls (incl. zero length calls) but not syscalls. It can be used for those who want to analyze direct calls only. The series includes the kernel generic code changes. The x86 support based on the LBR filter (or sofware filter) and the PPC check. The series also includes the changes to perf record to support the new filter: $ perf record -j call -e cycles .. Patch is relative to tip.git @ commit e6f195f Merge branch 'ras/core' Stephane Eranian (4): perf: add PERF_SAMPLE_BRANCH_CALL perf/x86: add support for PERF_SAMPLE_BRANCH_CALL perf/powerpc: add support for PERF_SAMPLE_BRANCH_CALL perf record: add ability to sample call branches arch/powerpc/perf/power8-pmu.c | 3 +++ arch/x86/kernel/cpu/perf_event_intel_lbr.c | 4 include/uapi/linux/perf_event.h| 2 ++ tools/perf/Documentation/perf-record.txt | 1 + tools/perf/util/parse-branch-options.c | 1 + 5 files changed, 11 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] perf record: add ability to sample call branches
This patch add a new branch type sampling filter to perf record.
It is named 'call' and maps to PERF_SAMPLE_BRANCH_CALL. It samples
direct call branches only, unlike 'any_call' which includes indirect
calls as well.
$ perf record -j call -e cycles .
The man page is updated accordingly.
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 1 +
tools/perf/util/parse-branch-options.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 2e9ce77..b027d28 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -236,6 +236,7 @@ It is possible to select the types of branches captured by
enabling filters. The
- any_call: any function call or system call
- any_ret: any function return or system call return
- ind_call: any indirect branch
+- call: direct calls, including far (to/from kernel) calls
- u: only when the branch target is at the user level
- k: only when the branch target is in the kernel
- hv: only when the target is at the hypervisor level
diff --git a/tools/perf/util/parse-branch-options.c
b/tools/perf/util/parse-branch-options.c
index a3b1e13..355eecf 100644
--- a/tools/perf/util/parse-branch-options.c
+++ b/tools/perf/util/parse-branch-options.c
@@ -27,6 +27,7 @@ static const struct branch_mode branch_modes[] = {
BRANCH_OPT("no_tx", PERF_SAMPLE_BRANCH_NO_TX),
BRANCH_OPT("cond", PERF_SAMPLE_BRANCH_COND),
BRANCH_OPT("ind_jmp", PERF_SAMPLE_BRANCH_IND_JUMP),
+ BRANCH_OPT("call", PERF_SAMPLE_BRANCH_CALL),
BRANCH_END
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] perf/powerpc: add support for PERF_SAMPLE_BRANCH_CALL
The patch catches PERF_SAMPLE_BRANCH_CALL because it is not clear whether
this is actually supported by the hardware.
Signed-off-by: Stephane Eranian
---
arch/powerpc/perf/power8-pmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 396351d..7d5e295 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -676,6 +676,9 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type)
if (branch_sample_type & PERF_SAMPLE_BRANCH_IND_CALL)
return -1;
+ if (branch_sample_type & PERF_SAMPLE_BRANCH_CALL)
+ return -1;
+
if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY_CALL) {
pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
return pmu_bhrb_filter;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] perf/x86: add support for PERF_SAMPLE_BRANCH_CALL
This patch enables the suport for the PERF_SAMPLE_BRANCH_CALL
for Intel x86 processors. When the processor support LBR filtering
this the selection is done in hardware. Otherwise, the filter is
applied by software. Note that we chose to include zero length calls
because they also represent calls.
Signed-off-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index ad0b8b0..bfd0b71 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -555,6 +555,8 @@ static int intel_pmu_setup_sw_lbr_filter(struct perf_event
*event)
if (br_type & PERF_SAMPLE_BRANCH_IND_JUMP)
mask |= X86_BR_IND_JMP;
+ if (br_type & PERF_SAMPLE_BRANCH_CALL)
+ mask |= X86_BR_CALL | X86_BR_ZERO_CALL;
/*
* stash actual user request into reg, it may
* be used by fixup code for some CPU
@@ -890,6 +892,7 @@ static const int
snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX_SHIFT] = {
[PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL,
[PERF_SAMPLE_BRANCH_COND_SHIFT] = LBR_JCC,
[PERF_SAMPLE_BRANCH_IND_JUMP_SHIFT] = LBR_IND_JMP,
+ [PERF_SAMPLE_BRANCH_CALL_SHIFT] = LBR_REL_CALL,
};
static const int hsw_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX_SHIFT] = {
@@ -905,6 +908,7 @@ static const int
hsw_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX_SHIFT] = {
[PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT] = LBR_REL_CALL | LBR_IND_CALL
| LBR_RETURN | LBR_CALL_STACK,
[PERF_SAMPLE_BRANCH_IND_JUMP_SHIFT] = LBR_IND_JMP,
+ [PERF_SAMPLE_BRANCH_CALL_SHIFT] = LBR_REL_CALL,
};
/* core */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: android-goldfish: Allow compiling the driver with COMPILE_TEST
On Sat, 10 Oct 2015 17:08:32 +0100, Luis de Bethencourt wrote: > The driver depends on GOLDFISH but there isn't a build dependency > so it's a good idea to allow the driver to always be built when the > COMPILE_TEST option is enabled. > > That way, the driver can be built with a config generated by make > allyesconfig and check if a patch would break the build. > > Signed-off-by: Luis de Bethencourt > --- > drivers/mmc/host/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index 12b274a..56f5b14 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -473,7 +473,7 @@ config MMC_DAVINCI > > config MMC_GOLDFISH > tristate "goldfish qemu Multimedia Card Interface support" > - depends on GOLDFISH > + depends on GOLDFISH || COMPILE_TEST > help > This selects the Goldfish Multimedia card Interface emulation > found on the Goldfish Android virtual device emulation. Looks good. Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 13
Hi all,
There will be no linux-next release tomorrow.
Changes since 20151012:
I used the h8300 tree from next-20150828 since the current tree has been
rebased onto linux-next again :-(
The dwmw2-iommu tree still had its build failure for which I applied a fix
patch.
The battery tree still had its build failure so I used the version from
next-20150925.
The tip tree gained a conflict against the arm64 tree.
Non-merge commits (relative to Linus' tree): 6443
5153 files changed, 269454 insertions(+), 109610 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.
Below is a summary of the state of the merge.
I am currently merging 228 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (25cb62b76430 Linux 4.3-rc5)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (868e87ccda24 ARM: make RiscPC depend on MMU)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs
for v4.3-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (f2dd80ecca5f powerpc/powernv: Panic on unhandled
Machine Check)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (9ef2e965e554 ipv6: drop frames with attached skb->sk in
forwarding)
Merging ipsec/master (4e077237cfb6 xfrm: Fix state threshold configuration from
userspace)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for
nf_dup_ipv{4,6})
Merging sound-current/for-linus (601d62959d08 Merge tag 'asoc-fix-v4.3-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag
'iwlwifi-for-kalle-2015-10-05' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (25cb62b76430 Linux 4.3-rc5)
Merging usb.current/usb-linus (25cb62b76430 Linux 4.3-rc5)
Merging usb-gadget-fixes/fixes (f5f6afa85aa8 usb: renesas_usbhs: Add support
for R-Car H3)
Merging usb-serial-fixes/usb-linus (049e6dde7e57 Linux 4.3-rc4)
Merging staging.current/staging-linus (25cb62b76430 Linux 4.3-rc5)
Merging char-misc.current/char-misc-linus (25cb62b76430 Linux 4.3-rc5)
Merging input-current/for-linus (879f2fea8a5a Input: ads7846 - correct the
value got from SPI)
Merging crypto-current/master (92b279070dd6 crypto: camellia_aesni_avx - Fix
CPU feature checks)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default
emit rule)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm:
Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 trac
Re: [PATCH RFC 0/2] simplefb: Add regulator handling support
Hi, On 12-10-15 19:04, Chen-Yu Tsai wrote: Hi everyone, This series adds regulator claiming and enabling support for simplefb. Sometimes the simplefb display output path consits of external conversion chips and/or LCD drivers and backlights. These devices normally have GPIOs to turn them on and/or bring them out of reset, and regulators supplying power to them. While the kernel does not touch unclaimed GPIOs, the regulator core happily disables unused regulators. Thus we need simplefb to claim and enable the regulators used throughout the display pipeline. Ack for doing something like this (adding regulator support) to simplefb, it makes sense to have this. Now the DT bindings don't support a list of regulators directly, so I'm working around it by having a "num-supplies" property to specify the number of supply properties to check, and name the actual supplies as "vinN-supply". Hmm, I can see the need for a "supplies" property with a list of regulators in other use-cases (e.g. the generic mmc-pwrseq driver) too. Now as discussed we can simply do vin0-supply - vinN-supply properties and be done with it, but maybe we need to actually add support for a generic "supplies" property ? And if not then maybe we need a few generic helper devm helper function which takes a node, figures out how much vinN-supply properties there are and returns a dynamically allocated array containing references to all the regulators, or a PTR_ERR in case of err, at which point the caller is expected to fail the probe so that any successfully acquired regulators are released. Mark, what are your thoughts on this ? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20151012, in drivers/bluetooth
Hi Jim, > Building with the attached random configuration file, > > warning: (BT_HCIBPA10X) selects BT_HCIUART which has unmet direct > dependencies (NET && BT && TTY) > > ERROR: "tty_unthrottle" [drivers/bluetooth/hci_uart.ko] undefined! > ERROR: "tty_termios_encode_baud_rate" [drivers/bluetooth/hci_uart.ko] > undefined! > ERROR: "tty_unregister_ldisc" [drivers/bluetooth/hci_uart.ko] undefined! > ERROR: "tty_ldisc_flush" [drivers/bluetooth/hci_uart.ko] undefined! > ERROR: "n_tty_ioctl_helper" [drivers/bluetooth/hci_uart.ko] undefined! > ERROR: "tty_driver_flush_buffer" [drivers/bluetooth/hci_uart.ko] undefined! > ERROR: "tty_register_ldisc" [drivers/bluetooth/hci_uart.ko] undefined! > ERROR: "tty_set_termios" [drivers/bluetooth/hci_uart.ko] undefined! thanks for the report. We already fixed it in bluetooth-next and it should be with that in linux-next as well. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active
On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote:
>
> On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
> [...]
>
> > diff --git a/drivers/cpufreq/arm_big_little.c
> > b/drivers/cpufreq/arm_big_little.c
> > index f1e42f8..59115a4 100644
> > --- a/drivers/cpufreq/arm_big_little.c
> > +++ b/drivers/cpufreq/arm_big_little.c
> > @@ -149,6 +149,18 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> > new_cluster, u32 rate)
> > __func__, cpu, old_cluster, new_cluster, new_rate);
> >
> > ret = clk_set_rate(clk[new_cluster], new_rate * 1000);
> > + if (!ret) {
> > + /*
> > +* FIXME: clk_set_rate has to handle the case where
> > clk_change_rate
> > +* can fail due to hardware or firmware issues. Until the clk
> > core
> > +* layer is fixed, we can check here. In most of the cases we
> > will
> > +* be reading only the cached value anyway. This needs to be
> > removed
> > +* once clk core is fixed.
> > +*/
> > + if (clk_get_rate(clk[new_cluster]) != new_rate * 1000)
> > + ret = -EIO;
> > + }
> > +
> > if (WARN_ON(ret)) {
> > pr_err("clk_set_rate failed: %d, new cluster: %d\n", ret,
> > new_cluster);
> > @@ -189,15 +201,6 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
> > new_cluster, u32 rate)
> > mutex_unlock(&cluster_lock[old_cluster]);
> > }
> >
> > - /*
> > -* FIXME: clk_set_rate has to handle the case where clk_change_rate
> > -* can fail due to hardware or firmware issues. Until the clk core
> > -* layer is fixed, we can check here. In most of the cases we will
> > -* be reading only the cached value anyway. This needs to be removed
> > -* once clk core is fixed.
> > -*/
> > - if (bL_cpufreq_get_rate(cpu) != new_rate)
> > - return -EIO;
> > return 0;
> > }
> >
> >
> >
> >
>
> The above change looks good to me but with minor nit. You can get rid of
> if(!ret) check if you move the hunk after if (WARN_ON(ret))
But then we wouldn't get the WARN_ON and pr_err triggered when we detect
the clock rate isn't set, which surely is half the reason for the check
in the first place?
(P.S. I'm on holiday this week without access to my main computer, dev
boards or decent internet connectivity).
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand -fix
On 10/13/2015 03:42 AM, yalin wang wrote:
There is a redundant check and a memory leak introduced by a patch in
mmotm. This patch removes an unlikely(order) check as we are sure order
is not zero at the time. It also checks if a page is already allocated
to avoid a memory leak.
This is a fix to the mmotm patch
mm-page_alloc-reserve-pageblocks-for-high-order-atomic-allocations-on-demand.patch
Signed-off-by: yalin wang
Acked-by: Mel Gorman
Acked-by: Vlastimil Babka
---
mm/page_alloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0d6f540..043b691 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2241,13 +2241,13 @@ struct page *buffered_rmqueue(struct zone
*preferred_zone,
spin_lock_irqsave(&zone->lock, flags);
page = NULL;
- if (unlikely(order) && (alloc_flags & ALLOC_HARDER)) {
+ if (alloc_flags & ALLOC_HARDER) {
page = __rmqueue_smallest(zone, order,
MIGRATE_HIGHATOMIC);
if (page)
trace_mm_page_alloc_zone_locked(page, order,
migratetype);
}
-
- page = __rmqueue(zone, order, migratetype, gfp_flags);
+ if (!page)
+ page = __rmqueue(zone, order, migratetype, gfp_flags);
spin_unlock(&zone->lock);
if (!page)
goto failed;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] mtd: nand: pass page number to ecc->write_xxx() methods
Hi Brian, On Mon, 12 Oct 2015 16:35:37 -0700 Brian Norris wrote: > On Fri, Oct 02, 2015 at 07:53:25AM +0200, Boris Brezillon wrote: > > The ->read_xxx() methods are all passed the page number the NAND controller > > is supposed to read, but ->write_xxx() do not have such a parameter. > > > > This is a problem if we want to properly implement data > > scrambling/randomization in order to mitigate MLC sensibility to repeated > > pattern: to prevent bitflips in adjacent pages in the same block we need > > to avoid repeating the same pattern at the same offset in those pages, > > hence the randomizer/scrambler engine need to be passed the page value > > in order to adapt its seed accordingly. > > > > Moreover, adding the page parameter to the ->write_xxx() methods add some > > consistency to the current API. > > > > Signed-off-by: Boris Brezillon > > CC: Josh Wu > > CC: Ezequiel Garcia > > CC: Maxime Ripard > > CC: Greg Kroah-Hartman > > CC: Huang Shijie > > CC: Stefan Agner > > CC: de...@driverdev.osuosl.org > > CC: linux-arm-ker...@lists.infradead.org > > CC: linux-kernel@vger.kernel.org > > --- > > Changes since v2: > > - fixed compilation error in the gpmi driver > > - compile tested all impacted drivers except the bf5xx_nand, > > fsl_elbc_nand and fsl_ifc_nand ones > > > > Changes since v1: > > - rebased on l2-mtd/master > > - fixed compilation error in the docg4 driver > > --- > > drivers/mtd/nand/atmel_nand.c | 6 -- > > drivers/mtd/nand/bf5xx_nand.c | 3 ++- > > drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++-- > > drivers/mtd/nand/cafe_nand.c | 3 ++- > > drivers/mtd/nand/denali.c | 5 +++-- > > drivers/mtd/nand/docg4.c | 6 +++--- > > drivers/mtd/nand/fsl_elbc_nand.c | 4 ++-- > > drivers/mtd/nand/fsl_ifc_nand.c | 2 +- > > drivers/mtd/nand/gpmi-nand/gpmi-nand.c| 8 +++ > > drivers/mtd/nand/hisi504_nand.c | 3 ++- > > drivers/mtd/nand/lpc32xx_mlc.c| 3 ++- > > drivers/mtd/nand/lpc32xx_slc.c| 5 +++-- > > drivers/mtd/nand/nand_base.c | 31 > > ++- > > drivers/mtd/nand/omap2.c | 3 ++- > > drivers/mtd/nand/pxa3xx_nand.c| 3 ++- > > drivers/mtd/nand/sh_flctl.c | 3 ++- > > drivers/mtd/nand/sunxi_nand.c | 5 +++-- > > drivers/mtd/nand/vf610_nfc.c | 2 +- > > drivers/staging/mt29f_spinand/mt29f_spinand.c | 3 ++- > > include/linux/mtd/nand.h | 6 +++--- > > 20 files changed, 66 insertions(+), 42 deletions(-) > > Hmm, am I missing something, or does this not apply to l2-mtd.git or > linux-next.git? Hm, actually I based it on l2-mtd but before you applied my cleanup series, which explains why it does not apply anymore. I'll send a v3 after rebasing on l2-mtd. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] thp: use is_zero_pfn only after pte_present check
On 10/13/2015 04:38 AM, Minchan Kim wrote:
Use is_zero_pfn on pteval only after pte_present check on pteval
(It might be better idea to introduce is_zero_pte where checks
pte_present first). Otherwise, it could work with swap or
migration entry and if pte_pfn's result is equal to zero_pfn
by chance, we lose user's data in __collapse_huge_page_copy.
So if you're luck, the application is segfaulted and finally you
could see below message when the application is exit.
BUG: Bad rss-counter state mm:88007f099300 idx:2 val:3
Cc:
More specific:
Cc: # 4.1+
Fixes: ca0984caa823 ("mm: incorporate zero pages into transparent huge
pages")
Acked-by: Kirill A. Shutemov
Acked-by: Vlastimil Babka
Reviewed-by: Andrea Arcangeli
Signed-off-by: Minchan Kim
---
Hello Greg,
This patch should go to -stable but when you will apply it
after merging of linus tree, it will be surely conflicted due
to userfaultfd part.
I want to know how to handle it.
Thanks.
mm/huge_memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 4b06b8db9df2..bbac913f96bc 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2206,7 +2206,8 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
for (_pte = pte; _pte < pte+HPAGE_PMD_NR;
_pte++, address += PAGE_SIZE) {
pte_t pteval = *_pte;
- if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
+ if (pte_none(pteval) || (pte_present(pteval) &&
+ is_zero_pfn(pte_pfn(pteval {
if (!userfaultfd_armed(vma) &&
++none_or_zero <= khugepaged_max_ptes_none)
continue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3-rc3 BAR allocation problems on multiple machines
> > Updated on V210 - the others were more recent. Now I get more BAR > > warning there too: > > > > http://kodu.ut.ee/~mroos/dm/dm.v210+patches > > > > interesting, mem and mem64 is overlapping. > > [ 38.824625] /pci@1f,70: TOMATILLO PCI Bus Module ver[4:0] > [ 38.824654] /pci@1f,70: PCI IO [io > 0x7f60100-0x7f601ff] offset 7f60100 > [ 38.824680] /pci@1f,70: PCI MEM [mem > 0x7f7-0x7f7] offset 7f7 > [ 38.824704] /pci@1f,70: PCI MEM64 [mem > 0x7f7-0x7f7] offset 7f7 > [ 38.826310] PCI: Scanning PBM /pci@1f,70 > [ 38.826479] schizo f0069c00: PCI host bridge to bus :00 > [ 38.826506] pci_bus :00: root bus resource [io > 0x7f60100-0x7f601ff] (bus address [0x-0xff]) > [ 38.826536] pci_bus :00: root bus resource [mem > 0x7f7-0x7f7] (bus address [0x-0x]) > [ 38.826565] pci_bus :00: root bus resource [mem > 0x7f7-0x7f7] (bus address [0x-0x]) > > We need to add more sanitary checking. > > Can you send boot log after booting with "debug ignore_loglevel > ofpci_debug=1" ? http://kodu.ut.ee/~mroos/dm/dm.v210+patch+debug Applied the fix_mem_mem64_overlapping.patch and retested. The BAR allocation problems are still there: http://kodu.ut.ee/~mroos/dm/dm.v210+patch+mem64patch+debug -- Meelis Roos (mr...@linux.ee) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 1/2] mfd: da9053: Addition of extra registers for GPIOs 8-13
On Thu, 08 Oct 2015, Steve Twiss wrote: > From: Steve Twiss > > Definitions for GPIO registers 8, 9, 10, 11, 12 and 13 are added into > the register header file. > > - DA9052_GPIO_8_9_REG25 > - DA9052_GPIO_10_11_REG 26 > - DA9052_GPIO_12_13_REG 27 > > A modification is also made to the MFD core code to define these registers > as readable and writable. The functions for da9052_reg_readable() and > da9052_reg_writeable() have had their case statements altered to include > these new registers. > > Signed-off-by: Steve Twiss > > --- > This patch applies against linux-next and v4.3-rc4 > > > drivers/mfd/da9052-core.c | 6 ++ > include/linux/mfd/da9052/reg.h | 3 +++ > 2 files changed, 9 insertions(+) Applied, thanks. > diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c > index 46e3840..c0bf68a 100644 > --- a/drivers/mfd/da9052-core.c > +++ b/drivers/mfd/da9052-core.c > @@ -51,6 +51,9 @@ static bool da9052_reg_readable(struct device *dev, > unsigned int reg) > case DA9052_GPIO_2_3_REG: > case DA9052_GPIO_4_5_REG: > case DA9052_GPIO_6_7_REG: > + case DA9052_GPIO_8_9_REG: > + case DA9052_GPIO_10_11_REG: > + case DA9052_GPIO_12_13_REG: > case DA9052_GPIO_14_15_REG: > case DA9052_ID_0_1_REG: > case DA9052_ID_2_3_REG: > @@ -178,6 +181,9 @@ static bool da9052_reg_writeable(struct device *dev, > unsigned int reg) > case DA9052_GPIO_2_3_REG: > case DA9052_GPIO_4_5_REG: > case DA9052_GPIO_6_7_REG: > + case DA9052_GPIO_8_9_REG: > + case DA9052_GPIO_10_11_REG: > + case DA9052_GPIO_12_13_REG: > case DA9052_GPIO_14_15_REG: > case DA9052_ID_0_1_REG: > case DA9052_ID_2_3_REG: > diff --git a/include/linux/mfd/da9052/reg.h b/include/linux/mfd/da9052/reg.h > index c4dd3a8..5010f97 100644 > --- a/include/linux/mfd/da9052/reg.h > +++ b/include/linux/mfd/da9052/reg.h > @@ -65,6 +65,9 @@ > #define DA9052_GPIO_2_3_REG 22 > #define DA9052_GPIO_4_5_REG 23 > #define DA9052_GPIO_6_7_REG 24 > +#define DA9052_GPIO_8_9_REG 25 > +#define DA9052_GPIO_10_11_REG26 > +#define DA9052_GPIO_12_13_REG27 > #define DA9052_GPIO_14_15_REG28 > > /* POWER SEQUENCER CONTROL REGISTERS */ -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: Compile MFD_STW481X with COMPILE_TEST
On Mon, 12 Oct 2015, Luis de Bethencourt wrote: > The driver depends on ARCH_NOMADIK but there isn't a build dependency > so it's a good idea to allow the driver to always be built when the > COMPILE_TEST option is enabled. > > That way, the driver can be built with a config generated by make > allyesconfig and check if a patch would break the build. > > Signed-off-by: Luis de Bethencourt > --- > drivers/mfd/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 99d6367..68d708f 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -1471,7 +1471,7 @@ config MFD_WM8994 > > config MFD_STW481X > tristate "Support for ST Microelectronics STw481x" > - depends on I2C && ARCH_NOMADIK > + depends on I2C && (ARCH_NOMADIK || COMPILE_TEST) > select REGMAP_I2C > select MFD_CORE > help -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] arm: add __initbss section attribute
> On Oct 13, 2015, at 04:04, Sam Ravnborg wrote: > >> --- a/include/asm-generic/vmlinux.lds.h >> +++ b/include/asm-generic/vmlinux.lds.h >> >> -#define BSS_SECTION(sbss_align, bss_align, stop_align) >> \ >> +#define BSS_SECTION(sbss_align, bss_align, initbss_align, stop_align) >> \ > > A few comments: > > 1) - please align the backslash at the end of the > line with the backslash above it. > 2) - you need to fix all the remaining users of BSS_SECTION. > 3) - do we really need the flexibility to specify an alignment (stop_align)? >If not - drop the extra argument. > > Sam i change lots of __initdata to __initbss to test it on ARM arch, initbss_change.diff Description: Binary data build result : yalin@ubuntu:~/linux-next$ ll ../kernel_out_arm/arch/arm/boot/*Image* -rwxrwxr-x 1 yalin yalin 14487552 Oct 13 15:08 ../kernel_out_arm/arch/arm/boot/Image* # apply the patch -rwxrwxr-x 1 yalin yalin 14512128 Oct 12 11:48 ../kernel_out_arm/arch/arm/boot/Image_old* -rwxrwxr-x 1 yalin yalin 6479568 Oct 13 15:08 ../kernel_out_arm/arch/arm/boot/zImage*# apply the patch -rwxrwxr-x 1 yalin yalin 6479664 Oct 12 17:31 ../kernel_out_arm/arch/arm/boot/zImage_old* Image size shrink about 24576 bytes zImage seems not change much . it will be more useful for platform which don’t use compress Image like ARM64 / x86 platform i think. Thanks
Re: [PATCH v4 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
On Mon, 12 Oct 2015, Andrew F. Davis wrote:
> On 10/05/2015 04:27 AM, Lee Jones wrote:
> >On Mon, 05 Oct 2015, Lee Jones wrote:
> >
> >>On Thu, 01 Oct 2015, Andrew F. Davis wrote:
> >>
> >>>This patch adds support for TPS65912 mfd device. It provides
> >>>communication through the I2C and SPI interfaces. It contains
> >>>the following components:
> >>>
> >>> - Regulators
> >>> - GPIO controller
> >>>
> >>>Signed-off-by: Andrew F. Davis
> >>>---
> >>> drivers/mfd/Kconfig | 25
> >>> drivers/mfd/Makefile | 3 +
> >>> drivers/mfd/tps65912-core.c | 108 ++
> >>> drivers/mfd/tps65912-i2c.c | 82 ++
> >>> drivers/mfd/tps65912-spi.c | 81 ++
> >>> include/linux/mfd/tps65912.h | 345
> >>> +++
> >>> 6 files changed, 644 insertions(+)
> >>> create mode 100644 drivers/mfd/tps65912-core.c
> >>> create mode 100644 drivers/mfd/tps65912-i2c.c
> >>> create mode 100644 drivers/mfd/tps65912-spi.c
> >>> create mode 100644 include/linux/mfd/tps65912.h
> >>
> >>Applied, thanks.
> >
> >Whoops, I forgot about the removal patch.
> >
> >For this patch:
> > Acked-by: Lee Jones
> >
> >Can you break up the removal patch into subsystems as well?
> >
>
> I can if you would like, but as I responded in the other patch I
> think that will cause problems as the Kconfig symbols in the new
> will allow the old to be compiled and this will break build. All
> the removals may have to be brought in in a single patch, again
> up to you.
If the other Maintainers are happy, I'll just take the set through
MFD and provide the necessaries. Just collect the Acks you need and
I'll do the rest.
> >>>diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >>>index 9a8df8e..02b321f 100644
> >>>--- a/drivers/mfd/Kconfig
> >>>+++ b/drivers/mfd/Kconfig
> >>>@@ -1167,6 +1167,31 @@ config MFD_TPS65910
> >>> if you say yes here you get support for the TPS65910 series of
> >>> Power Management chips.
> >>>
> >>>+config MFD_TPS65912
> >>>+ tristate
> >>>+ select REGMAP
> >>>+ select REGMAP_IRQ
> >>>+
> >>>+config MFD_TPS65912_I2C
> >>>+ tristate "TI TPS65912 Power Management chip with I2C"
> >>>+ select MFD_TPS65912
> >>>+ select REGMAP_I2C
> >>>+ depends on I2C
> >>>+ depends on OF || COMPILE_TEST
> >>>+ help
> >>>+If you say yes here you get support for the TPS65912 series of
> >>>+PM chips with I2C interface.
> >>>+
> >>>+config MFD_TPS65912_SPI
> >>>+ tristate "TI TPS65912 Power Management chip with SPI"
> >>>+ select MFD_TPS65912
> >>>+ select REGMAP_SPI
> >>>+ depends on SPI_MASTER
> >>>+ depends on OF || COMPILE_TEST
> >>>+ help
> >>>+If you say yes here you get support for the TPS65912 series of
> >>>+PM chips with SPI interface.
> >>>+
> >>> config MFD_TPS80031
> >>> bool "TI TPS80031/TPS80032 Power Management chips"
> >>> depends on I2C=y
> >>>diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> >>>index 004aa76..49c3530 100644
> >>>--- a/drivers/mfd/Makefile
> >>>+++ b/drivers/mfd/Makefile
> >>>@@ -69,6 +69,9 @@ obj-$(CONFIG_TPS6507X) += tps6507x.o
> >>> obj-$(CONFIG_MFD_TPS65217) += tps65217.o
> >>> obj-$(CONFIG_MFD_TPS65218) += tps65218.o
> >>> obj-$(CONFIG_MFD_TPS65910) += tps65910.o
> >>>+obj-$(CONFIG_MFD_TPS65912)+= tps65912-core.o
> >>>+obj-$(CONFIG_MFD_TPS65912_I2C)+= tps65912-i2c.o
> >>>+obj-$(CONFIG_MFD_TPS65912_SPI) += tps65912-spi.o
> >>> obj-$(CONFIG_MFD_TPS80031) += tps80031.o
> >>> obj-$(CONFIG_MENELAUS) += menelaus.o
> >>>
> >>>diff --git a/drivers/mfd/tps65912-core.c b/drivers/mfd/tps65912-core.c
> >>>new file mode 100644
> >>>index 000..e787950
> >>>--- /dev/null
> >>>+++ b/drivers/mfd/tps65912-core.c
> >>>@@ -0,0 +1,108 @@
> >>>+/*
> >>>+ * Core functions for TI TPS65912x PMIC
> >>>+ *
> >>>+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
> >>>+ *
> >>>+ * Author: Andrew F. Davis
> >>>+ *
> >>>+ * This program is free software; you can redistribute it and/or
> >>>+ * modify it under the terms of the GNU General Public License version 2
> >>>as
> >>>+ * published by the Free Software Foundation.
> >>>+ *
> >>>+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> >>>+ * kind, whether expressed or implied; without even the implied warranty
> >>>+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>>+ * GNU General Public License version 2 for more details.
> >>>+ *
> >>>+ * Based on the TPS65218 driver and the previous TPS65912 driver by
> >>>+ * Margarita Olaya Cabrera
> >>>+ */
> >>>+
> >>>+#include
> >>>+#include
> >>>+#include
> >>>+
> >>>+#include
> >>>+
> >>>+static const struct regmap_irq tps65912_irqs[] = {
> >>>+ /* INT_STS IRQs */
> >>>+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_F, 0, TPS65912_INT_STS_PWRHOLD_F),
> >>>+ REGMAP_IRQ_REG(TPS65912_IRQ_VMON, 0, TPS65912_INT_STS_VMON),
> >>>+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRON, 0, TPS65912
Re: [PATCH 03/16] irqdomain: Allow irq domain lookup by fwnode
On Mon, 12 Oct 2015 13:31:09 -0500
Suravee Suthikulpanit wrote:
Hi Suravee,
> [RESEND] Not sure if the email went out the first time.
>
> Hi Marc,
>
> On 10/6/15 12:36, Marc Zyngier wrote:
> > So far, our irq domains are still looked up by device node.
> > Let's change this and allow a domain to be looked up using
> > a fwnode_handle pointer.
> >
> > The existing interfaces are preserved with a couple of helpers.
> >
> > Signed-off-by: Marc Zyngier
> > ---
> > include/linux/irqdomain.h | 11 +--
> > kernel/irq/irqdomain.c| 14 ++
> > 2 files changed, 15 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> > index 2f508f4..607c185 100644
> > --- a/include/linux/irqdomain.h
> > +++ b/include/linux/irqdomain.h
> > @@ -183,10 +183,17 @@ struct irq_domain *irq_domain_add_legacy(struct
> > device_node *of_node,
> > irq_hw_number_t first_hwirq,
> > const struct irq_domain_ops *ops,
> > void *host_data);
> > -extern struct irq_domain *irq_find_matching_host(struct device_node *node,
> > -enum irq_domain_bus_token
> > bus_token);
> > +extern struct irq_domain *irq_find_matching_fwnode(struct fwnode_handle
> > *fwnode,
> > + enum irq_domain_bus_token
> > bus_token);
> > extern void irq_set_default_host(struct irq_domain *host);
> >
> > +static inline struct irq_domain *irq_find_matching_host(struct device_node
> > *node,
> > + enum
> > irq_domain_bus_token bus_token)
> > +{
> > + return irq_find_matching_fwnode(node ? &node->fwnode : NULL,
> > + bus_token);
> > +}
> > +
> > static inline struct irq_domain *irq_find_host(struct device_node *node)
> > {
> > return irq_find_matching_host(node, DOMAIN_BUS_ANY);
> > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> > index 1aee5c1..10b6105 100644
> > --- a/kernel/irq/irqdomain.c
> > +++ b/kernel/irq/irqdomain.c
> > @@ -191,12 +191,12 @@ struct irq_domain *irq_domain_add_legacy(struct
> > device_node *of_node,
> > EXPORT_SYMBOL_GPL(irq_domain_add_legacy);
> >
> > /**
> > - * irq_find_matching_host() - Locates a domain for a given device node
> > - * @node: device-tree node of the interrupt controller
> > + * irq_find_matching_fwnode() - Locates a domain for a given fwnode
> > + * @fwnode: FW descriptor of the interrupt controller
> >* @bus_token: domain-specific data
> >*/
> > -struct irq_domain *irq_find_matching_host(struct device_node *node,
> > - enum irq_domain_bus_token bus_token)
> > +struct irq_domain *irq_find_matching_fwnode(struct fwnode_handle *fwnode,
> > + enum irq_domain_bus_token bus_token)
> > {
> > struct irq_domain *h, *found = NULL;
> > int rc;
> > @@ -212,12 +212,10 @@ struct irq_domain *irq_find_matching_host(struct
> > device_node *node,
> > */
> > mutex_lock(&irq_domain_mutex);
> > list_for_each_entry(h, &irq_domain_list, link) {
> > - struct device_node *of_node;
> > - of_node = irq_domain_get_of_node(h);
> > if (h->ops->match)
> > - rc = h->ops->match(h, node, bus_token);
> > + rc = h->ops->match(h, to_of_node(fwnode), bus_token);
> > else
> > - rc = ((of_node != NULL) && (of_node == node) &&
> > + rc = ((fwnode != NULL) && (h->fwnode == fwnode) &&
> > ((bus_token == DOMAIN_BUS_ANY) ||
> >(h->bus_token == bus_token)));
> >
> >
>
> In the kernel/irq/irq_domain.c, shouldn't you also change the export
> symbol from:
>
> EXPORT_SYMBOL_GPL(irq_find_matching_host);
>
> to:
>
> EXPORT_SYMBOL_GPL(irq_find_matching_fwnode);
>
> at the end of this function as well?
Well spotted! I'll update the v2 branch.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
Hello Lokesh,
Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
+Nishanth,
On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.
E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.
Why not use "root=PARTUUID=${uuid}" option instead of relying on mmcblk no?
U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
does this in u-boot.
Good tip ... I do not know, if it is possible to update U-Boot
on this boards...
Current U-Boot says:
U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
I2C: ready
DRAM: 512 MiB
[...]
U-Boot# mmc rescan
U-Boot# mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
PartStart SectorNum Sectors UUIDType
1 63 144522 000ce343-01 0e Boot
2 144585 659861 000ce343-02 83
U-Boot# part uuid mmc 0:2 uuid
Unknown command 'part' - try 'help'
U-Boot#
So, if this patch has no chance for mainline, please let me
know it, thanks!
bye,
Heiko
[1]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=437bc42e7ff930dc4d4bd47199d2e823cf84bf4c;hp=85d17be374678ec37fd1e55db994a942e400dc80
Thanks and regards,
Lokesh
Signed-off-by: Heiko Schocher
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"
I adapt this to the omap_hsmmc driver.
Is there another solution for this problem?
Or why was this patch not accepted to mainline?
drivers/mmc/card/block.c | 6 --
drivers/mmc/host/omap_hsmmc.c | 6 ++
include/linux/mmc/host.h | 3 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;
- devidx = find_first_zero_bit(dev_use, max_devices);
+ devidx = find_next_zero_bit(dev_use, max_devices,
+ card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
* index anymore so we keep track of a name index.
*/
if (!subname) {
- md->name_idx = find_first_zero_bit(name_use, max_devices);
+ md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;
+ if (pdev->dev.of_node) {
+ ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+ if (ret >= 0)
+ host->mmc->devidx = ret;
+ }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */
+ /* preferred mmc block device index (mmcblkX) */
+ unsigned intdevidx;
+
unsigned long private[0] cacheline_aligned;
};
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 3/6] pci:host: Add Altera PCIe host controller driver
On Mon, Oct 12, 2015 at 8:03 PM, Arnd Bergmann wrote:
>
> On Friday 09 October 2015 18:15:40 Bjorn Helgaas wrote:
> >
> > I don't know if this should be a kernel taint, a simple warning in
> > dmesg, or what. I guess the tainting mechanism is probably too
> > general-purpose for this, and add_taint() doesn't give any dmesg
> > indication. We wouldn't see the taint unless the problem actually
> > caused an oops or panic. In this case, I think I want a clue in dmesg
> > so we have a chance of seeing it even if there is no oops. So
> > probably something like a dev_warn("non-compliant config accesses")
> > would work.
> >
> > You really should double-check with the hardware guys, because it's
> > pretty obvious that the PCI spec requires 1- and 2-byte config
> > accesses to work correctly. For example, if you read/modify/write to
> > update PCI_COMMAND, you will inadvertently clear the RW1C bits in
> > PCI_STATUS.
>
> Would it help to require a DT property here that flags the device
> as having a broken config space?
>
> Then we could implement both in the driver, and only use the
> RMW based implementation if the firmware describes the device
> as "altera,broken-pci-config-space".
>
I have checked the PCI/TLP specification, the address needs to be
4-byte aligned. But, we can use "byte enable" field to update specific
bytes.
For example, if byte enable is 0x3 (0011b), that mean it only update
lower 2 bytes. By doing this, we can resolve the RW1C issue here.
I will update the driver with this in next revision.
Thanks for reviewing.
Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Deadline scheduler and audio
Hi LKML, I had a talk a Linuxcon Europe last week about the deadline scheduler from an audio developer's perspective. The talk was AFAIK not recorded but the slides are here [1]. I've also had a few email conversations with Juri Lelli (thanks!) who suggested to follow up on LKML after the talk. In short, the main thesis of the talk is that the deadline scheduler's requirement of entering a runtime (in time units) can be a difficult question to answer, for a variety of reasons: * CPU capacity changes (e g the kernel changes frequency dynamically, or in the case of big.LITTLE even moves to a core with different characteristics) * The software itself need to adapt to changes in the audio pipeline. This might require a temporary "boost" that's greater than the normal runtime, and might also occur when the current period's runtime has already been consumed. For the latter problem someone in the audience suggested to temporarily change the thread to SCHED_FIFO, and then back to SCHED_DEADLINE when normal operations are resumed. An open question is whether we can do better than that? * In addition, I raised the question of how much time in PREEMPT_OFF would count as a bug. This might be an impossible question to answer for all use cases, but even a ballpark figure for typical laptop hardware would be better than nothing. 100 us? 1 ms? 10 ms? 100 ms? I think most of us would think spending, say, 10 seconds in PREEMPT_OFF would be quite bad - but is there anything that says that a driver should not do that? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic [1] http://events.linuxfoundation.org/sites/events/files/slides/deadline%20audio%20-%20Linuxcon%20EU%202015.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updated scalable urandom patchkit
> This might be stupid, but could something asynchronous work? Perhaps > have the entropy generators dump their entropy into a central pool via > a cycbuf, and have a background kthread manage the per-cpu or > per-process entropy pools? No for two reasons: (Minor): One of the functions of the mixback is to ensure that the next reader hashes a *different* pool state. If the mixback is delayed, the next reader might hash the *same* pool state and return the same numbers. (There are easy workarounds for this.) (Major): What do you do when the circular buffer is full? If it's not safe to skip the mixback, then we have to block and get into the same lock-contention problem. But... this suggestion of having a separate thread do the mixback gives me an idea. In fact, I think it's a good idea. Ted (or anyone else listening), what do you think of the following? I think it would solve Andi's problem and be a smaller code change than the abuse mitigation mode. (Which is still a good idea, but is off the critical path.) - Associated with a pool is an atomic "mixback needed" flag. - Also an optional mixback buffer. (Optional because the mixback could just recompute it.) - Dropping the lock requires the following operations: - Test the mixback needed flag. If set, - Copy out and wipe the buffer, - smp_wmb() - Clear the flag - smp_wmb() - Do the mixback, and - Re-check again before dropping the lock. (This check before dropping the lock is technically an optional optimization.) - Drop the lock. - smp_mb()(Since it's write-to-read, we can't use _rmb or _wmb.) - Test the mixback pending flag again. - If it's set, trylock(). If that succeeds, go do the mixback as above. - If it fails, return. Each reader uses already-discussed nonce techniques to safely do concurrent reads from the same pool. Then, at the end: - (Optional) trylock() and, if it succeeds, do mixback directly. - Copy our mixback data to the buffer (race conditions be damned) - smp_wmb() - set the mixback needed flag - smp_mb() (Since it's write-to-read; or use smp_store_mb()) - trylock() - If that fails. return - If that succeeds (and the flag is still set) do the mixback This is based on the fact that if there are multiple concurrent reads, we only need one mixback (thus, only one buffer/flag), but the "last one out the door" has to do it. Also, we don't care if we mis-count and end up doing it twice. Each reader sets the flag and *then* does a trylock. If the trylock fails, it's guaranteed that the lock-holder will see the flag and take care of the mixback for us. The writers drop the lock and *then* test the flag. The result is that readers *never* do a blocking acquire of the pool lock. Which should solve all the contention problems. Andi's stupid application will still be stupid, but won't fall off a locking cliff. (We could also use w[5] as the "mixback needed" flag and just force it to 1 on the off chance it's zero with negligible loss of entropy and zero security loss.) The one thing I worry about is livelock keeping one thread in the mixback code indefinitely, which can be mitigated by dropping the lock and waiting before re-testing and re-acquiring if we loop too often. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Tue, 13 Oct 2015, Richard Cochran wrote: > On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > > The transforms such an application would > > perform are: > > > > System Clock <-> Audio clock > > System Clock <-> Network Device Clock [<-> PTP Master Clock] > > This is extra work with no benefit. In fact, this hurts you > because of the need to take avoid update_wall_time AND because of the > NTP frequency adjustments. Cascaded servos are prone to gain peaking, > and this can easily avoided in this case. In such a system the frequency updates are coming from PTP, so you have a strong correlation. > > Modern Intel platforms can perform a more accurate cross- > > timestamp in hardware (ART,audio device clock). The audio driver > > requires ART->system time transforms -- the same as required for > > the network driver. > > No, it doesn't need the system time. It only needs the PTP time. > > > The modification to the original patch accomodates these > > slow devices by adding the option of providing an ART value outside > > of the retry loop and adding a history which can consulted in the > > case of an out of date counter value. The history is kept by > > making the shadow_timekeeper an array. Each write to the > > timekeeper rotates through the array, preserving a > > history of updates. > > This is all wrong. All you need to provide the DSP with (ART, PTP) > pairs. This can be done in a multiple of the DSP period, like every > 1, 10, or 100 milliseconds. You are restricting the problem space to this particular use case. There are other use cases where PTP is not available or not the relevant reference, but you still want to correlate time domains to ART. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcnet32: fix a logic error with pci_set_dma_mask
On Mon, Oct 12, 2015 at 05:38:14AM -0700, David Miller wrote: > From: Geliang Tang > Date: Fri, 9 Oct 2015 03:45:39 -0700 > > > pcnet32 can't work on my machine recently. It says "architecture > > does not support 32bit PCI busmaster DMA". There is a logic error > > in it: pci_set_dma_mask() return 0 means return successfully. > > > > Signed-off-by: Geliang Tang > > This driver doesn't call pci_set_dma_mask() in any of my tree(s). This patch is against linux-next tree. It was introduced by commit 9c034d4 'pcnet32: use pci_set_dma_mask insted of pci_dma_supported'. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pxa: remove incorrect __init annotation on pxa27x_set_pwrmode
On Monday 12 October 2015 23:07:28 Robert Jarzmik wrote: > Arnd Bergmann writes: > > The z2 in particular never did, except in the powerdown handler. So if it > > is unable to wake up reliably from DEEPSLEEP, that may be a reason to use > > that flag only in the poweroff function but not during normal operation. > My first thought was : > This flag's only use is for Suspend to RAM. There might be special > wirings where the voltage to the RAM is provided out of SYS_EN pin > control, and therefore PWRMODE_DEEPSLEEP is possible. But the most > common pattern would be a PMIC, providing voltage to the DRAM through > Vcc_Mem. > > But having a closer look, you're right, I have misunderstood the way z2 > poweroff > was designed. The setting of poweroff to PWRMODE_DEEPSLEEP + > pxa27x_cpu_pm_enter() is a whole, it is the closest to a platform halt where > no > external chip handles the poweroff phase, and memory is shutdown in deep > sleep. > > Therefore I'll drop Thierry's patch (which would actually break suspend to > RAM I > think) and take yours. Ok, sounds good. thanks! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: remove unless line in obj_free
On (10/13/15 14:31), Hui Zhu wrote: > Signed-off-by: Hui Zhu s/unless/useless/ other than that Reviewed-by: Sergey Senozhatsky -ss > --- > mm/zsmalloc.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index f135b1b..c7338f0 100644 > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -1428,8 +1428,6 @@ static void obj_free(struct zs_pool *pool, struct > size_class *class, > struct page *first_page, *f_page; > unsigned long f_objidx, f_offset; > void *vaddr; > - int class_idx; > - enum fullness_group fullness; > > BUG_ON(!obj); > > @@ -1437,7 +1435,6 @@ static void obj_free(struct zs_pool *pool, struct > size_class *class, > obj_to_location(obj, &f_page, &f_objidx); > first_page = get_first_page(f_page); > > - get_zspage_mapping(first_page, &class_idx, &fullness); > f_offset = obj_idx_to_offset(f_page, f_objidx, class->size); > > vaddr = kmap_atomic(f_page); > -- > 1.9.1 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential use-after-free in shrink_page_list
Hello, On Wed 07-10-15 18:43:30, Andrey Konovalov wrote: > While fuzzing the kernel (4.3-rc4) with KASAN and Trinity I got the > following report: > > == > BUG: KASan: use after free in shrink_page_list+0x93a/0xf10 at addr > 88003487da80 Hum, looking into a trace it seems KASAN really found a page with inode belonging to a destroyed BDI. I think this may be the same problem that was also reported in http://lists.openwall.net/linux-ext4/2015/08/13/3. Christoph, did you have time to look into it? Honza > Read of size 8 by task kswapd0/622 > = > BUG kmalloc-16 (Not tainted): kasan: bad access detected > - > > Disabling lock debugging due to kernel taint > INFO: Allocated in bdi_init+0xb9/0x480 age=235622 cpu=0 pid=6 > [< none >] __slab_alloc+0x44a/0x480 mm/slub.c:2402 > [< inline >] slab_alloc mm/slub.c:2470 > [< none >] kmem_cache_alloc_trace+0x12a/0x160 mm/slub.c:2529 > [< inline >] kmalloc include/linux/slab.h:440 > [< inline >] kzalloc include/linux/slab.h:593 > [< inline >] cgwb_bdi_init mm/backing-dev.c:749 > [< none >] bdi_init+0xb9/0x480 mm/backing-dev.c:775 > [< none >] blk_alloc_queue_node+0xfc/0x380 block/blk-core.c:656 > [< none >] blk_init_queue_node+0x1f/0x60 block/blk-core.c:754 > [< none >] blk_init_queue+0xe/0x10 block/blk-core.c:745 > [< none >] __scsi_alloc_queue+0x14/0x30 drivers/scsi/scsi_lib.c:2139 > [< none >] scsi_alloc_queue+0x1c/0x80 drivers/scsi/scsi_lib.c:2151 > [< none >] scsi_alloc_sdev+0x3cd/0x5f0 scsi_scan.c:0 > [< none >] scsi_probe_and_add_lun+0xc3a/0x10a0 scsi_scan.c:0 > [< none >] __scsi_add_device+0x112/0x120 ??:0 > [< none >] ata_scsi_scan_host+0xed/0x260 ??:0 > [< none >] async_port_probe+0x61/0x80 drivers/ata/libata-core.c:6097 > [< none >] async_run_entry_fn+0x74/0x190 async.c:0 > [< none >] process_one_work+0x276/0x630 kernel/workqueue.c:2030 > [< none >] worker_thread+0x98/0x720 kernel/workqueue.c:2162 > INFO: Freed in bdi_destroy+0x1d9/0x200 age=1073 cpu=0 pid=5919 > [< none >] __slab_free+0x150/0x270 mm/slub.c:2587 > [< inline >] slab_free mm/slub.c:2736 > [< none >] kfree+0x13a/0x150 mm/slub.c:3522 > [< inline >] wb_exit include/linux/backing-dev.h:483 > [< none >] bdi_destroy+0x1d9/0x200 mm/backing-dev.c:839 > [< none >] blk_cleanup_queue+0x158/0x190 block/blk-core.c:579 > [< none >] __scsi_remove_device+0x63/0x110 ??:0 > [< none >] scsi_remove_device+0x27/0x40 ??:0 > [< none >] sdev_store_delete+0x22/0x30 scsi_sysfs.c:0 > [< none >] dev_attr_store+0x39/0x50 drivers/base/core.c:137 > [< none >] sysfs_kf_write+0x8a/0xa0 file.c:0 > [< none >] kernfs_fop_write+0x167/0x200 file.c:0 > [< none >] __vfs_write+0x57/0x170 ??:0 > [< none >] vfs_write+0xeb/0x250 ??:0 > [< none >] SyS_write+0x53/0xb0 ??:0 > [< none >] entry_SYSCALL_64_fastpath+0x12/0x71 > arch/x86/entry/entry_64.S:185 > > INFO: Slab 0xead21f40 objects=12 used=4 fp=0x88003487d3f0 > flags=0x180 > INFO: Object 0x88003487da80 @offset=2688 fp=0x (null) > > Bytes b4 88003487da70: a3 08 ff ff 00 00 00 00 aa 18 57 81 ff ff > ff ff ..W. > Object 88003487da80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > Redzone 88003487da90: bb bb bb bb bb bb bb bb > > Padding 88003487dbc8: 84 d5 76 81 ff ff ff ff > ..v. > CPU: 0 PID: 622 Comm: kswapd0 Tainted: GB 4.3.0-rc4-kasan #16 > Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 > 88003487da80 880034c0f878 814a3e7c 880036003b00 > 880034c0f8a8 812090b8 880036003b00 ead21f40 > 88003487da80 eaceaf98 880034c0f8d0 8120def1 > Call Trace: > [] dump_stack+0x44/0x58 lib/dump_stack.c:15 > [] print_trailer+0xf8/0x150 mm/slub.c:650 > [] object_err+0x31/0x40 mm/slub.c:657 > [] kasan_report_error+0x1e5/0x3f0 ??:0 > [] kasan_report+0x34/0x40 ??:0 > [< inline >] ? inode_write_congested include/linux/backing-dev.h:193 > [] ? shrink_page_list+0x93a/0xf10 mm/vmscan.c:957 > [] __asan_load8+0x64/0xa0 ??:0 > [] ? page_mapping+0x2f/0x70 ??:0 > [< inline >] inode_write_congested include/linux/backing-dev.h:193 > [] shrink_page_list+0x93a/0xf10 mm/vmscan.c:957 > [] shrink_inactive_list+0x2f4/0x5f0 mm/vmscan.c:1610 > [< inline >] shrink_list mm/vmscan.c:1945 > [] shrink_lruvec+0x87a/0xa50 mm/vmscan.c:2229 > [] shrink_zone+0xc0/0x2c0 mm/vmscan
Re: [PATCH] EDAC: use debugfs_remove_recursive instead of debugfs_remove
On Tue, Oct 13, 2015 at 10:22:51AM +0800, Tan Xiaojun wrote: > debugfs_remove is used to remove a file or an empty directory from > the debugfs filesystem, but mci->debugfs is not empty. How exactly do you trigger this? And by "this" I'm not even sure what the problem is as your commit message doesn't say. So please explain also what the problem is. Also, use this branch instead: http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next We did change EDAC debugfs handling recently so your patch doesn't apply anymore. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / sleep: Drop pm_request_idle() from pm_generic_complete()
On 12 October 2015 at 22:15, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 02:44:29 AM Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>>
>> The pm_request_idle() in pm_generic_complete() is pointless as it is
>> called with the runtime PM usage counter different from zero (bumped
>> up by the core during the prepare phase of system suspend) and the
>> core calls pm_runtime_put() for all devices after executing their
>> complete callbacks, so drop it.
>>
>> This allows the PCI PM layer to use pm_generic_complete() too.
>>
>> Signed-off-by: Rafael J. Wysocki
>> ---
>>
>> On top of https://patchwork.kernel.org/patch/7291251/ .
>
> Due to the lack of comments for the last several days (which I'm taking as
> the lack of objections), I'm tentatively queing this up for v4.4.
>
> Please let me know if there are any problems with that.
Looks good to me, so unless it's too late you may add my reviewed-by tag.
Reviewed-by: Ulf Hansson
Kind regards
Uffe
>
> Thanks,
> Rafael
>
>
>> ---
>> drivers/base/power/generic_ops.c |6 --
>> drivers/pci/pci-driver.c |9 ++---
>> 2 files changed, 2 insertions(+), 13 deletions(-)
>>
>> Index: linux-pm/drivers/base/power/generic_ops.c
>> ===
>> --- linux-pm.orig/drivers/base/power/generic_ops.c
>> +++ linux-pm/drivers/base/power/generic_ops.c
>> @@ -296,11 +296,5 @@ void pm_generic_complete(struct device *
>>
>> if (drv && drv->pm && drv->pm->complete)
>> drv->pm->complete(dev);
>> -
>> - /*
>> - * Let runtime PM try to suspend devices that haven't been in use
>> before
>> - * going into the system-wide sleep state we're resuming from.
>> - */
>> - pm_request_idle(dev);
>> }
>> #endif /* CONFIG_PM_SLEEP */
>> Index: linux-pm/drivers/pci/pci-driver.c
>> ===
>> --- linux-pm.orig/drivers/pci/pci-driver.c
>> +++ linux-pm/drivers/pci/pci-driver.c
>> @@ -686,13 +686,8 @@ static int pci_pm_prepare(struct device
>>
>> static void pci_pm_complete(struct device *dev)
>> {
>> - struct device_driver *drv = dev->driver;
>> - struct pci_dev *pci_dev = to_pci_dev(dev);
>> -
>> - pci_dev_complete_resume(pci_dev);
>> -
>> - if (drv && drv->pm && drv->pm->complete)
>> - drv->pm->complete(dev);
>> + pci_dev_complete_resume(to_pci_dev(dev));
>> + pm_generic_complete(dev);
>> }
>>
>> #else /* !CONFIG_PM_SLEEP */
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection
On Mon, 12 Oct 2015, Mark Brown wrote: > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote: > > On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote: > > > On Wed, 07 Oct 2015, Mark Brown wrote: > > > > > This all seems pretty much fine to me - the things it is controlling are > > > > fairly specific to the way the former Wolfson devices do, they only > > > > really make sense with a fairly particular algorithm which isn't widely > > > > implemented. > > > > Is that an Ack? > > > I am guessing Mark is slightly hesitant to ack as he probably > > doesn't want to add reviewing all our jack detection bindings to > > his already fairly sizable work load and doing so here likely > > means it will be expected in the future. From talking to people at Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again. > Pretty much (plus generally being busy at ELC-E last week) - if there's > specific questions that's one thing but if it's just general requests to > look at bindings then it seems like the relevant subsystem maintainers This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked. > should have the confidence to review straightfoward device properties > like this. I don't think these bindings are particularly straightforward. The contain many terms which I'm unfamiliar with, and again, to me (the uninitiated) this looks like way too many bindings just to see if an audio jack is plugged in or not. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dm snapshot: fix memory leak
If wrong option is given then we are returning but we missed releasing
the workqueue and pstore.
Add an error path and use it to correctly release resources on failure.
Fixes: b0d3cc011e53 ("dm snapshot: add new persistent store option to support
overflow")
Signed-off-by: Sudip Mukherjee
---
drivers/md/dm-snap-persistent.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm-snap-persistent.c b/drivers/md/dm-snap-persistent.c
index 229be55..5ff7c23 100644
--- a/drivers/md/dm-snap-persistent.c
+++ b/drivers/md/dm-snap-persistent.c
@@ -847,6 +847,7 @@ static void persistent_drop_snapshot(struct
dm_exception_store *store)
static int persistent_ctr(struct dm_exception_store *store, char *options)
{
struct pstore *ps;
+ int ret;
/* allocate the pstore */
ps = kzalloc(sizeof(*ps), GFP_KERNEL);
@@ -868,9 +869,9 @@ static int persistent_ctr(struct dm_exception_store *store,
char *options)
ps->metadata_wq = alloc_workqueue("ksnaphd", WQ_MEM_RECLAIM, 0);
if (!ps->metadata_wq) {
- kfree(ps);
DMERR("couldn't start header metadata update thread");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_free_ps;
}
if (options) {
@@ -879,13 +880,20 @@ static int persistent_ctr(struct dm_exception_store
*store, char *options)
store->userspace_supports_overflow = true;
else {
DMERR("Unsupported persistent store option: %s",
options);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_option;
}
}
store->context = ps;
return 0;
+
+err_option:
+ destroy_workqueue(ps->metadata_wq);
+err_free_ps:
+ kfree(ps);
+ return ret;
}
static unsigned persistent_status(struct dm_exception_store *store,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection
On Mon, 12 Oct 2015, Chanwoo Choi wrote: > On 2015년 10월 12일 19:16, Chanwoo Choi wrote: > > Hi Charles, > > > > On 2015년 10월 12일 17:45, Charles Keepax wrote: > >> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote: > >>> On Wed, 07 Oct 2015, Mark Brown wrote: > >>> > On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote: > > Add additional bindings to allow configuration of the system specific > > microphone detection settings. > > This all seems pretty much fine to me - the things it is controlling are > fairly specific to the way the former Wolfson devices do, they only > really make sense with a fairly particular algorithm which isn't widely > implemented. > >>> > >>> Is that an Ack? > >> > >> I am guessing Mark is slightly hesitant to ack as he probably > >> doesn't want to add reviewing all our jack detection bindings to > >> his already fairly sizable work load and doing so here likely > >> means it will be expected in the future. From talking to people at > >> LinuxCon it looks like it is pretty unlikely the DT maintainers > >> will be acking individual bindings as well, basically they are > >> only really looking at major/framework things and leaving the > >> rest to subsystem maintainers. > >> > >> Given that these patches only touch MFD/Extcon and extcon > >> is a subsystem designed to handle things like jack detection > >> isn't it really sufficient that you and Chanwoo have looked this > >> and are happy with it? Otherwise I really don't see anyway to > >> move this forward and would appreciate any suggestions? > > > > I'm positive about your patches. After receiving the ack from MFD maintainer > > I want to apply this patch-set on extcon git repository. > > > > Also, I reviewed this patch on previous patch[1]. > > [1]https://lkml.org/lkml/2015/9/11/81 > > As you said, this patch touch MFD and EXTCON subsystem. > If you get the Ack or agreement from MFD maintainer, > I'm willing to apply it on extcon git. > > Also, If this patch dont receive the additional ack message > unitl the end of this week, I'll merge patch1-3 on extcon-next branch > for Linux 4.4. Absolutely not! I should be extremely cross if you 'go over my head' and apply MFD patches without the correct Acks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mfd: rt5033: Add RT5033 Flash led sub device
Hi Lee Jones,
Okay, I'm try to remove needless part and resend it
Thanks for the review
Thank you
On 2015년 10월 13일 16:06, Lee Jones wrote:
> On Mon, 12 Oct 2015, Ingi Kim wrote:
>
>> This patch adds rt5033-led sub device to support it.
>>
>> Signed-off-by: Ingi Kim
>> ---
>> drivers/mfd/rt5033.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
>> index d60f916..b7f374b 100644
>> --- a/drivers/mfd/rt5033.c
>> +++ b/drivers/mfd/rt5033.c
>> @@ -40,13 +40,17 @@ static const struct regmap_irq_chip rt5033_irq_chip = {
>> };
>>
>> static const struct mfd_cell rt5033_devs[] = {
>> -{ .name = "rt5033-regulator", },
>> {
>> +.name = "rt5033-regulator",
>> +}, {
>
> There's no need for this change. Please remove it.
>
>> .name = "rt5033-charger",
>> .of_compatible = "richtek,rt5033-charger",
>> }, {
>> .name = "rt5033-battery",
>> .of_compatible = "richtek,rt5033-battery",
>> +}, {
>> +.name = "rt5033-led",
>> +.of_compatible = "richtek,rt5033-led",
>
> For when you resubmit with the hunk above removed:
>
> Acked-by: Lee Jones
>
>> },
>> };
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
> Hello Lokesh,
>
> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
>> +Nishanth,
>>
>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
>>> On embedded devices, often there is a combination of
>>> removable mmc devices (e.g. MMC/SD cards) and hard
>>> wired ones (e.g. eMMC). Depending on the hardware
>>> configuration, the 'mmcblkN' node might change if
>>> the removable device is available or not at boot time.
>>>
>>> E.g. if the removable device is attached at boot time,
>>> it might become mmxblk0. And the hard wired one mmcblk1.
>>> But if the removable device isn't there at boot time,
>>> the hard wired one will become mmcblk0. This makes it
>>> somehow difficult to hard code the root device to the
>>> non-removable device and boot fast.
>>
>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
>> mmcblk no?
>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
>> does this in u-boot.
>
> Good tip ... I do not know, if it is possible to update U-Boot
> on this boards...
>
> Current U-Boot says:
> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
>
> I2C: ready
> DRAM: 512 MiB
> [...]
> U-Boot# mmc rescan
> U-Boot# mmc part
>
> Partition Map for MMC device 0 -- Partition Type: DOS
>
> PartStart SectorNum Sectors UUIDType
> 1 63 144522 000ce343-01 0e Boot
> 2 144585 659861 000ce343-02 83
> U-Boot# part uuid mmc 0:2 uuid
> Unknown command 'part' - try 'help'
> U-Boot#
>
> So, if this patch has no chance for mainline, please let me
> know it, thanks!
>
IIRC, Nishanth had posted a patch something similar but got rejected for
some reason. Probably Nishanth can comment more here.
Thanks and regards,
Lokesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Tue, Oct 13, 2015 at 03:55:17AM +0800, Yuyang Du wrote: > I think maybe the real disease is the tg->load_avg is not updated in time. > I.e., it is after migrate, the source cfs_rq does not decrease its > contribution > to the parent's tg->load_avg fast enough. No, using the load_avg for shares calculation seems wrong; that would mean we'd first have to ramp up the avg before you react. You want to react quickly to actual load changes, esp. going up. We use the avg to guess the global group load, since that's the best compromise we have, but locally it doesn't make sense to use the avg if we have the actual values. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ext2: Add locking for DAX faults
On Mon 12-10-15 15:41:35, Ross Zwisler wrote: > On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote: > > On Fri, Oct 09, 2015 at 04:02:08PM -0600, Ross Zwisler wrote: > > > Add locking to ensure that DAX faults are isolated from ext2 operations > > > that modify the data blocks allocation for an inode. This is intended to > > > be analogous to the work being done in XFS by Dave Chinner: > > > > > > http://www.spinics.net/lists/linux-fsdevel/msg90260.html > > > > > > Compared with XFS the ext2 case is greatly simplified by the fact that > > > ext2 > > > already allocates and zeros new blocks before they are returned as part of > > > ext2_get_block(), so DAX doesn't need to worry about getting unmapped or > > > unwritten buffer heads. > > > > > > This means that the only work we need to do in ext2 is to isolate the DAX > > > faults from inode block allocation changes. I believe this just means > > > that > > > we need to isolate the DAX faults from truncate operations. > > > > Why limit this just to DAX page faults? > > Yep, I see that XFS uses the same locking to protect both DAX and non-DAX > faults. I'll add this protection to non-DAX ext2 faults as well. Actually, since ext2 driver doesn't support punch hole, there is no need for additional locking in non-DAX paths. So we can save some space in inode and locking for that common case. So I'd prefer if we didn't add unnecessary locking in those paths and just document that for non-DAX faults using page lock and i_size check is enough. After all the main usecase of ext2 driver these days is for people with tiny devices... Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Tue, Oct 13, 2015 at 03:32:47AM +0800, Yuyang Du wrote: > On Mon, Oct 12, 2015 at 01:47:23PM +0200, Peter Zijlstra wrote: > > > > Also, should we do the below? At this point se->on_rq is still 0 so > > reweight_entity() will not update (dequeue/enqueue) the accounting, but > > we'll have just accounted the 'old' load.weight. > > > > Doing it this way around we'll first update the weight and then account > > it, which seems more accurate. > > I think the original looks ok. > > The account_entity_enqueue() adds child entity's load.weight to parent's load: > > update_load_add(&cfs_rq->load, se->load.weight) > > Then recalculate the shares. > > Then reweight_entity() resets the parent entity's load.weight. Yes, some days I should just not be allowed near a keyboard :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection
On Fri, 02 Oct 2015, Charles Keepax wrote: > Add additional bindings to allow configuration of the system specific > microphone detection settings. > > Signed-off-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt | 21 > + > include/dt-bindings/mfd/arizona.h |5 + > 2 files changed, 26 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index a8fee60..b98a11b 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -73,6 +73,27 @@ Optional properties: > If this node is not mentioned or if the value is unknown, then > headphone detection mode is set to HPDETL. > > + - wlf,micd-software-compare : Use a software comparison to determine mic > +presence > + - wlf,micd-detect-debounce : Additional software microphone detection > +debounce specified in milliseconds. > + - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset > +polarity if one exists. > + - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to > +performing microphone detection, specified as per the > ARIZONA_MICD_TIME_XXX > +defines. > + - wlf,micd-rate : Delay between successive microphone detection > measurements, > +specified as per the ARIZONA_MICD_TIME_XXX defines. > + - wlf,micd-dbtime : Microphone detection hardware debounces specified as > the > +number of measurements to take, valid values being 2 and 4. > + - wlf,micd-timeout : Timeout for microphone detection, specified in > +milliseconds. > + - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone > +detection. > + > + - wlf,gpsw : Settings for the general purpose switch, set as one of the > +ARIZONA_GPSW_XXX defines. Where are all of these bindings to be consumed? >- DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified > if > they are being externally supplied. As covered in > Documentation/devicetree/bindings/regulator/regulator.txt > diff --git a/include/dt-bindings/mfd/arizona.h > b/include/dt-bindings/mfd/arizona.h > index c40f665..dedf46f 100644 > --- a/include/dt-bindings/mfd/arizona.h > +++ b/include/dt-bindings/mfd/arizona.h > @@ -110,4 +110,9 @@ > #define ARIZONA_ACCDET_MODE_HPM 4 > #define ARIZONA_ACCDET_MODE_ADC 7 > > +#define ARIZONA_GPSW_OPEN 0 > +#define ARIZONA_GPSW_CLOSED 1 > +#define ARIZONA_GPSW_CLAMP_ENABLED 2 > +#define ARIZONA_GPSW_CLAMP_DISABLED 3 > + > #endif -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert
On Mon, 12 Oct 2015, Charles Keepax wrote: > On Mon, Oct 05, 2015 at 11:01:05AM +0100, Lee Jones wrote: > > On Fri, 02 Oct 2015, Charles Keepax wrote: > > > > > Add additional binding for inverting the polarity of the detection on > > > the jack detection pins. > > > > > > Signed-off-by: Charles Keepax > > > --- > > > Documentation/devicetree/bindings/mfd/arizona.txt |2 ++ > > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > > > b/Documentation/devicetree/bindings/mfd/arizona.txt > > > index b98a11b..ef59696 100644 > > > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > > > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > > > @@ -73,6 +73,8 @@ Optional properties: > > > If this node is not mentioned or if the value is unknown, then > > > headphone detection mode is set to HPDETL. > > > > > > + - wlf,jd-invert : Invert the polarity of the jack detection switch > > > + > > > > There are other jack detection properties in the bindings docs. > > > > Please generify. > > Apologies but not sure I follow what you want me to do here? Do > you just want me to drop the wlf, prefix on this one? I'm trying to avoid every vendor having their own audio jack properties, when many of them have exactly the same function. Please take a look at each of your bindings and make an informed decision on which you think are unique to you and which you think others can/will make use of. Of course, if you have a unique requirement for a property and can justify its existence, then it should be submitted with your vendor prefix. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/5] cpufreq: ondemand: update sampling rate immediately
We are immediately updating sampling rate for already queued-works, only
if the new expiry is lesser than the old one.
But what about the case, where the user doesn't want frequent events and
want to increase sampling time immediately? Shouldn't we cancel the
works (and so their interrupts) on all policy->cpus (which might occur
very shortly).
This patch removes this special case and simplifies code by immediately
updating the expiry.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_ondemand.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index 03ac6ce54042..bf0511a9735c 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -231,17 +231,8 @@ static unsigned int od_dbs_timer(struct cpu_dbs_info *cdbs,
static struct common_dbs_data od_dbs_cdata;
/**
- * update_sampling_rate - update sampling rate effective immediately if needed.
+ * update_sampling_rate - update sampling rate immediately.
* @new_rate: new sampling rate
- *
- * If new rate is smaller than the old, simply updating
- * dbs_tuners_int.sampling_rate might not be appropriate. For example, if the
- * original sampling_rate was 1 second and the requested new sampling rate is
10
- * ms because the user needs immediate reaction from ondemand governor, but not
- * sure if higher frequency will be required or not, then, the governor may
- * change the sampling rate too late; up to 1 second later. Thus, if we are
- * reducing the sampling rate, we need to make the new value effective
- * immediately.
*/
static void update_sampling_rate(struct dbs_data *dbs_data,
unsigned int new_rate)
@@ -255,7 +246,6 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
for_each_online_cpu(cpu) {
struct cpufreq_policy *policy;
struct od_cpu_dbs_info_s *dbs_info;
- unsigned long next_sampling, appointed_at;
policy = cpufreq_cpu_get(cpu);
if (!policy)
@@ -270,16 +260,9 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
if (!delayed_work_pending(&dbs_info->cdbs.dwork))
continue;
- next_sampling = jiffies + usecs_to_jiffies(new_rate);
- appointed_at = dbs_info->cdbs.dwork.timer.expires;
-
- if (time_before(next_sampling, appointed_at)) {
- cancel_delayed_work_sync(&dbs_info->cdbs.dwork);
-
- gov_queue_work(dbs_data, policy,
- usecs_to_jiffies(new_rate), true);
-
- }
+ cancel_delayed_work_sync(&dbs_info->cdbs.dwork);
+ gov_queue_work(dbs_data, policy, usecs_to_jiffies(new_rate),
+ true);
}
}
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/5] cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate()
'timer_mutex' is required to sync work-handlers of policy->cpus.
update_sampling_rate() is just canceling the works and queuing them
again. This isn't protecting anything at all in update_sampling_rate()
and is not gonna be of any use.
Even if a work-handler is already running for a CPU,
cancel_delayed_work_sync() will wait for it to finish.
Drop these unnecessary locks.
Reviewed-by: Preeti U Murthy
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_ondemand.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index 1fa9088c84a8..03ac6ce54042 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -267,27 +267,19 @@ static void update_sampling_rate(struct dbs_data
*dbs_data,
dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
cpufreq_cpu_put(policy);
- mutex_lock(&dbs_info->cdbs.shared->timer_mutex);
-
- if (!delayed_work_pending(&dbs_info->cdbs.dwork)) {
- mutex_unlock(&dbs_info->cdbs.shared->timer_mutex);
+ if (!delayed_work_pending(&dbs_info->cdbs.dwork))
continue;
- }
next_sampling = jiffies + usecs_to_jiffies(new_rate);
appointed_at = dbs_info->cdbs.dwork.timer.expires;
if (time_before(next_sampling, appointed_at)) {
-
- mutex_unlock(&dbs_info->cdbs.shared->timer_mutex);
cancel_delayed_work_sync(&dbs_info->cdbs.dwork);
- mutex_lock(&dbs_info->cdbs.shared->timer_mutex);
gov_queue_work(dbs_data, policy,
usecs_to_jiffies(new_rate), true);
}
- mutex_unlock(&dbs_info->cdbs.shared->timer_mutex);
}
}
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 5/5] cpufreq: Get rid of ->governor_enabled and its lock
Invalid state-transitions is verified by governor core now and there is
no need to replicate that in cpufreq core.
Stop verifying the same in cpufreq core. That will get rid of
policy->governor_enabled and cpufreq_governor_lock.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 24
include/linux/cpufreq.h | 1 -
2 files changed, 25 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 25c4c15103a0..0c89b09672e4 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -102,7 +102,6 @@ static LIST_HEAD(cpufreq_governor_list);
static struct cpufreq_driver *cpufreq_driver;
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
static DEFINE_RWLOCK(cpufreq_driver_lock);
-DEFINE_MUTEX(cpufreq_governor_lock);
/* Flag to suspend/resume CPUFreq governors */
static bool cpufreq_suspended;
@@ -2035,21 +2034,6 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
pr_debug("%s: for CPU %u, event %u\n", __func__, policy->cpu, event);
- mutex_lock(&cpufreq_governor_lock);
- if ((policy->governor_enabled && event == CPUFREQ_GOV_START)
- || (!policy->governor_enabled
- && (event == CPUFREQ_GOV_LIMITS || event == CPUFREQ_GOV_STOP))) {
- mutex_unlock(&cpufreq_governor_lock);
- return -EBUSY;
- }
-
- if (event == CPUFREQ_GOV_STOP)
- policy->governor_enabled = false;
- else if (event == CPUFREQ_GOV_START)
- policy->governor_enabled = true;
-
- mutex_unlock(&cpufreq_governor_lock);
-
ret = policy->governor->governor(policy, event);
if (!ret) {
@@ -2057,14 +2041,6 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
policy->governor->initialized++;
else if (event == CPUFREQ_GOV_POLICY_EXIT)
policy->governor->initialized--;
- } else {
- /* Restore original values */
- mutex_lock(&cpufreq_governor_lock);
- if (event == CPUFREQ_GOV_STOP)
- policy->governor_enabled = true;
- else if (event == CPUFREQ_GOV_START)
- policy->governor_enabled = false;
- mutex_unlock(&cpufreq_governor_lock);
}
if (((event == CPUFREQ_GOV_POLICY_INIT) && ret) ||
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index dca22de98d94..d211da0763b7 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -80,7 +80,6 @@ struct cpufreq_policy {
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
- boolgovernor_enabled; /* governor start/stop flag */
charlast_governor[CPUFREQ_NAME_LEN]; /* last
governor used */
struct work_struct update; /* if update_policy() needs to be
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 4/5] cpufreq: governor: Quit work-handlers early if governor is stopped
cpufreq_governor_lock is abused by using it outside of cpufreq core,
i.e. in cpufreq-governors. But we didn't had a better solution to the
problem (described later) at that point of time, and following was the
only acceptable solution:
6f1e4efd882e ("cpufreq: Fix timer/workqueue corruption by protecting
reading governor_enabled")
The cpufreq governor core is fixed against possible races now and things
are in much better shape.
The original problem:
When a CPU is hot unplugged, we cancel delayed works for all
policy->cpus via gov_cancel_work(). If the work is already running on
any CPU, the workqueue code will wait for the work to finish, to prevent
the work items from re-queuing themselves.
This works most of the time, except for the case where the work handler
determines that it should adjust the delay for all other CPUs, that the
policy is managing. When this happens, the canceling CPU will cancel its
own work but can queue up the works on other policy->cpus.
For example, consider CPU 0-4 in a policy and we called
gov_cancel_work() for them. Workqueue core canceled the works for 0-3
and is waiting for the handler to finish on CPU4. At that time, handler
on CPU4 can restart works on CPU 0-3 again. Which makes 0-3 run works,
which the governor core thinks are canceled.
To fix that in a different (non-hacky) way, set set shared->policy to
false before trying to cancel the work. It should be updated within
timer_mutex, which will prevent the work-handlers to start. Once the
work-handlers finds that we are already trying to stop the governor, it
will exit early. And that will prevent queuing of works again as well.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_governor.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 750626d8fb03..931424ca96d9 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -171,10 +171,6 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
cpufreq_policy *policy,
{
int i;
- mutex_lock(&cpufreq_governor_lock);
- if (!policy->governor_enabled)
- goto out_unlock;
-
if (!all_cpus) {
/*
* Use raw_smp_processor_id() to avoid preemptible warnings.
@@ -188,9 +184,6 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
cpufreq_policy *policy,
for_each_cpu(i, policy->cpus)
__gov_queue_work(i, dbs_data, delay);
}
-
-out_unlock:
- mutex_unlock(&cpufreq_governor_lock);
}
EXPORT_SYMBOL_GPL(gov_queue_work);
@@ -229,13 +222,24 @@ static void dbs_timer(struct work_struct *work)
struct cpu_dbs_info *cdbs = container_of(work, struct cpu_dbs_info,
dwork.work);
struct cpu_common_dbs_info *shared = cdbs->shared;
- struct cpufreq_policy *policy = shared->policy;
- struct dbs_data *dbs_data = policy->governor_data;
+ struct cpufreq_policy *policy;
+ struct dbs_data *dbs_data;
unsigned int sampling_rate, delay;
bool modify_all = true;
mutex_lock(&shared->timer_mutex);
+ policy = shared->policy;
+
+ /*
+* Governor might already be disabled and there is no point continuing
+* with the work-handler.
+*/
+ if (!policy)
+ goto unlock;
+
+ dbs_data = policy->governor_data;
+
if (dbs_data->cdata->governor == GOV_CONSERVATIVE) {
struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
@@ -252,6 +256,7 @@ static void dbs_timer(struct work_struct *work)
delay = dbs_data->cdata->gov_dbs_timer(cdbs, dbs_data, modify_all);
gov_queue_work(dbs_data, policy, delay, modify_all);
+unlock:
mutex_unlock(&shared->timer_mutex);
}
@@ -488,9 +493,17 @@ static int cpufreq_governor_stop(struct cpufreq_policy
*policy,
if (!shared || !shared->policy)
return -EBUSY;
+ /*
+* Work-handler must see this updated, as it should not proceed any
+* further after governor is disabled. And so timer_mutex is taken while
+* updating this value.
+*/
+ mutex_lock(&shared->timer_mutex);
+ shared->policy = NULL;
+ mutex_unlock(&shared->timer_mutex);
+
gov_cancel_work(dbs_data, policy);
- shared->policy = NULL;
mutex_destroy(&shared->timer_mutex);
return 0;
}
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 3/5] cpufreq: ondemand: queue work for policy->cpus together
Currently update_sampling_rate() runs over each online CPU and
cancels/queues work on it. Its very inefficient for the case where a
single policy manages multiple CPUs, as they can be processed together.
Also drop the unnecessary cancel_delayed_work_sync() as we are doing a
mod_delayed_work_on() in gov_queue_work(), which will take care of
pending works for us.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_ondemand.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index bf0511a9735c..4677c7e9d534 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -238,29 +238,36 @@ static void update_sampling_rate(struct dbs_data
*dbs_data,
unsigned int new_rate)
{
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+ struct cpufreq_policy *policy;
+ struct od_cpu_dbs_info_s *dbs_info;
+ struct cpumask cpumask;
int cpu;
+ cpumask_copy(&cpumask, cpu_online_mask);
+
od_tuners->sampling_rate = new_rate = max(new_rate,
dbs_data->min_sampling_rate);
- for_each_online_cpu(cpu) {
- struct cpufreq_policy *policy;
- struct od_cpu_dbs_info_s *dbs_info;
-
+ for_each_cpu(cpu, &cpumask) {
policy = cpufreq_cpu_get(cpu);
if (!policy)
continue;
+
+ /* clear all CPUs of this policy */
+ cpumask_andnot(&cpumask, &cpumask, policy->cpus);
+
if (policy->governor != &cpufreq_gov_ondemand) {
cpufreq_cpu_put(policy);
continue;
}
+
dbs_info = &per_cpu(od_cpu_dbs_info, cpu);
cpufreq_cpu_put(policy);
- if (!delayed_work_pending(&dbs_info->cdbs.dwork))
+ /* Make sure the work is not canceled on policy->cpus */
+ if (!dbs_info->cdbs.shared->policy)
continue;
- cancel_delayed_work_sync(&dbs_info->cdbs.dwork);
gov_queue_work(dbs_data, policy, usecs_to_jiffies(new_rate),
true);
}
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Tue, Oct 13, 2015 at 10:06:48AM +0200, Peter Zijlstra wrote: > On Tue, Oct 13, 2015 at 03:55:17AM +0800, Yuyang Du wrote: > > > I think maybe the real disease is the tg->load_avg is not updated in time. > > I.e., it is after migrate, the source cfs_rq does not decrease its > > contribution > > to the parent's tg->load_avg fast enough. > > No, using the load_avg for shares calculation seems wrong; that would > mean we'd first have to ramp up the avg before you react. > > You want to react quickly to actual load changes, esp. going up. > > We use the avg to guess the global group load, since that's the best > compromise we have, but locally it doesn't make sense to use the avg if > we have the actual values. That is, can you send the original patch with a Changelog etc.. so that I can press 'A' :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] tpm: introduce tpm_buf
This patch introduces struct tpm_buf that provides a string buffer for
constructing TPM commands. This allows to construct variable sized TPM
commands. For the buffer a page is allocated and mapped, which limits
maximum size to PAGE_SIZE.
Variable sized TPM commands are needed in order to add algorithmic
agility.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm.h | 97 ++
1 file changed, 97 insertions(+)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f8319a0..df43979 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2004 IBM Corporation
+ * Copyright (C) 2015 Intel Corporation
*
* Authors:
* Leendert van Doorn
@@ -28,6 +29,7 @@
#include
#include
#include
+#include
enum tpm_const {
TPM_MINOR = 224,/* officially assigned */
@@ -382,6 +384,101 @@ struct tpm_cmd_t {
tpm_cmd_params params;
} __packed;
+/* A string buffer type for constructing TPM commands. This is based on the
+ * ideas of string buffer code in security/keys/trusted.h but is heap based
+ * in order to keep the stack usage minimal.
+ */
+
+enum tpm_buf_flags {
+ TPM_BUF_OVERFLOW= BIT(0),
+};
+
+struct tpm_buf {
+ struct page *data_page;
+ unsigned int flags;
+ u8 *data;
+};
+
+static inline void tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
+{
+ struct tpm_input_header *head;
+
+ buf->data_page = alloc_page(GFP_HIGHUSER);
+ if (!buf->data_page)
+ return -ENOMEM;
+
+ buf->flags = 0;
+ buf->data = kmap(buf->data_page);
+
+ head = (struct tpm_input_header *) buf->data;
+
+ head->tag = cpu_to_be16(tag);
+ head->length = cpu_to_be32(sizeof(*head));
+ head->ordinal = cpu_to_be32(ordinal);
+
+ return 0;
+}
+
+static inline void tpm_buf_destroy(struct tpm_buf *buf)
+{
+ kunmap(buf->data_page);
+ __free_page(buf->data_page);
+}
+
+static inline u32 tpm_buf_length(struct tpm_buf *buf)
+{
+ struct tpm_input_header *head = (struct tpm_input_header *) buf->data;
+
+ return be32_to_cpu(head->length);
+}
+
+static inline u16 tpm_buf_tag(struct tpm_buf *buf)
+{
+ struct tpm_input_header *head = (struct tpm_input_header *) buf->data;
+
+ return be16_to_cpu(head->tag);
+}
+
+static inline void tpm_buf_append(struct tpm_buf *buf,
+ const unsigned char *new_data,
+ unsigned int new_len)
+{
+ struct tpm_input_header *head = (struct tpm_input_header *) buf->data;
+ u32 len = tpm_buf_length(buf);
+
+ /* Return silently if overflow has already happened. */
+ if (buf->flags & TPM_BUF_OVERFLOW)
+ return;
+
+ if ((len + new_len) > PAGE_SIZE) {
+ WARN(1, "tpm_buf: overflow\n");
+ buf->flags |= TPM_BUF_OVERFLOW;
+ return;
+ }
+
+ memcpy(&buf->data[len], new_data, new_len);
+ head->length = cpu_to_be32(len + new_len);
+}
+
+static inline void tpm_buf_append_u8(struct tpm_buf *buf, const u8 value)
+{
+ tpm_buf_append(buf, &value, 1);
+}
+
+static inline void tpm_buf_append_u16(struct tpm_buf *buf, const u16 value)
+{
+ __be16 value2 = cpu_to_be16(value);
+
+ tpm_buf_append(buf, (u8 *) &value2, 2);
+}
+
+static inline void tpm_buf_append_u32(struct tpm_buf *buf, const u32 value)
+{
+ __be32 value2 = cpu_to_be32(value);
+
+ tpm_buf_append(buf, (u8 *) &value2, 4);
+}
+
extern struct class *tpm_class;
extern dev_t tpm_devt;
extern const struct file_operations tpm_fops;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] Basic trusted keys support for TPM 2.0
Basic trusted keys support: auth value and SHA256. v2: * Removed all the changes that modify the existing functions to use the new struct tpm_buf. These changes should be done separately from this patch set as they require separate QA + review. * 'keyhandle=' is now required for TPM2. Makes sense to always state the sealing key because there's no any fixed keys on the chip (thanks to Andreas Fuchs for this comment). * I updated tpm_buf to a be heap based structure. Now there's one full page of memory for variable sized messages. Also the stack is greatly reduced. Jarkko Sakkinen (4): tpm: introduce tpm_buf keys, trusted: move struct trusted_key_options to trusted-type.h tpm: seal/unseal for TPM 2.0 keys, trusted: seal/unseal with TPM 2.0 chips drivers/char/tpm/tpm-interface.c | 76 drivers/char/tpm/tpm.h | 110 + drivers/char/tpm/tpm2-cmd.c | 250 ++- include/keys/trusted-type.h | 14 ++- include/linux/tpm.h | 26 security/keys/trusted.c | 36 +- security/keys/trusted.h | 11 -- 7 files changed, 507 insertions(+), 16 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: axp20x: Add a cell for the power button part of the,axp288 PMICs
On Mon, 12 Oct 2015, Borun Fu wrote:
> This patch adds the mfd cell info for axp288 power key device.
>
> Signed-off-by: Borun Fu
> Signed-off-by: Fei Yang
> ---
> drivers/mfd/axp20x.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 3f576b7..3f4e11f 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -161,6 +161,21 @@ static struct resource axp22x_pek_resources[] = {
> },
> };
>
> +static struct resource axp288_power_button_resources[] = {
> + {
> + .name = "PEK_DBR",
> + .start = AXP288_IRQ_POKN,
> + .end= AXP288_IRQ_POKN,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .name = "PEK_DBF",
> + .start = AXP288_IRQ_POKP,
> + .end= AXP288_IRQ_POKP,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static struct resource axp288_fuel_gauge_resources[] = {
> {
> .start = AXP288_IRQ_QWBTU,
> @@ -572,6 +587,11 @@ static struct mfd_cell axp288_cells[] = {
> .resources = axp288_fuel_gauge_resources,
> },
> {
> + .name = "axp20x-pek", /* axp20x-pek works for AXP288 as well */
Doesn't this change insinuate that?
If axp20x-pek didn't work for AXP288 you wouldn't have put it in this
structure right?
> + .num_resources = ARRAY_SIZE(axp288_power_button_resources),
> + .resources = axp288_power_button_resources,
> + },
> + {
> .name = "axp288_pmic_acpi",
> },
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] keys, trusted: seal/unseal with TPM 2.0 chips
Call tpm_seal_trusted() and tpm_unseal_trusted() for TPM 2.0 chips.
Signed-off-by: Jarkko Sakkinen
Reviewed-by: Andreas Fuchs
---
security/keys/trusted.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index c0594cb..d3633cf 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -862,12 +862,19 @@ static int datablob_parse(char *datablob, struct
trusted_key_payload *p,
static struct trusted_key_options *trusted_options_alloc(void)
{
struct trusted_key_options *options;
+ int tpm2;
+
+ tpm2 = tpm_is_tpm2(TPM_ANY_NUM);
+ if (tpm2 < 0)
+ return NULL;
options = kzalloc(sizeof *options, GFP_KERNEL);
if (options) {
/* set any non-zero defaults */
options->keytype = SRK_keytype;
- options->keyhandle = SRKHANDLE;
+
+ if (!tpm2)
+ options->keyhandle = SRKHANDLE;
}
return options;
}
@@ -905,6 +912,11 @@ static int trusted_instantiate(struct key *key,
int ret = 0;
int key_cmd;
size_t key_len;
+ int tpm2;
+
+ tpm2 = tpm_is_tpm2(TPM_ANY_NUM);
+ if (tpm2 < 0)
+ return tpm2;
if (datalen <= 0 || datalen > 32767 || !prep->data)
return -EINVAL;
@@ -932,12 +944,20 @@ static int trusted_instantiate(struct key *key,
goto out;
}
+ if (!options->keyhandle) {
+ ret = -EINVAL;
+ goto out;
+ }
+
dump_payload(payload);
dump_options(options);
switch (key_cmd) {
case Opt_load:
- ret = key_unseal(payload, options);
+ if (tpm2)
+ ret = tpm_unseal_trusted(TPM_ANY_NUM, payload, options);
+ else
+ ret = key_unseal(payload, options);
dump_payload(payload);
dump_options(options);
if (ret < 0)
@@ -950,7 +970,10 @@ static int trusted_instantiate(struct key *key,
pr_info("trusted_key: key_create failed (%d)\n", ret);
goto out;
}
- ret = key_seal(payload, options);
+ if (tpm2)
+ ret = tpm_seal_trusted(TPM_ANY_NUM, payload, options);
+ else
+ ret = key_seal(payload, options);
if (ret < 0)
pr_info("trusted_key: key_seal failed (%d)\n", ret);
break;
@@ -1018,6 +1041,13 @@ static int trusted_update(struct key *key, struct
key_preparsed_payload *prep)
kfree(new_p);
goto out;
}
+
+ if (!new_o->keyhandle) {
+ ret = -EINVAL;
+ kfree(new_p);
+ goto out;
+ }
+
/* copy old key values, and reseal with new pcrs */
new_p->migratable = p->migratable;
new_p->key_len = p->key_len;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] tpm: seal/unseal for TPM 2.0
Added tpm_trusted_seal() and tpm_trusted_unseal() API for sealing
trusted keys.
This patch implements basic sealing and unsealing functionality for
TPM 2.0:
* Seal with a parent key using a 20 byte auth value.
* Unseal with a parent key using a 20 byte auth value.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 76
drivers/char/tpm/tpm.h | 15 ++-
drivers/char/tpm/tpm2-cmd.c | 250 ++-
include/keys/trusted-type.h | 2 +-
include/linux/tpm.h | 26
5 files changed, 366 insertions(+), 3 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index e85d341..c50637d 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -666,6 +666,30 @@ int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx,
u8 *res_buf)
}
/**
+ * tpm_is_tpm2 - is the chip a TPM2 chip?
+ * @chip_num: tpm idx # or ANY
+ *
+ * Returns < 0 on error, and 1 or 0 on success depending whether the chip
+ * is a TPM2 chip.
+ */
+int tpm_is_tpm2(u32 chip_num)
+{
+ struct tpm_chip *chip;
+ int rc;
+
+ chip = tpm_chip_find_get(chip_num);
+ if (chip == NULL)
+ return -ENODEV;
+
+ rc = (chip->flags & TPM_CHIP_FLAG_TPM2) != 0;
+
+ tpm_chip_put(chip);
+
+ return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_is_tpm2);
+
+/**
* tpm_pcr_read - read a pcr value
* @chip_num: tpm idx # or ANY
* @pcr_idx: pcr idx to retrieve
@@ -1021,6 +1045,58 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max)
}
EXPORT_SYMBOL_GPL(tpm_get_random);
+/**
+ * tpm_seal_trusted() - seal a trusted key
+ * @chip_num: A specific chip number for the request or TPM_ANY_NUM
+ * @options: authentication values and other options
+ * @payload: the key data in clear and encrypted form
+ *
+ * Returns < 0 on error and 0 on success. At the moment, only TPM 2.0 chips
+ * are supported.
+ */
+int tpm_seal_trusted(u32 chip_num, struct trusted_key_payload *payload,
+struct trusted_key_options *options)
+{
+ struct tpm_chip *chip;
+ int rc;
+
+ chip = tpm_chip_find_get(chip_num);
+ if (chip == NULL || !(chip->flags & TPM_CHIP_FLAG_TPM2))
+ return -ENODEV;
+
+ rc = tpm2_seal_trusted(chip, payload, options);
+
+ tpm_chip_put(chip);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_seal_trusted);
+
+/**
+ * tpm_unseal_trusted() - unseal a trusted key
+ * @chip_num: A specific chip number for the request or TPM_ANY_NUM
+ * @options: authentication values and other options
+ * @payload: the key data in clear and encrypted form
+ *
+ * Returns < 0 on error and 0 on success. At the moment, only TPM 2.0 chips
+ * are supported.
+ */
+int tpm_unseal_trusted(u32 chip_num, struct trusted_key_payload *payload,
+ struct trusted_key_options *options)
+{
+ struct tpm_chip *chip;
+ int rc;
+
+ chip = tpm_chip_find_get(chip_num);
+ if (chip == NULL || !(chip->flags & TPM_CHIP_FLAG_TPM2))
+ return -ENODEV;
+
+ rc = tpm2_unseal_trusted(chip, payload, options);
+
+ tpm_chip_put(chip);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_unseal_trusted);
+
static int __init tpm_init(void)
{
int rc;
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index df43979..09aca509 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -90,6 +90,9 @@ enum tpm2_return_codes {
enum tpm2_algorithms {
TPM2_ALG_SHA1 = 0x0004,
+ TPM2_ALG_KEYEDHASH = 0x0008,
+ TPM2_ALG_SHA256 = 0x000B,
+ TPM2_ALG_NULL = 0x0010
};
enum tpm2_command_codes {
@@ -97,6 +100,10 @@ enum tpm2_command_codes {
TPM2_CC_SELF_TEST = 0x0143,
TPM2_CC_STARTUP = 0x0144,
TPM2_CC_SHUTDOWN= 0x0145,
+ TPM2_CC_CREATE = 0x0153,
+ TPM2_CC_LOAD= 0x0157,
+ TPM2_CC_UNSEAL = 0x015E,
+ TPM2_CC_FLUSH_CONTEXT = 0x0165,
TPM2_CC_GET_CAPABILITY = 0x017A,
TPM2_CC_GET_RANDOM = 0x017B,
TPM2_CC_PCR_READ= 0x017E,
@@ -399,7 +406,7 @@ struct tpm_buf {
u8 *data;
};
-static inline void tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
+static inline int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
{
struct tpm_input_header *head;
@@ -525,6 +532,12 @@ static inline void tpm_remove_ppi(struct tpm_chip *chip)
int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash);
int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max);
+int tpm2_seal_trusted(struct tpm_chip *chip,
+ struct trusted_key_payload *payload,
+ struct trusted_key_options *options);
+int tpm2_unseal_trusted(struct tpm_chip *chip,
+ struct
[PATCH v2 2/4] keys, trusted: move struct trusted_key_options to trusted-type.h
Moved struct trusted_key_options to trustes-type.h so that the fields
can be accessed from drivers/char/tpm.
Signed-off-by: Jarkko Sakkinen
---
include/keys/trusted-type.h | 12
security/keys/trusted.h | 11 ---
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 56f82e5..c91651f 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -12,10 +12,12 @@
#include
#include
+#include
#define MIN_KEY_SIZE 32
#define MAX_KEY_SIZE 128
#define MAX_BLOB_SIZE 320
+#define MAX_PCRINFO_SIZE 64
struct trusted_key_payload {
struct rcu_head rcu;
@@ -26,6 +28,16 @@ struct trusted_key_payload {
unsigned char blob[MAX_BLOB_SIZE];
};
+struct trusted_key_options {
+ uint16_t keytype;
+ uint32_t keyhandle;
+ unsigned char keyauth[TPM_DIGEST_SIZE];
+ unsigned char blobauth[TPM_DIGEST_SIZE];
+ uint32_t pcrinfo_len;
+ unsigned char pcrinfo[MAX_PCRINFO_SIZE];
+ int pcrlock;
+};
+
extern struct key_type key_type_trusted;
#endif /* _KEYS_TRUSTED_TYPE_H */
diff --git a/security/keys/trusted.h b/security/keys/trusted.h
index 3249fbd..ff001a5 100644
--- a/security/keys/trusted.h
+++ b/security/keys/trusted.h
@@ -2,7 +2,6 @@
#define __TRUSTED_KEY_H
/* implementation specific TPM constants */
-#define MAX_PCRINFO_SIZE 64
#define MAX_BUF_SIZE 512
#define TPM_GETRANDOM_SIZE 14
#define TPM_OSAP_SIZE 36
@@ -36,16 +35,6 @@ enum {
SRK_keytype = 4
};
-struct trusted_key_options {
- uint16_t keytype;
- uint32_t keyhandle;
- unsigned char keyauth[SHA1_DIGEST_SIZE];
- unsigned char blobauth[SHA1_DIGEST_SIZE];
- uint32_t pcrinfo_len;
- unsigned char pcrinfo[MAX_PCRINFO_SIZE];
- int pcrlock;
-};
-
#define TPM_DEBUG 0
#if TPM_DEBUG
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: add link to the Intel Graphics for Linux web site
There's plenty of drm/i915 related hardware and software documentation, and firmware downloads for the latest platforms. Cc: Daniel Vetter Signed-off-by: Jani Nikula --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5f467845ef72..95c6bcb6bf22 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3584,6 +3584,7 @@ M:Daniel Vetter M: Jani Nikula L: intel-...@lists.freedesktop.org L: dri-de...@lists.freedesktop.org +W: https://01.org/linuxgraphics/ Q: http://patchwork.freedesktop.org/project/intel-gfx/ T: git git://anongit.freedesktop.org/drm-intel S: Supported -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc
On Sun, 11 Oct 2015, Jonathan Cameron wrote:
> On 05/10/15 07:14, H. Nikolaus Schaller wrote:
> > This driver code was found as:
> >
> > https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
> >
> > Fixed various compilation issues and test this driver on omap5 evm.
> >
> > Signed-off-by: Pradeep Goudagunta
> > Signed-off-by: H. Nikolaus Schaller
> > Signed-off-by: Marek Belisko
>
> I'm pretty much fine with this. However, there are some edits within the
> existing mfd support so I will want acks for that or for the driver to go
> through the MFD tree (note that as it touched that, even if only a header,
> Lee and Samuel should have been cc'd).
>
> One thing that slightly confuses me is there seems to be hints of support in
> the
> mfd driver already... I can't find any sign of the child device however so
> I guess this is fine from that point of view.
>
> Reviewed-by: Jonathan Cameron
> > ---
> > drivers/iio/adc/Kconfig| 9 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/palmas_gpadc.c | 818
> > +
> > include/linux/mfd/palmas.h | 75 ++--
Acked-by: Lee Jones
> > 4 files changed, 879 insertions(+), 24 deletions(-)
> > create mode 100644 drivers/iio/adc/palmas_gpadc.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index eb0cd89..05a0368 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -242,6 +242,15 @@ config NAU7802
> > To compile this driver as a module, choose M here: the
> > module will be called nau7802.
> >
> > +config PALMAS_GPADC
> > + tristate "TI Palmas General Purpose ADC"
> > + depends on MFD_PALMAS
> > + help
> > + Say yes here to build support for Texas Instruments Palmas.
> > +
> > + Palmas series pmic chip (twl6035/6037) is used in smartphones and
> > + tablets and supports a 16 channel general purpose ADC.
> > +
> > config QCOM_SPMI_IADC
> > tristate "Qualcomm SPMI PMIC current ADC"
> > depends on SPMI
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index a096210..716f112 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
> > obj-$(CONFIG_MCP3422) += mcp3422.o
> > obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> > obj-$(CONFIG_NAU7802) += nau7802.o
> > +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
> > obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
> > obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
> > obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> > diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> > new file mode 100644
> > index 000..6805d81
> > --- /dev/null
> > +++ b/drivers/iio/adc/palmas_gpadc.c
> > @@ -0,0 +1,818 @@
> > +/*
> > + * palmas-adc.c -- TI PALMAS GPADC.
> > + *
> > + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
> > + *
> > + * Author: Pradeep Goudagunta
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MOD_NAME "palmas-gpadc"
> > +#define PALMAS_ADC_CONVERSION_TIMEOUT (msecs_to_jiffies(5000))
> > +#define PALMAS_TO_BE_CALCULATED 0
> > +#define PALMAS_GPADC_TRIMINVALID -1
> > +
> > +struct palmas_gpadc_info {
> > +/* calibration codes and regs */
> > + int x1; /* lower ideal code */
> > + int x2; /* higher ideal code */
> > + int v1; /* expected lower volt reading */
> > + int v2; /* expected higher volt reading */
> > + u8 trim1_reg; /* register number for lower trim */
> > + u8 trim2_reg; /* register number for upper trim */
> > + int gain; /* calculated from above (after reading trim regs) */
> > + int offset; /* calculated from above (after reading trim regs) */
> > + int gain_error; /* calculated from above (after reading trim regs) */
> > + bool is_uncalibrated; /* if channel has calibration data */
> > +};
> > +
> > +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2,
> > _is_uncalibrated) \
> > + [PALMAS_ADC_CH_##_chan] = { \
> > + .x1 = _x1, \
> > + .x2 = _x2, \
> > + .v1 = _v1, \
> > + .v2 = _v2, \
> > + .gain = PALMAS_TO_BE_CALCULATED, \
> > + .offset = PALMAS_TO_BE_CALCULATED, \
> > + .gain_error = PALMAS_TO_BE_CALCULATED, \
> > + .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
> > + .trim2_reg = PALMAS_GPADC_TRIM##_t2, \
> > + .is_uncalibrated = _is_uncalibrated \
> > + }
> > +
> > +static struct p
Re: [RFC PATCH 1/2] ext4: Fix possible deadlock with local interrupts disabled and page-draining IPI
On Mon 12-10-15 17:51:07, Nikolay Borisov wrote: > Hello and thanks for the reply, > > On 10/12/2015 04:40 PM, Jan Kara wrote: > > On Fri 09-10-15 11:03:30, Nikolay Borisov wrote: > >> On 10/09/2015 10:37 AM, Hillf Danton wrote: > >> @@ -109,8 +109,8 @@ static void ext4_finish_bio(struct bio *bio) > >>if (bio->bi_error) > >>buffer_io_error(bh); > >>} while ((bh = bh->b_this_page) != head); > >> - bit_spin_unlock(BH_Uptodate_Lock, &head->b_state); > >>local_irq_restore(flags); > > > > What if it takes 100ms to unlock after IRQ restored? > > I'm not sure I understand in what direction you are going? Care to > elaborate? > > >>> Your change introduces extra time cost the lock waiter has to pay in > >>> the case that irq happens before the lock is released. > >> > >> [CC filesystem and mm people. For reference the thread starts here: > >> http://thread.gmane.org/gmane.linux.kernel/2056996 ] > >> > >> Right, I see what you mean and it's a good point but when doing the > >> patches I was striving for correctness and starting a discussion, hence > >> the RFC. In any case I'd personally choose correctness over performance > >> always ;). > >> > >> As I'm not an fs/ext4 expert and have added the relevant parties (please > >> use reply-all from now on so that the thread is not being cut in the > >> middle) who will be able to say whether it impact is going to be that > >> big. I guess in this particular code path worrying about this is prudent > >> as writeback sounds like a heavily used path. > >> > >> Maybe the problem should be approached from a different angle e.g. > >> drain_all_pages and its reliance on the fact that the IPI will always be > >> delivered in some finite amount of time? But what if a cpu with disabled > >> interrupts is waiting on the task issuing the IPI? > > > > So I have looked through your patch and also original report (thread starts > > here: https://lkml.org/lkml/2015/10/8/341) and IMHO one question hasn't > > been properly answered yet: Who is holding BH_Uptodate_Lock we are spinning > > on? You have suggested in https://lkml.org/lkml/2015/10/8/464 that it was > > __block_write_full_page_endio() call but that cannot really be the case. > > BH_Uptodate_Lock is used only in IO completion handlers - > > end_buffer_async_read, end_buffer_async_write, ext4_finish_bio. So there > > really should be some end_io function running on some other CPU which holds > > BH_Uptodate_Lock for that buffer. > > I did check all the call traces of the current processes on the machine > at the time of the hard lockup and none of the 3 functions you mentioned > were in any of the call chains. But while I was looking the code of > end_buffer_async_write and in the comments I saw it was mentioned that > those completion handler were called from __block_write_full_page_endio > so that's what pointed my attention to that function. But you are right > that it doesn't take the BH lock. > > Furthermore the fact that the BH_Async_Write flag is set points me in > the direction that end_buffer_async_write should have been executing but > as I said issuing "bt" for all the tasks didn't show this function. Actually ext4_bio_write_page() also sets BH_Async_Write so that seems like a more likely place where that flag got set since ext4_finish_bio() was then handling IO completion. > I'm beginning to wonder if it's possible that a single bit memory error > has crept up, but this still seems like a long shot... Yup. Possible but a long shot. Is the problem reproducible in any way? > Btw I think in any case the spin_lock patch is wrong as this code can be > called from within softirq context and we do want to be interrupt safe > at that point. Agreed, that patch is definitely wrong. > > BTW: I suppose the filesystem uses 4k blocksize, doesn't it? > > Unfortunately I cannot tell you with 100% certainty, since on this > server there are multiple block devices with blocksize either 1k or 4k. > So it is one of these. If you know a way to extract this information > from a vmcore file I'd be happy to do it. Well, if you have a crashdump, then bh->b_size is the block size. So just check that for the bh we are spinning on. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] backlight: 88pm860x_bl: add missing of_node_put
On Sat, 10 Oct 2015, Julia Lawall wrote:
> for_each_child_of_node performs an of_node_get on each iteration, so
> a break out of the loop requires an of_node_put.
>
> The semantic patch that fixes this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @@
> expression root,e;
> local idexpression child;
> iterator name for_each_child_of_node;
> @@
>
> for_each_child_of_node(root, child) {
>... when != of_node_put(child)
>when != e = child
> + of_node_put(child);
> ? break;
>...
> }
> ... when != child
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/video/backlight/88pm860x_bl.c |1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
> diff --git a/drivers/video/backlight/88pm860x_bl.c
> b/drivers/video/backlight/88pm860x_bl.c
> index 2da5862..6d8dc2c 100644
> --- a/drivers/video/backlight/88pm860x_bl.c
> +++ b/drivers/video/backlight/88pm860x_bl.c
> @@ -180,6 +180,7 @@ static int pm860x_backlight_dt_init(struct
> platform_device *pdev,
> data->iset = PM8606_WLED_CURRENT(iset);
> of_property_read_u32(np, "marvell,88pm860x-pwm",
>&data->pwm);
> + of_node_put(np);
> break;
> }
> }
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: ccm - remove goto
Instead of using goto and jumping to a label and then returning from
there, lets return directly. The label out: is not used from anywhere
else in the code.
Signed-off-by: Sudip Mukherjee
---
crypto/ccm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/crypto/ccm.c b/crypto/ccm.c
index cc31ea4..daa7e6d 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -881,14 +881,13 @@ static int crypto_rfc4309_create(struct crypto_template
*tmpl,
if (err)
goto out_drop_alg;
-out:
return err;
out_drop_alg:
crypto_drop_aead(spawn);
out_free_inst:
kfree(inst);
- goto out;
+ return err;
}
static struct crypto_template crypto_rfc4309_tmpl = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: da9062-core: Rename get_device_type to da9062_get_device_type
On Fri, 09 Oct 2015, Axel Lin wrote:
> Rename get_device_type() to da9062_get_device_type().
> This function is only used in this file so make it static.
>
> Signed-off-by: Axel Lin
> ---
> drivers/mfd/da9062-core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> index f80d947..a9ad024 100644
> --- a/drivers/mfd/da9062-core.c
> +++ b/drivers/mfd/da9062-core.c
> @@ -198,7 +198,7 @@ static int da9062_clear_fault_log(struct da9062 *chip)
> return ret;
> }
>
> -int get_device_type(struct da9062 *chip)
> +static int da9062_get_device_type(struct da9062 *chip)
> {
> int device_id, variant_id, variant_mrc;
> int ret;
> @@ -466,7 +466,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> if (ret < 0)
> dev_warn(chip->dev, "Cannot clear fault log\n");
>
> - ret = get_device_type(chip);
> + ret = da9062_get_device_type(chip);
> if (ret)
> return ret;
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V1 1/2] mfd: da9053: Addition of extra registers for GPIOs 8-13
On 13 October 2015 08:32 Lee Jones wrote: > To: Opensource [Steve Twiss] > Cc: LINUXKERNEL; Samuel Ortiz; David Dajun Chen; Support Opensource > Subject: Re: [PATCH V1 1/2] mfd: da9053: Addition of extra registers for > GPIOs 8-13 > > On Thu, 08 Oct 2015, Steve Twiss wrote: > > > From: Steve Twiss > > > > Definitions for GPIO registers 8, 9, 10, 11, 12 and 13 are added into > > the register header file. > > > > - DA9052_GPIO_8_9_REG25 > > - DA9052_GPIO_10_11_REG 26 > > - DA9052_GPIO_12_13_REG 27 > > > > A modification is also made to the MFD core code to define these registers > > as readable and writable. The functions for da9052_reg_readable() and > > da9052_reg_writeable() have had their case statements altered to include > > these new registers. > > > > Signed-off-by: Steve Twiss > > > > --- > > This patch applies against linux-next and v4.3-rc4 > > > > > > drivers/mfd/da9052-core.c | 6 ++ > > include/linux/mfd/da9052/reg.h | 3 +++ > > 2 files changed, 9 insertions(+) > > Applied, thanks. Thanks Lee. Regards, Steve
Re: [Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap
On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote:
> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> > On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> > > i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> > > map it with memremap rather than the implied cache setting of
> > > acpi_os_ioremap().
> > >
> > > Cc: Daniel Vetter
> > > Cc: Jani Nikula
> > > Cc: intel-...@lists.freedesktop.org
> > > Cc: David Airlie
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: Dan Williams
> >
> > Assuming you've run sparse over this to make sure you've caught them all,
> > and with the nit below addressed this is
> >
> > Reviewed-by: Daniel Vetter
>
> Indeed, re-running sparse again found a few conversions of ioread* I
> missed as well as moving the force casting out of validate_vbt() to
> find_vbt().
>
> > Feel free to pull v2 into whatever tree you think it's suitable for (but
> > you can also resend and I'll pick it up).
>
> Please pick up v2 below.
Queued for -next, thanks for the patch. Aside: Attached or separate mail
seems easier, somehow git apply-mbox can't auto-eat this for of patch.
-Daniel
>
> >
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > b/drivers/gpu/drm/i915/intel_panel.c
> > > index e2ab3f6ed022..c8444d5f549f 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -387,7 +387,7 @@ intel_panel_detect(struct drm_device *dev)
> > >
> > > /* Assume that the BIOS does not lie through the OpRegion... */
> > > if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> > > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> > > + return *(dev_priv->opregion.lid_state) & 0x1 ?
> >
> > () are redundant now here.
>
> Yup, fixed.
>
> 8<
> Subject: i915: switch from acpi_os_ioremap to memremap
>
> From: Dan Williams
>
> i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> map it with memremap rather than the implied cache setting of
> acpi_os_ioremap().
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-...@lists.freedesktop.org
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dan Williams
> ---
> drivers/gpu/drm/i915/i915_debugfs.c |2 -
> drivers/gpu/drm/i915/i915_drv.h | 12 ++---
> drivers/gpu/drm/i915/intel_bios.c | 25 +-
> drivers/gpu/drm/i915/intel_opregion.c | 83
> -
> drivers/gpu/drm/i915/intel_panel.c|2 -
> 5 files changed, 62 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e3ec9049081f..15989cc16e92 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1849,7 +1849,7 @@ static int i915_opregion(struct seq_file *m, void
> *unused)
> goto out;
>
> if (opregion->header) {
> - memcpy_fromio(data, opregion->header, OPREGION_SIZE);
> + memcpy(data, opregion->header, OPREGION_SIZE);
> seq_write(m, data, OPREGION_SIZE);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e1db8de52851..d8684634a31d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -444,14 +444,14 @@ struct opregion_swsci;
> struct opregion_asle;
>
> struct intel_opregion {
> - struct opregion_header __iomem *header;
> - struct opregion_acpi __iomem *acpi;
> - struct opregion_swsci __iomem *swsci;
> + struct opregion_header *header;
> + struct opregion_acpi *acpi;
> + struct opregion_swsci *swsci;
> u32 swsci_gbda_sub_functions;
> u32 swsci_sbcb_sub_functions;
> - struct opregion_asle __iomem *asle;
> - void __iomem *vbt;
> - u32 __iomem *lid_state;
> + struct opregion_asle *asle;
> + void *vbt;
> + u32 *lid_state;
> struct work_struct asle_work;
> };
> #define OPREGION_SIZE(8*1024)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index c19e669ffe50..f6762a5faee8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1231,20 +1231,13 @@ static const struct dmi_system_id
> intel_no_opregion_vbt[] = {
> { }
> };
>
> -static const struct bdb_header *validate_vbt(const void __iomem *_base,
> +static const struct bdb_header *validate_vbt(const void *base,
>size_t size,
> - const void __iomem *_vbt,
> + const void *_vbt,
>const char *source)
> {
> - /*
> - * This is the one place where we explicitly discard the address space
> - * (__iomem) of the BIOS/VBT. (And this will cause a sparse complai
Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion
On 2015-10-12 21:39, Mitchel Humpherys wrote:
On Tue, Oct 06 2015 at 05:35:41 PM, Rob Herring
wrote:
On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott
wrote:
[...]
+Example:
+
+ ion {
+ compatbile = "linux,ion";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ion-system-heap {
+ linux,ion-heap-id = <0>;
+ linux,ion-heap-type = ;
+ linux,ion-heap-name = "system";
How does this vary across platforms? Is all of this being pushed down
to DT, because there is no coordination of this at the kernel ABI
level across platforms. In other words, why can't heap 0 be hardcoded
as system heap in the driver. It seems to me any 1 of these 3
properties could be used to derive the other 2.
The heap-id<->heap-type mapping isn't necessarily 1:1. As Laura
indicated elsewhere on this thread, a given heap might need to be
contiguous on one platform but not on another. In that case you just
swap out the heap-type here and there's no need for userspace to
change.
The heap-name, OTOH, could be derived from the heap-id, which is what
we
hackishly do here [1] and here[2].
By the way, since we agreed that heap id and heap type mappings
are not 1:1 - we have a problem with the current API.
In userspace we currently have this:
int ion_alloc(int fd, size_t len, size_t align, unsigned int heap_mask,
unsigned int flags, ion_user_handle_t *handle);
We do not specify here what TYPE of heap we want the allocation to come
from.
This may lead to very unpleasant stuff when porting from one platfrom to
another.
But, manual heap id control is VERY neat, since it allows to cover a lot
of
platform-specific cases, where allocating memory from certain heaps can
yield performance boost.
In other words - maybe we should specify both suitable heap types and
heap ids?
[1]
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n53
[2]
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/staging/android/ion/msm/msm_ion.c?h=msm-3.14#n398
-Mitch
--
Regards,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND] mfd: rtsx: add support for rts522A
On Sat, 10 Oct 2015, 敬锐 wrote:
> Sorry for bother you, but I still can't see this patch applied.
> Is there something wrong?
Sorry about that Micky, I guess this one fell through the gaps.
Re-applied, should be in -next by tomorrow.
> On 07/08/2015 03:38 PM, Lee Jones wrote:
> > On Wed, 08 Jul 2015, 敬锐 wrote:
> >
> >>
> >> On 07/07/2015 07:46 PM, Lee Jones wrote:
> >>> On Mon, 29 Jun 2015, micky_ch...@realsil.com.cn wrote:
> >>>
> From: Micky Ching
>
> rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
> Add it to file mfd/rts5227.c to support this chip.
>
> Signed-off-by: Micky Ching
> ---
> drivers/mfd/Kconfig | 7 ++--
> drivers/mfd/rts5227.c| 77
> ++--
> drivers/mfd/rtsx_pcr.c | 5 +++
> drivers/mfd/rtsx_pcr.h | 3 ++
> include/linux/mfd/rtsx_pci.h | 6
> 5 files changed, 93 insertions(+), 5 deletions(-)
> >>> I Acked this once already.
> >>>
> >>> What's changed since then?
> >> It's not changed, but I don't have time to fix magic numbers these days,
> >> so, I prefer you apply this patch not waiting next patch.
> > Subsequent patches are irrelevant. I Acked this patch, so the Ack
> > should carry forward.
> >
> > I'll apply the patch for now, but please bear this in mind for the
> > future.
> >
> > Patch applied, thanks.
> >
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6538159..614c146 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -686,9 +686,10 @@ config MFD_RTSX_PCI
> select MFD_CORE
> help
> This supports for Realtek PCI-Express card reader including
> rts5209,
> - rts5229, rtl8411, etc. Realtek card reader supports access to
> many
> - types of memory cards, such as Memory Stick, Memory Stick Pro,
> - Secure Digital and MultiMediaCard.
> + rts5227, rts522A, rts5229, rts5249, rts524A, rts525A,
> rtl8411, etc.
> + Realtek card reader supports access to many types of memory
> cards,
> + such as Memory Stick, Memory Stick Pro, Secure Digital and
> + MultiMediaCard.
>
> config MFD_RT5033
> tristate "Richtek RT5033 Power Management IC"
> diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
> index ce012d7..cf13e66 100644
> --- a/drivers/mfd/rts5227.c
> +++ b/drivers/mfd/rts5227.c
> @@ -26,6 +26,14 @@
>
> #include "rtsx_pcr.h"
>
> +static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
> +{
> +u8 val;
> +
> +rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, &val);
> +return val & 0x0F;
> +}
> +
> static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
> {
> u8 driving_3v3[4][3] = {
> @@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr
> *pcr, u8 pm_state)
> rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
>
> if (pm_state == HOST_ENTER_S3)
> -rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
> +rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10,
> 0x10);
>
> rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
> }
> @@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr
> *pcr)
> rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8,
> 0xB8);
> else
> rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8,
> 0x88);
> -rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10,
> 0x00);
>
> return rtsx_pci_send_cmd(pcr, 100);
> }
> @@ -298,8 +306,73 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
> pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
> pcr->rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
>
> +pcr->ic_version = rts5227_get_ic_version(pcr);
> pcr->sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
> pcr->sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
> pcr->ms_pull_ctl_enable_tbl = rts5227_ms_pull_ctl_enable_tbl;
> pcr->ms_pull_ctl_disable_tbl = rts5227_ms_pull_ctl_disable_tbl;
> +
> +pcr->reg_pm_ctrl3 = PM_CTRL3;
> +}
> +
> +static int rts522a_optimize_phy(struct rtsx_pcr *pcr)
> +{
> +int err;
> +
> +err = rtsx_pci_write_register(pcr, RTS522A_PM_CTRL3,
> D3_DELINK_MODE_EN,
> +0x00);
> +
Re: 4.3 group scheduling regression
On Tue, Oct 13, 2015 at 10:06:48AM +0200, Peter Zijlstra wrote: > On Tue, Oct 13, 2015 at 03:55:17AM +0800, Yuyang Du wrote: > > > I think maybe the real disease is the tg->load_avg is not updated in time. > > I.e., it is after migrate, the source cfs_rq does not decrease its > > contribution > > to the parent's tg->load_avg fast enough. > > No, using the load_avg for shares calculation seems wrong; that would > mean we'd first have to ramp up the avg before you react. > > You want to react quickly to actual load changes, esp. going up. > > We use the avg to guess the global group load, since that's the best > compromise we have, but locally it doesn't make sense to use the avg if > we have the actual values. In Mike's case, since the mplayer group has only one active task, after the task migrates, the source cfs_rq should have zero contrib to the tg, so at the destination, the group entity should have the entire tg's share. It is just the zeroing can be that fast we need. But yes, in a general case, the load_avg (that has the blocked load) is likely to lag behind. Using the actual load.weight to accelerate the process makes sense. It is especially helpful to the less hungry tasks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16] Divorcing irqdomain and device_node
On 12/10/15 21:38, Rafael J. Wysocki wrote:
> On Sunday, October 11, 2015 11:01:17 PM Thomas Gleixner wrote:
>> On Tue, 6 Oct 2015, Marc Zyngier wrote:
>>> [This patch series used to be called "Making the generic ACPI GSI
>>> layer irqdomain aware", but as I've radically changed my approach to
>>> this problem, I've decided to reset the counters...]
>>>
>>> The irqdomain code is not entierely ACPI friendly, as it has some
>>> built-in knowledge of the device-tree. Nothing too harmful, but enough
>>> to scare the ARM ACPI developpers which end up with their own version
>>> of the square wheel. And some of the ramifications actually run deeper
>>> than initially expected.
>>>
>>> This series adapts the irqdomain code to use 'struct fwnode_handle'
>>> instead of 'struct device_node' as the identifier for a domain
>>> (compatibility interfaces are of course added). It also introduces a
>>> generic IRQ specifier that firmware interfaces (DT or ACPI) can
>>> directly use to configure interrupts, and allow the ACPI GSI code to
>>> be plugged into this.
>>>
>>> As examples, we convert the ARM GIC ACPI support to use irqdomains as
>>> originally intended, and rework the MSI code to also move away from
>>> using device nodes when using irqdomains.
>>>
>>> Overall, this gives us a way to use irqdomains on both DT and ACPI
>>> enabled platforms, having very little changes made to the actual
>>> drivers (other than the probing infrastructure). Because we keep the
>>> flow of information between the various layers identical between ACPI
>>> and DT, we immediately benefit from the existing infrastructure.
>>>
>>> This has been test-booted on Juno, is based on 4.3-rc4, and available at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
>>> irq/irq-domain-fwnode-v1
>>>
>>> Marc Zyngier (16):
>>> irqdomain: Use an accessor for the of_node field
>>> irqdomain: Convert irqdomain->of_node to fwnode
>>> irqdomain: Allow irq domain lookup by fwnode
>>> irqdomain: Introduce a firmware-specific IRQ specifier structure
>>> irqchip: Convert all alloc/xlate users from of_node to fwnode
>>> irqdomain: Introduce irq_create_fwspec_mapping
>>> irqdomain: Introduce irq_domain_create_{linear,tree}
>>> irqdomain: Add a fwnode_handle allocator
>>> acpi/gsi: Always perform an irq domain lookup
>>> acpi/gsi: Add acpi_set_irq_model to initialize the GSI layer
>>> irqchip/gic: Get rid of gic_init_bases()
>>> irqchip/gic: Switch ACPI support to stacked domains
>>> irqchip/gic: Kill the xlate method
>>> acpi/gsi: Cleanup acpi_register_gsi
>>> irqdomain: Introduce irq_domain_create_hierarchy
>>> irqdomain/msi: Use fwnode instead of of_node
>>
>> I really like this one way better than the previous attempts and I
>> couldn't find any real issue when going through them with a fine comb.
>>
>> I'd like to get that into 4.4, so I have to ask for the opinion of
>> ACPI folks. Having an ack on those patches would be nice.
>
> I've ACKed the generic ones, please let me know if I missed any of them.
>
> The rest seems to be ARM-specific ...
Thanks a lot Rafael.
I'll repost the series today with a couple of fixes so that Thomas can
stick it into -next.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: exynos_defconfig: Enable Maxim 8997 family drivers
Hello Krzysztof, On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote: > Enable support for Maxim 8997 Multi Functional Device present on Trats and > Origen boards by toggling on drivers: charger, haptic motor, > LED, RTC and extcon. > > This allows to test and usage of these boards with exynos config. > > Signed-off-by: Krzysztof Kozlowski > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Tue, Oct 13, 2015 at 10:10:23AM +0200, Peter Zijlstra wrote: > On Tue, Oct 13, 2015 at 10:06:48AM +0200, Peter Zijlstra wrote: > > On Tue, Oct 13, 2015 at 03:55:17AM +0800, Yuyang Du wrote: > > > > > I think maybe the real disease is the tg->load_avg is not updated in time. > > > I.e., it is after migrate, the source cfs_rq does not decrease its > > > contribution > > > to the parent's tg->load_avg fast enough. > > > > No, using the load_avg for shares calculation seems wrong; that would > > mean we'd first have to ramp up the avg before you react. > > > > You want to react quickly to actual load changes, esp. going up. > > > > We use the avg to guess the global group load, since that's the best > > compromise we have, but locally it doesn't make sense to use the avg if > > we have the actual values. > > That is, can you send the original patch with a Changelog etc.. so that > I can press 'A' :-) Sure, in minutes, :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: exynos_defconfig: Enable Maxim 77693 LED and haptic drivers
Hello Krzysztof, On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote: > Enable support for: > 1. Haptic motor driver on Trats2 board (Maxim 77693) and Note 4 >(Maxim 77843); > 2. LED driver on Trats2 board (Maxim 77693). > > Signed-off-by: Krzysztof Kozlowski > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 resend] err.h: add (missing) unlikely() to IS_ERR_OR_NULL()
IS_ERR_VALUE() already contains it and so we need to add this only to
the !ptr check. That will allow users of IS_ERR_OR_NULL(), to not add
this compiler flag.
Signed-off-by: Viresh Kumar
---
@Jiri: You have applied all other patches, but this one. Can you please
apply this one as well, as all others were applied based on the
assumption that this one is applied. :)
include/linux/err.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/err.h b/include/linux/err.h
index a729120644d5..56762ab41713 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -37,7 +37,7 @@ static inline bool __must_check IS_ERR(__force const void
*ptr)
static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
{
- return !ptr || IS_ERR_VALUE((unsigned long)ptr);
+ return unlikely(!ptr) || IS_ERR_VALUE((unsigned long)ptr);
}
/**
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Tue, Oct 13, 2015 at 09:51:02AM +0200, Thomas Gleixner wrote: > > You are restricting the problem space to this particular use > case. There are other use cases where PTP is not available or not the > relevant reference, but you still want to correlate time domains to > ART. They may well be other use cases, but they have not been identified here. The PTP to media clock problem has a very simple solution. You do not need a history of system time stamps to solve it. Even if you wanted to correlate the system time's UTC with the media clock, still you don't need any shadow history for that. Just feed (ART, UTC) pairs into the DSP at a regular rate, and let the DSP do the math. This does not need to be part of the central time keeping code at all. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/4] KASAN for arm64
On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote: > Andrey Ryabinin (3): > arm64: move PGD_SIZE definition to pgalloc.h > arm64: add KASAN support > Documentation/features/KASAN: arm64 supports KASAN now > > Linus Walleij (1): > ARM64: kasan: print memory assignment Patches queued for 4.4. Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver
Hi Dave, On 16 September 2015 at 09:57, Dave Young wrote: >> >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c >> >> new file mode 100644 >> >> index 000..7ae45cc >> >> --- /dev/null >> >> +++ b/drivers/watchdog/sbsa_gwdt.c >> >> @@ -0,0 +1,459 @@ >> >> +/* >> >> + * SBSA(Server Base System Architecture) Generic Watchdog driver >> >> + * >> >> + * Copyright (c) 2015, Linaro Ltd. >> >> + * Author: Fu Wei >> >> + * Suravee Suthikulpanit >> >> + * >> >> + * This program is free software; you can redistribute it and/or modify >> >> + * it under the terms of the GNU General Public License 2 as published >> >> + * by the Free Software Foundation. >> >> + * >> >> + * This program is distributed in the hope that it will be useful, >> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> >> + * GNU General Public License for more details. >> >> + * >> >> + * The SBSA Generic watchdog driver is compatible with the pretimeout >> >> + * concept of Linux kernel. >> >> + * The timeout and pretimeout are determined by WCV or WOR. >> >> + * The first watch period is set by writing WCV directly, that can >> >> + * support more than 10s timeout at the maximum system counter >> >> + * frequency (400MHz). >> >> + * When WS0 is triggered, the second watch period (pretimeout) is >> >> + * determined by one of these registers: >> >> + * (1)WOR: 32bit register, this gives a maximum watch period of >> >> + * around 10s at the maximum system counter frequency. It's loaded >> >> + * automatically by hardware. >> >> + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", >> >> + * it will be loaded in WS0 interrupt routine. If system is in >> >> + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled >> >> + * and WS0 == true), the ping operation will only reload WCV. >> > >> > Below is the field comment about ws0_mode, it says ws0_mode is only >> > for rebooting in second stage timeout, but kexec/kdump can reboot in >> > either first or second stage >> >> Great thanks for your feedback. >> >> yes, if kexec/kdump reboot the system before the WS0, ws0_mode may not be >> set. >> in this case, if WS0 is triggered during the reboot(AFAIK, panic will >> disable irq, and in the early boot stage of system, irq is disabled, >> too.), ws0_mode will be set at the next "open" in kdump kernel >> if WS0 haven't triggered until the watchdog is opened again in kdump >> kernel , ws0_mode won't be set. >> >> ws0_mode doesn't indicate if the system is in the kdump kernel, it >> indicates that if WS0 is triggered, when the watchdog is initialized. >> >> Do I answer your question? > > Yes, thanks for explanation. So it sounds better to change the comment like > below? > from > (reboot by kexec/kdump in panic with watchdog enabled and WS0 == true) > to > (reboot in the pre-timeout stage and WS0 == true) " in the pre-timeout stage" means " WS0 == true", so I think we should say: (reboot with watchdog enabled and WS0 == true) Thanks for your suggestion. > > Thanks > Dave -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] ARM: multi_v7_defconfig: Enable Maxim 8997 family drivers
Hello Krzysztof, On Tue, Oct 13, 2015 at 3:27 AM, Krzysztof Kozlowski wrote: > Enable support for Maxim 8997 Multi Function Device present on Trats and > Origen boards by toggling on drivers: main MFD, charger, haptic motor, > regulator, LED and RTC. > > This allows to test and usage of these boards with multi_v7 config. > > Signed-off-by: Krzysztof Kozlowski > --- [snip] > CONFIG_MFD_MAX77686=y > CONFIG_MFD_MAX77693=y > CONFIG_MFD_MAX8907=y > +CONFIG_MFD_MAX8997=y Only slightly related with your patch but some of the MFD driver for PMICs used in Exynos boards (like MAX77686) have a tristate Kconfig symbol while others like this one have a boolean. Do you know if there are any restrictions w.r.t build this as module or is just an arbitrary decision? I'm asking since probably we should either allow this to build as a module or convert the others to boolean. Patch looks good to me: Reviewed-by: Javier Martinez Canillas Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] sched: consider missed ticks when updating global cpu load
On Tue, Oct 13, 2015 at 09:04:36AM +0200, Peter Zijlstra wrote: > On Mon, Oct 12, 2015 at 07:45:35PM +0200, Frederic Weisbecker wrote: > > > I think it will take more than a single patch to rework all of > > > update_process_times(). And we should also ask Thomas for his opinion, > > > but I think we want: > > > > > > - make update_process_times() take a nr_ticks argument > > > - fixup everything below it > > > > > > - fix tick_nohz_handler to not ignore the hrtimer_forward() > > > return value and pass it into > > > tick_sched_handle()/update_process_times(). > > > > > > (assuming this is the right oneshot tick part, tick-common > > > seems to be about periodic timers which aren't used much ?!) > > > > this_nohz_handler() is the low res nohz handler. tick_sched_handle() > > is the high res one (I should rename these). I think we should rather i also think frederic was confused.. > > find out the pending updates from update_process_times() itself and pass > > it to scheduler_tick() which is the one interested in it. > > tick_nohz_handler() calls tick_sched_handler() ?! > > And tick_nohz_handler() actually computes the number of ticks -- which > we then happily ignore. > > Why compute it again a few functions down? i think so. additionally, i think it would be better to assume that scheduler_tick() handles 1 tick as peter said e.g. because of virt, and to handle the case caused by full NOHZ *in the nohz related code*. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable Maxim 77693 LED and haptic drivers
Hello Krzysztof, On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote: > Enable support for: > 1. Haptic motor driver on Trats2 board (Maxim 77693) and Note 4 (Maxim >77843); > 2. LED driver on Trats2 board (Maxim 77693). > > Signed-off-by: Krzysztof Kozlowski > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fixed several comment coding style blasphemies.
Signed-off-by: Michal Hrbek
---
drivers/gpu/vga/vgaarb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index a0b4334..41f3e13 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -96,7 +96,8 @@ static const char *vga_iostate_to_str(unsigned int iostate)
static int vga_str_to_iostate(char *buf, int str_size, int *io_state)
{
/* we could in theory hand out locks on IO and mem
-* separately to userspace but it can cause deadlocks */
+* separately to userspace but it can cause deadlocks
+*/
if (strncmp(buf, "none", 4) == 0) {
*io_state = VGA_RSRC_NONE;
return 1;
@@ -155,13 +156,15 @@ static inline void vga_irq_set_state(struct vga_device
*vgadev, bool state)
/* If we don't ever use VGA arb we should avoid
- turning off anything anywhere due to old X servers getting
- confused about the boot device not being VGA */
+ * turning off anything anywhere due to old X servers getting
+ * confused about the boot device not being VGA
+ */
static void vga_check_first_use(void)
{
/* we should inform all GPUs in the system that
* VGA arb has occurred and to try and disable resources
-* if they can */
+* if they can
+*/
if (!vga_arbiter_used) {
vga_arbiter_used = true;
vga_arbiter_notify_clients();
@@ -985,11 +988,11 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
goto done;
}
/* TODO: Add this?
- if (io_state == VGA_RSRC_NONE) {
- ret_val = -EPROTO;
- goto done;
- }
- */
+* if (io_state == VGA_RSRC_NONE) {
+* ret_val = -EPROTO;
+* goto done;
+* }
+*/
}
pdev = priv->target;
@@ -1037,10 +1040,10 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
goto done;
}
/* TODO: Add this?
- if (io_state == VGA_RSRC_NONE) {
- ret_val = -EPROTO;
- goto done;
- }
+* if (io_state == VGA_RSRC_NONE) {
+* ret_val = -EPROTO;
+* goto done;
+* }
*/
pdev = priv->target;
@@ -1276,7 +1279,8 @@ static int pci_notify(struct notifier_block *nb, unsigned
long action,
/* For now we're only intereted in devices added and removed. I didn't
* test this thing here, so someone needs to double check for the
-* cases of hotplugable vga cards. */
+* cases of hotplugable vga cards.
+*/
if (action == BUS_NOTIFY_ADD_DEVICE)
notify = vga_arbiter_add_pci_device(pdev);
else if (action == BUS_NOTIFY_DEL_DEVICE)
@@ -1317,7 +1321,8 @@ static int __init vga_arb_device_init(void)
bus_register_notifier(&pci_bus_type, &pci_notifier);
/* We add all pci devices satisfying vga class in the arbiter by
-* default */
+* default
+*/
pdev = NULL;
while ((pdev =
pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks
On 12/10/15 20:25, Rafael J. Wysocki wrote: On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote: [...] Instead of just removing the check completely on x86, IMO restrict it to some newer/later version of ACPI so you can still force vendors to fix their ACPI tables at-least in future. No, we can't force vendors to fix their ACPI tables. This is completely unrealistic. No, I was referring to the future platforms *only* We simly need to deal with the bugs in the ACPI tables in the kernel. Yes sadly true for existing systems, but if we now place a check for ACPIv6.0 and above, we might avoid seeing such broken tables sometime in future once the kernel with this check in place is used for validation. It would be good to get such sanity check in the tools used to build those tables, but yes since such static tables can be built in many ways, its difficult to deal it in all those tools. As I said to Al, we need those checks in firmware test suites. Having them in the kernel is OK too, but they should cause warnings to be printed to the kernel log instead of causing the kernel to panic. Agreed -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: lm3533: fix build warning
On Wed, 07 Oct 2015, Sudip Mukherjee wrote:
> We were getting build warning about unused variable 'ret'.
> The commit c749db571dcf has removed the use of ret but missed removing
> the variable which is unused now.
>
> Fixes: c749db571dcf ("mfd: lm3533: Simplify function return logic")
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/mfd/lm3533-core.c | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
> index 193ecee1..5abcbb2 100644
> --- a/drivers/mfd/lm3533-core.c
> +++ b/drivers/mfd/lm3533-core.c
> @@ -592,7 +592,6 @@ static int lm3533_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> struct lm3533 *lm3533;
> - int ret;
>
> dev_dbg(&i2c->dev, "%s\n", __func__);
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mfd: rtsx: fix build warning
On Wed, 07 Oct 2015, Sudip Mukherjee wrote:
> We were getting build warning about unused variable 'err'.
> The commit a3c29b099829 has removed the use of err but missed removing
> the variable which is unused now.
>
> Fixes: a3c29b099829 ("mfd: rtsx: Simplify function return logic")
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/mfd/rtsx_pcr.c | 2 --
> 1 file changed, 2 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
> index b98cf1d..d63f3a8 100644
> --- a/drivers/mfd/rtsx_pcr.c
> +++ b/drivers/mfd/rtsx_pcr.c
> @@ -561,8 +561,6 @@ EXPORT_SYMBOL_GPL(rtsx_pci_write_ppbuf);
>
> static int rtsx_pci_set_pull_ctl(struct rtsx_pcr *pcr, const u32 *tbl)
> {
> - int err;
> -
> rtsx_pci_init_cmd(pcr);
>
> while (*tbl & 0x) {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: Make TPS6105X select REGMAP_I2C
On Wed, 07 Oct 2015, Axel Lin wrote:
> This is required since
> commit 7e5071199355 ("mfd: tps6105x: Use i2c regmap to access registers").
>
> Signed-off-by: Axel Lin
> ---
> drivers/mfd/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 87e84e7..0063c92 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1070,6 +1070,7 @@ config MFD_PALMAS
> config TPS6105X
> tristate "TI TPS61050/61052 Boost Converters"
> depends on I2C
> + select REGMAP_I2C
> select REGULATOR
> select MFD_CORE
> select REGULATOR_FIXED_VOLTAGE
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] EDAC: use debugfs_remove_recursive instead of debugfs_remove
On 2015/10/13 15:41, Borislav Petkov wrote: > On Tue, Oct 13, 2015 at 10:22:51AM +0800, Tan Xiaojun wrote: >> debugfs_remove is used to remove a file or an empty directory from >> the debugfs filesystem, but mci->debugfs is not empty. > > How exactly do you trigger this? And by "this" I'm not even sure what > the problem is as your commit message doesn't say. So please explain > also what the problem is. > > Also, use this branch instead: > > http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next > > We did change EDAC debugfs handling recently so your patch doesn't apply > anymore. > > Thanks. > Sorry, I don't describe it well. I do test like that: 1)open EDAC config and open CONFIG_EDAC_DEBUG 2)insmod a edac_mc module (like i3000_edac or others in drivers/edac/) 3)rmmod this module 4)we can also see files under /sys/kernel/debug/edac/ like "fake_inject" If you think this patch is OK, I will do patch in your branch and send V2. Thanks. Xiaojun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] mfd: sec-core: Dump PMIC revision to find out the HW
On Wed, 07 Oct 2015, Krzysztof Kozlowski wrote:
> There are different revisions of the same chipset. For example S2MPS13 has
> more than 2 revisions. They differ slightly in regulator constraints.
> Print the revision number to easily find which PMIC is used on the board.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changs since v1:
> None.
> ---
> drivers/mfd/sec-core.c | 10 ++
> 1 file changed, 10 insertions(+)
For my own reference:
Acked-by: Lee Jones
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index 2d1137a7a0ee..589e5efc2d7f 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -253,6 +253,15 @@ static const struct regmap_config s5m8767_regmap_config
> = {
> .cache_type = REGCACHE_FLAT,
> };
>
> +static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
> +{
> + unsigned int val;
> +
> + /* For each device type, the REG_ID is always the first register */
> + if (!regmap_read(sec_pmic->regmap_pmic, S2MPS11_REG_ID, &val))
> + dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
> +}
> +
> #ifdef CONFIG_OF
> /*
> * Only the common platform data elements for s5m8767 are parsed here from
> the
> @@ -425,6 +434,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> goto err_mfd;
>
> device_init_wakeup(sec_pmic->dev, sec_pmic->wakeup);
> + sec_pmic_dump_rev(sec_pmic);
>
> return ret;
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] leds: rt5033: Add RT5033 Flash led device driver
Hi Ingi,
On 10/13/2015 04:58 AM, Ingi Kim wrote:
Hi Jacek,
Thanks for your kind comments
I also append reply below
On 2015년 10월 13일 00:10, Jacek Anaszewski wrote:
Hi Ingi,
Thanks for the update. Few comments below.
On 10/12/2015 03:12 PM, Ingi Kim wrote:
This patch adds device driver of Richtek RT5033 PMIC.
The driver supports a current regulated output to drive
white LEDs for camera flash.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-rt5033.c | 223
+
include/linux/mfd/rt5033-private.h | 49
include/linux/mfd/rt5033.h | 22 +++-
5 files changed, 301 insertions(+), 2 deletions(-)
create mode 100644 drivers/leds/leds-rt5033.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 42990f2..29613e3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -345,6 +345,14 @@ config LEDS_PCA963X
LED driver chip accessed via the I2C bus. Supported
devices include PCA9633 and PCA9634
+config LEDS_RT5033
+tristate "LED support for RT5033 PMIC"
+depends on LEDS_CLASS_FLASH && OF
+depends on MFD_RT5033
+help
+ This option enables support for on-chip LED driver on
+ RT5033 PMIC.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index b503f92..bcc4d93 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+= leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ)+= leds-cobalt-raq.o
obj-$(CONFIG_LEDS_SUNFIRE)+= leds-sunfire.o
obj-$(CONFIG_LEDS_PCA9532)+= leds-pca9532.o
+obj-$(CONFIG_LEDS_RT5033)+= leds-rt5033.o
obj-$(CONFIG_LEDS_GPIO_REGISTER)+= leds-gpio-register.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_LP3944)+= leds-lp3944.o
diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
new file mode 100644
index 000..b470c94
--- /dev/null
+++ b/drivers/leds/leds-rt5033.c
@@ -0,0 +1,223 @@
+/*
+ * led driver for RT5033
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Ingi Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#define RT5033_LED_FLASH_TIMEOUT_MIN64000
+#define RT5033_LED_FLASH_TIMEOUT_STEPS32000
+#define RT5033_LED_TORCH_CURRENT_LEVEL_MAX16
+
+/* Macro for getting offset of flash timeout */
+#define GET_TIMEOUT_OFFSET(tm, step)((tm) / (step) - 2)
+
+static struct rt5033_led *flcdev_to_led(
+struct led_classdev_flash *fled_cdev)
+{
+return container_of(fled_cdev, struct rt5033_led, fled_cdev);
+}
+
+static int rt5033_led_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
+struct rt5033_led *led = flcdev_to_led(fled_cdev);
I assume that you don't use mutex here deliberately?
Actually I'm not sure why flash driver uses mutex.
Which flash driver do you have on mind?
In consideration of blocking competition, however, I'd be better to use it
[...]
+
+static int rt5033_led_flash_strobe_set(struct led_classdev_flash *fled_cdev,
+ bool state)
+{
+struct rt5033_led *led = flcdev_to_led(fled_cdev);
+u32 flash_tm_reg;
I think that you need a mutex here and in rt5033_led_flash_strobe_set.
Otherwise following is possible:
Process 1:
rt5033_led_flash_strobe_set(led_cdev, 1);
regmap_update_bits(led->regmap,RT5033_REG_FLED_FUNCTION1,
RT5033_FLED_FUNC1_MASK, RT5033_FLED_RESET);
fled_cdev->led_cdev.brightness = LED_OFF;
Process 2:
led_set_brightness(led_cdev, 1);
fled_cdev->led_cdev.brightness = 1;
rt5033_led_brightness_set(led_cdev, LED_FULL);
regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1,
RT5033_FLED_FUNC1_MASK, RT5033_FLED_PINCTRL);
regmap_update_bits(led->regmap,RT5033_REG_FLED_CTRL1,
RT5033_FLED_CTRL1_MASK,
(brightness - 1) << 4);
regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
RT5033_FLED_CTRL2_MASK, RT5033_FLED_ENFLED);
Process 1:
regmap_update_bits(led->regmap,RT5033_REG_FLED_STROBE_CTRL2,
RT5033_FLED_STRBCTRL2_MASK, flash_tm_reg);
regmap_update_bits(led->regmap,RT5033_REG_FLED_FUNCTION1,
RT5033_FLED_FUNC1_MASK, RT5033_FLED_STRB_SEL
| RT5033_FLED_PINCTRL);
regmap_update_bits(led->regmap,RT5033_REG_FLED_FUNCTION2,
RT5033_FLED_FUNC2_MASK, RT5033_FLED_ENFLED
In
Re: [PATCH v2 0/4] Basic trusted keys support for TPM 2.0
On Tue, Oct 13, 2015 at 11:11:21AM +0300, Jarkko Sakkinen wrote: > Basic trusted keys support: auth value and SHA256. > > v2: > > * Removed all the changes that modify the existing functions to use > the new struct tpm_buf. These changes should be done separately from > this patch set as they require separate QA + review. > * 'keyhandle=' is now required for TPM2. Makes sense to always state > the sealing key because there's no any fixed keys on the chip (thanks > to Andreas Fuchs for this comment). > * I updated tpm_buf to a be heap based structure. Now there's one full > page of memory for variable sized messages. Also the stack is greatly > reduced. The basic test that I did was: ID=$(keyctl add trusted kmk "new 32 keyhandle=0x8000" @u) keyctl pipe $ID > blob.hex keyctl clear @u keyctl add trusted kmk "load `cat blob.hex` keyhandle=0x8000" @u keyctl clear @u I also checked that the code fails with -EINVAL when keyhandle is not given. For generating a sealing key I used tpm2-root-key script from https://github.com/jsakkine/linux-tpm2 I think the code is in the shape that it is ready to be pulled but some tested-by's are needed. > Jarkko Sakkinen (4): > tpm: introduce tpm_buf > keys, trusted: move struct trusted_key_options to trusted-type.h > tpm: seal/unseal for TPM 2.0 > keys, trusted: seal/unseal with TPM 2.0 chips > > drivers/char/tpm/tpm-interface.c | 76 > drivers/char/tpm/tpm.h | 110 + > drivers/char/tpm/tpm2-cmd.c | 250 > ++- > include/keys/trusted-type.h | 14 ++- > include/linux/tpm.h | 26 > security/keys/trusted.c | 36 +- > security/keys/trusted.h | 11 -- > 7 files changed, 507 insertions(+), 16 deletions(-) > > -- > 2.5.0 > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v9 2/9] Input: goodix - reset device at init
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 13 October, 2015 10:08
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
>
> On Tue, Oct 13, 2015 at 06:38:23AM +, Tirdea, Irina wrote:
> >
> >
> > > -Original Message-
> > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > > Sent: 12 October, 2015 19:48
> > > To: Tirdea, Irina
> > > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> > > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> > >
> > > On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > > > After power on, it is recommended that the driver resets the device.
> > > > The reset procedure timing is described in the datasheet and is used
> > > > at device init (before writing device configuration) and
> > > > for power management. It is a sequence of setting the interrupt
> > > > and reset pins high/low at specific timing intervals. This procedure
> > > > also includes setting the slave address to the one specified in the
> > > > ACPI/device tree.
> > > >
> > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > > driver gt9xx.c for Android (publicly available in Android kernel
> > > > trees for various devices).
> > > >
> > > > For reset the driver needs to control the interrupt and
> > > > reset gpio pins (configured through ACPI/device tree). For devices
> > > > that do not have the gpio pins properly declared, the functionality
> > > > depending on these pins will not be available, but the device can still
> > > > be used with basic functionality.
> > > >
> > > > For both device tree and ACPI, the interrupt gpio pin configuration is
> > > > read from the "irq-gpio" property and the reset pin configuration is
> > > > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > > > can be specified using the _DSD section. This functionality will not be
> > > > available for devices that use indexed gpio pins declared in the _CRS
> > > > section (we need to provide backward compatibility with devices
> > > > that do not support using the interrupt gpio pin as output).
> > > >
> > > > For ACPI, the pins can be specified using ACPI 5.1:
> > > > Device (STAC)
> > > > {
> > > > Name (_HID, "GDIX1001")
> > > > ...
> > > >
> > > > Method (_CRS, 0, Serialized)
> > > > {
> > > > Name (RBUF, ResourceTemplate ()
> > > > {
> > > > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > > > AddressingMode7Bit, "\\I2C0",
> > > > 0x00, ResourceConsumer, ,
> > > > )
> > > >
> > > > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > > > "\\I2C0", 0x00, ResourceConsumer, ,
> > > > )
> > > > { // Pin list
> > > > 0
> > > > }
> > > >
> > > > GpioIo (Exclusive, PullDown, 0x, 0x,
> > > > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > > > ResourceConsumer, ,
> > > > )
> > > > {
> > > > 1
> > > > }
> > > > })
> > > > Return (RBUF)
> > > > }
> > > >
> > > > Name (_DSD, Package ()
> > > > {
> > > > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > Package ()
> > > > {
> > > > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > > > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > > > ...
> > > > }
> > > > }
> > > >
> > > > Signed-off-by: Octavian Purdila
> > > > Signed-off-by: Irina Tirdea
> > > > Acked-by: Bastien Nocera
> > > > Tested-by: Bastien Nocera
> > > > Tested-by: Aleksei Mamlin
> > > > ---
> > > > .../bindings/input/touchscreen/goodix.txt | 5 +
> > > > drivers/input/touchscreen/Kconfig | 1 +
> > > > drivers/input/touchscreen/goodix.c | 101
> > > > +
> > > > 3 files changed, 107 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > index 8ba98ee..7137881 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > @@ -12,6 +12,8 @@ Required properties:
> > > > - reg : I2C address of the chip. Should be 0x5d or
> > > > 0x14
> > > > - interrupt-parent
Re: [PATCH v4 11/25] ARM/dmaengine: edma: Merge the two drivers under drivers/dma/
On 10/12/2015 07:00 PM, Vinod Koul wrote:
> On Thu, Sep 24, 2015 at 01:01:58PM +0300, Peter Ujfalusi wrote:
>> Move the code out from arch/arm/common and merge it inside of the dmaengine
>> driver.
>> This change is done with as minimal change to the code as possible to avoid
>> any possibilities to introducing regression.
>
> Is this a pure move patch or code has been modified, if latter am
> disappointed that existing code style issue have not been fixed
Yes, it is mostly code move, I have done minimal changes only needed to get
the moved code working in the new location.
Patch 13 in this series will go through the file and will fix up most (I hope
all) of the outstanding coding style issues.
At this point I wanted to have as small change as possible.
>> +static inline void edma_write(struct edma_cc *ecc, int offset, int val)
>> +{
>> +__raw_writel(val, ecc->base + offset);
>> +}
>> +static inline void edma_modify(struct edma_cc *ecc, int offset, unsigned
>> and,
>> + unsigned or)
>
> This looks bad on my 80 char screen, and few more places below
>
>> +{
>> +unsigned val = edma_read(ecc, offset);
>
> checkpatch should have asked you to add empty line here, many places below
> too
>
>> +val &= and;
>> +val |= or;
>> +edma_write(ecc, offset, val);
>> +}
>
> empty line here and few more places
>
> More later :)
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] mfd: sec-core: Disable buck voltage reset on watchdog falling edge
On Wed, 07 Oct 2015, Krzysztof Kozlowski wrote:
> The WRSTBI bit (disabled by default but enabled by bootloader), when
> set, is responsible for resetting voltages to default values of
> certain bucks on falling edge of Warm Reset Input pin from AP.
>
> However on some boards (with S2MPS13) the pin is pulled down so any
> suspend will effectively trigger the reset of bucks supplying the power
> to the little and big cores. In the same time when resuming, these bucks
> must provide voltage greater or equal to voltage before suspend to match
> the frequency chosen by cpufreq. If voltage (default value of voltage
> after reset) is lower than one set by cpufreq before suspend, then
> system will hang during resuming.
>
> Signed-off-by: Krzysztof Kozlowski
> Reported-by: Bartlomiej Zolnierkiewicz
> Tested-by: Bartlomiej Zolnierkiewicz
These should be in chronological order.
I will do that for you this time when I apply the patch.
For my own reference:
Acked-by: Lee Jones
> ---
>
> Changs since v1:
> 1. Add Bartlomiej's Reported-by and Tested-by.
> ---
> drivers/mfd/sec-core.c | 26 ++
> include/linux/mfd/samsung/core.h| 2 ++
> include/linux/mfd/samsung/s2mps13.h | 1 +
> 3 files changed, 29 insertions(+)
>
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index 589e5efc2d7f..2626fc0b5b8c 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -262,6 +262,29 @@ static void sec_pmic_dump_rev(struct sec_pmic_dev
> *sec_pmic)
> dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
> }
>
> +static void sec_pmic_configure(struct sec_pmic_dev *sec_pmic)
> +{
> + int err;
> +
> + if (sec_pmic->device_type != S2MPS13X)
> + return;
> +
> + if (sec_pmic->pdata->disable_wrstbi) {
> + /*
> + * If WRSTBI pin is pulled down this feature must be disabled
> + * because each Suspend to RAM will trigger buck voltage reset
> + * to default values.
> + */
> + err = regmap_update_bits(sec_pmic->regmap_pmic,
> + S2MPS13_REG_WRSTBI,
> + S2MPS13_REG_WRSTBI_MASK, 0x0);
> + if (err)
> + dev_warn(sec_pmic->dev,
> + "Cannot initialize WRSTBI config: %d\n",
> + err);
> + }
> +}
> +
> #ifdef CONFIG_OF
> /*
> * Only the common platform data elements for s5m8767 are parsed here from
> the
> @@ -289,6 +312,8 @@ static struct sec_platform_data
> *sec_pmic_i2c_parse_dt_pdata(
>
> pd->manual_poweroff = of_property_read_bool(dev->of_node,
> "samsung,s2mps11-acokb-ground");
> + pd->disable_wrstbi = of_property_read_bool(dev->of_node,
> +
> "samsung,s2mps11-wrstbi-ground");
> return pd;
> }
> #else
> @@ -434,6 +459,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> goto err_mfd;
>
> device_init_wakeup(sec_pmic->dev, sec_pmic->wakeup);
> + sec_pmic_configure(sec_pmic);
> sec_pmic_dump_rev(sec_pmic);
>
> return ret;
> diff --git a/include/linux/mfd/samsung/core.h
> b/include/linux/mfd/samsung/core.h
> index aa78957e092f..a06098639399 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -134,6 +134,8 @@ struct sec_platform_data {
> int buck4_init;
> /* Whether or not manually set PWRHOLD to low during shutdown. */
> boolmanual_poweroff;
> + /* Disable the WRSTBI (buck voltage warm reset) when probing? */
> + booldisable_wrstbi;
> };
>
> /**
> diff --git a/include/linux/mfd/samsung/s2mps13.h
> b/include/linux/mfd/samsung/s2mps13.h
> index b1fd675fa36f..239e977ba45d 100644
> --- a/include/linux/mfd/samsung/s2mps13.h
> +++ b/include/linux/mfd/samsung/s2mps13.h
> @@ -184,5 +184,6 @@ enum s2mps13_regulators {
> * Let's assume that default value will be set.
> */
> #define S2MPS13_BUCK_RAMP_DELAY 12500
> +#define S2MPS13_REG_WRSTBI_MASK BIT(5)
>
> #endif /* __LINUX_MFD_S2MPS13_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mfd: dt-bindings: Document pulled down WRSTBI pin on S2MPS1X
On Wed, 07 Oct 2015, Krzysztof Kozlowski wrote: > Document a new Device Tree property 'samsung,s2mps11-wrstbi-ground' > indicating that WRSTBI pin of S2MPS13 PMIC is pulled down so > corresponding buck warm reset function should be disabled. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changs since v1: > None. > --- > Documentation/devicetree/bindings/mfd/s2mps11.txt | 3 +++ > 1 file changed, 3 insertions(+) Applied, thanks. > diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt > b/Documentation/devicetree/bindings/mfd/s2mps11.txt > index 90eaef393325..890f0b0e1643 100644 > --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt > +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt > @@ -19,6 +19,9 @@ Optional properties: >connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1 >register to turn off the power. Usually the ACOKB is pulled up to VBATT so >when PWRHOLD pin goes low, the rising ACOKB will trigger power off. > +- samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled > + down. When the system is suspended it will always go down thus triggerring > + unwanted buck warm reset (setting buck voltages to default values). > > Optional nodes: > - clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered > 32.768 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] mfd: sec-core: Disable buck voltage reset on watchdog falling edge
On Wed, 07 Oct 2015, Krzysztof Kozlowski wrote:
> The WRSTBI bit (disabled by default but enabled by bootloader), when
> set, is responsible for resetting voltages to default values of
> certain bucks on falling edge of Warm Reset Input pin from AP.
>
> However on some boards (with S2MPS13) the pin is pulled down so any
> suspend will effectively trigger the reset of bucks supplying the power
> to the little and big cores. In the same time when resuming, these bucks
> must provide voltage greater or equal to voltage before suspend to match
> the frequency chosen by cpufreq. If voltage (default value of voltage
> after reset) is lower than one set by cpufreq before suspend, then
> system will hang during resuming.
>
> Signed-off-by: Krzysztof Kozlowski
> Reported-by: Bartlomiej Zolnierkiewicz
> Tested-by: Bartlomiej Zolnierkiewicz
Applied, thanks.
> ---
>
> Changs since v1:
> 1. Add Bartlomiej's Reported-by and Tested-by.
> ---
> drivers/mfd/sec-core.c | 26 ++
> include/linux/mfd/samsung/core.h| 2 ++
> include/linux/mfd/samsung/s2mps13.h | 1 +
> 3 files changed, 29 insertions(+)
>
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index 589e5efc2d7f..2626fc0b5b8c 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -262,6 +262,29 @@ static void sec_pmic_dump_rev(struct sec_pmic_dev
> *sec_pmic)
> dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
> }
>
> +static void sec_pmic_configure(struct sec_pmic_dev *sec_pmic)
> +{
> + int err;
> +
> + if (sec_pmic->device_type != S2MPS13X)
> + return;
> +
> + if (sec_pmic->pdata->disable_wrstbi) {
> + /*
> + * If WRSTBI pin is pulled down this feature must be disabled
> + * because each Suspend to RAM will trigger buck voltage reset
> + * to default values.
> + */
> + err = regmap_update_bits(sec_pmic->regmap_pmic,
> + S2MPS13_REG_WRSTBI,
> + S2MPS13_REG_WRSTBI_MASK, 0x0);
> + if (err)
> + dev_warn(sec_pmic->dev,
> + "Cannot initialize WRSTBI config: %d\n",
> + err);
> + }
> +}
> +
> #ifdef CONFIG_OF
> /*
> * Only the common platform data elements for s5m8767 are parsed here from
> the
> @@ -289,6 +312,8 @@ static struct sec_platform_data
> *sec_pmic_i2c_parse_dt_pdata(
>
> pd->manual_poweroff = of_property_read_bool(dev->of_node,
> "samsung,s2mps11-acokb-ground");
> + pd->disable_wrstbi = of_property_read_bool(dev->of_node,
> +
> "samsung,s2mps11-wrstbi-ground");
> return pd;
> }
> #else
> @@ -434,6 +459,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> goto err_mfd;
>
> device_init_wakeup(sec_pmic->dev, sec_pmic->wakeup);
> + sec_pmic_configure(sec_pmic);
> sec_pmic_dump_rev(sec_pmic);
>
> return ret;
> diff --git a/include/linux/mfd/samsung/core.h
> b/include/linux/mfd/samsung/core.h
> index aa78957e092f..a06098639399 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -134,6 +134,8 @@ struct sec_platform_data {
> int buck4_init;
> /* Whether or not manually set PWRHOLD to low during shutdown. */
> boolmanual_poweroff;
> + /* Disable the WRSTBI (buck voltage warm reset) when probing? */
> + booldisable_wrstbi;
> };
>
> /**
> diff --git a/include/linux/mfd/samsung/s2mps13.h
> b/include/linux/mfd/samsung/s2mps13.h
> index b1fd675fa36f..239e977ba45d 100644
> --- a/include/linux/mfd/samsung/s2mps13.h
> +++ b/include/linux/mfd/samsung/s2mps13.h
> @@ -184,5 +184,6 @@ enum s2mps13_regulators {
> * Let's assume that default value will be set.
> */
> #define S2MPS13_BUCK_RAMP_DELAY 12500
> +#define S2MPS13_REG_WRSTBI_MASK BIT(5)
>
> #endif /* __LINUX_MFD_S2MPS13_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] mfd: sec-core: Dump PMIC revision to find out the HW
On Wed, 07 Oct 2015, Krzysztof Kozlowski wrote:
> There are different revisions of the same chipset. For example S2MPS13 has
> more than 2 revisions. They differ slightly in regulator constraints.
> Print the revision number to easily find which PMIC is used on the board.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changs since v1:
> None.
> ---
> drivers/mfd/sec-core.c | 10 ++
> 1 file changed, 10 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index 2d1137a7a0ee..589e5efc2d7f 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -253,6 +253,15 @@ static const struct regmap_config s5m8767_regmap_config
> = {
> .cache_type = REGCACHE_FLAT,
> };
>
> +static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
> +{
> + unsigned int val;
> +
> + /* For each device type, the REG_ID is always the first register */
> + if (!regmap_read(sec_pmic->regmap_pmic, S2MPS11_REG_ID, &val))
> + dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
> +}
> +
> #ifdef CONFIG_OF
> /*
> * Only the common platform data elements for s5m8767 are parsed here from
> the
> @@ -425,6 +434,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> goto err_mfd;
>
> device_init_wakeup(sec_pmic->dev, sec_pmic->wakeup);
> + sec_pmic_dump_rev(sec_pmic);
>
> return ret;
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] sched/fair: Update task group's load_avg after task migrate
When cfs_rq has removed_load_avg (when task migrates from this cfs_rq),
we need to update its contribution to the group's load_avg. This should
not increase tg's update too much, because in most of the cases, the
cfs_rq has already decayed load_avg.
Signed-off-by: Yuyang Du
---
kernel/sched/fair.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 601a253..824aa9f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2686,12 +2686,13 @@ static inline u64 cfs_rq_clock_task(struct cfs_rq
*cfs_rq);
static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
{
struct sched_avg *sa = &cfs_rq->avg;
- int decayed;
+ int decayed, removed = 0;
if (atomic_long_read(&cfs_rq->removed_load_avg)) {
long r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
sa->load_avg = max_t(long, sa->load_avg - r, 0);
sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
+ removed = 1;
}
if (atomic_long_read(&cfs_rq->removed_util_avg)) {
@@ -2708,7 +2709,7 @@ static inline int update_cfs_rq_load_avg(u64 now, struct
cfs_rq *cfs_rq)
cfs_rq->load_last_update_time_copy = sa->last_update_time;
#endif
- return decayed;
+ return decayed || removed;
}
/* Update task and its cfs_rq load average */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] sched: make fair sched class can handle the cgroup change by other class
On Mon, Oct 05, 2015 at 06:16:23PM +0900, byungchul.p...@lge.com wrote: > From: Byungchul Park > > Original fair sched class can handle the cgroup change occured within its > class with task_move_group_fair(), but there is no way to know it if the > change happened outside. This patch makes the fair sched class can handle > the change of cgroup which happened even at other sched class. > > Additionally, it makes sched_move_task() more flexable so that any other > sched class can add task_move_group_xx() callback easily in future when > it is needed. I don't get the problem... when !fair, set_task_rq() will do what needs doing. The only reason we need task_move_group_fair() is the extra accounting required when we actually _are_ of the fair class, it needs to unaccount, move and reaccount. If we're not fair, the whole switched_from/to stuff should do that for us, no? So please explain the problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
