Re: [PATCH 3/3] gpio: sch: Enable IRQ support for Quark X1000
On Fri, Sep 26, 2014 at 11:18 AM, Mika Westerberg wrote: > On Fri, Sep 26, 2014 at 09:14:48AM +, Chang, Rebecca Swee Fun wrote: >> > > + >> > > + /* disable interrupts */ >> > > + sch_gpio_irq_disable_all(sch, sch->chip.ngpio); >> > > + >> > > + err = request_irq(sch->irq_num, sch_gpio_irq_handler, >> > > + IRQF_SHARED, KBUILD_MODNAME, sch); >> > >> > This seems weird, typically irqchip drivers don't call request_irq() >> > directly but >> > instead irq_set_chained_handler() or similar. With >> > gpiochip_irqchip_* stuff you don't need even that. >> > >> Regarding this, gpio-sch is actually using shared interrupts and the >> IRQ resources are from ACPI SCI. As per my understanding, resources >> from ACPI SCI might be shared for power management purposes. In this >> case, irq_set_chained_handler() might not be able to use here. What do >> you think? > > I think you are right. And then you can't use gpiochip_irqchip_* helpers > either :-( No since that implies that the gpiochip lives in its own irqdomain, and this driver uses a linear range of irqs provided from another domain, just allocates descriptors for them. I'll take a look at this and see if it's merge material now. 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: [PATCHv4] serial: of-serial: fix up PM ops on no_console_suspend and port type
On 10/15/2014 02:41 PM, Joseph Lo wrote: On 10/15/2014 02:32 PM, Jingchang Lu wrote: -Original Message- From: Joseph Lo [mailto:jose...@nvidia.com] Sent: Wednesday, October 15, 2014 9:01 AM To: Lu Jingchang-B35083; gre...@linuxfoundation.org Cc: pe...@hurleysoftware.com; a...@arndb.de; linux-kernel@vger.kernel.org; linux-ser...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCHv4] serial: of-serial: fix up PM ops on no_console_suspend and port type On 10/14/2014 04:42 PM, Jingchang Lu wrote: This patch fixes commit 2dea53bf57783f243c892e99c10c6921e956aa7e, "serial: of-serial: add PM suspend/resume support", which disables the uart clock on suspend, but also causes a hardware hang on register access if no_console_suspend command line option is used. Also, not every of_serial device is an 8250 port, so the serial8250 suspend/resume functions should only be applied to a real 8250 port. Signed-off-by: Jingchang Lu If you can make sure this patch can build without include , then this patch The build passes on my cloned linux-next tree, include next-20141014, but is required on my another kernel-3.12+ based tree, then I didn't add this header file when upstream. Is the build broken on your source tree, and is the tree latest? If the header is needed, I will add it. I tested it on next-20141013 and k3.14, both of them need the fix. I can check it again against the latest linux-next tree later. Thanks. OK, I confirmed it. You should add the header file. It also doesn't build for me with the latest linux-next tree. Maybe you missed to enable CONFIG_PM_SLEEP or CONFIG_SERIAL_8250 when doing the build test in linux-next tree. -Joseph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv4] serial: of-serial: fix up PM ops on no_console_suspend and port type
>-Original Message-
>From: Joseph Lo [mailto:jose...@nvidia.com]
>Sent: Wednesday, October 15, 2014 2:42 PM
>To: Lu Jingchang-B35083; gre...@linuxfoundation.org
>Cc: pe...@hurleysoftware.com; a...@arndb.de; linux-kernel@vger.kernel.org;
>linux-ser...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
>Subject: Re: [PATCHv4] serial: of-serial: fix up PM ops on
>no_console_suspend and port type
>
>On 10/15/2014 02:32 PM, Jingchang Lu wrote:
>>> -Original Message-
>>> From: Joseph Lo [mailto:jose...@nvidia.com]
>>> Sent: Wednesday, October 15, 2014 9:01 AM
>>> To: Lu Jingchang-B35083; gre...@linuxfoundation.org
>>> Cc: pe...@hurleysoftware.com; a...@arndb.de;
>>> linux-kernel@vger.kernel.org; linux-ser...@vger.kernel.org;
>>> linux-arm-ker...@lists.infradead.org
>>> Subject: Re: [PATCHv4] serial: of-serial: fix up PM ops on
>>> no_console_suspend and port type
>>>
>>> On 10/14/2014 04:42 PM, Jingchang Lu wrote:
>>>> This patch fixes commit 2dea53bf57783f243c892e99c10c6921e956aa7e,
>>>> "serial: of-serial: add PM suspend/resume support", which disables
>>>> the uart clock on suspend, but also causes a hardware hang on
>>>> register access if no_console_suspend command line option is used.
>>>>
>>>> Also, not every of_serial device is an 8250 port, so the serial8250
>>>> suspend/resume functions should only be applied to a real 8250 port.
>>>>
>>>> Signed-off-by: Jingchang Lu
>>>
>>> If you can make sure this patch can build without include
>>> , then this patch
>> The build passes on my cloned linux-next tree, include next-20141014,
>> but is required on my another kernel-3.12+ based tree, then I didn't
>> add this header file when upstream.
>> Is the build broken on your source tree, and is the tree latest?
>> If the header is needed, I will add it.
>I tested it on next-20141013 and k3.14, both of them need the fix. I can
>check it again against the latest linux-next tree later. Thanks.
Sorry, it is needed indeed, I have forgotten enable the PM in the next tree
due the lack of PM supporting of my board, I test the function on my 3.12 tree.
I will add it right now.
Best Regards,
Jingchang
>
>-Joseph
>
>> Thanks.
>>
>> Best Regards,
>> Jingchang
>>>
>>> Tested-by: Joseph Lo
>>>
>>> And thanks for your fix.
>>>
>>>> ---
>>>> changes in v4:
>>>>separate 8250 port suspend/resume from of_serial_suspend/resume.
>>>>
>>>> changes in v3:
>>>>fix up point reference and deference.
>>>>
>>>> changes in v2:
>>>>add switch selection on uart type.
>>>>
>>>>drivers/tty/serial/of_serial.c | 52
>>> --
>>>>1 file changed, 45 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/serial/of_serial.c
>>>> b/drivers/tty/serial/of_serial.c index 8bc2563..5281f8f 100644
>>>> --- a/drivers/tty/serial/of_serial.c
>>>> +++ b/drivers/tty/serial/of_serial.c
>>>> @@ -241,13 +241,48 @@ static int of_platform_serial_remove(struct
>>> platform_device *ofdev)
>>>>}
>>>>
>>>>#ifdef CONFIG_PM_SLEEP
>>>> -static int of_serial_suspend(struct device *dev)
>>>> +#ifdef CONFIG_SERIAL_8250
>>>> +static void of_serial_suspend_8250(struct of_serial_info *info)
>>>>{
>>>> - struct of_serial_info *info = dev_get_drvdata(dev);
>>>> + struct uart_8250_port *port8250 = serial8250_get_port(info->line);
>>>> + struct uart_port *port = &port8250->port;
>>>>
>>>>serial8250_suspend_port(info->line);
>>>> - if (info->clk)
>>>> + if (info->clk && (!uart_console(port) || console_suspend_enabled))
>>>>clk_disable_unprepare(info->clk);
>>>> +}
>>>> +
>>>> +static void of_serial_resume_8250(struct of_serial_info *info) {
>>>> + struct uart_8250_port *port8250 = serial8250_get_port(info->line);
>>>> + struct uart_port *port = &port8250->port;
>>>> +
>>>> + if (info->clk && (!uart_console(port) || console_suspend_enabled))
>>>> + clk_prepare_enable(info->clk);
>>>> +
>>>> + serial8250_resume_port(info->line);
>>>> +}
>>>> +#el
Re: [PATCH v4 4/6] ARM: rockchip: add basic smp support for rk3288
Russell,
On 10/14/2014 04:37 PM, Russell King - ARM Linux wrote:
On Tue, Oct 14, 2014 at 02:50:07PM -0700, Kever Yang wrote:
Heiko,
On 10/14/2014 02:23 PM, Heiko Stübner wrote:
Am Dienstag, 14. Oktober 2014, 13:24:03 schrieb Doug Anderson:
Kever,
On Mon, Oct 13, 2014 at 1:12 PM, Kever Yang
wrote:
+ /*
+* We need to soft reset the cpu when we turn off the cpu power
domain, +* or else the active processors might be stalled when
the individual +* processor is powered down.
+*/
+ if (read_cpuid_part_number() != ARM_CPU_PART_CORTEX_A9) {
I haven't done a full review of this patch, but it seems unlikely that
your uses of read_cpuid_part_number() and read_cpuid_part() in this
patch are correct. You use both functions and in both cases compare
the results to ARM_CPU_PART_CORTEX_A9.
I think read_cpuid_part() would be the correct one, as it does
You are right, read_cpuid_part() is correct one on kernel next,
I mix up 3.14 kernel and next tree, only read_cpuid_part_number() is
available
in 3.14 kernel.
I will correct it in my next version, any other changes needed for new
version?
You need to at the _very_ _minimum_ build test your code against a
recent kernel, and preferably test it to make sure that it works as
you intend.
Thanks for you advice, I'll be more careful next time.
I'm sorry for not test this patch with rk3188(A9 based) board,
I do have test it on top of kernel next with my rk3288 evb(not A9 based),
and I didn't get any warning for read_cpuid_part_number()
during building the image.
- Kever
Developing on such an old kernel version, and hoping that the code is
going to be correct for later kernels isn't a nice idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: serial: 8250_core: restore the LCR register in set_sleep
In ST16650V2 based serial uarts, while initalizing the PM state,
LCR registers are being initialized to 0 in serial8250_set_sleep().
If console port is already initialized and being used, this will
throws garbage in the console.
Signed-off-by: Sudhir Sreedharan
---
drivers/tty/serial/8250/8250_core.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index ca5cfdc..e054482 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -595,6 +595,7 @@ static void serial8250_rpm_put_tx(struct uart_8250_port *p)
*/
static void serial8250_set_sleep(struct uart_8250_port *p, int sleep)
{
+ unsigned char lcr, efr;
/*
* Exar UARTs have a SLEEP register that enables or disables
* each UART to enter sleep mode separately. On the XR17V35x the
@@ -611,6 +612,8 @@ static void serial8250_set_sleep(struct uart_8250_port *p,
int sleep)
if (p->capabilities & UART_CAP_SLEEP) {
if (p->capabilities & UART_CAP_EFR) {
+ lcr = serial_in(p, UART_LCR);
+ efr = serial_in(p, UART_EFR);
serial_out(p, UART_LCR, UART_LCR_CONF_MODE_B);
serial_out(p, UART_EFR, UART_EFR_ECB);
serial_out(p, UART_LCR, 0);
@@ -618,8 +621,8 @@ static void serial8250_set_sleep(struct uart_8250_port *p,
int sleep)
serial_out(p, UART_IER, sleep ? UART_IERX_SLEEP : 0);
if (p->capabilities & UART_CAP_EFR) {
serial_out(p, UART_LCR, UART_LCR_CONF_MODE_B);
- serial_out(p, UART_EFR, 0);
- serial_out(p, UART_LCR, 0);
+ serial_out(p, UART_EFR, sleep ? 0 : efr);
+ serial_out(p, UART_LCR, sleep ? 0 : lcr);
}
}
out:
--
1.7.0.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/
Subject: [PATCH] kobject: fix the race between kobject_del and get_device_parent
When the last child kobject was deleted, it's parent kobject will be deleted,
when removing the parent kobject if the parent kobject's sd has been set NULL
and still not been removed from it's kset's list, at the same time another one
trigger an device adding event, the function get_parent_device() will get the
parent object from the kset's list for kobject_add(), but this time parent
kobject's sd has been NULL. This race will make the sysfs_create_dir() return
ENOENT, the new kobject will be failed to added into sysfs and trigger BUG()
when creating attribute group under the new device's directory. So move the
kobject removal from kset's list before kobj->sd=NULL.
The race situation:
path0(remove parent kobj, e.g:/sys/devices/virtual/block/) path1(register a
new device)
kobject_del(){
get_device_parent(){
... ...
sysfs_remove_dir(kobj); //kobj->sd=NULL
spin_lock(&dev->class->p->glue_dirs.list_lock);
... <===
list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
kobj_kset_leave(kobj); //remove kobj from kset list...
} }
We had triggered the bug, the detail message link:
https://lkml.org/lkml/2014/10/13/40
Signed-off-by: Weng Meiling
---
lib/kobject.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/kobject.c b/lib/kobject.c
index 58751bb..af2b7bb 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -560,12 +560,13 @@ void kobject_del(struct kobject *kobj)
if (!kobj)
return;
+ kobj_kset_leave(kobj);
+
sd = kobj->sd;
sysfs_remove_dir(kobj);
sysfs_put(sd);
kobj->state_in_sysfs = 0;
- kobj_kset_leave(kobj);
kobject_put(kobj->parent);
kobj->parent = NULL;
}
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4] serial: of-serial: fix up PM ops on no_console_suspend and port type
On 10/15/2014 02:32 PM, Jingchang Lu wrote:
-Original Message-
From: Joseph Lo [mailto:jose...@nvidia.com]
Sent: Wednesday, October 15, 2014 9:01 AM
To: Lu Jingchang-B35083; gre...@linuxfoundation.org
Cc: pe...@hurleysoftware.com; a...@arndb.de; linux-kernel@vger.kernel.org;
linux-ser...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCHv4] serial: of-serial: fix up PM ops on
no_console_suspend and port type
On 10/14/2014 04:42 PM, Jingchang Lu wrote:
This patch fixes commit 2dea53bf57783f243c892e99c10c6921e956aa7e,
"serial: of-serial: add PM suspend/resume support", which disables the
uart clock on suspend, but also causes a hardware hang on register
access if no_console_suspend command line option is used.
Also, not every of_serial device is an 8250 port, so the serial8250
suspend/resume functions should only be applied to a real 8250 port.
Signed-off-by: Jingchang Lu
If you can make sure this patch can build without include
, then this patch
The build passes on my cloned linux-next tree, include next-20141014,
but is required on my another kernel-3.12+ based tree, then I didn't
add this header file when upstream.
Is the build broken on your source tree, and is the tree latest?
If the header is needed, I will add it.
I tested it on next-20141013 and k3.14, both of them need the fix. I can
check it again against the latest linux-next tree later. Thanks.
-Joseph
Thanks.
Best Regards,
Jingchang
Tested-by: Joseph Lo
And thanks for your fix.
---
changes in v4:
separate 8250 port suspend/resume from of_serial_suspend/resume.
changes in v3:
fix up point reference and deference.
changes in v2:
add switch selection on uart type.
drivers/tty/serial/of_serial.c | 52
--
1 file changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/of_serial.c
b/drivers/tty/serial/of_serial.c index 8bc2563..5281f8f 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -241,13 +241,48 @@ static int of_platform_serial_remove(struct
platform_device *ofdev)
}
#ifdef CONFIG_PM_SLEEP
-static int of_serial_suspend(struct device *dev)
+#ifdef CONFIG_SERIAL_8250
+static void of_serial_suspend_8250(struct of_serial_info *info)
{
- struct of_serial_info *info = dev_get_drvdata(dev);
+ struct uart_8250_port *port8250 = serial8250_get_port(info->line);
+ struct uart_port *port = &port8250->port;
serial8250_suspend_port(info->line);
- if (info->clk)
+ if (info->clk && (!uart_console(port) || console_suspend_enabled))
clk_disable_unprepare(info->clk);
+}
+
+static void of_serial_resume_8250(struct of_serial_info *info) {
+ struct uart_8250_port *port8250 = serial8250_get_port(info->line);
+ struct uart_port *port = &port8250->port;
+
+ if (info->clk && (!uart_console(port) || console_suspend_enabled))
+ clk_prepare_enable(info->clk);
+
+ serial8250_resume_port(info->line);
+}
+#else
+static inline void of_serial_suspend_8250(struct of_serial_info
+*info) { }
+
+static inline void of_serial_resume_8250(struct of_serial_info *info)
+{ } #endif
+
+static int of_serial_suspend(struct device *dev) {
+ struct of_serial_info *info = dev_get_drvdata(dev);
+
+ switch(info->type) {
+ case PORT_8250 ... PORT_MAX_8250:
+ of_serial_suspend_8250(info);
+ break;
+ default:
+ break;
+ }
return 0;
}
@@ -256,10 +291,13 @@ static int of_serial_resume(struct device *dev)
{
struct of_serial_info *info = dev_get_drvdata(dev);
- if (info->clk)
- clk_prepare_enable(info->clk);
-
- serial8250_resume_port(info->line);
+ switch(info->type) {
+ case PORT_8250 ... PORT_MAX_8250:
+ of_serial_resume_8250(info);
+ break;
+ default:
+ break;
+ }
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Fix Text randomization
On Wed, Oct 15, 2014 at 7:38 AM, Michael Ellerman wrote: > On Fri, 2014-10-10 at 05:45:26 UTC, Vineeth Vijayan wrote: >> Right now there is no way to disable TEXT randomization on a PPC32 >> machine. text randomization happens even in the case of "echo 0 > >> /proc/sys/kernel/randomize_va_space" > > Yeah it seems to happen on ppc64 too. > >> This happens due to the incorrect definition of ELF_ET_DYN_BASE at >> arch/powerpc/include/asm/elf.h > > What is incorrect about it? We are not the only arch that does that. > I think we are one of the arch which does it. The same has been tested on x86 and arm, where ELF_ET_DYN_BASE doesn’t use randomize_et_dyn call, and it works properly as per the user-space definition of randomization; (i.e when at "echo 0 > /proc/sys/kernel/randomize_va_space", TEXT randomization should not happen.) > I'm not clear on what has changed to break this? > > cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] init: Disable defaults if init= fails
On 10/14/2014 10:56 PM, Andy Lutomirski wrote: > On Tue, Oct 14, 2014 at 10:46 PM, Frank Rowand wrote: >> On 10/14/2014 2:21 PM, Andy Lutomirski wrote: >>> On Tue, Oct 14, 2014 at 2:00 PM, Andrew Morton >>> wrote: On Wed, 1 Oct 2014 11:13:14 -0700 Andy Lutomirski wrote: > On Wed, Oct 1, 2014 at 11:05 AM, wrote: >> On Tue, Sep 30, 2014 at 09:53:56PM -0700, Andy Lutomirski wrote: >>> I significantly prefer default N. Scripts that play with init= really >>> don't want the fallback, and I can imagine contexts in which it could >>> be a security problem. >> >> While I certainly would prefer the non-fallback behavior for init as >> well, standard kernel practice has typically been to use "default y" for >> previously built-in features that become configurable. And I'd >> certainly prefer a compile-time configuration option like this (even >> with default y) over a "strictinit" kernel command-line option. >> > > Fair enough. > > So: "default y" for a release or two, then switch the default? Having > default y will annoy virtme, though it's not the end of the world. > Virtme is intended to work with more-or-less-normal kernels. > Adding another Kconfig option is tiresome. What was wrong with strictinit=? >>> >>> The consensus seems to be that adding a non-default option to get >> >> ^ I do not think you know what the word consensus means. :-) >> >> I did not agree. >> >> I do agree with Andrew (but with no opinion on whether "strictinit=SOMETHING" >> or just "strictinit". >> >>> sensible behavior would be unfortunate. Also, I don't like > > Even you're not disagreeing that it's ugly, though, FWIW. You are putting (lack of) words in my mouth. I did not comment on "ugly" because it did not seem that big a deal to me. I have no desire to bikeshed on ugly in this particular instance. > >> ^ >> behavior that is useful in some or many contexts > > Is there a context in which the current behavior is useful beyond > "whoops, I typoed my grub command line edit, and I still want my > system to boot into *something* even if it's the wrong thing"? I'm > not personally that sympathetic to that particular use case, but maybe > there's another one. We've been through this before. I should have ignored your "sensible behavior" comment. Sorry, again no need for me to bike shed on that. The question from Andrew was whether to use a config option or a command line option. One could choose either behavior as default, whether controlled by command line or config option. > > --Andy > >> >>> strictinit=, since backwards-compatible setups will have to do >>> init=foo strictinit=foo. My original proposal was init=foo >>> strictinit. >>> >>> TBH, my preference would be to make strict mode unconditional. >>> http://xkcd.com/1172/ >>> >>> --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arm64: dts: exynos7: add support for cpuidle core power down
Exynos7 has core power down state where cores can be powered off independently.
This patch adds support for this state.
Signed-off-by: Chander Kashyap
---
This patch has following dependencies:
- [PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
- [PATCH v9 0/8] ARM generic idle states
http://permalink.gmane.org/gmane.linux.power-management.general/49224
arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index ce221ac..8e0a034 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -36,6 +36,7 @@
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP>;
reg = <0x0>;
};
@@ -43,6 +44,7 @@
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP>;
reg = <0x1>;
};
@@ -50,6 +52,7 @@
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP>;
reg = <0x2>;
};
@@ -57,8 +60,23 @@
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP>;
reg = <0x3>;
};
+
+ idle-states {
+ entry-method = "arm,psci";
+
+ CPU_SLEEP: cpu-sleep {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ arm,psci-suspend-param = <0x001>;
+ entry-latency-us = <20>;
+ exit-latency-us = <150>;
+ min-residency-us = <2100>;
+ status = "enabled";
+ };
+ };
};
psci {
--
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] MAINTAINERS: Update Santosh Shilimkar's email id
On Mon, Oct 13, 2014 at 02:16:28PM -0400, Santosh Shilimkar wrote: > Signed-off-by: Santosh Shilimkar Applied, thanks. -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 net-next RFC 1/3] virtio: support for urgent descriptors
Jason Wang writes: > Below should be useful for some experiments Jason is doing. > I thought I'd send it out for early review/feedback. > > event idx feature allows us to defer interrupts until > a specific # of descriptors were used. > Sometimes it might be useful to get an interrupt after > a specific descriptor, regardless. > This adds a descriptor flag for this, and an API > to create an urgent output descriptor. > This is still an RFC: > we'll need a feature bit for drivers to detect this, > but we've run out of feature bits for virtio 0.X. > For experimentation purposes, drivers can assume > this is set, or add a driver-specific feature bit. > > Signed-off-by: Michael S. Tsirkin > Signed-off-by: Jason Wang The new VRING_DESC_F_URGENT bit is theoretically nicer, but for networking (which tends to take packets in order) couldn't we just set the event counter to give us a tx interrupt at the packet we want? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: krealloc in kernel/params.c
Rasmus Villemoes writes:
> It is likely that I'm just missing something trivial, but I have
> a hard time understanding 63662139e ("params: Fix potential
> memory leak in add_sysfs_param()").
Yes, it was a bad commit, and we've been discussing it, see:
[PATCH] params: fix potential memory leak in add_sysfs_param()
The only error case we are about is when add_sysfs_param()
is called from module_param_sysfs_setup(): the in-kernel cases
at boot time are assumed not to fail.
That call should invoke free_module_param_attrs() when it fails,
rather than relying on add_sysfs_param() to clean up.
Don't patch bad code - rewrite it. (Kernigan and Plauger)
How's this?
params: cleanup sysfs allocation
commit 63662139e519ce06090b2759cf4a1d291b9cc0e2 attempted to patch a
leak (which would only happen on OOM, ie. never), but it didn't quite
work.
This rewrites the code to be as simple as possible. add_sysfs_param()
adds a parameter. If it fails, it's the caller's responsibility to
clean up the parameters which already exist.
The kzalloc-then-always-krealloc pattern is perhaps overly simplistic,
but this code has clearly confused people. It worked on me...
Signed-off-by: Rusty Russell
diff --git a/kernel/params.c b/kernel/params.c
index db97b791390f..5b8005d01dfc 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -603,68 +603,58 @@ static __modinit int add_sysfs_param(struct
module_kobject *mk,
const struct kernel_param *kp,
const char *name)
{
- struct module_param_attrs *new;
- struct attribute **attrs;
- int err, num;
+ struct module_param_attrs *new_mp;
+ struct attribute **new_attrs;
+ unsigned int i;
/* We don't bother calling this with invisible parameters. */
BUG_ON(!kp->perm);
if (!mk->mp) {
- num = 0;
- attrs = NULL;
- } else {
- num = mk->mp->num;
- attrs = mk->mp->grp.attrs;
+ /* First allocation. */
+ mk->mp = kzalloc(sizeof(*mk->mp), GFP_KERNEL);
+ if (!mk->mp)
+ return -ENOMEM;
+ mk->mp->grp.name = "parameters";
+ /* NULL-terminated attribute array. */
+ mk->mp->grp.attrs = kzalloc(sizeof(mk->mp->grp.attrs[0]),
+ GFP_KERNEL);
+ /* Caller will cleanup via free_module_param_attrs */
+ if (!mk->mp->grp.attrs)
+ return -ENOMEM;
}
- /* Enlarge. */
- new = krealloc(mk->mp,
- sizeof(*mk->mp) + sizeof(mk->mp->attrs[0]) * (num+1),
- GFP_KERNEL);
- if (!new) {
- kfree(attrs);
- err = -ENOMEM;
- goto fail;
- }
- /* Despite looking like the typical realloc() bug, this is safe.
-* We *want* the old 'attrs' to be freed either way, and we'll store
-* the new one in the success case. */
- attrs = krealloc(attrs, sizeof(new->grp.attrs[0])*(num+2), GFP_KERNEL);
- if (!attrs) {
- err = -ENOMEM;
- goto fail_free_new;
- }
+ /* Enlarge allocations. */
+ new_mp = krealloc(mk->mp,
+ sizeof(*mk->mp) +
+ sizeof(mk->mp->attrs[0]) * (mk->mp->num + 1),
+ GFP_KERNEL);
+ if (!new_mp)
+ return -ENOMEM;
+ mk->mp = new_mp;
- /* Sysfs wants everything zeroed. */
- memset(new, 0, sizeof(*new));
- memset(&new->attrs[num], 0, sizeof(new->attrs[num]));
- memset(&attrs[num], 0, sizeof(attrs[num]));
- new->grp.name = "parameters";
- new->grp.attrs = attrs;
+ /* Extra pointer for NULL terminator */
+ new_attrs = krealloc(mk->mp->grp.attrs,
+sizeof(mk->mp->grp.attrs[0]) * (mk->mp->num + 2),
+GFP_KERNEL);
+ if (!new_attrs)
+ return -ENOMEM;
+ mk->mp->grp.attrs = new_attrs;
/* Tack new one on the end. */
- sysfs_attr_init(&new->attrs[num].mattr.attr);
- new->attrs[num].param = kp;
- new->attrs[num].mattr.show = param_attr_show;
- new->attrs[num].mattr.store = param_attr_store;
- new->attrs[num].mattr.attr.name = (char *)name;
- new->attrs[num].mattr.attr.mode = kp->perm;
- new->num = num+1;
+ sysfs_attr_init(&mk->mp->attrs[mk->mp->num].mattr.attr);
+ mk->mp->attrs[mk->mp->num].param = kp;
+ mk->mp->attrs[mk->mp->num].mattr.show = param_attr_show;
+ mk->mp->attrs[mk->mp->num].mattr.store = param_attr_store;
+ mk->mp->attrs[mk->mp->num].mattr.attr.name = (char *)name;
+ mk->mp->attrs[mk->mp->num].mattr.attr.mode = kp->perm;
+ mk->mp->num++;
/* Fix up all the pointers, since krealloc can move us */
- for (num = 0;
Re: [PATCH] aarch64: filter $x from kallsyms
Catalin Marinas writes: > On Thu, Sep 18, 2014 at 05:18:57AM +0100, Rusty Russell wrote: >> Kyle McMartin writes: >> > Similar to ARM, AArch64 is generating $x and $d syms... which isn't >> > terribly helpful when looking at %pF output and the like. Filter those >> > out in kallsyms, modpost and when looking at module symbols. >> > >> > Seems simplest since none of these check EM_ARM anyway, to just add it >> > to the strchr used, rather than trying to make things overly >> > complicated. >> > >> > initcall_debug improves: >> > dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs >> > dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 >> > usecs >> > >> > Signed-off-by: Kyle McMartin >> >> Acked-by: Rusty Russell > > Thanks. Shall I understand that you are ok for me to take it via the > arm64 tree (or you'd prefer to merge it via your tree)? Sorry, vacation. Yes, it was all yours, and I see it in Linus' tree now. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio_balloon: Convert "vballon" kthread into a workqueue
Petr Mladek writes:
> Workqueues have clean and rich API for all basic operations. The code is
> usually
> easier and better readable. It can be easily tuned for the given purpose.
OK, sure.
> -static void fill_balloon(struct virtio_balloon *vb, size_t num)
> +static void fill_balloon(struct virtio_balloon *vb, size_t diff)
> {
> struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
> + size_t num;
> + bool done;
>
> /* We can only do one array worth at a time. */
> - num = min(num, ARRAY_SIZE(vb->pfns));
> + num = min(diff, ARRAY_SIZE(vb->pfns));
> + done = (num == diff) ? true : false;
>
> mutex_lock(&vb->balloon_lock);
> for (vb->num_pfns = 0; vb->num_pfns < num;
> @@ -143,6 +143,7 @@ static void fill_balloon(struct virtio_balloon *vb,
> size_t num)
>VIRTIO_BALLOON_PAGES_PER_PAGE);
> /* Sleep for at least 1/5 of a second before retry. */
> msleep(200);
> + done = false;
> break;
> }
> set_page_pfns(vb->pfns + vb->num_pfns, page);
> @@ -154,6 +155,9 @@ static void fill_balloon(struct virtio_balloon *vb,
> size_t num)
> if (vb->num_pfns != 0)
> tell_host(vb, vb->inflate_vq);
> mutex_unlock(&vb->balloon_lock);
> +
> + if (!done)
> + queue_work(vb->wq, &vb->wq_work);
> }
Hmm, this is a bit convoluted. I would spell it out by keeping a
num_done counter:
if (num_done < diff)
queue_work(vb->wq, &vb->wq_work);
> static void release_pages_by_pfn(const u32 pfns[], unsigned int num)
> @@ -168,20 +172,25 @@ static void release_pages_by_pfn(const u32 pfns[],
> unsigned int num)
> }
> }
>
> -static void leak_balloon(struct virtio_balloon *vb, size_t num)
> +static void leak_balloon(struct virtio_balloon *vb, size_t diff)
> {
> struct page *page;
> struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
> + size_t num;
> + bool done;
>
> /* We can only do one array worth at a time. */
> - num = min(num, ARRAY_SIZE(vb->pfns));
> + num = min(diff, ARRAY_SIZE(vb->pfns));
> + done = (num == diff) ? true : false;
>
> mutex_lock(&vb->balloon_lock);
> for (vb->num_pfns = 0; vb->num_pfns < num;
>vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
> page = balloon_page_dequeue(vb_dev_info);
> - if (!page)
> + if (!page) {
> + done = false;
> break;
> + }
> set_page_pfns(vb->pfns + vb->num_pfns, page);
> vb->num_pages -= VIRTIO_BALLOON_PAGES_PER_PAGE;
> }
> @@ -195,6 +204,9 @@ static void leak_balloon(struct virtio_balloon *vb,
> size_t num)
> tell_host(vb, vb->deflate_vq);
> mutex_unlock(&vb->balloon_lock);
> release_pages_by_pfn(vb->pfns, vb->num_pfns);
> +
> + if (!done)
> + queue_work(vb->wq, &vb->wq_work);
> }
Here too.
> @@ -471,11 +469,13 @@ static int virtballoon_probe(struct virtio_device *vdev)
> if (err)
> goto out_free_vb_mapping;
>
> - vb->thread = kthread_run(balloon, vb, "vballoon");
> - if (IS_ERR(vb->thread)) {
> - err = PTR_ERR(vb->thread);
> + vb->wq = alloc_workqueue("vballoon_wq",
> + WQ_FREEZABLE | WQ_MEM_RECLAIM, 0);
> + if (!vb->wq) {
> + err = -ENOMEM;
> goto out_del_vqs;
> }
> + INIT_WORK(&vb->wq_work, balloon);
That looks racy to me; shouldn't we init vq-work before allocating wq?
Otherwise, looks good!
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] taint: add TAINT_DEBUG for invasive debugging features
"Luis R. Rodriguez" writes: > From: "Luis R. Rodriguez" > > At times we may add module parameters or debugging / testing > kernel features, when enabled though we don't really want > to be spending time debugging them. Add a taint flag for > this to avoid spurious bug reports. The recently introduced KERNEL_PARAM_FL_UNSAFE flag for module parameters does this explicitly. It uses TAINT_USER, should it use this instead? Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] module: add extra argument for parse_params() callback
"Luis R. Rodriguez" writes: > From: "Luis R. Rodriguez" > > This adds an extra argument onto parse_params() to be used > as a way to make the unused callback a bit more useful and > generic by allowing the caller to pass on a data structure > of its choice. An example use case is to allow us to easily > make module parameters for every module which we will do > next. Acked-by: Rusty Russell Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv4] serial: of-serial: fix up PM ops on no_console_suspend and port type
>-Original Message-
>From: Joseph Lo [mailto:jose...@nvidia.com]
>Sent: Wednesday, October 15, 2014 9:01 AM
>To: Lu Jingchang-B35083; gre...@linuxfoundation.org
>Cc: pe...@hurleysoftware.com; a...@arndb.de; linux-kernel@vger.kernel.org;
>linux-ser...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
>Subject: Re: [PATCHv4] serial: of-serial: fix up PM ops on
>no_console_suspend and port type
>
>On 10/14/2014 04:42 PM, Jingchang Lu wrote:
>> This patch fixes commit 2dea53bf57783f243c892e99c10c6921e956aa7e,
>> "serial: of-serial: add PM suspend/resume support", which disables the
>> uart clock on suspend, but also causes a hardware hang on register
>> access if no_console_suspend command line option is used.
>>
>> Also, not every of_serial device is an 8250 port, so the serial8250
>> suspend/resume functions should only be applied to a real 8250 port.
>>
>> Signed-off-by: Jingchang Lu
>
>If you can make sure this patch can build without include
>, then this patch
The build passes on my cloned linux-next tree, include next-20141014,
but is required on my another kernel-3.12+ based tree, then I didn't
add this header file when upstream.
Is the build broken on your source tree, and is the tree latest?
If the header is needed, I will add it.
Thanks.
Best Regards,
Jingchang
>
>Tested-by: Joseph Lo
>
>And thanks for your fix.
>
>> ---
>> changes in v4:
>> separate 8250 port suspend/resume from of_serial_suspend/resume.
>>
>> changes in v3:
>> fix up point reference and deference.
>>
>> changes in v2:
>> add switch selection on uart type.
>>
>> drivers/tty/serial/of_serial.c | 52
>--
>> 1 file changed, 45 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/tty/serial/of_serial.c
>> b/drivers/tty/serial/of_serial.c index 8bc2563..5281f8f 100644
>> --- a/drivers/tty/serial/of_serial.c
>> +++ b/drivers/tty/serial/of_serial.c
>> @@ -241,13 +241,48 @@ static int of_platform_serial_remove(struct
>platform_device *ofdev)
>> }
>>
>> #ifdef CONFIG_PM_SLEEP
>> -static int of_serial_suspend(struct device *dev)
>> +#ifdef CONFIG_SERIAL_8250
>> +static void of_serial_suspend_8250(struct of_serial_info *info)
>> {
>> -struct of_serial_info *info = dev_get_drvdata(dev);
>> +struct uart_8250_port *port8250 = serial8250_get_port(info->line);
>> +struct uart_port *port = &port8250->port;
>>
>> serial8250_suspend_port(info->line);
>> -if (info->clk)
>> +if (info->clk && (!uart_console(port) || console_suspend_enabled))
>> clk_disable_unprepare(info->clk);
>> +}
>> +
>> +static void of_serial_resume_8250(struct of_serial_info *info) {
>> +struct uart_8250_port *port8250 = serial8250_get_port(info->line);
>> +struct uart_port *port = &port8250->port;
>> +
>> +if (info->clk && (!uart_console(port) || console_suspend_enabled))
>> +clk_prepare_enable(info->clk);
>> +
>> +serial8250_resume_port(info->line);
>> +}
>> +#else
>> +static inline void of_serial_suspend_8250(struct of_serial_info
>> +*info) { }
>> +
>> +static inline void of_serial_resume_8250(struct of_serial_info *info)
>> +{ } #endif
>> +
>> +static int of_serial_suspend(struct device *dev) {
>> +struct of_serial_info *info = dev_get_drvdata(dev);
>> +
>> +switch(info->type) {
>> +case PORT_8250 ... PORT_MAX_8250:
>> +of_serial_suspend_8250(info);
>> +break;
>> +default:
>> +break;
>> +}
>>
>> return 0;
>> }
>> @@ -256,10 +291,13 @@ static int of_serial_resume(struct device *dev)
>> {
>> struct of_serial_info *info = dev_get_drvdata(dev);
>>
>> -if (info->clk)
>> -clk_prepare_enable(info->clk);
>> -
>> -serial8250_resume_port(info->line);
>> +switch(info->type) {
>> +case PORT_8250 ... PORT_MAX_8250:
>> +of_serial_resume_8250(info);
>> +break;
>> +default:
>> +break;
>> +}
>>
>> return 0;
>> }
>>
Re: [PATCH] Do not silently discard WRITE_SAME requests
On 10/14/2014 5:57 PM, Martin K. Petersen wrote:
"Petr" == Petr Vandrovec writes:
Petr,
Petr> Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458)
Petr> says that EOPNOTSUPP is returned when DISCARD request failed, as
Petr> discarding is optional, and failures can be safely ignored. That
Petr> is definitely not true for WRITE_SAME failures, and so unsupported
Petr> WRITE_SAME should return different error code than unsupported
Petr> DISCARD.
I agree. With Lukas' change the bio batch error handling is too
permissive for the write same case. It also made the regular zeroout
error handling case a bit fishy but it is unlikely that we'd get
EOPNOTSUPP on a regular write.
So for the block portion:
Acked-by: Martin K. Petersen
Cc: sta...@vger.kernel.org # 3.7+
Petr> revert of blacklisting VMware's LSI (if anything, blacklist should
Petr> be for current firmware version of 'VMware Virtual SCSI Disk', as
Petr> f.e. passed-through (RDM) SCSI disks do support WRITE_SAME under
Petr> VMware) -- see attached updated diff.
If you have a better heuristic then let's by all means use it. Please
adjust the pattern matching strings to match the actual values returned
by the target.
SCSI: Only blacklist WRITE SAME for VMware virtual disks
Commit 4089b71cc820 blacklisted WRITE SAME for all VMware disks.
However, the WRITE SAME commands are supported for passthrough
disks. Change the heuristic so we only blacklist virtual disks.
Hi,
is there any reason to do blacklisting? Why not let first request
fail, and switch to non-write-same code path once that happens?
If you want to go ahead with blacklisting, then entries should be:
{ "VMware", "Virtual disk", "1.0", BLIST_NO_WRITE_SAME }, //ESX
{ "VMware,", "VMware Virtual S", "1.0", BLIST_NO_WRITE_SAME }, //WS,Fusion
(yes, on Workstation and Fusion there is really comma in the vendor name
and VMware is repeated in the device ID - first is 'VMware, Inc.'
truncated to 8 characters, and second is 'VMware Virtual SCSI Hard
Drive' truncated to 16; we got revision right...)
Thanks,
Petr
Signed-off-by: Martin K. Petersen
Reported-by: Petr Vandrovec
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 613231c16194..787933d43d32 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1419,11 +1419,6 @@ mptspi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto out_mptspi_probe;
}
- /* VMWare emulation doesn't properly implement WRITE_SAME
-*/
- if (pdev->subsystem_vendor == 0x15AD)
- sh->no_write_same = 1;
-
spin_lock_irqsave(&ioc->FreeQlock, flags);
/* Attach the SCSI Host to the IOC structure
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 49014a143c6a..402aebfb97dd 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -249,6 +249,7 @@ static struct {
{"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM},
{"Traxdata", "CDR4120", NULL, BLIST_NOLUN}, /* locks up */
{"USB2.0", "SMARTMEDIA/XD", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"VMware", "Virtual SCSI Disk", NULL, BLIST_NO_WRITE_SAME},
{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index ba3f1e8d0d57..c57daffe57af 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -955,6 +955,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
if (*bflags & BLIST_NO_DIF)
sdev->no_dif = 1;
+ if (*bflags & BLIST_NO_WRITE_SAME)
+ sdev->no_write_same = 1;
+
sdev->eh_timeout = SCSI_DEFAULT_EH_TIMEOUT;
if (*bflags & BLIST_TRY_VPD_PAGES)
diff --git a/include/scsi/scsi_devinfo.h b/include/scsi/scsi_devinfo.h
index 183eaab7c380..1a24efb4b1d6 100644
--- a/include/scsi/scsi_devinfo.h
+++ b/include/scsi/scsi_devinfo.h
@@ -36,5 +36,6 @@
for sequential scan */
#define BLIST_TRY_VPD_PAGES 0x1000 /* Attempt to read VPD pages */
#define BLIST_NO_RSOC 0x2000 /* don't try to issue RSOC */
+#define BLIST_NO_WRITE_SAME0x4000 /* don't try to issue WRITE SAME */
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5] init: Disable defaults if init= fails
On Tue, Oct 14, 2014 at 10:46 PM, Frank Rowand wrote: > On 10/14/2014 2:21 PM, Andy Lutomirski wrote: >> On Tue, Oct 14, 2014 at 2:00 PM, Andrew Morton >> wrote: >>> On Wed, 1 Oct 2014 11:13:14 -0700 Andy Lutomirski >>> wrote: >>> On Wed, Oct 1, 2014 at 11:05 AM, wrote: > On Tue, Sep 30, 2014 at 09:53:56PM -0700, Andy Lutomirski wrote: >> I significantly prefer default N. Scripts that play with init= really >> don't want the fallback, and I can imagine contexts in which it could >> be a security problem. > > While I certainly would prefer the non-fallback behavior for init as > well, standard kernel practice has typically been to use "default y" for > previously built-in features that become configurable. And I'd > certainly prefer a compile-time configuration option like this (even > with default y) over a "strictinit" kernel command-line option. > Fair enough. So: "default y" for a release or two, then switch the default? Having default y will annoy virtme, though it's not the end of the world. Virtme is intended to work with more-or-less-normal kernels. >>> >>> Adding another Kconfig option is tiresome. What was wrong with strictinit=? >> >> The consensus seems to be that adding a non-default option to get > > ^ I do not think you know what the word consensus means. :-) > > I did not agree. > > I do agree with Andrew (but with no opinion on whether "strictinit=SOMETHING" > or just "strictinit". > >> sensible behavior would be unfortunate. Also, I don't like Even you're not disagreeing that it's ugly, though, FWIW. > ^ > behavior that is useful in some or many contexts Is there a context in which the current behavior is useful beyond "whoops, I typoed my grub command line edit, and I still want my system to boot into *something* even if it's the wrong thing"? I'm not personally that sympathetic to that particular use case, but maybe there's another one. --Andy > >> strictinit=, since backwards-compatible setups will have to do >> init=foo strictinit=foo. My original proposal was init=foo >> strictinit. >> >> TBH, my preference would be to make strict mode unconditional. >> http://xkcd.com/1172/ >> >> --Andy >> > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5] init: Disable defaults if init= fails
On 10/14/2014 2:21 PM, Andy Lutomirski wrote: > On Tue, Oct 14, 2014 at 2:00 PM, Andrew Morton > wrote: >> On Wed, 1 Oct 2014 11:13:14 -0700 Andy Lutomirski >> wrote: >> >>> On Wed, Oct 1, 2014 at 11:05 AM, wrote: On Tue, Sep 30, 2014 at 09:53:56PM -0700, Andy Lutomirski wrote: > I significantly prefer default N. Scripts that play with init= really > don't want the fallback, and I can imagine contexts in which it could > be a security problem. While I certainly would prefer the non-fallback behavior for init as well, standard kernel practice has typically been to use "default y" for previously built-in features that become configurable. And I'd certainly prefer a compile-time configuration option like this (even with default y) over a "strictinit" kernel command-line option. >>> >>> Fair enough. >>> >>> So: "default y" for a release or two, then switch the default? Having >>> default y will annoy virtme, though it's not the end of the world. >>> Virtme is intended to work with more-or-less-normal kernels. >>> >> >> Adding another Kconfig option is tiresome. What was wrong with strictinit=? > > The consensus seems to be that adding a non-default option to get ^ I do not think you know what the word consensus means. :-) I did not agree. I do agree with Andrew (but with no opinion on whether "strictinit=SOMETHING" or just "strictinit". > sensible behavior would be unfortunate. Also, I don't like ^ behavior that is useful in some or many contexts > strictinit=, since backwards-compatible setups will have to do > init=foo strictinit=foo. My original proposal was init=foo > strictinit. > > TBH, my preference would be to make strict mode unconditional. > http://xkcd.com/1172/ > > --Andy > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] Security : smack : Use kmem_cache for allocation and freeing of inode_smack
On Wed, 15 Oct 2014 11:26:16 +0530 Rohit Kumar wrote: > From: Rohit > > Use kmem_cache to allocate/free inode_smack since they are > alloced in high volumes making it a perfect case for kmem_cache. > > Accounting of memory allocation is below : > total slacknet count-alloc/freecaller > Before (with kzalloc) > 1919872 719952 1919872 29998/0 > new_inode_smack+0x14 > After (with kmem_cache) > 12016800 1201680 30042/0 > new_inode_smack+0x18 > > ... > > --- a/security/smack/smack_lsm.c > +++ b/security/smack/smack_lsm.c > @@ -53,6 +53,7 @@ > #define SMK_SENDING 2 > > LIST_HEAD(smk_ipv6_port_list); > +struct kmem_cache *smack_inode_cache; static. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Security : smack : Use kmem_cache for allocation and freeing of inode_smack
From: Rohit
Use kmem_cache to allocate/free inode_smack since they are
alloced in high volumes making it a perfect case for kmem_cache.
Accounting of memory allocation is below :
total slacknet count-alloc/freecaller
Before (with kzalloc)
1919872 719952 1919872 29998/0
new_inode_smack+0x14
After (with kmem_cache)
12016800 1201680 30042/0
new_inode_smack+0x18
Signed-off-by: Rohit
---
security/smack/smack_lsm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index d515ec2..58a5c92 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -53,6 +53,7 @@
#define SMK_SENDING2
LIST_HEAD(smk_ipv6_port_list);
+struct kmem_cache *smack_inode_cache;
#ifdef CONFIG_SECURITY_SMACK_BRINGUP
static void smk_bu_mode(int mode, char *s)
@@ -240,7 +241,7 @@ struct inode_smack *new_inode_smack(struct smack_known *skp)
{
struct inode_smack *isp;
- isp = kzalloc(sizeof(struct inode_smack), GFP_NOFS);
+ isp = kmem_cache_zalloc(smack_inode_cache, GFP_NOFS);
if (isp == NULL)
return NULL;
@@ -767,7 +768,7 @@ static int smack_inode_alloc_security(struct inode *inode)
*/
static void smack_inode_free_security(struct inode *inode)
{
- kfree(inode->i_security);
+ kmem_cache_free(smack_inode_cache, inode->i_security);
inode->i_security = NULL;
}
@@ -4264,10 +4265,16 @@ static __init int smack_init(void)
if (!security_module_enable(&smack_ops))
return 0;
+ smack_inode_cache = KMEM_CACHE(inode_smack, 0);
+ if (!smack_inode_cache)
+ return -ENOMEM;
+
tsp = new_task_smack(&smack_known_floor, &smack_known_floor,
GFP_KERNEL);
- if (tsp == NULL)
+ if (tsp == NULL) {
+ kmem_cache_destroy(smack_inode_cache);
return -ENOMEM;
+ }
printk(KERN_INFO "Smack: Initializing.\n");
--
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 0/3] pwm: ftm: add Power Management support
Changes in v2: - Fix one bug. - Add regmap cache support. - Remove run time PM for now. Xiubo Li (3): pwm: ftm: fix one bug of wrong counting the use counter. pwm: ftm: add regmap rbtree type cache support. pwm: ftm: add Power Management support for FTM pwm. drivers/pwm/pwm-fsl-ftm.c | 64 --- 1 file changed, 60 insertions(+), 4 deletions(-) -- 2.1.0.27.g96db324 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH (net.git) 1/1] stmmac: fix sti compatibililies
this patch is to fix the stmmac data compatibilities for
all the SoCs inside the platform file.
Signed-off-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h |3 ++-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 4452889..c3c4065 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -144,7 +144,8 @@ extern const struct stmmac_of_data meson6_dwmac_data;
extern const struct stmmac_of_data sun7i_gmac_data;
#endif
#ifdef CONFIG_DWMAC_STI
-extern const struct stmmac_of_data sti_gmac_data;
+extern const struct stmmac_of_data stih4xx_dwmac_data;
+extern const struct stmmac_of_data stid127_dwmac_data;
#endif
#ifdef CONFIG_DWMAC_SOCFPGA
extern const struct stmmac_of_data socfpga_gmac_data;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 0d6b9ad..db56fa7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -37,10 +37,10 @@ static const struct of_device_id stmmac_dt_ids[] = {
{ .compatible = "allwinner,sun7i-a20-gmac", .data = &sun7i_gmac_data},
#endif
#ifdef CONFIG_DWMAC_STI
- { .compatible = "st,stih415-dwmac", .data = &sti_gmac_data},
- { .compatible = "st,stih416-dwmac", .data = &sti_gmac_data},
- { .compatible = "st,stid127-dwmac", .data = &sti_gmac_data},
- { .compatible = "st,stih407-dwmac", .data = &sti_gmac_data},
+ { .compatible = "st,stih415-dwmac", .data = &stih4xx_dwmac_data},
+ { .compatible = "st,stih416-dwmac", .data = &stih4xx_dwmac_data},
+ { .compatible = "st,stid127-dwmac", .data = &stid127_dwmac_data},
+ { .compatible = "st,stih407-dwmac", .data = &stih4xx_dwmac_data},
#endif
#ifdef CONFIG_DWMAC_SOCFPGA
{ .compatible = "altr,socfpga-stmmac", .data = &socfpga_gmac_data },
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/exynos: fix vblank handling during dpms off
On 2014년 10월 10일 21:39, Andrzej Hajda wrote:
> On 10/02/2014 12:52 PM, Inki Dae wrote:
>> On 2014년 10월 02일 17:58, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
The patch disables vblanks during dpms off only if pagefilp has
not been finished. It also replaces drm_vblank_off with
drm_crtc_vblank_put.
It fixes issue with page_flip ioctl not being able to acquire vblank
counter.
>>> This problem isn't related with pageflip, it just causes from
>>> 7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
>>> drm_vblank_get() after drm_vblank_off()).
>>>
>>> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
>>> after the commit .
>>>
>>> How about below patch?
>> Thanks you Joonyoung and Andrzej,
>>
>> drm_vblank_on/off() are legacy api so it would be better to use
>> drm_vblank_crtc_on/off functions instead.
>>
>> And drm_vblank_crtc_off() makes sure that the latest vblank frame count
>> is stored and restored by drm_vblank_crtc_on() again. So my opinion is,
>>
>> static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
>> {
>> [snip]
>>
>> if (mode > DRM_MODE_DPMS_ON) {
>> /* wait for the completion of page flip. */
>> if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
>> !atomic_read(&exynos_crtc->pending_flip),
>> HZ/20))
>> atomic_set(&exynos_crtc->pending_flip, 0);
>> drm_crtc_vblank_off(crtc); //<- store the latest
>> vblank frame count.
>> } else {
>> drm_crtc_vblank_on(crtc); //<- restore the vblank
>> frame count.
>> }
>>
>> [snip]
>> }
>>
>>
>> Tested and worked well with above patch. How about it?
>>
>>
>
> drm_crtc_vblank_on should be called after dpms on, otherwise it can fail
> enabling vblank. I have provided
> full explanation in my other email [1].
> You can modify your patch or just use the one provided in [1].
I will just merge your patch set after review and test. :)
Thanks,
Inki Dae
>
> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/116152
>
> Regards
> Andrzej
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] SELinux list corruption fix for 3.18
On Wed, Oct 15, 2014 at 7:27 AM, Linus Torvalds wrote: > > No, the log is correct (the log always is, the back-merges can cause > the trivial *diff* to be broken). To add some details: the commits in there are f6ed66087648 Merge branch 'stable-3.18' of git://git.infradead.org/users/pcmoore/selinux into f 7c66bdc72bc3 selinux: fix inode security list corruption e7387395a07d selinux: normalize audit log formatting 8497b78ecc9d selinux: cleanup error reporting in selinux_nlmsg_perm() 6eb1ddc6bd3f selinux: make the netif cache namespace aware 5e29532fed21 selinux: register nf hooks with single nf_register_hooks call 82341ad9b962 selinux: fix a problem with IPv6 traffic denials in selinux_ip_postroute() 04e8d6ab1fa6 selinux: Permit bounded transitions under NO_NEW_PRIVS or NOSUID. and all but the list corruption fix seem to just be duplicate commits of things I have already gotten elsewhere. Somebody cherry-picking commits and duplicating them? So there are more things rotten in this tree than a back-merge. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] SELinux list corruption fix for 3.18
On Tue, Oct 14, 2014 at 5:05 PM, James Morris wrote: > This is a fix for list corruption in the SELinux code. > > Note that the git-log output is still broken due to the back-merge issue > previously discussed. The fix is in commit > 7c66bdc72bc3d792886c42bbab4b214c1fe536e0 No, the log is correct (the log always is, the back-merges can cause the trivial *diff* to be broken). Your branch has way more than that one list corruption fix in it. Please fix your branch, or fix your description. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: build failure after merge of the net tree
On 10/15/2014 4:02 AM, David Miller wrote:
From: Stephen Rothwell
Date: Wed, 15 Oct 2014 10:44:11 +1100
Hi all,
After merging the net tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/built-in.o: In function `.LANCHOR0':
:(.rodata+0x6b764): undefined reference to `sti_gmac_data'
:(.rodata+0x6b828): undefined reference to `sti_gmac_data'
:(.rodata+0x6b8ec): undefined reference to `sti_gmac_data'
:(.rodata+0x6b9b0): undefined reference to `sti_gmac_data'
Caused by commit 53b26b9bc9a5 ("stmmac: dwmac-sti: review the
glue-logic for STi4xx and STiD127 SoCs") which renamed sti_gmac_data to
stih4xx_dwmac_data (or something) without updating all the references
to it (including the one added in the previous commit ...).
I reverted that commit for today.
Sigh, Giuseppe if I don't see a proper fix by tomorrow I'm
reverting all of the stmmac changes I applied today.
I am looking at this now and let you know soon
peppe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] pwm: ftm: add Power Management support for FTM pwm.
Add PM support for FTM pwm driver using callback function suspend
and resume in .driver.pm of platform_driver.
Signed-off-by: Xiubo Li
---
drivers/pwm/pwm-fsl-ftm.c | 49 ++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
index 9bfbea5..666e1be 100644
--- a/drivers/pwm/pwm-fsl-ftm.c
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -436,7 +437,7 @@ static int fsl_pwm_probe(struct platform_device *pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- fpc->regmap = devm_regmap_init_mmio_clk(&pdev->dev, NULL, base,
+ fpc->regmap = devm_regmap_init_mmio_clk(&pdev->dev, "ftm_sys", base,
&fsl_pwm_regmap_config);
if (IS_ERR(fpc->regmap)) {
dev_err(&pdev->dev, "regmap init failed\n");
@@ -487,6 +488,51 @@ static int fsl_pwm_remove(struct platform_device *pdev)
return pwmchip_remove(&fpc->chip);
}
+#ifdef CONFIG_PM_SLEEP
+static int fsl_pwm_suspend(struct device *dev)
+{
+ struct fsl_pwm_chip *fpc = dev_get_drvdata(dev);
+ u32 val;
+
+ regcache_cache_only(fpc->regmap, true);
+ regcache_mark_dirty(fpc->regmap);
+
+ /* read from cache */
+ regmap_read(fpc->regmap, FTM_OUTMASK, &val);
+ if ((val & 0xFF) != 0xFF) {
+ clk_disable_unprepare(fpc->clk[FSL_PWM_CLK_CNTEN]);
+ clk_disable_unprepare(fpc->clk[fpc->cnt_select]);
+ clk_disable_unprepare(fpc->clk[FSL_PWM_CLK_SYS]);
+ }
+
+ return 0;
+}
+
+static int fsl_pwm_resume(struct device *dev)
+{
+ struct fsl_pwm_chip *fpc = dev_get_drvdata(dev);
+ u32 val;
+
+ /* read from cache */
+ regmap_read(fpc->regmap, FTM_OUTMASK, &val);
+ if ((val & 0xFF) != 0xFF) {
+ clk_prepare_enable(fpc->clk[FSL_PWM_CLK_SYS]);
+ clk_prepare_enable(fpc->clk[fpc->cnt_select]);
+ clk_prepare_enable(fpc->clk[FSL_PWM_CLK_CNTEN]);
+ }
+
+ /* restore all registers from cache */
+ regcache_cache_only(fpc->regmap, false);
+ regcache_sync(fpc->regmap);
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops fsl_pwm_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(fsl_pwm_suspend, fsl_pwm_resume)
+};
+
static const struct of_device_id fsl_pwm_dt_ids[] = {
{ .compatible = "fsl,vf610-ftm-pwm", },
{ /* sentinel */ }
@@ -497,6 +543,7 @@ static struct platform_driver fsl_pwm_driver = {
.driver = {
.name = "fsl-ftm-pwm",
.of_match_table = fsl_pwm_dt_ids,
+ .pm = &fsl_pwm_pm_ops,
},
.probe = fsl_pwm_probe,
.remove = fsl_pwm_remove,
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] pwm: ftm: fix one bug of wrong counting the use counter.
No matter what times the FTM pwm is enabled, the use_count will
always be one.
Signed-off-by: Xiubo Li
---
drivers/pwm/pwm-fsl-ftm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
index 0f2cc7e..1150598 100644
--- a/drivers/pwm/pwm-fsl-ftm.c
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -299,7 +299,7 @@ static int fsl_counter_clock_enable(struct fsl_pwm_chip
*fpc)
{
int ret;
- if (fpc->use_count != 0)
+ if (fpc->use_count++ != 0)
return 0;
/* select counter clock source */
@@ -316,8 +316,6 @@ static int fsl_counter_clock_enable(struct fsl_pwm_chip
*fpc)
return ret;
}
- fpc->use_count++;
-
return 0;
}
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] pwm: ftm: add regmap rbtree type cache support.
This patch is to prepare for adding PM support for FTM pwm driver
using callback function suspend and resume in .driver.pm of
platform_driver.
Signed-off-by: Xiubo Li
---
drivers/pwm/pwm-fsl-ftm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
index 1150598..9bfbea5 100644
--- a/drivers/pwm/pwm-fsl-ftm.c
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -397,12 +397,23 @@ static int fsl_pwm_init(struct fsl_pwm_chip *fpc)
return 0;
}
+static bool fsl_pwm_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case FTM_CNT:
+ return true;
+ }
+ return false;
+}
+
static const struct regmap_config fsl_pwm_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.max_register = FTM_PWMLOAD,
+ .volatile_reg = fsl_pwm_volatile_reg,
+ .cache_type = REGCACHE_RBTREE,
};
static int fsl_pwm_probe(struct platform_device *pdev)
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] x86: Enumerate kernel FSGS capability in AT_HWCAP2
From: Andi Kleen
The kernel needs to explicitely enable RD/WRFSBASE to handle context
switch correctly. So the application needs to know if it can safely use
these instruction. Just looking at the CPUID bit is not enough because it
may be running in a kernel that does not enable the instructions.
One way for the application would be to just try and catch the SIGILL.
But that is difficult to do in libraries which may not want
to overwrite the signal handlers of the main application.
So we need to provide a way for the application to discover the kernel
capability.
I used AT_HWCAP2 in the ELF aux vector which is already used by
PPC for similar things. We define a new Linux defined bitmap
returned in AT_HWCAP. Currently it has only one bit set,
for kernel is FSGSBASE capable.
The application can then access it manually or using
the getauxval() function in newer glibc.
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/elf.h| 7 +++
arch/x86/include/uapi/asm/hwcap.h | 7 +++
arch/x86/kernel/cpu/common.c | 7 ++-
3 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/include/uapi/asm/hwcap.h
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index 1a055c8..950d45d 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -256,6 +256,13 @@ extern int force_personality32;
#define ELF_HWCAP (boot_cpu_data.x86_capability[0])
+extern unsigned kernel_enabled_features;
+
+/* HWCAP2 supplies kernel enabled CPU feature, so that the application
+ can know that it can safely use them. The bits are defined in
+ uapi/asm/hwcap.h. */
+#define ELF_HWCAP2 kernel_enabled_features;
+
/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in
intent than poking at uname or /proc/cpuinfo.
diff --git a/arch/x86/include/uapi/asm/hwcap.h
b/arch/x86/include/uapi/asm/hwcap.h
new file mode 100644
index 000..d9c54f8
--- /dev/null
+++ b/arch/x86/include/uapi/asm/hwcap.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_HWCAP_H
+#define _ASM_HWCAP_H 1
+
+#define HWCAP2_FSGSBASE(1 << 0)/* Kernel enabled RD/WR FS/GS
BASE */
+/* upto bit 31 free */
+
+#endif
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 4d5368f..e099370 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,6 +49,8 @@
#include "cpu.h"
+unsigned kernel_enabled_features __read_mostly;
+
/* all of these masks are initialized in setup_cpu_local_masks() */
cpumask_var_t cpu_initialized_mask;
cpumask_var_t cpu_callout_mask;
@@ -954,8 +957,10 @@ static void identify_cpu(struct cpuinfo_x86 *c)
numa_add_cpu(smp_processor_id());
#endif
- if (cpu_has(c, X86_FEATURE_FSGSBASE))
+ if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
+ kernel_enabled_features |= HWCAP2_FSGSBASE;
set_in_cr4(X86_CR4_FSGSBASE);
+ }
}
#ifdef CONFIG_X86_64
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] x86: Make old K8 swapgs workaround conditional
From: Andi Kleen Every gs selector/index reload always paid an extra MFENCE between the two SWAPGS. This was to work around an old bug in early K8 steppings. All other CPUs don't need the extra mfence. Patch the extra MFENCE only in for K8. Signed-off-by: Andi Kleen --- arch/x86/include/asm/cpufeature.h | 1 + arch/x86/kernel/cpu/amd.c | 3 +++ arch/x86/kernel/entry_64.S| 10 +- 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index bb9b258..5125c95 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -102,6 +102,7 @@ #define X86_FEATURE_APERFMPERF ( 3*32+28) /* APERFMPERF */ #define X86_FEATURE_EAGER_FPU ( 3*32+29) /* "eagerfpu" Non lazy FPU restore */ #define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in S3 state */ +#define X86_FEATURE_SWAPGS_MFENCE (3*32+31) /* SWAPGS may need MFENCE */ /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */ #define X86_FEATURE_XMM3 ( 4*32+ 0) /* "pni" SSE-3 */ diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 60e5497..85988e8 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -544,6 +544,9 @@ static void init_amd_k8(struct cpuinfo_x86 *c) if ((level >= 0x0f48 && level < 0x0f50) || level >= 0x0f58) set_cpu_cap(c, X86_FEATURE_REP_GOOD); + /* Early steppings needed a mfence on swapgs. */ + set_cpu_cap(c, X86_FEATURE_SWAPGS_MFENCE); + /* * Some BIOSes incorrectly force this feature, but only K8 revision D * (model = 0x14) and later actually support it. diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 43b46a1..5913360 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -1216,13 +1216,21 @@ ENTRY(native_load_gs_index) SWAPGS gs_change: movl %edi,%gs -2: mfence /* workaround */ +2: ASM_NOP3/* may be replaced with mfence */ SWAPGS popfq_cfi ret CFI_ENDPROC END(native_load_gs_index) + /* Early K8 systems needed an mfence after swapgs to workaround a bug */ + .section .altinstr_replacement,"ax" +3: mfence + .previous + .section .altinstructions,"a" + altinstruction_entry 2b,3b,X86_FEATURE_SWAPGS_MFENCE,3,3 + .previous + _ASM_EXTABLE(gs_change,bad_gs) .section .fixup,"ax" /* running with kernelgs */ -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] x86: Add support for rd/wr fs/gs base
From: Andi Kleen Introduction: IvyBridge added four new instructions to directly write the fs and gs 64bit base registers. Previously this had to be done with a system call to write to MSRs. The main use case is fast user space threading and switching the fs/gs registers quickly there. Another use case is having (relatively) cheap access to a new address register per thread. The instructions are opt-in and have to be explicitely enabled by the OS. For more details on how to use the instructions see Documentation/x86/fsgs.txt added in a followon patch. Paranoid exception path changes: === The paranoid entry/exit code is used for any NMI like exception. Previously Linux couldn't support the new instructions because the paranoid entry code relied on the gs base never being negative outside the kernel to decide when to use swaps. It would check the gs MSR value and assume it was already running in kernel if negative. To get rid of this assumption we have to revamp the paranoid exception path to not rely on this. We can use the new instructions to get (relatively) quick access to the GS value, and use it directly. This is also significantly faster than a MSR read, so will speed NMIs (critical for profiling) The kernel gs for the paranoid path is now stored at the bottom of the IST stack (so that it can be derived from RSP). For this we need to know the size of the IST stack (4K or 8K), which is now passed in as a stack parameter to save_paranoid. The original patch compared the gs with the kernel gs and assumed that if it was identical, swapgs was not needed (and no user space processing was needed). This was nice and simple and didn't need a lot of changes. But this had the side effect that if a user process set its GS to the same as the kernel it may lose rescheduling checks (so a racing reschedule IPI would have been only acted upon the next non paranoid interrupt) This version now switches to full save/restore of the GS. This requires quite some changes in the paranoid path. Unfortunately I didn't come up with a simpler scheme. Previously we had a flag in EBX that indicated whether SWAPGS needs to be called later or not. In the new scheme this turns into a tristate, with a new "restore from R15" mode that is used when the FSGSBASE instructions are available. In this case the GS base is saved and restored. The exit paths are all adjusted to handle this correctly. There is one complication: to allow debuggers (especially from the int3 or debug vectors) access to the user GS we need to save it in the task struct. Normally the next context switch would overwrite it with the wrong value from kernel_gs, so we set new flag also in task_struct that prevents it. The flag is cleared on context switch. [Even with the additional flag the new FS/GS context switch is vastly faster than the old MSR based version for bases >4GB] To prevent recursive interrupts clobbering this state in the task_struct this is only done for interrupts coming directly from ring 3. After a reschedule comes back we check if the flag is still set. If it wasn't set the GS is back in the (swapped) kernel gs so we revert to the SWAPGS mode, instead of restoring GS. So the three possible states for the paranoid exit path are: - Do nothing (pre FSGSBASE), if we interrupted the kernel as determined by the existing negative GS - Do swapgs, if we interrupted user space with positive GS (pre FSGSBASE), or we saved gs, but it was overwritten later by a context switch (with FSGSBASE) - Restore from R15 (with FSGSBASE), if the gs base was saved in R15, and not overwritten by a context switch. Context switch changes: == Then after these changes we need to also use the new instructions to save/restore fs and gs, so that the new values set by the users won't disappear. This is also significantly faster for the case when the 64bit base has to be switched (that is when GS is larger than 4GB), as we can replace the slow MSR write with a faster wr[fg]sbase execution. The instructions do not context switch the segment index, so the old invariant that fs or gs index have to be 0 for a different 64bit value to stick is still true. Previously it was enforced by arch_prctl, now the user program has to make sure it keeps the segment indexes zero. If it doesn't the changes may not stick. [Yes, this implies that programs can find out when they got context switched. However they could already do that before by checking the timing.] This is in term enables fast switching when there are enough threads that their TLS segment does not fit below 4GB, or alternatively programs that use fs as an additional base register will not get a sigificant context switch penalty. It is all done in a single patch because there was no simple way to do it in pieces without having crash holes inbetween. v2: Change to save/restore GS instead of using swapgs based on the value. Large scale changes. v3: Fix wrong flag ini
[PATCH 7/8] x86: Add documentation for rd/wr fs/gs base
From: Andi Kleen
Signed-off-by: Andi Kleen
---
Documentation/x86/fsgs.txt | 73 ++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/x86/fsgs.txt
diff --git a/Documentation/x86/fsgs.txt b/Documentation/x86/fsgs.txt
new file mode 100644
index 000..d895b25
--- /dev/null
+++ b/Documentation/x86/fsgs.txt
@@ -0,0 +1,73 @@
+
+Using FS and GS prefixes on x86_64-linux
+
+The x86 architecture supports segment prefixes per instruction to add an
+offset to an address. On 64bit x86, these are mostly nops, except for FS
+and GS.
+
+This offers an efficient way to reference a global pointer.
+
+The compiler has to generate special code to use these base registers,
+or they can be accessed with inline assembler.
+
+ mov %gs:offset,%reg
+ mov %fs:offset,%reg
+
+FS is used to address the thread local segment (TLS), declared using
+__thread. The compiler the automatically generates the correct prefixes and
+relocations to access these values.
+
+FS is normally managed by the runtime code or the threading library.
+
+GS is freely available, but may need special (compiler or inline assembler)
+code to use.
+
+Traditionally 64bit FS and GS could be set by the arch_prctl system call
+
+ arch_prctl(ARCH_SET_GS, value)
+ arch_prctl(ARCH_SET_FS, value)
+
+[There was also an older method using modify_ldt(), inherited from 32bit,
+but this is not discussed here.]
+
+However using a syscall is problematic for user space threading libraries
+that want to context switch in user space.
+
+Newer Intel CPUs (Ivy Bridge and later) added new instructions to directly
+access these registers quickly from user context
+
+ RDFSBASE %reg read the FS base(or _readfsbase_u64)
+ RDGSBASE %reg read the GS base(or _readgsbase_u64)
+
+ WRFSBASE %reg write the FS base (or _writefsbase_u64)
+ WRGSBASE %reg write the GS base (or _writegsbase_u64)
+
+The instructions are supported by the CPU when the "fsgsbase" string is shown
in
+/proc/cpuinfo (or directly retrieved through the CPUID instruction).
+The instructions are only available to 64bit binaries.
+
+However the kernel needs to explicitly enable these instructions, as it
+may otherwise not correctly context switch the state. Newer Linux
+kernels enable this. When the kernel did not enable the instruction
+they will fault.
+
+An FSGSBASE enabled kernel can be detected by checking the AT_HWCAP2
+bitmask in the aux vector. When the HWCAP2_FSGSBASE bit is set the
+kernel supports RDFSGSBASE.
+
+ #include
+ #include
+
+ /* Will be eventually in asm/hwcap.h */
+ #define HWCAP2_FSGSBASE(1 << 0)
+
+unsigned val = getauxval(AT_HWCAP2);
+if (val & HWCAP2_FSGSBASE) {
+asm("wrgsbase %0" :: "r" (ptr));
+}
+
+Another requirement is that the FS or GS selector has to be zero
+(is normally true unless changed explicitly)
+
+
+Andi Kleen
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] x86: Naturally align the debug IST stack
From: Andi Kleen
The followon patch for RD*BASE requires the IST stacks to be naturally
aligned because it uses and to access the bottom of the stack.
This was true for everyone except for the debug ist stack.
Make the debug ist stack naturally aligned too.
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/page_64_types.h | 4 ++--
arch/x86/kernel/cpu/common.c | 8 +++-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 6782051..8b31477 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -17,8 +17,8 @@
#define STACKFAULT_STACK 1
#define DOUBLEFAULT_STACK 2
#define NMI_STACK 3
-#define DEBUG_STACK 4
-#define MCE_STACK 5
+#define MCE_STACK 4
+#define DEBUG_STACK 5 /* Must be always last */
#define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
#define PUD_PAGE_SIZE (_AC(1, UL) << PUD_SHIFT)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e4ab2b4..a9f1331 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1162,8 +1162,12 @@ static const unsigned int
exception_stack_sizes[N_EXCEPTION_STACKS] = {
[DEBUG_STACK - 1] = DEBUG_STKSZ
};
+/* The IST stacks must be naturally aligned */
+
static DEFINE_PER_CPU_PAGE_ALIGNED(char, exception_stacks
- [(N_EXCEPTION_STACKS - 1) * EXCEPTION_STKSZ + DEBUG_STKSZ]);
+ [(N_EXCEPTION_STACKS - 1) * EXCEPTION_STKSZ]);
+static DEFINE_PER_CPU_2PAGE_ALIGNED(char, debug_stack
+ [DEBUG_STKSZ]);
/* May not be marked __init: used by software suspend */
void syscall_init(void)
@@ -1336,6 +1340,8 @@ void cpu_init(void)
char *estacks = per_cpu(exception_stacks, cpu);
for (v = 0; v < N_EXCEPTION_STACKS; v++) {
+ if (v == DEBUG_STACK - 1)
+ estacks = per_cpu(debug_stack, cpu);
estacks += exception_stack_sizes[v];
oist->ist[v] = t->x86_tss.ist[v] =
(unsigned long)estacks;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] x86: Use rd/wr fs/gs base in arch_prctl
From: Andi Kleen
Convert arch_prctl to use the new instructions to
change fs/gs if available, instead of using MSRs.
This is merely a small performance optimization,
no new functionality.
With the new instructions the syscall is really obsolete,
as everything can be set directly in ring 3. But the syscall
is widely used by existing software, so we still support it.
The syscall still enforces that the addresses are not
in kernel space, even though that is not needed more.
This is mainly so that the programs written for new CPUs
do not suddenly fail on old CPUs.
With the new instructions available it prefers to use
them in the context switch, instead of using the old
"use GDT segment rewrite" trick.
Signed-off-by: Andi Kleen
---
arch/x86/kernel/process_64.c | 45
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 9bad75a..7669b3b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -486,15 +486,23 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
int ret = 0;
int doit = task == current;
int cpu;
+ int fast_seg = boot_cpu_has(X86_FEATURE_FSGSBASE);
switch (code) {
case ARCH_SET_GS:
+ /*
+* With fast_seg we don't need that check anymore,
+* but keep it so that programs do not suddenly
+* start failing when run on older CPUs.
+* If you really want to set a address in kernel space
+* use WRGSBASE directly.
+*/
if (addr >= TASK_SIZE_OF(task))
return -EPERM;
cpu = get_cpu();
/* handle small bases via the GDT because that's faster to
switch. */
- if (addr <= 0x) {
+ if (addr <= 0x && !fast_seg) {
set_32bit_tls(task, GS_TLS, addr);
if (doit) {
load_TLS(&task->thread, cpu);
@@ -506,8 +514,17 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
task->thread.gsindex = 0;
task->thread.gs = addr;
if (doit) {
- load_gs_index(0);
- ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, addr);
+ if (fast_seg) {
+ local_irq_disable();
+ swapgs();
+ loadsegment(gs, 0);
+ wrgsbase(addr);
+ swapgs();
+ local_irq_enable();
+ } else {
+ load_gs_index(0);
+ ret = wrmsrl_safe(MSR_KERNEL_GS_BASE,
addr);
+ }
}
}
put_cpu();
@@ -520,7 +537,7 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
cpu = get_cpu();
/* handle small bases via the GDT because that's faster to
switch. */
- if (addr <= 0x) {
+ if (addr <= 0x && !fast_seg) {
set_32bit_tls(task, FS_TLS, addr);
if (doit) {
load_TLS(&task->thread, cpu);
@@ -535,7 +552,10 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
/* set the selector to 0 to not confuse
__switch_to */
loadsegment(fs, 0);
- ret = wrmsrl_safe(MSR_FS_BASE, addr);
+ if (fast_seg)
+ wrfsbase(addr);
+ else
+ ret = wrmsrl_safe(MSR_FS_BASE, addr);
}
}
put_cpu();
@@ -544,6 +564,8 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
unsigned long base;
if (task->thread.fsindex == FS_TLS_SEL)
base = read_32bit_tls(task, FS_TLS);
+ else if (doit && fast_seg)
+ base = rdfsbase();
else if (doit)
rdmsrl(MSR_FS_BASE, base);
else
@@ -558,9 +580,16 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
base = read_32bit_tls(task, GS_TLS);
else if (doit) {
savesegment(gs, gsindex);
-
[PATCH 1/8] percpu: Add a DEFINE_PER_CPU_2PAGE_ALIGNED
From: Andi Kleen Needed in a followon patch which needs to naturally align a 8K stack. I just put it into the page aligned section. This may cause an extra 4K hole if we're unlucky. Cc: t...@kernel.org Signed-off-by: Andi Kleen --- include/linux/percpu-defs.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/percpu-defs.h b/include/linux/percpu-defs.h index cfd5604..e6e7f38 100644 --- a/include/linux/percpu-defs.h +++ b/include/linux/percpu-defs.h @@ -163,6 +163,10 @@ DEFINE_PER_CPU_SECTION(type, name, "..page_aligned")\ __aligned(PAGE_SIZE) +#define DEFINE_PER_CPU_2PAGE_ALIGNED(type, name) \ + DEFINE_PER_CPU_SECTION(type, name, "..page_aligned")\ + __aligned(2*PAGE_SIZE) + /* * Declaration/definition used for per-CPU variables that must be read mostly. */ -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] x86: Add intrinsics/macros for new rd/wr fs/gs base instructions
From: Andi Kleen
Add C intrinsics and assembler macros for the new rd/wr fs/gs base
instructions and for swapgs.
Very straight forward. Used in followon patch.
For assembler only a few standard registers used by entry_64.S
are defined.
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/fsgs.h | 54 +
1 file changed, 54 insertions(+)
create mode 100644 arch/x86/include/asm/fsgs.h
diff --git a/arch/x86/include/asm/fsgs.h b/arch/x86/include/asm/fsgs.h
new file mode 100644
index 000..1df5085
--- /dev/null
+++ b/arch/x86/include/asm/fsgs.h
@@ -0,0 +1,54 @@
+#ifndef _ASM_FSGS_H
+#define _ASM_FSGS_H 1
+
+#ifndef __ASSEMBLY__
+
+static inline void swapgs(void)
+{
+ asm volatile("swapgs" ::: "memory");
+}
+
+/* Must be protected by X86_FEATURE_FSGSBASE check. */
+
+static inline unsigned long rdgsbase(void)
+{
+ unsigned long gs;
+ asm volatile(".byte 0xf3,0x48,0x0f,0xae,0xc8 # rdgsbaseq %%rax"
+ : "=a" (gs)
+ :: "memory");
+ return gs;
+}
+
+static inline unsigned long rdfsbase(void)
+{
+ unsigned long fs;
+ asm volatile(".byte 0xf3,0x48,0x0f,0xae,0xc0 # rdfsbaseq %%rax"
+ : "=a" (fs)
+ :: "memory");
+ return fs;
+}
+
+static inline void wrgsbase(unsigned long gs)
+{
+ asm volatile(".byte 0xf3,0x48,0x0f,0xae,0xd8 # wrgsbaseq %%rax"
+ :: "a" (gs)
+ : "memory");
+}
+
+static inline void wrfsbase(unsigned long fs)
+{
+ asm volatile(".byte 0xf3,0x48,0x0f,0xae,0xd0 # wrfsbaseq %%rax"
+ :: "a" (fs)
+ : "memory");
+}
+
+#else
+
+/* Handle old assemblers. */
+#define RDGSBASE_R15 .byte 0xf3,0x49,0x0f,0xae,0xcf
+#define WRGSBASE_RDI .byte 0xf3,0x48,0x0f,0xae,0xdf
+#define WRGSBASE_R15 .byte 0xf3,0x49,0x0f,0xae,0xdf
+
+#endif /* __ASSEMBLY__ */
+
+#endif
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: dwc3: be more verbose on ERRATIC_ERROR interrupt
Hi, On Tue, Oct 14, 2014 at 01:15:05PM -0700, David Cohen wrote: > ERRATIC_ERROR interrupt is an event that needs more attention from > developers than currently implemented, since this indicates a serious > stability issue. The only way to get warned about it is by selecting the > maximum driver's verbosity. > > This patch increases a bit the error's verbosity. > > Signed-off-by: David Cohen > --- > drivers/usb/dwc3/gadget.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 3818b26bfc05..132e761d62e4 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -2484,7 +2484,8 @@ static void dwc3_gadget_interrupt(struct dwc3 *dwc, > dev_vdbg(dwc->dev, "Start of Periodic Frame\n"); > break; > case DWC3_DEVICE_EVENT_ERRATIC_ERROR: > - dev_vdbg(dwc->dev, "Erratic Error\n"); > + WARN_ON_ONCE(1); > + dev_dbg(dwc->dev, "Erratic Error\n"); how about: WARN_ONCE(true, "Erratic Error\n"); instead ? > break; > case DWC3_DEVICE_EVENT_CMD_CMPL: > dev_vdbg(dwc->dev, "Command Complete\n"); > -- > 2.1.0 > -- balbi signature.asc Description: Digital signature
Re: [PATCH RFC] virtio_net: enable tx interrupt
On 10/15/2014 12:33 PM, Jason Wang wrote:
> On 10/15/2014 07:11 AM, Michael S. Tsirkin wrote:
>> > On Wed, Oct 15, 2014 at 12:53:59AM +0300, Michael S. Tsirkin wrote:
>> > static void skb_xmit_done(struct virtqueue *vq)
>> > {
>> > struct virtnet_info *vi = vq->vdev->priv;
>> > + struct send_queue *sq = &vi->sq[vq2txq(vq)];
>> >
>> > - /* Suppress further interrupts. */
>> > - virtqueue_disable_cb(vq);
>> > -
>> > One note here: current code seems racy because of doing
>> > virtqueue_disable_cb from skb_xmit_done that I'm dropping here: there's
>> > no guarantee we don't get an interrupt while tx ring is running, and if
>> > that happens we can end up with interrupts disabled forever.
>> >
> Looks harmless since:
>
> - if event index is enabled, virtqueue_disable_cb() does nothing in fact.
> - if event index is disabled, we don't depend on tx interrupt and when
> num_free is low we will try to enable the tx interrupt again.
Ok, I think I get you here. For 'current' you mean the rfc I post.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio_balloon: return the amount of freed memory from leak_balloon()
From: Raushaniya Maksudova
This value would be useful in the next patch to provide the amount of
the freed memory for OOM killer.
Signed-off-by: Raushaniya Maksudova
Signed-off-by: Denis V. Lunev
CC: Rusty Russell
CC: Michael S. Tsirkin
---
drivers/virtio/virtio_balloon.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index f893148..66cac10 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -168,8 +168,9 @@ static void release_pages_by_pfn(const u32 pfns[], unsigned
int num)
}
}
-static void leak_balloon(struct virtio_balloon *vb, size_t num)
+static unsigned leak_balloon(struct virtio_balloon *vb, size_t num)
{
+ unsigned num_freed_pages;
struct page *page;
struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info;
@@ -186,6 +187,7 @@ static void leak_balloon(struct virtio_balloon *vb, size_t
num)
vb->num_pages -= VIRTIO_BALLOON_PAGES_PER_PAGE;
}
+ num_freed_pages = vb->num_pfns;
/*
* Note that if
* virtio_has_feature(vdev, VIRTIO_BALLOON_F_MUST_TELL_HOST);
@@ -195,6 +197,7 @@ static void leak_balloon(struct virtio_balloon *vb, size_t
num)
tell_host(vb, vb->deflate_vq);
mutex_unlock(&vb->balloon_lock);
release_pages_by_pfn(vb->pfns, vb->num_pfns);
+ return num_freed_pages;
}
static inline void update_stat(struct virtio_balloon *vb, int idx,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] shrink virtio baloon on OOM in guest
Excessive virtio_balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. Various mechanisms are responsible for correct virtio_balloon memory management. Nevertheless it is often the case that these control tools does not have enough time to react on fast changing memory load. As a result OS runs out of memory and invokes OOM-killer. The balancing of memory by use of the virtio balloon should not cause the termination of processes while there are pages in the balloon. Now there is no way for virtio balloon driver to free memory at the last moment before some process get killed by OOM-killer. This does not provide a security breach as baloon itself is running inside guest OS and is working in the cooperation with the host. Thus some improvements from guest side should be considered as normal. To solve the problem, introduce a virtio_balloon callback which is expected to be called from the oom notifier call chain in out_of_memory() function. If virtio balloon could release some memory, it will make the system to return and retry the allocation that forced the out of memory killer to run. Patch 1 of this series adds support for implementation of virtio_balloon callback, so now leak_balloon() function returns number of freed pages. Patch 2 implements virtio_balloon callback itself. Changes from v1: - minor cosmetic tweaks suggested by rusty@ Signed-off-by: Raushaniya Maksudova Signed-off-by: Denis V. Lunev CC: Rusty Russell CC: Michael S. Tsirkin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio_balloon: free some memory from balloon on OOM
From: Raushaniya Maksudova
Excessive virtio_balloon inflation can cause invocation of OOM-killer,
when Linux is under severe memory pressure. Various mechanisms are
responsible for correct virtio_balloon memory management. Nevertheless
it is often the case that these control tools does not have enough time
to react on fast changing memory load. As a result OS runs out of memory
and invokes OOM-killer. The balancing of memory by use of the virtio
balloon should not cause the termination of processes while there are
pages in the balloon. Now there is no way for virtio balloon driver to
free some memory at the last moment before some process will be get
killed by OOM-killer.
This does not provide a security breach as balloon itself is running
inside guest OS and is working in the cooperation with the host. Thus
some improvements from guest side should be considered as normal.
To solve the problem, introduce a virtio_balloon callback which is
expected to be called from the oom notifier call chain in out_of_memory()
function. If virtio balloon could release some memory, it will make
the system to return and retry the allocation that forced the out of
memory killer to run.
Signed-off-by: Raushaniya Maksudova
Signed-off-by: Denis V. Lunev
CC: Rusty Russell
CC: Michael S. Tsirkin
---
drivers/virtio/virtio_balloon.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 66cac10..ab1fa69 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -36,6 +37,12 @@
*/
#define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >>
VIRTIO_BALLOON_PFN_SHIFT)
#define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
+#define OOM_VBALLOON_DEFAULT_PAGES 256
+#define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
+
+static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
+module_param(oom_pages, int, S_IRUSR | S_IWUSR);
+MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
struct virtio_balloon
{
@@ -71,6 +78,9 @@ struct virtio_balloon
/* Memory statistics */
int need_stats_update;
struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR];
+
+ /* To register callback in oom notifier call chain */
+ struct notifier_block nb;
};
static struct virtio_device_id id_table[] = {
@@ -290,6 +300,35 @@ static void update_balloon_size(struct virtio_balloon *vb)
&actual);
}
+/*
+ * virtballoon_oom_notify - release pages when system is under severe
+ * memory pressure (called from out_of_memory())
+ * @self : notifier block struct
+ * @dummy: not used
+ * @parm : returned - number of freed pages
+ *
+ * The balancing of memory by use of the virtio balloon should not cause
+ * the termination of processes while there are pages in the balloon.
+ * If virtio balloon manages to release some memory, it will make the
+ * system return and retry the allocation that forced the OOM killer
+ * to run.
+ */
+static int virtballoon_oom_notify(struct notifier_block *self,
+ unsigned long dummy, void *parm)
+{
+ unsigned num_freed_pages;
+ unsigned long *freed;
+ struct virtio_balloon *vb;
+
+ freed = parm;
+ vb = container_of(self, struct virtio_balloon, nb);
+ num_freed_pages = leak_balloon(vb, oom_pages);
+ update_balloon_size(vb);
+ *freed += num_freed_pages;
+
+ return NOTIFY_OK;
+}
+
static int balloon(void *_vballoon)
{
struct virtio_balloon *vb = _vballoon;
@@ -446,6 +485,12 @@ static int virtballoon_probe(struct virtio_device *vdev)
if (err)
goto out_free_vb;
+ vb->nb.notifier_call = virtballoon_oom_notify;
+ vb->nb.priority = VIRTBALLOON_OOM_NOTIFY_PRIORITY;
+ err = register_oom_notifier(&vb->nb);
+ if (err < 0)
+ goto out_oom_notify;
+
vb->thread = kthread_run(balloon, vb, "vballoon");
if (IS_ERR(vb->thread)) {
err = PTR_ERR(vb->thread);
@@ -455,6 +500,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
return 0;
out_del_vqs:
+ unregister_oom_notifier(&vb->nb);
+out_oom_notify:
vdev->config->del_vqs(vdev);
out_free_vb:
kfree(vb);
@@ -479,6 +526,7 @@ static void virtballoon_remove(struct virtio_device *vdev)
{
struct virtio_balloon *vb = vdev->priv;
+ unregister_oom_notifier(&vb->nb);
kthread_stop(vb->thread);
remove_common(vb);
kfree(vb);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] virtio_net: enable tx interrupt
On 10/15/2014 07:11 AM, Michael S. Tsirkin wrote:
> On Wed, Oct 15, 2014 at 12:53:59AM +0300, Michael S. Tsirkin wrote:
>> > static void skb_xmit_done(struct virtqueue *vq)
>> > {
>> >struct virtnet_info *vi = vq->vdev->priv;
>> > + struct send_queue *sq = &vi->sq[vq2txq(vq)];
>> >
>> > - /* Suppress further interrupts. */
>> > - virtqueue_disable_cb(vq);
>> > -
> One note here: current code seems racy because of doing
> virtqueue_disable_cb from skb_xmit_done that I'm dropping here: there's
> no guarantee we don't get an interrupt while tx ring is running, and if
> that happens we can end up with interrupts disabled forever.
>
Looks harmless since:
- if event index is enabled, virtqueue_disable_cb() does nothing in fact.
- if event index is disabled, we don't depend on tx interrupt and when
num_free is low we will try to enable the tx interrupt again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 15
Hi all, Please do not add any material intended for v3.19 to your linux-next included trees until after v3.18-rc1 has been released. Changes since 20141014: Added tree: drm-misc The akpm tree lost most of its patches that turned up in Linus' tree. Non-merge commits (relative to Linus' tree): 1604 1324 files changed, 39745 insertions(+), 15368 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 225 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (2d65a9f48fcd Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (ad684dce87fa ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset") Merging m68k-current/for-linus (24cae7934cf1 m68k: Reformat arch/m68k/mm/hwtest.c) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging powerpc-merge-mpe/for-linus (d53ba6b3bba3 cxl: Fix afu_read() not doing finish_wait() on signal or non-blocking) Merging sparc/master (bdcf81b658eb sparc64: Fix lockdep warnings on reboot on Ultra-5) Merging net/master (9b462d02d6dd tcp: TCP Small Queues and strange attractors) [master 247e414efb00] Revert "stmmac: dwmac-sti: review the glue-logic for STi4xx and STiD127 SoCs" Merging ipsec/master (b8c203b2d2fc xfrm: Generate queueing routes only from route lookup functions) Merging sound-current/for-linus (3f4032861cfb ALSA: bebob: Fix failure to detect source of clock for Terratec Phase 88) Merging pci-current/for-linus (7cbeb9f90db8 PCI: pciehp: Fix pcie_wait_cmd() timeout) Merging wireless/master (f8adaf0ae978 brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()) Merging driver-core.current/driver-core-linus (5e40d331bd72 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security) Merging tty.current/tty-linus (9e82bf014195 Linux 3.17-rc5) Merging usb.current/usb-linus (0f33be009b89 Linux 3.17-rc6) Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when multiple TRBs are started) Merging usb-serial-fixes/usb-linus (dee80ad12d2b USB: cp210x: add support for Seluxit USB dongle) Merging staging.current/staging-linus (80213c03c415 Merge tag 'pci-v3.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging char-misc.current/char-misc-linus (9e82bf014195 Linux 3.17-rc5) Merging input-current/for-linus (447a8b858e4b Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (be34c4ef693f crypto: sha - Handle unaligned input data in generic sha256 and sha512.) Merging ide/master (a53dae49b2fe ide: use module_platform_driver()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL dereference in selftest removal code) Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip readin
Linus GIT 3.17.0+ - BUG: unable to handle kernel paging request - IP: [] scan_block+0x59/0x100
[ 68.164917] BUG: unable to handle kernel paging request at 88021dc52000 [ 68.164957] IP: [] scan_block+0x59/0x100 [ 68.164987] PGD 2902067 PUD 2905067 PMD 21fdf2067 PTE 80021dc52060 [ 68.165020] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 68.165048] Modules linked in: ecb uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev ath3k media btusb snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi dell_wmi ipv6 bnep rfcomm bluetooth dell_laptop snd_soc_rt5640 snd_soc_rl6231 intel_rapl x86_pkg_temp_thermal snd_soc_core intel_powerclamp snd_compress coretemp microcode snd_pcm_dmaengine ath9k snd_seq_dummy ath9k_common ath9k_hw ath mac80211 snd_seq_oss snd_hda_intel cfg80211 sr_mod snd_hda_controller cdrom snd_seq_midi rfkill r8169 ehci_pci snd_hda_codec mii snd_hwdep lpc_ich ehci_hcd snd_rawmidi snd_pcm_oss snd_mixer_oss wmi mei_me snd_pcm thermal xhci_pci snd_seq_midi_event shpchp mei xhci_hcd snd_seq battery snd_seq_device snd_timer sdhci_acpi snd sdhci soundcore snd_soc_sst_acpi mmc_core ac processor [ 68.165428] fuse [ 68.165434] CPU: 2 PID: 1017 Comm: kmemleak Not tainted 3.17.0+ #17 [ 68.165463] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 11/14/2013 [ 68.165494] task: 8802115a4dc0 ti: 8800d57ac000 task.ti: 8800d57ac000 [ 68.165527] RIP: 0010:[] [] scan_block+0x59/0x100 [ 68.165563] RSP: 0018:8800d57afd78 EFLAGS: 00010046 [ 68.165587] RAX: RBX: 880214828000 RCX: [ 68.165618] RDX: 880214828000 RSI: 88021dc53000 RDI: 88021dc52000 [ 68.165648] RBP: 8800d57afdb8 R08: 0001 R09: 003f6033 [ 68.165678] R10: R11: 0001 R12: 88021dc52000 [ 68.165708] R13: 88021dc52ff9 R14: 880214828000 R15: [ 68.165739] FS: () GS:88021db0() knlGS: [ 68.165775] CS: 0010 DS: ES: CR0: 80050033 [ 68.165800] CR2: 88021dc52000 CR3: 0001fd838000 CR4: 001407e0 [ 68.165830] Stack: [ 68.165839] 8800d57afdb8 81528559 8110a016 880214828000 [ 68.165874] 88021ec0 880214828050 0292 88021dc53000 [ 68.165910] 8800d57afdf8 81109feb 8802115a5678 81a16580 [ 68.165945] Call Trace: [ 68.165960] [] ? _raw_spin_lock_irqsave+0x48/0x52 [ 68.165988] [] ? scan_gray_list+0xe2/0x15f [ 68.166015] [] scan_gray_list+0xb7/0x15f [ 68.166040] [] kmemleak_scan+0x29c/0x466 [ 68.166066] [] ? kmemleak_write+0x354/0x354 [ 68.166092] [] kmemleak_scan_thread+0x82/0xa4 [ 68.166120] [] kthread+0xd6/0xde [ 68.166143] [] ? __kthread_parkme+0x62/0x62 [ 68.166170] [] ret_from_fork+0x7c/0xb0 [ 68.166195] [] ? __kthread_parkme+0x62/0x62 [ 68.166220] Code: 00 45 85 ff 74 18 31 d2 be 86 04 00 00 48 c7 c7 24 cf 7f 81 e8 c0 d8 f4 ff e8 a2 ab 41 00 e8 20 fc ff ff 85 c0 0f 85 98 00 00 00 <49> 8b 3c 24 be 01 00 00 00 e8 09 f9 ff ff 48 85 c0 48 89 c3 74 [ 68.166370] RIP [] scan_block+0x59/0x100 [ 68.166396] RSP [ 68.166411] CR2: 88021dc52000 [ 68.172682] ---[ end trace fe9bfcfd7e0c3b2d ]--- [ 68.172685] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41 [ 68.172687] in_atomic(): 1, irqs_disabled(): 1, pid: 1017, name: kmemleak [ 68.172688] INFO: lockdep is turned off. [ 68.172689] irq event stamp: 11064396 [ 68.172690] hardirqs last enabled at (11064395): [] _raw_spin_unlock_irqrestore+0x3a/0x5c [ 68.172693] hardirqs last disabled at (11064396): [] _raw_spin_lock_irqsave+0x1a/0x52 [ 68.172697] softirqs last enabled at (10535470): [] __do_softirq+0x21b/0x277 [ 68.172700] softirqs last disabled at (10535465): [] irq_exit+0x59/0xd0 [ 68.172702] Preemption disabled at:[] scan_gray_list+0xe2/0x15f [ 68.172707] CPU: 2 PID: 1017 Comm: kmemleak Tainted: G D 3.17.0+ #17 [ 68.172708] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 11/14/2013 [ 68.172709] 03f9 8800d57af978 815221b2 810790d7 [ 68.172712] 8800d57af9a8 8105794f 7000 [ 68.172715] 880211fe8bf8 0009 0046 8800d57af9c8 [ 68.172718] Call Trace: [ 68.172722] [] dump_stack+0x4f/0x7c [ 68.172726] [] ? console_unlock+0x348/0x394 [ 68.172729] [] __might_sleep+0x214/0x21c [ 68.172733] [] down_read+0x1c/0x4b [ 68.172737] [] exit_signals+0x21/0x115 [ 68.172740] [] ? kmsg_dump+0x1d/0x199 [ 68.172744] [] do_exit+0x108/0x9a5 [ 68.172747] [] ? kmsg_dump+0x173/0x199 [ 68.172762] [] ? kmsg_dump+0x190/0x199 [ 68.172767] [] oops_end+0xa1/0xa9 [ 68.172774] [] no_context+0x2d6/0x338 [ 68.172780] [] ? find_usage_backwards+0x68/0x70 [ 68.172785] [] __bad_area_nosemaphore+0x6f/0x1bf [ 68.172791] [] bad_area_nosemaphore+0xe/0x10 [ 68.172796] [] __do_page_fault+0x181/0x363 [ 68.172
Re: [resend Patch v3 1/2] kaslr: check if kernel location is changed
On 10/14/14 at 08:49am, Vivek Goyal wrote: > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote: > > On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote: > > > On 10/13/2014 08:19 AM, Vivek Goyal wrote: > > > >>> > > > >>> This really shouldn't have happened this way on x86-64. It has to > > > >>> happen > > > >>> this way on i386, but I worry that this may be a serious misdesign in > > > >>> kaslr > > > >>> on x86-64. I'm also wondering if there is any other fallout of this? > > > >> > > > >> I agree. On x86_64, we should stick to previous design and this new > > > >> logic of performing relocations does not sound very clean and makes > > > >> things very confusing. > > > >> > > > >> I am wondering that why couldn't we simply adjust page tables in case > > > >> of > > > >> kaslr on x86_64, instead of performing relocations. > > > > > > > > Well, IIUC, if virtual addresses are shifted w.r.t what virtual address > > > > kernel was compiled for, then relocation will have to be done. > > > > > > > > So question will be if physical address shift is enough for kaslr or > > > > virtual address shift is necessary. > > > > > > > > > > I would assume that without a virtual address shift kaslr is pretty darn > > > pointless. Without the physical address shift the 1:1 map can be used, > > > and again, kaslr becomes pointless. However, there is absolutely no > > > reason why they should be coupled. They can, in fact, be independently > > > randomized. > > > > Agreed. On x86_64, we should be able to randomize virtual address space > > and physical address space independently. And in that case whole of > > the physical memory should be available for a possible location for > > kernel. (As opposed to a small limit (I guess 1GB) now) It can be done to randomize virtual address space and physical address space independently. But limited by the 2G of kernel text mapping and module mapping virtual address space, virtual address can be randomized in (0x100, 1G) range. While physical address can be randomized in (0x100, 4G) according to the identity mapping of normal kernel. Then phys_base still stores an relative value, a different offset than before. This can be easily implement. One thing is still there's a limit for physical addr randomization, only below 4G. So I am wondering if we can extend the identify mapping to complete mapping of 48 bit, using 1G page frame. This can make physical addr be randomized to anywhere. So now there may be 3 options: 1) Fix this bug in current kaslr. Since when randomize the new kernel location in choose_kernel_location(), cmdline options has been checked strictly, e.g if nokaslr is specified, it's safe to do the kernel location randomization. Then in handle_relocations(), we only need to check if the kernel location is changed, comparing with kernel loaded addr. If changed, kaslr is done, let's do the relocation handling. If not changed, no kaslr id done, just skip the relocation handling like before. 2) randomize the virtual addr space and physical addr space independently. But physical addr space must be below 4G. 3) extend the identity mapping to 48bit of addr space. Then we can randomized the virtual addr space in (0x100, 1G) and physical addr space in (0x100, real physical memory end). If option 3 is doable, it's the best. If not, I think bug fix should be better. > > Hi Peter, > > So what do we do about this issue in short term to make kexec work. Even > if we go for above solution, to make kexec work we will have to pass > "nokaslr" as we don't want kernel to move around in physical address space > as it might stomp over ELF headers we have stored. kexec doesn't need ELF headers. Kdump may need it. But in current kexec-tools implementation, kernel/initrd and other stuffs are placed from top to down, current implementation won't do kaslr since it only happened between kernel loaded addr and 1G. So we don't need to worry about the stomping. > > If you don't like current patch, should we just disable relocations in > x86_64 if "nokaslr" command line is passed. That way kernel will not > be moved in physical as well as virtual address space. > > Thanks > Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-next RFC 3/3] virtio-net: conditionally enable tx interrupt
On 10/15/2014 05:51 AM, Michael S. Tsirkin wrote:
> On Sat, Oct 11, 2014 at 03:16:46PM +0800, Jason Wang wrote:
>> > We free transmitted packets in ndo_start_xmit() in the past to get better
>> > performance in the past. One side effect is that skb_orphan() needs to be
>> > called in ndo_start_xmit() which makes sk_wmem_alloc not accurate in
>> > fact. For TCP protocol, this means several optimization could not work well
>> > such as TCP small queue and auto corking. This can lead extra low
>> > throughput of small packets stream.
>> >
>> > Thanks to the urgent descriptor support. This patch tries to solve this
>> > issue by enable the tx interrupt selectively for stream packets. This means
>> > we don't need to orphan TCP stream packets in ndo_start_xmit() but enable
>> > tx interrupt for those packets. After we get tx interrupt, a tx napi was
>> > scheduled to free those packets.
>> >
>> > With this method, sk_wmem_alloc of TCP socket were more accurate than in
>> > the past which let TCP can batch more through TSQ and auto corking.
>> >
>> > Signed-off-by: Jason Wang
>> > ---
>> > drivers/net/virtio_net.c | 164
>> > ---
>> > 1 file changed, 128 insertions(+), 36 deletions(-)
>> >
>> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> > index 5810841..b450fc4 100644
>> > --- a/drivers/net/virtio_net.c
>> > +++ b/drivers/net/virtio_net.c
>> > @@ -72,6 +72,8 @@ struct send_queue {
>> >
>> >/* Name of the send queue: output.$index */
>> >char name[40];
>> > +
>> > + struct napi_struct napi;
>> > };
>> >
>> > /* Internal representation of a receive virtqueue */
>> > @@ -217,15 +219,40 @@ static struct page *get_a_page(struct receive_queue
>> > *rq, gfp_t gfp_mask)
>> >return p;
>> > }
>> >
>> > +static int free_old_xmit_skbs(struct send_queue *sq, int budget)
>> > +{
>> > + struct sk_buff *skb;
>> > + unsigned int len;
>> > + struct virtnet_info *vi = sq->vq->vdev->priv;
>> > + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
>> > + int sent = 0;
>> > +
>> > + while (sent < budget &&
>> > + (skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
>> > + pr_debug("Sent skb %p\n", skb);
>> > +
>> > + u64_stats_update_begin(&stats->tx_syncp);
>> > + stats->tx_bytes += skb->len;
>> > + stats->tx_packets++;
>> > + u64_stats_update_end(&stats->tx_syncp);
>> > +
>> > + dev_kfree_skb_any(skb);
>> > + sent++;
>> > + }
>> > +
>> > + return sent;
>> > +}
>> > +
>> > static void skb_xmit_done(struct virtqueue *vq)
>> > {
>> >struct virtnet_info *vi = vq->vdev->priv;
>> > + struct send_queue *sq = &vi->sq[vq2txq(vq)];
>> >
>> > - /* Suppress further interrupts. */
>> > - virtqueue_disable_cb(vq);
>> > -
>> > - /* We were probably waiting for more output buffers. */
>> > - netif_wake_subqueue(vi->dev, vq2txq(vq));
>> > + if (napi_schedule_prep(&sq->napi)) {
>> > + virtqueue_disable_cb(vq);
>> > + virtqueue_disable_cb_urgent(vq);
> This disable_cb is no longer safe in xmit_done callback,
> since queue can be running at the same time.
>
> You must do it under tx lock. And yes, this likely will not work
> work well without event_idx. We'll probably need extra
> synchronization for such old hosts.
>
>
>
Yes, and the virtqueue_enable_cb_prepare() in virtnet_poll_tx() needs to
be synced with virtqueue_enabled_cb_dealyed(). Otherwise an old idx will
be published and we may still see tx interrupt storm.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: fix incorrect header string
Commit fbe96f29 (perf tools: Make perf.data more self-descriptive) read '/proc/cpuinfo' to form cpu descriptor. For ARM, it finds 'Processor' field. It is correct when the patch merged, but due to commit b4b8f770 (ARM: kernel: update cpuinfo to print all online CPUs features), the corresponding information becomes 'model name' field. This patch simply corrects it. Signed-off-by: Wang Nan --- tools/perf/perf-sys.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h index 937e432..4293970 100644 --- a/tools/perf/perf-sys.h +++ b/tools/perf/perf-sys.h @@ -113,7 +113,7 @@ #define mb() ((void(*)(void))0x0fa0)() #define wmb() ((void(*)(void))0x0fa0)() #define rmb() ((void(*)(void))0x0fa0)() -#define CPUINFO_PROC "Processor" +#define CPUINFO_PROC "model name" #endif #ifdef __aarch64__ -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next RFC 0/3] virtio-net: Conditionally enable tx interrupt
On 10/15/2014 05:51 AM, Michael S. Tsirkin wrote: > On Tue, Oct 14, 2014 at 02:53:27PM -0400, David Miller wrote: >> From: Jason Wang >> Date: Sat, 11 Oct 2014 15:16:43 +0800 >> >>> We free old transmitted packets in ndo_start_xmit() currently, so any >>> packet must be orphaned also there. This was used to reduce the overhead of >>> tx interrupt to achieve better performance. But this may not work for some >>> protocols such as TCP stream. TCP depends on the value of sk_wmem_alloc to >>> implement various optimization for small packets stream such as TCP small >>> queue and auto corking. But orphaning packets early in ndo_start_xmit() >>> disable such things more or less since sk_wmem_alloc was not accurate. This >>> lead extra low throughput for TCP stream of small writes. >>> >>> This series tries to solve this issue by enable tx interrupts for all TCP >>> packets other than the ones with push bit or pure ACK. This is done through >>> the support of urgent descriptor which can force an interrupt for a >>> specified packet. If tx interrupt was enabled for a packet, there's no need >>> to orphan it in ndo_start_xmit(), we can free it tx napi which is scheduled >>> by tx interrupt. Then sk_wmem_alloc was more accurate than before and TCP >>> can batch more for small write. More larger skb was produced by TCP in this >>> case to improve both throughput and cpu utilization. >>> >>> Test shows great improvements on small write tcp streams. For most of the >>> other cases, the throughput and cpu utilization are the same in the >>> past. Only few cases, more cpu utilization was noticed which needs more >>> investigation. >>> >>> Review and comments are welcomed. >> I think proper accounting and queueing (at all levels, not just TCP >> sockets) is more important than trying to skim a bunch of cycles by >> avoiding TX interrupts. >> >> Having an event to free the SKB is absolutely essential for the stack >> to operate correctly. >> >> And with virtio-net you don't even have the excuse of "the HW >> unfortunately doesn't have an appropriate TX event." >> >> So please don't play games, and instead use TX interrupts all the >> time. You can mitigate them in various ways, but don't turn them on >> selectively based upon traffic type, that's terrible. > This got me thinking: how about using virtqueue_enable_cb_delayed > for this mitigation? Should work, another possible solution is interrupt coalescing, which can speed up also the case without event index. > It's pretty easy to implement - I'll send a proof of concept patch > separately. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] arm64: Add DTS support for Spreadtrum's Shark64 SoC
Hi, Arnd
2014-09-29 21:47 GMT+08:00 Arnd Bergmann :
> On Monday 29 September 2014 20:04:49 zhang.l...@gmail.com wrote:
>> +
>> +/memreserve/ 0x8000 0x0001;
>
> Maybe add a comment explaining why it is reserved?
>
>> + chosen {
>> + bootargs = "earlycon=serial_sprd,0x7000";
>> + };
>
> Just remove this for now, the command line should really be set by the
> boot loader, not hardcoded in the dts file.
>
> IIRC, the earlycon=... syntax is not recommended on DT based systems,
> better use the "stdout-path" syntax instead.
>
I have tried to use "stdout-path" instead of "bootargs= "earlycon=
..." like below :
/ {
...
chosen {
stdout-path = "/serial@7000";
};
uart0: serial@7000 {
status="okay";
};
...
};
But then there is nothing output information on serial console.(I have
been testing in Fast Model)
I saw the below code in init/main.c
/* Check for early params. */
static int __init do_early_param(char *param, char *val, const char *unused)
{
const struct obs_kernel_param *p;
for (p = __setup_start; p < __setup_end; p++) {
if ((p->early && parameq(param, p->str)) ||
(strcmp(param, "console") == 0 &&
strcmp(p->str, "earlycon") == 0)
) {
if (p->setup_func(val) != 0)
pr_warn("Malformed early option '%s'\n", param);
}
}
/* We accept everything at this stage. */
return 0;
}
And I saw a patch from Grant Likely, he had a comment in it :
"If the devicetree specifies a serial port as a stdout device, then the
kernel can use it as the default console if nothing else was selected on
the command line. For any serial port that uses the uart_add_one_port()
feature, the uart_add_one_port() has all the information needed to
automatically enable the console device, which is what this patch does."
So, I guess that the reason why I can't see any output information on
console after using "stdout-path" instead of "earlycon" is that I
haven't a driver of Spreadtrum's serial, and dose not use the
uart_add_one_port() feature.
I don't know is correct what I guess.
Could you give me some suggestions to solve this problem?
Thanks,
Chunyan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 6/6] ARM: mach-bcm: Consolidate currently supported IPROC SoCs
Move ARCH_BCM_5301X subarch under ARCH_IPROC architecture. Additional IPROC chipsets that share a lot of commonality should be added under ARCH_IPROC as well. Signed-off-by: Scott Branden --- arch/arm/mach-bcm/Kconfig | 37 - 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index ecc544a..08e7103 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -33,6 +33,22 @@ menu "iProc SoC based Machine types" which includes the following variants: BCM11300, BCM11320, BCM11350, BCM11360, BCM58300, BCM58302, BCM58303, BCM58305. + + config ARCH_BCM_5301X + bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7 + select ARCH_BCM_IPROC + help + Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores. + + This is a network SoC line mostly used in home routers and + wifi access points, it's internal name is Northstar. + This inclused the following SoC: BCM53010, BCM53011, BCM53012, + BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707, + BCM4708 and BCM4709. + + Do not confuse this with the BCM4760 which is a totally + different SoC or with the older BCM47XX and BCM53XX based + network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx endmenu config ARCH_BCM_MOBILE @@ -108,27 +124,6 @@ config ARCH_BCM2835 This enables support for the Broadcom BCM2835 SoC. This SoC is used in the Raspberry Pi and Roku 2 devices. -config ARCH_BCM_5301X - bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7 - select ARM_GIC - select CACHE_L2X0 - select HAVE_ARM_SCU if SMP - select HAVE_ARM_TWD if SMP - select ARM_GLOBAL_TIMER - select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK - help - Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores. - - This is a network SoC line mostly used in home routers and - wifi access points, it's internal name is Northstar. - This inclused the following SoC: BCM53010, BCM53011, BCM53012, - BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707, - BCM4708 and BCM4709. - - Do not confuse this with the BCM4760 which is a totally - different SoC or with the older BCM47XX and BCM53XX based - network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx - config ARCH_BCM_63XX bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7 depends on MMU -- 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 v5 3/6] ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC
From: Jonathan Richardson This defconfig is utilized so a customer or developer can understand what kernel drivers are utilized by the Cygnus SoC. It also enables debug configs which should be disabled if optimal performance is desired. Tested-by: Jonathan Richardson Reviewed-by: JD (Jiandong) Zheng Signed-off-by: Scott Branden --- arch/arm/configs/bcm_cygnus_defconfig | 243 + 1 file changed, 243 insertions(+) create mode 100644 arch/arm/configs/bcm_cygnus_defconfig diff --git a/arch/arm/configs/bcm_cygnus_defconfig b/arch/arm/configs/bcm_cygnus_defconfig new file mode 100644 index 000..c8d6158 --- /dev/null +++ b/arch/arm/configs/bcm_cygnus_defconfig @@ -0,0 +1,243 @@ +CONFIG_KERNEL_XZ=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_FHANDLE=y +CONFIG_IRQ_DOMAIN_DEBUG=y +CONFIG_NO_HZ_IDLE=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=19 +CONFIG_CGROUPS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_CGROUP_SCHED=y +CONFIG_BLK_CGROUP=y +CONFIG_NAMESPACES=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_EMBEDDED=y +CONFIG_PERF_EVENTS=y +# CONFIG_COMPAT_BRK is not set +CONFIG_JUMP_LABEL=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y +CONFIG_ARCH_BCM=y +CONFIG_ARCH_BCM_CYGNUS=y +CONFIG_ARM_THUMBEE=y +CONFIG_PCI=y +CONFIG_PCI_DEBUG=y +CONFIG_PREEMPT=y +CONFIG_AEABI=y +CONFIG_HIGHMEM=y +# CONFIG_COMPACTION is not set +# CONFIG_ATAGS is not set +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_ARM_APPENDED_DTB=y +CONFIG_CPU_IDLE=y +CONFIG_VFP=y +CONFIG_NEON=y +# CONFIG_SUSPEND is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_MROUTE=y +CONFIG_IP_MROUTE_MULTIPLE_TABLES=y +CONFIG_SYN_COOKIES=y +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_LRO is not set +# CONFIG_INET_DIAG is not set +CONFIG_TCP_CONG_ADVANCED=y +# CONFIG_TCP_CONG_BIC is not set +# CONFIG_TCP_CONG_WESTWOOD is not set +# CONFIG_TCP_CONG_HTCP is not set +CONFIG_IPV6=y +# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET6_XFRM_MODE_TUNNEL is not set +# CONFIG_INET6_XFRM_MODE_BEET is not set +# CONFIG_IPV6_SIT is not set +CONFIG_IPV6_MULTIPLE_TABLES=y +CONFIG_IPV6_SUBTREES=y +CONFIG_IPV6_MROUTE=y +CONFIG_NETFILTER=y +# CONFIG_BRIDGE_NETFILTER is not set +CONFIG_NF_CONNTRACK=y +# CONFIG_NF_CONNTRACK_PROCFS is not set +CONFIG_NF_CONNTRACK_FTP=y +CONFIG_NF_CONNTRACK_IPV4=y +CONFIG_IP_NF_IPTABLES=y +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +CONFIG_IP_NF_NAT=y +CONFIG_IP_NF_TARGET_MASQUERADE=y +CONFIG_IP_NF_TARGET_REDIRECT=y +CONFIG_IP_NF_MANGLE=y +CONFIG_IP_NF_RAW=y +CONFIG_NF_CONNTRACK_IPV6=y +CONFIG_IP6_NF_IPTABLES=y +CONFIG_IP6_NF_MATCH_AH=y +CONFIG_IP6_NF_MATCH_EUI64=y +CONFIG_IP6_NF_MATCH_FRAG=y +CONFIG_IP6_NF_MATCH_OPTS=y +CONFIG_IP6_NF_MATCH_IPV6HEADER=y +CONFIG_IP6_NF_MATCH_MH=y +CONFIG_IP6_NF_MATCH_RT=y +CONFIG_IP6_NF_FILTER=y +CONFIG_IP6_NF_TARGET_REJECT=y +CONFIG_IP6_NF_MANGLE=y +CONFIG_IP6_NF_RAW=y +CONFIG_BRIDGE=y +# CONFIG_BRIDGE_IGMP_SNOOPING is not set +CONFIG_VLAN_8021Q=y +CONFIG_NET_SCHED=y +CONFIG_NET_SCH_FQ_CODEL=y +CONFIG_CFG80211=y +# CONFIG_CFG80211_DEFAULT_PS is not set +CONFIG_CFG80211_WEXT=y +CONFIG_RFKILL=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_FIRMWARE_IN_KERNEL is not set +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_NAND=y +CONFIG_MTD_UBI=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR=y +CONFIG_NETDEVICES=y +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_PHYLIB=y +CONFIG_BROADCOM_PHY=y +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +# CONFIG_KEYBOARD_ATKBD is not set +# CONFIG_INPUT_MOUSE is not set +CONFIG_INPUT_TOUCHSCREEN=y +# CONFIG_SERIO is not set +# CONFIG_LEGACY_PTYS is not set +CONFIG_SERIAL_8250=y +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=2 +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +CONFIG_SERIAL_8250_DW=y +CONFIG_SERIAL_OF_PLATFORM=y +# CONFIG_HW_RANDOM is not set +CONFIG_I2C_CHARDEV=y +# CONFIG_I2C_HELPER_AUTO is not set +CONFIG_I2C_SMBUS=y +CONFIG_SPI=y +CONFIG_SPI_PL022=y
[PATCH v5 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC
From: Jonathan Richardson
Adds initial support for the Cygnus SoC based on Broadcom’s iProc series.
Move ARCH_BCM_5301x under the ARCH_BCM_IPROC architecture.
Reviewed-by: Ray Jui
Reviewed-by: Desmond Liu
Reviewed-by: JD (Jiandong) Zheng
Tested-by: Jonathan Richardson
Signed-off-by: Scott Branden
---
arch/arm/mach-bcm/Kconfig | 30 ++
arch/arm/mach-bcm/Makefile |3 +++
arch/arm/mach-bcm/bcm_cygnus.c | 26 ++
3 files changed, 59 insertions(+)
create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 2abad74..ecc544a 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -5,6 +5,36 @@ menuconfig ARCH_BCM
if ARCH_BCM
+menu "iProc SoC based Machine types"
+ config ARCH_BCM_IPROC
+ bool
+ select ARM_GIC
+ select CACHE_L2X0
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if SMP
+ select ARM_GLOBAL_TIMER
+
+ select CLKSRC_MMIO
+ select ARCH_REQUIRE_GPIOLIB
+ select ARM_AMBA
+ select PINCTRL
+ help
+ This enables support for systems based on Broadcom IPROC
architected SoCs.
+ The IPROC complex contains one or more ARM CPUs along with
common
+ core periperals. Application specific SoCs are created by
adding a
+ uArchitecture containing peripherals outside of the IPROC
complex.
+ Currently supported SoCs are Cygnus.
+
+ config ARCH_BCM_CYGNUS
+ bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
+ select ARCH_BCM_IPROC
+ help
+ Enable support for the Cygnus family,
+ which includes the following variants:
+ BCM11300, BCM11320, BCM11350, BCM11360,
+ BCM58300, BCM58302, BCM58303, BCM58305.
+endmenu
+
config ARCH_BCM_MOBILE
bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7
select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 300ae4b..34d45ba 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -10,6 +10,9 @@
# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
+# Cygnus
+obj-$(CONFIG_ARCH_BCM_CYGNUS) += bcm_cygnus.o
+
# BCM281XX
obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
diff --git a/arch/arm/mach-bcm/bcm_cygnus.c b/arch/arm/mach-bcm/bcm_cygnus.c
new file mode 100644
index 000..41b4933
--- /dev/null
+++ b/arch/arm/mach-bcm/bcm_cygnus.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright 2014 Broadcom Corporation. All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+
+static const char const *bcm_cygnus_dt_compat[] = {
+ "brcm,cygnus",
+ NULL,
+};
+
+DT_MACHINE_START(BCM_CYGNUS_DT, "Broadcom Cygnus SoC")
+ .l2c_aux_val= 0,
+ .l2c_aux_mask = ~0,
+ .dt_compat = bcm_cygnus_dt_compat,
+MACHINE_END
--
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 v5 2/6] dt-bindings: Document Broadcom Cygnus SoC and clocks
From: Jonathan Richardson
Reviewed-by: Arun Parameswaran
Tested-by: Jonathan Richardson
Reviewed-by: JD (Jiandong) Zheng
Reviewed-by: Ray Jui
Signed-off-by: Scott Branden
---
.../devicetree/bindings/arm/bcm/cygnus.txt | 31 ++
.../devicetree/bindings/clock/bcm-cygnus-clock.txt | 34
2 files changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/bcm/cygnus.txt
create mode 100644 Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
diff --git a/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
b/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
new file mode 100644
index 000..4c77169
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
@@ -0,0 +1,31 @@
+Broadcom Cygnus device tree bindings
+
+
+
+Boards with Cygnus SoCs shall have the following properties:
+
+Required root node property:
+
+BCM11300
+compatible = "brcm,bcm11300", "brcm,cygnus";
+
+BCM11320
+compatible = "brcm,bcm11320", "brcm,cygnus";
+
+BCM11350
+compatible = "brcm,bcm11350", "brcm,cygnus";
+
+BCM11360
+compatible = "brcm,bcm11360", "brcm,cygnus";
+
+BCM58300
+compatible = "brcm,bcm58300", "brcm,cygnus";
+
+BCM58302
+compatible = "brcm,bcm58302", "brcm,cygnus";
+
+BCM58303
+compatible = "brcm,bcm58303", "brcm,cygnus";
+
+BCM58305
+compatible = "brcm,bcm58305", "brcm,cygnus";
diff --git a/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
b/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
new file mode 100644
index 000..00d26ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
@@ -0,0 +1,34 @@
+Broadcom Cygnus Clocks
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Currently various "fixed" clocks are declared for peripheral drivers that use
+the common clock framework to reference their core clocks. Proper support of
+these clocks will be added later
+
+Device tree example:
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <1>;
+ clock-frequency = <2500>;
+ };
+
+ apb_clk: apb_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <10>;
+ };
+
+ periph_clk: periph_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5>;
+ };
+ };
--
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 v5 0/6] Add initial support for Broadcom Cygnus SoC
This patchset contains initial support for Broadcom's Cygnus SoC based on our iProc architecture. Initial support is minimal and includes just the mach platform code, clock driver, and a basic device tree configuration. Peripheral drivers will be submitted soon, as will device tree configurations for other Cygnus board variants. Changes from v4: - simple clock tree used. reworked clock driver will be submitted later - fixed MAINTAINERS patchset error - removed DEBUG_UART_8250 Kconfig.debug legacy support - made ARCH_BCM_IPROC a silent Kconfig option - removed multi_v7_defconfig as it is not needed at this time, can support in future patchset but does not seem optimal configs for our current usage. Changes from v3: - restart functionality removed. Will be added in a different patchset in drivers/power - removed NEON init sequence. Will be moved to bootloader - cleaned up Kconfigs for ARCH_BCM_CYGNUS by removing unnecessary selects - consolidated ARCH_BCM_IPROC with select from ARCH_BCM_CYGNUS and ARCH_BCM5301X - removed bcm911360_entphn binding - added documentation for SoCs currently supported in Cygnus family Changes from v2: - rebased to 3.17 kernel Changes from v1: - Address code review comments as per previous responses. - Copyright headers updated to remove Broadcom URL. - mach platform code still contains hard coded addresses. These address are the same for all Cygnus variants. Could you please provide guidance on where they should go if you would still like them changed. There does not seem to be a reason to change them to device tree as they do not change. Jonathan Richardson (3): ARM: cygnus: Initial support for Broadcom Cygnus SoC dt-bindings: Document Broadcom Cygnus SoC and clocks ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC Scott Branden (3): ARM: dts: Enable Broadcom Cygnus SoC MAINTAINERS: Entry for Cygnus/iproc arm architecture ARM: mach-bcm: Consolidate currently supported IPROC SoCs .../devicetree/bindings/arm/bcm/cygnus.txt | 31 +++ .../devicetree/bindings/clock/bcm-cygnus-clock.txt | 34 +++ MAINTAINERS| 15 ++ arch/arm/boot/dts/Makefile |4 + arch/arm/boot/dts/bcm-cygnus-clock.dtsi| 73 ++ arch/arm/boot/dts/bcm-cygnus.dtsi | 109 + arch/arm/boot/dts/bcm911360_entphn.dts | 22 ++ arch/arm/boot/dts/bcm911360k.dts | 22 ++ arch/arm/boot/dts/bcm958300k.dts | 22 ++ arch/arm/configs/bcm_cygnus_defconfig | 243 arch/arm/mach-bcm/Kconfig | 67 -- arch/arm/mach-bcm/Makefile |3 + arch/arm/mach-bcm/bcm_cygnus.c | 26 +++ 13 files changed, 650 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/cygnus.txt create mode 100644 Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt create mode 100644 arch/arm/boot/dts/bcm-cygnus-clock.dtsi create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts create mode 100644 arch/arm/boot/dts/bcm911360k.dts create mode 100644 arch/arm/boot/dts/bcm958300k.dts create mode 100644 arch/arm/configs/bcm_cygnus_defconfig create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c -- 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 v5 5/6] MAINTAINERS: Entry for Cygnus/iproc arm architecture
Acked-by: Jonathan Richardson Signed-off-by: Scott Branden --- MAINTAINERS | 15 +++ 1 file changed, 15 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ee1bc5b..794804a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2125,6 +2125,21 @@ L: linux-s...@vger.kernel.org S: Supported F: drivers/scsi/bnx2i/ +BROADCOM CYGNUS/IPROC ARM ARCHITECTURE +M: Ray Jui +M: Scott Branden +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: bcm-kernel-feedback-l...@broadcom.com +T: git git://git.github.com/brcm/linux.git +S: Maintained +F: Documentation/devicetree/bindings/arm/bcm/cygnus.txt +F: Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt +F: arch/arm/boot/dts/*cygnus* +F: arch/arm/boot/dts/bcm9113* +F: arch/arm/boot/dts/bcm9583* +F: arch/arm/configs/bcm_cygnus_defconfig +F: arch/arm/mach-bcm/bcm_cygnus.c + BROADCOM KONA GPIO DRIVER M: Ray Jui L: bcm-kernel-feedback-l...@broadcom.com -- 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 v5 4/6] ARM: dts: Enable Broadcom Cygnus SoC
DT files to enable cygnus consisting on reference designs
and cygnus core configuration.
Reviewed-by: Ray Jui
Reviewed-by: Arun Parameswaran
Tested-by: Jonathan Richardson
Reviewed-by: JD (Jiandong) Zheng
Signed-off-by: Scott Branden
---
arch/arm/boot/dts/Makefile |4 ++
arch/arm/boot/dts/bcm-cygnus-clock.dtsi | 73 +
arch/arm/boot/dts/bcm-cygnus.dtsi | 109 +++
arch/arm/boot/dts/bcm911360_entphn.dts | 22 +++
arch/arm/boot/dts/bcm911360k.dts| 22 +++
arch/arm/boot/dts/bcm958300k.dts| 22 +++
6 files changed, 252 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm-cygnus-clock.dtsi
create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts
create mode 100644 arch/arm/boot/dts/bcm911360k.dts
create mode 100644 arch/arm/boot/dts/bcm958300k.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7c80af9..a6b734a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -54,6 +54,10 @@ dtb-$(CONFIG_ARCH_AT91) += at91-sama5d4ek.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
+ bcm911360_entphn.dtb \
+ bcm911360k.dtb \
+ bcm958300k.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
dtb-$(CONFIG_ARCH_BCM_63XX) += bcm963138dvt.dtb
dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
diff --git a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
new file mode 100644
index 000..d06172b
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2014 Broadcom Corporation. All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <1>;
+ clock-frequency = <2500>;
+ };
+
+ apb_clk: apb_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <10>;
+ };
+
+ periph_clk: periph_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5>;
+ };
+
+ sdio_clk: lcpll_ch2 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2>;
+ };
+
+ axi81_clk: axi81_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+
+ keypad_clk: keypad_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <31806>;
+ };
+
+ adc_clk: adc_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1562500>;
+ };
+
+ pwm_clk: pwm_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100>;
+ };
+
+ lcd_clk: mipipll_ch1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+};
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
new file mode 100644
index 000..a377ab2
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2014 Broadcom Corporation. All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "brcm,cygnus";
+ model = "Broadcom Cygnus SoC";
+ interrupt-parent = <&gic>;
+
+ aliases
Re: get_maintainers.pl doesn't actually get the real MAINTAINERS?
On Tue, 2014-10-14 at 19:31 -0700, Scott Branden wrote: > On 14-10-14 07:26 PM, Joe Perches wrote: > > On Tue, 2014-10-14 at 19:18 -0700, Scott Branden wrote: > >> Hello, > >> > >> I try running scripts/get_maintainers.pl but it doesn't seem to get the > >> real maintainers properly. Please note this is run against the current > >> MAINTAINERS file. > >> > >> One Example: I would expect drivers/mmc/host/sdhci-bcm2835.c to be > >> maintained by Stephen Warren based on drivers/*/*bcm2835* below. > > > > get_maintainers doesn't use * as a depth wildcard > > > > */ matches a single top level directory level > > */*/ matches one level below the top directory level. > > > >>But > >> the get_maintainers.pl script does not seem to process the information > >> in such a way. So what needs to be corrected - the script or the syntax > >> used in the MAINTAINERS file? > >> > >> BROADCOM BCM2835 ARM ARCHICTURE > >> M: Stephen Warren > >> L: linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers) > >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git > >> S: Maintained > >> F: arch/arm/mach-bcm/board_bcm2835.c > >> F: arch/arm/boot/dts/bcm2835* > >> F: arch/arm/configs/bcm2835_defconfig > >> F: drivers/*/*bcm2835* > > > > F: drivers/*/*/*bmc2835* > Thanks for the explanation. So somebody should really do the following > to maintain any files no matter where they are located? > F:*/*bcm2835* > F:*/*/*bcm2835* > F:*/*/*/*bcm2835* > F:*/*/*/*/*bcm2835* > F:*/*/*/*/*/*bcm2835* > F:*/*/*/*/*/*/*bcm2835* > F:*/*/*/*/*/*/*/*bcm2835* > > Or, can a recursive option be added in the script? Hasn't been much of a need for that but knock yourself out if you think something like a ... might be useful. Look for function "file_match_pattern" if you want to extend it. There is a file name matching option "N:" that does something similar. Difference is that F: patterns matches do not use git history by default to find other people that have submitted patches, N: does. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 25/27] Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: Yijing Wang Date: Wed, 15 Oct 2014 11:07:13 +0800 > Use MSI chip framework instead of arch MSI functions to configure > MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework. > > Signed-off-by: Yijing Wang Acked-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/27] Use MSI chip framework to configure MSI/MSI-X in all platforms
Now there are a lot of weak arch functions in MSI code. Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm, that's a better solution than overriding lots of existing weak arch functionsin. This series use MSI chip framework to refactor MSI code across all platforms to eliminate weak arch functions. Then all MSI irqs will be managed in a unified framework. Because this series changed a lot of ARCH MSI code, so tests in the related platforms are warmly welcomed! And you may access it at: https://github.com/YijingWang/msi-chip-v3.git master v2->v3: 1. For patch "x86/xen/MSI: Eliminate...", introduce a new global flag "pci_msi_ignore_mask" to control the msi mask instead of replacing the irqchip->mask with nop function, the latter method has problem pointed out by Konrad Rzeszutek Wilk. 2. Save msi chip in arch pci sysdata instead of associating msi chip to pci bus. Because pci devices under same host share the same msi chip, so I think associate msi chip to pci host/pci sysdata is better than to bother every pci bus/devices. A better solution suggested by Liviu is to rip out pci_host_bridge from pci_create_root_bus(), then we can save some pci host common attributes like domain_nr, msi_chip, resources, into the generic pci_host_bridge. Because this changes to pci host bridge is also a large series, so I think we should go step by step, I will try to post it in another series later. 4. Clean up arm pcibios_add_bus() and pcibios_remove_bus() which were used to associate msi chip to pci bus. v1->v2: Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.." and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas. RFC->v1: Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead of #ifdef to fix MSI bug in xen running in x86. Rename arch_get_match_msi_chip() to arch_find_msi_chip(). Drop use struct device as the msi_chip argument, we will do that later in another patchset. Yijing Wang (27): MSI: Remove the redundant irq_set_chip_data() x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq() s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq() arm/MSI: Save MSI chip in pci_sys_data PCI: tegra: Save msi chip in pci_sys_data PCI: designware: Save msi chip in pci_sys_data PCI: rcar: Save msi chip in pci_sys_data PCI: mvebu: Save msi chip in pci_sys_data arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus() PCI/MSI: Remove useless bus->msi assignment PCI/MSI: Refactor struct msi_chip to make it become more common x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq x86/MSI: Remove unused MSI weak arch functions Mips/MSI: Save msi chip in pci sysdata MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq MIPS/Xlp: Remove the dead function destroy_irq() to fix build error MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq PCI/MSI: Clean up unused MSI arch functions arch/arm/include/asm/mach/pci.h | 10 +- arch/arm/include/asm/pci.h |9 ++ arch/arm/kernel/bios32.c| 19 +--- arch/arm/mach-iop13xx/include/mach/pci.h|4 + arch/arm/mach-iop13xx/iq81340mc.c |3 + arch/arm/mach-iop13xx/iq81340sc.c |5 +- arch/arm/mach-iop13xx/msi.c | 11 ++- arch/ia64/include/asm/pci.h | 10 ++ arch/ia64/kernel/msi_ia64.c | 14 ++- arch/ia64/pci/pci.c |1 + arch/mips/include/asm/netlogic/xlp-hal/pcibus.h |1 + arch/mips/include/asm/octeon/pci-octeon.h |4 + arch/mips/include/asm/pci.h | 14 +++ arch/mips/pci/msi-octeon.c | 31 +++--- arch/mips/pci/msi-xlp.c | 15 ++- arch/mips/pci/pci-octeon.c |3 + arch/mips/pci/pci-xlp.c |3 + arch/mips/pci/pci-xlr.c | 17 +++- arch/powerpc/include/asm/pci-bridge.h | 15 +++ arch/powerpc/kernel/msi.c | 12 ++- arch/powerpc/kernel/pci-common.c|3 + arch/s390/include/asm/pci.h |9 ++ arch/s390/pci/pci.c | 16 ++- arch/sparc/kernel/pci.c |
Re: rcu_preempt detected stalls.
On 10/13/2014 01:35 PM, Dave Jones wrote: > oday in "rcu stall while fuzzing" news: > > INFO: rcu_preempt detected stalls on CPUs/tasks: > Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646 > Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646 > (detected by 0, t=6502 jiffies, g=75434, c=75433, q=0) I've complained about RCU stalls couple days ago (in a different context) on -next. I guess whatever causing them made it into Linus's tree? https://lkml.org/lkml/2014/10/11/64 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 12/27] x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/x86/include/asm/pci.h | 13 +
arch/x86/kernel/apic/io_apic.c | 19 +++
arch/x86/pci/acpi.c|1 +
arch/x86/pci/common.c |3 +++
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 0892ea0..f41b58a 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -20,6 +20,9 @@ struct pci_sysdata {
#ifdef CONFIG_X86_64
void*iommu; /* IOMMU private data */
#endif
+#ifdef CONFIG_PCI_MSI
+ struct msi_chip *msi_chip;
+#endif
};
extern int pci_routeirq;
@@ -41,6 +44,15 @@ static inline int pci_proc_domain(struct pci_bus *bus)
}
#endif
+#ifdef CONFIG_PCI_MSI
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct pci_sysdata *sd = bus->sysdata;
+
+ return sd->msi_chip;
+}
+#endif
+
/* Can be used to override the logic in pci_scan_bus for skipping
already-configured bus numbers - to be used for buggy BIOSes
or architectures with incomplete PCI setup by the loader */
@@ -101,6 +113,7 @@ void native_teardown_msi_irq(unsigned int irq);
void native_restore_msi_irqs(struct pci_dev *dev);
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
unsigned int irq_base, unsigned int irq_offset);
+extern struct msi_chip *x86_msi_chip;
#else
#define native_setup_msi_irqs NULL
#define native_teardown_msi_irqNULL
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 29290f5..ec79b38 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3227,11 +3227,30 @@ int native_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
return 0;
}
+static int __native_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev, int nvec, int type)
+{
+ return native_setup_msi_irqs(dev, nvec, type);
+}
+
void native_teardown_msi_irq(unsigned int irq)
{
irq_free_hwirq(irq);
}
+static void __native_teardown_msi_irq(struct msi_chip *chip,
+ unsigned int irq)
+{
+ native_teardown_msi_irq(irq);
+}
+
+static struct msi_chip native_msi_chip = {
+ .setup_irqs = __native_setup_msi_irqs,
+ .teardown_irq = __native_teardown_msi_irq,
+};
+
+struct msi_chip *x86_msi_chip = &native_msi_chip;
+
#ifdef CONFIG_DMAR_TABLE
static int
dmar_msi_set_affinity(struct irq_data *data, const struct cpumask *mask,
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..6341d6d 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -508,6 +508,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root
*root)
sd = &info->sd;
sd->domain = domain;
+ sd->msi_chip = x86_msi_chip;
sd->node = node;
sd->companion = device;
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 7b20bcc..0b2319a 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -468,6 +468,9 @@ void pcibios_scan_root(int busnum)
return;
}
sd->node = x86_pci_root_bus_node(busnum);
+#ifdef CONFIG_PCI_MSI
+ sd->msi_chip = x86_msi_chip;
+#endif
x86_pci_root_bus_resources(busnum, &resources);
printk(KERN_DEBUG "PCI: Probing PCI hardware (bus %02x)\n", busnum);
bus = pci_scan_root_bus(NULL, busnum, &pci_root_ops, sd, &resources);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 04/27] arm/MSI: Save MSI chip in pci_sys_data
Saving msi chip in pci_sys_data can make pci bus and
devices don't need to know msi chip detail, it also
make pci enumeration code be decoupled from msi chip.
In fact, all pci devices under the same pci hostbridge
share same msi chip. So msi chip should be seen as one
of resources or attributes to be initialized in pci host
bridge driver. Currently, pci hostbridge drivers create
pci_host_bridge in pci_create_root_bus(), and pass arch
specific pci sysdata to core pci scan functions. So pci
arch sysdata is good place to save msi chip.
Signed-off-by: Yijing Wang
---
arch/arm/include/asm/mach/pci.h |6 ++
arch/arm/include/asm/pci.h |9 +
arch/arm/kernel/bios32.c|3 +++
drivers/pci/msi.c |6 ++
include/linux/pci.h |9 +
5 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 7fc4278..59b0d87 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -22,6 +22,9 @@ struct hw_pci {
#ifdef CONFIG_PCI_DOMAINS
int domain;
#endif
+#ifdef CONFIG_PCI_MSI
+ struct msi_chip *msi_chip;
+#endif
struct pci_ops *ops;
int nr_controllers;
void**private_data;
@@ -47,6 +50,9 @@ struct pci_sys_data {
#ifdef CONFIG_PCI_DOMAINS
int domain;
#endif
+#ifdef CONFIG_PCI_MSI
+ struct msi_chip *msi_chip;
+#endif
struct list_head node;
int busnr; /* primary bus number
*/
u64 mem_offset; /* bus->cpu memory mapping offset
*/
diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
index 7e95d85..b562c09 100644
--- a/arch/arm/include/asm/pci.h
+++ b/arch/arm/include/asm/pci.h
@@ -31,6 +31,15 @@ static inline int pci_proc_domain(struct pci_bus *bus)
}
#endif /* CONFIG_PCI_DOMAINS */
+#ifdef CONFIG_PCI_MSI
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct pci_sys_data *root = bus->sysdata;
+
+ return root->msi_chip;
+}
+#endif
+
/*
* The PCI address space does equal the physical memory address space.
* The networking and block device layers use this boolean for bounce
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 17a26c1..a19038d 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -471,6 +471,9 @@ static void pcibios_init_hw(struct device *parent, struct
hw_pci *hw,
#ifdef CONFIG_PCI_DOMAINS
sys->domain = hw->domain;
#endif
+#ifdef CONFIG_PCI_MSI
+ sys->msi_chip = hw->msi_chip;
+#endif
sys->busnr = busnr;
sys->swizzle = hw->swizzle;
sys->map_irq = hw->map_irq;
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 22e413c..f11108c 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -35,6 +35,9 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
msi_desc *desc)
struct msi_chip *chip = dev->bus->msi;
int err;
+ if (!chip)
+ chip = pci_msi_chip(dev->bus);
+
if (!chip || !chip->setup_irq)
return -EINVAL;
@@ -50,6 +53,9 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
struct msi_desc *entry = irq_get_msi_desc(irq);
struct msi_chip *chip = entry->dev->bus->msi;
+ if (!chip)
+ chip = pci_msi_chip(entry->dev->bus);
+
if (!chip || !chip->teardown_irq)
return;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9cd2721..7a48b40 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1433,6 +1433,15 @@ static inline int pci_get_new_domain_nr(void) { return
-ENOSYS; }
#include
+/* Just avoid compile error, will be clean up later */
+#ifdef CONFIG_PCI_MSI
+
+#ifndef pci_msi_chip
+#define pci_msi_chip(bus) NULL
+#endif
+
+#endif
+
/* these helpers provide future and backwards compatibility
* for accessing popular PCI BAR info */
#define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
--
1.7.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] smaps should deal with huge zero page exactly same as normal zero page
On Tue, Oct 14, 2014 at 02:57:30PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 10, 2014 at 09:21:08PM +0800, Fengwei Yin wrote:
> > On Thu, Oct 09, 2014 at 09:36:30AM -0700, Dave Hansen wrote:
> > > On 10/09/2014 02:19 AM, Fengwei Yin wrote:
> > > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > > > index 80ca4fb..8550b27 100644
> > > > --- a/fs/proc/task_mmu.c
> > > > +++ b/fs/proc/task_mmu.c
> > > > @@ -476,7 +476,7 @@ static void smaps_pte_entry(pte_t ptent, unsigned
> > > > long addr,
> > > > mss->nonlinear += ptent_size;
> > > > }
> > > >
> > > > - if (!page)
> > > > + if (!page || is_huge_zero_page(page))
> > > > return;
> > >
> > > This really seems like a bit of a hack. A normal (small) zero page
> > > won't make it to this point because of the vm_normal_page() check in
> > > smaps_pte_entry() which hits the _PAGE_SPECIAL bit in the pte.
> > >
> > > Is there a reason we can't set _PAGE_SPECIAL on the huge_zero_page ptes?
> > > If we did that, we wouldn't need a special case here.
> > >
> > > If we can't do that for some reason, can we at least teach
> > > vm_normal_page() about the huge_zero_page in some other way?
> > I suppose _PAGE_SPECIAL can't work. Two reasons:
> > 1. Not all arch have HAVE_PTE_SPECIAL set. So always need another way to
> >handle the arch which has no PTE_SPECIAL.
> > 2. _PAGE_SPECIAL is just for PTE now. If want to add it for huge page,
> >we need to introduce pmd_mkspecial() thing which I don't think it's
> >worth to do now (unless you want it. :)).
> >
> > Yes. We could move the check to vm_normal_page(). But it still needs
> > export functions from huge_memory.c.
> >
> > Please check the new patch.
> >
> > >
> > > > if (PageAnon(page))
> > > > @@ -516,7 +516,8 @@ static int smaps_pte_range(pmd_t *pmd, unsigned
> > > > long addr, unsigned long end,
> > > > if (pmd_trans_huge_lock(pmd, vma, &ptl) == 1) {
> > > > smaps_pte_entry(*(pte_t *)pmd, addr, HPAGE_PMD_SIZE,
> > > > walk);
> > > > spin_unlock(ptl);
> > > > - mss->anonymous_thp += HPAGE_PMD_SIZE;
> > > > + if (!is_huge_zero_pmd(*pmd))
> > > > + mss->anonymous_thp += HPAGE_PMD_SIZE;
> > > > return 0;
> > > > }
> > >
> > > How about we just move this hunk in to smaps_pte_entry()? Something
> > > along these lines:
> > >
> > > ...
> > > if (PageAnon(page)) {
> > > mss->anonymous += ptent_size;
> > > + if (PageTransHuge(page))
> > > + mss->anonymous_thp += ptent_size;
> > > }
> > Done.
> > >
> > > If we do that, plus teaching vm_normal_page() about huge_zero_pages, it
> > > will help keep the hacks and the extra code due to huge pages to a
> > > miniumum.
> > >
> > > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > > > index 63579cb..758f569 100644
> > > > --- a/include/linux/huge_mm.h
> > > > +++ b/include/linux/huge_mm.h
> > > > @@ -34,6 +34,10 @@ extern int change_huge_pmd(struct vm_area_struct
> > > > *vma, pmd_t *pmd,
> > > > unsigned long addr, pgprot_t newprot,
> > > > int prot_numa);
> > > >
> > > > +extern bool is_huge_zero_page(struct page *page);
> > > > +
> > > > +extern bool is_huge_zero_pmd(pmd_t pmd);
> > > > +
> > > > enum transparent_hugepage_flag {
> > > > TRANSPARENT_HUGEPAGE_FLAG,
> > > > TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
> > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > > index d9a21d06..bedc3ae 100644
> > > > --- a/mm/huge_memory.c
> > > > +++ b/mm/huge_memory.c
> > > > @@ -173,12 +173,12 @@ static int start_khugepaged(void)
> > > > static atomic_t huge_zero_refcount;
> > > > static struct page *huge_zero_page __read_mostly;
> > > >
> > > > -static inline bool is_huge_zero_page(struct page *page)
> > > > +bool is_huge_zero_page(struct page *page)
> > > > {
> > > > return ACCESS_ONCE(huge_zero_page) == page;
> > > > }
> > > >
> > > > -static inline bool is_huge_zero_pmd(pmd_t pmd)
> > > > +bool is_huge_zero_pmd(pmd_t pmd)
> > > > {
> > > > return is_huge_zero_page(pmd_page(pmd));
> > > > }
> > >
> > > ^^^ And all these exports.
> >
> > A new function is_huge_zero_pfn() is added to mm/huge_memory.c
> > and exported.
> >
> > Thanks.
>
> > From 4e7bdd5bc22874175982ab50303eab32843c753c Mon Sep 17 00:00:00 2001
> > From: Fengwei Yin
> > Date: Thu, 9 Oct 2014 22:20:58 +0800
> > Subject: [PATCH] smaps should deal with huge zero page exactly same as
> > normal
> > zero page.
> >
>
> Description?
>
> > Signed-off-by: Fengwei Yin
> > ---
> > fs/proc/task_mmu.c | 6 --
> > include/linux/huge_mm.h | 2 ++
> > mm/huge_memory.c| 5 +
> > mm/memory.c | 4
> > 4 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
[PATCH v3 02/27] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
introduced two __weak arch functions arch_msix_mask_irq() and
arch_msi_mask_irq() to work around a bug when running xen in x86.
These two functions made msi code more complex. This patch reverts
the commit and introduces a global flag to control msi mask action to
avoid the bug. The patch is also preparation for using MSI chip framework
instead of weak arch MSI functions in all platforms. Keep default_msi_mask_irq()
and default_msix_mask_irq() in linux/msi.h to make s390 MSI code compile
happy, they will be removed in the later patch.
Signed-off-by: Yijing Wang
CC: David Vrabel
CC: Konrad Rzeszutek Wilk
---
Hi David and Konrad,
I dropped the Acked-by and tested-by, because this version has a
lot changes compared to last. So, I guess you may want to check it again.
---
arch/x86/include/asm/x86_init.h |3 ---
arch/x86/kernel/x86_init.c | 10 --
arch/x86/pci/xen.c | 14 ++
drivers/pci/msi.c | 29 -
include/linux/msi.h |8 ++--
5 files changed, 20 insertions(+), 44 deletions(-)
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index e45e4da..f58a9c7 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -172,7 +172,6 @@ struct x86_platform_ops {
struct pci_dev;
struct msi_msg;
-struct msi_desc;
struct x86_msi_ops {
int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
@@ -183,8 +182,6 @@ struct x86_msi_ops {
void (*teardown_msi_irqs)(struct pci_dev *dev);
void (*restore_msi_irqs)(struct pci_dev *dev);
int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
- u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
- u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
};
struct IO_APIC_route_entry;
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index e48b674..234b072 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -116,8 +116,6 @@ struct x86_msi_ops x86_msi = {
.teardown_msi_irqs = default_teardown_msi_irqs,
.restore_msi_irqs = default_restore_msi_irqs,
.setup_hpet_msi = default_setup_hpet_msi,
- .msi_mask_irq = default_msi_mask_irq,
- .msix_mask_irq = default_msix_mask_irq,
};
/* MSI arch specific hooks */
@@ -140,14 +138,6 @@ void arch_restore_msi_irqs(struct pci_dev *dev)
{
x86_msi.restore_msi_irqs(dev);
}
-u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
-{
- return x86_msi.msi_mask_irq(desc, mask, flag);
-}
-u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
-{
- return x86_msi.msix_mask_irq(desc, flag);
-}
#endif
struct x86_io_apic_ops x86_io_apic_ops = {
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4..e5b8b78 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -394,14 +394,6 @@ static void xen_teardown_msi_irq(unsigned int irq)
{
xen_destroy_irq(irq);
}
-static u32 xen_nop_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
-{
- return 0;
-}
-static u32 xen_nop_msix_mask_irq(struct msi_desc *desc, u32 flag)
-{
- return 0;
-}
#endif
int __init pci_xen_init(void)
@@ -425,8 +417,7 @@ int __init pci_xen_init(void)
x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
- x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
- x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
+ pci_msi_ignore_mask = 1;
#endif
return 0;
}
@@ -506,8 +497,7 @@ int __init pci_xen_initial_domain(void)
x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
- x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
- x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
+ pci_msi_ignore_mask = 1;
#endif
xen_setup_acpi_sci();
__acpi_register_gsi = acpi_register_gsi_xen;
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ecb92a5..22e413c 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -23,6 +23,7 @@
#include "pci.h"
static int pci_msi_enable = 1;
+int pci_msi_ignore_mask;
#define msix_table_size(flags) ((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
@@ -162,11 +163,11 @@ static inline __attribute_const__ u32 msi_mask(unsigned x)
* reliably as devices without an INTx disable bit will then generate a
* level IRQ which will never be cleared.
*/
-u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
+u32 __msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
{
u32 mask_bits = desc->masked;
- if (!desc->msi_attrib.maskbit)
+ if (pci_msi_ignore_mask || !desc-
[PATCH v3 13/27] x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
Acked-by: David Vrabel
CC: Konrad Rzeszutek Wilk
---
arch/x86/pci/xen.c | 58 +++-
1 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index e5b8b78..75067ca 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -157,7 +157,8 @@ static int acpi_register_gsi_xen(struct device *dev, u32
gsi,
struct xen_pci_frontend_ops *xen_pci_frontend;
EXPORT_SYMBOL_GPL(xen_pci_frontend);
-static int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+static int xen_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev, int nvec, int type)
{
int irq, ret, i;
struct msi_desc *msidesc;
@@ -219,7 +220,8 @@ static void xen_msi_compose_msg(struct pci_dev *pdev,
unsigned int pirq,
msg->data = XEN_PIRQ_MSI_DATA;
}
-static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+static int xen_hvm_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev, int nvec, int type)
{
int irq, pirq;
struct msi_desc *msidesc;
@@ -267,7 +269,8 @@ error:
#ifdef CONFIG_XEN_DOM0
static bool __read_mostly pci_seg_supported = true;
-static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+static int xen_initdom_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev, int nvec, int type)
{
int ret = 0;
struct msi_desc *msidesc;
@@ -349,7 +352,8 @@ out:
return ret;
}
-static void xen_initdom_restore_msi_irqs(struct pci_dev *dev)
+static void xen_initdom_restore_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev)
{
int ret = 0;
@@ -376,7 +380,13 @@ static void xen_initdom_restore_msi_irqs(struct pci_dev
*dev)
}
#endif
-static void xen_teardown_msi_irqs(struct pci_dev *dev)
+static void xen_teardown_msi_irq(struct msi_chip *chip, unsigned int irq)
+{
+ xen_destroy_irq(irq);
+}
+
+static void xen_teardown_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev)
{
struct msi_desc *msidesc;
@@ -386,14 +396,22 @@ static void xen_teardown_msi_irqs(struct pci_dev *dev)
else
xen_pci_frontend_disable_msi(dev);
- /* Free the IRQ's and the msidesc using the generic code. */
- default_teardown_msi_irqs(dev);
-}
+ list_for_each_entry(msidesc, &dev->msi_list, list) {
+ int i, nvec;
+ if (msidesc->irq == 0)
+ continue;
+ if (msidesc->nvec_used)
+ nvec = msidesc->nvec_used;
+ else
+ nvec = 1 << msidesc->msi_attrib.multiple;
+ for (i = 0; i < nvec; i++)
+ xen_teardown_msi_irq(chip, msidesc->irq + i);
+ }
-static void xen_teardown_msi_irq(unsigned int irq)
-{
- xen_destroy_irq(irq);
}
+
+struct msi_chip xen_msi_chip;
+
#endif
int __init pci_xen_init(void)
@@ -414,9 +432,9 @@ int __init pci_xen_init(void)
#endif
#ifdef CONFIG_PCI_MSI
- x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
- x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
- x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
+ xen_msi_chip.setup_irqs = xen_setup_msi_irqs;
+ xen_msi_chip.teardown_irqs = xen_teardown_msi_irqs;
+ x86_msi_chip = &xen_msi_chip;
pci_msi_ignore_mask = 1;
#endif
return 0;
@@ -436,8 +454,9 @@ int __init pci_xen_hvm_init(void)
#endif
#ifdef CONFIG_PCI_MSI
- x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
- x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
+ xen_msi_chip.setup_irqs = xen_hvm_setup_msi_irqs;
+ xen_msi_chip.teardown_irq = xen_teardown_msi_irq;
+ x86_msi_chip = &xen_msi_chip;
#endif
return 0;
}
@@ -494,9 +513,10 @@ int __init pci_xen_initial_domain(void)
int irq;
#ifdef CONFIG_PCI_MSI
- x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
- x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
- x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
+ xen_msi_chip.setup_irqs = xen_initdom_setup_msi_irqs;
+ xen_msi_chip.teardown_irq = xen_teardown_msi_irq;
+ xen_msi_chip.restore_irqs = xen_initdom_restore_msi_irqs;
+ x86_msi_chip = &xen_msi_chip;
pci_msi_ignore_mask = 1;
#endif
xen_setup_acpi_sci();
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 11/27] PCI/MSI: Refactor struct msi_chip to make it become more common
Now there are a lot of __weak arch functions in MSI code.
These functions make MSI driver complex. Thierry introduced
MSI chip framework to configure MSI/MSI-X irq in arm. Use
MSI chip framework to refactor all other platform MSI
code to eliminate weak arch MSI functions. This patch add
.restore_irqs(), .teardown_irqs() and .setup_irqs() to make it
become more common.
Signed-off-by: Yijing Wang
Reviewed-by: Lucas Stach
---
drivers/pci/msi.c | 15 +++
include/linux/msi.h |4
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 56e54ad..5cbd774 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -61,6 +61,11 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
{
struct msi_desc *entry;
int ret;
+ struct msi_chip *chip;
+
+ chip = pci_msi_chip(dev->bus);
+ if (chip && chip->setup_irqs)
+ return chip->setup_irqs(chip, dev, nvec, type);
/*
* If an architecture wants to support multiple MSI, it needs to
@@ -103,6 +108,11 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
{
+ struct msi_chip *chip = pci_msi_chip(dev->bus);
+
+ if (chip && chip->teardown_irqs)
+ return chip->teardown_irqs(chip, dev);
+
return default_teardown_msi_irqs(dev);
}
@@ -126,6 +136,11 @@ static void default_restore_msi_irq(struct pci_dev *dev,
int irq)
void __weak arch_restore_msi_irqs(struct pci_dev *dev)
{
+ struct msi_chip *chip = pci_msi_chip(dev->bus);
+
+ if (chip && chip->restore_irqs)
+ return chip->restore_irqs(chip, dev);
+
return default_restore_msi_irqs(dev);
}
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 175aa21..eb5ae36 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -74,7 +74,11 @@ struct msi_chip {
int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
struct msi_desc *desc);
+ int (*setup_irqs)(struct msi_chip *chip, struct pci_dev *dev,
+ int nvec, int type);
void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
+ void (*teardown_irqs)(struct msi_chip *chip, struct pci_dev *dev);
+ void (*restore_irqs)(struct msi_chip *chip, struct pci_dev *dev);
};
#endif /* LINUX_MSI_H */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 10/27] PCI/MSI: Remove useless bus->msi assignment
Now msi chip is saved in pci_sys_data in arm, we could clean the bus->msi assignment in pci core. Signed-off-by: Yijing Wang CC: Thierry Reding CC: Thomas Petazzoni --- drivers/pci/probe.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index efa48dc..98bf4c3 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -682,7 +682,6 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent, child->parent = parent; child->ops = parent->ops; - child->msi = parent->msi; child->sysdata = parent->sysdata; child->bus_flags = parent->bus_flags; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 16/27] Mips/MSI: Save msi chip in pci sysdata
Save msi chip in pci sysdata, add arch pci_find_msi_chip()
to extract out msi chip.
Signed-off-by: Yijing Wang
---
arch/mips/include/asm/pci.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index 974b0e3..287661b 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -43,6 +43,9 @@ struct pci_controller {
int iommu;
+#ifdef CONFIG_PCI_MSI
+ struct msi_chip *msi_chip;
+#endif
/* Optional access methods for reading/writing the bus number
of the PCI controller */
int (*get_busno)(void);
@@ -54,6 +57,17 @@ struct pci_controller {
*/
extern void register_pci_controller(struct pci_controller *hose);
+#ifdef CONFIG_PCI_MSI
+
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct pci_controller *control = (struct pci_controller *)bus->sysdata;
+
+ return control->msi_chip;
+}
+
+#endif
+
/*
* board supplied pci irq fixup routine
*/
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 03/27] s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
Now only s390/MSI use default_msi_mask_irq() and
default_msix_mask_irq(), replace them with the common
msi mask irq functions __msi_mask_irq() and __msix_mask_irq().
Remove default_msi_mask_irq() and default_msix_mask_irq().
Signed-off-by: Yijing Wang
---
arch/s390/pci/pci.c |4 ++--
include/linux/msi.h |2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 2fa7b14..552b990 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -448,9 +448,9 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev)
/* Release MSI interrupts */
list_for_each_entry(msi, &pdev->msi_list, list) {
if (msi->msi_attrib.is_msix)
- default_msix_mask_irq(msi, 1);
+ __msix_mask_irq(msi, 1);
else
- default_msi_mask_irq(msi, 1, 1);
+ __msi_mask_irq(msi, 1, 1);
irq_set_msi_desc(msi->irq, NULL);
irq_free_desc(msi->irq);
msi->msg.address_lo = 0;
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 9ac1e3b..175aa21 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -65,8 +65,6 @@ void arch_restore_msi_irqs(struct pci_dev *dev);
void default_teardown_msi_irqs(struct pci_dev *dev);
void default_restore_msi_irqs(struct pci_dev *dev);
-#define default_msi_mask_irq __msi_mask_irq
-#define default_msix_mask_irq __msix_mask_irq
struct msi_chip {
struct module *owner;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 15/27] x86/MSI: Remove unused MSI weak arch functions
Now we can clean up MSI weak arch functions in x86.
Signed-off-by: Yijing Wang
---
arch/x86/include/asm/pci.h |5 +
arch/x86/include/asm/x86_init.h |4
arch/x86/kernel/apic/io_apic.c | 21 +
arch/x86/kernel/x86_init.c | 24
4 files changed, 6 insertions(+), 48 deletions(-)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index f41b58a..3a5cf19 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -108,14 +108,11 @@ extern void pci_iommu_alloc(void);
#ifdef CONFIG_PCI_MSI
/* implemented in arch/x86/kernel/apic/io_apic. */
struct msi_desc;
-int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
-void native_teardown_msi_irq(unsigned int irq);
-void native_restore_msi_irqs(struct pci_dev *dev);
+void native_teardown_msi_irq(struct msi_chip *chip, unsigned int irq);
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
unsigned int irq_base, unsigned int irq_offset);
extern struct msi_chip *x86_msi_chip;
#else
-#define native_setup_msi_irqs NULL
#define native_teardown_msi_irqNULL
#endif
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index f58a9c7..2514f67 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -174,13 +174,9 @@ struct pci_dev;
struct msi_msg;
struct x86_msi_ops {
- int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
void (*compose_msi_msg)(struct pci_dev *dev, unsigned int irq,
unsigned int dest, struct msi_msg *msg,
u8 hpet_id);
- void (*teardown_msi_irq)(unsigned int irq);
- void (*teardown_msi_irqs)(struct pci_dev *dev);
- void (*restore_msi_irqs)(struct pci_dev *dev);
int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
};
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index ec79b38..11d353f 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3200,7 +3200,8 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc
*msidesc,
return 0;
}
-int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+static int native_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *msidesc;
unsigned int irq;
@@ -3227,26 +3228,14 @@ int native_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
return 0;
}
-static int __native_setup_msi_irqs(struct msi_chip *chip,
- struct pci_dev *dev, int nvec, int type)
-{
- return native_setup_msi_irqs(dev, nvec, type);
-}
-
-void native_teardown_msi_irq(unsigned int irq)
+void native_teardown_msi_irq(struct msi_chip *chip, unsigned int irq)
{
irq_free_hwirq(irq);
}
-static void __native_teardown_msi_irq(struct msi_chip *chip,
- unsigned int irq)
-{
- native_teardown_msi_irq(irq);
-}
-
static struct msi_chip native_msi_chip = {
- .setup_irqs = __native_setup_msi_irqs,
- .teardown_irq = __native_teardown_msi_irq,
+ .setup_irqs = native_setup_msi_irqs,
+ .teardown_irq = native_teardown_msi_irq,
};
struct msi_chip *x86_msi_chip = &native_msi_chip;
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 234b072..cc32568 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -110,34 +110,10 @@ EXPORT_SYMBOL_GPL(x86_platform);
#if defined(CONFIG_PCI_MSI)
struct x86_msi_ops x86_msi = {
- .setup_msi_irqs = native_setup_msi_irqs,
.compose_msi_msg= native_compose_msi_msg,
- .teardown_msi_irq = native_teardown_msi_irq,
- .teardown_msi_irqs = default_teardown_msi_irqs,
- .restore_msi_irqs = default_restore_msi_irqs,
.setup_hpet_msi = default_setup_hpet_msi,
};
-/* MSI arch specific hooks */
-int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
- return x86_msi.setup_msi_irqs(dev, nvec, type);
-}
-
-void arch_teardown_msi_irqs(struct pci_dev *dev)
-{
- x86_msi.teardown_msi_irqs(dev);
-}
-
-void arch_teardown_msi_irq(unsigned int irq)
-{
- x86_msi.teardown_msi_irq(irq);
-}
-
-void arch_restore_msi_irqs(struct pci_dev *dev)
-{
- x86_msi.restore_msi_irqs(dev);
-}
#endif
struct x86_io_apic_ops x86_io_apic_ops = {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 09/27] arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus()
MSI chip will be saved in pci_sys_data, now we can
clean up pcibios_add_bus() and pcibios_remove_bus()
in arm, and use pci_find_msi_chip() to get msi chip
in core MSI code.
Signed-off-by: Yijing Wang
---
arch/arm/include/asm/mach/pci.h |4
arch/arm/kernel/bios32.c| 16
drivers/pci/msi.c | 11 +++
3 files changed, 3 insertions(+), 28 deletions(-)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 59b0d87..230b2c9 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -39,8 +39,6 @@ struct hw_pci {
resource_size_t start,
resource_size_t size,
resource_size_t align);
- void(*add_bus)(struct pci_bus *bus);
- void(*remove_bus)(struct pci_bus *bus);
};
/*
@@ -71,8 +69,6 @@ struct pci_sys_data {
resource_size_t start,
resource_size_t size,
resource_size_t align);
- void(*add_bus)(struct pci_bus *bus);
- void(*remove_bus)(struct pci_bus *bus);
void*private_data; /* platform controller private data
*/
};
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a19038d..b1b872e 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -360,20 +360,6 @@ void pcibios_fixup_bus(struct pci_bus *bus)
}
EXPORT_SYMBOL(pcibios_fixup_bus);
-void pcibios_add_bus(struct pci_bus *bus)
-{
- struct pci_sys_data *sys = bus->sysdata;
- if (sys->add_bus)
- sys->add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
- struct pci_sys_data *sys = bus->sysdata;
- if (sys->remove_bus)
- sys->remove_bus(bus);
-}
-
/*
* Swizzle the device pin each time we cross a bridge. If a platform does
* not provide a swizzle function, we perform the standard PCI swizzling.
@@ -478,8 +464,6 @@ static void pcibios_init_hw(struct device *parent, struct
hw_pci *hw,
sys->swizzle = hw->swizzle;
sys->map_irq = hw->map_irq;
sys->align_resource = hw->align_resource;
- sys->add_bus = hw->add_bus;
- sys->remove_bus = hw->remove_bus;
INIT_LIST_HEAD(&sys->resources);
if (hw->private_data)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index f11108c..56e54ad 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -32,12 +32,10 @@ int pci_msi_ignore_mask;
int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
- struct msi_chip *chip = dev->bus->msi;
+ struct msi_chip *chip;
int err;
- if (!chip)
- chip = pci_msi_chip(dev->bus);
-
+ chip = pci_msi_chip(dev->bus);
if (!chip || !chip->setup_irq)
return -EINVAL;
@@ -51,10 +49,7 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
msi_desc *desc)
void __weak arch_teardown_msi_irq(unsigned int irq)
{
struct msi_desc *entry = irq_get_msi_desc(irq);
- struct msi_chip *chip = entry->dev->bus->msi;
-
- if (!chip)
- chip = pci_msi_chip(entry->dev->bus);
+ struct msi_chip *chip = pci_msi_chip(entry->dev->bus);
if (!chip || !chip->teardown_irq)
return;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 07/27] PCI: rcar: Save msi chip in pci_sys_data
Save msi chip in pci_sys_data instead of assign
msi chip to every pci bus in .add_bus().
Signed-off-by: Yijing Wang
---
drivers/pci/host/pcie-rcar.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 61158e0..c999c7e 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -380,20 +380,10 @@ static int rcar_pcie_setup(int nr, struct pci_sys_data
*sys)
return 1;
}
-static void rcar_pcie_add_bus(struct pci_bus *bus)
-{
- if (IS_ENABLED(CONFIG_PCI_MSI)) {
- struct rcar_pcie *pcie = sys_to_pcie(bus->sysdata);
-
- bus->msi = &pcie->msi.chip;
- }
-}
-
struct hw_pci rcar_pci = {
.setup = rcar_pcie_setup,
.map_irq= of_irq_parse_and_map_pci,
.ops= &rcar_pcie_ops,
- .add_bus= rcar_pcie_add_bus,
};
static void rcar_pcie_enable(struct rcar_pcie *pcie)
@@ -402,6 +392,9 @@ static void rcar_pcie_enable(struct rcar_pcie *pcie)
rcar_pci.nr_controllers = 1;
rcar_pci.private_data = (void **)&pcie;
+#ifdef CONFIG_PCI_MSI
+ rcar_pci.msi_chip = &pcie->msi.chip;
+#endif
pci_common_init_dev(&pdev->dev, &rcar_pci);
#ifdef CONFIG_PCI_DOMAINS
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 20/27] MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/mips/pci/pci-xlr.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/mips/pci/pci-xlr.c b/arch/mips/pci/pci-xlr.c
index 0dde803..0e611de 100644
--- a/arch/mips/pci/pci-xlr.c
+++ b/arch/mips/pci/pci-xlr.c
@@ -149,6 +149,8 @@ static struct resource nlm_pci_io_resource = {
.flags = IORESOURCE_IO,
};
+static struct msi_chip xlr_msi_chip;
+
struct pci_controller nlm_pci_controller = {
.index = 0,
.pci_ops= &nlm_pci_ops,
@@ -156,6 +158,9 @@ struct pci_controller nlm_pci_controller = {
.mem_offset = 0xUL,
.io_resource= &nlm_pci_io_resource,
.io_offset = 0xUL,
+#ifdef CONFIG_PCI_MSI
+ .msi_chip = &xlr_msi_chip,
+#endif
};
/*
@@ -214,11 +219,13 @@ static int get_irq_vector(const struct pci_dev *dev)
}
#ifdef CONFIG_PCI_MSI
-void arch_teardown_msi_irq(unsigned int irq)
+static void xlr_teardown_msi_irq(struct msi_chip *chip,
+ unsigned int irq)
{
}
-int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+static int xlr_setup_msi_irq(struct msi_chip *chip,
+ struct pci_dev *dev, struct msi_desc *desc)
{
struct msi_msg msg;
struct pci_dev *lnk;
@@ -263,6 +270,12 @@ int arch_setup_msi_irq(struct pci_dev *dev, struct
msi_desc *desc)
write_msi_msg(irq, &msg);
return 0;
}
+
+static struct msi_chip xlr_msi_chip = {
+ .setup_irq = xlr_setup_msi_irq,
+ .teardown_irq = xlr_teardown_msi_irq,
+};
+
#endif
/* Extra ACK needed for XLR on chip PCI controller */
--
1.7.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: get_maintainers.pl doesn't actually get the real MAINTAINERS?
On 14-10-14 07:26 PM, Joe Perches wrote: On Tue, 2014-10-14 at 19:18 -0700, Scott Branden wrote: Hello, I try running scripts/get_maintainers.pl but it doesn't seem to get the real maintainers properly. Please note this is run against the current MAINTAINERS file. One Example: I would expect drivers/mmc/host/sdhci-bcm2835.c to be maintained by Stephen Warren based on drivers/*/*bcm2835* below. get_maintainers doesn't use * as a depth wildcard */ matches a single top level directory level */*/ matches one level below the top directory level. But the get_maintainers.pl script does not seem to process the information in such a way. So what needs to be corrected - the script or the syntax used in the MAINTAINERS file? BROADCOM BCM2835 ARM ARCHICTURE M: Stephen Warren L: linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git S: Maintained F: arch/arm/mach-bcm/board_bcm2835.c F: arch/arm/boot/dts/bcm2835* F: arch/arm/configs/bcm2835_defconfig F: drivers/*/*bcm2835* F: drivers/*/*/*bmc2835* Thanks for the explanation. So somebody should really do the following to maintain any files no matter where they are located? F: */*bcm2835* F: */*/*bcm2835* F: */*/*/*bcm2835* F: */*/*/*/*bcm2835* F: */*/*/*/*/*bcm2835* F: */*/*/*/*/*/*bcm2835* F: */*/*/*/*/*/*/*bcm2835* Or, can a recursive option be added in the script? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/27] PCI: designware: Save msi chip in pci_sys_data
Save msi chip in pci_sys_data instead of assign
msi chip to every pci bus in .add_bus().
Signed-off-by: Yijing Wang
---
drivers/pci/host/pcie-designware.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index dfed00a..56fa8ab 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -498,6 +498,10 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
val |= PORT_LOGIC_SPEED_CHANGE;
dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val);
+#ifdef CONFIG_PCI_MSI
+ dw_pcie_msi_chip.dev = pp->dev;
+ dw_pci.msi_chip = &dw_pcie_msi_chip;
+#endif
dw_pci.nr_controllers = 1;
dw_pci.private_data = (void **)&pp;
@@ -747,21 +751,10 @@ static int dw_pcie_map_irq(const struct pci_dev *dev, u8
slot, u8 pin)
return irq;
}
-static void dw_pcie_add_bus(struct pci_bus *bus)
-{
- if (IS_ENABLED(CONFIG_PCI_MSI)) {
- struct pcie_port *pp = sys_to_pcie(bus->sysdata);
-
- dw_pcie_msi_chip.dev = pp->dev;
- bus->msi = &dw_pcie_msi_chip;
- }
-}
-
static struct hw_pci dw_pci = {
.setup = dw_pcie_setup,
.scan = dw_pcie_scan_bus,
.map_irq= dw_pcie_map_irq,
- .add_bus= dw_pcie_add_bus,
};
void dw_pcie_setup_rc(struct pcie_port *pp)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 19/27] MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X IRQ. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/mips/include/asm/netlogic/xlp-hal/pcibus.h |1 +
arch/mips/pci/msi-xlp.c | 11 +--
arch/mips/pci/pci-xlp.c |3 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/mips/include/asm/netlogic/xlp-hal/pcibus.h
b/arch/mips/include/asm/netlogic/xlp-hal/pcibus.h
index 91540f4..90646ad 100644
--- a/arch/mips/include/asm/netlogic/xlp-hal/pcibus.h
+++ b/arch/mips/include/asm/netlogic/xlp-hal/pcibus.h
@@ -103,6 +103,7 @@
#ifdef CONFIG_PCI_MSI
void xlp_init_node_msi_irqs(int node, int link);
+extern struct msi_chip xlp_chip;
#else
static inline void xlp_init_node_msi_irqs(int node, int link) {}
#endif
diff --git a/arch/mips/pci/msi-xlp.c b/arch/mips/pci/msi-xlp.c
index e469dc7..cca2257 100644
--- a/arch/mips/pci/msi-xlp.c
+++ b/arch/mips/pci/msi-xlp.c
@@ -245,7 +245,8 @@ static struct irq_chip xlp_msix_chip = {
.irq_unmask = unmask_msi_irq,
};
-void arch_teardown_msi_irq(unsigned int irq)
+static void xlp_teardown_msi_irq(struct msi_chip *chip,
+ unsigned int irq)
{
}
@@ -450,7 +451,8 @@ static int xlp_setup_msix(uint64_t lnkbase, int node, int
link,
return 0;
}
-int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+static int xlp_setup_msi_irq(struct msi_chip *chip,
+ struct pci_dev *dev, struct msi_desc *desc)
{
struct pci_dev *lnkdev;
uint64_t lnkbase;
@@ -472,6 +474,11 @@ int arch_setup_msi_irq(struct pci_dev *dev, struct
msi_desc *desc)
return xlp_setup_msi(lnkbase, node, link, desc);
}
+struct msi_chip xlp_chip = {
+ .setup_irq = xlp_setup_msi_irq,
+ .teardown_irq = xlp_teardown_msi_irq,
+};
+
void __init xlp_init_node_msi_irqs(int node, int link)
{
struct nlm_soc_info *nodep;
diff --git a/arch/mips/pci/pci-xlp.c b/arch/mips/pci/pci-xlp.c
index 7babf01..5d7b6a0 100644
--- a/arch/mips/pci/pci-xlp.c
+++ b/arch/mips/pci/pci-xlp.c
@@ -174,6 +174,9 @@ struct pci_controller nlm_pci_controller = {
.mem_offset = 0xUL,
.io_resource= &nlm_pci_io_resource,
.io_offset = 0xUL,
+#ifdef CONFIG_PCI_MSI
+ .msi_chip = &xlp_chip,
+#endif
};
struct pci_dev *xlp_get_pcie_link(const struct pci_dev *dev)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 17/27] MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/mips/include/asm/octeon/pci-octeon.h |4 +++
arch/mips/pci/msi-octeon.c| 31
arch/mips/pci/pci-octeon.c|3 ++
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/mips/include/asm/octeon/pci-octeon.h
b/arch/mips/include/asm/octeon/pci-octeon.h
index 64ba56a..27ffe42 100644
--- a/arch/mips/include/asm/octeon/pci-octeon.h
+++ b/arch/mips/include/asm/octeon/pci-octeon.h
@@ -66,4 +66,8 @@ enum octeon_dma_bar_type {
*/
extern enum octeon_dma_bar_type octeon_dma_bar_type;
+#ifdef CONFIG_PCI_MSI
+extern struct msi_chip octeon_msi_chip;
+#endif
+
#endif
diff --git a/arch/mips/pci/msi-octeon.c b/arch/mips/pci/msi-octeon.c
index 63bbe07..fd4d698 100644
--- a/arch/mips/pci/msi-octeon.c
+++ b/arch/mips/pci/msi-octeon.c
@@ -57,7 +57,7 @@ static int msi_irq_size;
*
* Returns 0 on success.
*/
-int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+static int octeon_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
struct msi_msg msg;
u16 control;
@@ -132,12 +132,12 @@ msi_irq_allocated:
/* Make sure the search for available interrupts didn't fail */
if (irq >= 64) {
if (request_private_bits) {
- pr_err("arch_setup_msi_irq: Unable to find %d free
interrupts, trying just one",
- 1 << request_private_bits);
+ pr_err("%s: Unable to find %d free interrupts, trying
just one",
+ __func__, 1 << request_private_bits);
request_private_bits = 0;
goto try_only_one;
} else
- panic("arch_setup_msi_irq: Unable to find a free MSI
interrupt");
+ panic("%s: Unable to find a free MSI interrupt",
__func__);
}
/* MSI interrupts start at logical IRQ OCTEON_IRQ_MSI_BIT0 */
@@ -168,7 +168,7 @@ msi_irq_allocated:
msg.address_hi = (0 + CVMX_SLI_PCIE_MSI_RCV) >> 32;
break;
default:
- panic("arch_setup_msi_irq: Invalid octeon_dma_bar_type");
+ panic("%s: Invalid octeon_dma_bar_type", __func__);
}
msg.data = irq - OCTEON_IRQ_MSI_BIT0;
@@ -182,7 +182,8 @@ msi_irq_allocated:
return 0;
}
-int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+static int octeon_setup_msi_irqs(struct msi_chip *chip, struct pci_dev *dev,
+ int nvec, int type)
{
struct msi_desc *entry;
int ret;
@@ -201,7 +202,7 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int
type)
return 1;
list_for_each_entry(entry, &dev->msi_list, list) {
- ret = arch_setup_msi_irq(dev, entry);
+ ret = octeon_setup_msi_irq(dev, entry);
if (ret < 0)
return ret;
if (ret > 0)
@@ -210,14 +211,13 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec,
int type)
return 0;
}
-
/**
* Called when a device no longer needs its MSI interrupts. All
* MSI interrupts for the device are freed.
*
* @irq:The devices first irq number. There may be multple in sequence.
*/
-void arch_teardown_msi_irq(unsigned int irq)
+static void octeon_teardown_msi_irq(struct msi_chip *chip, unsigned int irq)
{
int number_irqs;
u64 bitmask;
@@ -226,8 +226,8 @@ void arch_teardown_msi_irq(unsigned int irq)
if ((irq < OCTEON_IRQ_MSI_BIT0)
|| (irq > msi_irq_size + OCTEON_IRQ_MSI_BIT0))
- panic("arch_teardown_msi_irq: Attempted to teardown illegal "
- "MSI interrupt (%d)", irq);
+ panic("%s: Attempted to teardown illegal "
+ "MSI interrupt (%d)", __func__, irq);
irq -= OCTEON_IRQ_MSI_BIT0;
index = irq / 64;
@@ -249,8 +249,8 @@ void arch_teardown_msi_irq(unsigned int irq)
/* Shift the mask to the correct bit location */
bitmask <<= irq0;
if ((msi_free_irq_bitmask[index] & bitmask) != bitmask)
- panic("arch_teardown_msi_irq: Attempted to teardown MSI "
- "interrupt (%d) not in use", irq);
+ panic("%s: Attempted to teardown MSI "
+ "interrupt (%d) not in use", __func__, irq);
/* Checks are done, update the in use bitmask */
spin_lock(&msi_free_irq_bitmask_lock);
@@ -259,6 +259,11 @@ void arch_teardown_msi_irq(unsigned int irq)
spin_unlock(&msi_free_irq_bitmask_lock);
}
+struct msi_chip octeon_msi_chip = {
+ .setup_irqs = octeon_setup_msi_irqs,
+ .teardown_irq = octeon_teardown_msi_irq,
+};
+
static DEFINE_RAW_SPINLOCK(octeon_irq_
[PATCH v3 18/27] MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
Commit 465665f78a7 ("mips: Kill pointless destroy_irq()") removed
the destroy_irq(). So remove the leftover one in xlp_setup_msix()
to fix build error.
arch/mips/pci/msi-xlp.c: In function 'xlp_setup_msix':
arch/mips/pci/msi-xlp.c:447:3: error: implicit declaration of function
'destroy_irq'..
cc1: some warnings being treated as errors
make[1]: *** [arch/mips/pci/msi-xlp.o] Error 1
make: *** [arch/mips/pci/] Error 2
Signed-off-by: Yijing Wang
Cc: Thomas Gleixner
---
arch/mips/pci/msi-xlp.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/mips/pci/msi-xlp.c b/arch/mips/pci/msi-xlp.c
index fa374fe..e469dc7 100644
--- a/arch/mips/pci/msi-xlp.c
+++ b/arch/mips/pci/msi-xlp.c
@@ -443,10 +443,8 @@ static int xlp_setup_msix(uint64_t lnkbase, int node, int
link,
msg.data = 0xc00 | msixvec;
ret = irq_set_msi_desc(xirq, desc);
- if (ret < 0) {
- destroy_irq(xirq);
+ if (ret < 0)
return ret;
- }
write_msi_msg(xirq, &msg);
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/27] PCI: tegra: Save msi chip in pci_sys_data
Save msi chip in pci_sys_data instead of assign
msi chip to every pci bus in .add_bus().
Signed-off-by: Yijing Wang
---
drivers/pci/host/pci-tegra.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874..5af0525 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev,
u8 slot, u8 pin)
return irq;
}
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
- if (IS_ENABLED(CONFIG_PCI_MSI)) {
- struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
- bus->msi = &pcie->msi.chip;
- }
-}
-
static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
{
struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -1881,11 +1872,13 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
memset(&hw, 0, sizeof(hw));
+#ifdef CONFIG_PCI_MSI
+ hw.msi_chip = &pcie->msi.chip;
+#endif
hw.nr_controllers = 1;
hw.private_data = (void **)&pcie;
hw.setup = tegra_pcie_setup;
hw.map_irq = tegra_pcie_map_irq;
- hw.add_bus = tegra_pcie_add_bus;
hw.scan = tegra_pcie_scan_bus;
hw.ops = &tegra_pcie_ops;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 21/27] Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
Hi Michael,
I dropped the Acked-by , because this version has a
lot changes compared to last. So, I guess you may want to check it again.
---
arch/powerpc/include/asm/pci-bridge.h | 15 +++
arch/powerpc/kernel/msi.c | 12 ++--
arch/powerpc/kernel/pci-common.c |3 +++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 4ca90a3..233553e 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -32,6 +32,10 @@ struct pci_controller {
int self_busno;
struct resource busn;
+#ifdef CONFIG_PCI_MSI
+ struct msi_chip *msi_chip;
+#endif
+
void __iomem *io_base_virt;
#ifdef CONFIG_PPC64
void *io_base_alloc;
@@ -94,6 +98,17 @@ struct pci_controller {
void *private_data;
};
+#ifdef CONFIG_PCI_MSI
+extern struct msi_chip ppc_msi_chip;
+
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct pci_controller *hose = bus->sysdata;
+
+ return hose->msi_chip;
+}
+#endif
+
/* These are used for config access before all the PCI probing
has been done. */
extern int early_read_config_byte(struct pci_controller *hose, int bus,
diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
index 71bd161..f38b67c 100644
--- a/arch/powerpc/kernel/msi.c
+++ b/arch/powerpc/kernel/msi.c
@@ -13,7 +13,8 @@
#include
-int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+static int ppc_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev, int nvec, int type)
{
if (!ppc_md.setup_msi_irqs || !ppc_md.teardown_msi_irqs) {
pr_debug("msi: Platform doesn't provide MSI callbacks.\n");
@@ -27,7 +28,13 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int
type)
return ppc_md.setup_msi_irqs(dev, nvec, type);
}
-void arch_teardown_msi_irqs(struct pci_dev *dev)
+static void ppc_teardown_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev)
{
ppc_md.teardown_msi_irqs(dev);
}
+
+struct msi_chip ppc_msi_chip = {
+ .setup_irqs = ppc_setup_msi_irqs,
+ .teardown_irqs = ppc_teardown_msi_irqs,
+};
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index b2814e2..9f18b42 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1594,6 +1594,9 @@ void pcibios_scan_phb(struct pci_controller *hose)
/* Wire up PHB bus resources */
pcibios_setup_phb_resources(hose, &resources);
+#ifdef CONFIG_PCI_MSI
+ hose->msi_chip = &ppc_msi_chip;
+#endif
hose->busn.start = hose->first_busno;
hose->busn.end = hose->last_busno;
hose->busn.flags = IORESOURCE_BUS;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 23/27] arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/arm/mach-iop13xx/include/mach/pci.h |4
arch/arm/mach-iop13xx/iq81340mc.c|3 +++
arch/arm/mach-iop13xx/iq81340sc.c|5 -
arch/arm/mach-iop13xx/msi.c | 11 +--
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-iop13xx/include/mach/pci.h
b/arch/arm/mach-iop13xx/include/mach/pci.h
index 59f42b5..c87ac3a 100644
--- a/arch/arm/mach-iop13xx/include/mach/pci.h
+++ b/arch/arm/mach-iop13xx/include/mach/pci.h
@@ -11,6 +11,10 @@ void iop13xx_atu_select(struct hw_pci *plat_pci);
void iop13xx_pci_init(void);
void iop13xx_map_pci_memory(void);
+#ifdef CONFIG_PCI_MSI
+extern struct msi_chip iop13xx_msi_chip;
+#endif
+
#define IOP_PCI_STATUS_ERROR (PCI_STATUS_PARITY | \
PCI_STATUS_SIG_TARGET_ABORT | \
PCI_STATUS_REC_TARGET_ABORT | \
diff --git a/arch/arm/mach-iop13xx/iq81340mc.c
b/arch/arm/mach-iop13xx/iq81340mc.c
index 9cd07d3..1f499b6 100644
--- a/arch/arm/mach-iop13xx/iq81340mc.c
+++ b/arch/arm/mach-iop13xx/iq81340mc.c
@@ -59,6 +59,9 @@ static struct hw_pci iq81340mc_pci __initdata = {
.map_irq= iq81340mc_pcix_map_irq,
.scan = iop13xx_scan_bus,
.preinit= iop13xx_pci_init,
+#ifdef CONFIG_PCI_MSI
+ .msi_chip = &iop13xx_msi_chip,
+#endif
};
static int __init iq81340mc_pci_init(void)
diff --git a/arch/arm/mach-iop13xx/iq81340sc.c
b/arch/arm/mach-iop13xx/iq81340sc.c
index b3ec11c..8bdfdc5 100644
--- a/arch/arm/mach-iop13xx/iq81340sc.c
+++ b/arch/arm/mach-iop13xx/iq81340sc.c
@@ -60,7 +60,10 @@ static struct hw_pci iq81340sc_pci __initdata = {
.setup = iop13xx_pci_setup,
.scan = iop13xx_scan_bus,
.map_irq= iq81340sc_atux_map_irq,
- .preinit= iop13xx_pci_init
+ .preinit= iop13xx_pci_init,
+#ifdef CONFIG_PCI_MSI
+ .msi_chip = &iop13xx_msi_chip,
+#endif
};
static int __init iq81340sc_pci_init(void)
diff --git a/arch/arm/mach-iop13xx/msi.c b/arch/arm/mach-iop13xx/msi.c
index e7730cf..3135a63 100644
--- a/arch/arm/mach-iop13xx/msi.c
+++ b/arch/arm/mach-iop13xx/msi.c
@@ -132,7 +132,8 @@ static struct irq_chip iop13xx_msi_chip = {
.irq_unmask = unmask_msi_irq,
};
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+static int iop13xx_setup_msi_irq(struct msi_chip *chip,
+ struct pci_dev *dev, struct msi_desc *desc)
{
int id, irq = irq_alloc_desc_from(IRQ_IOP13XX_MSI_0, -1);
struct msi_msg msg;
@@ -159,7 +160,13 @@ int arch_setup_msi_irq(struct pci_dev *pdev, struct
msi_desc *desc)
return 0;
}
-void arch_teardown_msi_irq(unsigned int irq)
+static void iop13xx_teardown_msi_irq(struct msi_chip *chip,
+ unsigned int irq)
{
irq_free_desc(irq);
}
+
+struct msi_chip iop13xx_chip = {
+ .setup_irq = iop13xx_setup_msi_irq,
+ .teardown_irq = iop13xx_teardown_msi_irq,
+};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 08/27] PCI: mvebu: Save msi chip in pci_sys_data
Save msi chip in pci_sys_data instead of assign
msi chip to every pci bus in .add_bus().
Signed-off-by: Yijing Wang
---
drivers/pci/host/pci-mvebu.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index b1315e1..f8e9c6c 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -774,12 +774,6 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct
pci_sys_data *sys)
return bus;
}
-static void mvebu_pcie_add_bus(struct pci_bus *bus)
-{
- struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
- bus->msi = pcie->msi;
-}
-
static resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
const struct resource *res,
resource_size_t start,
@@ -816,6 +810,9 @@ static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
memset(&hw, 0, sizeof(hw));
+#ifdef CONFIG_PCI_MSI
+ hw.msi_chip = pcie->msi;
+#endif
hw.nr_controllers = 1;
hw.private_data = (void **)&pcie;
hw.setup = mvebu_pcie_setup;
@@ -823,7 +820,6 @@ static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
hw.map_irq= of_irq_parse_and_map_pci;
hw.ops= &mvebu_pcie_ops;
hw.align_resource = mvebu_pcie_align_resource;
- hw.add_bus= mvebu_pcie_add_bus;
pci_common_init(&hw);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 14/27] Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
drivers/iommu/irq_remapping.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 33c4395..48d57e9 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -139,8 +139,8 @@ error:
return ret;
}
-static int irq_remapping_setup_msi_irqs(struct pci_dev *dev,
- int nvec, int type)
+static int irq_remapping_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *dev, int nvec, int type)
{
if (type == PCI_CAP_ID_MSI)
return do_setup_msi_irqs(dev, nvec);
@@ -148,6 +148,11 @@ static int irq_remapping_setup_msi_irqs(struct pci_dev
*dev,
return do_setup_msix_irqs(dev, nvec);
}
+static struct msi_chip remap_msi_chip = {
+ .setup_irqs = irq_remapping_setup_msi_irqs,
+ .teardown_irq = native_teardown_msi_irq,
+};
+
static void eoi_ioapic_pin_remapped(int apic, int pin, int vector)
{
/*
@@ -165,9 +170,9 @@ static void __init irq_remapping_modify_x86_ops(void)
x86_io_apic_ops.set_affinity= set_remapped_irq_affinity;
x86_io_apic_ops.setup_entry = setup_ioapic_remapped_entry;
x86_io_apic_ops.eoi_ioapic_pin = eoi_ioapic_pin_remapped;
- x86_msi.setup_msi_irqs = irq_remapping_setup_msi_irqs;
x86_msi.setup_hpet_msi = setup_hpet_msi_remapped;
x86_msi.compose_msi_msg = compose_remapped_msi_msg;
+ x86_msi_chip = &remap_msi_chip;
}
static __init int setup_nointremap(char *str)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 22/27] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
Hi Sebastian,
I dropped the Acked-by , because this version has a
lot changes compared to last. So, I guess you may want to check it again.
---
arch/s390/include/asm/pci.h |9 +
arch/s390/pci/pci.c | 12 ++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index c030900..4d41f08 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -88,6 +88,8 @@ struct zpci_dev {
u32 uid;/* user defined id */
u8 util_str[CLP_UTIL_STR_LEN]; /* utility string */
+ struct msi_chip *msi_chip;
+
/* IRQ stuff */
u64 msi_addr; /* MSI address */
struct airq_iv *aibv; /* adapter interrupt bit vector */
@@ -121,6 +123,13 @@ struct zpci_dev {
struct dentry *debugfs_perf;
};
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct zpci_dev *zpci = bus->sysdata;
+
+ return zpci->msi_chip;
+}
+
static inline bool zdev_enabled(struct zpci_dev *zdev)
{
return (zdev->fh & (1UL << 31)) ? true : false;
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 552b990..bf6732f 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -358,7 +358,8 @@ static void zpci_irq_handler(struct airq_struct *airq)
}
}
-int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+static int zpci_setup_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *pdev, int nvec, int type)
{
struct zpci_dev *zdev = get_zdev(pdev);
unsigned int hwirq, msi_vecs;
@@ -434,7 +435,8 @@ out:
return rc;
}
-void arch_teardown_msi_irqs(struct pci_dev *pdev)
+static void zpci_teardown_msi_irqs(struct msi_chip *chip,
+ struct pci_dev *pdev)
{
struct zpci_dev *zdev = get_zdev(pdev);
struct msi_desc *msi;
@@ -464,6 +466,11 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev)
airq_iv_free_bit(zpci_aisb_iv, zdev->aisb);
}
+static struct msi_chip zpci_msi_chip = {
+ .setup_irqs = zpci_setup_msi_irqs,
+ .teardown_irqs = zpci_teardown_msi_irqs,
+};
+
static void zpci_map_resources(struct zpci_dev *zdev)
{
struct pci_dev *pdev = zdev->pdev;
@@ -749,6 +756,7 @@ static int zpci_scan_bus(struct zpci_dev *zdev)
if (ret)
return ret;
+ zdev->msi_chip = &zpci_msi_chip;
zdev->bus = pci_scan_root_bus(NULL, ZPCI_BUS_NR, &pci_root_ops,
zdev, &resources);
if (!zdev->bus) {
--
1.7.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: get_maintainers.pl doesn't actually get the real MAINTAINERS?
On Tue, 2014-10-14 at 19:18 -0700, Scott Branden wrote: > Hello, > > I try running scripts/get_maintainers.pl but it doesn't seem to get the > real maintainers properly. Please note this is run against the current > MAINTAINERS file. > > One Example: I would expect drivers/mmc/host/sdhci-bcm2835.c to be > maintained by Stephen Warren based on drivers/*/*bcm2835* below. get_maintainers doesn't use * as a depth wildcard */ matches a single top level directory level */*/ matches one level below the top directory level. > But > the get_maintainers.pl script does not seem to process the information > in such a way. So what needs to be corrected - the script or the syntax > used in the MAINTAINERS file? > > BROADCOM BCM2835 ARM ARCHICTURE > M:Stephen Warren > L:linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers) > T:git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git > S:Maintained > F:arch/arm/mach-bcm/board_bcm2835.c > F:arch/arm/boot/dts/bcm2835* > F:arch/arm/configs/bcm2835_defconfig > F:drivers/*/*bcm2835* F: drivers/*/*/*bmc2835* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 26/27] tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/tile/include/asm/pci.h | 10 ++
arch/tile/kernel/pci_gx.c | 13 +++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/tile/include/asm/pci.h b/arch/tile/include/asm/pci.h
index dfedd7a..d27d9ec 100644
--- a/arch/tile/include/asm/pci.h
+++ b/arch/tile/include/asm/pci.h
@@ -152,6 +152,7 @@ struct pci_controller {
int pio_io_index; /* PIO region index for I/O space access */
#endif
+ struct msi_chip *msi_chip;
/*
* Mem-Map regions for all the memory controllers so that Linux can
* map all of its physical memory space to the PCI bus.
@@ -179,6 +180,15 @@ struct pci_controller {
int irq_intx_table[4];
};
+extern struct msi_chip tilegx_msi;
+
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct pci_controller *controller = bus->sysdata;
+
+ return controller->msi_chip;
+}
+
extern struct pci_controller pci_controllers[TILEGX_NUM_TRIO *
TILEGX_TRIO_PCIES];
extern gxio_trio_context_t trio_contexts[TILEGX_NUM_TRIO];
extern int num_trio_shims;
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index e39f9c5..ba66517 100644
--- a/arch/tile/kernel/pci_gx.c
+++ b/arch/tile/kernel/pci_gx.c
@@ -887,6 +887,7 @@ int __init pcibios_init(void)
controller->mem_offset);
pci_add_resource(&resources, &controller->io_space);
controller->first_busno = next_busno;
+ controller->msi_chip = &tilegx_msi;
bus = pci_scan_root_bus(NULL, next_busno, controller->ops,
controller, &resources);
controller->root_bus = bus;
@@ -1485,7 +1486,8 @@ static struct irq_chip tilegx_msi_chip = {
/* TBD: support set_affinity. */
};
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+static int tile_setup_msi_irq(struct msi_chip *chip,
+ struct pci_dev *pdev, struct msi_desc *desc)
{
struct pci_controller *controller;
gxio_trio_context_t *trio_context;
@@ -1604,7 +1606,12 @@ is_64_failure:
return ret;
}
-void arch_teardown_msi_irq(unsigned int irq)
+static void tile_teardown_msi_irq(struct msi_chip *chip, unsigned int irq)
{
irq_free_hwirq(irq);
}
+
+struct msi_chip tilegx_msi = {
+ .setup_irq = tile_setup_msi_irq,
+ .teardown_irq = tile_teardown_msi_irq,
+};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 25/27] Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/sparc/kernel/pci.c | 14 --
arch/sparc/kernel/pci_impl.h | 12
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index b36365f..a46a148 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -656,6 +656,9 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
printk("PCI: Scanning PBM %s\n", node->full_name);
+#ifdef CONFIG_PCI_MSI
+ pbm->msi_chip = &sparc_msi_chip;
+#endif
pci_add_resource_offset(&resources, &pbm->io_space,
pbm->io_space.start);
pci_add_resource_offset(&resources, &pbm->mem_space,
@@ -905,7 +908,8 @@ int pci_domain_nr(struct pci_bus *pbus)
EXPORT_SYMBOL(pci_domain_nr);
#ifdef CONFIG_PCI_MSI
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+static int sparc_setup_msi_irq(struct msi_chip *chip,
+ struct pci_dev *pdev, struct msi_desc *desc)
{
struct pci_pbm_info *pbm = pdev->dev.archdata.host_controller;
unsigned int irq;
@@ -916,7 +920,7 @@ int arch_setup_msi_irq(struct pci_dev *pdev, struct
msi_desc *desc)
return pbm->setup_msi_irq(&irq, pdev, desc);
}
-void arch_teardown_msi_irq(unsigned int irq)
+static void sparc_teardown_msi_irq(struct msi_chip *chip, unsigned int irq)
{
struct msi_desc *entry = irq_get_msi_desc(irq);
struct pci_dev *pdev = entry->dev;
@@ -925,6 +929,12 @@ void arch_teardown_msi_irq(unsigned int irq)
if (pbm->teardown_msi_irq)
pbm->teardown_msi_irq(irq, pdev);
}
+
+struct msi_chip sparc_msi_chip = {
+ .setup_irq = sparc_setup_msi_irq,
+ .teardown_irq = sparc_teardown_msi_irq,
+};
+
#endif /* !(CONFIG_PCI_MSI) */
static void ali_sound_dma_hack(struct pci_dev *pdev, int set_bit)
diff --git a/arch/sparc/kernel/pci_impl.h b/arch/sparc/kernel/pci_impl.h
index 75803c7..073bb4e 100644
--- a/arch/sparc/kernel/pci_impl.h
+++ b/arch/sparc/kernel/pci_impl.h
@@ -55,6 +55,8 @@ struct sparc64_msiq_cookie {
struct pci_pbm_info *pbm;
unsigned long msiqid;
};
+
+extern struct msi_chip sparc_msi_chip;
#endif
struct pci_pbm_info {
@@ -132,6 +134,7 @@ struct pci_pbm_info {
void*msi_queues;
unsigned long *msi_bitmap;
unsigned int*msi_irq_table;
+ struct msi_chip *msi_chip;
int (*setup_msi_irq)(unsigned int *irq_p, struct pci_dev *pdev,
struct msi_desc *entry);
void (*teardown_msi_irq)(unsigned int irq, struct pci_dev *pdev);
@@ -153,6 +156,15 @@ struct pci_pbm_info {
int numa_node;
};
+#ifdef CONFIG_PCI_MSI
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct pci_pbm_info *pbm = bus->sysdata;
+
+ return pbm->msi_chip;
+}
+#endif
+
extern struct pci_pbm_info *pci_pbm_root;
extern int pci_num_pbms;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 24/27] IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/ia64/include/asm/pci.h | 10 ++
arch/ia64/kernel/msi_ia64.c | 14 ++
arch/ia64/pci/pci.c |1 +
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index 52af5ed..907dcba 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@ -94,6 +94,7 @@ struct pci_controller {
int segment;
int node; /* nearest node with memory or NUMA_NO_NODE for
global allocation */
+ struct msi_chip *msi_chip;
void *platform_data;
};
@@ -101,6 +102,15 @@ struct pci_controller {
#define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)
#define pci_domain_nr(busdev)(PCI_CONTROLLER(busdev)->segment)
+extern struct msi_chip chip;
+
+static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
+{
+ struct pci_controller *ctrl = bus->sysdata;
+
+ return ctrl->msi_chip;
+}
+
extern struct pci_ops pci_root_ops;
static inline int pci_proc_domain(struct pci_bus *bus)
diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
index 8c3730c..401fc98 100644
--- a/arch/ia64/kernel/msi_ia64.c
+++ b/arch/ia64/kernel/msi_ia64.c
@@ -112,15 +112,16 @@ static struct irq_chip ia64_msi_chip = {
};
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+static int arch_ia64_setup_msi_irq(struct msi_chip *chip,
+ struct pci_dev *dev, struct msi_desc *desc)
{
if (platform_setup_msi_irq)
- return platform_setup_msi_irq(pdev, desc);
+ return platform_setup_msi_irq(dev, desc);
- return ia64_setup_msi_irq(pdev, desc);
+ return ia64_setup_msi_irq(dev, desc);
}
-void arch_teardown_msi_irq(unsigned int irq)
+static void arch_ia64_teardown_msi_irq(struct msi_chip *chip, unsigned int irq)
{
if (platform_teardown_msi_irq)
return platform_teardown_msi_irq(irq);
@@ -128,6 +129,11 @@ void arch_teardown_msi_irq(unsigned int irq)
return ia64_teardown_msi_irq(irq);
}
+struct msi_chip chip = {
+ .setup_irq = arch_ia64_setup_msi_irq,
+ .teardown_irq = arch_ia64_teardown_msi_irq,
+};
+
#ifdef CONFIG_INTEL_IOMMU
#ifdef CONFIG_SMP
static int dmar_msi_set_affinity(struct irq_data *data,
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..299b67d 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -437,6 +437,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root
*root)
controller->companion = device;
controller->node = acpi_get_node(device->handle);
+ controller->msi_chip = &chip;
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 27/27] PCI/MSI: Clean up unused MSI arch functions
Now we use struct msi_chip in all platforms to configure
MSI/MSI-X. We can clean up the unused arch functions.
Signed-off-by: Yijing Wang
---
Hi Lucas,
I dropped the reviewed-by, because this version has a lot changes
compared to last one, I guess you may want to check it again.
---
drivers/iommu/irq_remapping.c |2 +-
drivers/pci/msi.c | 103 +++--
include/linux/msi.h | 14 --
include/linux/pci.h |8 ---
4 files changed, 39 insertions(+), 88 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 48d57e9..77160a5 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -92,7 +92,7 @@ error:
/*
* Restore altered MSI descriptor fields and prevent just destroyed
-* IRQs from tearing down again in default_teardown_msi_irqs()
+* IRQs from tearing down again in teardown_msi_irqs()
*/
msidesc->irq = 0;
msidesc->nvec_used = 0;
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 5cbd774..b9fefe9 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -28,54 +28,31 @@ int pci_msi_ignore_mask;
#define msix_table_size(flags) ((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
-/* Arch hooks */
-
-int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
-{
- struct msi_chip *chip;
- int err;
-
- chip = pci_msi_chip(dev->bus);
- if (!chip || !chip->setup_irq)
- return -EINVAL;
-
- err = chip->setup_irq(chip, dev, desc);
- if (err < 0)
- return err;
-
- return 0;
-}
-
-void __weak arch_teardown_msi_irq(unsigned int irq)
-{
- struct msi_desc *entry = irq_get_msi_desc(irq);
- struct msi_chip *chip = pci_msi_chip(entry->dev->bus);
-
- if (!chip || !chip->teardown_irq)
- return;
-
- chip->teardown_irq(chip, irq);
-}
-
-int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *entry;
int ret;
struct msi_chip *chip;
chip = pci_msi_chip(dev->bus);
- if (chip && chip->setup_irqs)
+ if (!chip)
+ return -EINVAL;
+
+ if (chip->setup_irqs)
return chip->setup_irqs(chip, dev, nvec, type);
/*
* If an architecture wants to support multiple MSI, it needs to
-* override arch_setup_msi_irqs()
+* implement chip->setup_irqs().
*/
if (type == PCI_CAP_ID_MSI && nvec > 1)
return 1;
+ if (!chip->setup_irq)
+ return -EINVAL;
+
list_for_each_entry(entry, &dev->msi_list, list) {
- ret = arch_setup_msi_irq(dev, entry);
+ ret = chip->setup_irq(chip, dev, entry);
if (ret < 0)
return ret;
if (ret > 0)
@@ -85,13 +62,20 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
return 0;
}
-/*
- * We have a default implementation available as a separate non-weak
- * function, as it is used by the Xen x86 PCI code
- */
-void default_teardown_msi_irqs(struct pci_dev *dev)
+static void teardown_msi_irqs(struct pci_dev *dev)
{
struct msi_desc *entry;
+ struct msi_chip *chip;
+
+ chip = pci_msi_chip(dev->bus);
+ if (!chip)
+ return;
+
+ if (chip->teardown_irqs)
+ return chip->teardown_irqs(chip, dev);
+
+ if (!chip->teardown_irq)
+ return;
list_for_each_entry(entry, &dev->msi_list, list) {
int i, nvec;
@@ -102,20 +86,10 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
else
nvec = 1 << entry->msi_attrib.multiple;
for (i = 0; i < nvec; i++)
- arch_teardown_msi_irq(entry->irq + i);
+ chip->teardown_irq(chip, entry->irq + i);
}
}
-void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
-{
- struct msi_chip *chip = pci_msi_chip(dev->bus);
-
- if (chip && chip->teardown_irqs)
- return chip->teardown_irqs(chip, dev);
-
- return default_teardown_msi_irqs(dev);
-}
-
static void default_restore_msi_irq(struct pci_dev *dev, int irq)
{
struct msi_desc *entry;
@@ -134,10 +108,18 @@ static void default_restore_msi_irq(struct pci_dev *dev,
int irq)
__write_msi_msg(entry, &entry->msg);
}
-void __weak arch_restore_msi_irqs(struct pci_dev *dev)
+static void default_restore_msi_irqs(struct pci_dev *dev)
{
- struct msi_chip *chip = pci_msi_chip(dev->bus);
+ struct msi_desc *entry = NULL;
+
+ list_for_each_entry(entry, &dev->msi_list, list) {
+ default_restore_msi_irq(dev, entry->irq);
+ }
+}
+static void restore_msi_irqs(struct pci_dev *dev)
+{
+ s
[PATCH v3 01/27] MSI: Remove the redundant irq_set_chip_data()
Currently, pcie-designware, pcie-rcar and pci-tegra drivers
use irq chip_data to save the msi_chip pointer. They
already call irq_set_chip_data() in their own MSI irq map
functions. And chip_data is an opaque pointer, how to use
it is arch dependent. It should not be placed in MSI core.
Signed-off-by: Yijing Wang
Reviewed-by: Thierry Reding
---
drivers/pci/msi.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 2f7c92c..ecb92a5 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -41,14 +41,13 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
msi_desc *desc)
if (err < 0)
return err;
- irq_set_chip_data(desc->irq, chip);
-
return 0;
}
void __weak arch_teardown_msi_irq(unsigned int irq)
{
- struct msi_chip *chip = irq_get_chip_data(irq);
+ struct msi_desc *entry = irq_get_msi_desc(irq);
+ struct msi_chip *chip = entry->dev->bus->msi;
if (!chip || !chip->teardown_irq)
return;
--
1.7.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] hyperv: Implement Time Synchronization using host time sample
These old duplicated patches are accidentally send by the mail server... Sorry
for that.
> -Original Message-
> From: Thomas Shao [mailto:huis...@microsoft.com]
> Sent: Tuesday, October 14, 2014 1:49 PM
> To: t...@linutronix.de; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; KY Srinivasan
> Cc: Thomas Shao
> Subject: [PATCH] hyperv: Implement Time Synchronization using host time
> sample
>
> In current hyper-v time sync service,it only gets the initial clock time from
> the
> host. It didn't process the following time samples. This change introduced a
> module parameter called host_time_sync. If it is set to true, the guest will
> periodically sychronize it's time with the host clock using host time sample.
> By
> default it is disabled, because we still recommend user to configure NTP for
> time synchronization.
>
> Signed-off-by: Thomas Shao
> Reviewed-by: K. Y. Srinivasan
> ---
> drivers/hv/hv_util.c | 114
> +---
> kernel/time/timekeeping.c |1 +
> 2 files changed, 107 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c index
> 3b9c9ef..1d8390c
> 100644
> --- a/drivers/hv/hv_util.c
> +++ b/drivers/hv/hv_util.c
> @@ -51,11 +51,30 @@
> #define HB_WS2008_MAJOR 1
> #define HB_WS2008_VERSION(HB_WS2008_MAJOR << 16 | HB_MINOR)
>
> +#define TIMESAMPLE_INTERVAL 50L /* 5s in nanosecond */
> +
> +/*host sends time sample for every 5s.So the max polling interval *is
> +128*5 = 640s.
> +*/
> +#define TIME_ADJ_MAX_INTERVAL 128 /*Max polling interval */
> +
> static int sd_srv_version;
> static int ts_srv_version;
> static int hb_srv_version;
> static int util_fw_version;
>
> +/*host sends time sample for every 5s.So the initial polling interval
> +*is 5s.
> +*/
> +static s32 adj_interval = 1;
> +
> +/*The host_time_sync module parameter is used to control the time
> + sync between host and guest.
> +*/
> +static bool host_time_sync;
> +module_param(host_time_sync, bool, (S_IRUGO | S_IWUSR));
> +MODULE_PARM_DESC(host_time_sync, "If the guest sync time with host");
> +
> static void shutdown_onchannelcallback(void *context); static struct
> hv_util_service util_shutdown = {
> .util_cb = shutdown_onchannelcallback, @@ -163,15 +182,61 @@
> static void shutdown_onchannelcallback(void *context)
> /*
> * Set guest time to host UTC time.
> */
> -static inline void do_adj_guesttime(u64 hosttime)
> +static inline void do_adj_guesttime(u64 hosttime, bool forceSync)
> {
> - s64 host_tns;
> - struct timespec host_ts;
> + s64 host_tns, guest_tns, diff;
> + struct timespec host_ts, guest_ts;
> + struct timex txc;
> + s64 tickchg;
> + int diff_sign;
>
> host_tns = (hosttime - WLTIMEDELTA) * 100;
> host_ts = ns_to_timespec(host_tns);
>
> - do_settimeofday(&host_ts);
> + if (forceSync) {
> + do_settimeofday(&host_ts);
> + } else {
> + guest_ts = CURRENT_TIME;
> + guest_tns = timespec_to_ns(&guest_ts);
> + diff = host_tns - guest_tns;
> + if (diff >= 0) {
> + diff_sign = 1;
> + } else {
> + diff_sign = -1;
> + diff = -diff;
> + }
> +
> + /*1s in nanosecond */
> + if (diff > 10 || diff < -10) {
> + do_settimeofday(&host_ts);
> + return;
> + }
> +
> + /*1ms in nanosecond */
> + if (diff > 100 || diff < -100) {
> + /* get the current tick value */
> + txc.modes = 0;
> + do_adjtimex(&txc);
> +
> + tickchg = diff * TICK_USEC /
> + (TIMESAMPLE_INTERVAL *
> adj_interval);
> +
> + if (tickchg > TICK_USEC/10)
> + tickchg = TICK_USEC/10;
> +
> + if (txc.tick == TICK_USEC + diff_sign * tickchg)
> + return;
> +
> + txc.modes = ADJ_TICK;
> + txc.tick = TICK_USEC + diff_sign * tickchg;
> +
> + do_adjtimex(&txc);
> + } else {
> + /* double the polling interval*/
> + if (adj_interval < TIME_ADJ_MAX_INTERVAL)
> + adj_interval = adj_interval * 2;
> + }
> + }
> }
>
> /*
> @@ -179,8 +244,9 @@ static inline void do_adj_guesttime(u64 hosttime)
> */
>
> struct adj_time_work {
> - struct work_struct work;
> + struct work_struct work;
> u64 host_time;
> + boolforceSync;
> };
>
> static void hv_set_host_time(struct work_struct *work) @@ -188,7 +254,7
> @@ static void hv_set_host_time(struct work
Re: [PATCH 0/8] power_supply: Add API for safe access of get_property-like function attrs
Hi, On 2014년 10월 14일 21:20, Krzysztof Kozlowski wrote: > Hi, > > > After fixing issue with referencing old power supply after driver > unbind in charger manager [1] I noticed that the race condition in such > case may still exist. It would be harder to trigger but still possible. > > The race is between using a reference to power supply (obtained > with power_supply_get_by_name()) and removing the driver. > > This patchset aims to fix the race by introducing wrappers for > accessing the power supply function attributes. > > Patch 1 introduces new API. Other patches replace direct calls in > drivers. > > Rebased on next-20141007. > Tested on Trats2 board (max77693 + charger manager). > > > Kindly asking for reviewing/testing the drivers, although the changes > are straightforward. > Looks good to me, but need someone to comment on this. Acked-by : Jonghwa Lee Thanks, Jonghwa > > Best regards, > Krzysztof > > > [1] https://lkml.org/lkml/2014/10/13/272 > > > > Krzysztof Kozlowski (8): > power_supply: Add API for safe access of power supply function attrs > power_supply: sysfs: Use power_supply_*() API for accessing function > attrs > power: 88pm860x_charger: Use power_supply_*() API for accessing > function attrs > power: ab8500: Use power_supply_*() API for accessing function attrs > mfd: ab8500: Use power_supply_*() API for accessing function attrs > power: apm_power: Use power_supply_*() API for accessing function > attrs > power: bq2415x_charger: Use power_supply_*() API for accessing > function attrs > power: charger-manager: Use power_supply_*() API for accessing > function attrs > > drivers/mfd/ab8500-sysctrl.c | 7 +++-- > drivers/power/88pm860x_charger.c | 13 + > drivers/power/ab8500_btemp.c | 2 +- > drivers/power/ab8500_charger.c | 2 +- > drivers/power/ab8500_fg.c | 2 +- > drivers/power/abx500_chargalg.c| 4 +-- > drivers/power/apm_power.c | 4 +-- > drivers/power/bq2415x_charger.c| 3 +- > drivers/power/charger-manager.c| 37 + > drivers/power/power_supply_core.c | 57 > -- > drivers/power/power_supply_sysfs.c | 6 ++-- > include/linux/power_supply.h | 16 +++ > 12 files changed, 115 insertions(+), 38 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
get_maintainers.pl doesn't actually get the real MAINTAINERS?
Hello, I try running scripts/get_maintainers.pl but it doesn't seem to get the real maintainers properly. Please note this is run against the current MAINTAINERS file. One Example: I would expect drivers/mmc/host/sdhci-bcm2835.c to be maintained by Stephen Warren based on drivers/*/*bcm2835* below. But the get_maintainers.pl script does not seem to process the information in such a way. So what needs to be corrected - the script or the syntax used in the MAINTAINERS file? BROADCOM BCM2835 ARM ARCHICTURE M: Stephen Warren L: linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git S: Maintained F: arch/arm/mach-bcm/board_bcm2835.c F: arch/arm/boot/dts/bcm2835* F: arch/arm/configs/bcm2835_defconfig F: drivers/*/*bcm2835* Regards, Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch/x86/purgatory/Makefile: supress kexec-purgatory.c is up to date message
On 10/14/14 at 05:52pm, Vivek Goyal wrote:
> On Tue, Oct 14, 2014 at 12:46:58PM +0800, WANG Chao wrote:
> > Supress this unnecessary message during kernel re-build
> > (CONFIG_KEXEC_FILE=y):
> >
> > make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date.
> >
> > Signed-off-by: WANG Chao
> > ---
> > arch/x86/purgatory/Makefile | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> > index f52e033..2c835e3 100644
> > --- a/arch/x86/purgatory/Makefile
> > +++ b/arch/x86/purgatory/Makefile
> > @@ -24,6 +24,7 @@ quiet_cmd_bin2c = BIN2C $@
> >
> > $(obj)/kexec-purgatory.c: $(obj)/purgatory.ro FORCE
> > $(call if_changed,bin2c)
> > + @:
>
> Where can I find the description of "@:" and how does it work?
@ is used to suppress echo'ing. See:
https://www.gnu.org/software/make/manual/html_node/Echoing.html
This is a trick to avoid "... is up to date" message". Check out commit
a9358bc ("x86/build: Supress realmode.bin is up to date message").
Thanks
WANG Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: powerpc: Fix Text randomization
On Fri, 2014-10-10 at 05:45:26 UTC, Vineeth Vijayan wrote: > Right now there is no way to disable TEXT randomization on a PPC32 > machine. text randomization happens even in the case of "echo 0 > > /proc/sys/kernel/randomize_va_space" Yeah it seems to happen on ppc64 too. > This happens due to the incorrect definition of ELF_ET_DYN_BASE at > arch/powerpc/include/asm/elf.h What is incorrect about it? We are not the only arch that does that. I'm not clear on what has changed to break this? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] scsi: add try_rc16 blacklist flag
> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Tuesday, October 14, 2014 6:08 PM > To: Sitsofe Wheeler > Cc: KY Srinivasan; Haiyang Zhang; Christoph Hellwig; Hannes Reinecke; linux- > s...@vger.kernel.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; James E.J. Bottomley > Subject: Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag > > > "Sitsofe" == Sitsofe Wheeler writes: > > Sitsofe> Microsoft Hyper-V virtual disks currently only claim SPC-2 > Sitsofe> compliance causing the kernel skip checks for features such as > Sitsofe> thin provisioning even though the virtual disk advertises them. > > Last time around we identified this as a problem with Microsoft's > interpretation of the T10 SBC spec. And they promised that they are going to > fix that. It has been fixed in windows 10 and a bug has been opened for earlier hosts. K. Y > > -- > Martin K. PetersenOracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
