[PATCH 1/1] drivers/vga: check decodes for vgaarb lock/unlock
There is a bug that X windows system may use an invalid decodes iostat
on the VGA Arbiter device when lock and unlock. this may cause system
crash. So we must validate the value of iostat.
Signed-off-by: Li, Zhen-Hua
---
drivers/gpu/vga/vgaarb.c | 55
1 file changed, 37 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index af02597..4772367 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -906,8 +906,9 @@ static ssize_t vga_arb_write(struct file *file, const char
__user * buf,
struct vga_arb_private *priv = file->private_data;
struct vga_arb_user_card *uc = NULL;
struct pci_dev *pdev;
+ struct vga_device *vgadev = NULL;
- unsigned int io_state;
+ unsigned int io_state = 0;
char *kbuf, *curr_pos;
size_t remaining = count;
@@ -927,6 +928,19 @@ static ssize_t vga_arb_write(struct file *file, const char
__user * buf,
curr_pos = kbuf;
kbuf[count] = '\0'; /* Just to make sure... */
+ pdev = priv->target;
+ if (priv->target == NULL) {
+ pr_debug("No device found");
+ ret_val = -ENODEV;
+ goto done;
+ }
+ vgadev = vgadev_find(pdev);
+ if (vgadev == NULL) {
+ pr_debug("Could not find vga device for %s", pci_name(pdev));
+ ret_val = -ENODEV;
+ goto done;
+ }
+
if (strncmp(curr_pos, "lock ", 5) == 0) {
curr_pos += 5;
remaining -= 5;
@@ -937,14 +951,15 @@ static ssize_t vga_arb_write(struct file *file, const
char __user * buf,
ret_val = -EPROTO;
goto done;
}
- if (io_state == VGA_RSRC_NONE) {
+ if ((vgadev->owns & io_state) != io_state) {
+ pr_debug("iostate (%x and %x ) do not match",
+ io_state, vgadev->owns);
+
ret_val = -EPROTO;
goto done;
}
-
- pdev = priv->target;
- if (priv->target == NULL) {
- ret_val = -ENODEV;
+ if (io_state == VGA_RSRC_NONE) {
+ ret_val = -EPROTO;
goto done;
}
@@ -969,14 +984,21 @@ static ssize_t vga_arb_write(struct file *file, const
char __user * buf,
pr_debug("client 0x%p called 'unlock'\n", priv);
- if (strncmp(curr_pos, "all", 3) == 0)
+ if (strncmp(curr_pos, "all", 3) == 0) {
io_state = VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM;
- else {
+ } else {
if (!vga_str_to_iostate
(curr_pos, remaining, &io_state)) {
ret_val = -EPROTO;
goto done;
}
+ if ((vgadev->owns & io_state) != io_state) {
+ pr_debug("iostate (%x and %x ) do not match",
+ io_state, vgadev->owns);
+
+ ret_val = -EPROTO;
+ goto done;
+ }
/* TODO: Add this?
if (io_state == VGA_RSRC_NONE) {
ret_val = -EPROTO;
@@ -985,11 +1007,6 @@ static ssize_t vga_arb_write(struct file *file, const
char __user * buf,
*/
}
- pdev = priv->target;
- if (priv->target == NULL) {
- ret_val = -ENODEV;
- goto done;
- }
for (i = 0; i < MAX_USER_CARDS; i++) {
if (priv->cards[i].pdev == pdev)
uc = &priv->cards[i];
@@ -1029,6 +1046,13 @@ static ssize_t vga_arb_write(struct file *file, const
char __user * buf,
ret_val = -EPROTO;
goto done;
}
+ if ((vgadev->owns & io_state) != io_state) {
+ pr_debug("iostate (%x and %x ) do not match",
+ io_state, vgadev->owns);
+
+ ret_val = -EPROTO;
+ goto done;
+ }
/* TODO: Add this?
if (io_state == VGA_RSRC_NONE) {
ret_val = -EPROTO;
@@ -1036,11 +1060,6 @@ static ssize_t vga_arb_write(struct file *file, const
char __user * buf,
}
*/
- pdev = priv->target;
- if (priv->target == NULL) {
- ret_val = -ENODEV;
- goto done;
- }
if (vga_tryget(pdev, io_state)) {
[PATCH] m68k/atari: Call paging_init() before nf_init()
nf_init() uses virt_to_phys(), which depends on m68k_memoffset being set and
module_fixup() having been called, but this is only done in paging_init().
Hence call paging_init() before nf_init().
This went unnoticed, as virt_to_phys() is a no-op on Atari, unless you start
fiddling with the memory blocks in the bootinfo manually.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/kernel/setup_mm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 99cfe0577ad0..5b8ec4d5f8e8 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -348,12 +348,12 @@ void __init setup_arch(char **cmdline_p)
panic("No configuration setup");
}
+ paging_init();
+
#ifdef CONFIG_NATFEAT
nf_init();
#endif
- paging_init();
-
#ifndef CONFIG_SUN3
for (i = 1; i < m68k_num_memory; i++)
free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: Rusty Russell Date: Fri, 18 Oct 2013 16:47:14 +1030 > Do you want awk script to turn the latter into the former? Would that > really help? Rusty in the several years I've been operating this way, you're the first person who seems to mind it. To be honest I sometimes just silently deal with the stable CC:, but it's much easier if things operate as they do now, and the burdon is on the submitter instead of me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: trace-cmd problem with FC19
On 10/17/2013 11:11 PM, Bob Copeland wrote: On Thu, Oct 17, 2013 at 04:56:56PM -0400, Steven Rostedt wrote: Hmm, are you sure? You may want to do both: sudo trace-cmd -v which trace-cmd Aaargh, bullocks! My home dir is an NFS mount on FC19 x64 machine and it has a 32-bit trace-cmd installed in ~/bin. Sorry for the noise. to see which version it is. To clarify - I ran into the referenced issue using an older, self-compiled version with a recent kernel. The FC19 distro version may be fine, for all I know. Indeed saw your post googling for this error message, which is why I cloned trace-cmd repo. Going to sit in a corner feeling stupid :-( Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: phy: omap: Add omap-control Support for AM437x
On 10/15/2013 01:02 PM, George Cherian wrote:
> This adds omap control module support for USBSS in AM437x SoC.
> Update DT binding information to reflect these changes.
>
> Signed-off-by: George Cherian
Acked-by: Roger Quadros
> ---
> Changes from v1:
> Make ON and OFF operations symmetric.
>
> Documentation/devicetree/bindings/usb/omap-usb.txt | 2 ++
> drivers/usb/phy/phy-omap-control.c | 19 +++
> include/linux/usb/omap_control_usb.h | 6 ++
> 3 files changed, 27 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 090e5e2..c495135 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -87,6 +87,8 @@ Required properties:
> e.g. USB3 PHY and SATA PHY on OMAP5.
> "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
> DRA7 platform.
> + "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on
> + AM437 platform.
> - reg : Address and length of the register set for the device. It contains
> the address of "otghs_control" for control-phy-otghs or "power" register
> for other types.
> diff --git a/drivers/usb/phy/phy-omap-control.c
> b/drivers/usb/phy/phy-omap-control.c
> index 09c5ace..e725318 100644
> --- a/drivers/usb/phy/phy-omap-control.c
> +++ b/drivers/usb/phy/phy-omap-control.c
> @@ -84,6 +84,20 @@ void omap_control_usb_phy_power(struct device *dev, int on)
> else
> val |= OMAP_CTRL_USB2_PHY_PD;
> break;
> +
> + case OMAP_CTRL_TYPE_AM437USB2:
> + if (on) {
> + val &= ~(AM437X_CTRL_USB2_PHY_PD |
> + AM437X_CTRL_USB2_OTG_PD);
> + val |= (AM437X_CTRL_USB2_OTGVDET_EN |
> + AM437X_CTRL_USB2_OTGSESSEND_EN);
> + } else {
> + val &= ~(AM437X_CTRL_USB2_OTGVDET_EN |
> + AM437X_CTRL_USB2_OTGSESSEND_EN);
> + val |= (AM437X_CTRL_USB2_PHY_PD |
> + AM437X_CTRL_USB2_OTG_PD);
> + }
> + break;
> default:
> dev_err(dev, "%s: type %d not recognized\n",
> __func__, control_usb->type);
> @@ -197,6 +211,7 @@ static const enum omap_control_usb_type otghs_data =
> OMAP_CTRL_TYPE_OTGHS;
> static const enum omap_control_usb_type usb2_data = OMAP_CTRL_TYPE_USB2;
> static const enum omap_control_usb_type pipe3_data = OMAP_CTRL_TYPE_PIPE3;
> static const enum omap_control_usb_type dra7usb2_data =
> OMAP_CTRL_TYPE_DRA7USB2;
> +static const enum omap_control_usb_type am437usb2_data =
> OMAP_CTRL_TYPE_AM437USB2;
>
> static const struct of_device_id omap_control_usb_id_table[] = {
> {
> @@ -215,6 +230,10 @@ static const struct of_device_id
> omap_control_usb_id_table[] = {
> .compatible = "ti,control-phy-dra7usb2",
> .data = &dra7usb2_data,
> },
> + {
> + .compatible = "ti,control-phy-am437usb2",
> + .data = &am437usb2_data,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, omap_control_usb_id_table);
> diff --git a/include/linux/usb/omap_control_usb.h
> b/include/linux/usb/omap_control_usb.h
> index 596b019..69ae383 100644
> --- a/include/linux/usb/omap_control_usb.h
> +++ b/include/linux/usb/omap_control_usb.h
> @@ -24,6 +24,7 @@ enum omap_control_usb_type {
> OMAP_CTRL_TYPE_USB2,/* USB2_PHY, power down in CONTROL_DEV_CONF */
> OMAP_CTRL_TYPE_PIPE3, /* PIPE3 PHY, DPLL & seperate Rx/Tx power */
> OMAP_CTRL_TYPE_DRA7USB2, /* USB2 PHY, power and power_aux e.g. DRA7 */
> + OMAP_CTRL_TYPE_AM437USB2, /* USB2 PHY, power e.g. AM437x */
> };
>
> struct omap_control_usb {
> @@ -64,6 +65,11 @@ enum omap_control_usb_mode {
>
> #define OMAP_CTRL_USB2_PHY_PDBIT(28)
>
> +#define AM437X_CTRL_USB2_PHY_PD BIT(0)
> +#define AM437X_CTRL_USB2_OTG_PD BIT(1)
> +#define AM437X_CTRL_USB2_OTGVDET_EN BIT(19)
> +#define AM437X_CTRL_USB2_OTGSESSEND_EN BIT(20)
> +
> #if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
> extern void omap_control_usb_phy_power(struct device *dev, int on);
> extern void omap_control_usb_set_mode(struct device *dev,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] static_key: flush rate limit timer on rmmod
2013-10-17 12:35+0200, Paolo Bonzini:
> Il 17/10/2013 12:10, Radim Krčmář ha scritto:
> > Fix a bug when we free module memory while timer is pending by marking
> > deferred static keys and flushing the timer on module unload.
> >
> > Also make static_key_rate_limit() useable more than once.
> >
> > Reproducer: (host crasher)
> > modprobe kvm_intel
> > (sleep 1; echo quit) \
> > | qemu-kvm -kernel /dev/null -monitor stdio &
> > sleep 0.5
> > until modprobe -rv kvm_intel 2>/dev/null; do true; done
> > modprobe -v kvm_intel
> >
> > Signed-off-by: Radim Krčmář
> > ---
> > Very hacky; I've already queued generalizing ratelimit and applying it
> > here, but there is still a lot to do on static keys ...
> >
> > include/linux/jump_label.h | 1 +
> > kernel/jump_label.c| 17 -
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> > index a507907..848bd15 100644
> > --- a/include/linux/jump_label.h
> > +++ b/include/linux/jump_label.h
> > @@ -58,6 +58,7 @@ struct static_key {
> > #ifdef CONFIG_MODULES
> > struct static_key_mod *next;
> > #endif
> > + atomic_t deferred;
> > };
> >
> > # include
> > diff --git a/kernel/jump_label.c b/kernel/jump_label.c
> > index 297a924..7018042 100644
> > --- a/kernel/jump_label.c
> > +++ b/kernel/jump_label.c
> > @@ -116,8 +116,9 @@ EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
> > void jump_label_rate_limit(struct static_key_deferred *key,
> > unsigned long rl)
> > {
> > + if (!atomic_xchg(&key->key.deferred, 1))
> > + INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
>
> Can it actually happen that jump_label_rate_limit is called multiple
> times? If so, this hunk alone would be a separate bugfix. I don't
> think all the concurrency that you're protecting against can actually
> happen, but in any case I'd just take the jump_label_lock() instead of
> using atomics.
It can't happen in current code and it is highly unlikely to happen in
future too.
There was no reason to take the lock, so I didn't, but we could use bool
in struct then ... I'll do it, even though it has more lines of code, it
is probably easier to understand.
> It's also not necessary to use a new field, since you can just check
> key->timeout.
The flush is done automatically and we don't know if the jump_entry
belongs to deferred key, so we shouldn't just blindly try.
(another bit to jump_entry flags would supply enough information, but we
haven't decided if we want to optimize them into pointers and there
isn't much space in them + they were introduced in patch [5/7])
> All this gives something like this for static_key_rate_limit_flush:
>
> if (key->timeout) {
> jump_label_lock();
> if (key->enabled) {
> jump_label_unlock();
> flush_delayed_work(&dkey->work);
> } else
> jump_label_unlock();
> }
Ugh, I see a problem in original patch now: I changed it from
cancel_delayed_work() in the module that owns this key shortly before
posting, because it could still bug then and forgot it isn't good to
take jump_label_lock() a second time, which would be done in the flush.
This needs be solved by checking if we are the last module that uses
this key and issuing a cancel() then and I'm not sure it would not still
bug yet -- the work could already be running, just waiting for
jump_label_lock() we would then somehow manage to free the memory first.
(leaving it to programmer starts to look sane ...)
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] m68k/atari: Call paging_init() before nf_init()
Geert,
does your fiddling with memory blocks in bootinfo now result in kernels
being possible to boot in FastRAM?
Cheers,
Michael
nf_init() uses virt_to_phys(), which depends on m68k_memoffset being
set and
module_fixup() having been called, but this is only done in
paging_init().
Hence call paging_init() before nf_init().
This went unnoticed, as virt_to_phys() is a no-op on Atari, unless you
start
fiddling with the memory blocks in the bootinfo manually.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/kernel/setup_mm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 99cfe0577ad0..5b8ec4d5f8e8 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -348,12 +348,12 @@ void __init setup_arch(char **cmdline_p)
panic("No configuration setup");
}
+ paging_init();
+
#ifdef CONFIG_NATFEAT
nf_init();
#endif
- paging_init();
-
#ifndef CONFIG_SUN3
for (i = 1; i < m68k_num_memory; i++)
free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k"
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 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x
On Friday 18 October 2013 11:50 AM, NeilBrown wrote:
On Sat, 5 Oct 2013 13:17:09 +0200 Andreas Fenkart wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard detection of the module block otherwise.
Signed-off-by: Andreas Fenkart
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to set
+named pinctrl states "default", "active" and "idle ", see example below. The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,
--
| PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins = <
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ >;
+ };
+
+ mmc1: mmc@4806 {
+ ti,non-removable;
+ bus-width = <4>;
+ vmmc-supply = <&ldo2_reg>;
+ vmmc_aux-supply = <&vmmc>;
+ ti,quirk-swakeup-missing;
+ pinctrl-names = "default", "active", "idle";
+ pinctrl-0 = <&mmc1_pins>;
+ pinctrl-1 = <&mmc1_pins>;
+ pinctrl-2 = <&mmc1_cirq_pin>;
+ ti,cirq-gpio = <&gpio3 28 0>;
+ };
hi,
I've been trying to get SD irq to work on my OMAP3 DM3730.
I seems to need the magic to catch interrupts while FCLK is off, as
the only way I can get it to work at the moment is to keep FCLK on.
I discovered your patch and tried it out, but it doesn't seem to work for me.
I have a Libertas WIFI chip attached to the second mmc (which is sometimes
called mmc1, and sometimes mmc2 - very confusing!).
I added:
mmc2_cirq_pin: pinmux_cirq_pin {
pinctrl-single,pins = <
0x012e (PIN_INPUT_PULLUP | MUX_MODE4) /* MMC2_DAT1 as
GPIO5_5 */
>;
};
and
&mmc2 {
ti,quirk-swakeup-missing;
pinctrl-names = "default", "active", "idle";
pinctrl-0 = <&mmc2_pins>;
pinctrl-1 = <&mmc2_pins>;
pinctrl-2 = <&mmc2_cirq_pin>;
ti,cirq-gpio = <&gpio5 5 0>; /* GPIO133 = 128+5 */
};
to my dts file but it doesn't make any apparent difference.
Any idea what I might be doing wrong?
(the base kernel I am applying patches to is from 8th Oct,
commit 0e7a3ed04f0cd4311096d691888f88569310ee6c)
BTW,
- with the default polling, I get about 1Mb/sec with iperf
- with sd-irq enabled and FCLK kept on the whole time, I get 4Mb/sec
- with sd-irq enable, FCLK kept on, and the 5ms polling also
running, I get over 5Mb/sec!
Still much less than the 40Mb/sec that I would like to get...
(removing svenk...@ti.com)
Hi,
Can you check if you have bus-width property set ?
bus-width = <4>;
Thanks and Regards,
Balaji T K
Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] ata: ahci_platform: Manage SATA PHY
On 10/17/2013 04:57 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, October 16, 2013 02:42:52 PM Roger Quadros wrote:
>> From: Balaji T K
>>
>> Some platforms have a PHY hooked up to the
>> SATA controller. The PHY needs to be initialized
>> and powered up for SATA to work. We do that
>> using the PHY framework.
>>
>> [Roger Q] Cleaned up.
>>
>> CC: Tejun Heo
>> Signed-off-by: Balaji T K
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/ata/ahci-platform.txt |3 +-
>> drivers/ata/ahci.h |2 ++
>> drivers/ata/ahci_platform.c| 29
>> +++-
>> 3 files changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> b/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> index 89de156..c8a6cea 100644
>> --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> @@ -4,7 +4,8 @@ SATA nodes are defined to describe on-chip Serial ATA
>> controllers.
>> Each SATA controller should have its own node.
>>
>> Required properties:
>> -- compatible: compatible list, contains "snps,spear-ahci"
>> +- compatible: compatible list, contains "snps,spear-ahci",
>> +snps,exynos5440-ahci or "snps,dwc-ahci"
>
> minor nit:
> s/snps,exynos5440-ahci/"snps,exynos5440-ahci"/
OK.
>
>> - interrupts:
>> - reg :
>>
>> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
>> index 1145637..94484cb 100644
>> --- a/drivers/ata/ahci.h
>> +++ b/drivers/ata/ahci.h
>> @@ -37,6 +37,7 @@
>>
>> #include
>> #include
>> +#include
>>
>> /* Enclosure Management Control */
>> #define EM_CTRL_MSG_TYPE 0x000f
>> @@ -322,6 +323,7 @@ struct ahci_host_priv {
>> u32 em_buf_sz; /* EM buffer size in byte */
>> u32 em_msg_type;/* EM message type */
>> struct clk *clk; /* Only for platforms
>> supporting clk */
>> +struct phy *phy; /* If platforms use phy */
>
> minor nit:
> s/If platforms use phy/If platform uses PHY/
Right.
>
>> void*plat_data; /* Other platform data */
>> };
>>
>> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
>> index 2daaee0..5a0f1418 100644
>> --- a/drivers/ata/ahci_platform.c
>> +++ b/drivers/ata/ahci_platform.c
>> @@ -141,6 +141,21 @@ static int ahci_probe(struct platform_device *pdev)
>> }
>> }
>>
>> +hpriv->phy = devm_phy_get(dev, "sata-phy");
>> +if (IS_ERR(hpriv->phy)) {
>> +dev_dbg(dev, "can't get sata-phy\n");
>> +/* return only if -EPROBE_DEFER */
>> +if (PTR_ERR(hpriv->phy) == -EPROBE_DEFER) {
>> +rc = -EPROBE_DEFER;
>> +goto disable_unprepare_clk;
>> +}
>> +}
>> +
>> +if (!IS_ERR(hpriv->phy)) {
>> +phy_init(hpriv->phy);
>> +phy_power_on(hpriv->phy);
>> +}
>> +
>> /*
>> * Some platforms might need to prepare for mmio region access,
>> * which could be done in the following init call. So, the mmio
>> @@ -150,7 +165,7 @@ static int ahci_probe(struct platform_device *pdev)
>> if (pdata && pdata->init) {
>> rc = pdata->init(dev, hpriv->mmio);
>> if (rc)
>> -goto disable_unprepare_clk;
>> +goto disable_phy;
>> }
>>
>> ahci_save_initial_config(dev, hpriv,
>> @@ -220,6 +235,12 @@ static int ahci_probe(struct platform_device *pdev)
>> pdata_exit:
>> if (pdata && pdata->exit)
>> pdata->exit(dev);
>> +disable_phy:
>> +if (!IS_ERR(hpriv->phy)) {
>> +phy_power_off(hpriv->phy);
>> +phy_exit(hpriv->phy);
>> +}
>> +
>> disable_unprepare_clk:
>> if (!IS_ERR(hpriv->clk))
>> clk_disable_unprepare(hpriv->clk);
>> @@ -238,6 +259,11 @@ static void ahci_host_stop(struct ata_host *host)
>> if (pdata && pdata->exit)
>> pdata->exit(dev);
>>
>> +if (!IS_ERR(hpriv->phy)) {
>> +phy_power_off(hpriv->phy);
>> +phy_exit(hpriv->phy);
>> +}
>> +
>> if (!IS_ERR(hpriv->clk)) {
>> clk_disable_unprepare(hpriv->clk);
>> clk_put(hpriv->clk);
>> @@ -328,6 +354,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend,
>> ahci_resume);
>
> Shouldn't phy_power_off/on also be used in ahci_suspend() and ahci_resume()?
I think so. Maybe even phy_exit and phy_init?
>
>> static const struct of_device_id ahci_of_match[] = {
>> { .compatible = "snps,spear-ahci", },
>> { .compatible = "snps,exynos5440-ahci", },
>> +{ .compatible = "snps,dwc-ahci", },
>
> This change together with ahci-platform.txt one should be in a separate patch.
Agreed.
>
Re: [PATCH 4/7] static_key: use static_key_slow_inc_deferred()
2013-10-17 12:39+0200, Paolo Bonzini: > Il 17/10/2013 12:10, Radim Krčmář ha scritto: > > Simple replacement where possible. > > Saves us problematic access to the structure and allows optimalizations > > and bug fixes to take place. > > I think you should introduce this first as a simple wrapper around > static_key_slow_inc, and then add the bells and whistles you have in > patches 2 and 3. Ok, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] jump_label: relax branch hinting restrictions
2013-10-17 13:35-0400, Steven Rostedt:
> On Thu, 17 Oct 2013 12:10:28 +0200
> Radim Krčmář wrote:
>
> > We implemented the optimized branch selection in higher levels of api.
> > That made static_keys very unintuitive, so this patch introduces another
> > element to jump_table, carrying one bit that tells the underlying code
> > which branch to optimize.
> >
> > It is now possible to select optimized branch for every jump_entry.
> >
> > Current side effect is 1/3 increase increase in space, we could:
> > * use bitmasks and selectors on 2+ aligned code/struct.
> > - aligning jump target is easy, but because it is not done by default
> > and few bytes in .text are much worse that few kilos in .data,
> > I chose not to
> > - data is probably aligned by default on all current architectures,
> > but programmer can force misalignment of static_key
> > * optimize each architecture independently
> > - I can't test everything and this patch shouldn't break anything, so
> > others can contribute in the future
> > * choose something worse, like packing or splitting
> > * ignore
> >
> > proof: example & x86_64 disassembly: (F = )
> >
> > struct static_key flexible_feature;
> > noinline void jump_label_experiment(void) {
> > if ( static_key_false(&flexible_feature))
> > asm ("push 0xa1");
> > else asm ("push 0xa0");
> > if (!static_key_false(&flexible_feature))
> > asm ("push 0xb0");
> > else asm ("push 0xb1");
> > if ( static_key_true(&flexible_feature))
> > asm ("push 0xc1");
> > else asm ("push 0xc0");
> > if (!static_key_true(&flexible_feature))
> > asm ("push 0xd0");
> > else asm ("push 0xd1");
> > }
> >
> > Disassembly of section .text: (push marked by "->")
> >
> > F81002000 :
> > F81002000: e8 7b 29 75 00 callq F81754980 <__fentry__>
> > F81002005: 55 push %rbp
> > F81002006: 48 89 e5mov%rsp,%rbp
> > F81002009: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F8100200e: ->ff 34 25 a0 00 00 00pushq 0xa0
> > F81002015: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F8100201a: ->ff 34 25 b0 00 00 00pushq 0xb0
> > F81002021: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F81002026: ->ff 34 25 c1 00 00 00pushq 0xc1
> > F8100202d: 0f 1f 00nopl (%rax)
> > F81002030: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > F81002035: ->ff 34 25 d1 00 00 00pushq 0xd1
> > F8100203c: 5d pop%rbp
> > F8100203d: 0f 1f 00nopl (%rax)
> > F81002040: c3 retq
>
> This looks exactly like what we want. I take it this is with your
> patch. What was the result before the patch?
Yes, this is after the patch.
The branches would (should) be the same without patch, but
static_key_true() was defined as !static_key_false(), so this piece of
code was invalid before, because half of them would be patched to use
the wrong branch.
> -- Steve
>
> > F81002041: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
> > F81002048: ->ff 34 25 d0 00 00 00pushq 0xd0
> > F8100204f: 5d pop%rbp
> > F81002050: c3 retq
> > F81002051: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
> > F81002058: ->ff 34 25 c0 00 00 00pushq 0xc0
> > F8100205f: 90 nop
> > F81002060: eb cb jmpF8100202d <[...]+0x2d>
> > F81002062: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
> > F81002068: ->ff 34 25 b1 00 00 00pushq 0xb1
> > F8100206f: 90 nop
> > F81002070: eb af jmpF81002021 <[...]+0x21>
> > F81002072: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
> > F81002078: ->ff 34 25 a1 00 00 00pushq 0xa1
> > F8100207f: 90 nop
> > F81002080: eb 93 jmpF81002015 <[...]+0x15>
> > F81002082: 66 66 66 66 66 2e 0f[...]
> > F81002089: 1f 84 00 00 00 00 00
> >
> > Contents of section .data: (relevant part of embedded __jump_table)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: honor ACPI FADT flag indicating absence of a CMOS RTC
>>> On 18.10.13 at 08:29, Ingo Molnar wrote: > * Jan Beulich wrote: > >> We shouldn't be creating a corresponding platform device in that case. > > There's a sad lack of context in the changelog, how was it found, does > this address any problem/bug observed in practice, etc? This was a result from code review in Xen hypervisor code in the context of ACPI 5 work there, which lead me to check whether Linux would honor that flag. No known issue in practice so far. Once the below got clarified, I can certainly extend the description in an eventual resubmission (albeit I would have though that fixing the not honoring of a firmware flag should speak for itself). >> +#ifdef CONFIG_ACPI >> +if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) >> +return -ENODEV; >> +#endif > > It might also be prudent to emit a KERN_INFO line telling that we don't > create the device - so that people who suddenly see unexpected breakage or > change in behavior have a chance to see what we've done? There are so many other -ENODEV return paths here which don't emit messages that this seemed inappropriate, the more that a message _is_ being issued if the platform RTC device does get registered (and hence one could judge by the message disappearing between before and after the patch got applied). Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] m68k/atari: Call paging_init() before nf_init()
On Fri, Oct 18, 2013 at 9:29 AM, Michael Schmitz
wrote:
> does your fiddling with memory blocks in bootinfo now result in kernels
> being possible to boot in FastRAM?
No, I only played with the start address of ST-RAM.
Probably you can run a kernel in FastRAM with some minor tweaks if
you remove the ST-RAM block from the bootinfo, but then you loose
(at least) atafb :-)
With the DISCONTIGMEM memory model, the kernel must be stored in the
first memory block. As ST-RAM is before FastRAM in memory, you cannot
have the kernel in FastRAM without losing ST-RAM (as main memory ---
you can still e.g. ioremap() it for atafb, and use the rest of it as
swap through
a block device like z2ram. This is basically what we do on Amiga with Chip RAM
and Z2 RAM).
With the SPARSEMEM memory model, you should be able to store the kernel
in FastRAM and have ST-RAM, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Friday 11 October 2013 09:31 PM, Tony Lindgren wrote: * Linus Walleij [131011 09:05]: On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren wrote: * Linus Walleij [131011 03:40]: On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros wrote: The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Yeah I saw this in the code there. In this case it seems syscon-type regmap access can be used to read/write the registers, so maybe the pin controller also need to get a handle on some clock etc? Uhh, let's not go there.. The resource availability needs to be handled transparently in regmap code and the reg provider hardware module driver using runtime PM. OK we can surely discuss this with broonie, it makes sense to have regmap be able to do its deed transparently. Yes I think so too. Sounds like we need callbacks for the runtime PM checks to the "register provider" driver. Hwo knows, maybe those features are there already :) Hi Tony, Any conclusion on using regmap for omap control module non-mux registers ? Thanks and Regards, Balaji T K -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 17
On Fri, Oct 18, 2013 at 01:38:47AM +0100, Mark Brown wrote: > Hi all, > > I've uploaded today's linux-next tree to the master branch of the > repository below: > > git://gitorious.org/thierryreding/linux-next.git > > A next-20131017 tag is also provided for convenience. > > One new conflict today but otherwise uneventful. x86_64 allmodconfigs > build after each merge but no other build tests were done. Hi, I'm seeing a fairly large fallout on boot testing. See http://lists.linaro.org/pipermail/kernel-build-reports/2013-October/000719.html for full list (I need to start providing longer backlogs for failures, the top of the oopses is lost in the email). For example, on dove (SolidRun Cubox) I see: [0.707248] Unable to handle kernel NULL pointer dereference at virtual address 0054 [0.715297] pgd = c0004000 [0.717984] [0054] *pgd= [0.721548] Internal error: Oops: 5 [#1] ARM [0.725794] Modules linked in: [0.728841] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc5-next-20131017 #1 [0.736114] task: ef035c00 ti: ef036000 task.ti: ef036000 [0.741497] PC is at kfree+0x54/0xc4 [0.745063] LR is at ata_host_register+0x3c/0x290 [0.749741] pc : []lr : []psr: 4193 [0.749741] sp : ef037da8 ip : 0034 fp : [0.761159] r10: r9 : ef061810 r8 : c0519fc8 [0.766353] r7 : c0519fc8 r6 : a113 r5 : r4 : ef1c9dd0 [0.772850] r3 : c0fc8fe0 r2 : c07c9000 r1 : 4000 r0 : [0.779349] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [0.786708] Control: 10c5387d Table: 4019 DAC: 0015 [0.792428] Process swapper (pid: 1, stack limit = 0xef036248) [0.798234] Stack: (0xef037da8 to 0xef038000) [0.957218] [] (kfree+0x54/0xc4) from [] (ata_host_register+0x3c/0x290) [0.965542] [] (ata_host_register+0x3c/0x290) from [] (ata_host_activate+0xdc/0x118) [0.974992] [] (ata_host_activate+0xdc/0x118) from [] (mv_platform_probe+0x2dc/0x36c) [0.984527] [] (mv_platform_probe+0x2dc/0x36c) from [] (platform_drv_probe+0x18/0x48) [0.994051] [] (platform_drv_probe+0x18/0x48) from [] (really_probe+0x74/0x1fc) [1.003062] [] (really_probe+0x74/0x1fc) from [] (__driver_attach+0x98/0x9c) [1.011804] [] (__driver_attach+0x98/0x9c) from [] (bus_for_each_dev+0x60/0x94) [1.020808] [] (bus_for_each_dev+0x60/0x94) from [] (bus_add_driver+0x148/0x1f0) [1.029898] [] (bus_add_driver+0x148/0x1f0) from [] (driver_register+0x78/0xf8) [1.038911] [] (driver_register+0x78/0xf8) from [] (mv_init+0x30/0x50) [1.047144] [] (mv_init+0x30/0x50) from [] (do_one_initcall+0x100/0x14c) [1.07] [] (do_one_initcall+0x100/0x14c) from [] (kernel_init_freeable+0x120/0x1c0) [1.065259] [] (kernel_init_freeable+0x120/0x1c0) from [] (kernel_init+0x8/0x158) [1.074441] [] (kernel_init+0x8/0x158) from [] (ret_from_fork+0x14/0x3c) [1.082841] Code: e0823283 e3110902 1593301c e593001c (e5904054) I bisected it down to commit 55acc602faae7c10e53acdca0c70f4936c2539c6, which is really weird. That is: commit 55acc602faae7c10e53acdca0c70f4936c2539c6 Merge: e32face ba6857b Author: Mark Brown AuthorDate: Thu Oct 17 23:55:55 2013 +0100 Commit: Mark Brown CommitDate: Thu Oct 17 23:55:55 2013 +0100 Merge remote-tracking branch 'driver-core/driver-core-next' Conflicts: include/linux/netdevice.h But there isn't anything controversial in the merge commit. I tried checking out either side of that merge, and they both boot fine. I redid the merge myself, and I get no delta compared to your merge and I still get the same failure. I've got more failures than dove, I'll try bisecting a few of the others in the morning (it's late here), hopefully they will help indicate what's actually going wrong. I'm guessing something just happens to move around enough to expose a different problem once the two branches are merged. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x
On Fri, 18 Oct 2013 12:59:56 +0530 Balaji T K wrote:
> On Friday 18 October 2013 11:50 AM, NeilBrown wrote:
> > On Sat, 5 Oct 2013 13:17:09 +0200 Andreas Fenkart
> > wrote:
> >
> >> The am335x can't detect pending cirq in PM runtime suspend.
> >> This patch reconfigures dat1 as a GPIO before going to suspend.
> >> SDIO interrupts are detected with the GPIO, while in runtime
> >> suspend, standard detection of the module block otherwise.
> >>
> >> Signed-off-by: Andreas Fenkart
> >>
> >> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> >> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> >> index 1136e6b..146f3ad 100644
> >> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> >> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> >> @@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
> >> ti,needs-special-reset: Requires a special softreset sequence
> >> ti,needs-special-hs-handling: HSMMC IP needs special setting for
> >> handling High Speed
> >> ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
> >> -SDIO irq while in suspend. Fallback to polling. Affected chips are
> >> -am335x,
> >> +SDIO irq while in suspend. The workaround is to reconfigure the dat1 line
> >> as a
> >> +GPIO upon suspend. Beyond this option and the GPIO config, you also need
> >> to set
> >> +named pinctrl states "default", "active" and "idle ", see example below.
> >> The
> >> +MMC driver will then then toggle between default and idle during the
> >> runtime
> >> +Affected chips are am335x,
> >>
> >> --
> >> | PRCM |
> >> @@ -49,3 +52,24 @@ Example:
> >>vmmc-supply = <&vmmc>; /* phandle to regulator node */
> >>ti,non-removable;
> >>};
> >> +
> >> +[am335x with with gpio for sdio irq]
> >> +
> >> + mmc1_cirq_pin: pinmux_cirq_pin {
> >> + pinctrl-single,pins = <
> >> + 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
> >> + >;
> >> + };
> >> +
> >> + mmc1: mmc@4806 {
> >> + ti,non-removable;
> >> + bus-width = <4>;
> >> + vmmc-supply = <&ldo2_reg>;
> >> + vmmc_aux-supply = <&vmmc>;
> >> + ti,quirk-swakeup-missing;
> >> + pinctrl-names = "default", "active", "idle";
> >> + pinctrl-0 = <&mmc1_pins>;
> >> + pinctrl-1 = <&mmc1_pins>;
> >> + pinctrl-2 = <&mmc1_cirq_pin>;
> >> + ti,cirq-gpio = <&gpio3 28 0>;
> >> + };
> >
> >
> > hi,
> > I've been trying to get SD irq to work on my OMAP3 DM3730.
> > I seems to need the magic to catch interrupts while FCLK is off, as
> > the only way I can get it to work at the moment is to keep FCLK on.
> >
> > I discovered your patch and tried it out, but it doesn't seem to work for
> > me.
> >
> > I have a Libertas WIFI chip attached to the second mmc (which is sometimes
> > called mmc1, and sometimes mmc2 - very confusing!).
> > I added:
> > mmc2_cirq_pin: pinmux_cirq_pin {
> > pinctrl-single,pins = <
> > 0x012e (PIN_INPUT_PULLUP | MUX_MODE4) /* MMC2_DAT1 as
> > GPIO5_5 */
> > >;
> > };
> >
> > and
> >
> > &mmc2 {
> > ti,quirk-swakeup-missing;
> > pinctrl-names = "default", "active", "idle";
> > pinctrl-0 = <&mmc2_pins>;
> > pinctrl-1 = <&mmc2_pins>;
> > pinctrl-2 = <&mmc2_cirq_pin>;
> > ti,cirq-gpio = <&gpio5 5 0>; /* GPIO133 = 128+5 */
> > };
> >
> > to my dts file but it doesn't make any apparent difference.
> >
> > Any idea what I might be doing wrong?
> > (the base kernel I am applying patches to is from 8th Oct,
> > commit 0e7a3ed04f0cd4311096d691888f88569310ee6c)
> >
> > BTW,
> > - with the default polling, I get about 1Mb/sec with iperf
> > - with sd-irq enabled and FCLK kept on the whole time, I get 4Mb/sec
> > - with sd-irq enable, FCLK kept on, and the 5ms polling also
> > running, I get over 5Mb/sec!
> > Still much less than the 40Mb/sec that I would like to get...
> >
> (removing svenk...@ti.com)
>
> Hi,
>
> Can you check if you have bus-width property set ?
> bus-width = <4>;
>
>
Yes I do.
as well as the settings above I have:
vmmc-supply = <&vaux4>;
bus-width = <4>;
ti,non-removable;
cap-power-off-card;
vaux4 is from a twl4030 and powers the wifi chip.
'cap-power-off-card' I added support for myself to so the card would power
off when not in use.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
On Sun, Sep 22, 2013 at 09:59:56AM -0700, Mike Dunn wrote: > Currently the driver assumes that the values specified in the > brightness-levels device tree property increase as they are parsed from > left to right. But boards that invert the signal between the PWM output > and the backlight will need to specify decreasing brightness-levels. > This patch removes the assumption that the last element of the array is > the maximum value, and instead searches the array for the maximum value > and uses that in the duty cycle calculation. > > Signed-off-by: Mike Dunn > --- > Changelog: > v2: > - commit message reworded; correct line wrap used > - 'max_level' variable renamed to 'scale' > - loop counter variable type changed to unsigned int > - value held in scale changed from array index to actual maximum level > - blank lines added around loop for readability > > drivers/video/backlight/pwm_bl.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) Hey Mike, I've pushed a slightly different version of this patch which gets rid of the intermediate max variable and uses the new scale field exclusively to pass the same information around. Could you look at the patch from my for-next branch in the PWM tree and see whether that still works for the specific hardware that you need this for? Thierry pgpa3EADIxTHH.pgp Description: PGP signature
Re: [PATCH v5 13/17] clk: at91: add PMC usb clock
On 17/10/2013 18:55, Boris BREZILLON :
This patch adds new at91 usb clock implementation using common clk framework.
This clock is used to clock usb ports (ohci, ehci and udc).
Signed-off-by: Boris BREZILLON
Acked-by: Nicolas Ferre
Ok, this one is now replacing the older 13/17.
Thanks Boris.
Bye,
---
arch/arm/mach-at91/Kconfig | 11 ++
drivers/clk/at91/Makefile |1 +
drivers/clk/at91/clk-usb.c | 400
drivers/clk/at91/pmc.c | 15 ++
drivers/clk/at91/pmc.h |9 +
5 files changed, 436 insertions(+)
create mode 100644 drivers/clk/at91/clk-usb.c
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 6ad37da..b76dc4c 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -3,6 +3,9 @@ if ARCH_AT91
config HAVE_AT91_UTMI
bool
+config HAVE_AT91_USB_CLK
+ bool
+
config HAVE_AT91_DBGU0
bool
@@ -82,6 +85,7 @@ config SOC_SAMA5D3
select HAVE_AT91_DBGU1
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's SAMA5D3 family SoC.
This support covers SAMA5D31, SAMA5D33, SAMA5D34, SAMA5D35.
@@ -96,12 +100,14 @@ config SOC_AT91RM9200
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
select AT91_USE_OLD_CLK
+ select HAVE_AT91_USB_CLK
config SOC_AT91SAM9260
bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
select HAVE_AT91_DBGU0
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
or AT91SAM9G20 SoC.
@@ -112,6 +118,7 @@ config SOC_AT91SAM9261
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9261 or
AT91SAM9G10 SoC.
@@ -121,6 +128,7 @@ config SOC_AT91SAM9263
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+ select HAVE_AT91_USB_CLK
config SOC_AT91SAM9RL
bool "AT91SAM9RL"
@@ -137,6 +145,7 @@ config SOC_AT91SAM9G45
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
This support covers AT91SAM9G45, AT91SAM9G46, AT91SAM9M10 and
AT91SAM9M11.
@@ -148,6 +157,7 @@ config SOC_AT91SAM9X5
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+ select HAVE_AT91_USB_CLK
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
This means that your SAM9 name finishes with a '5' (except if it is
@@ -161,6 +171,7 @@ config SOC_AT91SAM9N12
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+ select HAVE_AT91_USB_CLK
help
Select this if you are using Atmel's AT91SAM9N12 SoC.
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index a824883..61db058 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -8,3 +8,4 @@ obj-y += clk-system.o clk-peripheral.o
obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS)+= clk-programmable.o
obj-$(CONFIG_HAVE_AT91_UTMI) += clk-utmi.o
+obj-$(CONFIG_HAVE_AT91_USB_CLK)+= clk-usb.o
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
new file mode 100644
index 000..0454555
--- /dev/null
+++ b/drivers/clk/at91/clk-usb.c
@@ -0,0 +1,400 @@
+/*
+ * drivers/clk/at91/clk-usb.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pmc.h"
+
+#define USB_SOURCE_MAX 2
+
+#define SAM9X5_USB_DIV_SHIFT 8
+#define SAM9X5_USB_MAX_DIV 0xf
+
+#define RM9200_USB_DIV_SHIFT 28
+#define RM9200_USB_DIV_TAB_SIZE4
+
+struct at91sam9x5_clk_usb {
+ struct clk_hw hw;
+ struct at91_pmc *pmc;
+};
+
+#define to_at91sam9x5_clk_usb(hw) \
+ container_of(hw, struct at91sam9x5_clk_usb, hw)
+
+struct at91rm9200_clk_usb {
+ struct clk_hw hw;
+ struct at91_pmc *pmc;
+ u32 divisors[4];
+};
+
+#define to_at91rm9200_clk_usb(hw) \
+ container_of(hw, struct at91rm9200_clk_usb, hw)
+
+static unsigned long at91sam9x5_clk_usb_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 tmp;
+ u8 usbdiv;
+ struct at91sam9x5_clk_usb *usb = to_at9
Re: [PATCH] set data enable logic level to low
On 14/10/13 01:44, Roel Kluin wrote: > Signed-off-by: Roel Kluin > --- > drivers/video/omap2/dss/display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/omap2/dss/display.c > b/drivers/video/omap2/dss/display.c > index fafe7c9..669a81f 100644 > --- a/drivers/video/omap2/dss/display.c > +++ b/drivers/video/omap2/dss/display.c > @@ -266,7 +266,7 @@ void videomode_to_omap_video_timings(const struct > videomode *vm, > OMAPDSS_SIG_ACTIVE_LOW; > ovt->de_level = vm->flags & DISPLAY_FLAGS_DE_HIGH ? > OMAPDSS_SIG_ACTIVE_HIGH : > - OMAPDSS_SIG_ACTIVE_HIGH; > + OMAPDSS_SIG_ACTIVE_LOW; > ovt->data_pclk_edge = vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE ? > OMAPDSS_DRIVE_SIG_RISING_EDGE : > OMAPDSS_DRIVE_SIG_FALLING_EDGE; > Thanks. Next time, please write a patch description and prefix patch subject with appropriate string. In this case "OMAPDSS: ..." would be fine. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/2] vmsplice: unmap gifted pages for recipient
On 10/17/2013 03:48 PM, Robert Jennings wrote:
> * Vlastimil Babka (vba...@suse.cz) wrote:
>> On 10/07/2013 10:21 PM, Robert C Jennings wrote:
>>> Introduce use of the unused SPLICE_F_MOVE flag for vmsplice to zap
>>> pages.
>>>
>>> When vmsplice is called with flags (SPLICE_F_GIFT | SPLICE_F_MOVE) the
>>> writer's gift'ed pages would be zapped. This patch supports further work
>>> to move vmsplice'd pages rather than copying them. That patch has the
>>> restriction that the page must not be mapped by the source for the move,
>>> otherwise it will fall back to copying the page.
>>>
>>> Signed-off-by: Matt Helsley
>>> Signed-off-by: Robert C Jennings
>>> ---
>>> Since the RFC went out I have coalesced the zap_page_range() call to
>>> operate on VMAs rather than calling this for each page. For a 256MB
>>> vmsplice this reduced the write side 50% from the RFC.
>>> ---
>>> fs/splice.c| 51
>>> +-
>>> include/linux/splice.h | 1 +
>>> 2 files changed, 51 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/splice.c b/fs/splice.c
>>> index 3b7ee65..a62d61e 100644
>>> --- a/fs/splice.c
>>> +++ b/fs/splice.c
>>> @@ -188,12 +188,17 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
>>> {
>>> unsigned int spd_pages = spd->nr_pages;
>>> int ret, do_wakeup, page_nr;
>>> + struct vm_area_struct *vma;
>>> + unsigned long user_start, user_end;
>>>
>>> ret = 0;
>>> do_wakeup = 0;
>>> page_nr = 0;
>>> + vma = NULL;
>>> + user_start = user_end = 0;
>>>
>>> pipe_lock(pipe);
>>> + down_read(¤t->mm->mmap_sem);
>>
>> Seems like you could take the mmap_sem only when GIFT and MOVE is set.
>> Maybe it won't help that much for performance but at least serve as
>> documenting the reason it's needed?
>>
>> Vlastimil
>>
>
> I had been doing that previously but moving this outside the loop and
> acquiring it once did improve performance. I'll add a comment on
> down_read() as to the reason for taking this though.
>
> -Rob
Hm perhaps in light of recent patches to reduce mmap_sem usage only to
really critical regions, maybe it really shouldn't be taken at all if
not needed.
Vlastimil
>>> for (;;) {
>>> if (!pipe->readers) {
>>> @@ -212,8 +217,44 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
>>> buf->len = spd->partial[page_nr].len;
>>> buf->private = spd->partial[page_nr].private;
>>> buf->ops = spd->ops;
>>> - if (spd->flags & SPLICE_F_GIFT)
>>> + if (spd->flags & SPLICE_F_GIFT) {
>>> + unsigned long useraddr =
>>> + spd->partial[page_nr].useraddr;
>>> +
>>> + if ((spd->flags & SPLICE_F_MOVE) &&
>>> + !buf->offset &&
>>> + (buf->len == PAGE_SIZE)) {
>>> + /* Can move page aligned buf, gather
>>> +* requests to make a single
>>> +* zap_page_range() call per VMA
>>> +*/
>>> + if (vma && (useraddr == user_end) &&
>>> + ((useraddr + PAGE_SIZE) <=
>>> + vma->vm_end)) {
>>> + /* same vma, no holes */
>>> + user_end += PAGE_SIZE;
>>> + } else {
>>> + if (vma)
>>> + zap_page_range(vma,
>>> + user_start,
>>> + (user_end -
>>> +user_start),
>>> + NULL);
>>> + vma = find_vma_intersection(
>>> + current->mm,
>>> + useraddr,
>>> + (useraddr +
>>> +PAGE_SIZE));
>>> + if (!IS_ERR_OR_NULL(vma)) {
>>> + user_start = useraddr;
>>> + user_end = (useraddr +
>>> + PAGE_SIZE);
>>> + } else
>>> + vma = NULL;
>>> + }
>>> + }
>>>
[PATCH] mm/pagewalk.c: Fix walk_page_range access wrong PTEs
From: Chen LinX When walk_page_range walk a memory map's page tables, it'll skip VM_PFNMAP area, then variable 'next' will to assign to vma->vm_end, it maybe larger than 'end'. In next loop, 'addr' will be larger than 'next'. Then in /proc//pagemap file reading procedure, the 'addr' will growing forever in pagemap_pte_range, pte_to_pagemap_entry will access wrong pte. [ 93.387934] BUG: Bad page map in process procrank pte:8437526f pmd:785de067 [ 93.387936] addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping: (null) index:9108d [ 93.387938] CPU: 1 PID: 4974 Comm: procrank Tainted: GB W O 3.10.1+ #1 [ 93.387942] f0d983c8 f0d983c8 e8271e48 c281ef4b e8271e84 c20ee794 c2a3f150 9108d000 [ 93.387946] 00200073 f0d99020 0009108d e8342d90 8437526f 0009108d [ 93.387950] 00084375 fffa4234 e8271e98 c20ef836 e8271f28 f0d983c8 [ 93.387951] Call Trace: [ 93.387953] [] dump_stack+0x16/0x18 [ 93.387956] [] print_bad_pte+0x114/0x1b0 [ 93.387959] [] vm_normal_page+0x56/0x60 [ 93.387961] [] pagemap_pte_range+0x17a/0x1d0 [ 93.387963] [] ? m_next+0x70/0x70 [ 93.387966] [] walk_page_range+0x19e/0x2c0 [ 93.387969] [] ? ptrace_may_access+0x24/0x40 [ 93.387971] [] pagemap_read+0x16e/0x200 [ 93.387973] [] ? m_next+0x70/0x70 [ 93.387976] [] ? quota_send_warning+0x1f0/0x1f0 [ 93.387979] [] ? pagemap_pte_hole+0x50/0x50 [ 93.387981] [] ? clear_refs_pte_range+0xc0/0xc0 [ 93.387984] [] vfs_read+0x84/0x150 [ 93.387986] [] ? clear_refs_pte_range+0xc0/0xc0 [ 93.387988] [] SyS_read+0x4a/0x80 [ 93.387991] [] syscall_call+0x7/0xb [ 93.387996] [] ? e1000_regdump+0x6f/0x37c [ 102.866190] [] ? cpuidle_idle_call+0x93/0x1b0 [ 102.872124] [] ? atomic_notifier_call_chain+0x1a/0x20 [ 102.878834] [] ? arch_cpu_idle+0x8/0x20 [ 102.884183] [] ? cpu_startup_entry+0x4d/0x1b0 [ 102.890116] [] ? rest_init+0x5d/0x60 [ 102.895174] [] ? start_kernel+0x31b/0x321 [ 102.900717] [] ? repair_env_string+0x51/0x51 [ 102.906551] [] ? i386_start_kernel+0x12c/0x12f Signed-off-by: Liu ShuoX Signed-off-by: Chen LinX --- mm/pagewalk.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/pagewalk.c b/mm/pagewalk.c index 5da2cbc..2beeabf 100644 --- a/mm/pagewalk.c +++ b/mm/pagewalk.c @@ -242,7 +242,7 @@ int walk_page_range(unsigned long addr, unsigned long end, if (err) break; pgd++; - } while (addr = next, addr != end); + } while (addr = next, addr < end); return err; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/17] ARM: at91: move to common clk framework
On 11/10/2013 09:37, Boris BREZILLON : Hello, This patch series is the 4th version of the new at91 clock implementation (using common clk framework). Mike, DT maintainers, Can you have a look at this series converting the AT91 family to common clock framework and associated Device Tree description? Here is the thread on gmane: http://thread.gmane.org/gmane.linux.ports.arm.kernel/272550 Mike, I think that you already reviewed a previous version of this series and I guess that we have finalized it. So gentlemen, It can be good for us if you can give us your "review" or "acknowledgement" tags... Thanks, best regards, Most of the clock provided by the PMC (Power Management Controller) are implemented : - main clock (main oscillator) - pll clocks - master clock - programmable clocks - utmi clock - peripheral clocks - system clocks This implementation is only compatible with device tree definition. The goal is to define the whole clock tree in the device tree. Could a dt maintainer take a look at these dt bindinds. This patch series is based on linus tree (but should apply correctly on linux-next) and has been tested on sama5d31ek. Best Regards, Boris Changes since v3: - simplify master clk implementation (drop set_rate/parent support) - fix bug in set_rate function of pll driver - fix coding style issues - define macros and constants where needed - remove peripheral id macro references - remove sam9g35 specific handling (sam9g35 = sam9x5) - rework main clk prepare function to handle automatic rate calculation Changes since v2: - fix several bugs in clk implementations - drop non-dt boards support - split the series to ease review and tests: * 1 patch series for new clk implementations (this series) * 1 patch series to move each at91 SoC to common clk framework (coming soon) - modify dt-bindings (add atmel,clk- prefix to atmel specific properties) - add clk macros for dt-bindings - add pmc framework (helper function to access pmc registers) - add interrupt support to enable passive wait in clk_prepare functions Changes since v1: - fix bugs in pll, programmable and system clock implementations (wrong bit position). - add usb clock configuration support (ohci and udc drivers + clk_lookup for non dt boards) - rework of the system clock interfaces (no need to define a parent clock, system clock is a gate with no rate info) - change system, peripheral and programmable clk dt bindings (1 master node and multiple child nodes each defining a system/peripheral or prog clock) - fix bugs in sama5 dt definition Boris BREZILLON (17): ARM: at91: move at91_pmc.h to include/linux/clk/at91_pmc.h ARM: at91: add Kconfig options for common clk support clk: at91: add PMC base support clk: at91: add PMC macro file for dt definitions clk: at91: add PMC main clock clk: at91: add PMC pll clocks clk: at91: add PMC master clock clk: at91: add PMC system clocks clk: at91: add PMC peripheral clocks clk: at91: add peripheral clk macros for peripheral clk dt bindings clk: at91: add PMC programmable clocks clk: at91: add PMC utmi clock clk: at91: add PMC usb clock clk: at91: add PMC smd clock clk: at91: add PMC clk device tree binding doc. ARM: at91: move pit timer to common clk framework ARM: at91: add new compatible strings for pmc driver .../devicetree/bindings/clock/at91-clock.txt | 328 arch/arm/mach-at91/Kconfig | 44 ++ arch/arm/mach-at91/Kconfig.non_dt |6 + arch/arm/mach-at91/Makefile|2 +- arch/arm/mach-at91/at91rm9200.c|2 +- arch/arm/mach-at91/at91sam9260.c |2 +- arch/arm/mach-at91/at91sam9261.c |2 +- arch/arm/mach-at91/at91sam9263.c |2 +- arch/arm/mach-at91/at91sam926x_time.c | 14 +- arch/arm/mach-at91/at91sam9g45.c |2 +- arch/arm/mach-at91/at91sam9n12.c |2 +- arch/arm/mach-at91/at91sam9rl.c|2 +- arch/arm/mach-at91/at91sam9x5.c|2 +- arch/arm/mach-at91/clock.c |7 +- arch/arm/mach-at91/generic.h |3 +- arch/arm/mach-at91/pm.c|2 +- arch/arm/mach-at91/pm_slowclock.S |2 +- arch/arm/mach-at91/sama5d3.c |2 +- arch/arm/mach-at91/setup.c |8 +- drivers/clk/Makefile |1 + drivers/clk/at91/Makefile | 12 + drivers/clk/at91/clk-main.c| 189 +++ drivers/clk/at91/clk-master.c | 278 ++ drivers/clk/at91/clk-peripheral.c | 407 +++ drivers/clk/at91/clk-pll.c
Re: linux-next: Tree for Oct 17
On Fri, Oct 18, 2013 at 12:45:26AM -0700, Olof Johansson wrote: > On Fri, Oct 18, 2013 at 01:38:47AM +0100, Mark Brown wrote: > > Hi all, > > > > I've uploaded today's linux-next tree to the master branch of the > > repository below: > > > > git://gitorious.org/thierryreding/linux-next.git > > > A next-20131017 tag is also provided for convenience. > > > > One new conflict today but otherwise uneventful. x86_64 allmodconfigs > > build after each merge but no other build tests were done. > > Hi, > > I'm seeing a fairly large fallout on boot testing. See > http://lists.linaro.org/pipermail/kernel-build-reports/2013-October/000719.html > for full list (I need to start providing longer backlogs for failures, the top > of the oopses is lost in the email). > > For example, on dove (SolidRun Cubox) I see: > > [0.707248] Unable to handle kernel NULL pointer dereference at virtual > address 0054 > [0.715297] pgd = c0004000 > [0.717984] [0054] *pgd= > [0.721548] Internal error: Oops: 5 [#1] ARM > [0.725794] Modules linked in: > [0.728841] CPU: 0 PID: 1 Comm: swapper Not tainted > 3.12.0-rc5-next-20131017 #1 > [0.736114] task: ef035c00 ti: ef036000 task.ti: ef036000 > [0.741497] PC is at kfree+0x54/0xc4 > [0.745063] LR is at ata_host_register+0x3c/0x290 > [0.749741] pc : []lr : []psr: 4193 > [0.749741] sp : ef037da8 ip : 0034 fp : > [0.761159] r10: r9 : ef061810 r8 : c0519fc8 > [0.766353] r7 : c0519fc8 r6 : a113 r5 : r4 : ef1c9dd0 > [0.772850] r3 : c0fc8fe0 r2 : c07c9000 r1 : 4000 r0 : > [0.779349] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment > kernel > [0.786708] Control: 10c5387d Table: 4019 DAC: 0015 > [0.792428] Process swapper (pid: 1, stack limit = 0xef036248) > [0.798234] Stack: (0xef037da8 to 0xef038000) > [0.957218] [] (kfree+0x54/0xc4) from [] > (ata_host_register+0x3c/0x290) > [0.965542] [] (ata_host_register+0x3c/0x290) from [] > (ata_host_activate+0xdc/0x118) > [0.974992] [] (ata_host_activate+0xdc/0x118) from [] > (mv_platform_probe+0x2dc/0x36c) > [0.984527] [] (mv_platform_probe+0x2dc/0x36c) from [] > (platform_drv_probe+0x18/0x48) > [0.994051] [] (platform_drv_probe+0x18/0x48) from [] > (really_probe+0x74/0x1fc) > [1.003062] [] (really_probe+0x74/0x1fc) from [] > (__driver_attach+0x98/0x9c) > [1.011804] [] (__driver_attach+0x98/0x9c) from [] > (bus_for_each_dev+0x60/0x94) > [1.020808] [] (bus_for_each_dev+0x60/0x94) from [] > (bus_add_driver+0x148/0x1f0) > [1.029898] [] (bus_add_driver+0x148/0x1f0) from [] > (driver_register+0x78/0xf8) > [1.038911] [] (driver_register+0x78/0xf8) from [] > (mv_init+0x30/0x50) > [1.047144] [] (mv_init+0x30/0x50) from [] > (do_one_initcall+0x100/0x14c) > [1.07] [] (do_one_initcall+0x100/0x14c) from [] > (kernel_init_freeable+0x120/0x1c0) > [1.065259] [] (kernel_init_freeable+0x120/0x1c0) from > [] (kernel_init+0x8/0x158) > [1.074441] [] (kernel_init+0x8/0x158) from [] > (ret_from_fork+0x14/0x3c) > [1.082841] Code: e0823283 e3110902 1593301c e593001c (e5904054) > > > I bisected it down to commit 55acc602faae7c10e53acdca0c70f4936c2539c6, which > is really weird. That is: > > commit 55acc602faae7c10e53acdca0c70f4936c2539c6 > Merge: e32face ba6857b > Author: Mark Brown > AuthorDate: Thu Oct 17 23:55:55 2013 +0100 > Commit: Mark Brown > CommitDate: Thu Oct 17 23:55:55 2013 +0100 > > Merge remote-tracking branch 'driver-core/driver-core-next' > > Conflicts: > include/linux/netdevice.h > > > But there isn't anything controversial in the merge commit. > > I tried checking out either side of that merge, and they both boot > fine. I redid the merge myself, and I get no delta compared to your > merge and I still get the same failure. > > I've got more failures than dove, I'll try bisecting a few of the others > in the morning (it's late here), hopefully they will help indicate what's > actually going wrong. I'm guessing something just happens to move around > enough to expose a different problem once the two branches are merged. Looking at that oops it seems like host is actually NULL when kfree() is called in ata_host_register(). That seems to only happen when freeing up any of the unused ports, which is strange in itself because Cubox seems to only register a single one. Also if host is indeed NULL, then things should go haywire much sooner. Looks like you won't easily find out what's going on here unless you get into it somewhat deeper and perhaps trace what exactly fails and why the NULL pointer is even there in the first place. Thierry pgpEClK8cEolS.pgp Description: PGP signature
Re: [PATCH v2 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
On 17.10.2013 19:46, Dave Martin wrote:
On Mon, Oct 14, 2013 at 07:08:24PM +0400, Vyacheslav Tyrtov wrote:
From: Tarek Dakhran
Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
---
arch/arm/mach-exynos/Makefile | 2 +
arch/arm/mach-exynos/edcs.c | 270 ++
2 files changed, 272 insertions(+)
create mode 100644 arch/arm/mach-exynos/edcs.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 5369615..ba6efdb 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -34,3 +34,5 @@ AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
obj-$(CONFIG_MACH_EXYNOS4_DT) += mach-exynos4-dt.o
obj-$(CONFIG_MACH_EXYNOS5_DT) += mach-exynos5-dt.o
+
+obj-$(CONFIG_SOC_EXYNOS5410) += edcs.o
diff --git a/arch/arm/mach-exynos/edcs.c b/arch/arm/mach-exynos/edcs.c
new file mode 100644
index 000..e304bd9
--- /dev/null
+++ b/arch/arm/mach-exynos/edcs.c
@@ -0,0 +1,270 @@
+/*
+ * arch/arm/mach-exynos/edcs.c - exynos dual cluster power management support
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran
+ *
+ * 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.
+ *
+ * EDCS(exynos dual cluster support) for Exynos5410 SoC.
+ */
+
[snip]
+#define EDCS_CORE_STATUS(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x4)
+#define EDCS_CORE_OPTION(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x8)
+
+#define REG_CPU_STATE_ADDR0(S5P_VA_SYSRAM_NS + 0x28)
Is there any reason why S5P_VA_SYSRAM_NS needs to be a static mapping?
What do you mean by "static mapping"?
+#define REG_CPU_STATE_ADDR(_nr)(REG_CPU_STATE_ADDR0 + \
+_nr * EDCS_CPUS_PER_CLUSTER)
+
+static arch_spinlock_t edcs_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+static int edcs_use_count[EDCS_CPUS_PER_CLUSTER][EDCS_CLUSTERS];
+static int core_count[EDCS_CLUSTERS];
+
+static void exynos_core_power_control(unsigned int cpu, unsigned int cluster,
+ bool enable)
+{
+ unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
+ int value = enable ? S5P_CORE_LOCAL_PWR_EN : 0;
+
+ if ((__raw_readl(EDCS_CORE_STATUS(offset)) & 0x3) != value)
+ __raw_writel(value, EDCS_CORE_CONFIGURATION(offset));
I think you need to replace all the __raw_readl() / __raw_writel() calls
in this file with readl_relaxed() / writel_relaxed().
This ensures little-endian byte order, so that BE8 kernels will work.
Will be done.
+}
+
+static void exynos_core_power_up(unsigned int cpu, unsigned int cluster)
+{
+ exynos_core_power_control(cpu, cluster, true);
+}
[snip]
+
+ edcs_use_count[cpu][cluster]++;
+ if (edcs_use_count[cpu][cluster] == 1) {
+ ++core_count[cluster];
+ set_boot_flag(cpu, 0x2);
0x2 looks like a magic number. Can we have a #define for that?
Will be done.
If the boot flag is read by the inbound CPU or by a peripheral then
there are memory ordering issues to take into account. Otherwise, can't
the inbound CPU come online and race with the write to the boot flag?
Inbound CPU doesn't write the boot flag.
What is the memory type of REG_STATE_ADDR()?
Same type as S5P_VA_SYSRAM_NS.
This 4K region is mapped as follows:
static struct map_desc exynos5410_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_SYSRAM_NS,
.pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
.length = SZ_4K,
.type = MT_DEVICE,
},
};
+ exynos_core_power_up(cpu, cluster);
+ } else if (edcs_use_count[cpu][cluster] != 2) {
+ /*
+* The only possible values are:
+* 0 = CPU down
+* 1 = CPU (still) up
+* 2 = CPU requested to be up before it had a chance
+* to actually make itself down.
+* Any other value is a bug.
+*/
+ BUG();
+ }
+
+ arch_spin_unlock(&edcs_lock);
+ local_irq_enable();
+
+ return 0;
+}
+static void exynos_power_down(void)
+{
+ unsigned int mpidr, cpu, cluster;
+ bool last_man = false, skip_wfi = false;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+ BUG_ON(cpu >= EDCS_CPUS_PER_CLUSTER || cluster >= EDCS_CLUSTERS);
+
+ __mcpm_cpu_going_down(cpu, cluster);
+
+ arch_spin_lock(&edcs_lock);
+
Re: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 15:49, Lucas Stach wrote: > Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: > [...] >> Sorry to ask this but, Where is this requirement coming from? >> I have not spotted any thing as such in ePAPR specs. >> >> >> All the spec says is. >> === >> The compatible property value consists of one or more strings that >> define the specific programming model for the device. This list of >> strings should be used by a client program for device driver selection. >> The property value consists of a concatenated list of null terminated >> strings, *from most specific to most general.* They allow a device to >> express its compatibility with a family of similar devices, potentially >> allowing a single device driver to match against several devices. >> The recommended format is “manufacturer,model”, where manufacturer is a >> string describing the name of the manufacturer (such as an OUI), and >> model specifies the model number. >> >> Example: >> compatible = “fsl,mpc8641-uart”, “ns16550"; >> In this example, an operating system would first try to locate a device >> driver that supported fsl,mpc8641-uart. If a driver was not found, it >> would then try to locate a driver that supported the more general >> ns16550 device type. >> === >> >> The more general compatible string in this case is "st,comms-ssc-i2c", >> rather than the first soc name. >> How can a first SOC name be more general? >> >> As this driver is not very specific to StiH415, it is generic driver for >> ST comms-ssc-i2c block. >> > > You just can't know if someone in the future decides to subtly change > the register layout or make some other incompatible change to the > comms-ssc-i2c block. > This is not the case for comms-ssc-i2c block, This IP is kind of reused from past 10+ years(I think!!). Am not predicting the future here, but I am making a informed guess from past experience that this IP would not change in future. Am still not happy with the idea of using first SoC for the compatible for following reasons: 1> Generic IPs can be integrated into various vendor SoCs. For example synopsis IP can be integrated by ST parts and other non-ST parts. What would be the first SoC name in this case? 2> Looking at example like "arm,pl310-cache", "arm,l220-cache"... or any other generic ips, why are these IPs not encoding the first SoC name in there compatible string? I think the answer is generic IP. 3> IMHO, the idea of first SoC might solve the problem you described, but why would some one know about the first SoC when this was available. In this case this IP was available may be 10+ years back on an ST40 platform. Having such old SoC names in compatible strings in the device trees for a modern chip looks bit confusing. 4> ST generic drivers which are in kernel still use st, name, so I would like this consistency across all the st drivers (at least the ones which are going to be used by mach-sti platforms). 5> ePAPR spec clearly says that compatible string should contain "most specific to most general" names. In this case using more generic name makes more sense than having a specific name because its generic IP. Allowing a single device driver to match against several devices. 6> IMHO, the compatible string should be "vendor,-" rather than first SoC. Thanks, srini > So as a general rule of thumb you take the first SoC where a particular > IP block appeared as the compatible string, so you can just pick the > name of the SoC where the incompatible change was made as the next > string and not need to invent generic and unspecific comms-ssc-i2c-v2 > compatibles. > > Regards, > Lucas > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] ARM64: Add kernel probes(Kprobes) support
(2013/10/17 20:17), Sandeepa Prabhu wrote:
> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
> and return probes(kretprobes) support for ARM64.
>
> Kprobes mechanism make use of software breakpoint and single stepping
> support available in ARM v8 kernel.
>
Thank you! This looks much better for me now. ;)
> This patchset make use of (and dependant upon) dynamic kernel patching
> feature published in patch series: https://lkml.org/lkml/2013/10/15/891
>
> changes: v1 -> v2
> 1. Implemented review comments on v1
> 2. Debug montior hooks implementation is changed to use rwlocks
> instead of rcu and spinlock.
Eventually, we'd better reconsider using rcu there, or prohibit probing
readlock related functions. For the first step, this will be good.
> 3. Enabled recursing in kprobes handler for kprobes re-enter support.
> 4. Re-split the patchset to seperate single-stepping, simulation and
> kretprobes features.
> 5. instruction simulation is made independent of 'struct kprobes'
> 6. Added 'Linaro Copyright' statements in new added files.
> 7. Used arm64 instead of aarch64 in file names and comments.
>
> Tested on ARM v8 fast model with sample modules from: samples/kprobes/
>
> Sandeepa Prabhu (6):
> arm64: support single-step and breakpoint handler hooks
> arm64: Kprobes with single stepping support
> arm64: Kprobes instruction simulation support
> arm64: Add kernel return probes support(kretprobes)
> arm64: Enable kprobes support for arm64 platform
> kprobes: Add cases for arm and arm64 in sample module
>
> arch/arm64/Kconfig | 2 +
> arch/arm64/configs/defconfig| 20 +-
> arch/arm64/include/asm/debug-monitors.h | 21 +
> arch/arm64/include/asm/kprobes.h| 60 +++
> arch/arm64/include/asm/probes.h | 50 +++
> arch/arm64/include/asm/ptrace.h | 6 +
> arch/arm64/kernel/Makefile | 2 +
> arch/arm64/kernel/condn-helpers.c | 120 ++
> arch/arm64/kernel/debug-monitors.c | 86 +++-
> arch/arm64/kernel/entry.S | 2 +
> arch/arm64/kernel/kprobes-arm64.c | 313 +++
> arch/arm64/kernel/kprobes-arm64.h | 30 ++
One comment, this name looks a bit wired. Since it seems that these are
for instruction decoding, can we merge it with probe-decode.h and
rename it as probe-decode.{h,c}? When we implement uprobes, we still
can expand it (add the decoding table for uprobes in the probe-decode.c).
> arch/arm64/kernel/kprobes.c | 682
>
> arch/arm64/kernel/kprobes.h | 30 ++
> arch/arm64/kernel/probes-decode.h | 110 ++
> arch/arm64/kernel/simulate-insn.c | 184 +
> arch/arm64/kernel/simulate-insn.h | 33 ++
> arch/arm64/kernel/vmlinux.lds.S | 1 +
> samples/kprobes/kprobe_example.c| 16 +
> 19 files changed, 1756 insertions(+), 12 deletions(-)
BTW, is there any public git repository which has this series?
Thank you again!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/9] Extended H/W error log driver
[PATCH v3 1/9] ACPI, APEI, CPER: Fix status check during error printing
[PATCH v3 2/9] ACPI, CPER: Update cper info
[PATCH v3 3/9] bitops: Introduce a more generic BITMASK macro
[PATCH v3 4/9] ACPI, x86: Extended error log driver for x86 platform
[PATCH v3 5/9] DMI: Parse memory device (type 17) in SMBIOS
[PATCH v3 6/9] ACPI, APEI, CPER: Add UEFI 2.4 support for memory error
[PATCH v3 7/9] ACPI, APEI, CPER: Enhance memory reporting capability
[PATCH v3 8/9] ACPI, APEI, CPER: Cleanup CPER memory error output format
[PATCH v3 9/9] EDAC, GHES: Update ghes error record info
OK, this is the 3rd version. Hope it is the last one :-).
this version just updates some minors places and apply some Ack/Review
information. In this version I remove the last patch for trace interface.
Maybe it is time to build a new RAS trace interface to integrate all
RAS related error report interfaces now.
new output format as below:
dmesg output:
[ 498.485536] {1}Hardware error detected on CPU45
[ 498.485616] {1}It has been corrected by h/w and requires no further action
[ 498.485655] {1}event severity: corrected
[ 498.485660] {1} Error 0, type: corrected
[ 498.485681] {1} section_type: memory error
[ 498.485686] {1} physical_address: 0x00207ff1a000
[ 498.485697] {1} DIMM location: Memriser7 CHANNEL A DIMM 0
[ 498.485720] {2}Hardware error detected on CPU45
[ 498.485728] {2}It has been corrected by h/w and requires no further action
[ 498.485735] {2}event severity: corrected
[ 498.485740] {2} Error 0, type: corrected
[ 498.485748] {2} section_type: memory error
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/7] sched: power: Remove power capacity hints for kworker threads
On Thu, Oct 17, 2013 at 05:54:16PM +0100, Peter Zijlstra wrote: > On Thu, Oct 17, 2013 at 05:40:38PM +0100, Morten Rasmussen wrote: > > On Mon, Oct 14, 2013 at 04:14:25PM +0100, Arjan van de Ven wrote: > > > On 10/14/2013 6:33 AM, Peter Zijlstra wrote: > > > > On Fri, Oct 11, 2013 at 06:19:14PM +0100, Morten Rasmussen wrote: > > > >> Removing power hints for kworker threads enables easier use of > > > >> workqueues in the power driver late callback. That would otherwise > > > >> lead to an endless loop unless it is prevented in the power driver. > > > > > > > > There's many kworker users; some of them actually consume lots of > > > > cputime. Therefore how did you come to the conclusion that excepting all > > > > users was the better choice of a little added complexity in the one > > > > place where it actually matters? > > > > > > .. and likely only for a very few architectures > > > > > > x86, and I suspect modern ARM, can change frequency synchronously. > > > (using an instruction or maybe two or three for ARM) > > > > It should be possible to implement synchronous frequency changes on most > > modern ARM platforms. It is a bit more than a few instructions to change > > frequency though particularly for the current cpufreq drivers. > > > > cpufreq drivers, like the one for ARM TC2, uses the clock framework to > > manage clocks. clk_set_rate() is allowed to sleep which won't work if we > > call it from scheduler context. The clock framework will need a look if > > it doesn't provide a very fast synchronous alternative to clk_set_rate() > > to change frequency and we want to use it for scheduler driven frequency > > scaling. > > > > cpufreq has pre- and post-change notifiers so the current TC2 clock driver > > waits (yields) in its clk_set_rate() implementation until the change has > > happened to ensure that the post-change notifier happens at the right > > time. Since clk_set_rate() is allowed to sleep other tasks may be > > running while waiting for the change to complete. This may be true for > > other clock drivers as well. > > > > AFAICT, there is no way to reuse the existing cpufreq drivers in a > > sensible way for scheduler driven frequency scaling. It should be > > possible to have very fast frequency changes on ARM but it is not the > > way it is currently done. > > > Note that you still have preemption disabled in your late callback from > finish_task_switch(). There's no way you can wait/yield/whatever from > there. Nor is that really sane. No, that is what I have realized after messing around trying to call into cpufreq. It just won't work. A non-waiting/yielding/whatever driver is needed. There is no point in having the late callback it won't solve anything. > > Just say no to the existing cruft ? That is the only way ahead I think. intel_pstate.c does it. I will into what it takes to do something similar on ARM TC2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 8/9] ACPI, APEI, CPER: Cleanup CPER memory error output format
Keep up only the most important fields for memory error
reporting. The detail information will be moved to perf/trace
interface.
Suggested-by: Tony Luck
Signed-off-by: Chen, Gong
Reviewed-by: Mauro Carvalho Chehab
---
drivers/acpi/apei/cper.c | 67 ++--
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index b1a8a55..9dd54e1 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -33,6 +33,7 @@
#include
#include
+#define INDENT_SP " "
/*
* CPER record ID need to be unique even after reboot, because record
* ID is used as index for ERST storage, while CPER records from
@@ -206,29 +207,29 @@ static void cper_print_mem(const char *pfx, const struct
cper_sec_mem_err *mem)
printk("%s""physical_address_mask: 0x%016llx\n",
pfx, mem->physical_addr_mask);
if (mem->validation_bits & CPER_MEM_VALID_NODE)
- printk("%s""node: %d\n", pfx, mem->node);
+ pr_debug("node: %d\n", mem->node);
if (mem->validation_bits & CPER_MEM_VALID_CARD)
- printk("%s""card: %d\n", pfx, mem->card);
+ pr_debug("card: %d\n", mem->card);
if (mem->validation_bits & CPER_MEM_VALID_MODULE)
- printk("%s""module: %d\n", pfx, mem->module);
+ pr_debug("module: %d\n", mem->module);
if (mem->validation_bits & CPER_MEM_VALID_RANK_NUMBER)
- printk("%s""rank: %d\n", pfx, mem->rank);
+ pr_debug("rank: %d\n", mem->rank);
if (mem->validation_bits & CPER_MEM_VALID_BANK)
- printk("%s""bank: %d\n", pfx, mem->bank);
+ pr_debug("bank: %d\n", mem->bank);
if (mem->validation_bits & CPER_MEM_VALID_DEVICE)
- printk("%s""device: %d\n", pfx, mem->device);
+ pr_debug("device: %d\n", mem->device);
if (mem->validation_bits & CPER_MEM_VALID_ROW)
- printk("%s""row: %d\n", pfx, mem->row);
+ pr_debug("row: %d\n", mem->row);
if (mem->validation_bits & CPER_MEM_VALID_COLUMN)
- printk("%s""column: %d\n", pfx, mem->column);
+ pr_debug("column: %d\n", mem->column);
if (mem->validation_bits & CPER_MEM_VALID_BIT_POSITION)
- printk("%s""bit_position: %d\n", pfx, mem->bit_pos);
+ pr_debug("bit_position: %d\n", mem->bit_pos);
if (mem->validation_bits & CPER_MEM_VALID_REQUESTOR_ID)
- printk("%s""requestor_id: 0x%016llx\n", pfx, mem->requestor_id);
+ pr_debug("requestor_id: 0x%016llx\n", mem->requestor_id);
if (mem->validation_bits & CPER_MEM_VALID_RESPONDER_ID)
- printk("%s""responder_id: 0x%016llx\n", pfx, mem->responder_id);
+ pr_debug("responder_id: 0x%016llx\n", mem->responder_id);
if (mem->validation_bits & CPER_MEM_VALID_TARGET_ID)
- printk("%s""target_id: 0x%016llx\n", pfx, mem->target_id);
+ pr_debug("target_id: 0x%016llx\n", mem->target_id);
if (mem->validation_bits & CPER_MEM_VALID_ERROR_TYPE) {
u8 etype = mem->error_type;
printk("%s""error_type: %d, %s\n", pfx, etype,
@@ -296,55 +297,45 @@ static void cper_print_pcie(const char *pfx, const struct
cper_sec_pcie *pcie,
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
}
-static const char * const cper_estatus_section_flag_strs[] = {
- "primary",
- "containment warning",
- "reset",
- "error threshold exceeded",
- "resource not accessible",
- "latent error",
-};
-
static void cper_estatus_print_section(
const char *pfx, const struct acpi_generic_data *gdata, int sec_no)
{
uuid_le *sec_type = (uuid_le *)gdata->section_type;
__u16 severity;
+ char newpfx[64];
severity = gdata->error_severity;
- printk("%s""section: %d, severity: %d, %s\n", pfx, sec_no, severity,
+ printk("%s""Error %d, type: %s\n", pfx, sec_no,
cper_severity_str(severity));
- printk("%s""flags: 0x%02x\n", pfx, gdata->flags);
- cper_print_bits(pfx, gdata->flags, cper_estatus_section_flag_strs,
- ARRAY_SIZE(cper_estatus_section_flag_strs));
if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
printk("%s""fru_id: %pUl\n", pfx, (uuid_le *)gdata->fru_id);
if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
printk("%s""fru_text: %.20s\n", pfx, gdata->fru_text);
+ snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
- printk("%s""section_type: general processor error\n", pfx);
+ printk("%s""section_type: general processor error\n", newpfx);
[PATCH v3 5/9] DMI: Parse memory device (type 17) in SMBIOS
This patch adds a new interface to decode memory device (type 17)
to help error reporting on DIMMs.
Original-author: Tony Luck
Signed-off-by: Chen, Gong
Acked-by: Naveen N. Rao
Acked-by: Borislav Petkov
Reviewed-by: Mauro Carvalho Chehab
---
arch/ia64/kernel/setup.c| 1 +
arch/x86/kernel/setup.c | 1 +
drivers/firmware/dmi_scan.c | 60 +
include/linux/dmi.h | 5
4 files changed, 67 insertions(+)
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 4fc2e95..d86669b 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -1063,6 +1063,7 @@ check_bugs (void)
static int __init run_dmi_scan(void)
{
dmi_scan_machine();
+ dmi_memdev_walk();
dmi_set_dump_stack_arch_desc();
return 0;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f0de629..918d489 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -993,6 +993,7 @@ void __init setup_arch(char **cmdline_p)
efi_init();
dmi_scan_machine();
+ dmi_memdev_walk();
dmi_set_dump_stack_arch_desc();
/*
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index fa0affb..59579a7 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -25,6 +25,13 @@ static int dmi_initialized;
/* DMI system identification string used during boot */
static char dmi_ids_string[128] __initdata;
+static struct dmi_memdev_info {
+ const char *device;
+ const char *bank;
+ u16 handle;
+} *dmi_memdev;
+static int dmi_memdev_nr;
+
static const char * __init dmi_string_nosave(const struct dmi_header *dm, u8 s)
{
const u8 *bp = ((u8 *) dm) + dm->length;
@@ -322,6 +329,42 @@ static void __init dmi_save_extended_devices(const struct
dmi_header *dm)
dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
}
+static void __init count_mem_devices(const struct dmi_header *dm, void *v)
+{
+ if (dm->type != DMI_ENTRY_MEM_DEVICE)
+ return;
+ dmi_memdev_nr++;
+}
+
+static void __init save_mem_devices(const struct dmi_header *dm, void *v)
+{
+ const char *d = (const char *)dm;
+ static int nr;
+
+ if (dm->type != DMI_ENTRY_MEM_DEVICE)
+ return;
+ if (nr >= dmi_memdev_nr) {
+ pr_warn(FW_BUG "Too many DIMM entries in SMBIOS table\n");
+ return;
+ }
+ dmi_memdev[nr].handle = dm->handle;
+ dmi_memdev[nr].device = dmi_string(dm, d[0x10]);
+ dmi_memdev[nr].bank = dmi_string(dm, d[0x11]);
+ nr++;
+}
+
+void __init dmi_memdev_walk(void)
+{
+ if (!dmi_available)
+ return;
+
+ if (dmi_walk_early(count_mem_devices) == 0 && dmi_memdev_nr) {
+ dmi_memdev = dmi_alloc(sizeof(*dmi_memdev) * dmi_memdev_nr);
+ if (dmi_memdev)
+ dmi_walk_early(save_mem_devices);
+ }
+}
+
/*
* Process a DMI table entry. Right now all we care about are the BIOS
* and machine entries. For 2.5 we should pull the smbus controller info
@@ -815,3 +858,20 @@ bool dmi_match(enum dmi_field f, const char *str)
return !strcmp(info, str);
}
EXPORT_SYMBOL_GPL(dmi_match);
+
+void dmi_memdev_name(u16 handle, const char **bank, const char **device)
+{
+ int n;
+
+ if (dmi_memdev == NULL)
+ return;
+
+ for (n = 0; n < dmi_memdev_nr; n++) {
+ if (handle == dmi_memdev[n].handle) {
+ *bank = dmi_memdev[n].bank;
+ *device = dmi_memdev[n].device;
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(dmi_memdev_name);
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index b6eb7a0..f820f0a 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -99,6 +99,7 @@ extern const char * dmi_get_system_info(int field);
extern const struct dmi_device * dmi_find_device(int type, const char *name,
const struct dmi_device *from);
extern void dmi_scan_machine(void);
+extern void dmi_memdev_walk(void);
extern void dmi_set_dump_stack_arch_desc(void);
extern bool dmi_get_date(int field, int *yearp, int *monthp, int *dayp);
extern int dmi_name_in_vendors(const char *str);
@@ -107,6 +108,7 @@ extern int dmi_available;
extern int dmi_walk(void (*decode)(const struct dmi_header *, void *),
void *private_data);
extern bool dmi_match(enum dmi_field f, const char *str);
+extern void dmi_memdev_name(u16 handle, const char **bank, const char
**device);
#else
@@ -115,6 +117,7 @@ static inline const char * dmi_get_system_info(int field) {
return NULL; }
static inline const struct dmi_device * dmi_find_device(int type, const char
*name,
const struct dmi_device *from) { return NULL; }
static inline void dmi_scan_machine(void) { return; }
+static inline void dmi_memdev_walk(void) { }
static inli
[PATCH v3 2/9] ACPI, CPER: Update cper info
To prepare for the following patches and make related
definition more clear, update some definitions about CPER.
v2 -> v1: Update some more definitions suggested by Boris
Signed-off-by: Chen, Gong
Acked-by: Borislav Petkov
Reviewed-by: Mauro Carvalho Chehab
---
drivers/acpi/apei/apei-internal.h | 12
drivers/acpi/apei/cper.c | 58 +++
drivers/acpi/apei/ghes.c | 54 ++--
include/acpi/actbl1.h | 14 +-
include/acpi/ghes.h | 2 +-
include/linux/cper.h | 2 +-
6 files changed, 71 insertions(+), 71 deletions(-)
diff --git a/drivers/acpi/apei/apei-internal.h
b/drivers/acpi/apei/apei-internal.h
index f220d64..21ba34a 100644
--- a/drivers/acpi/apei/apei-internal.h
+++ b/drivers/acpi/apei/apei-internal.h
@@ -122,11 +122,11 @@ struct dentry;
struct dentry *apei_get_debugfs_dir(void);
#define apei_estatus_for_each_section(estatus, section)
\
- for (section = (struct acpi_hest_generic_data *)(estatus + 1); \
+ for (section = (struct acpi_generic_data *)(estatus + 1); \
(void *)section - (void *)estatus < estatus->data_length; \
section = (void *)(section+1) + section->error_data_length)
-static inline u32 apei_estatus_len(struct acpi_hest_generic_status *estatus)
+static inline u32 cper_estatus_len(struct acpi_generic_status *estatus)
{
if (estatus->raw_data_length)
return estatus->raw_data_offset + \
@@ -135,10 +135,10 @@ static inline u32 apei_estatus_len(struct
acpi_hest_generic_status *estatus)
return sizeof(*estatus) + estatus->data_length;
}
-void apei_estatus_print(const char *pfx,
- const struct acpi_hest_generic_status *estatus);
-int apei_estatus_check_header(const struct acpi_hest_generic_status *estatus);
-int apei_estatus_check(const struct acpi_hest_generic_status *estatus);
+void cper_estatus_print(const char *pfx,
+ const struct acpi_generic_status *estatus);
+int cper_estatus_check_header(const struct acpi_generic_status *estatus);
+int cper_estatus_check(const struct acpi_generic_status *estatus);
int apei_osc_setup(void);
#endif
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index f827f02..eb5f6d6 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -5,7 +5,7 @@
* Author: Huang Ying
*
* CPER is the format used to describe platform hardware error by
- * various APEI tables, such as ERST, BERT and HEST etc.
+ * various tables, such as ERST, BERT and HEST etc.
*
* For more information about CPER, please refer to Appendix N of UEFI
* Specification version 2.3.
@@ -73,7 +73,7 @@ static const char *cper_severity_str(unsigned int severity)
* printed, with @pfx is printed at the beginning of each line.
*/
void cper_print_bits(const char *pfx, unsigned int bits,
-const char *strs[], unsigned int strs_size)
+const char * const strs[], unsigned int strs_size)
{
int i, len = 0;
const char *str;
@@ -98,32 +98,32 @@ void cper_print_bits(const char *pfx, unsigned int bits,
printk("%s\n", buf);
}
-static const char *cper_proc_type_strs[] = {
+static const char * const cper_proc_type_strs[] = {
"IA32/X64",
"IA64",
};
-static const char *cper_proc_isa_strs[] = {
+static const char * const cper_proc_isa_strs[] = {
"IA32",
"IA64",
"X64",
};
-static const char *cper_proc_error_type_strs[] = {
+static const char * const cper_proc_error_type_strs[] = {
"cache error",
"TLB error",
"bus error",
"micro-architectural error",
};
-static const char *cper_proc_op_strs[] = {
+static const char * const cper_proc_op_strs[] = {
"unknown or generic",
"data read",
"data write",
"instruction execution",
};
-static const char *cper_proc_flag_strs[] = {
+static const char * const cper_proc_flag_strs[] = {
"restartable",
"precise IP",
"overflow",
@@ -248,7 +248,7 @@ static const char *cper_pcie_port_type_strs[] = {
};
static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
- const struct acpi_hest_generic_data *gdata)
+ const struct acpi_generic_data *gdata)
{
if (pcie->validation_bits & CPER_PCIE_VALID_PORT_TYPE)
printk("%s""port_type: %d, %s\n", pfx, pcie->port_type,
@@ -283,17 +283,17 @@ static void cper_print_pcie(const char *pfx, const struct
cper_sec_pcie *pcie,
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
}
-static const char *apei_estatus_section_flag_strs[] = {
+static const char * const cper_estatus_section_flag_strs[] = {
"primary",
"containment warning",
"reset",
- "threshold exceeded"
[PATCH v3 7/9] ACPI, APEI, CPER: Enhance memory reporting capability
After H/W error happens under FFM enabled mode, lots of information
are shown but some important parts like DIMM location missed. This
patch is used to show these extra fileds.
Original-author: Tony Luck
Signed-off-by: Chen, Gong
Acked-by: Naveen N. Rao
Acked-by: Borislav Petkov
Reviewed-by: Mauro Carvalho Chehab
---
drivers/acpi/apei/cper.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index 946ef52..b1a8a55 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -210,6 +211,8 @@ static void cper_print_mem(const char *pfx, const struct
cper_sec_mem_err *mem)
printk("%s""card: %d\n", pfx, mem->card);
if (mem->validation_bits & CPER_MEM_VALID_MODULE)
printk("%s""module: %d\n", pfx, mem->module);
+ if (mem->validation_bits & CPER_MEM_VALID_RANK_NUMBER)
+ printk("%s""rank: %d\n", pfx, mem->rank);
if (mem->validation_bits & CPER_MEM_VALID_BANK)
printk("%s""bank: %d\n", pfx, mem->bank);
if (mem->validation_bits & CPER_MEM_VALID_DEVICE)
@@ -232,6 +235,15 @@ static void cper_print_mem(const char *pfx, const struct
cper_sec_mem_err *mem)
etype < ARRAY_SIZE(cper_mem_err_type_strs) ?
cper_mem_err_type_strs[etype] : "unknown");
}
+ if (mem->validation_bits & CPER_MEM_VALID_MODULE_HANDLE) {
+ const char *bank = NULL, *device = NULL;
+ dmi_memdev_name(mem->mem_dev_handle, &bank, &device);
+ if (bank != NULL && device != NULL)
+ printk("%s""DIMM location: %s %s", pfx, bank, device);
+ else
+ printk("%s""DIMM DMI handle: 0x%.4x",
+ pfx, mem->mem_dev_handle);
+ }
}
static const char *cper_pcie_port_type_strs[] = {
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] ACPI, x86: Extended error log driver for x86 platform
This H/W error log driver (a.k.a eMCA driver) is implemented based on
http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html
After errors are captured, more valuable information can be
got via this new enhanced H/W error log driver.
v3 -> v2: fix a MACRO definition error and some cleanup
v2 -> v1: eliminate spin_lock & minor fixes suggested by Boris
Signed-off-by: Chen, Gong
---
arch/x86/include/asm/mce.h | 5 +
arch/x86/kernel/cpu/mcheck/mce.c | 20 +++
drivers/acpi/Kconfig | 20 +++
drivers/acpi/Makefile| 2 +
drivers/acpi/acpi_extlog.c | 319 +++
drivers/acpi/bus.c | 3 +-
include/linux/acpi.h | 1 +
7 files changed, 369 insertions(+), 1 deletion(-)
create mode 100644 drivers/acpi/acpi_extlog.c
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index cbe6b9e..072b2f8 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -16,6 +16,7 @@
#define MCG_EXT_CNT_SHIFT 16
#define MCG_EXT_CNT(c) (((c) & MCG_EXT_CNT_MASK) >> MCG_EXT_CNT_SHIFT)
#define MCG_SER_P (1ULL<<24) /* MCA recovery/new status bits */
+#define MCG_ELOG_P (1ULL<<26) /* Extended error log supported */
/* MCG_STATUS register defines */
#define MCG_STATUS_RIPV (1ULL<<0) /* restart ip valid */
@@ -186,6 +187,10 @@ enum mcp_flags {
MCP_UC = (1 << 1), /* log uncorrected errors */
MCP_DONTLOG = (1 << 2), /* only clear, don't log */
};
+
+void register_elog_handler(int (*f)(const char *, int, int));
+void unregister_elog_handler(int (*f)(const char *, int, int));
+
void machine_check_poll(enum mcp_flags flags, mce_banks_t *b);
int mce_notify_irq(void);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index b3218cd..981e0d3 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -48,6 +48,8 @@
#include "mce-internal.h"
+static int (*mce_ext_err_print)(const char *, int, int);
+
static DEFINE_MUTEX(mce_chrdev_read_mutex);
#define rcu_dereference_check_mce(p) \
@@ -576,6 +578,21 @@ static void mce_read_aux(struct mce *m, int i)
DEFINE_PER_CPU(unsigned, mce_poll_count);
+void register_elog_handler(int (*f)(const char *, int, int))
+{
+ mce_ext_err_print = f;
+}
+EXPORT_SYMBOL_GPL(register_elog_handler);
+
+void unregister_elog_handler(int (*f)(const char *, int, int))
+{
+ if (f) {
+ WARN_ON(mce_ext_err_print != f);
+ mce_ext_err_print = NULL;
+ }
+}
+EXPORT_SYMBOL_GPL(unregister_elog_handler);
+
/*
* Poll for corrected events or events that happened before reset.
* Those are just logged through /dev/mcelog.
@@ -624,6 +641,9 @@ void machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
(m.status & (mca_cfg.ser ? MCI_STATUS_S : MCI_STATUS_UC)))
continue;
+ if (mce_ext_err_print)
+ mce_ext_err_print(NULL, m.extcpu, i);
+
mce_read_aux(&m, i);
if (!(flags & MCP_TIMESTAMP))
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 22327e6..c67ec61 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -372,4 +372,24 @@ config ACPI_BGRT
source "drivers/acpi/apei/Kconfig"
+config ACPI_EXTLOG
+ tristate "Extended Error Log support"
+ depends on X86_MCE
+ default n
+ help
+ Certain usages such as Predictive Failure Analysis (PFA) require
+ more information about the error than what can be described in
+ processor machine check banks. Most server processors log
+ additional information about the error in processor uncore
+ registers. Since the addresses and layout of these registers vary
+ widely from one processor to another, system software cannot
+ readily make use of them. To complicate matters further, some of
+ the additional error information cannot be constructed space
+ between "additional" and "error" without detailed knowledge
+ about platform topology.
+
+ Enhanced MCA Logging allows firmware to provide additional error
+ information to system software, synchronous with MCE or CMCI. This
+ driver adds support for that functionality.
+
endif # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index cdaf68b..bce34af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,3 +82,5 @@ processor-$(CONFIG_CPU_FREQ) += processor_perflib.o
obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
obj-$(CONFIG_ACPI_APEI)+= apei/
+
+obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
new file mode 100644
index 000..afeab59
--- /dev/null
+++ b/drivers/acpi/acpi_extlog.c
[PATCH v3 9/9] EDAC, GHES: Update ghes error record info
In latest UEFI spec(by now it's 2.4) there are some new
fields for memory error reporting. Add these new fields for
ghes_edac interface.
Signed-off-by: Chen, Gong
Cc: Mauro Carvalho Chehab
---
drivers/edac/ghes_edac.c | 11 +++
include/linux/edac.h | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 0ad797b..d5a98a4 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -314,6 +314,8 @@ void ghes_edac_report_mem_error(struct ghes *ghes, int sev,
p += sprintf(p, "card:%d ", mem_err->card);
if (mem_err->validation_bits & CPER_MEM_VALID_MODULE)
p += sprintf(p, "module:%d ", mem_err->module);
+ if (mem_err->validation_bits & CPER_MEM_VALID_RANK_NUMBER)
+ p += sprintf(p, "rank:%d ", mem_err->rank);
if (mem_err->validation_bits & CPER_MEM_VALID_BANK)
p += sprintf(p, "bank:%d ", mem_err->bank);
if (mem_err->validation_bits & CPER_MEM_VALID_ROW)
@@ -322,6 +324,15 @@ void ghes_edac_report_mem_error(struct ghes *ghes, int sev,
p += sprintf(p, "col:%d ", mem_err->column);
if (mem_err->validation_bits & CPER_MEM_VALID_BIT_POSITION)
p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
+ if (mem_err->validation_bits & CPER_MEM_VALID_MODULE_HANDLE) {
+ const char *bank = NULL, *device = NULL;
+ dmi_memdev_name(mem_err->mem_dev_handle, &bank, &device);
+ if (bank != NULL && device != NULL)
+ p += sprintf(p, "DIMM location:%s %s ", bank, device);
+ else
+ p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
+mem_err->mem_dev_handle);
+ }
if (p > e->location)
*(p - 1) = '\0';
diff --git a/include/linux/edac.h b/include/linux/edac.h
index 5c6d7fb..dbdffe8 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -51,7 +51,7 @@ static inline void opstate_init(void)
#define EDAC_MC_LABEL_LEN 31
/* Maximum size of the location string */
-#define LOCATION_SIZE 80
+#define LOCATION_SIZE 256
/* Defines the maximum number of labels that can be reported */
#define EDAC_MAX_LABELS8
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Check for NULL return values from allocating functions
On Thu 17-10-13 07:49:34, Laura Abbott wrote:
> A security audit revealed that several functions were not checking
> return value of allocation functions. These allocations may return
> NULL which may lead to NULL pointer dereferences and crashes or
> security concerns. Fix this by properly checking the return value
> and handling the error appropriately.
>
> Signed-off-by: Laura Abbott
> ---
> fs/buffer.c | 17 +++--
> 1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 4d74335..b53f863 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1561,6 +1561,9 @@ void create_empty_buffers(struct page *page,
> struct buffer_head *bh, *head, *tail;
>
> head = alloc_page_buffers(page, blocksize, 1);
> + if (head == NULL)
> + return;
> +
This cannot happen. alloc_page_buffers() is called with retry == 1 and
thus it will loop until it gets the memory it wants.
> bh = head;
> do {
> bh->b_state |= b_state;
> @@ -3008,16 +3011,18 @@ int _submit_bh(int rw, struct buffer_head *bh,
> unsigned long bio_flags)
> BUG_ON(buffer_unwritten(bh));
>
> /*
> - * Only clear out a write error when rewriting
> - */
> - if (test_set_buffer_req(bh) && (rw & WRITE))
> - clear_buffer_write_io_error(bh);
> -
> - /*
>* from here on down, it's all bio -- do the initial mapping,
>* submit_bio -> generic_make_request may further map this bio around
>*/
> bio = bio_alloc(GFP_NOIO, 1);
> + if (bio == NULL)
> + return -ENOMEM;
And the same is true here. If the gfp mask has __GFP_WAIT set (and
GFP_NOIO does have that), mempool_alloc() loops until it gets the memory.
So I agree we might be missing some details in documentation but the code
is correct.
Honza
> +
> + /*
> + * Only clear out a write error when rewriting
> + */
> + if (test_set_buffer_req(bh) && (rw & WRITE))
> + clear_buffer_write_io_error(bh);
>
> bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
> bio->bi_bdev = bh->b_bdev;
--
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/
[PATCH v3 6/9] ACPI, APEI, CPER: Add UEFI 2.4 support for memory error
In latest UEFI spec(by now it is 2.4) memory error definition
for CPER (UEFI 2.4 Appendix N Common Platform Error Record)
adds some new fields. These fields help people to locate
memory error on actual DIMM location.
Original-author: Tony Luck
Signed-off-by: Chen, Gong
Reviewed-by: Borislav Petkov
Reviewed-by: Mauro Carvalho Chehab
Acked-by: Naveen N. Rao
---
arch/x86/kernel/cpu/mcheck/mce-apei.c | 3 +--
drivers/acpi/apei/cper.c | 7 ---
drivers/acpi/apei/ghes.c | 4 ++--
drivers/edac/ghes_edac.c | 5 ++---
include/linux/cper.h | 11 +--
5 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce-apei.c
b/arch/x86/kernel/cpu/mcheck/mce-apei.c
index cd8b166..de8b60a 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-apei.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-apei.c
@@ -42,8 +42,7 @@ void apei_mce_report_mem_error(int corrected, struct
cper_sec_mem_err *mem_err)
struct mce m;
/* Only corrected MC is reported */
- if (!corrected || !(mem_err->validation_bits &
- CPER_MEM_VALID_PHYSICAL_ADDRESS))
+ if (!corrected || !(mem_err->validation_bits & CPER_MEM_VALID_PA))
return;
mce_setup(&m);
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index eb5f6d6..946ef52 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -8,7 +8,7 @@
* various tables, such as ERST, BERT and HEST etc.
*
* For more information about CPER, please refer to Appendix N of UEFI
- * Specification version 2.3.
+ * Specification version 2.4.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License version
@@ -191,16 +191,17 @@ static const char *cper_mem_err_type_strs[] = {
"memory sparing",
"scrub corrected error",
"scrub uncorrected error",
+ "physical memory map-out event",
};
static void cper_print_mem(const char *pfx, const struct cper_sec_mem_err *mem)
{
if (mem->validation_bits & CPER_MEM_VALID_ERROR_STATUS)
printk("%s""error_status: 0x%016llx\n", pfx, mem->error_status);
- if (mem->validation_bits & CPER_MEM_VALID_PHYSICAL_ADDRESS)
+ if (mem->validation_bits & CPER_MEM_VALID_PA)
printk("%s""physical_address: 0x%016llx\n",
pfx, mem->physical_addr);
- if (mem->validation_bits & CPER_MEM_VALID_PHYSICAL_ADDRESS_MASK)
+ if (mem->validation_bits & CPER_MEM_VALID_PA_MASK)
printk("%s""physical_address_mask: 0x%016llx\n",
pfx, mem->physical_addr_mask);
if (mem->validation_bits & CPER_MEM_VALID_NODE)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 0db6e4f..a30bc31 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -419,7 +419,7 @@ static void ghes_handle_memory_failure(struct
acpi_generic_data *gdata, int sev)
if (sec_sev == GHES_SEV_CORRECTED &&
(gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED) &&
- (mem_err->validation_bits & CPER_MEM_VALID_PHYSICAL_ADDRESS)) {
+ (mem_err->validation_bits & CPER_MEM_VALID_PA)) {
pfn = mem_err->physical_addr >> PAGE_SHIFT;
if (pfn_valid(pfn))
memory_failure_queue(pfn, 0, MF_SOFT_OFFLINE);
@@ -430,7 +430,7 @@ static void ghes_handle_memory_failure(struct
acpi_generic_data *gdata, int sev)
}
if (sev == GHES_SEV_RECOVERABLE &&
sec_sev == GHES_SEV_RECOVERABLE &&
- mem_err->validation_bits & CPER_MEM_VALID_PHYSICAL_ADDRESS) {
+ mem_err->validation_bits & CPER_MEM_VALID_PA) {
pfn = mem_err->physical_addr >> PAGE_SHIFT;
memory_failure_queue(pfn, 0, 0);
}
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index bb53467..0ad797b 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -297,15 +297,14 @@ void ghes_edac_report_mem_error(struct ghes *ghes, int
sev,
}
/* Error address */
- if (mem_err->validation_bits & CPER_MEM_VALID_PHYSICAL_ADDRESS) {
+ if (mem_err->validation_bits & CPER_MEM_VALID_PA) {
e->page_frame_number = mem_err->physical_addr >> PAGE_SHIFT;
e->offset_in_page = mem_err->physical_addr & ~PAGE_MASK;
}
/* Error grain */
- if (mem_err->validation_bits & CPER_MEM_VALID_PHYSICAL_ADDRESS_MASK) {
+ if (mem_err->validation_bits & CPER_MEM_VALID_PA_MASK)
e->grain = ~(mem_err->physical_addr_mask & ~PAGE_MASK);
- }
/* Memory error location, mapped on e->location */
p = e->location;
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 09ebe21..2fc0ec3 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -218,8 +218,8 @@ enum {
#def
[PATCH v3 3/9] bitops: Introduce a more generic BITMASK macro
GENMASK is used to create a contiguous bitmask([hi:lo]). It is
implemented twice in current kernel. One is in EDAC driver, the other
is in SiS/XGI FB driver. Move it to a more generic place for other
usage.
Signed-off-by: Chen, Gong
Cc: Borislav Petkov
Cc: Thomas Winischhofer
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Acked-by: Borislav Petkov
Acked-by: Mauro Carvalho Chehab
---
drivers/edac/amd64_edac.c | 46 --
drivers/edac/amd64_edac.h | 8
drivers/edac/sb_edac.c| 2 +-
drivers/video/sis/init.c | 5 ++---
include/linux/bitops.h| 8
5 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 3c9e4e9..b53d0de 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -339,8 +339,8 @@ static void get_cs_base_and_mask(struct amd64_pvt *pvt, int
csrow, u8 dct,
if (pvt->fam == 0xf && pvt->ext_model < K8_REV_F) {
csbase = pvt->csels[dct].csbases[csrow];
csmask = pvt->csels[dct].csmasks[csrow];
- base_bits = GENMASK(21, 31) | GENMASK(9, 15);
- mask_bits = GENMASK(21, 29) | GENMASK(9, 15);
+ base_bits = GENMASK_ULL(31, 21) | GENMASK_ULL(15, 9);
+ mask_bits = GENMASK_ULL(29, 21) | GENMASK_ULL(15, 9);
addr_shift = 4;
/*
@@ -352,16 +352,16 @@ static void get_cs_base_and_mask(struct amd64_pvt *pvt,
int csrow, u8 dct,
csbase = pvt->csels[dct].csbases[csrow];
csmask = pvt->csels[dct].csmasks[csrow >> 1];
- *base = (csbase & GENMASK(5, 15)) << 6;
- *base |= (csbase & GENMASK(19, 30)) << 8;
+ *base = (csbase & GENMASK_ULL(15, 5)) << 6;
+ *base |= (csbase & GENMASK_ULL(30, 19)) << 8;
*mask = ~0ULL;
/* poke holes for the csmask */
- *mask &= ~((GENMASK(5, 15) << 6) |
- (GENMASK(19, 30) << 8));
+ *mask &= ~((GENMASK_ULL(15, 5) << 6) |
+ (GENMASK_ULL(30, 19) << 8));
- *mask |= (csmask & GENMASK(5, 15)) << 6;
- *mask |= (csmask & GENMASK(19, 30)) << 8;
+ *mask |= (csmask & GENMASK_ULL(15, 5)) << 6;
+ *mask |= (csmask & GENMASK_ULL(30, 19)) << 8;
return;
} else {
@@ -370,9 +370,11 @@ static void get_cs_base_and_mask(struct amd64_pvt *pvt,
int csrow, u8 dct,
addr_shift = 8;
if (pvt->fam == 0x15)
- base_bits = mask_bits = GENMASK(19,30) | GENMASK(5,13);
+ base_bits = mask_bits =
+ GENMASK_ULL(30,19) | GENMASK_ULL(13,5);
else
- base_bits = mask_bits = GENMASK(19,28) | GENMASK(5,13);
+ base_bits = mask_bits =
+ GENMASK_ULL(28,19) | GENMASK_ULL(13,5);
}
*base = (csbase & base_bits) << addr_shift;
@@ -561,7 +563,7 @@ static u64 sys_addr_to_dram_addr(struct mem_ctl_info *mci,
u64 sys_addr)
* section 3.4.2 of AMD publication 24592: AMD x86-64 Architecture
* Programmer's Manual Volume 1 Application Programming.
*/
- dram_addr = (sys_addr & GENMASK(0, 39)) - dram_base;
+ dram_addr = (sys_addr & GENMASK_ULL(39, 0)) - dram_base;
edac_dbg(2, "using DRAM Base register to translate SysAddr 0x%lx to
DramAddr 0x%lx\n",
(unsigned long)sys_addr, (unsigned long)dram_addr);
@@ -597,7 +599,7 @@ static u64 dram_addr_to_input_addr(struct mem_ctl_info
*mci, u64 dram_addr)
* concerning translating a DramAddr to an InputAddr.
*/
intlv_shift = num_node_interleave_bits(dram_intlv_en(pvt, 0));
- input_addr = ((dram_addr >> intlv_shift) & GENMASK(12, 35)) +
+ input_addr = ((dram_addr >> intlv_shift) & GENMASK_ULL(35, 12)) +
(dram_addr & 0xfff);
edac_dbg(2, " Intlv Shift=%d DramAddr=0x%lx maps to InputAddr=0x%lx\n",
@@ -849,7 +851,7 @@ static u64 get_error_address(struct amd64_pvt *pvt, struct
mce *m)
end_bit = 39;
}
- addr = m->addr & GENMASK(start_bit, end_bit);
+ addr = m->addr & GENMASK_ULL(end_bit, start_bit);
/*
* Erratum 637 workaround
@@ -861,7 +863,7 @@ static u64 get_error_address(struct amd64_pvt *pvt, struct
mce *m)
u16 mce_nid;
u8 intlv_en;
- if ((addr & GENMASK(24, 47)) >> 24 != 0x00fdf7)
+ if ((addr & GENMASK_ULL(47, 24)) >> 24 != 0x00fdf7)
return addr;
mce_nid = amd_get_nb_id(m->extcpu);
@@ -871,7 +873,7 @@ static u64 get_error_address(struct amd64_pvt *pvt, struct
mce *m)
[PATCH v3 1/9] ACPI, APEI, CPER: Fix status check during error printing
Commit aaf9d93 only catches condition check before print,
but the similar check is needed during printing CPER error
sections.
Signed-off-by: Chen, Gong
Reviewed-by: Borislav Petkov
Reviewed-by: Mauro Carvalho Chehab
---
drivers/acpi/apei/cper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index 33dc6a0..f827f02 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -353,7 +353,7 @@ void apei_estatus_print(const char *pfx,
cper_severity_str(severity));
data_len = estatus->data_length;
gdata = (struct acpi_hest_generic_data *)(estatus + 1);
- while (data_len > sizeof(*gdata)) {
+ while (data_len >= sizeof(*gdata)) {
gedata_len = gdata->error_data_length;
apei_estatus_print_section(pfx, gdata, sec_no);
data_len -= gedata_len + sizeof(*gdata);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] init: make init failures more explicit
This patch proposes to make init failures more explicit.
Before this, the "No init found" message didn't help much.
It could sometimes be misleading and actually mean
"No *working* init found".
This message could hide many different issues:
- no init program candidates found at all
- some init program candidates exist but can't be executed
(missing execute permissions, failed to load shared libraries,
executable compiled for an unknown architecture...)
This patch notifies the kernel user when a candidate
init program is found but can't be executed. It also replaces
"No init found" by "No working init found", which is more correct.
This will help embedded Linux developers (especially the new comers),
regularly making and debugging new root filesystems.
Signed-off-by: Michael Opdenacker
---
init/main.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/init/main.c b/init/main.c
index 63d3e8f..a9a2833 100644
--- a/init/main.c
+++ b/init/main.c
@@ -811,6 +811,20 @@ static int run_init_process(const char *init_filename)
(const char __user *const __user *)envp_init);
}
+static int try_to_run_init_process(const char *init_filename)
+{
+ int ret;
+
+ ret = run_init_process(init_filename);
+
+ if (ret && ret != -ENOENT) {
+ pr_err("Starting init: %s exists but couldn't execute it\n",
+ init_filename);
+ }
+
+ return ret;
+}
+
static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
@@ -843,13 +857,13 @@ static int __ref kernel_init(void *unused)
pr_err("Failed to execute %s. Attempting defaults...\n",
execute_command);
}
- if (!run_init_process("/sbin/init") ||
- !run_init_process("/etc/init") ||
- !run_init_process("/bin/init") ||
- !run_init_process("/bin/sh"))
+ if (!try_to_run_init_process("/sbin/init") ||
+ !try_to_run_init_process("/etc/init") ||
+ !try_to_run_init_process("/bin/init") ||
+ !try_to_run_init_process("/bin/sh"))
return 0;
- panic("No init found. Try passing init= option to kernel. "
+ panic("No working init found. Try passing init= option to kernel. "
"See Linux Documentation/init.txt for guidance.");
}
--
1.8.1.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: [RFC][PATCH 4/7] sched: power: Remove power capacity hints for kworker threads
On Thu, Oct 17, 2013 at 06:18:38PM +0100, Arjan van de Ven wrote: > >> > >> cpufreq has pre- and post-change notifiers so the current TC2 clock driver > > yeah those are EVIL ;-) > > >> waits (yields) in its clk_set_rate() implementation until the change has > >> happened to ensure that the post-change notifier happens at the right > >> time. Since clk_set_rate() is allowed to sleep other tasks may be > >> running while waiting for the change to complete. This may be true for > >> other clock drivers as well. > >> > >> AFAICT, there is no way to reuse the existing cpufreq drivers in a > >> sensible way for scheduler driven frequency scaling. > > that's the conclusion we came to as well about a year ago (and is also > why we're no longer using cpufreq core for the Intel pstate driver. > the locking/sleeping/callback/cpuhotplug/sysfs/etc stuff is just a MESS > for something that ends up being extremely simple if you just code the > sequence... for us it's just one register write to change... which shows this > as an > extreme obviously) We should be able to boil it down to a sequence on ARM as well. But it means dropping cpufreq and looking at the clock framework. Are you still using the pre- and post-change notifiers on Intel, or can they be ignored safely? > > > > > > Note that you still have preemption disabled in your late callback from > > finish_task_switch(). There's no way you can wait/yield/whatever from > > there. Nor is that really sane. > > the other fun one with this could be that if you have a series of > scheduleable tasks > for changing stuff somehow you want to keep ordering in the requests, and > only do > the last one/etc. > Not Fun(tm) Agreed, I don't want to go there. Also, the overhead will probably kill any benefit that there might be. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/7] arm64: introduce interfaces to hotpatch kernel and module code
Hi Tixy, On Thu, Oct 17, 2013 at 04:24:01PM +0100, Jon Medhurst (Tixy) wrote: > On Thu, 2013-10-17 at 12:38 +0100, Will Deacon wrote: > > On Thu, Oct 17, 2013 at 07:19:35AM +0100, Jiang Liu wrote: > > > + /* > > > + * Execute __aarch64_insn_patch_text() on every online CPU, > > > + * which ensure serialization among all online CPUs. > > > + */ > > > + return stop_machine(aarch64_insn_patch_text_cb, &patch, NULL); > > > +} > > > > Whoa, whoa, whoa! The comment here is wrong -- we only run the patching on > > *one* CPU, which is the right thing to do. However, the arch/arm/ call to > > stop_machine in kprobes does actually run the patching code on *all* the > > online cores (including the cache flushing!). I think this is to work around > > cores without hardware cache maintenance broadcasting, but that could easily > > be called out specially (like we do in patch.c) and the flushing could be > > separated from the patching too. > [...] > > For code modifications done in 32bit ARM kprobes (and ftrace) I'm not > sure we ever actually resolved the possible cache flushing issues. If > there was specific reasons for flushing on all cores I can't remember > them, sorry. I have a suspicion that doing so was a case of sticking > with what the code was already doing, and flushing on all cores seemed > safest to guard against problems we hadn't thought about. [...] > Sorry, I don't think I've added much light on things here have I? I think you missed the bit I was confused about :) Flushing the cache on each core is necessary if cache_ops_need_broadcast, so I can understand why you'd have code to do that. The bit I don't understand is that you actually patch the instruction on each core too! Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init: make init failures more explicit
Fantastic
I've been hurt by this in the past
- and this patch would certainly would have helped save some time!
--
Kieran
On 18 October 2013 09:47, Michael Opdenacker
wrote:
> This patch proposes to make init failures more explicit.
>
> Before this, the "No init found" message didn't help much.
> It could sometimes be misleading and actually mean
> "No *working* init found".
>
> This message could hide many different issues:
> - no init program candidates found at all
> - some init program candidates exist but can't be executed
> (missing execute permissions, failed to load shared libraries,
> executable compiled for an unknown architecture...)
>
> This patch notifies the kernel user when a candidate
> init program is found but can't be executed. It also replaces
> "No init found" by "No working init found", which is more correct.
>
> This will help embedded Linux developers (especially the new comers),
> regularly making and debugging new root filesystems.
>
> Signed-off-by: Michael Opdenacker
> ---
> init/main.c | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index 63d3e8f..a9a2833 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -811,6 +811,20 @@ static int run_init_process(const char *init_filename)
> (const char __user *const __user *)envp_init);
> }
>
> +static int try_to_run_init_process(const char *init_filename)
> +{
> + int ret;
> +
> + ret = run_init_process(init_filename);
> +
> + if (ret && ret != -ENOENT) {
> + pr_err("Starting init: %s exists but couldn't execute it\n",
> + init_filename);
> + }
> +
> + return ret;
> +}
> +
> static noinline void __init kernel_init_freeable(void);
>
> static int __ref kernel_init(void *unused)
> @@ -843,13 +857,13 @@ static int __ref kernel_init(void *unused)
> pr_err("Failed to execute %s. Attempting defaults...\n",
> execute_command);
> }
> - if (!run_init_process("/sbin/init") ||
> - !run_init_process("/etc/init") ||
> - !run_init_process("/bin/init") ||
> - !run_init_process("/bin/sh"))
> + if (!try_to_run_init_process("/sbin/init") ||
> + !try_to_run_init_process("/etc/init") ||
> + !try_to_run_init_process("/bin/init") ||
> + !try_to_run_init_process("/bin/sh"))
> return 0;
>
> - panic("No init found. Try passing init= option to kernel. "
> + panic("No working init found. Try passing init= option to kernel. "
> "See Linux Documentation/init.txt for guidance.");
> }
>
> --
> 1.8.1.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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
module: Documentation/module-signing.txt?
Rusty,
Since v3.7 there's a link to Documentation/module-signing.txt in
init/Kconfig. It was added by your commit 106a4ee258d1 ("module:
signature checking hook"). It seems that this file was never added to
the tree. Is it perhaps queued somewhere?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/6] ARM: at91/dt: define sama5d3 clocks
On 11/10/2013 14:43, Boris BREZILLON :
Define sama5d3 clocks in sama5d3 device tree.
Add references to the appropriate clocks in each peripheral.
Signed-off-by: Boris BREZILLON
good:
Acked-by: Nicolas Ferre
---
arch/arm/boot/dts/sama5d3.dtsi | 331 ++-
arch/arm/boot/dts/sama5d3_can.dtsi | 18 ++
arch/arm/boot/dts/sama5d3_emac.dtsi | 10 ++
arch/arm/boot/dts/sama5d3_gmac.dtsi | 10 ++
arch/arm/boot/dts/sama5d3_lcd.dtsi | 15 ++
arch/arm/boot/dts/sama5d3_mci2.dtsi | 11 ++
arch/arm/boot/dts/sama5d3_tcb1.dtsi | 12 ++
arch/arm/boot/dts/sama5d3_uart.dtsi | 19 ++
8 files changed, 425 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 5cdaba4..c4dad3b 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
/ {
model = "Atmel SAMA5D3 family SoC";
@@ -56,6 +57,14 @@
reg = <0x2000 0x800>;
};
+ clocks {
+ adc_op_clk: adc_op_clk{
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2000>;
+ };
+ };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
@@ -79,6 +88,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ clocks = <&periph 21>;
+ clock-names = "mci_clk";
};
spi0: spi@f0004000 {
@@ -92,6 +103,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi0>;
+ clocks = <&periph 24>;
+ clock-names = "spi_clk";
status = "disabled";
};
@@ -101,6 +114,8 @@
interrupts = <38 IRQ_TYPE_LEVEL_HIGH 4>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+ clocks = <&periph 38>;
+ clock-names = "pclk";
status = "disabled";
};
@@ -108,6 +123,8 @@
compatible = "atmel,at91sam9x5-tcb";
reg = <0xf001 0x100>;
interrupts = <26 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&periph 26>;
+ clock-names = "t0_clk";
};
i2c0: i2c@f0014000 {
@@ -121,6 +138,7 @@
pinctrl-0 = <&pinctrl_i2c0>;
#address-cells = <1>;
#size-cells = <0>;
+ clocks = <&periph 18>;
status = "disabled";
};
@@ -135,6 +153,7 @@
pinctrl-0 = <&pinctrl_i2c1>;
#address-cells = <1>;
#size-cells = <0>;
+ clocks = <&periph 19>;
status = "disabled";
};
@@ -144,6 +163,8 @@
interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart0>;
+ clocks = <&periph 12>;
+ clock-names = "usart";
status = "disabled";
};
@@ -153,6 +174,8 @@
interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart1>;
+ clocks = <&periph 13>;
+ clock-names = "usart";
status = "disabled";
};
@@ -174,6 +197,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ clocks = <&periph 22>;
+ clock-names = "mci_clk";
};
spi1: spi@f8008000 {
@@ -187,6 +212,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi1>;
+
Re: [PATCH v2 6/6] ARM: at91/dt: remove old clk material
On 11/10/2013 14:43, Boris BREZILLON :
This patch removes the old main clk node which is now useless as sama5d3
SoCs and boards are no longer compatible with the old at91 clk
implementations.
It also remove old clock definitions (clock definitions using at91 old clk
framework).
Signed-off-by: Boris BREZILLON
Happy to see all these lines removed!
Acked-by: Nicolas Ferre
I am looking forward the same result on other SoCs.
---
arch/arm/boot/dts/sama5d3xcm.dtsi | 11 --
arch/arm/mach-at91/sama5d3.c | 346 -
2 files changed, 357 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3xcm.dtsi
b/arch/arm/boot/dts/sama5d3xcm.dtsi
index dce5419..f55ed07 100644
--- a/arch/arm/boot/dts/sama5d3xcm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xcm.dtsi
@@ -18,17 +18,6 @@
reg = <0x2000 0x2000>;
};
- clocks {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- main_clock: clock@0 {
- compatible = "atmel,osc", "fixed-clock";
- clock-frequency = <1200>;
- };
- };
-
ahb {
apb {
spi0: spi@f0004000 {
diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
index 3426098..ae58fea 100644
--- a/arch/arm/mach-at91/sama5d3.c
+++ b/arch/arm/mach-at91/sama5d3.c
@@ -21,349 +21,6 @@
#include "generic.h"
#include "sam9_smc.h"
-#if defined(CONFIG_OLD_CLK_AT91)
-#include "clock.h"
-/*
- * Clocks
- * */
-
-/*
- * The peripheral clocks.
- */
-
-static struct clk pioA_clk = {
- .name = "pioA_clk",
- .pid= SAMA5D3_ID_PIOA,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
- .name = "pioB_clk",
- .pid= SAMA5D3_ID_PIOB,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
- .name = "pioC_clk",
- .pid= SAMA5D3_ID_PIOC,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioD_clk = {
- .name = "pioD_clk",
- .pid= SAMA5D3_ID_PIOD,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioE_clk = {
- .name = "pioE_clk",
- .pid= SAMA5D3_ID_PIOE,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
- .name = "usart0_clk",
- .pid= SAMA5D3_ID_USART0,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart1_clk = {
- .name = "usart1_clk",
- .pid= SAMA5D3_ID_USART1,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart2_clk = {
- .name = "usart2_clk",
- .pid= SAMA5D3_ID_USART2,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart3_clk = {
- .name = "usart3_clk",
- .pid= SAMA5D3_ID_USART3,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk uart0_clk = {
- .name = "uart0_clk",
- .pid= SAMA5D3_ID_UART0,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk uart1_clk = {
- .name = "uart1_clk",
- .pid= SAMA5D3_ID_UART1,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi0_clk = {
- .name = "twi0_clk",
- .pid= SAMA5D3_ID_TWI0,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi1_clk = {
- .name = "twi1_clk",
- .pid= SAMA5D3_ID_TWI1,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi2_clk = {
- .name = "twi2_clk",
- .pid= SAMA5D3_ID_TWI2,
- .type = CLK_TYPE_PERIPHERAL,
- .div= AT91_PMC_PCR_DIV2,
-};
-static struct clk mmc0_clk = {
- .name = "mci0_clk",
- .pid= SAMA5D3_ID_HSMCI0,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc1_clk = {
- .name = "mci1_clk",
- .pid= SAMA5D3_ID_HSMCI1,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc2_clk = {
- .name = "mci2_clk",
- .pid= SAMA5D3_ID_HSMCI2,
- .type = CLK_TYPE_PERIPHERAL,
-};
-static struc
[PATCH v6] media: st-rc: Add ST remote control driver
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP (IRB) is common across all the ST
parts for settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
This driver adds only Rx functionality via LIRC codec.
Signed-off-by: Srinivas Kandagatla
Acked-by: Sean Young
---
Hi Chehab,
This is a very simple rc driver for IRB controller found in STi SOCs.
This driver is a raw driver which feeds data to lirc codec for the user lircd
to decode the keys.
Am happy to prefix "rx-mode" and "tx-mode" device tree properties with "st", if
you think these can not be generic properties.
Changes since v5:
- removed redundancy error checks and using small letters
for hex as suggested by Prabhakar L.
- make tx-mode and rx-mode more descriptive.
Changes since v4:
- updated dt bindings doc with suggestions from Stephen W.
Changes since v3:
- updated dt bindings doc with suggestions from Mark R.
Changes since v2:
- Updated Kconfig dependencies as suggested by Sean and Chehab.
- Fixed a logical check spoted by Sean.
Changes since v1:
- Device tree bindings cleaned up as suggested by Mark and Pawel
- use ir_raw_event_reset under overflow conditions as suggested by Sean.
- call ir_raw_event_handle in interrupt handler as suggested by Sean.
- correct allowed_protos flag with RC_BIT_ types as suggested by Sean.
- timeout and rx resolution added as suggested by Sean.
Thankyou all for reviewing and commenting.
I would like to get this driver at least in 3.13.
Thanks,
srini
Documentation/devicetree/bindings/media/st-rc.txt | 29 ++
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/st_rc.c | 395 +
4 files changed, 435 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
create mode 100644 drivers/media/rc/st_rc.c
diff --git a/Documentation/devicetree/bindings/media/st-rc.txt
b/Documentation/devicetree/bindings/media/st-rc.txt
new file mode 100644
index 000..05c432d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st-rc.txt
@@ -0,0 +1,29 @@
+Device-Tree bindings for ST IRB IP
+
+Required properties:
+ - compatible: Should contain "st,comms-irb".
+ - reg: Base physical address of the controller and length of memory
+ mapped region.
+ - interrupts: interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the interrupt
+ controller parent.
+ - rx-mode: can be "infrared" or "uhf". This property specifies the L1
+ protocol used for receiving remote control signals. rx-mode should
+ be present iff the rx pins are wired up.
+ - tx-mode: should be "infrared". This property specifies the L1
+ protocol used for transmitting remote control signals. tx-mode should
+ be present iff the tx pins are wired up.
+
+Optional properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure muxing
+ properly for IRB pins.
+ - clocks : phandle with clock-specifier pair for IRB.
+
+Example node:
+
+ rc: rc@fe518000 {
+ compatible = "st,comms-irb";
+ reg = <0xfe518000 0x234>;
+ interrupts = <0 203 0>;
+ rx-mode = "infrared";
+ };
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 11e84bc..904f113 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -322,4 +322,14 @@ config IR_GPIO_CIR
To compile this driver as a module, choose M here: the module will
be called gpio-ir-recv.
+config RC_ST
+ tristate "ST remote control receiver"
+ depends on ARCH_STI && RC_CORE
+ help
+Say Y here if you want support for ST remote control driver
+which allows both IR and UHF RX.
+The driver passes raw pulse and space information to the LIRC decoder.
+
+If you're not sure, select N here.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 56bacf0..f4eb32c 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
+obj-$(CONFIG_RC_ST) += st_rc.o
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
new file mode 100644
index 000..65120c2
--- /dev/null
+++ b/drivers/media/rc/st_rc.c
@@ -0,0 +1,395 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Srinivas Kandagatla
+ *
+ * This program is free software; you can r
Re: [PATCH] init: fix in-place parameter modification regression
On Fri, Oct 18, 2013 at 02:20:38PM +1030, Rusty Russell wrote:
> Back when there was almost no parameter parsing support, everyone got
> used to keeping pointers into the original. Making everyone kstrdup()
> seems like gratuitous churn which is likely to make more bugs.
>
> Your fix means __setup() gets treated specially, in that only it can
> mangle the command line. That makes sense. But it introduces another
> regression: normal parsing functions can't keep pointers, since that's
> now __initdata.
>
> There are two possible solutions:
> (1) Audit all __setup to make sure they copy if they want to mangle.
> There are about 750 of them, but many are trivial.
> (2) alloc_bootmem() a third commandline for parsing.
>
> Now, many functions of form __setup("XXX=") should be turned into
> module_param anyway.
>
> I suggest we do (2) for the moment, and start sweeping through cleaning
> up __setup() in the longer term.
>
Yes, the buffer cannot be __initdata. I'm sending an updated patch.
However, keeping pointers to buffer, that will be reinitialized
in next initcall parameters parsing pass, might cause some race
conditions.
Thanks,
Krzysiek
-- >8 --
Subject: [PATCH v2] init: fix in-place parameter modification regression
Before commit 026cee0086fe1df4cf74691cf273062cc769617d
("params: _initcall-like kernel parameters") the __setup
parameter parsing code could modify parameter in the
static_command_line buffer and such modifications were kept. After
that commit such modifications are destroyed during per-initcall level
parameter parsing because the same static_command_line buffer is used
and only parameters for appropriate initcall level are parsed.
That change broke at least parsing "ubd" parameter in the ubd driver
when the COW file is used.
Now the separate buffer is used for per-initcall parameter parsing.
Signed-off-by: Krzysztof Mazur
---
init/main.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/init/main.c b/init/main.c
index 63d3e8f..c093b5c 100644
--- a/init/main.c
+++ b/init/main.c
@@ -132,6 +132,8 @@ char __initdata boot_command_line[COMMAND_LINE_SIZE];
char *saved_command_line;
/* Command line for parameter parsing */
static char *static_command_line;
+/* Command line for per-initcall parameter parsing */
+static char *initcall_command_line;
static char *execute_command;
static char *ramdisk_execute_command;
@@ -348,6 +350,7 @@ static inline void smp_prepare_cpus(unsigned int maxcpus) {
}
static void __init setup_command_line(char *command_line)
{
saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
+ initcall_command_line = alloc_bootmem(strlen (boot_command_line)+1);
static_command_line = alloc_bootmem(strlen (command_line)+1);
strcpy (saved_command_line, boot_command_line);
strcpy (static_command_line, command_line);
@@ -745,9 +748,9 @@ static void __init do_initcall_level(int level)
extern const struct kernel_param __start___param[], __stop___param[];
initcall_t *fn;
- strcpy(static_command_line, saved_command_line);
+ strcpy(initcall_command_line, saved_command_line);
parse_args(initcall_level_names[level],
- static_command_line, __start___param,
+ initcall_command_line, __start___param,
__stop___param - __start___param,
level, level,
&repair_env_string);
--
1.8.4.1.635.g6a5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/9] Extended H/W error log driver
On Fri, Oct 18, 2013 at 04:23:35AM -0400, Chen, Gong wrote: > OK, this is the 3rd version. Hope it is the last one :-). It looks ok to me so far, I'm guessing Tony you're picking this up or should I? > this version just updates some minors places and apply some Ack/Review > information. In this version I remove the last patch for trace > interface. Maybe it is time to build a new RAS trace interface to > integrate all RAS related error report interfaces now. Yeah, let's start small here by moving the CREATE_TRACE_POINTS macro definition to something like arch/x86/ras/core.c and work slowly up from there. We have ras_event.h for tracepoints already. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] init: make init failures more explicit
On Fri, Oct 18, 2013 at 10:47 AM, Michael Opdenacker
wrote:
> + if (ret && ret != -ENOENT) {
> + pr_err("Starting init: %s exists but couldn't execute it\n",
I think it makes sense to also print the value of ret here.
Apart from your -ENOEXEC case, peeking a bit around, it can be also be
-EINVAL, -ENOMEM (debug binary too big for small embedded system?),
-EACCES, -E2BIG, ...
> + init_filename);
> + }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] f2fs: use true and false for boolean value
Signed-off-by: Haicheng Li --- fs/f2fs/segment.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 3b20359..862fef3 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -1277,9 +1277,9 @@ static bool flush_sits_in_journal(struct f2fs_sb_info *sbi) __mark_sit_entry_dirty(sbi, segno); } update_sits_in_cursum(sum, -sits_in_cursum(sum)); - return 1; + return true; } - return 0; + return false; } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] f2fs: no need to check other dirty_segmap when the seg has been found
Because one dirty seg can only be mapped to one dirty_type. Otherwise, it's a
bug.
Signed-off-by: Haicheng Li
---
fs/f2fs/segment.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 862fef3..5ff0524 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -79,9 +79,13 @@ static void __remove_dirty_segment(struct f2fs_sb_info *sbi,
unsigned int segno,
enum dirty_type t = DIRTY_HOT_DATA;
/* clear all the bitmaps */
- for (; t <= DIRTY_COLD_NODE; t++)
- if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
+ for (; t <= DIRTY_COLD_NODE; t++) {
+ if (test_and_clear_bit(segno,
+ dirty_i->dirty_segmap[t])) {
dirty_i->nr_dirty[t]--;
+ break;
+ }
+ }
if (get_valid_blocks(sbi, segno, sbi->segs_per_sec) == 0)
clear_bit(GET_SECNO(sbi, segno),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Build error for nommu if CONFIG_DEBUG_ATOMIC_SLEEP is selected
Hi Michael, I got below build error for nommu if CONFIG_DEBUG_ATOMIC_SLEEP is selected. Also got the same build error if CONFIG_PROVE_LOCKING is selected. Seems this issue is introduced by commit 662bbcb2747c2 "mm, sched: Allow uaccess in atomic with pagefault_disable()". arch/arm/kernel/built-in.o: In function `arch_ptrace': arch/arm/kernel/ptrace.c:852: undefined reference to `might_fault' arch/arm/kernel/built-in.o: In function `restore_sigframe': arch/arm/kernel/signal.c:173: undefined reference to `might_fault' arch/arm/kernel/signal.c:174: undefined reference to `might_fault' arch/arm/kernel/signal.c:175: undefined reference to `might_fault' arch/arm/kernel/signal.c:176: undefined reference to `might_fault' arch/arm/kernel/built-in.o:arch/arm/kernel/signal.c:177: more undefined references to `might_fault' follow make: *** [vmlinux] Error 1 Regards, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] init: make init failures more explicit
Hi Geert,
On 10/18/2013 11:23 AM, Geert Uytterhoeven wrote:
> On Fri, Oct 18, 2013 at 10:47 AM, Michael Opdenacker
> wrote:
>> + if (ret && ret != -ENOENT) {
>> + pr_err("Starting init: %s exists but couldn't execute it\n",
> I think it makes sense to also print the value of ret here.
> Apart from your -ENOEXEC case, peeking a bit around, it can be also be
> -EINVAL, -ENOMEM (debug binary too big for small embedded system?),
> -EACCES, -E2BIG, ...
I agree. It would definitely make sense. I'll propose a new version.
Many thanks!
Cheers,
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] mfd: tc3589x: detect the precise version
On Wed, Oct 16, 2013 at 11:23 AM, Lee Jones wrote:
> On Tue, 15 Oct 2013, Linus Walleij wrote:
>> static const struct i2c_device_id tc3589x_id[] = {
>> - { "tc3589x", 24 },
>> + { "tc35890", TC3589X_TC35890 },
>> + { "tc35892", TC3589X_TC35892 },
>> + { "tc35893", TC3589X_TC35893 },
>> + { "tc35894", TC3589X_TC35894 },
>> + { "tc35895", TC3589X_TC35895 },
>> + { "tc35896", TC3589X_TC35896 },
>> + { "tc3589x", TC3589X_UNKNOWN },
>> { }
>> };
>> MODULE_DEVICE_TABLE(i2c, tc3589x_id);
>
> This is an awful lot of code for what we're trying to achieve.
I am not only trying to achive setting the number of GPIOs right,
I want the system to be aware of exactly which version of the chip
it is dealing with because they all have subtle differences, and
people will run into this in the future when adding more features.
http://www.toshiba-components.com/mobile/data/General_Presentation_IO_Expander_www_Jan_2012.pdf
See table on p.14 for example.
> 1. I guess that other OSes will need to capture the same
> information, so wouldn't it be prudant to do so via a DT property?
> That way it's just a one or two liner.
This patch is not about Device Tree. It is about probing from
the device name.
> 2. As we're only using .driver_data for num_gpio at this time, just
> place them in tc3589x_id as you have done for tc3589x.
This doesn't scale to the other pecularities that differ and I
then just push the problem onto the next person dealing with
this chip.
> 3. Again, as all of this extra code is only used for pulling out
> num_gpio, group the devices by num_gpio:
>
>> + switch (id->driver_data) {
>> + case TC3589X_TC35893:
>> + case TC3589X_TC35895:
>> + case TC3589X_TC35896:
>> + tc3589x->num_gpio = 20;
>> + break;
>> + case TC3589X_TC35890:
>> + case TC3589X_TC35892:
>> + case TC3589X_TC35894:
>> + case TC3589X_UNKNOWN:
>> + default:
>> + tc3589x->num_gpio = 24;
>> + break;
>> + }
This I can do. The switch tree can then be extended as need
be in the future.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] init: make init failures more explicit
On Fri, Oct 18, 2013 at 11:47 AM, Michael Opdenacker
wrote:
> This patch proposes to make init failures more explicit.
>
> Before this, the "No init found" message didn't help much.
> It could sometimes be misleading and actually mean
> "No *working* init found".
Heh, I was just looking at similar thing, except in my case dumping
out the execve error code would be the key (now I'm getting -ENOEXEC
back from init exec for no obvious reason). In case something like
this is getting merged I'd appreciate -errno dump as well.
diff --git a/init/main.c b/init/main.c
index 63d3e8f..56fb84a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -815,6 +815,8 @@ static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
{
+ int err;
+
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
@@ -826,9 +828,11 @@ static int __ref kernel_init(void *unused)
flush_delayed_fput();
if (ramdisk_execute_command) {
- if (!run_init_process(ramdisk_execute_command))
+ err = run_init_process(ramdisk_execute_command);
+ if (!err)
return 0;
- pr_err("Failed to execute %s\n", ramdisk_execute_command);
+ pr_err("Failed to execute %s, error: %d\n",
+ ramdisk_execute_command, err);
}
/*
@@ -838,10 +842,12 @@ static int __ref kernel_init(void *unused)
* trying to recover a really broken machine.
*/
if (execute_command) {
- if (!run_init_process(execute_command))
+ err = run_init_process(execute_command);
+ if (!err)
return 0;
- pr_err("Failed to execute %s. Attempting defaults...\n",
- execute_command);
+ pr_err("Failed to execute %s, error: %d\n",
+ execute_command, err);
+ pr_err("Attempting defaults...\n");
}
if (!run_init_process("/sbin/init") ||
!run_init_process("/etc/init") ||
--
Janne
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: tc3589x: add device tree bindings
On Wed, Oct 16, 2013 at 11:08 AM, Lee Jones wrote: > 1. MFD patches have the following syntax: > mfd: [-sub]: /* Note the uppercase 'D' */ Sure fixed this. > 2. The binding document is normally attached to the patch which > applies the bindings, unless we've stopped doing that now. This is a bit of special case since we already have "sort-of" device tree support on this driver. commit a435ae1d51e2f18414f2a87219fdbe068231e692 added some device tree support but no bindings. >> + >> +Example: >> + > > 3. You left off the example? OMG I'll fix. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts
Hi Doug,
On 10/16/2013 07:39 AM, Doug Anderson wrote:
> In the patch (9623b5b mmc: dw_mmc: Disable low power mode if SDIO
> interrupts are used) I added code that disabled the low power mode of
> dw_mmc when SDIO interrupts are used. That code worked but always
> felt a little hacky because we ended up disabling low power as a side
> effect of the first enable_sdio_irq() call. That wouldn't be so bad
> except that disabling low power involves a complicated process of
> writing to the CMD/CMDARG registers and that extra process makes it
> difficult to cleanly the read-modify-write race in
> dw_mci_enable_sdio_irq() (see future patch in the series).
>
> Change the code to take advantage of the init_card() callback of the
> mmc core to know when an SDIO card has been inserted. If we've got a
> SDIO card and we're configured to use SDIO Interrupts then turn off
> "low power mode" right away.
>
> Signed-off-by: Doug Anderson
> ---
> drivers/mmc/host/dw_mmc.c | 68
> ---
> drivers/mmc/host/dw_mmc.h | 1 +
> 2 files changed, 36 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 0a6a512..1b75816 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -822,7 +823,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
> bool force_clkinit)
>
> /* enable clock; only low power if no SDIO */
> clk_en_a = SDMMC_CLKEN_ENABLE << slot->id;
> - if (!(mci_readl(host, INTMASK) & SDMMC_INT_SDIO(slot->id)))
> + if (!test_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags))
> clk_en_a |= SDMMC_CLKEN_LOW_PWR << slot->id;
> mci_writel(host, CLKENA, clk_en_a);
>
> @@ -1050,27 +1051,37 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> return present;
> }
>
> -/*
> - * Disable lower power mode.
> - *
> - * Low power mode will stop the card clock when idle. According to the
> - * description of the CLKENA register we should disable low power mode
> - * for SDIO cards if we need SDIO interrupts to work.
> - *
> - * This function is fast if low power mode is already disabled.
> - */
> -static void dw_mci_disable_low_power(struct dw_mci_slot *slot)
> +static void dw_mci_init_card(struct mmc_host *mmc, struct mmc_card *card)
> {
> + struct dw_mci_slot *slot = mmc_priv(mmc);
> struct dw_mci *host = slot->host;
> - u32 clk_en_a;
> - const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
>
> - clk_en_a = mci_readl(host, CLKENA);
> + /*
> + * Low power mode will stop the card clock when idle. According to the
> + * description of the CLKENA register we should disable low power mode
> + * for SDIO cards if we need SDIO interrupts to work.
> + */
> + if (mmc->caps | MMC_CAP_SDIO_IRQ) {
mmc->caps & MMC_CAP_SDIO_IRQ?
> + const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
> + u32 clk_en_a_old;
> + u32 clk_en_a;
>
> - if (clk_en_a & clken_low_pwr) {
> - mci_writel(host, CLKENA, clk_en_a & ~clken_low_pwr);
> - mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
> - SDMMC_CMD_PRV_DAT_WAIT, 0);
> + clk_en_a_old = mci_readl(host, CLKENA);
> +
> + if (card->type == MMC_TYPE_SDIO ||
> + card->type == MMC_TYPE_SD_COMBO) {
> + set_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags);
> + clk_en_a = clk_en_a_old & ~clken_low_pwr;
> + } else {
> + clear_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags);
> + clk_en_a = clk_en_a_old | clken_low_pwr;
When this condition is entered? card->type is always MMC_TYPE_SDIO or
MMC_TYPE_SD_COMBO, isn't?
Best Regards,
Jaehoon Chung
> + }
> +
> + if (clk_en_a != clk_en_a_old) {
> + mci_writel(host, CLKENA, clk_en_a);
> + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
> + SDMMC_CMD_PRV_DAT_WAIT, 0);
> + }
> }
> }
>
> @@ -1082,21 +1093,11 @@ static void dw_mci_enable_sdio_irq(struct mmc_host
> *mmc, int enb)
>
> /* Enable/disable Slot Specific SDIO interrupt */
> int_mask = mci_readl(host, INTMASK);
> - if (enb) {
> - /*
> - * Turn off low power mode if it was enabled. This is a bit of
> - * a heavy operation and we disable / enable IRQs a lot, so
> - * we'll leave low power mode disabled and it will get
> - * re-enabled again in dw_mci_setup_bus().
> - */
> - dw_mci_disable_low_power(slot);
> -
> - mci_writel(host, INTMASK,
> -(int_mask | SDMMC_INT_SDIO(slot->id)));
> - }
Re: [PATCH] tracing: fix referencing after memory freeing and refactors code
2013/10/17 Steven Rostedt :
> On Thu, 17 Oct 2013 22:44:56 -0300
> "Geyslan G. Bem" wrote:
>
>> Restructures function logic conditions testing 'tracing_open_generic'
>> return before the others. It avoids: unnecessary trace_array_get and
>> kzalloc when tracing is disabled; and fix the possible 'dir'
>> assignment after freeing it.
>>
>> Centralizes the exiting, ensuring the 'trace_array_put' on error,
>> in accordance to Coding Style, Chapter 7.
>>
>> Signed-off-by: Geyslan G. Bem
>> ---
>> kernel/trace/trace_events.c | 22 --
>> 1 file changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
>> index 368a4d5..8232362 100644
>> --- a/kernel/trace/trace_events.c
>> +++ b/kernel/trace/trace_events.c
>> @@ -1108,26 +1108,28 @@ static int system_tr_open(struct inode *inode,
>> struct file *filp)
>> struct trace_array *tr = inode->i_private;
>> int ret;
>>
>> - if (trace_array_get(tr) < 0)
>> - return -ENODEV;
>> + ret = tracing_open_generic(inode, filp);
>> + if (ret)
>> + return ret;
>> +
>> + ret = trace_array_get(tr);
>> + if (ret)
>> + return ret;
>
> Hmm,
>
> I'm thinking of just nuking the tracing_open_generic() here. The only
> thing it does here is the tracing_disabled check. The assignment of
> inode->i_private to filp->private_data is pointless as it just
> reassigns it anyway.
>
> We could add a tracing_is_disabled() function to test instead.
Nice, I can do it.
Questions:
1267 static const struct file_operations ftrace_enable_fops = {
1268 .open = tracing_open_generic,
...
1286 static const struct file_operations ftrace_event_filter_fops = {
1287 .open = tracing_open_generic,
...
1317 static const struct file_operations ftrace_show_header_fops = {
1318 .open = tracing_open_generic,
Are that structures in same case? Their 'open' can be replaced to the
new 'tracing_is_disabled()?
I think that 'subsystem_open()' can be also refactored to use the
about to rise 'tracing_is_disabled()'. Am I right?
1096 ret = tracing_open_generic(inode, filp);
Regards,
-- Geyslan
>
> -- Steve
>
>>
>> /* Make a temporary dir that has no system but points to tr */
>> dir = kzalloc(sizeof(*dir), GFP_KERNEL);
>> if (!dir) {
>> - trace_array_put(tr);
>> - return -ENOMEM;
>> + ret = -ENOMEM;
>> + goto err_dir;
>> }
>>
>> dir->tr = tr;
>>
>> - ret = tracing_open_generic(inode, filp);
>> - if (ret < 0) {
>> - trace_array_put(tr);
>> - kfree(dir);
>> - }
>> -
>> filp->private_data = dir;
>> + return 0;
>>
>> +err_dir:
>> + trace_array_put(tr);
>> return ret;
>> }
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2] irqchip: mmp: add dt support for wakeup
Ping ?
> -Original Message-
> From: Neil Zhang [mailto:zhan...@marvell.com]
> Sent: 2013年10月11日 16:24
> To: linux-kernel@vger.kernel.org
> Cc: haojian.zhu...@gmail.com; t...@linutronix.de; Neil Zhang
> Subject: [PATCH 2/2 v2] irqchip: mmp: add dt support for wakeup
>
> Some of the Marvell SoCs use GIC as its interrupt controller,and ICU only
> used as
> wakeup logic. When AP subsystem is powered off, GIC will lose its context, the
> PMU will need ICU to wakeup the AP subsystem.
> So add wakeup entry for such kind of usage.
>
> Signed-off-by: Neil Zhang
> ---
> .../devicetree/bindings/arm/mrvl/intc.txt | 14 ++-
> drivers/irqchip/irq-mmp.c | 124
>
> include/linux/irqchip/mmp.h| 13 ++
> 3 files changed, 150 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 8b53273..4180928 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -2,7 +2,7 @@
>
> Required properties:
> - compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
> - "mrvl,mmp2-mux-intc"
> + "mrvl,mmp2-mux-intc", "mrvl,mmp-intc-wakeupgen"
> - reg : Address and length of the register set of the interrupt controller.
>If the interrupt controller is intc, address and length means the range
>of the whold interrupt controller. If the interrupt controller is
> mux-intc, @@
> -15,6 +15,9 @@ Required properties:
> - interrupt-controller : Identifies the node as an interrupt controller.
> - #interrupt-cells : Specifies the number of cells needed to encode an
>interrupt source.
> +- mrvl,intc-gbl-mask : Specifies the address and value for global mask
> +in the
> + interrupt controller.
> +- mrvl,intc-for-cp : Specifies the irqs that will be routed to cp
> - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
>controller.
> - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge @@
> -39,6 +42,15 @@ Example:
> mrvl,intc-nr-irqs = <2>;
> };
>
> + intc: wakeupgen@d4282000 {
> + compatible = "mrvl,mmp-intc-wakeupgen";
> + reg = <0xd4282000 0x1000>;
> + mrvl,intc-nr-irqs = <64>;
> + mrvl,intc-gbl-mask = <0x114 0x3
> + 0x144 0x3>;
> + mrvl,intc-for-cp = <0 31 32>;
> + };
> +
> * Marvell Orion Interrupt controller
>
> Required properties
> diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c index
> 470c5de..445a00c 100644
> --- a/drivers/irqchip/irq-mmp.c
> +++ b/drivers/irqchip/irq-mmp.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -58,6 +60,8 @@ struct mmp_intc_conf { static void __iomem
> *mmp_icu_base; static struct icu_chip_data icu_data[MAX_ICU_NR]; static
> int max_icu_nr;
> +static u32 irq_for_cp[64];
> +static u32 irq_for_cp_nr;/* How many irqs will be routed to cp */
>
> extern void mmp2_clear_pmic_int(void);
>
> @@ -123,6 +127,50 @@ static void icu_unmask_irq(struct irq_data *d)
> }
> }
>
> +static int irq_ignore_wakeup(struct icu_chip_data *data, int hwirq) {
> + int i;
> +
> + if (hwirq < 0 || hwirq >= data->nr_irqs)
> + return 1;
> +
> + for (i = 0; i < irq_for_cp_nr; i++)
> + if (irq_for_cp[i] == hwirq)
> + return 1;
> +
> + return 0;
> +}
> +
> +static void icu_mask_irq_wakeup(struct irq_data *d) {
> + struct icu_chip_data *data = &icu_data[0];
> + int hwirq = d->hwirq - data->virq_base;
> + u32 r;
> +
> + if (irq_ignore_wakeup(data, hwirq))
> + return;
> +
> + r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> + r &= ~data->conf_mask;
> + r |= data->conf_disable;
> + writel_relaxed(r, mmp_icu_base + (hwirq << 2)); }
> +
> +static void icu_unmask_irq_wakeup(struct irq_data *d) {
> + struct icu_chip_data *data = &icu_data[0];
> + int hwirq = d->irq - data->virq_base;
> + u32 r;
> +
> + if (irq_ignore_wakeup(data, hwirq))
> + return;
> +
> + r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> + r &= ~data->conf_mask;
> + r |= data->conf_enable;
> + writel_relaxed(r, mmp_icu_base + (hwirq << 2)); }
> +
> struct irq_chip icu_irq_chip = {
> .name = "icu_irq",
> .irq_mask = icu_mask_irq,
> @@ -491,5 +539,81 @@ err:
> irq_domain_remove(icu_data[i].domain);
> return -EINVAL;
> }
> +
> +void __init mmp_of_wakeup_init(void)
> +{
> + struct device_node *node;
> + const __be32 *wakeup_reg;
> + const __be32 *cp_irq_reg;
> + int ret, nr_irqs;
> + int size, i = 0;
> + int irq;
> +
> + node = of_find_compatible_node(NULL, NULL,
> "mrvl,mmp-intc-wakeupgen");
> +
Re: [PATCH 2/2] mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock
On 10/17/2013 05:23 AM, James Hogan wrote: > Hi Doug, > > On 16 October 2013 17:43, Doug Anderson wrote: >> On Wed, Oct 16, 2013 at 2:49 AM, James Hogan wrote: We can't just use the standard host->lock since that lock is not irq safe and mmc_signal_sdio_irq() (called from interrupt context) calls dw_mci_enable_sdio_irq(). Add a new irq-safe lock to protect INTMASK. An alternate solution to this is to punt mmc_signal_sdio_irq() to the tasklet and then protect INTMASK modifications by the standard host lock. This seemed like a bit more of a high-latency change. >>> >>> A probably lighter-weight alternative to that alternative is to just >>> make the existing lock irq safe. Has this been considered? >>> >>> I'm not entirely convinced it's worth having a separate lock rather than >>> changing the existing one, but the patch still appears to be correct, so: >>> Reviewed-by: James Hogan >> >> I did look at that alternate solution and rejected it, but am happy to >> send that up if people think it's better. Here's why I rejected it: >> >> 1. It looks like someone has gone through quite a bit of work to _not_ >> grab the existing lock in the IRQ handler. The IRQ handler always >> pushes all real work over to the tasklet. I can only assume that they >> did this for some good reason and I'd hate to switch it without >> knowing for sure why. >> >> 2. We might have performance problems if we blindly changed the >> existing code to an IRQ-safe spinlock. We hold the existing >> "host->lock" spinlock for the entire duration of >> dw_mci_tasklet_func(). That's a pretty intense chunk of code, full of >> nested loops (some with 500ms timeouts!), mdelay(20) calls to handle >> some errors, etc. I say "might" because I think that the expected >> case is that code runs pretty quickly. I ran some brief tests on one >> system and saw a worst case time of 170us and an common case time of >> ~10us. Are we OK with having interrupts disabled for that long? Are >> we OK with having the dw_mci interrupt handler potentially spin on a >> spinlock for that long? >> > > Fair enough, I'm convinced now. That code did look pretty heavy when I > looked at it too. > >> >> I don't think it would be terrible to look at reworking the way that >> dw_mmc handles interrupts, but that seems pretty major. Yes, Reworking is pretty major. but if we need to rework, i think we can rework it in future. > > Yeh, I suppose at least the potentially large delays are all for > exceptional cases, so it's not a critical problem. > >> BTW: is the cost of an extra lock actually that high? > > I don't know tbh. In this case the spinlock usage doesn't appear to > actually overlap. > >> ...or are you talking the cost in terms of code complexity? > > In this case it'd only be a space and code complexity thing I think. I > suppose in some cases the benefit of finer-grained locking is probably > pretty marginal, but there's a good case for it here. It might be > worth renaming the lock to irq_lock or something like that so it's > clear it doesn't have to protect only for INTMASK in the future - up > to you. It seems good that use the irq_lock than intmask_lock. (It's just naming) > > Cheers > James > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5 v2] mfd: tc3589x: Add device tree bindings
This defines the device tree bindings for the Toshiba TC3589x
series of multi-purpose expanders. Only the stuff I can test
is defined: GPIO and keypad. Others may implement more
subdevices further down the road.
This is to complement
commit a435ae1d51e2f18414f2a87219fdbe068231e692
"mfd: Enable the tc3589x for Device Tree" which left off
the definition of the device tree bindings.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Include a verbose example in the DT bindings.
- Explain why this is a stand-alone bindings patch.
---
Documentation/devicetree/bindings/mfd/tc3589x.txt | 107 ++
1 file changed, 107 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tc3589x.txt
diff --git a/Documentation/devicetree/bindings/mfd/tc3589x.txt
b/Documentation/devicetree/bindings/mfd/tc3589x.txt
new file mode 100644
index 000..565a426
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tc3589x.txt
@@ -0,0 +1,107 @@
+* Toshiba TC3589x multi-purpose expander
+
+The Toshiba TC3589x series are I2C-based MFD devices which may expose the
+following built-in devices: gpio, keypad, rotator (vibrator), PWM (for
+e.g. LEDs or vibrators) The included models are:
+
+- TC35890
+- TC35892
+- TC35893
+- TC35894
+- TC35895
+- TC35896
+
+Required properties:
+ - compatible : must be "toshiba,tc35890", "toshiba,tc35892",
"toshiba,tc35893",
+ "toshiba,tc35894", "toshiba,tc35895" or "toshiba,tc35896"
+ - reg : I2C address of the device
+ - interrupt-parent : specifies which IRQ controller we're connected to
+ - interrupts : the interrupt on the parent the controller is connected to
+ - interrupt-controller : marks the device node as an interrupt controller
+ - #interrupt-cells : should be <1>, the first cell is the IRQ offset on this
+ TC3589x interrupt controller.
+
+Optional nodes:
+
+- GPIO
+ This GPIO module inside the TC3589x has 24 (TC35890, TC35892) or 20
+ (other models) GPIO lines.
+ - compatible : must be "toshiba,tc3589x-gpio"
+ - interrupts : interrupt on the parent, which must be the tc3589x MFD device
+ - interrupt-controller : marks the device node as an interrupt controller
+ - #interrupt-cells : should be <2>, the first cell is the IRQ offset on this
+ TC3589x GPIO interrupt controller, the second cell is the interrupt flags
+ in accordance with . The following
+ flags are valid:
+ - IRQ_TYPE_LEVEL_LOW
+ - IRQ_TYPE_LEVEL_HIGH
+ - IRQ_TYPE_EDGE_RISING
+ - IRQ_TYPE_EDGE_FALLING
+ - IRQ_TYPE_EDGE_BOTH
+ - gpio-controller : marks the device node as a GPIO controller
+ - #gpio-cells : should be <2>, the first cell is the GPIO offset on this
+ GPIO controller, the second cell is the flags.
+
+- Keypad
+ This keypad is the same on all variants, supporting up to 96 different
+ keys. The linux-specific properties are modeled on those already existing
+ in other input drivers.
+ - compatible : must be "toshiba,tc3589x-keypad"
+ - debounce-delay-ms : debounce interval in milliseconds
+ - keypad,num-rows : number of rows in the matrix, see
+ bindings/input/matrix-keymap.txt
+ - keypad,num-columns : number of columns in the matrix, see
+ bindings/input/matrix-keymap.txt
+ - linux,keymap: the definition can be found in
+ bindings/input/matrix-keymap.txt
+ - linux,no-autorepeat: do no enable autorepeat feature.
+ - linux,wakeup: use any event on keypad as wakeup event.
+
+Example:
+
+tc35893@44 {
+ compatible = "toshiba,tc35893";
+ reg = <0x44>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <26 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ tc3589x_gpio {
+ compatible = "toshiba,tc3589x-gpio";
+ interrupts = <0>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ tc3589x_keypad {
+ compatible = "toshiba,tc3589x-keypad";
+ interrupts = <6>;
+ debounce-delay-ms = <4>;
+ keypad,num-columns = /bits/ 8 <8>;
+ keypad,num-rows = /bits/ 8 <8>;
+ linux,no-autorepeat;
+ linux,wakeup;
+ linux,keymap = <0x0301006b
+ 0x04010066
+ 0x06040072
+ 0x040200d7
+ 0x0303006a
+ 0x0205000e
+ 0x0607008b
+ 0x051c
+ 0x0403000b
+ 0x03040034
+ 0x05020067
+ 0x0305006c
+ 0x040500e7
+ 0x0005009e
+ 0x06020073
+ 0x01030039
+ 0x07060069
+ 0x050500d9>;
[PATCH 2/5 v2] mfd: tc3589x: Detect the precise version
Instead of detecting the "tc3589x" and hard-coding the number of
GPIO pins to 24, encode all the possible subtypes and set the
number of GPIO pins from the type.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Compress the switch tree to the two variables we currently
have to deal with.
---
drivers/mfd/tc3589x.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/tc3589x.c b/drivers/mfd/tc3589x.c
index 70f4909f..87ea51d 100644
--- a/drivers/mfd/tc3589x.c
+++ b/drivers/mfd/tc3589x.c
@@ -16,6 +16,19 @@
#include
#include
+/**
+ * enum tc3589x_version - indicates the TC3589x version
+ */
+enum tc3589x_version {
+ TC3589X_TC35890,
+ TC3589X_TC35892,
+ TC3589X_TC35893,
+ TC3589X_TC35894,
+ TC3589X_TC35895,
+ TC3589X_TC35896,
+ TC3589X_UNKNOWN,
+};
+
#define TC3589x_CLKMODE_MODCTL_SLEEP 0x0
#define TC3589x_CLKMODE_MODCTL_OPERATION (1 << 0)
@@ -361,7 +374,21 @@ static int tc3589x_probe(struct i2c_client *i2c,
tc3589x->i2c = i2c;
tc3589x->pdata = pdata;
tc3589x->irq_base = pdata->irq_base;
- tc3589x->num_gpio = id->driver_data;
+
+ switch (id->driver_data) {
+ case TC3589X_TC35893:
+ case TC3589X_TC35895:
+ case TC3589X_TC35896:
+ tc3589x->num_gpio = 20;
+ break;
+ case TC3589X_TC35890:
+ case TC3589X_TC35892:
+ case TC3589X_TC35894:
+ case TC3589X_UNKNOWN:
+ default:
+ tc3589x->num_gpio = 24;
+ break;
+ }
i2c_set_clientdata(i2c, tc3589x);
@@ -432,7 +459,13 @@ static int tc3589x_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(tc3589x_dev_pm_ops, tc3589x_suspend, tc3589x_resume);
static const struct i2c_device_id tc3589x_id[] = {
- { "tc3589x", 24 },
+ { "tc35890", TC3589X_TC35890 },
+ { "tc35892", TC3589X_TC35892 },
+ { "tc35893", TC3589X_TC35893 },
+ { "tc35894", TC3589X_TC35894 },
+ { "tc35895", TC3589X_TC35895 },
+ { "tc35896", TC3589X_TC35896 },
+ { "tc3589x", TC3589X_UNKNOWN },
{ }
};
MODULE_DEVICE_TABLE(i2c, tc3589x_id);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/7] arm64, jump label: optimize jump label implementation
Hi guys, On Fri, Oct 18, 2013 at 04:31:22AM +0100, Jiang Liu (Gerry) wrote: > On 2013/10/17 23:27, Steven Rostedt wrote: > > On Thu, 17 Oct 2013 22:40:32 +0800 > > Jiang Liu wrote: > > > > > > You could make the code more concise by limiting your patching ability > > to > > branch immediates. Then a nop is simply a branch to the next > > instruction (I > > doubt any modern CPUs will choke on this, whereas the architecture > > requires > > a NOP to take time). > I guess a NOP should be more effecient than a "B #4" on real CPUs:) > >>> > >>> Well, I was actually questioning that. A NOP *has* to take time (the > >>> architecture prevents implementations from discaring it) whereas a static, > >>> unconditional branch will likely be discarded early on by CPUs with even > >>> simple branch prediction logic. > >> I naively thought "NOP" is cheaper than a "B" :( > >> Will use a "B #1" to replace "NOP". > >> > > > > Really?? What's the purpose of a NOP then? It seems to me that an > > architecture is broken if a NOP is slower than a static branch. Cheers for making me double-check this: it turns out I was mixing up my architecture and micro-architecture. The architecture actually states: `The timing effects of including a NOP instruction in a program are not guaranteed. It can increase execution time, leave it unchanged, or even reduce it. Therefore, NOP instructions are not suitable for timing loops.' however I know of at least one micro-architecture where a NOP is actually more expensive than some other instructions, hence my original concerns. > I have discussed this with one of our chip design members. > He thinks "NOP" should be better than "B #1" because jump instruction > is one of the most complex instructions for microarchitecture, which > may stall the pipeline. And NOP should be friendly enough for all > microarchitectures. So I will keep the "NOP" version. Fine by me, we can't please all micro-architectures and NOP probably makes more sense. However, I would rather you rework your aarch64_insn_gen_nop function to actually generate hint instructions (since NOP is a hint alias in AArch64), where you specify the alias as a parameter. In other news, the GCC guys have started pushing a patch to add the %c output template to the AArch64 backend: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01314.html Cheers, and sorry for the earlier confusion, Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thermal: Fix binding problem when there is thermal zone params
The thermal zone params can be used to set governor
to specific thermal governor for thermal zone device.
But if the thermal zone params has only governor name
without thermal bind params, then the thermal zone device
will not be binding to cooling device. Because tz->ops->bind
operator is not invoked in bind_tz() and bind_cdev() when
there is thermal zone params.
Signed-off-by: Wei Ni
Signed-off-by: Jinyoung Park
---
drivers/thermal/thermal_core.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 4962a6a..2ea41d3 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -247,7 +247,7 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
if (!pos->tzp && !pos->ops->bind)
continue;
- if (!pos->tzp && pos->ops->bind) {
+ if (pos->ops->bind) {
ret = pos->ops->bind(pos, cdev);
if (ret)
print_bind_err_msg(pos, cdev, ret);
@@ -282,8 +282,8 @@ static void bind_tz(struct thermal_zone_device *tz)
mutex_lock(&thermal_list_lock);
- /* If there is no platform data, try to use ops->bind */
- if (!tzp && tz->ops->bind) {
+ /* If there is ops->bind, try to use ops->bind */
+ if (tz->ops->bind) {
list_for_each_entry(pos, &thermal_cdev_list, node) {
ret = tz->ops->bind(tz, pos);
if (ret)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] genirq: error reporting for non-percpu interrupt in request_percpu_irq()
Return a separate error code when a non-percpu interrupt is passed to request_percpu_irq(). Suggested-by: Will Deacon Signed-off-by: Vinayak Kale --- kernel/irq/manage.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 514bcfd..c2713ae 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1671,10 +1671,12 @@ int request_percpu_irq(unsigned int irq, irq_handler_t handler, return -EINVAL; desc = irq_to_desc(irq); - if (!desc || !irq_settings_can_request(desc) || - !irq_settings_is_per_cpu_devid(desc)) + if (!desc || !irq_settings_can_request(desc)) return -EINVAL; + if (!irq_settings_is_per_cpu_devid(desc)) + return -EPERM; + action = kzalloc(sizeof(struct irqaction), GFP_KERNEL); if (!action) return -ENOMEM; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x
On Fri, Oct 18, 2013 at 8:20 AM, NeilBrown wrote:
> On Sat, 5 Oct 2013 13:17:09 +0200 Andreas Fenkart wrote:
>
>> The am335x can't detect pending cirq in PM runtime suspend.
>> This patch reconfigures dat1 as a GPIO before going to suspend.
>> SDIO interrupts are detected with the GPIO, while in runtime
>> suspend, standard detection of the module block otherwise.
>>
>> Signed-off-by: Andreas Fenkart
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> index 1136e6b..146f3ad 100644
>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
>> ti,needs-special-reset: Requires a special softreset sequence
>> ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
>> High Speed
>> ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
>> -SDIO irq while in suspend. Fallback to polling. Affected chips are
>> -am335x,
>> +SDIO irq while in suspend. The workaround is to reconfigure the dat1 line
>> as a
>> +GPIO upon suspend. Beyond this option and the GPIO config, you also need to
>> set
>> +named pinctrl states "default", "active" and "idle ", see example below.
>> The
>> +MMC driver will then then toggle between default and idle during the runtime
>> +Affected chips are am335x,
>>
>> --
>> | PRCM |
>> @@ -49,3 +52,24 @@ Example:
>> vmmc-supply = <&vmmc>; /* phandle to regulator node */
>> ti,non-removable;
>> };
>> +
>> +[am335x with with gpio for sdio irq]
>> +
>> + mmc1_cirq_pin: pinmux_cirq_pin {
>> + pinctrl-single,pins = <
>> + 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
>> + >;
>> + };
>> +
>> + mmc1: mmc@4806 {
>> + ti,non-removable;
>> + bus-width = <4>;
>> + vmmc-supply = <&ldo2_reg>;
>> + vmmc_aux-supply = <&vmmc>;
>> + ti,quirk-swakeup-missing;
>> + pinctrl-names = "default", "active", "idle";
>> + pinctrl-0 = <&mmc1_pins>;
>> + pinctrl-1 = <&mmc1_pins>;
>> + pinctrl-2 = <&mmc1_cirq_pin>;
>> + ti,cirq-gpio = <&gpio3 28 0>;
>> + };
>
>
> hi,
> I've been trying to get SD irq to work on my OMAP3 DM3730.
> I seems to need the magic to catch interrupts while FCLK is off, as
> the only way I can get it to work at the moment is to keep FCLK on.
>
> I discovered your patch and tried it out, but it doesn't seem to work for me.
>
> I have a Libertas WIFI chip attached to the second mmc (which is sometimes
> called mmc1, and sometimes mmc2 - very confusing!).
Hi Neil,
I have a DM3730 board with the same setup, Libertas (Marvell SD8686)
wifi + bt chip attached to mmc2.
I was going to try to add support for this to the DTS but it would be
great if I can use your as a reference.
Would you be so kind to share your DTS?
Thanks a lot and best regards,
Javier
> I added:
> mmc2_cirq_pin: pinmux_cirq_pin {
> pinctrl-single,pins = <
> 0x012e (PIN_INPUT_PULLUP | MUX_MODE4) /* MMC2_DAT1
> as GPIO5_5 */
> >;
> };
>
> and
>
> &mmc2 {
> ti,quirk-swakeup-missing;
> pinctrl-names = "default", "active", "idle";
> pinctrl-0 = <&mmc2_pins>;
> pinctrl-1 = <&mmc2_pins>;
> pinctrl-2 = <&mmc2_cirq_pin>;
> ti,cirq-gpio = <&gpio5 5 0>; /* GPIO133 = 128+5 */
> };
>
> to my dts file but it doesn't make any apparent difference.
>
> Any idea what I might be doing wrong?
> (the base kernel I am applying patches to is from 8th Oct,
> commit 0e7a3ed04f0cd4311096d691888f88569310ee6c)
>
> BTW,
> - with the default polling, I get about 1Mb/sec with iperf
> - with sd-irq enabled and FCLK kept on the whole time, I get 4Mb/sec
> - with sd-irq enable, FCLK kept on, and the 5ms polling also
>running, I get over 5Mb/sec!
> Still much less than the 40Mb/sec that I would like to get...
>
> Thanks,
> NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] genirq: error reporting for non-percpu interrupt in request_percpu_irq()
Need for this patch is discussed in mail-thread [1]. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204414.html Thanks -Vinayak On Fri, Oct 18, 2013 at 3:36 PM, Vinayak Kale wrote: > Return a separate error code when a non-percpu interrupt is passed to > request_percpu_irq(). > > Suggested-by: Will Deacon > Signed-off-by: Vinayak Kale > --- > kernel/irq/manage.c |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c > index 514bcfd..c2713ae 100644 > --- a/kernel/irq/manage.c > +++ b/kernel/irq/manage.c > @@ -1671,10 +1671,12 @@ int request_percpu_irq(unsigned int irq, > irq_handler_t handler, > return -EINVAL; > > desc = irq_to_desc(irq); > - if (!desc || !irq_settings_can_request(desc) || > - !irq_settings_is_per_cpu_devid(desc)) > + if (!desc || !irq_settings_can_request(desc)) > return -EINVAL; > > + if (!irq_settings_is_per_cpu_devid(desc)) > + return -EPERM; > + > action = kzalloc(sizeof(struct irqaction), GFP_KERNEL); > if (!action) > return -ENOMEM; > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: SMMU: add devices attached to the SMMU to an IOMMU group
On Mon, Oct 14, 2013 at 7:07 PM, Will Deacon wrote:
> On Mon, Oct 14, 2013 at 04:13:15PM +0100, Antonios Motakis wrote:
>> On Mon, Oct 14, 2013 at 2:48 PM, Will Deacon wrote:
>> > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> > > index 0f45a48..8b71332 100644
>> > > --- a/drivers/iommu/arm-smmu.c
>> > > +++ b/drivers/iommu/arm-smmu.c
>> > > @@ -1502,6 +1502,8 @@ static int arm_smmu_add_device(struct device *dev)
>> > > {
>> > > struct arm_smmu_device *child, *parent, *smmu;
>> > > struct arm_smmu_master *master = NULL;
>> > > + struct iommu_group *group;
>> > > + int ret;
>> > >
>> > > spin_lock(&arm_smmu_devices_lock);
>> > > list_for_each_entry(parent, &arm_smmu_devices, list) {
>> > > @@ -1534,13 +1536,27 @@ static int arm_smmu_add_device(struct device
>> > > *dev)
>> > > if (!master)
>> > > return -ENODEV;
>> > >
>> > > + group = iommu_group_get(dev);
>> >
>> > I'm not especially familiar with IOMMU groups (I understand them as the
>> > minimum translation granularity, which would mean single StreamID for the
>> > ARM SMMU), but under what circumstances would you expect to receive a
>> > non-NULL group here? I can't see any other code adding devices to groups
>> > (outside of other drivers)...
>> >
>>
>> You are right, only other IOMMU drivers will add a device to a group.
>> There was a discussion about this when I posted a similar patch for
>> the Exynos System MMU driver, see
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185675.html
>>
>> The idea is to check in the case of add_device() being called multiple
>> times, which is not the case most of the time, but still a sane
>> safeguard.
>
> Ok, but it feels a bit weird. The current code (arm_smmu_add_device)
> basically does a bunch of sanity checking against the DT data in order to
> find where the master sits in the device topology. Then it updates
> dev->archdata.iommu to point at the relevant SMMU instance.
>
> So, the interesting case is where the device was previously associated with
> a *different* IOMMU. In that case, the current code clobbers the iommu field
> with the new smmu, whereas the new code could end up getting very confused
> with respect to IOMMU groups.
>
> A better way is probably to check that dev->archdata.iommu is NULL before we
> assign to it. If not, then spit out a warning and return an error. That
> would also mean you could get rid of the group get/put calls.
>
Good point, this is a better way to handle this. I'll respin based on this.
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: error reporting for non-percpu interrupt in request_percpu_irq()
On Fri, Oct 18, 2013 at 11:06:29AM +0100, Vinayak Kale wrote: > Return a separate error code when a non-percpu interrupt is passed to > request_percpu_irq(). > > Suggested-by: Will Deacon > Signed-off-by: Vinayak Kale > --- > kernel/irq/manage.c |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c > index 514bcfd..c2713ae 100644 > --- a/kernel/irq/manage.c > +++ b/kernel/irq/manage.c > @@ -1671,10 +1671,12 @@ int request_percpu_irq(unsigned int irq, > irq_handler_t handler, > return -EINVAL; > > desc = irq_to_desc(irq); > - if (!desc || !irq_settings_can_request(desc) || > - !irq_settings_is_per_cpu_devid(desc)) > + if (!desc || !irq_settings_can_request(desc)) > return -EINVAL; > > + if (!irq_settings_is_per_cpu_devid(desc)) > + return -EPERM; I reckon -ENODEV is clearer here. Also, there's a counterpart to this code in request_threaded_irq, where I think we should do something similar. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] mfd: max77693: Include linux/of.h header
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat Cc: SangYoung, Son --- drivers/mfd/max77693.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c index 4d81ed2..9f92463 100644 --- a/drivers/mfd/max77693.c +++ b/drivers/mfd/max77693.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5 v2] mfd: tc3589x: Detect the precise version
On Fri, 18 Oct 2013, Linus Walleij wrote: > Instead of detecting the "tc3589x" and hard-coding the number of > GPIO pins to 24, encode all the possible subtypes and set the > number of GPIO pins from the type. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Compress the switch tree to the two variables we currently > have to deal with. So you chose my least favourite alternative. ;) > --- > drivers/mfd/tc3589x.c | 37 +++-- > 1 file changed, 35 insertions(+), 2 deletions(-) Anyway... patch applied. -- 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/5] mfd: tc3589x: detect the precise version
Whoops, read this after. Fair enough. -- 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] x86: honor ACPI FADT flag indicating absence of a CMOS RTC
* Jan Beulich wrote: > >>> On 18.10.13 at 08:29, Ingo Molnar wrote: > > * Jan Beulich wrote: > > > >> We shouldn't be creating a corresponding platform device in that case. > > > > There's a sad lack of context in the changelog, how was it found, does > > this address any problem/bug observed in practice, etc? > > This was a result from code review in Xen hypervisor code in the context > of ACPI 5 work there, which lead me to check whether Linux would honor > that flag. No known issue in practice so far. Once the below got > clarified, I can certainly extend the description in an eventual > resubmission (albeit I would have though that fixing the not honoring of > a firmware flag should speak for itself). I thought we've been through this before, firmware related changes never 'speak for themselves'! The quality and effect of firmware flags varies wildly (sometimes they are good and avoid problems, sometimes they are crap and cause problems) and it's important to know the full context. So in this area there's no such thing as being overly verbose in a changelog. > >> +#ifdef CONFIG_ACPI > >> + if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) > >> + return -ENODEV; > >> +#endif > > > > It might also be prudent to emit a KERN_INFO line telling that we don't > > create the device - so that people who suddenly see unexpected breakage or > > change in behavior have a chance to see what we've done? > > There are so many other -ENODEV return paths here which don't > emit messages that this seemed inappropriate, the more that a > message _is_ being issued if the platform RTC device does get > registered (and hence one could judge by the message > disappearing between before and after the patch got applied). I'm trying to be conservative and protect users against potential bad side effects of such a change. It's routine. We can mark it as temporary and zap it a few kernel releases later. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tracing: fix referencing after memory freeing and refactors code
2013/10/18 Geyslan Gregório Bem :
> 2013/10/17 Steven Rostedt :
>> On Thu, 17 Oct 2013 22:44:56 -0300
>> "Geyslan G. Bem" wrote:
>>
>>> Restructures function logic conditions testing 'tracing_open_generic'
>>> return before the others. It avoids: unnecessary trace_array_get and
>>> kzalloc when tracing is disabled; and fix the possible 'dir'
>>> assignment after freeing it.
>>>
>>> Centralizes the exiting, ensuring the 'trace_array_put' on error,
>>> in accordance to Coding Style, Chapter 7.
>>>
>>> Signed-off-by: Geyslan G. Bem
>>> ---
>>> kernel/trace/trace_events.c | 22 --
>>> 1 file changed, 12 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
>>> index 368a4d5..8232362 100644
>>> --- a/kernel/trace/trace_events.c
>>> +++ b/kernel/trace/trace_events.c
>>> @@ -1108,26 +1108,28 @@ static int system_tr_open(struct inode *inode,
>>> struct file *filp)
>>> struct trace_array *tr = inode->i_private;
>>> int ret;
>>>
>>> - if (trace_array_get(tr) < 0)
>>> - return -ENODEV;
>>> + ret = tracing_open_generic(inode, filp);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = trace_array_get(tr);
>>> + if (ret)
>>> + return ret;
>>
>> Hmm,
>>
>> I'm thinking of just nuking the tracing_open_generic() here. The only
>> thing it does here is the tracing_disabled check. The assignment of
>> inode->i_private to filp->private_data is pointless as it just
>> reassigns it anyway.
>>
>> We could add a tracing_is_disabled() function to test instead.
>
> Nice, I can do it.
>
> Questions:
I realized that here not:
>
> 1267 static const struct file_operations ftrace_enable_fops = {
> 1268 .open = tracing_open_generic,
> ...
> 1286 static const struct file_operations ftrace_event_filter_fops = {
> 1287 .open = tracing_open_generic,
> ...
> 1317 static const struct file_operations ftrace_show_header_fops = {
> 1318 .open = tracing_open_generic,
Tell me about this other case:
>
> Are that structures in same case? Their 'open' can be replaced to the
> new 'tracing_is_disabled()?
>
> I think that 'subsystem_open()' can be also refactored to use the
> about to rise 'tracing_is_disabled()'. Am I right?
> 1096 ret = tracing_open_generic(inode, filp);
Regards,
-- Geyslan
>
>>
>> -- Steve
>>
>>>
>>> /* Make a temporary dir that has no system but points to tr */
>>> dir = kzalloc(sizeof(*dir), GFP_KERNEL);
>>> if (!dir) {
>>> - trace_array_put(tr);
>>> - return -ENOMEM;
>>> + ret = -ENOMEM;
>>> + goto err_dir;
>>> }
>>>
>>> dir->tr = tr;
>>>
>>> - ret = tracing_open_generic(inode, filp);
>>> - if (ret < 0) {
>>> - trace_array_put(tr);
>>> - kfree(dir);
>>> - }
>>> -
>>> filp->private_data = dir;
>>> + return 0;
>>>
>>> +err_dir:
>>> + trace_array_put(tr);
>>> return ret;
>>> }
>>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] genirq: error reporting for non-percpu interrupt in request_percpu_irq()
Hi Will, On Fri, Oct 18, 2013 at 4:01 PM, Will Deacon wrote: > On Fri, Oct 18, 2013 at 11:06:29AM +0100, Vinayak Kale wrote: >> Return a separate error code when a non-percpu interrupt is passed to >> request_percpu_irq(). >> >> Suggested-by: Will Deacon >> Signed-off-by: Vinayak Kale >> --- >> kernel/irq/manage.c |6 -- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c >> index 514bcfd..c2713ae 100644 >> --- a/kernel/irq/manage.c >> +++ b/kernel/irq/manage.c >> @@ -1671,10 +1671,12 @@ int request_percpu_irq(unsigned int irq, >> irq_handler_t handler, >> return -EINVAL; >> >> desc = irq_to_desc(irq); >> - if (!desc || !irq_settings_can_request(desc) || >> - !irq_settings_is_per_cpu_devid(desc)) >> + if (!desc || !irq_settings_can_request(desc)) >> return -EINVAL; >> >> + if (!irq_settings_is_per_cpu_devid(desc)) >> + return -EPERM; > > I reckon -ENODEV is clearer here. I looked at the issue as "operation not allowed since interrupt is non-percpu" and I found below comment for EPERM in 'include/uapi/asm-generic/errno-base.h' . So thought this error code could be more fitting. #define EPERM1 /* Operation not permitted */ > > Also, there's a counterpart to this code in request_threaded_irq, where I > think we should do something similar. So in request_threaded_irq, we would still keep the WARN_ON for percpu interrupt and return a different error code. Is my understanding correct? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 8/8] ACPI / trace: Add trace interface for eMCA driver
On 10/16/2013 04:19 PM, Borislav Petkov wrote: Btw, I don't know what's the problem but when I hit reply-to-all to your emails, mutt drops your email address from the To: and makes the CC: list become the To: list. Strange. I'm seeing the same thing. Looking at the headers, Chen Gong's email includes a Mail-Follow-Up field which could be the problem. - Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] USB: OHCI: Properly handle ohci-s3c2410 suspend
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-s3c2410 suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Acked-by: Alan Stern
Cc: Greg KH
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
V2->V3:
-No changes.
As a build failure on "ep93xx proper suspend patch" and Linaro
id bounced. Rewrote this patch on top of latest Greg usb-next
branch. This patch not gives any build error. Patch is required
for ohci-s3c2410 proper suspending as Alan mentioned.
Initially when I wrote this patch I was working in Linaro, now
I am not part of Linaro that is why Linaro id is bouncing. Sending
this patch from personal mail id.
V1->V2:
-No changes.
Due to the build failure on ep93xx reverted this patch.
This patch is needed as Alan Stern suggestion.
drivers/usb/host/ohci-s3c2410.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index be3429e..b5bf9b7 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -426,28 +426,15 @@ static int ohci_hcd_s3c2410_drv_remove(struct
platform_device *pdev)
static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
- unsigned long flags;
+ bool do_wakeup = device_may_wakeup(dev);
int rc = 0;
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(&ohci->lock, flags);
- if (ohci->rh_state != OHCI_RH_SUSPENDED) {
- rc = -EINVAL;
- goto bail;
- }
-
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc)
+ return rc;
s3c2410_stop_hc(pdev);
-bail:
- spin_unlock_irqrestore(&ohci->lock, flags);
return rc;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 5/6] USB: OHCI: Properly handle ohci-exynos suspend
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-exynos suspend scenario.
Calling explicitly the ohci_suspend() routine in
exynos_ohci_suspend() will ensure proper handling of suspend
scenario.
Signed-off-by: Manjunath Goudar
Acked-by: Alan Stern
Cc: Arnd Bergmann
Cc: Greg KH
Cc: Kukjin Kim
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
V2->V3:
-No changes.
As a build failure on "ep93xx proper suspend patch"
and Linaro id bounced. Rewrote this patch on top of latest
Greg usb-next branch. This patch not gives any build error.
Patch is required for ohci-exynos proper suspending as Alan
mentioned.
Initially when I wrote this patch I was working in Linaro,
now I am not part of Linaro that is why Linaro id is bouncing.
Sending this patch from personal mail id.
V1->V2:
-No changes.
Due to the build failure on ep93xx reverted this patch.
This patch is needed as Alan Stern suggestion.
drivers/usb/host/ohci-exynos.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index a87baed..4b5c8bd 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -192,23 +192,14 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+ bool do_wakeup = device_may_wakeup(dev);
unsigned long flags;
- int rc = 0;
+ int rc = ohci_suspend(hcd, do_wakeup);
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(&ohci->lock, flags);
- if (ohci->rh_state != OHCI_RH_SUSPENDED &&
- ohci->rh_state != OHCI_RH_HALTED) {
- rc = -EINVAL;
- goto fail;
- }
+ if (rc)
+ return rc;
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+ spin_lock_irqsave(&ohci->lock, flags);
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
@@ -217,10 +208,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci->clk);
-fail:
spin_unlock_irqrestore(&ohci->lock, flags);
- return rc;
+ return 0;
}
static int exynos_ohci_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] ACPI, CPER: Update cper info
Gong, This mail seems to have missed copying you given the header issues. Thanks, Naveen On 10/17/2013 05:51 PM, Naveen N. Rao wrote: On 10/16/2013 07:09 AM, Chen Gong wrote: On Tue, Oct 15, 2013 at 11:47:23PM +0530, Naveen N. Rao wrote: Date: Tue, 15 Oct 2013 23:47:23 +0530 From: "Naveen N. Rao" To: "Chen, Gong" Cc: tony.l...@intel.com, b...@alien8.de, linux-kernel@vger.kernel.org, linux-a...@vger.kernel.org Subject: Re: [PATCH 2/8] ACPI, CPER: Update cper info User-Agent: Mutt/1.5.21 (2010-09-15) On 2013/10/11 02:32AM, Chen Gong wrote: To satisfy the necessary of following patches and make related definition more clear, update some definitions about CPER. No functional changes. Signed-off-by: Chen, Gong --- drivers/acpi/apei/apei-internal.h | 12 - drivers/acpi/apei/cper.c | 46 - drivers/acpi/apei/ghes.c | 54 +++ include/acpi/actbl1.h | 14 +- include/acpi/ghes.h | 2 +- 5 files changed, 64 insertions(+), 64 deletions(-) diff --git a/drivers/acpi/apei/apei-internal.h b/drivers/acpi/apei/apei-internal.h index f220d64..21ba34a 100644 --- a/drivers/acpi/apei/apei-internal.h +++ b/drivers/acpi/apei/apei-internal.h @@ -122,11 +122,11 @@ struct dentry; struct dentry *apei_get_debugfs_dir(void); #define apei_estatus_for_each_section(estatus, section)\ -for (section = (struct acpi_hest_generic_data *)(estatus + 1);\ +for (section = (struct acpi_generic_data *)(estatus + 1);\ This is a good one to rename, though I wonder if acpi_generic_error_data is more appropriate? (void *)section - (void *)estatus < estatus->data_length;\ section = (void *)(section+1) + section->error_data_length) -static inline u32 apei_estatus_len(struct acpi_hest_generic_status *estatus) +static inline u32 cper_estatus_len(struct acpi_generic_status *estatus) Not sure I understand the rationale for these changes - we are still dealing with ACPI/APEI generic error status/data structures. So, why the cper_ prefix? Because CPER is not APEI specific, beside APEI, some others like eMCA needs this. Right, but even the document you point to refers to these structures as what they are: ACPI Generic error status/data. Clearly, CPER is an incorrect prefix here since CPER/UEFI does *not* seem to have the same structure format. Regards, Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] netfilter: fix ordering of jumpstack allocation and table update
On Thu, Oct 17, 2013 at 02:24:33PM +0100, Will Deacon wrote: > During kernel stability testing on an SMP ARMv7 system, Yalin Wang > reported the following panic from the netfilter code: > > 1fe0: 001c 5e2d3b10 4007e779 4009e110 6010 0032 ff565656 > ff545454 > [] (ipt_do_table+0x448/0x584) from [] > (nf_iterate+0x48/0x7c) > [] (nf_iterate+0x48/0x7c) from [] > (nf_hook_slow+0x58/0x104) > [] (nf_hook_slow+0x58/0x104) from [] > (ip_local_deliver+0x88/0xa8) > [] (ip_local_deliver+0x88/0xa8) from [] > (ip_rcv_finish+0x418/0x43c) > [] (ip_rcv_finish+0x418/0x43c) from [] > (__netif_receive_skb+0x4cc/0x598) > [] (__netif_receive_skb+0x4cc/0x598) from [] > (process_backlog+0x84/0x158) > [] (process_backlog+0x84/0x158) from [] > (net_rx_action+0x70/0x1dc) > [] (net_rx_action+0x70/0x1dc) from [] > (__do_softirq+0x11c/0x27c) > [] (__do_softirq+0x11c/0x27c) from [] > (do_softirq+0x44/0x50) > [] (do_softirq+0x44/0x50) from [] > (local_bh_enable_ip+0x8c/0xd0) > [] (local_bh_enable_ip+0x8c/0xd0) from [] > (inet_stream_connect+0x164/0x298) > [] (inet_stream_connect+0x164/0x298) from [] > (sys_connect+0x88/0xc8) > [] (sys_connect+0x88/0xc8) from [] > (ret_fast_syscall+0x0/0x30) > Code: 2a21 e59d2028 e59de01c e59f011c (e7824103) > ---[ end trace da227214a82491bd ]--- > Kernel panic - not syncing: Fatal exception in interrupt > > This comes about because CPU1 is executing xt_replace_table in response > to a setsockopt syscall, resulting in: > > ret = xt_jumpstack_alloc(newinfo); > --> newinfo->jumpstack = kzalloc(size, GFP_KERNEL); > > [...] > > table->private = newinfo; > newinfo->initial_entries = private->initial_entries; > > Meanwhile, CPU0 is handling the network receive path and ends up in > ipt_do_table, resulting in: > > private = table->private; > > [...] > > jumpstack = (struct ipt_entry **)private->jumpstack[cpu]; > > On weakly ordered memory architectures, the writes to table->private > and newinfo->jumpstack from CPU1 can be observed out of order by CPU0. > Furthermore, on architectures which don't respect ordering of address > dependencies (i.e. Alpha), the reads from CPU0 can also be re-ordered. > > This patch adds an smp_wmb() before the assignment to table->private > (which is essentially publishing newinfo) to ensure that all writes to > newinfo will be observed before plugging it into the table structure. > A dependent-read barrier is also added on the consumer side, to ensure > the same ordering requirement are also respected there. We also need fixes for net/ipv6/netfilter/ip6_tables.c and net/ipv4/netfilter/arp_tables.c as well. Could you extend this patch and resend? Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mm/pagewalk.c: Fix walk_page_range access wrong PTEs
linx.z.chen@ wrote: > From: Chen LinX > > When walk_page_range walk a memory map's page tables, it'll skip VM_PFNMAP > area, > then variable 'next' will to assign to vma->vm_end, it maybe larger than > 'end'. > In next loop, 'addr' will be larger than 'next'. Then in /proc//pagemap > file > reading procedure, the 'addr' will growing forever in pagemap_pte_range, > pte_to_pagemap_entry will access wrong pte. > > [ 93.387934] BUG: Bad page map in process procrank pte:8437526f > pmd:785de067 > [ 93.387936] addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping: > (null) index:9108d > [ 93.387938] CPU: 1 PID: 4974 Comm: procrank Tainted: GB W O 3.10.1+ > #1 > [ 93.387942] f0d983c8 f0d983c8 e8271e48 c281ef4b e8271e84 c20ee794 > c2a3f150 9108d000 > [ 93.387946] 00200073 f0d99020 0009108d e8342d90 8437526f > 0009108d > [ 93.387950] 00084375 fffa4234 e8271e98 c20ef836 > e8271f28 f0d983c8 > [ 93.387951] Call Trace: > [ 93.387953] [] dump_stack+0x16/0x18 > [ 93.387956] [] print_bad_pte+0x114/0x1b0 > [ 93.387959] [] vm_normal_page+0x56/0x60 > [ 93.387961] [] pagemap_pte_range+0x17a/0x1d0 > [ 93.387963] [] ? m_next+0x70/0x70 > [ 93.387966] [] walk_page_range+0x19e/0x2c0 > [ 93.387969] [] ? ptrace_may_access+0x24/0x40 > [ 93.387971] [] pagemap_read+0x16e/0x200 > [ 93.387973] [] ? m_next+0x70/0x70 > [ 93.387976] [] ? quota_send_warning+0x1f0/0x1f0 > [ 93.387979] [] ? pagemap_pte_hole+0x50/0x50 > [ 93.387981] [] ? clear_refs_pte_range+0xc0/0xc0 > [ 93.387984] [] vfs_read+0x84/0x150 > [ 93.387986] [] ? clear_refs_pte_range+0xc0/0xc0 > [ 93.387988] [] SyS_read+0x4a/0x80 > [ 93.387991] [] syscall_call+0x7/0xb > [ 93.387996] [] ? e1000_regdump+0x6f/0x37c > [ 102.866190] [] ? cpuidle_idle_call+0x93/0x1b0 > [ 102.872124] [] ? atomic_notifier_call_chain+0x1a/0x20 > [ 102.878834] [] ? arch_cpu_idle+0x8/0x20 > [ 102.884183] [] ? cpu_startup_entry+0x4d/0x1b0 > [ 102.890116] [] ? rest_init+0x5d/0x60 > [ 102.895174] [] ? start_kernel+0x31b/0x321 > [ 102.900717] [] ? repair_env_string+0x51/0x51 > [ 102.906551] [] ? i386_start_kernel+0x12c/0x12f > > Signed-off-by: Liu ShuoX > Signed-off-by: Chen LinX Looks reasonable for me. Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3] New descriptor-based GPIO interface
On Thu, Oct 17, 2013 at 7:21 PM, Alexandre Courbot wrote: > Hi Linus, > > This version should merge as-is in your tree (I hope!). A patch for > documentation will follow soon. > > Changes since v2: > - rebased on top of Linus' for-next branch > - exported new gpiod_(un)lock_as_irq() functions in driver.h > - squashed a fix for a compilation error Thanks, let's see if I can get this into v3.13, right now it's unclear if I'll dare to do this. These do not apply right off as it requires the late fixes to the gpiod code which currently are in Torvalds' tree and on my fixes branch, so I'll merge in v3.12-rc6 as it arrives, and then attempt to apply this on top, but I don't know if I dare to do this so late. The outage of linux-next also contributes to this situation. We might have to take this as the first thing after the merge window and targeted for v3.14. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] m68k/amiga: Provide mach_random_get_entropy()
Use the beam position registers, which provide at least 17 bits of data
changing at 1.79 MHz.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Use beam position registers (which provide a faster rate but less bits)
instead of 24-bit Time-Of-Day clock in CIA B running at HSYNC.
arch/m68k/amiga/config.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/m68k/amiga/config.c b/arch/m68k/amiga/config.c
index f78361bff623..0b46d32a345f 100644
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -354,6 +354,14 @@ static void __init amiga_identify(void)
#undef AMIGAHW_ANNOUNCE
}
+
+static unsigned long amiga_random_get_entropy(void)
+{
+ /* VPOSR/VHPOSR provide at least 17 bits of data changing at 1.79 MHz */
+ return *(unsigned long *)&amiga_custom.vposr;
+}
+
+
/*
* Setup the Amiga configuration info
*/
@@ -391,6 +399,8 @@ void __init config_amiga(void)
mach_heartbeat = amiga_heartbeat;
#endif
+ mach_random_get_entropy = amiga_random_get_entropy;
+
/* Fill in the clock value (based on the 700 kHz E-Clock) */
amiga_colorclock = 5*amiga_eclock; /* 3.5 MHz */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] m68k: Add infrastructure for machine-specific random_get_entropy()
On m68k, get_cycles() (the default implementation for random_get_entropy())
always returns zero, providing no entropy for the random driver.
Add a hook where platforms can provide their own implementation, and wire
it up in the infrastructure provided by commit
61875f30daf60305712e25b209ef41ced2635bad ("random: allow architectures to
optionally define random_get_entropy()").
Signed-off-by: Geert Uytterhoeven
---
v2:
- Hook for random_get_entropy() instead of get_cycles()
arch/m68k/include/asm/timex.h | 10 ++
arch/m68k/kernel/time.c |4
2 files changed, 14 insertions(+)
diff --git a/arch/m68k/include/asm/timex.h b/arch/m68k/include/asm/timex.h
index 6759dad954f6..efc1f4892357 100644
--- a/arch/m68k/include/asm/timex.h
+++ b/arch/m68k/include/asm/timex.h
@@ -28,4 +28,14 @@ static inline cycles_t get_cycles(void)
return 0;
}
+extern unsigned long (*mach_random_get_entropy)(void);
+
+static inline unsigned long random_get_entropy(void)
+{
+ if (mach_random_get_entropy)
+ return mach_random_get_entropy();
+ return 0;
+}
+#define random_get_entropy random_get_entropy
+
#endif
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 7eb9792009f8..958f1adb9d0c 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -28,6 +28,10 @@
#include
#include
+
+unsigned long (*mach_random_get_entropy)(void);
+
+
/*
* timer_interrupt() needs to keep up the real-time clock,
* as well as call the "xtime_update()" routine every clocktick
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 17
On 10/18/2013 12:45 AM, Olof Johansson wrote: On Fri, Oct 18, 2013 at 01:38:47AM +0100, Mark Brown wrote: Hi all, I've uploaded today's linux-next tree to the master branch of the repository below: git://gitorious.org/thierryreding/linux-next.git > A next-20131017 tag is also provided for convenience. One new conflict today but otherwise uneventful. x86_64 allmodconfigs build after each merge but no other build tests were done. Hi, I'm seeing a fairly large fallout on boot testing. See http://lists.linaro.org/pipermail/kernel-build-reports/2013-October/000719.html for full list (I need to start providing longer backlogs for failures, the top of the oopses is lost in the email). For example, on dove (SolidRun Cubox) I see: [0.707248] Unable to handle kernel NULL pointer dereference at virtual address 0054 [0.715297] pgd = c0004000 [0.717984] [0054] *pgd= [0.721548] Internal error: Oops: 5 [#1] ARM [0.725794] Modules linked in: [0.728841] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc5-next-20131017 #1 [0.736114] task: ef035c00 ti: ef036000 task.ti: ef036000 [0.741497] PC is at kfree+0x54/0xc4 [0.745063] LR is at ata_host_register+0x3c/0x290 [0.749741] pc : []lr : []psr: 4193 [0.749741] sp : ef037da8 ip : 0034 fp : [0.761159] r10: r9 : ef061810 r8 : c0519fc8 [0.766353] r7 : c0519fc8 r6 : a113 r5 : r4 : ef1c9dd0 [0.772850] r3 : c0fc8fe0 r2 : c07c9000 r1 : 4000 r0 : [0.779349] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [0.786708] Control: 10c5387d Table: 4019 DAC: 0015 [0.792428] Process swapper (pid: 1, stack limit = 0xef036248) [0.798234] Stack: (0xef037da8 to 0xef038000) [0.957218] [] (kfree+0x54/0xc4) from [] (ata_host_register+0x3c/0x290) [0.965542] [] (ata_host_register+0x3c/0x290) from [] (ata_host_activate+0xdc/0x118) [0.974992] [] (ata_host_activate+0xdc/0x118) from [] (mv_platform_probe+0x2dc/0x36c) [0.984527] [] (mv_platform_probe+0x2dc/0x36c) from [] (platform_drv_probe+0x18/0x48) [0.994051] [] (platform_drv_probe+0x18/0x48) from [] (really_probe+0x74/0x1fc) [1.003062] [] (really_probe+0x74/0x1fc) from [] (__driver_attach+0x98/0x9c) [1.011804] [] (__driver_attach+0x98/0x9c) from [] (bus_for_each_dev+0x60/0x94) [1.020808] [] (bus_for_each_dev+0x60/0x94) from [] (bus_add_driver+0x148/0x1f0) [1.029898] [] (bus_add_driver+0x148/0x1f0) from [] (driver_register+0x78/0xf8) [1.038911] [] (driver_register+0x78/0xf8) from [] (mv_init+0x30/0x50) [1.047144] [] (mv_init+0x30/0x50) from [] (do_one_initcall+0x100/0x14c) [1.07] [] (do_one_initcall+0x100/0x14c) from [] (kernel_init_freeable+0x120/0x1c0) [1.065259] [] (kernel_init_freeable+0x120/0x1c0) from [] (kernel_init+0x8/0x158) [1.074441] [] (kernel_init+0x8/0x158) from [] (ret_from_fork+0x14/0x3c) [1.082841] Code: e0823283 e3110902 1593301c e593001c (e5904054) My 'sh' qemu run fails with: BUG: unable to handle kernel paging request at 6e81 PC: [<8c1f10ce>] ata_finalize_port_ops+0x4e/0xc0 pgd = 8c401150 [6e81] *pgd= Oops: [#1] Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc5-next-20131017-06210-gdaa01b0 #1 task: 8fc27be0 ti: 8fc28000 task.ti: 8fc28000 PC is at ata_finalize_port_ops+0x4e/0xc0 PR is at ata_host_start+0x48/0x1c0 PC : 8c1f10ce SP : 8fc29e0c SR : 40008001 TEA : 6e81 R0 : R1 : 8fc83018 R2 : 6e81 R3 : R4 : 8fc83000 R5 : 00bc R6 : 6e69 R7 : 8fc830f0 R8 : 8fd47cac R9 : 8fd47cac R10 : R11 : 8c207d80 R12 : 8c1f1080 R13 : R14 : 0064 MACH: MACL: 0001 GBR : PR : 8c1f21e8 Call trace: [<8c1f807e>] ata_host_activate+0x1e/0x120 [<8c207d80>] ata_sff_interrupt+0x0/0x240 [<8c209ed6>] pata_platform_probe+0x76/0x120 [<8c209ed6>] pata_platform_probe+0x76/0x120 [<8c1cf440>] platform_get_resource+0x0/0x60 [<8c1cfeda>] platform_drv_probe+0x1a/0x60 [<8c012800>] arch_local_save_flags+0x0/0x20 [<8c1ce1ee>] driver_probe_device+0x6e/0x260 [<8c012820>] arch_local_irq_restore+0x0/0x40 [<8c1cc4c0>] klist_devices_put+0x0/0x20 [<8c1ce466>] __driver_attach+0x86/0xa0 [<8c2fa800>] mutex_lock+0x0/0x60 [<8c1cc8c8>] bus_for_each_dev+0x48/0x80 [<8c1cc620>] next_device+0x0/0x20 [<8c1ce3e0>] __driver_attach+0x0/0xa0 [<8c1cd862>] bus_add_driver+0xc2/0x220 [<8c1ce90c>] driver_register+0x4c/0x120 [<8c3eeccc>] pata_platform_driver_init+0x0/0x14 [<8c011244>] do_one_initcall+0x1c4/0x280 [<8c3eeccc>] pata_platform_driver_init+0x0/0x14 [<8c059160>] register_irq_proc+0x0/0xa0 [<8c10b6f0>] proc_create_data+0x50/0xe0 [<8c03f2b8>] parse_args+0x218/0x3a0 [<8c03f000>] parameq+0x0/0xa0 [<8c012820>] arch_local_irq_restore+0x0/0x40 [<8c3e0a06>] kernel_init_freeable+0xce/0x1c8 [<8c011080>] do_one_initcall+0x0/0x280 [<8c3e0158>] repair_env_string+0
Re: [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control
On Wed, Oct 09, 2013 at 01:17:30PM +0100, srinivas kandagatla wrote: > .../devicetree/bindings/media/remote-control.txt | 31 > > 1 files changed, 31 insertions(+), 0 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/media/remote-control.txt > > diff --git a/Documentation/devicetree/bindings/media/remote-control.txt > b/Documentation/devicetree/bindings/media/remote-control.txt > new file mode 100644 > index 000..901ea56 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/remote-control.txt > @@ -0,0 +1,31 @@ > +Generic device tree bindings for remote control. > + > +properties: > +- compatible: Can contain any remote control driver compatible > string. > + example: "st-comms-irb, "gpio-ir-receiver". > >>> > >>> This is more generic than remote control, could this not just be left > >>> for the specific binding to describe? > >>> > +- reg: Base physical address of the controller and length of > memory > + mapped region. > >>> > >>> What if it's on a bus that isn't memory mapped (e.g. i2c, SPI)? > >>> > +- interrupts: Interrupt-specifier for the sole interrupt > generated by > + the device. The interrupt specifier format depends on the > + interrupt controller parent. Iff the device supports > interrupts. > >>> > >>> What if it has multiple interrupts, and has interrupts-names? > > I think for properties like interrupts, reg can be left undocumented > here and let the actual device bindings document on this. If it has no particur meaning for the class of binding, leaving it to the individual device bindings seems fine to me. > > >>> > >>> It might be better to only describe the properties that relate > >>> specifically to remote controls, rather than listing all of the generic > >>> properties that device tree bidnings may have. That would match the > >>> style of the clock bindings. > >>> > +- rx-mode: Can be "infrared" or "uhf". rx-mode should be > present iff > + the rx pins are wired up. > >>> > >>> I'm unsure on this. What if the device has multiple receivers that can > >>> be independently configured? > > Mauro C. had an option that this is not a real use-case and let's not > overdesign the API, thinking on a possible scenario that may never happen. > > Do you still think that this use case should be considered in this > discussion? Given how simple a device we're attempting to describe, I'm not even sure it makes sense to have a class of binding. We could leave this to individual device bindings for the moment. > > >> > >> Well, if a given remote controller hardware has more than one independent > >> receiver (or transmitter), each one should have its own devnode. > >> Likely, two entries at DT. > > > > Why? If an IP block happens to have support for N connections, that > > doesn't mean that each must be described individually. They likely share > > a bank of registers, and depending on the device they might not even be > > assigned consistently orgranised windows of that register bank. > > > >> > >>> What if it supports something other than > >>> "infrared" or "uhf"? What if a device can only be wired up as > >>> "infrared"? > > I think "infrared" and "uhf" covers all the use cases for remote controls. > > If the device only supports one mode. It can be documented in device > specific bindings. something like phy-mode of ethernet bindings. Given there's the possibility of a device supporting one mode, I think it would make more sense to describe the *-mode properties in the specific bindings which require them (though they may be identical). > >> > >>> I'm not sure how generic these are, though we should certainly encourage > >>> bindings that can be described this way to be described in the same way. > >>> > +- tx-mode: Can be "infrared" or "uhf". tx-mode should be > present iff > + the tx pins are wired up. > >>> > >>> I have similar concerns here to those for the rx-mode property. > >>> > + > +Optional properties: > +- linux,rc-map-name: Linux specific remote control map name. > Refer to > + include/media/rc-map.h for full list of maps. > >>> > >>> We shouldn't refer to Linux specifics (i.e. headers) in general in > >>> bindings. While it's possible to relax that a bit for linux,* > >>> properties, I'd prefer to explicitly list elements in the binding. That > >>> prevents the ABI from changing under our feet by someone altering what > >>> looks like a completely internal header file. > >> > >> Well, the remote controller keymaps at include/media/rc-map.h is just a > >> bunch of string names, defined as macro to avoid duplicating those names > >> everywhere, to avoid typos and to help some userspace parsing logic
[PATCH] PM / Hibernate: Use bool for boolean fields of struct snapshot_data
From: Rafael J. Wysocki
The snapshot_data structure used internally by the hibernate user
space interface code in user.c has three char fields that are used
to store boolean values. Change their data type to bool and use
true and false instead of 1 and 0, respectively, in assignments
involving those fields.
Signed-off-by: Rafael J. Wysocki
---
kernel/power/user.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Index: linux-pm/kernel/power/user.c
===
--- linux-pm.orig/kernel/power/user.c
+++ linux-pm/kernel/power/user.c
@@ -36,9 +36,9 @@ static struct snapshot_data {
struct snapshot_handle handle;
int swap;
int mode;
- char frozen;
- char ready;
- char platform_support;
+ bool frozen;
+ bool ready;
+ bool platform_support;
bool free_bitmaps;
} snapshot_state;
@@ -93,9 +93,9 @@ static int snapshot_open(struct inode *i
if (error)
atomic_inc(&snapshot_device_available);
- data->frozen = 0;
- data->ready = 0;
- data->platform_support = 0;
+ data->frozen = false;
+ data->ready = false;
+ data->platform_support = false;
Unlock:
unlock_system_sleep();
@@ -229,7 +229,7 @@ static long snapshot_ioctl(struct file *
if (error)
thaw_processes();
else
- data->frozen = 1;
+ data->frozen = true;
break;
@@ -240,7 +240,7 @@ static long snapshot_ioctl(struct file *
free_basic_memory_bitmaps();
data->free_bitmaps = false;
thaw_processes();
- data->frozen = 0;
+ data->frozen = false;
break;
case SNAPSHOT_CREATE_IMAGE:
@@ -270,7 +270,7 @@ static long snapshot_ioctl(struct file *
case SNAPSHOT_FREE:
swsusp_free();
memset(&data->handle, 0, sizeof(struct snapshot_handle));
- data->ready = 0;
+ data->ready = false;
/*
* It is necessary to thaw kernel threads here, because
* SNAPSHOT_CREATE_IMAGE may be invoked directly after
@@ -334,7 +334,7 @@ static long snapshot_ioctl(struct file *
* PM_HIBERNATION_PREPARE
*/
error = suspend_devices_and_enter(PM_SUSPEND_MEM);
- data->ready = 0;
+ data->ready = false;
break;
case SNAPSHOT_PLATFORM_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/
[RFC][PATCH v5 03/14] sched: define pack buddy CPUs
During the creation of sched_domain, we define a pack buddy CPU for each CPU
when one is available. We want to pack at all levels where a group of CPUs can
be power gated independently from others.
On a system that can't power gate a group of CPUs independently, the flag is
set at all sched_domain level and the buddy is set to -1. This is the default
behavior for all architectures.
On a dual clusters / dual cores system which can power gate each core and
cluster independently, the buddy configuration will be :
| Cluster 0 | Cluster 1 |
| CPU0 | CPU1 | CPU2 | CPU3 |
---
buddy | CPU0 | CPU0 | CPU0 | CPU2 |
If the cores in a cluster can't be power gated independently, the buddy
configuration becomes:
| Cluster 0 | Cluster 1 |
| CPU0 | CPU1 | CPU2 | CPU3 |
---
buddy | CPU0 | CPU1 | CPU0 | CPU0 |
Signed-off-by: Vincent Guittot
---
kernel/sched/core.c |1 +
kernel/sched/fair.c | 70 ++
kernel/sched/sched.h |5
3 files changed, 76 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 735e964..0bf5f4d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5184,6 +5184,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
root_domain *rd, int cpu)
rcu_assign_pointer(rq->sd, sd);
destroy_sched_domains(tmp, cpu);
+ update_packing_domain(cpu);
update_top_cache_domain(cpu);
}
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 11cd136..5547831 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -178,6 +178,76 @@ void sched_init_granularity(void)
update_sysctl();
}
+#ifdef CONFIG_SMP
+#ifdef CONFIG_SCHED_PACKING_TASKS
+/*
+ * Save the id of the optimal CPU that should be used to pack small tasks
+ * The value -1 is used when no buddy has been found
+ */
+DEFINE_PER_CPU(int, sd_pack_buddy);
+
+/*
+ * Look for the best buddy CPU that can be used to pack small tasks
+ * We make the assumption that it doesn't wort to pack on CPU that share the
+ * same powerline. We look for the 1st sched_domain without the
+ * SD_SHARE_POWERDOMAIN flag. Then we look for the sched_group with the lowest
+ * power per core based on the assumption that their power efficiency is
+ * better
+ */
+void update_packing_domain(int cpu)
+{
+ struct sched_domain *sd;
+ int id = -1;
+
+ sd = highest_flag_domain(cpu, SD_SHARE_POWERDOMAIN);
+ if (!sd)
+ sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
+ else
+ sd = sd->parent;
+
+ while (sd && (sd->flags & SD_LOAD_BALANCE)
+ && !(sd->flags & SD_SHARE_POWERDOMAIN)) {
+ struct sched_group *sg = sd->groups;
+ struct sched_group *pack = sg;
+ struct sched_group *tmp;
+
+ /*
+* The sched_domain of a CPU points on the local sched_group
+* and this CPU of this local group is a good candidate
+*/
+ id = cpu;
+
+ /* loop the sched groups to find the best one */
+ for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
+ if (tmp->sgp->power * pack->group_weight >
+ pack->sgp->power * tmp->group_weight)
+ continue;
+
+ if ((tmp->sgp->power * pack->group_weight ==
+ pack->sgp->power * tmp->group_weight)
+&& (cpumask_first(sched_group_cpus(tmp)) >= id))
+ continue;
+
+ /* we have found a better group */
+ pack = tmp;
+
+ /* Take the 1st CPU of the new group */
+ id = cpumask_first(sched_group_cpus(pack));
+ }
+
+ /* Look for another CPU than itself */
+ if (id != cpu)
+ break;
+
+ sd = sd->parent;
+ }
+
+ pr_debug("CPU%d packing on CPU%d\n", cpu, id);
+ per_cpu(sd_pack_buddy, cpu) = id;
+}
+#endif /* CONFIG_SCHED_PACKING_TASKS */
+#endif /* CONFIG_SMP */
+
#if BITS_PER_LONG == 32
# define WMULT_CONST (~0UL)
#else
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b3c5653..22e3f1d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1022,6 +1022,11 @@ extern void update_group_power(struct sched_domain *sd,
int cpu);
extern void trigger_load_balance(struct rq *rq, int cpu);
extern void idle_balance(int this_cpu, struct rq *this_rq);
+#ifdef CONFIG_SCHED_PACKING_TASKS
+extern void update_packing_domain(int cpu);
+#else
+static inline void update_packing_domain(int cpu) {};
+#endif
extern void idle_enter_fair(struct rq *this_rq);
extern void idle_exit_fair(struct rq *this_rq);
--
1.7.9.5
--
To unsubscribe from this li
[RFC][PATCH v5 00/14] sched: packing tasks
This is the 5th version of the previously named "packing small tasks" patchset. "small" has been removed because the patchset doesn't only target small tasks anymore. This patchset takes advantage of the new per-task load tracking that is available in the scheduler to pack the tasks in a minimum number of CPU/Cluster/Core. The packing mechanism takes into account the power gating topology of the CPUs to minimize the number of power domains that need to be powered on simultaneously. Most of the code has been put in fair.c file but it can be easily moved to another location. This patchset tries to solve one part of the larger energy-efficient scheduling problem and it should be merged with other proposals that solve other parts like the power-scheduler made by Morten. The packing is done in 3 steps: The 1st step creates a topology of the power gating of the CPUs that will help the scheduler to choose which CPUs will handle the current activity. This topology is described thanks to a new flag SD_SHARE_POWERDOMAIN that indicates whether the groups of CPUs of a scheduling domain share their power state. In order to be efficient, a group of CPUs that share their power state will be used (or not) simultaneously. By default, this flag is set in all sched_domain in order to keep the current behavior of the scheduler unchanged. The 2nd step evaluates the current activity of the system and creates a list of CPUs for handling it. The average activity level of CPUs is set to 80% but is configurable by changing the sched_packing_level knob. The activity level and the involvement of a CPU in the packing effort is evaluated during the periodic load balance similarly to cpu_power. Then, the default load balancing behavior is used to balance tasks between this reduced list of CPUs. As the current activity doesn't take into account a new task, an unused CPUs can also be selected during the 1st wake up and until the activity is updated. The 3rd step occurs when the scheduler selects a target CPU for a newly awakened task. The current wakeup latency of idle CPUs is used to select the one with the most shallow c-state. In some situation where the task load is small compared to the latency, the newly awakened task can even stay on the current CPU. Since the load is the main metric for the scheduler, the wakeup latency is transposed into an equivalent load so that the current mechanism of the load balance that is based on load comparison, is kept unchanged. A shared structure has been created to exchange information between scheduler and cpuidle (or any other framework that needs to share information). The wakeup latency is the only field for the moment but it could be extended with additional useful information like the target load or the expected sleep duration of a CPU. The patchset is based on v3.12-rc2 and is available in the git tree: git://git.linaro.org/people/vingu/kernel.git branch sched-packing-small-tasks-v5 If you want to test the patchset, you must enable CONFIG_PACKING_TASKS first. Then, you also need to create a arch_sd_local_flags that will clear the SD_SHARE_POWERDOMAIN flag at the appropriate level for your architecture. This has already be done for ARM architecture in the patchset. The figures below show the latency of cyclictest with and without the patchset on an ARM platform with a v3.11. The test has been runned 10 times on each kernel. #cyclictest -t 3 -q -e 100 -l 3000 -i 1800 -d 100 average (us) stdev v3.11381,579,86 v3.11 + patches 173,83 13,62 Change since V4: - v4 posting:https://lkml.org/lkml/2013/4/25/396 - Keep only the aggressive packing mode. - Add a finer grain power domain description mechanism that includes DT description - Add a structure to share information with other framework - Use current wakeup latency of an idle CPU when selecting the target idle CPU - All the task packing mechanism can be disabled with a single config option Change since V3: - v3 posting: https://lkml.org/lkml/2013/3/22/183 - Take into account comments on previous version. - Add an aggressive packing mode and a knob to select between the various mode Change since V2: - v2 posting: https://lkml.org/lkml/2012/12/12/164 - Migrate only a task that wakes up - Change the light tasks threshold to 20% - Change the loaded CPU threshold to not pull tasks if the current number of running tasks is null but the load average is already greater than 50% - Fix the algorithm for selecting the buddy CPU. Change since V1: -v1 posting: https://lkml.org/lkml/2012/10/7/19 Patch 2/6 - Change the flag name which was not clear. The new name is SD_SHARE_POWERDOMAIN. - Create an architecture dependent function to tune the sched_domain flags Patch 3/6 - Fix issues in the algorithm that looks for the best buddy CPU - Use pr_debug instead of pr_info - Fix for uniprocessor Patch 4/6 - Remove the use of usage_avg_sum which has not been merged Patch 5/6 - C
[RFC][PATCH v5 10/14] sched: init this_load to max in find_idlest_group
Init this_load to max value instead of 0 in find_idlest_group.
If the local group is skipped because it doesn't have allowed CPUs, this_load
stays to 0, no idlest group will be returned and the selected CPU will be a
not allowed one (which will be replaced in select_fallback_rq by a random
one). With a default value set to max, we will use the idlest group even if we
skip the local_group.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f9b03c1..2d9f782 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3532,7 +3532,7 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p,
int this_cpu, int sd_flag)
{
struct sched_group *idlest = NULL, *group = sd->groups;
- unsigned long min_load = ULONG_MAX, this_load = 0;
+ unsigned long min_load = ULONG_MAX, this_load = ULONG_MAX;
int load_idx = sd->forkexec_idx;
int imbalance = 100 + (sd->imbalance_pct-100)/2;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: kirkwood: remove lagacy clk workarounds
With legacy devices converted to DT and a proper ethernet MAC
workaround, we can now remove the clk workarounds for legacy
devices. While at it, also cleanup the list of includes.
Signed-off-by: Sebastian Hesselbarth
---
As a follow-up patch for latest mvebu PRs, this patch is based on
git://git.infradead.org/linux-mvebu.git tags/soc-3.13-2
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Kevin Hilman
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-kirkwood/board-dt.c | 42 ++--
1 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index 27c1877..3f5984e 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -10,56 +10,22 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
-#include
-#include
-#include
+#include
#include
-#include
#include
-#include
-#include
#include
#include "common.h"
-/*
- * There are still devices that doesn't know about DT yet. Get clock
- * gates here and add a clock lookup alias, so that old platform
- * devices still work.
-*/
-
-static void __init kirkwood_legacy_clk_init(void)
-{
-
- struct device_node *np = of_find_compatible_node(
- NULL, NULL, "marvell,kirkwood-gating-clock");
- struct of_phandle_args clkspec;
- struct clk *clk;
-
- clkspec.np = np;
- clkspec.args_count = 1;
-
- /*
-* The ethernet interfaces forget the MAC address assigned by
-* u-boot if the clocks are turned off. Until proper DT support
-* is available we always enable them for now.
-*/
- clkspec.args[0] = CGC_BIT_GE0;
- clk = of_clk_get_from_provider(&clkspec);
- clk_prepare_enable(clk);
-
- clkspec.args[0] = CGC_BIT_GE1;
- clk = of_clk_get_from_provider(&clkspec);
- clk_prepare_enable(clk);
-}
-
#define MV643XX_ETH_MAC_ADDR_LOW 0x0414
#define MV643XX_ETH_MAC_ADDR_HIGH 0x0418
@@ -164,8 +130,6 @@ static void __init kirkwood_dt_init(void)
kirkwood_cpufreq_init();
kirkwood_cpuidle_init();
- /* Setup clocks for legacy devices */
- kirkwood_legacy_clk_init();
kirkwood_pm_init();
kirkwood_dt_eth_fixup();
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v5 09/14] sched: update the packing cpu list
Use the activity statistics to update the list of CPUs that should be used
to hanlde the current system activity.
The cpu_power is updated for CPUs that don't participate to the packing
effort. We consider that their cpu_power is allocated to idleness as it
could be allocated by rt. So the cpu_power that remains available for cfs,
is set to min value (i.e. 1).
The cpu_power is used for a task that wakes up because a waking up task is
already taken into account in the current activity whereas we use the
power_available for a fork and exec because the task is not part of the current
activity.
In order to quickly found the packing starting point, we save information that
will be used to directly start with the right sched_group at the right
sched_domain level instead of running the complete update_packing_domain
algorithm each time we need to use the packing cpu list.
The sd_power_leader defines the leader of a group of CPU that can't be
powergated independantly. As soon as this CPU is used, all the CPU in the same
group will be used based on the fact that it doesn't worth to keep some cores
idle if they can't be power gated while one core in the group is running.
The sd_pack_group and sd_pack_domain are used to quickly check if a power
leader should be used in the packing effort
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 162 ++-
1 file changed, 149 insertions(+), 13 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c258c38..f9b03c1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -185,11 +185,20 @@ static unsigned long available_of(int cpu)
}
#ifdef CONFIG_SCHED_PACKING_TASKS
+struct sd_pack {
+ int my_buddy; /* cpu on which tasks should be packed */
+ int my_leader; /* cpu which leads the packing state of a group */
+ struct sched_domain *domain; /* domain at which the check is done */
+ struct sched_group *group; /* starting group for checking */
+};
+
/*
- * Save the id of the optimal CPU that should be used to pack small tasks
- * The value -1 is used when no buddy has been found
+ * Save per_cpu information about the optimal CPUs that should be used to pack
+ * tasks.
*/
-DEFINE_PER_CPU(int, sd_pack_buddy);
+DEFINE_PER_CPU(struct sd_pack, sd_pack_buddy) = {
+ .my_buddy = -1,
+};
/*
* The packing level of the scheduler
@@ -202,6 +211,15 @@ int __read_mostly sysctl_sched_packing_level =
DEFAULT_PACKING_LEVEL;
unsigned int sd_pack_threshold = (100 * 1024) / DEFAULT_PACKING_LEVEL;
+static inline int get_buddy(int cpu)
+{
+ return per_cpu(sd_pack_buddy, cpu).my_buddy;
+}
+
+static inline int get_leader(int cpu)
+{
+ return per_cpu(sd_pack_buddy, cpu).my_leader;
+}
int sched_proc_update_packing(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp,
@@ -219,13 +237,19 @@ int sched_proc_update_packing(struct ctl_table *table,
int write,
static inline bool is_packing_cpu(int cpu)
{
- int my_buddy = per_cpu(sd_pack_buddy, cpu);
+ int my_buddy = get_buddy(cpu);
return (my_buddy == -1) || (cpu == my_buddy);
}
-static inline int get_buddy(int cpu)
+static inline bool is_leader_cpu(int cpu, struct sched_domain *sd)
{
- return per_cpu(sd_pack_buddy, cpu);
+ if (sd != per_cpu(sd_pack_buddy, cpu).domain)
+ return 0;
+
+ if (cpu != get_leader(cpu))
+ return 0;
+
+ return 1;
}
/*
@@ -239,7 +263,9 @@ static inline int get_buddy(int cpu)
void update_packing_domain(int cpu)
{
struct sched_domain *sd;
- int id = -1;
+ struct sched_group *target = NULL;
+ struct sd_pack *pack = &per_cpu(sd_pack_buddy, cpu);
+ int id = cpu, pcpu = cpu;
sd = highest_flag_domain(cpu, SD_SHARE_POWERDOMAIN);
if (!sd)
@@ -247,6 +273,12 @@ void update_packing_domain(int cpu)
else
sd = sd->parent;
+ if (sd) {
+ pcpu = cpumask_first(sched_group_cpus(sd->groups));
+ if (pcpu != cpu)
+ goto end;
+ }
+
while (sd && (sd->flags & SD_LOAD_BALANCE)
&& !(sd->flags & SD_SHARE_POWERDOMAIN)) {
struct sched_group *sg = sd->groups;
@@ -258,15 +290,16 @@ void update_packing_domain(int cpu)
* and this CPU of this local group is a good candidate
*/
id = cpu;
+ target = pack;
/* loop the sched groups to find the best one */
for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
- if (tmp->sgp->power * pack->group_weight >
- pack->sgp->power * tmp->group_weight)
+ if (tmp->sgp->power_available * pack->group_weight >
+ pack->sgp->power_available * tmp->group_weight)
continue;
Re: [PATCH] x86: Remove WARN_ON(in_nmi()) from vmalloc_fault
On Wed, Oct 16, 2013 at 03:57:30PM -0400, Steven Rostedt wrote: > On Wed, 16 Oct 2013 12:36:32 -0700 > "Paul E. McKenney" wrote: > > > > > Ah but we have an in_interrupt() check in context_tracking_user_enter() > > > that protects > > > us against that. > > > > Here you are relying on the exception being treated as an interrupt, > > correct? > > I don't think so. It's relying on nmi_enter() also makes in_interrupt() > return true. Got it, never mind! Thanx, Paul > Like I said before. An NMI interrupting userspace should be no > different than an interrupt interrupting userspace. They both can > trigger vmalloc faults, and we should be able to deal with it. > > -- Steve > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v5 02/14] ARM: sched: clear SD_SHARE_POWERDOMAIN
The ARM platforms take advantage of packing tasks on few cores if the latters
can be powergated independantly. We use DT and the cpu topology descirption
to define at which level a core can be independantly powergated to the others
and the SD_SHARE_POWERDOMAIN will be set accordingly at MC and CPU sched_domain
level.
The power-gate properties should be added with the value 1 in cpu and cluster
node when then can power gate independantly from the other.
As an example of a quad cores system which can power gate each core
independantly, we should have a DT similar to the example below
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu-map {
cluster0 {
power-gate = <1>;
core0 {
cpu = <&cpu0>;
power-gate = <1>;
};
core1 {
cpu = <&cpu1>;
power-gate = <1>;
};
core2 {
cpu = <&cpu2>;
power-gate = <1>;
};
core3 {
cpu = <&cpu3>;
power-gate = <1>;
};
};
};
...
};
Signed-off-by: Vincent Guittot
---
arch/arm/include/asm/topology.h |4
arch/arm/kernel/topology.c | 50 ++-
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 58b8b84..5102847 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -5,12 +5,16 @@
#include
+#define CPU_CORE_GATE 0x1
+#define CPU_CLUSTER_GATE 0x2
+
struct cputopo_arm {
int thread_id;
int core_id;
int socket_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
+ int flags;
};
extern struct cputopo_arm cpu_topology[NR_CPUS];
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 85a8737..f38f1f9 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -24,6 +24,7 @@
#include
#include
+#include
/*
* cpu power scale management
@@ -79,6 +80,51 @@ unsigned long *__cpu_capacity;
unsigned long middle_capacity = 1;
+static int __init get_dt_power_topology(struct device_node *topo)
+{
+ const u32 *reg;
+ int len, power = 0;
+ int flag = CPU_CORE_GATE;
+
+ for (; topo; topo = of_get_next_parent(topo)) {
+ reg = of_get_property(topo, "power-gate", &len);
+ if (reg && len == 4 && be32_to_cpup(reg))
+ power |= flag;
+ flag <<= 1;
+ }
+
+ return power;
+}
+
+#define for_each_subnode_with_property(dn, pn, prop_name) \
+ for (dn = of_find_node_with_property(pn, prop_name); dn; \
+dn = of_find_node_with_property(dn, prop_name))
+
+static void __init init_dt_power_topology(void)
+{
+ struct device_node *cn, *topo;
+
+ /* Get power domain topology information */
+ cn = of_find_node_by_path("/cpus/cpu-map");
+ if (!cn) {
+ pr_warn("Missing cpu-map node, bailing out\n");
+ return;
+ }
+
+ for_each_subnode_with_property(topo, cn, "cpu") {
+ struct device_node *cpu;
+
+ cpu = of_parse_phandle(topo, "cpu", 0);
+ if (cpu) {
+ u32 hwid;
+
+ of_property_read_u32(cpu, "reg", &hwid);
+ cpu_topology[get_logical_index(hwid)].flags =
get_dt_power_topology(topo);
+
+ }
+ }
+}
+
/*
* Iterate all CPUs' descriptor in DT and compute the efficiency
* (as per table_efficiency). Also calculate a middle efficiency
@@ -151,6 +197,8 @@ static void __init parse_dt_topology(void)
middle_capacity = ((max_capacity / 3)
>> (SCHED_POWER_SHIFT-1)) + 1;
+ /* Retrieve power topology information from DT */
+ init_dt_power_topology();
}
/*
@@ -283,7 +331,7 @@ void __init init_cpu_topology(void)
cpu_topo->socket_id = -1;
cpumask_clear(&cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
-
+ cpu_topo->flags = 0;
set_power_scale(cpu, SCHED_POWER_SCALE);
}
smp_wmb();
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
[RFC][PATCH v5 05/14] sched: add a packing level knob
The knob is used to set an average load threshold that will be used to trig
the inclusion/removal of CPUs in the packing effort list.
Signed-off-by: Vincent Guittot
---
include/linux/sched/sysctl.h |9 +
kernel/sched/fair.c | 26 ++
kernel/sysctl.c | 17 +
3 files changed, 52 insertions(+)
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index bf8086b..f41afa5 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -44,6 +44,14 @@ enum sched_tunable_scaling {
};
extern enum sched_tunable_scaling sysctl_sched_tunable_scaling;
+#ifdef CONFIG_SCHED_PACKING_TASKS
+extern int __read_mostly sysctl_sched_packing_level;
+
+int sched_proc_update_packing(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *ppos);
+#endif
+
extern unsigned int sysctl_numa_balancing_scan_delay;
extern unsigned int sysctl_numa_balancing_scan_period_min;
extern unsigned int sysctl_numa_balancing_scan_period_max;
@@ -61,6 +69,7 @@ extern unsigned int sysctl_sched_shares_window;
int sched_proc_update_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length,
loff_t *ppos);
+
#endif
#ifdef CONFIG_SCHED_DEBUG
static inline unsigned int get_sysctl_timer_migration(void)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7149f38..5568980 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -186,6 +186,32 @@ void sched_init_granularity(void)
*/
DEFINE_PER_CPU(int, sd_pack_buddy);
+/*
+ * The packing level of the scheduler
+ *
+ * This level define the activity % above which we should add another CPU to
+ * participate to the packing effort of the tasks
+ */
+#define DEFAULT_PACKING_LEVEL 80
+int __read_mostly sysctl_sched_packing_level = DEFAULT_PACKING_LEVEL;
+
+unsigned int sd_pack_threshold = (100 * 1024) / DEFAULT_PACKING_LEVEL;
+
+
+int sched_proc_update_packing(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *ppos)
+{
+ int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
+ if (ret || !write)
+ return ret;
+
+ if (sysctl_sched_packing_level)
+ sd_pack_threshold = (100 * 1024) / sysctl_sched_packing_level;
+
+ return 0;
+}
+
static inline bool is_packing_cpu(int cpu)
{
int my_buddy = per_cpu(sd_pack_buddy, cpu);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index b2f06f3..77383fc 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -255,11 +255,17 @@ static struct ctl_table sysctl_base_table[] = {
{ }
};
+#ifdef CONFIG_SCHED_PACKING_TASKS
+static int min_sched_packing_level;
+static int max_sched_packing_level = 100;
+#endif /* CONFIG_SMP */
+
#ifdef CONFIG_SCHED_DEBUG
static int min_sched_granularity_ns = 10; /* 100 usecs */
static int max_sched_granularity_ns = NSEC_PER_SEC;/* 1 second */
static int min_wakeup_granularity_ns; /* 0 usecs */
static int max_wakeup_granularity_ns = NSEC_PER_SEC; /* 1 second */
+
#ifdef CONFIG_SMP
static int min_sched_tunable_scaling = SCHED_TUNABLESCALING_NONE;
static int max_sched_tunable_scaling = SCHED_TUNABLESCALING_END-1;
@@ -279,6 +285,17 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+#ifdef CONFIG_SCHED_PACKING_TASKS
+ {
+ .procname = "sched_packing_level",
+ .data = &sysctl_sched_packing_level,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = sched_proc_update_packing,
+ .extra1 = &min_sched_packing_level,
+ .extra2 = &max_sched_packing_level,
+ },
+#endif
#ifdef CONFIG_SCHED_DEBUG
{
.procname = "sched_min_granularity_ns",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v5 08/14] sched: move load idx selection in find_idlest_group
load_idx is used in find_idlest_group but initialized in select_task_rq_fair
even when not used. The load_idx initialisation is moved in find_idlest_group
and the sd_flag replaces it in the function's args.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e26f65..c258c38 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3430,12 +3430,16 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
*/
static struct sched_group *
find_idlest_group(struct sched_domain *sd, struct task_struct *p,
- int this_cpu, int load_idx)
+ int this_cpu, int sd_flag)
{
struct sched_group *idlest = NULL, *group = sd->groups;
unsigned long min_load = ULONG_MAX, this_load = 0;
+ int load_idx = sd->forkexec_idx;
int imbalance = 100 + (sd->imbalance_pct-100)/2;
+ if (sd_flag & SD_BALANCE_WAKE)
+ load_idx = sd->wake_idx;
+
do {
unsigned long load, avg_load;
int local_group, packing_cpus = 0;
@@ -3632,7 +3636,6 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int wake_flags)
}
while (sd) {
- int load_idx = sd->forkexec_idx;
struct sched_group *group;
int weight;
@@ -3641,10 +3644,7 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int wake_flags)
continue;
}
- if (sd_flag & SD_BALANCE_WAKE)
- load_idx = sd->wake_idx;
-
- group = find_idlest_group(sd, p, cpu, load_idx);
+ group = find_idlest_group(sd, p, cpu, sd_flag);
if (!group) {
sd = sd->child;
continue;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v5 07/14] sched: get CPU's activity statistic
Monitor the activity level of each group of each sched_domain level. The
activity is the amount of cpu_power that is currently used on a CPU. We use
the runnable_avg_sum and _period to evaluate this activity level. In the
special use case where the CPU is fully loaded by more than 1 task, the
activity level is set above the cpu_power in order to reflect the overload of
The cpu
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index db9b871..7e26f65 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -179,6 +179,11 @@ void sched_init_granularity(void)
}
#ifdef CONFIG_SMP
+static unsigned long available_of(int cpu)
+{
+ return cpu_rq(cpu)->cpu_available;
+}
+
#ifdef CONFIG_SCHED_PACKING_TASKS
/*
* Save the id of the optimal CPU that should be used to pack small tasks
@@ -3549,6 +3554,22 @@ done:
return target;
}
+static int get_cpu_activity(int cpu)
+{
+ struct rq *rq = cpu_rq(cpu);
+ u32 sum = rq->avg.runnable_avg_sum;
+ u32 period = rq->avg.runnable_avg_period;
+
+ sum = min(sum, period);
+
+ if (sum == period) {
+ u32 overload = rq->nr_running > 1 ? 1 : 0;
+ return available_of(cpu) + overload;
+ }
+
+ return (sum * available_of(cpu)) / period;
+}
+
/*
* sched_balance_self: balance the current task (running on cpu) in domains
* that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
@@ -4430,6 +4451,7 @@ struct sg_lb_stats {
unsigned long sum_weighted_load; /* Weighted load of group's tasks */
unsigned long load_per_task;
unsigned long group_power;
+ unsigned long group_activity; /* Total activity of the group */
unsigned int sum_nr_running; /* Nr tasks running in the group */
unsigned int group_capacity;
unsigned int idle_cpus;
@@ -4446,6 +4468,7 @@ struct sd_lb_stats {
struct sched_group *busiest;/* Busiest group in this sd */
struct sched_group *local; /* Local group in this sd */
unsigned long total_load; /* Total load of all groups in sd */
+ unsigned long total_activity; /* Total activity of all groups in sd */
unsigned long total_pwr;/* Total power of all groups in sd */
unsigned long avg_load; /* Average load across all groups in sd */
@@ -4465,6 +4488,7 @@ static inline void init_sd_lb_stats(struct sd_lb_stats
*sds)
.busiest = NULL,
.local = NULL,
.total_load = 0UL,
+ .total_activity = 0UL,
.total_pwr = 0UL,
.busiest_stat = {
.avg_load = 0UL,
@@ -4771,6 +4795,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
}
sgs->group_load += load;
+ sgs->group_activity += get_cpu_activity(i);
sgs->sum_nr_running += nr_running;
sgs->sum_weighted_load += weighted_cpuload(i);
if (idle_cpu(i))
@@ -4894,6 +4919,7 @@ static inline void update_sd_lb_stats(struct lb_env *env,
/* Now, start updating sd_lb_stats */
sds->total_load += sgs->group_load;
+ sds->total_activity += sgs->group_activity;
sds->total_pwr += sgs->group_power;
if (!local_group && update_sd_pick_busiest(env, sds, sg, sgs)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v5 01/14] sched: add a new arch_sd_local_flags for sched_domain init
The function arch_sd_local_flags is used to set flags in sched_domains
according to the platform architecture. A new flag SD_SHARE_POWERDOMAIN is
also created to reflect whether groups of CPUs in a sched_domain level can or
not reach different power state. As an example, the flag should be cleared at
CPU level if groups of cores can be power gated independently. This information
is used to decide if it's worth packing some tasks in a group of CPUs in order
to power gate the other groups instead of spreading the tasks. The default
behavior of the scheduler is to spread tasks across CPUs and groups of CPUs so
the flag is set into all sched_domains.
The cpu parameter of arch_sd_local_flags can be used by architecture to fine
tune the scheduler domain flags. As an example SD_SHARE_POWERDOMAIN flag can be
set differently for groups of CPUs according to DT information
Signed-off-by: Vincent Guittot
---
arch/ia64/include/asm/topology.h |3 ++-
arch/tile/include/asm/topology.h |3 ++-
include/linux/sched.h|1 +
include/linux/topology.h | 11 ---
kernel/sched/core.c | 10 --
5 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index a2496e4..4844896 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -46,7 +46,7 @@
void build_cpu_to_node_map(void);
-#define SD_CPU_INIT (struct sched_domain) {\
+#define SD_CPU_INIT(cpu) (struct sched_domain) { \
.parent = NULL, \
.child = NULL, \
.groups = NULL, \
@@ -65,6 +65,7 @@ void build_cpu_to_node_map(void);
| SD_BALANCE_EXEC \
| SD_BALANCE_FORK \
| SD_WAKE_AFFINE, \
+ | arch_sd_local_flags(0, cpu)\
.last_balance = jiffies, \
.balance_interval = 1,\
.nr_balance_failed = 0,\
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index d15c0d8..6f7a97d 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -51,7 +51,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
*/
/* sched_domains SD_CPU_INIT for TILE architecture */
-#define SD_CPU_INIT (struct sched_domain) {\
+#define SD_CPU_INIT(cpu) (struct sched_domain) { \
.min_interval = 4,\
.max_interval = 128, \
.busy_factor= 64, \
@@ -71,6 +71,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
| 0*SD_WAKE_AFFINE \
| 0*SD_SHARE_CPUPOWER \
| 0*SD_SHARE_PKG_RESOURCES \
+ | arch_sd_local_flags(0, cpu) \
| 0*SD_SERIALIZE\
, \
.last_balance = jiffies, \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6682da3..2004cdb 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -763,6 +763,7 @@ enum cpu_idle_type {
#define SD_BALANCE_WAKE0x0010 /* Balance on wakeup */
#define SD_WAKE_AFFINE 0x0020 /* Wake task to waking CPU */
#define SD_SHARE_CPUPOWER 0x0080 /* Domain members share cpu power */
+#define SD_SHARE_POWERDOMAIN 0x0100 /* Domain members share power domain */
#define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
resources */
#define SD_SERIALIZE 0x0400 /* Only a single load balancing
instance */
#define SD_ASYM_PACKING0x0800 /* Place busy groups earlier in
the domain */
diff --git a/include/linux/topology.h b/include/linux/topology.h
index d3cf0d6..f3cd3c2 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -85,7 +85,7 @@ int arch_update_cpu_topology(void);
#define ARCH_HAS_SCHED_WAKE_IDLE
/* Common values for SMT siblings */
#ifndef SD_SIBLING_INIT
-#define SD_SIBLING_INIT (struct sched_domain) {
\
+#define SD_SIBLING_INIT(cpu) (struct sched_domain) { \
.min_interval = 1,\
.max_interval = 2,\
.busy_factor= 64, \
@@ -99,6 +99,8 @@ int arch_update_cpu_topology(void);
[RFC][PATCH v5 14/14] cpuidle: set the current wake up latency
Save the current wake up latency of a core. This latency is not always
the latency of a defined c-state but can also be an intermediate value
when a core is ready to shutdown (timer migration, cache flush ...) but
wait for the last core of the cluster to finalize the cluster power down.
This latter use case is not manage by the current version of the patch because
it implies that the cpuidle drivers set the wake up latency instead of the
cpuidle core.
Signed-off-by: Vincent Guittot
Conflicts:
drivers/cpuidle/cpuidle.c
---
drivers/cpuidle/cpuidle.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index d75040d..7b6553b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include "cpuidle.h"
@@ -42,6 +43,12 @@ void disable_cpuidle(void)
off = 1;
}
+static void cpuidle_set_current_state(int cpu, int latency)
+{
+ struct sched_pm *stat = &per_cpu(sched_stat, cpu);
+
+ atomic_set(&(stat->wake_latency), latency);
+}
/**
* cpuidle_play_dead - cpu off-lining
*
@@ -79,12 +86,16 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct
cpuidle_driver *drv,
ktime_t time_start, time_end;
s64 diff;
+ cpuidle_set_current_state(dev->cpu, target_state->exit_latency);
+
time_start = ktime_get();
entered_state = target_state->enter(dev, drv, index);
time_end = ktime_get();
+ cpuidle_set_current_state(dev->cpu, 0);
+
local_irq_enable();
diff = ktime_to_us(ktime_sub(time_end, time_start));
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v5 06/14] sched: create a new field with available capacity
This new field power_available reflects the available capacity of a CPU
unlike the cpu_power which reflects the current capacity.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 14 +++---
kernel/sched/sched.h |3 ++-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5568980..db9b871 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4584,15 +4584,19 @@ static void update_cpu_power(struct sched_domain *sd,
int cpu)
if (!power)
power = 1;
+ cpu_rq(cpu)->cpu_available = power;
+ sdg->sgp->power_available = power;
+
cpu_rq(cpu)->cpu_power = power;
sdg->sgp->power = power;
+
}
void update_group_power(struct sched_domain *sd, int cpu)
{
struct sched_domain *child = sd->child;
struct sched_group *group, *sdg = sd->groups;
- unsigned long power;
+ unsigned long power, available;
unsigned long interval;
interval = msecs_to_jiffies(sd->balance_interval);
@@ -4604,7 +4608,7 @@ void update_group_power(struct sched_domain *sd, int cpu)
return;
}
- power = 0;
+ power = available = 0;
if (child->flags & SD_OVERLAP) {
/*
@@ -4614,6 +4618,8 @@ void update_group_power(struct sched_domain *sd, int cpu)
for_each_cpu(cpu, sched_group_cpus(sdg))
power += power_of(cpu);
+ available += available_of(cpu);
+
} else {
/*
* !SD_OVERLAP domains can assume that child groups
@@ -4623,11 +4629,13 @@ void update_group_power(struct sched_domain *sd, int
cpu)
group = child->groups;
do {
power += group->sgp->power;
+ available += group->sgp->power_available;
group = group->next;
} while (group != child->groups);
}
- sdg->sgp->power_orig = sdg->sgp->power = power;
+ sdg->sgp->power_orig = sdg->sgp->power_available = available;
+ sdg->sgp->power = power;
}
/*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 22e3f1d..d5a4ec0 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -459,6 +459,7 @@ struct rq {
struct sched_domain *sd;
unsigned long cpu_power;
+ unsigned long cpu_available;
unsigned char idle_balance;
/* For active balancing */
@@ -603,7 +604,7 @@ struct sched_group_power {
* CPU power of this group, SCHED_LOAD_SCALE being max power for a
* single CPU.
*/
- unsigned int power, power_orig;
+ unsigned int power, power_orig, power_available;
unsigned long next_update;
/*
* Number of busy cpus in this group.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
