Re: [PATCH] drivers/base/core.c: always output device renaming messages.
On Sat, Oct 12, 2013 at 1:26 AM, Skidmore, Donald C wrote: >> -Original Message- >> From: Greg KH [mailto:gre...@linuxfoundation.org] >> Sent: Friday, October 11, 2013 9:12 AM >> To: Bjorn Helgaas >> Cc: ethan.zhao; linux-kernel@vger.kernel.org; Skidmore, Donald C; e1000- >> de...@lists.sourceforge.net >> Subject: Re: [PATCH] drivers/base/core.c: always output device renaming >> messages. >> >> On Fri, Oct 11, 2013 at 10:08:09AM -0600, Bjorn Helgaas wrote: >> > [+cc Don, e1000-devel] >> > >> > On Fri, Oct 11, 2013 at 9:35 AM, Greg KH >> wrote: >> > > On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote: >> > >> From: "ethan.zhao" >> > >> >> > >> While loading ixgbevf driver,every vf detected will be output as >> > >> the same name 'eth4': >> > >> >> > >> ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network >> > >> Driver - version 2.8.7 Copyright (c) 2009-2012 Intel Corporation. >> > >> ixgbevf :20:10.0: enabling device ( -> 0002) ixgbe >> > >> :20:00.0 eth0: VF Reset msg received from vf 0 ixgbevf >> > >> :20:10.0: irq 199 for MSI/MSI-X ixgbevf :20:10.0: irq 200 >> > >> for MSI/MSI-X >> > >> ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue >> > >> Disabled: Rx Queue count = 1, Tx Queue count = 1 >> > > >> > > What is that message? That's not good, "eth%d"? >> > >> > Just a reminder that ixgbevf 2.8.7 is not the driver version that's in >> > the kernel tree, so it's easy to spend time on mainline issue that >> > have been fixed in the out-of-tree versions, or vice versa. >> > >> > Per Don, the latest ixgbevf driver is here: >> > https://sourceforge.net/projects/e1000/files/ixgbevf%20stable/ >> >> I hate to ask why isn't this merged upstream, but given that this is an Intel >> network driver, I know the answer :( >> >> Thanks for pointing this out, saved me a trip through the kernel tree... >> > > That message sure does look strange "eth%d"? From reading your email I'm > implying that it came from a 2.8.7 out or tree driver, is that correct? The > reason I'm asking is I want to make sure this is not an issue in the kernel > tree or the latest out of tree driver. Yes, it came from ixgbevf 2.8.7 > > Also for what it is worth I do have all the patches queued in Jeff K. tree > that gets the kernel tree and latest out of tree driver functionally in sync. > Once they pass our internal validation he should be pushing them upstream. > > Thanks for pointing out the error, > -Don Skidmore > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] AHCI: disabled FBS prior to issuing software reset
Hi, > On Sat, Sep 28, 2013 at 09:04:15PM +0800, xiangliang yu wrote: >> hi, Tejun >> i had tested the patch with Marvell 88se9235. And driver can find disk >> if FBS disabled, or can't find disk. > > So it can't find the disk if FBS stays enabled? Can you please attach > the boot log before & after? Below is boot log: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 330) ata_eh_revalidate_and_attach: dev->class = 5. ata8.15: Port Multiplier 1.2, 0x1b4b:0x9715 r160, 5 ports, feat 0x1/0x1f ahci :03:00.0: FBS is enabled ata8.00: hard resetting link ata8.00: SATA link down (SStatus 0 SControl 330) ata8.01: hard resetting link ata8.01: SATA link down (SStatus 0 SControl 330) ata8.02: hard resetting link ata8.02: SATA link down (SStatus 0 SControl 330) ata8.03: hard resetting link ata8.03: SATA link up 6.0 Gbps (SStatus 133 SControl 133) ata8.04: hard resetting link ata8.04: failed to resume link (SControl 133) ata8.04: failed to read SCR 0 (Emask=0x40) ata8.04: failed to read SCR 0 (Emask=0x40) ata8.04: failed to read SCR 1 (Emask=0x40) ata8.04: failed to read SCR 0 (Emask=0x40) ata_eh_revalidate_and_attach: dev->class = 1. ata8.03: native sectors (2) is smaller than sectors (976773168) ata8.03: ATA-8: ST3500413AS, JC4B, max UDMA/133 ata8.03: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata8.03: configured for UDMA/133 ata_eh_revalidate_and_attach: dev->class = 1. ata8.04: failed to IDENTIFY (I/O error, err_mask=0x100) ata8.15: hard resetting link ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330) ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133' ata8.15: PMP revalidation failed (errno=-19) ata8.15: hard resetting link ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330) ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133' ata8.15: PMP revalidation failed (errno=-19) ata8.15: limiting SATA link speed to 3.0 Gbps ata8.15: hard resetting link ata8.15: SATA link up 3.0 Gbps (SStatus 123 SControl 320) ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133' ata8.15: PMP revalidation failed (errno=-19) ata8.15: failed to recover PMP after 5 tries, giving up ata8.15: Port Multiplier detaching ata8.03: disabled ata8.00: disabled ata8: EH complete -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 tip/core/rcu 0/14] Sparse-related updates for 3.13
On Fri, Oct 11, 2013 at 04:16:59PM -0700, Paul E. McKenney wrote: > Changes from v2: > > o Switch from rcu_assign_pointer() to ACCESS_ONCE() given that > the pointers are all --rcu and already visible to readers, > as suggested by Eric Dumazet and Josh Triplett. Hang on a moment. Do *none* of these cases need write memory barriers? - Josh Triplet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers/base/core.c: always output device renaming messages.
On Fri, Oct 11, 2013 at 11:35 PM, Greg KH wrote:
> On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>> From: "ethan.zhao"
>>
>> While loading ixgbevf driver,every vf detected will be output as the
>> same name 'eth4':
>>
>> ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>> version 2.8.7
>> Copyright (c) 2009-2012 Intel Corporation.
>> ixgbevf :20:10.0: enabling device ( -> 0002)
>> ixgbe :20:00.0 eth0: VF Reset msg received from vf 0
>> ixgbevf :20:10.0: irq 199 for MSI/MSI-X
>> ixgbevf :20:10.0: irq 200 for MSI/MSI-X
>> ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>> count = 1, Tx Queue count = 1
>
> What is that message? That's not good, "eth%d"?
>
This message came from ixgbevf version 2.8.7, not from kernel 3.11.4,
output netdev name before registration.
>> ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>> aa:bb:cc:dd:ee:f1
>> ixgbevf: eth4: ixgbevf_probe: LRO is disabled
>> ixgbevf: eth4: ixgbevf_probe: GRO is enabled
>> ixgbevf: eth4: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>> Function Network Driver
>> ixgbevf :20:10.2: enabling device ( -> 0002)
>> ixgbe :20:00.0 eth0: VF Reset msg received from vf 1
>> ixgbevf :20:10.2: irq 201 for MSI/MSI-X
>> ixgbevf :20:10.2: irq 202 for MSI/MSI-X
>> ixgbevf: eth%d: ixgbevf_init_interrupt_scheme: Multiqueue Disabled: Rx Queue
>> count = 1, Tx Queue count = 1
>> ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>> aa:bb:cc:dd:ee:f2
>> ixgbevf: eth4: ixgbevf_probe: LRO is disabled
>> ixgbevf: eth4: ixgbevf_probe: GRO is enabled
>> ixgbevf: eth4: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>>
>> But if we view the NICs with ifconfig, found no NIC named 'eth4', the cause
>> is
>> udev has renamed the 'eth4' to 'eth10', 'eth10' one by one. because no
>> renaming
>> messages output, that is confusing.
>> So we need always output renaming messages in device_name() instead of
>> pr_debug().
>> After applied this patch, it is much clearer:
>
> How is journald tracking this today, without this extra message sent to
> the kernel log? It knows what devices are renamed to what somehow.
>
> I really don't want to clutter up the syslog for things that aren't
> needed, and as userspace was the one that told the kernel to rename the
> device, why does the kernel have to spit it back out again to userspace?
> That seems redundant, don't you think?
Yes, agree somehow , perfect system should run without any noise and
rubbish in log.
But if something wrong happened, no message shown will make us helpless.
As an user space daemon, udev, also has the reason to refuse any
message output(
you have udev tracking tools).
'redundant', yes, sometime waste and not perfect, but sometime the
backup help us more.
>
>> ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver -
>> version 2.8.7
>> Copyright (c) 2009-2012 Intel Corporation.
>> ixgbevf :20:10.0: enabling device ( -> 0002)
>> ixgbe :20:00.0 eth0: VF Reset msg received from vf 0
>> ixgbevf :20:10.0: Multiqueue Disabled: Rx Queue count = 1, Tx Queue
>> count
>> = 1
>> ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>> net eth4: 'eth4' renaming to 'eth8'
>
> A bit redundant, "eth4" shows up twice.
You hate 'redundant' , got it.
>
>> aa:bb:cc:dd:ee:11
>> ixgbevf: eth8: ixgbevf_probe: LRO is disabled
>> ixgbevf: eth8: ixgbevf_probe: GRO is enabled
>> ixgbevf: eth8: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>> Function Network Driver
>> ixgbevf :20:10.2: enabling device ( -> 0002)
>> ixgbe :20:00.0 eth0: VF Reset msg received from vf 1
>> ixgbevf :20:10.2: Multiqueue Disabled: Rx Queue count = 1, Tx Queue
>> count
>> = 1
>> ixgbevf: eth4: ixgbevf_probe: Intel(R) X540 Virtual Function
>> net eth4: 'eth4' renaming to 'eth9'
>> aa:bb:cc:dd:ee:12
>> ixgbevf: eth9: ixgbevf_probe: LRO is disabled
>> ixgbevf: eth9: ixgbevf_probe: GRO is enabled
>> ixgbevf: eth9: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual
>> Function Network Driver
>>
>> Signed-off-by: ethan.zhao
>> ---
>> drivers/base/core.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index 2d1c6ba..9a98794 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -1904,8 +1904,7 @@ int device_rename(struct device *dev, const char
>> *new_name)
>> if (!dev)
>> return -EINVAL;
>>
>> - pr_debug("device: '%s': %s: renaming to '%s'\n", dev_name(dev),
>> - __func__, new_name);
>> + dev_info(dev, "'%s' renaming to '%s'\n", dev_name(dev), new_name);
>
> How about:
> dev_dbg(dev, "renaming to '%s'\n", new_name);
If something confusing or wrong, need to take a look.
For pr_debug(), We have to build and load a debug kernel…
For dev_dbg(), We have to rebuil
Re: [PATCH v3] iio: exynos_adc: use wait_for_completion_timeout instead of interruptible
On 11 October 2013 20:00, Lars-Peter Clausen wrote:
> On 10/11/2013 10:23 AM, Naveen Krishna Chatradhi wrote:
>> This patch does the following
>> 1. use wait_for_completion_timeout instead of
>>wait_for_completion_interruptible_timeout
>> 2. Reset software if a timeout happens.
>> 3. Also reduce the timeout to 100milli secs
>
> It is always good to have a description of why a chance should be done in
> the commit message. It is obvious what the patch does by just looking at the
> changed lines, it is not that obvious though why those lines had to be
> changed.
>
>>
>> Note: submitted for review at https://patchwork.kernel.org/patch/2279591/
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>> Cc: Doug Anderson
>> Cc: Lars-Peter Clausen
>> ---
>> Changes since v1:
>> As per discussion at
>> http://marc.info/?l=linux-kernel&m=136517637228869&w=3
>>
>> This patch does the following
>> 1. use wait_for_completion_timeout instead of
>>wait_for_completion_interruptible_timeout
>> 2. Reset software if a timeout happens.
>> 3. Also reduce the timeout to 100milli secs
>>
>> Changes since v2:
>> None.
>> Rebased and reposting.
>>
>> ---
>> drivers/iio/adc/exynos_adc.c | 66
>> +++---
>> 1 file changed, 36 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index d25b262..f18ed7e 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -82,7 +82,7 @@ enum adc_version {
>> #define ADC_CON_EN_START (1u << 0)
>> #define ADC_DATX_MASK0xFFF
>>
>> -#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(1000))
>> +#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>>
>> struct exynos_adc {
>> void __iomem*regs;
>> @@ -112,6 +112,30 @@ static inline unsigned int
>> exynos_adc_get_version(struct platform_device *pdev)
>> return (unsigned int)match->data;
>> }
>>
>> +static void exynos_adc_hw_init(struct exynos_adc *info)
>> +{
>> + u32 con1, con2;
>> +
>> + if (info->version == ADC_V2) {
>> + con1 = ADC_V2_CON1_SOFT_RESET;
>> + writel(con1, ADC_V2_CON1(info->regs));
>> +
>> + con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> + ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> + writel(con2, ADC_V2_CON2(info->regs));
>> +
>> + /* Enable interrupts */
>> + writel(1, ADC_V2_INT_EN(info->regs));
>> + } else {
>> + /* set default prescaler values and Enable prescaler */
>> + con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>> +
>> + /* Enable 12-bit ADC resolution */
>> + con1 |= ADC_V1_CON_RES;
>> + writel(con1, ADC_V1_CON(info->regs));
>> + }
>> +}
>> +
>> static int exynos_read_raw(struct iio_dev *indio_dev,
>> struct iio_chan_spec const *chan,
>> int *val,
>> @@ -121,6 +145,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
>> struct exynos_adc *info = iio_priv(indio_dev);
>> unsigned long timeout;
>> u32 con1, con2;
>> + int ret;
>>
>> if (mask != IIO_CHAN_INFO_RAW)
>> return -EINVAL;
>> @@ -145,16 +170,21 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
>> ADC_V1_CON(info->regs));
>> }
>>
>> - timeout = wait_for_completion_interruptible_timeout
>> + timeout = wait_for_completion_timeout
>> (&info->completion, EXYNOS_ADC_TIMEOUT);
>
> Nitpick: It would be nice to put the &info->completion on the same line as
> the wait_for_completion...
I received a comment from Grant regarding the same.
I'm away from work this weekend. Will submit the code once i get back,
>
>> + if (timeout == 0) {
>> + dev_warn(&indio_dev->dev, "Conversion timed out reseting\n");
>> + exynos_adc_hw_init(info);
>> + ret = -ETIMEDOUT;
>> + } else {
>> + *val = info->value;
>> + ret = IIO_VAL_INT;
>> + }
>> *val = info->value;
>
> This line above should probably be removed.
Yes this is unnecessary. Will remove this.
>
>>
>> mutex_unlock(&indio_dev->mlock);
>>
>> - if (timeout == 0)
>> - return -ETIMEDOUT;
>> -
>> - return IIO_VAL_INT;
>> + return ret;
>> }
>>
>> static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
>> @@ -226,30 +256,6 @@ static int exynos_adc_remove_devices(struct device
>> *dev, void *c)
>> return 0;
>> }
>>
>> -static void exynos_adc_hw_init(struct exynos_adc *info)
>> -{
>> - u32 con1, con2;
>> -
>> - if (info->version == ADC_V2) {
>> - con1 = ADC_V2_CON1_SOFT_RESET;
>> - writel(con1, ADC_V2_CON1(info->regs));
>> -
>> - con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> - ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> - writel
Re: [PATCH] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
On 12 October 2013 11:12, Tomasz Figa wrote:
> On Saturday 12 of October 2013 04:28:51 Tomasz Figa wrote:
>> [Fixing incorrent mail addresses and dropping the old DT ML.]
>>
>> On Saturday 12 of October 2013 04:22:04 Tomasz Figa wrote:
>> > Hi Naveen,
>> >
>> > On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
>> > > The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
>> > > therefore is completely independent of the cpu frequency.
>> > > Thus, registering for a CPU freq notifier is very wasteful.
>> > >
>> > > This patch modifes the code such that, i2c bus registers to
>> > > cpu_freq_transition only for non Exynos SoCs.
>> > >
>> > > This change should save a bunch of cpufreq transitions calls
>> > > which does not apply to exynos SoCs.
>> >
>> > The idea is fine, although...
>> >
>> > > Signed-off-by: Naveen Krishna Chatradhi
>> > > ---
>> > > drivers/i2c/busses/i2c-s3c2410.c |4 ++--
>> > > 1 file changed, 2 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/drivers/i2c/busses/i2c-s3c2410.c
>> > > b/drivers/i2c/busses/i2c-s3c2410.c
>> > > index cab1c91..d062fa7 100644
>> > > --- a/drivers/i2c/busses/i2c-s3c2410.c
>> > > +++ b/drivers/i2c/busses/i2c-s3c2410.c
>> > > @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
>> > > struct s3c2410_platform_i2c *pdata;
>> > > int gpios[2];
>> > > struct pinctrl *pctrl;
>> > > -#ifdef CONFIG_CPU_FREQ
>> > > +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
>> >
>> > ...this is not a good coding practice, especially when already having
>> > multiplatform kernels in sight.
>> >
>> > The best way would be to check on which SoC we are running at runtime,
>> > but since this might need changing a lot of code, then at least I would
>> > change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
>> > compiled in when S3C24XX support is not enabled and if it's enabled then
>> > the notifier will be registered as a safe fallback that will run correctly
>> > on all platforms.
>
> Actually you can simply check for CONFIG_CPU_FREQ_S3C24XX here.
sure, this makes it more meaningful. will make the modifications and resubmit.
>
> Best regards,
> Tomasz
>
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 part2 v2 0/8] Arrange hotpluggable memory as ZONE_MOVABLE
Hello guys, this is the part2 of our memory hotplug work. This part is based on the part1: "x86, memblock: Allocate memory near kernel image before SRAT parsed" which is base on 3.12-rc4. You could refer part1 from: https://lkml.org/lkml/2013/10/10/644 Any comments are welcome! Thanks! [Problem] The current Linux cannot migrate pages used by the kerenl because of the kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET. When the pa is changed, we cannot simply update the pagetable and keep the va unmodified. So the kernel pages are not migratable. There are also some other issues will cause the kernel pages not migratable. For example, the physical address may be cached somewhere and will be used. It is not to update all the caches. When doing memory hotplug in Linux, we first migrate all the pages in one memory device somewhere else, and then remove the device. But if pages are used by the kernel, they are not migratable. As a result, memory used by the kernel cannot be hot-removed. Modifying the kernel direct mapping mechanism is too difficult to do. And it may cause the kernel performance down and unstable. So we use the following way to do memory hotplug. [What we are doing] In Linux, memory in one numa node is divided into several zones. One of the zones is ZONE_MOVABLE, which the kernel won't use. In order to implement memory hotplug in Linux, we are going to arrange all hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these memory. To do this, we need ACPI's help. [How we do this] In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The memory affinities in SRAT record every memory range in the system, and also, flags specifying if the memory range is hotpluggable. (Please refer to ACPI spec 5.0 5.2.16) With the help of SRAT, we have to do the following two things to achieve our goal: 1. When doing memory hot-add, allow the users arranging hotpluggable as ZONE_MOVABLE. (This has been done by the MOVABLE_NODE functionality in Linux.) 2. when the system is booting, prevent bootmem allocator from allocating hotpluggable memory for the kernel before the memory initialization finishes. (This is what we are going to do. See below.) [About this patch-set] In previous part's patches, we have made the kernel allocate memory near kernel image before SRAT parsed to avoid allocating hotpluggable memory for kernel. So this patch-set does the following things: 1. Improve memblock to support flags, which are used to indicate different memory type. 2. Mark all hotpluggable memory in memblock.memory[]. 3. Make the default memblock allocator skip hotpluggable memory. 4. Improve "movable_node" boot option to have higher priority of movablecore and kernelcore boot option. Change log v1 -> v2: 1. Rebase this part on the v7 version of part1 2. Fix bug: If movable_node boot option not specified, memblock still checks hotpluggable memory when allocating memory. Tang Chen (7): memblock, numa: Introduce flag into memblock memblock, mem_hotplug: Introduce MEMBLOCK_HOTPLUG flag to mark hotpluggable regions memblock: Make memblock_set_node() support different memblock_type acpi, numa, mem_hotplug: Mark hotpluggable memory in memblock acpi, numa, mem_hotplug: Mark all nodes the kernel resides un-hotpluggable memblock, mem_hotplug: Make memblock skip hotpluggable regions if needed x86, numa, acpi, memory-hotplug: Make movable_node have higher priority Yasuaki Ishimatsu (1): x86: get pg_data_t's memory from other node arch/metag/mm/init.c |3 +- arch/metag/mm/numa.c |3 +- arch/microblaze/mm/init.c |3 +- arch/powerpc/mm/mem.c |2 +- arch/powerpc/mm/numa.c|8 ++- arch/sh/kernel/setup.c|4 +- arch/sparc/mm/init_64.c |5 +- arch/x86/mm/init_32.c |2 +- arch/x86/mm/init_64.c |2 +- arch/x86/mm/numa.c| 63 +-- arch/x86/mm/srat.c|5 ++ include/linux/memblock.h | 39 ++- mm/memblock.c | 123 ++--- mm/memory_hotplug.c |1 + mm/page_alloc.c | 28 ++- 15 files changed, 252 insertions(+), 39 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/
[PULL REQUEST] i2c for 3.12
Linus, we had various reports of problems with deferred probing in the I2C subsystem, so this pull requst is a little bigger than usual. Most issues should be addressed now so devices will be found correctly. A few ususal driver bugfixes are in here, too. Please pull. Thanks, Wolfram The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to 2737de460e33df89461a59b247d3bfd477101785: i2c: i2c-mux-pinctrl: use deferred probe when adapter not found (2013-10-10 10:22:35 +0200) Ionut Nicu (2): i2c: i2c-mux-gpio: don't ignore of_get_named_gpio errors i2c: i2c-mux-gpio: use deferred probing Jean Delvare (1): i2c: Not all adapters have a parent Taras Kondratiuk (1): i2c: omap: Clear ARDY bit twice Wolfram Sang (6): i2c: i2c-designware-platdrv: replace platform_driver_probe to support deferred probing i2c: i2c-imx: replace platform_driver_probe to support deferred probing i2c: i2c-mxs: replace platform_driver_probe to support deferred probing i2c: i2c-stu300: replace platform_driver_probe to support deferred probing i2c: i2c-arb-gpio-challenge: use deferred probe when adapter not found i2c: i2c-mux-pinctrl: use deferred probe when adapter not found drivers/i2c/busses/i2c-designware-platdrv.c | 5 +++-- drivers/i2c/busses/i2c-imx.c| 11 ++- drivers/i2c/busses/i2c-mxs.c| 3 ++- drivers/i2c/busses/i2c-omap.c | 3 +++ drivers/i2c/busses/i2c-stu300.c | 11 +-- drivers/i2c/i2c-core.c | 3 +++ drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 2 +- drivers/i2c/muxes/i2c-mux-gpio.c| 14 +- drivers/i2c/muxes/i2c-mux-pinctrl.c | 4 ++-- 9 files changed, 34 insertions(+), 22 deletions(-) signature.asc Description: Digital signature
[PATCH part2 v2 1/8] x86: get pg_data_t's memory from other node
From: Yasuaki Ishimatsu
If system can create movable node which all memory of the node is allocated
as ZONE_MOVABLE, setup_node_data() cannot allocate memory for the node's
pg_data_t. So, invoke memblock_alloc_nid(...MAX_NUMNODES) again to retry when
the first allocation fails. Otherwise, the system could failed to boot.
(We don't use memblock_alloc_try_nid() to retry because in this function,
if the allocation fails, it will panic the system.)
The node_data could be on hotpluggable node. And so could pagetable and
vmemmap. But for now, doing so will break memory hot-remove path.
A node could have several memory devices. And the device who holds node
data should be hot-removed in the last place. But in NUMA level, we don't
know which memory_block (/sys/devices/system/node/nodeX/memoryXXX) belongs
to which memory device. We only have node. So we can only do node hotplug.
But in virtualization, developers are now developing memory hotplug in qemu,
which support a single memory device hotplug. So a whole node hotplug will
not satisfy virtualization users.
So at last, we concluded that we'd better do memory hotplug and local node
things (local node node data, pagetable, vmemmap, ...) in two steps.
Please refer to https://lkml.org/lkml/2013/6/19/73
For now, we put node_data of movable node to another node, and then improve
it in the future.
Signed-off-by: Yasuaki Ishimatsu
Signed-off-by: Lai Jiangshan
Signed-off-by: Tang Chen
Signed-off-by: Jiang Liu
Signed-off-by: Tang Chen
Signed-off-by: Zhang Yanfei
Reviewed-by: Wanpeng Li
Acked-by: Toshi Kani
---
arch/x86/mm/numa.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..e17db5d 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,14 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err("Cannot find %zu bytes in node %d\n",
- nd_size, nid);
- return;
+ pr_warn("Cannot find %zu bytes in node %d, so try other nodes",
+ nd_size, nid);
+ nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES,
+ MAX_NUMNODES);
+ if (!nd_pa) {
+ pr_err("Cannot find %zu bytes in any node\n", nd_size);
+ return;
+ }
}
nd = __va(nd_pa);
--
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 part2 v2 8/8] x86, numa, acpi, memory-hotplug: Make movable_node have higher priority
From: Tang Chen
If users specify the original movablecore=nn@ss boot option, the kernel will
arrange [ss, ss+nn) as ZONE_MOVABLE. The kernelcore=nn@ss boot option is similar
except it specifies ZONE_NORMAL ranges.
Now, if users specify "movable_node" in kernel commandline, the kernel will
arrange hotpluggable memory in SRAT as ZONE_MOVABLE. And if users do this, all
the other movablecore=nn@ss and kernelcore=nn@ss options should be ignored.
For those who don't want this, just specify nothing. The kernel will act as
before.
Signed-off-by: Tang Chen
Signed-off-by: Zhang Yanfei
Reviewed-by: Wanpeng Li
---
mm/page_alloc.c | 28 ++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index dd886fa..768ea0e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5021,9 +5021,33 @@ static void __init find_zone_movable_pfns_for_nodes(void)
nodemask_t saved_node_state = node_states[N_MEMORY];
unsigned long totalpages = early_calculate_totalpages();
int usable_nodes = nodes_weight(node_states[N_MEMORY]);
+ struct memblock_type *type = &memblock.memory;
+
+ /* Need to find movable_zone earlier when movable_node is specified. */
+ find_usable_zone_for_movable();
+
+ /*
+* If movable_node is specified, ignore kernelcore and movablecore
+* options.
+*/
+ if (movable_node_is_enabled()) {
+ for (i = 0; i < type->cnt; i++) {
+ if (!memblock_is_hotpluggable(&type->regions[i]))
+ continue;
+
+ nid = type->regions[i].nid;
+
+ usable_startpfn = PFN_DOWN(type->regions[i].base);
+ zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
+ min(usable_startpfn, zone_movable_pfn[nid]) :
+ usable_startpfn;
+ }
+
+ goto out2;
+ }
/*
-* If movablecore was specified, calculate what size of
+* If movablecore=nn[KMG] was specified, calculate what size of
* kernelcore that corresponds so that memory usable for
* any allocation type is evenly spread. If both kernelcore
* and movablecore are specified, then the value of kernelcore
@@ -5049,7 +5073,6 @@ static void __init find_zone_movable_pfns_for_nodes(void)
goto out;
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
- find_usable_zone_for_movable();
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
restart:
@@ -5140,6 +5163,7 @@ restart:
if (usable_nodes && required_kernelcore > usable_nodes)
goto restart;
+out2:
/* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
for (nid = 0; nid < MAX_NUMNODES; nid++)
zone_movable_pfn[nid] =
--
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 part2 v2 7/8] memblock, mem_hotplug: Make memblock skip hotpluggable regions if needed
From: Tang Chen
Linux kernel cannot migrate pages used by the kernel. As a result, hotpluggable
memory used by the kernel won't be able to be hot-removed. To solve this
problem, the basic idea is to prevent memblock from allocating hotpluggable
memory for the kernel at early time, and arrange all hotpluggable memory in
ACPI SRAT(System Resource Affinity Table) as ZONE_MOVABLE when initializing
zones.
In the previous patches, we have marked hotpluggable memory regions with
MEMBLOCK_HOTPLUG flag in memblock.memory.
In this patch, we make memblock skip these hotpluggable memory regions in
the default top-down allocation function if movable_node boot option is
specified.
Signed-off-by: Tang Chen
Signed-off-by: Zhang Yanfei
---
include/linux/memblock.h | 18 ++
mm/memblock.c| 12
mm/memory_hotplug.c |1 +
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 97480d3..bfc1dba 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -47,6 +47,10 @@ struct memblock {
extern struct memblock memblock;
extern int memblock_debug;
+#ifdef CONFIG_MOVABLE_NODE
+/* If movable_node boot option specified */
+extern bool movable_node_enabled;
+#endif /* CONFIG_MOVABLE_NODE */
#define memblock_dbg(fmt, ...) \
if (memblock_debug) printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
@@ -65,6 +69,20 @@ int memblock_reserve(phys_addr_t base, phys_addr_t size);
void memblock_trim_memory(phys_addr_t align);
int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
+#ifdef CONFIG_MOVABLE_NODE
+static inline bool memblock_is_hotpluggable(struct memblock_region *m)
+{
+ return m->flags & MEMBLOCK_HOTPLUG;
+}
+
+static inline bool movable_node_is_enabled(void)
+{
+ return movable_node_enabled;
+}
+#else
+static inline bool memblock_is_hotpluggable(struct memblock_region *m){ return
false; }
+static inline bool movable_node_is_enabled(void) { return false; }
+#endif
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
diff --git a/mm/memblock.c b/mm/memblock.c
index 7de9c76..7f69012 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -39,6 +39,9 @@ struct memblock memblock __initdata_memblock = {
};
int memblock_debug __initdata_memblock;
+#ifdef CONFIG_MOVABLE_NODE
+bool movable_node_enabled __initdata_memblock = false;
+#endif
static int memblock_can_resize __initdata_memblock;
static int memblock_memory_in_slab __initdata_memblock = 0;
static int memblock_reserved_in_slab __initdata_memblock = 0;
@@ -819,6 +822,11 @@ void __init_memblock __next_free_mem_range(u64 *idx, int
nid,
* @out_nid: ptr to int for nid of the range, can be %NULL
*
* Reverse of __next_free_mem_range().
+ *
+ * Linux kernel cannot migrate pages used by itself. Memory hotplug users won't
+ * be able to hot-remove hotpluggable memory used by the kernel. So this
+ * function skip hotpluggable regions if needed when allocating memory for the
+ * kernel.
*/
void __init_memblock __next_free_mem_range_rev(u64 *idx, int nid,
phys_addr_t *out_start,
@@ -843,6 +851,10 @@ void __init_memblock __next_free_mem_range_rev(u64 *idx,
int nid,
if (nid != MAX_NUMNODES && nid != memblock_get_region_node(m))
continue;
+ /* skip hotpluggable memory regions if needed */
+ if (movable_node_is_enabled() && memblock_is_hotpluggable(m))
+ continue;
+
/* scan areas before each reservation for intersection */
for ( ; ri >= 0; ri--) {
struct memblock_region *r = &rsv->regions[ri];
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 8c91d0a..729a2d8 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1436,6 +1436,7 @@ static int __init cmdline_parse_movable_node(char *p)
* the kernel away from hotpluggable memory.
*/
memblock_set_bottom_up(true);
+ movable_node_enabled = true;
#else
pr_warn("movable_node option not supported\n");
#endif
--
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 part2 v2 6/8] acpi, numa, mem_hotplug: Mark all nodes the kernel resides un-hotpluggable
From: Tang Chen
At very early time, the kernel have to use some memory such as
loading the kernel image. We cannot prevent this anyway. So any
node the kernel resides in should be un-hotpluggable.
Signed-off-by: Zhang Yanfei
Reviewed-by: Zhang Yanfei
---
arch/x86/mm/numa.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 408c02d..f26b16f 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -494,6 +494,14 @@ static int __init numa_register_memblks(struct
numa_meminfo *mi)
struct numa_memblk *mb = &mi->blk[i];
memblock_set_node(mb->start, mb->end - mb->start,
&memblock.memory, mb->nid);
+
+ /*
+* At this time, all memory regions reserved by memblock are
+* used by the kernel. Set the nid in memblock.reserved will
+* mark out all the nodes the kernel resides in.
+*/
+ memblock_set_node(mb->start, mb->end - mb->start,
+ &memblock.reserved, mb->nid);
}
/*
@@ -555,6 +563,30 @@ static void __init numa_init_array(void)
}
}
+static void __init numa_clear_kernel_node_hotplug(void)
+{
+ int i, nid;
+ nodemask_t numa_kernel_nodes;
+ unsigned long start, end;
+ struct memblock_type *type = &memblock.reserved;
+
+ /* Mark all kernel nodes. */
+ for (i = 0; i < type->cnt; i++)
+ node_set(type->regions[i].nid, numa_kernel_nodes);
+
+ /* Clear MEMBLOCK_HOTPLUG flag for memory in kernel nodes. */
+ for (i = 0; i < numa_meminfo.nr_blks; i++) {
+ nid = numa_meminfo.blk[i].nid;
+ if (!node_isset(nid, numa_kernel_nodes))
+ continue;
+
+ start = numa_meminfo.blk[i].start;
+ end = numa_meminfo.blk[i].end;
+
+ memblock_clear_hotplug(start, end - start);
+ }
+}
+
static int __init numa_init(int (*init_func)(void))
{
int i;
@@ -569,6 +601,8 @@ static int __init numa_init(int (*init_func)(void))
memset(&numa_meminfo, 0, sizeof(numa_meminfo));
WARN_ON(memblock_set_node(0, ULLONG_MAX, &memblock.memory,
MAX_NUMNODES));
+ WARN_ON(memblock_set_node(0, ULLONG_MAX, &memblock.reserved,
+ MAX_NUMNODES));
/* In case that parsing SRAT failed. */
WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX));
numa_reset_distance();
@@ -606,6 +640,16 @@ static int __init numa_init(int (*init_func)(void))
numa_clear_node(i);
}
numa_init_array();
+
+ /*
+* At very early time, the kernel have to use some memory such as
+* loading the kernel image. We cannot prevent this anyway. So any
+* node the kernel resides in should be un-hotpluggable.
+*
+* And when we come here, numa_init() won't fail.
+*/
+ numa_clear_kernel_node_hotplug();
+
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 part2 v2 5/8] acpi, numa, mem_hotplug: Mark hotpluggable memory in memblock
From: Tang Chen
When parsing SRAT, we know that which memory area is hotpluggable.
So we invoke function memblock_mark_hotplug() introduced by previous
patch to mark hotpluggable memory in memblock.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
arch/x86/mm/numa.c |2 ++
arch/x86/mm/srat.c |5 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index ab69e1d..408c02d 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -569,6 +569,8 @@ static int __init numa_init(int (*init_func)(void))
memset(&numa_meminfo, 0, sizeof(numa_meminfo));
WARN_ON(memblock_set_node(0, ULLONG_MAX, &memblock.memory,
MAX_NUMNODES));
+ /* In case that parsing SRAT failed. */
+ WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX));
numa_reset_distance();
ret = init_func();
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 266ca91..ca7c484 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -181,6 +181,11 @@ acpi_numa_memory_affinity_init(struct
acpi_srat_mem_affinity *ma)
(unsigned long long) start, (unsigned long long) end - 1,
hotpluggable ? " hotplug" : "");
+ /* Mark hotplug range in memblock. */
+ if (hotpluggable && memblock_mark_hotplug(start, ma->length))
+ pr_warn("SRAT: Failed to mark hotplug range [mem
%#010Lx-%#010Lx] in memblock\n",
+ (unsigned long long) start, (unsigned long long) end -
1);
+
return 0;
out_err_bad_srat:
bad_srat();
--
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 part2 v2 4/8] memblock: Make memblock_set_node() support different memblock_type
From: Tang Chen Signed-off-by: Tang Chen Reviewed-by: Zhang Yanfei --- arch/metag/mm/init.c |3 ++- arch/metag/mm/numa.c |3 ++- arch/microblaze/mm/init.c |3 ++- arch/powerpc/mm/mem.c |2 +- arch/powerpc/mm/numa.c|8 +--- arch/sh/kernel/setup.c|4 ++-- arch/sparc/mm/init_64.c |5 +++-- arch/x86/mm/init_32.c |2 +- arch/x86/mm/init_64.c |2 +- arch/x86/mm/numa.c|6 -- include/linux/memblock.h |3 ++- mm/memblock.c |6 +++--- 12 files changed, 28 insertions(+), 19 deletions(-) diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c index 1239195..d94a58f 100644 --- a/arch/metag/mm/init.c +++ b/arch/metag/mm/init.c @@ -205,7 +205,8 @@ static void __init do_init_bootmem(void) start_pfn = memblock_region_memory_base_pfn(reg); end_pfn = memblock_region_memory_end_pfn(reg); memblock_set_node(PFN_PHYS(start_pfn), - PFN_PHYS(end_pfn - start_pfn), 0); + PFN_PHYS(end_pfn - start_pfn), + &memblock.memory, 0); } /* All of system RAM sits in node 0 for the non-NUMA case */ diff --git a/arch/metag/mm/numa.c b/arch/metag/mm/numa.c index 9ae578c..229407f 100644 --- a/arch/metag/mm/numa.c +++ b/arch/metag/mm/numa.c @@ -42,7 +42,8 @@ void __init setup_bootmem_node(int nid, unsigned long start, unsigned long end) memblock_add(start, end - start); memblock_set_node(PFN_PHYS(start_pfn), - PFN_PHYS(end_pfn - start_pfn), nid); + PFN_PHYS(end_pfn - start_pfn), + &memblock.memory, nid); /* Node-local pgdat */ pgdat_paddr = memblock_alloc_base(sizeof(struct pglist_data), diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c index 74c7bcc..89077d3 100644 --- a/arch/microblaze/mm/init.c +++ b/arch/microblaze/mm/init.c @@ -192,7 +192,8 @@ void __init setup_memory(void) start_pfn = memblock_region_memory_base_pfn(reg); end_pfn = memblock_region_memory_end_pfn(reg); memblock_set_node(start_pfn << PAGE_SHIFT, - (end_pfn - start_pfn) << PAGE_SHIFT, 0); + (end_pfn - start_pfn) << PAGE_SHIFT, + &memblock.memory, 0); } /* free bootmem is whole main memory */ diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 3fa93dc..231b785 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -209,7 +209,7 @@ void __init do_init_bootmem(void) /* Place all memblock_regions in the same node and merge contiguous * memblock_regions */ - memblock_set_node(0, (phys_addr_t)ULLONG_MAX, 0); + memblock_set_node(0, (phys_addr_t)ULLONG_MAX, &memblock_memory, 0); /* Add all physical memory to the bootmem map, mark each area * present. diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index c916127..f82f2ea 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -670,7 +670,8 @@ static void __init parse_drconf_memory(struct device_node *memory) node_set_online(nid); sz = numa_enforce_memory_limit(base, size); if (sz) - memblock_set_node(base, sz, nid); + memblock_set_node(base, sz, + &memblock.memory, nid); } while (--ranges); } } @@ -760,7 +761,7 @@ new_range: continue; } - memblock_set_node(start, size, nid); + memblock_set_node(start, size, &memblock.memory, nid); if (--ranges) goto new_range; @@ -797,7 +798,8 @@ static void __init setup_nonnuma(void) fake_numa_create_new_node(end_pfn, &nid); memblock_set_node(PFN_PHYS(start_pfn), - PFN_PHYS(end_pfn - start_pfn), nid); + PFN_PHYS(end_pfn - start_pfn), + &memblock.memory, nid); node_set_online(nid); } } diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c index 1cf90e9..de19cfa 100644 --- a/arch/sh/kernel/setup.c +++ b/arch/sh/kernel/setup.c @@ -230,8 +230,8 @@ void __init __add_active_range(unsigned int nid, unsigned long start_pfn, pmb_bolt_mapping((unsigned long)__va(start), start, end - start, PAGE_KERNEL); - memblock_set_node(PFN_PHYS(start_pfn), - PFN_PHYS(end_pfn - start_pfn), nid); + memblock_set_node(PFN_PHYS(start_pfn), PFN_PHYS(end_pfn - start_pfn), + &memblock.memory, nid
[PATCH part2 v2 3/8] memblock, mem_hotplug: Introduce MEMBLOCK_HOTPLUG flag to mark hotpluggable regions
From: Tang Chen
In find_hotpluggable_memory, once we find out a memory region which is
hotpluggable, we want to mark them in memblock.memory. So that we could
control memblock allocator not to allocte hotpluggable memory for the kernel
later.
To achieve this goal, we introduce MEMBLOCK_HOTPLUG flag to indicate the
hotpluggable memory regions in memblock and a function memblock_mark_hotplug()
to mark hotpluggable memory if we find one.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
include/linux/memblock.h | 17 +++
mm/memblock.c| 52 ++
2 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 9a805ec..b788faa 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -19,6 +19,9 @@
#define INIT_MEMBLOCK_REGIONS 128
+/* Definition of memblock flags. */
+#define MEMBLOCK_HOTPLUG 0x1 /* hotpluggable region */
+
struct memblock_region {
phys_addr_t base;
phys_addr_t size;
@@ -60,6 +63,8 @@ int memblock_remove(phys_addr_t base, phys_addr_t size);
int memblock_free(phys_addr_t base, phys_addr_t size);
int memblock_reserve(phys_addr_t base, phys_addr_t size);
void memblock_trim_memory(phys_addr_t align);
+int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
+int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
@@ -122,6 +127,18 @@ void __next_free_mem_range_rev(u64 *idx, int nid,
phys_addr_t *out_start,
i != (u64)ULLONG_MAX; \
__next_free_mem_range_rev(&i, nid, p_start, p_end, p_nid))
+static inline void memblock_set_region_flags(struct memblock_region *r,
+unsigned long flags)
+{
+ r->flags |= flags;
+}
+
+static inline void memblock_clear_region_flags(struct memblock_region *r,
+ unsigned long flags)
+{
+ r->flags &= ~flags;
+}
+
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
int memblock_set_node(phys_addr_t base, phys_addr_t size, int nid);
diff --git a/mm/memblock.c b/mm/memblock.c
index 877973e..5bea331 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -683,6 +683,58 @@ int __init_memblock memblock_reserve(phys_addr_t base,
phys_addr_t size)
}
/**
+ * memblock_mark_hotplug - Mark hotpluggable memory with flag MEMBLOCK_HOTPLUG.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * This function isolates region [@base, @base + @size), and mark it with flag
+ * MEMBLOCK_HOTPLUG.
+ *
+ * Return 0 on succees, -errno on failure.
+ */
+int __init_memblock memblock_mark_hotplug(phys_addr_t base, phys_addr_t size)
+{
+ struct memblock_type *type = &memblock.memory;
+ int i, ret, start_rgn, end_rgn;
+
+ ret = memblock_isolate_range(type, base, size, &start_rgn, &end_rgn);
+ if (ret)
+ return ret;
+
+ for (i = start_rgn; i < end_rgn; i++)
+ memblock_set_region_flags(&type->regions[i], MEMBLOCK_HOTPLUG);
+
+ memblock_merge_regions(type);
+ return 0;
+}
+
+/**
+ * memblock_clear_hotplug - Clear flag MEMBLOCK_HOTPLUG for a specified region.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * This function isolates region [@base, @base + @size), and clear flag
+ * MEMBLOCK_HOTPLUG for the isolated regions.
+ *
+ * Return 0 on succees, -errno on failure.
+ */
+int __init_memblock memblock_clear_hotplug(phys_addr_t base, phys_addr_t size)
+{
+ struct memblock_type *type = &memblock.memory;
+ int i, ret, start_rgn, end_rgn;
+
+ ret = memblock_isolate_range(type, base, size, &start_rgn, &end_rgn);
+ if (ret)
+ return ret;
+
+ for (i = start_rgn; i < end_rgn; i++)
+ memblock_clear_region_flags(&type->regions[i],
MEMBLOCK_HOTPLUG);
+
+ memblock_merge_regions(type);
+ return 0;
+}
+
+/**
* __next_free_mem_range - next function for for_each_free_mem_range()
* @idx: pointer to u64 loop variable
* @nid: node selector, %MAX_NUMNODES for all nodes
--
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 part2 v2 2/8] memblock, numa: Introduce flag into memblock
From: Tang Chen
There is no flag in memblock to describe what type the memory is.
Sometimes, we may use memblock to reserve some memory for special usage.
And we want to know what kind of memory it is. So we need a way to
differentiate memory for different usage.
In hotplug environment, we want to reserve hotpluggable memory so the
kernel won't be able to use it. And when the system is up, we have to
free these hotpluggable memory to buddy. So we need to mark these memory
first.
In order to do so, we need to mark out these special memory in memblock.
In this patch, we introduce a new "flags" member into memblock_region:
struct memblock_region {
phys_addr_t base;
phys_addr_t size;
unsigned long flags; /* This is new. */
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
int nid;
#endif
};
This patch does the following things:
1) Add "flags" member to memblock_region.
2) Modify the following APIs' prototype:
memblock_add_region()
memblock_insert_region()
3) Add memblock_reserve_region() to support reserve memory with flags, and keep
memblock_reserve()'s prototype unmodified.
4) Modify other APIs to support flags, but keep their prototype unmodified.
The idea is from Wen Congyang and Liu Jiang
.
v1 -> v2:
As tj suggested, a zero flag MEMBLK_DEFAULT will make users confused. If
we want to specify any other flag, such MEMBLK_HOTPLUG, users don't know
to use MEMBLK_DEFAULT | MEMBLK_HOTPLUG or just MEMBLK_HOTPLUG. So remove
MEMBLK_DEFAULT (which is 0), and just use 0 by default to avoid confusions
to users.
Suggested-by: Wen Congyang
Suggested-by: Liu Jiang
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
include/linux/memblock.h |1 +
mm/memblock.c| 53 +-
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 77c60e5..9a805ec 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -22,6 +22,7 @@
struct memblock_region {
phys_addr_t base;
phys_addr_t size;
+ unsigned long flags;
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
int nid;
#endif
diff --git a/mm/memblock.c b/mm/memblock.c
index 53e477b..877973e 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -255,6 +255,7 @@ static void __init_memblock memblock_remove_region(struct
memblock_type *type, u
type->cnt = 1;
type->regions[0].base = 0;
type->regions[0].size = 0;
+ type->regions[0].flags = 0;
memblock_set_region_node(&type->regions[0], MAX_NUMNODES);
}
}
@@ -405,7 +406,8 @@ static void __init_memblock memblock_merge_regions(struct
memblock_type *type)
if (this->base + this->size != next->base ||
memblock_get_region_node(this) !=
- memblock_get_region_node(next)) {
+ memblock_get_region_node(next) ||
+ this->flags != next->flags) {
BUG_ON(this->base + this->size > next->base);
i++;
continue;
@@ -425,13 +427,15 @@ static void __init_memblock memblock_merge_regions(struct
memblock_type *type)
* @base: base address of the new region
* @size: size of the new region
* @nid: node id of the new region
+ * @flags: flags of the new region
*
* Insert new memblock region [@base,@base+@size) into @type at @idx.
* @type must already have extra room to accomodate the new region.
*/
static void __init_memblock memblock_insert_region(struct memblock_type *type,
int idx, phys_addr_t base,
- phys_addr_t size, int nid)
+ phys_addr_t size,
+ int nid, unsigned long flags)
{
struct memblock_region *rgn = &type->regions[idx];
@@ -439,6 +443,7 @@ static void __init_memblock memblock_insert_region(struct
memblock_type *type,
memmove(rgn + 1, rgn, (type->cnt - idx) * sizeof(*rgn));
rgn->base = base;
rgn->size = size;
+ rgn->flags = flags;
memblock_set_region_node(rgn, nid);
type->cnt++;
type->total_size += size;
@@ -450,6 +455,7 @@ static void __init_memblock memblock_insert_region(struct
memblock_type *type,
* @base: base address of the new region
* @size: size of the new region
* @nid: nid of the new region
+ * @flags: flags of the new region
*
* Add new memblock region [@base,@base+@size) into @type. The new region
* is allowed to overlap with existing ones - overlaps don't affect already
@@ -460,7 +466,8 @@ static void __init_memblock memblock_insert_region(struct
memblock_type *type,
* 0 on success, -errno on failure.
*/
static int __init_memblock memblock_add_re
Re: [PATCH v5 0/4] Fix Win8 backlight issue
On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote: > On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote: > > On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu wrote: > > > v5: > > > 1 Introduce video.use_native_backlight module parameter and set its > > > value to false by default as suggested by Rafael. For Win8 systems > > > which have broken ACPI video backlight control, the parameter can be > > > set to 1 in kernel cmdline to skip registering ACPI video's backlight > > > interface. Due to this change, the acpi_video_verify_backlight_support > > > is moved from video_detect.c to video.c - patch 3/4; > > > > That's a fairly untenable position for distro kernels to be in. They > > now have to ask every user that reports an issue with the backlight to > > try setting that option on the command line. While I appreciate the > > setting breaks things for some people, doesn't the Win8 issue impact > > far more people? Shouldn't it be defaulted to true? > > Well, we have a rule in the kernel not to introduce regressions for users even > if they are minority. Well, for some users, the regression actually happened when support for Win8 OSI call was introduced. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [PATCH v5 0/4] Fix Win8 backlight issue
On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote: > If we are to use a Kconfig option, why don't we use one instead of rather than > in addition to a command line option? Say, we have > CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like > the previous version of the Aaron's patchset (the one without > video.use_native_backlight)? Doesn't this mean user will have to rebuild distro kernel in order to test behavior? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 12/15] KVM: MMU: allow locklessly access shadow page table out of vcpu thread
On Fri, Oct 11, 2013 at 05:30:17PM -0300, Marcelo Tosatti wrote: > On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote: > > > n_max_mmu_pages is not a suitable limit to throttle freeing of pages via > > > RCU (its too large). If the free memory watermarks are smaller than > > > n_max_mmu_pages for all guests, OOM is possible. > > > > > Ah, yes. I am not saying n_max_mmu_pages will throttle RCU, just saying > > that slab size will be bound, so hopefully shrinker will touch it > > rarely. > > > > > > > > and, in addition, page released to slab is immediately > > > > > > available for allocation, no need to wait for grace period. > > > > > > > > > > See SLAB_DESTROY_BY_RCU comment at include/linux/slab.h. > > > > > > > > > This comment is exactly what I was referring to in the code you quoted. > > > > Do > > > > you see anything problematic in what comment describes? > > > > > > "This delays freeing the SLAB page by a grace period, it does _NOT_ > > > delay object freeing." The page is not available for allocation. > > By "page" I mean "spt page" which is a slab object. So "spt page" > > AKA slab object will be available fo allocation immediately. > > The object is reusable within that SLAB cache only, not the > entire system (therefore it does not prevent OOM condition). > Since object is allocatable immediately by shadow paging code the number of SLAB objects is bound by n_max_mmu_pages. If there is no enough memory for n_max_mmu_pages OOM condition can happen anyway since shadow paging code will usually have exactly n_max_mmu_pages allocated. > OK, perhaps it is useful to use SLAB_DESTROY_BY_RCU, but throttling > is still necessary, as described in the RCU documentation. > I do not see what should be throttled if we use SLAB_DESTROY_BY_RCU. RCU comes into play only when SLAB cache is shrunk and it happens far from kvm code. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
On Saturday 12 of October 2013 04:28:51 Tomasz Figa wrote:
> [Fixing incorrent mail addresses and dropping the old DT ML.]
>
> On Saturday 12 of October 2013 04:22:04 Tomasz Figa wrote:
> > Hi Naveen,
> >
> > On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
> > > The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
> > > therefore is completely independent of the cpu frequency.
> > > Thus, registering for a CPU freq notifier is very wasteful.
> > >
> > > This patch modifes the code such that, i2c bus registers to
> > > cpu_freq_transition only for non Exynos SoCs.
> > >
> > > This change should save a bunch of cpufreq transitions calls
> > > which does not apply to exynos SoCs.
> >
> > The idea is fine, although...
> >
> > > Signed-off-by: Naveen Krishna Chatradhi
> > > ---
> > > drivers/i2c/busses/i2c-s3c2410.c |4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> > > b/drivers/i2c/busses/i2c-s3c2410.c
> > > index cab1c91..d062fa7 100644
> > > --- a/drivers/i2c/busses/i2c-s3c2410.c
> > > +++ b/drivers/i2c/busses/i2c-s3c2410.c
> > > @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
> > > struct s3c2410_platform_i2c *pdata;
> > > int gpios[2];
> > > struct pinctrl *pctrl;
> > > -#ifdef CONFIG_CPU_FREQ
> > > +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
> >
> > ...this is not a good coding practice, especially when already having
> > multiplatform kernels in sight.
> >
> > The best way would be to check on which SoC we are running at runtime,
> > but since this might need changing a lot of code, then at least I would
> > change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
> > compiled in when S3C24XX support is not enabled and if it's enabled then
> > the notifier will be registered as a safe fallback that will run correctly
> > on all platforms.
Actually you can simply check for CONFIG_CPU_FREQ_S3C24XX here.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] add maintainers for low-power Intel MID platform
From: David Cohen Hi, I'd like to add official maintainers for Intel MID platform on Linux kernel. Current Intel MID support on upstream is outdated, but we've immediate plans to update the code. The 2 persons this patch is adding as maintainers are also part of Intel's internal team responsible for it. Please, consider to apply it. This patch is meant to be merged just after renaming Moorestown code to generic up-to-date Intel MID name on this patch set: http://marc.info/?l=linux-kernel&m=138154934101936&w=2 Br, David Cohen --- David Cohen (1): MAINTAINERS: INTEL MID SOC: add maintainers MAINTAINERS | 9 + 1 file changed, 9 insertions(+) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] MAINTAINERS: INTEL MID SOC: add maintainers
This patch adds official maintainers for low-power Intel MID platform. Signed-off-by: David Cohen Cc: Kuppuswamy Sathyanarayanan --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7534a80..8ef9e65 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7570,6 +7570,15 @@ F: arch/x86/platform/sfi/ F: drivers/sfi/ F: include/linux/sfi*.h +LOW-POWER INTEL MID SOC SUPPORT +M: David Cohen +M: Kuppuswamy Sathyanarayanan +S: Supported +F: arch/x86/platform/intel-mid/ +F: arch/x86/pci/intel_mid_pci.c +F: arch/x86/include/asm/intel-mid.h +F: arch/x86/include/asm/intel_mid*.h + SIMTEC EB110ATX (Chalice CATS) P: Ben Dooks P: Vincent Sanders -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: w90x900: remove deprecated IRQF_DISABLED
2013/10/12 Michael Opdenacker :
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
Acked-by: Wan zongshun
Thanks!
> ---
> arch/arm/mach-w90x900/time.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-w90x900/time.c b/arch/arm/mach-w90x900/time.c
> index 30fbca8..9230d37 100644
> --- a/arch/arm/mach-w90x900/time.c
> +++ b/arch/arm/mach-w90x900/time.c
> @@ -111,7 +111,7 @@ static irqreturn_t nuc900_timer0_interrupt(int irq, void
> *dev_id)
>
> static struct irqaction nuc900_timer0_irq = {
> .name = "nuc900-timer0",
> - .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> + .flags = IRQF_TIMER | IRQF_IRQPOLL,
> .handler= nuc900_timer0_interrupt,
> };
>
> --
> 1.8.1.2
>
--
Wan ZongShun.
www.mcuos.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] writeback: fix negative bdi max pause
Toralf runs trinity on UML/i386.
After some time it hangs and the last message line is
BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:1521]
It's found that pages_dirtied becomes very large.
More than 10 pages in this case:
period = HZ * pages_dirtied / task_ratelimit;
BUG_ON(pages_dirtied > 20);
BUG_ON(pages_dirtied > 10); <-
UML debug printf shows that we got negative pause here:
ick: pause : -984
ick: pages_dirtied : 0
ick: task_ratelimit: 0
pause:
+ if (pause < 0) {
+ extern int printf(char *, ...);
+ printf("ick : pause : %li\n", pause);
+ printf("ick: pages_dirtied : %lu\n", pages_dirtied);
+ printf("ick: task_ratelimit: %lu\n", task_ratelimit);
+ BUG_ON(1);
+ }
trace_balance_dirty_pages(bdi,
Since pause is bounded by [min_pause, max_pause] where min_pause is also
bounded by max_pause. It's suspected and demonstrated that the max_pause
calculation goes wrong:
ick: pause : -717
ick: min_pause : -177
ick: max_pause : -717
ick: pages_dirtied : 14
ick: task_ratelimit: 0
The problem lies in the two "long = unsigned long" assignments in
bdi_max_pause() which might go negative if the highest bit is 1, and
the min_t(long, ...) check failed to protect it falling under 0. Fix
all of them by using "unsigned long" throughout the function.
Reported-by: Toralf Förster
Tested-by: Toralf Förster
Cc:
Cc: Jan Kara
Cc: Richard Weinberger
Cc: Geert Uytterhoeven
Signed-off-by: Fengguang Wu
---
mm/page-writeback.c | 10 +-
mm/readahead.c |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
Changes since v1: Add CC list.
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 3f0c895..241a746 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1104,11 +1104,11 @@ static unsigned long dirty_poll_interval(unsigned long
dirty,
return 1;
}
-static long bdi_max_pause(struct backing_dev_info *bdi,
- unsigned long bdi_dirty)
+static unsigned long bdi_max_pause(struct backing_dev_info *bdi,
+ unsigned long bdi_dirty)
{
- long bw = bdi->avg_write_bandwidth;
- long t;
+ unsigned long bw = bdi->avg_write_bandwidth;
+ unsigned long t;
/*
* Limit pause time for small memory systems. If sleeping for too long
@@ -1120,7 +1120,7 @@ static long bdi_max_pause(struct backing_dev_info *bdi,
t = bdi_dirty / (1 + bw / roundup_pow_of_two(1 + HZ / 8));
t++;
- return min_t(long, t, MAX_PAUSE);
+ return min_t(unsigned long, t, MAX_PAUSE);
}
static long bdi_min_pause(struct backing_dev_info *bdi,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers: bus: omap_l3: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/bus/omap_l3_noc.c | 4 ++--
drivers/bus/omap_l3_smx.c | 6 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae..6ada27a 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -187,7 +187,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq,
l3_interrupt_handler,
- IRQF_DISABLED, "l3-dbg-irq", l3);
+ 0, "l3-dbg-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
@@ -197,7 +197,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq,
l3_interrupt_handler,
- IRQF_DISABLED, "l3-app-irq", l3);
+ 0, "l3-app-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->app_irq);
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc2164..769d64c 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -238,8 +238,7 @@ static int __init omap3_l3_probe(struct platform_device
*pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
- "l3-debug-irq", l3);
+ IRQF_TRIGGER_RISING, "l3-debug-irq", l3);
if (ret) {
dev_err(&pdev->dev, "couldn't request debug irq\n");
goto err1;
@@ -247,8 +246,7 @@ static int __init omap3_l3_probe(struct platform_device
*pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
- "l3-app-irq", l3);
+ IRQF_TRIGGER_RISING, "l3-app-irq", l3);
if (ret) {
dev_err(&pdev->dev, "couldn't request app irq\n");
goto err2;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mg_disk: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/mg_disk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
index 77a60be..7bc363f 100644
--- a/drivers/block/mg_disk.c
+++ b/drivers/block/mg_disk.c
@@ -936,7 +936,7 @@ static int mg_probe(struct platform_device *plat_dev)
goto probe_err_3b;
}
err = request_irq(host->irq, mg_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING,
MG_DEV_NAME, host);
if (err) {
printk(KERN_ERR "%s:%d fail (request_irq err=%d)\n",
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block: hd: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
This also removes a related comment which is obsolete too.
Signed-off-by: Michael Opdenacker
---
drivers/block/hd.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/block/hd.c b/drivers/block/hd.c
index bf397bf..e16985f 100644
--- a/drivers/block/hd.c
+++ b/drivers/block/hd.c
@@ -694,16 +694,6 @@ static const struct block_device_operations hd_fops = {
.getgeo = hd_getgeo,
};
-/*
- * This is the hard disk IRQ description. The IRQF_DISABLED in sa_flags
- * means we run the IRQ-handler with interrupts disabled: this is bad for
- * interrupt latency, but anything else has led to problems on some
- * machines.
- *
- * We enable interrupts in some of the routines after making sure it's
- * safe.
- */
-
static int __init hd_init(void)
{
int drive;
@@ -761,7 +751,7 @@ static int __init hd_init(void)
p->cyl, p->head, p->sect);
}
- if (request_irq(HD_IRQ, hd_interrupt, IRQF_DISABLED, "hd", NULL)) {
+ if (request_irq(HD_IRQ, hd_interrupt, 0, "hd", NULL)) {
printk("hd: unable to get IRQ%d for the hard disk driver\n",
HD_IRQ);
goto out1;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] NVMe: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/nvme-core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index da52092..c6699af 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@ -1134,11 +1134,10 @@ static int queue_request_irq(struct nvme_dev *dev,
struct nvme_queue *nvmeq,
{
if (use_threaded_interrupts)
return request_threaded_irq(dev->entry[nvmeq->cq_vector].vector,
- nvme_irq_check, nvme_irq,
- IRQF_DISABLED | IRQF_SHARED,
+ nvme_irq_check, nvme_irq, IRQF_SHARED,
name, nvmeq);
return request_irq(dev->entry[nvmeq->cq_vector].vector, nvme_irq,
- IRQF_DISABLED | IRQF_SHARED, name, nvmeq);
+ IRQF_SHARED, name, nvmeq);
}
static void nvme_init_queue(struct nvme_queue *nvmeq, u16 qid)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rsxx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/rsxx/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 6e85e21..93ecb78 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -890,7 +890,7 @@ static int rsxx_pci_probe(struct pci_dev *dev,
"Failed to enable MSI\n");
}
- st = request_irq(dev->irq, rsxx_isr, IRQF_DISABLED | IRQF_SHARED,
+ st = request_irq(dev->irq, rsxx_isr, IRQF_SHARED,
DRIVER_NAME, card);
if (st) {
dev_err(CARD_TO_DEV(card),
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpqarray: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/cpqarray.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c
index 2b94403..370721e 100644
--- a/drivers/block/cpqarray.c
+++ b/drivers/block/cpqarray.c
@@ -406,7 +406,7 @@ static int cpqarray_register_ctlr(int i, struct pci_dev
*pdev)
}
hba[i]->access.set_intr_mask(hba[i], 0);
if (request_irq(hba[i]->intr, do_ida_intr,
- IRQF_DISABLED|IRQF_SHARED, hba[i]->devname, hba[i]))
+ IRQF_SHARED, hba[i]->devname, hba[i]))
{
printk(KERN_ERR "cpqarray: Unable to get irq %d for %s\n",
hba[i]->intr, hba[i]->devname);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] support new huawei devices in option.c
Dear Greg:
>-Original Message-
>From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
>Sent: Saturday, October 12, 2013 4:58 AM
>To: Fangxiaozhi (Franko)
>Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Heyongquan;
>Wangyuhua; Yili (Neil)
>Subject: Re: [PATCH 1/1] support new huawei devices in option.c
>
>On Fri, Oct 11, 2013 at 03:48:21AM +, Fangxiaozhi (Franko) wrote:
>> 1. Add new supporting declarations to option.c, to support Huawei new
>devices with new bInterfaceSubClass value.
>> Signed-off-by: fangxiaozhi
>
>In the future, can you use an email client that doesn't turn tabs into spaces,
>so I
>don't have to edit the patch by hand?
>
>Also:
>
>> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03,
>0x01)
>> + }, { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03,
>> + 0x02) },
>
>
>
>That's a huge list of ids, is there any way we can just mark all of these as
>used by
>the device in an easier manner?
-OK, I will. Thank you very much.
>
>I'll take this for now, but I have a feeling that this list is just going to
>get worse
>over time, right?
-Yes, I think so. So we are discussing about this internally, and maybe try
to optimize it later.
>
>thanks,
>
>greg k-h
Best Regards,
Franko Fang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] score: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/score/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/score/kernel/time.c b/arch/score/kernel/time.c
index f0a43aff..24770cd 100644
--- a/arch/score/kernel/time.c
+++ b/arch/score/kernel/time.c
@@ -41,7 +41,7 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
static struct irqaction timer_irq = {
.handler = timer_interrupt,
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.name = "timer",
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] m32r: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/m32r/kernel/time.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/m32r/kernel/time.c b/arch/m32r/kernel/time.c
index 1a15f81..093f276 100644
--- a/arch/m32r/kernel/time.c
+++ b/arch/m32r/kernel/time.c
@@ -134,7 +134,6 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
static struct irqaction irq0 = {
.handler = timer_interrupt,
- .flags = IRQF_DISABLED,
.name = "MFT2",
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] avr32: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/avr32/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/avr32/kernel/time.c b/arch/avr32/kernel/time.c
index 12f828a..d0f771b 100644
--- a/arch/avr32/kernel/time.c
+++ b/arch/avr32/kernel/time.c
@@ -59,7 +59,7 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
static struct irqaction timer_irqaction = {
.handler= timer_interrupt,
/* Oprofile uses the same irq as the timer, so allow it to be shared */
- .flags = IRQF_TIMER | IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_TIMER | IRQF_SHARED,
.name = "avr32_comparator",
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: misc: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
from miscellaneous code in mach-xxx and plat-xxx
This flag is a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-ebsa110/core.c | 2 +-
arch/arm/mach-integrator/integrator_ap.c | 2 +-
arch/arm/mach-ks8695/time.c | 2 +-
arch/arm/mach-netx/time.c| 2 +-
arch/arm/mach-rpc/dma.c | 2 +-
arch/arm/mach-rpc/time.c | 1 -
arch/arm/mach-sa1100/time.c | 2 +-
arch/arm/mach-shark/core.c | 2 +-
arch/arm/mach-u300/timer.c | 2 +-
arch/arm/plat-iop/time.c | 2 +-
arch/arm/plat-pxa/dma.c | 2 +-
11 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-ebsa110/core.c b/arch/arm/mach-ebsa110/core.c
index 68ac934..8254e71 100644
--- a/arch/arm/mach-ebsa110/core.c
+++ b/arch/arm/mach-ebsa110/core.c
@@ -206,7 +206,7 @@ ebsa110_timer_interrupt(int irq, void *dev_id)
static struct irqaction ebsa110_timer_irq = {
.name = "EBSA110 Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= ebsa110_timer_interrupt,
};
diff --git a/arch/arm/mach-integrator/integrator_ap.c
b/arch/arm/mach-integrator/integrator_ap.c
index d9e95e6..b4b7683 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -368,7 +368,7 @@ static struct clock_event_device integrator_clockevent = {
static struct irqaction integrator_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= integrator_timer_interrupt,
.dev_id = &integrator_clockevent,
};
diff --git a/arch/arm/mach-ks8695/time.c b/arch/arm/mach-ks8695/time.c
index 426c976..a197874 100644
--- a/arch/arm/mach-ks8695/time.c
+++ b/arch/arm/mach-ks8695/time.c
@@ -122,7 +122,7 @@ static irqreturn_t ks8695_timer_interrupt(int irq, void
*dev_id)
static struct irqaction ks8695_timer_irq = {
.name = "ks8695_tick",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler= ks8695_timer_interrupt,
};
diff --git a/arch/arm/mach-netx/time.c b/arch/arm/mach-netx/time.c
index 6df42e6..3177c7a 100644
--- a/arch/arm/mach-netx/time.c
+++ b/arch/arm/mach-netx/time.c
@@ -99,7 +99,7 @@ netx_timer_interrupt(int irq, void *dev_id)
static struct irqaction netx_timer_irq = {
.name = "NetX Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= netx_timer_interrupt,
};
diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index 85883b2..6d3517d 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -141,7 +141,7 @@ static int iomd_request_dma(unsigned int chan, dma_t *dma)
struct iomd_dma *idma = container_of(dma, struct iomd_dma, dma);
return request_irq(idma->irq, iomd_dma_handle,
- IRQF_DISABLED, idma->dma.device_id, idma);
+ 0, idma->dma.device_id, idma);
}
static void iomd_free_dma(unsigned int chan, dma_t *dma)
diff --git a/arch/arm/mach-rpc/time.c b/arch/arm/mach-rpc/time.c
index 9a6def1..9a51588 100644
--- a/arch/arm/mach-rpc/time.c
+++ b/arch/arm/mach-rpc/time.c
@@ -75,7 +75,6 @@ ioc_timer_interrupt(int irq, void *dev_id)
static struct irqaction ioc_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED,
.handler= ioc_timer_interrupt
};
diff --git a/arch/arm/mach-sa1100/time.c b/arch/arm/mach-sa1100/time.c
index 713c86c..a98fded 100644
--- a/arch/arm/mach-sa1100/time.c
+++ b/arch/arm/mach-sa1100/time.c
@@ -112,7 +112,7 @@ static struct clock_event_device ckevt_sa1100_osmr0 = {
static struct irqaction sa1100_timer_irq = {
.name = "ost0",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= sa1100_ost0_interrupt,
.dev_id = &ckevt_sa1100_osmr0,
};
diff --git a/arch/arm/mach-shark/core.c b/arch/arm/mach-shark/core.c
index 1d32c5e..78942cd 100644
--- a/arch/arm/mach-shark/core.c
+++ b/arch/arm/mach-shark/core.c
@@ -114,7 +114,7 @@ shark_timer_interrupt(int irq, void *dev_id)
static struct irqaction shark_timer_irq = {
.name = "Shark Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= shark_timer_interrupt,
};
diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index b5db
[PATCH] arm: plat-orion: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/plat-orion/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-orion/time.c b/arch/arm/plat-orion/time.c
index 9d2b2ac..df671d0 100644
--- a/arch/arm/plat-orion/time.c
+++ b/arch/arm/plat-orion/time.c
@@ -174,7 +174,7 @@ static irqreturn_t orion_timer_interrupt(int irq, void
*dev_id)
static struct irqaction orion_timer_irq = {
.name = "orion_tick",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler= orion_timer_interrupt
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: w90x900: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-w90x900/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-w90x900/time.c b/arch/arm/mach-w90x900/time.c
index 30fbca8..9230d37 100644
--- a/arch/arm/mach-w90x900/time.c
+++ b/arch/arm/mach-w90x900/time.c
@@ -111,7 +111,7 @@ static irqreturn_t nuc900_timer0_interrupt(int irq, void
*dev_id)
static struct irqaction nuc900_timer0_irq = {
.name = "nuc900-timer0",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= nuc900_timer0_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/10] intel_mid: Renamed *mrst* to *intel_mid*
From: Kuppuswamy Sathyanarayanan
mrst is used as common name to represent all intel_mid type
soc's. But moorsetwon is just one of the intel_mid soc. So
renamed them to use intel_mid.
This patch mainly renames the variables and related
functions that uses *mrst* prefix with *intel_mid*.
To ensure that there are no functional changes, I have compared
the objdump of related files before and after rename and found
the only difference is symbol and name changes.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
Documentation/kernel-parameters.txt| 6 +-
arch/x86/include/asm/intel-mid.h | 26 ++---
arch/x86/include/asm/setup.h | 4 +-
arch/x86/include/uapi/asm/bootparam.h | 2 +-
arch/x86/kernel/apb_timer.c| 8 +-
arch/x86/kernel/head32.c | 4 +-
arch/x86/kernel/rtc.c | 2 +-
arch/x86/pci/intel_mid_pci.c | 12 +--
.../platform/intel-mid/early_printk_intel_mid.c| 2 +-
arch/x86/platform/intel-mid/intel-mid.c| 109 ++---
arch/x86/platform/intel-mid/intel_mid_vrtc.c | 8 +-
drivers/platform/x86/intel_scu_ipc.c | 2 +-
drivers/watchdog/intel_scu_watchdog.c | 2 +-
13 files changed, 93 insertions(+), 94 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index fcbb736..dfaeb0c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3471,11 +3471,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
default x2apic cluster mode on platforms
supporting x2apic.
- x86_mrst_timer= [X86-32,APBT]
- Choose timer option for x86 Moorestown MID platform.
+ x86_intel_mid_timer= [X86-32,APBT]
+ Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
- x86_mrst_timer=apbt_only | lapic_and_apbt
+ x86_intel_mid_timer=apbt_only | lapic_and_apbt
xen_emul_unplug=[HW,X86,XEN]
Unplug Xen emulated devices
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index cc79a4f..beb7a5f 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -13,7 +13,7 @@
#include
-extern int pci_mrst_init(void);
+extern int intel_mid_pci_init(void);
extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
extern int sfi_mrtc_num;
extern struct sfi_rtc_table_entry sfi_mrtc_array[];
@@ -25,33 +25,33 @@ extern struct sfi_rtc_table_entry sfi_mrtc_array[];
* we treat Medfield/Penwell as a variant of Moorestown. Penwell can be
* identified via MSRs.
*/
-enum mrst_cpu_type {
+enum intel_mid_cpu_type {
/* 1 was Moorestown */
- MRST_CPU_CHIP_PENWELL = 2,
+ INTEL_MID_CPU_CHIP_PENWELL = 2,
};
-extern enum mrst_cpu_type __mrst_cpu_chip;
+extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
#ifdef CONFIG_X86_INTEL_MID
-static inline enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
{
- return __mrst_cpu_chip;
+ return __intel_mid_cpu_chip;
}
#else /* !CONFIG_X86_INTEL_MID */
-#define mrst_identify_cpu()(0)
+#define intel_mid_identify_cpu()(0)
#endif /* !CONFIG_X86_INTEL_MID */
-enum mrst_timer_options {
- MRST_TIMER_DEFAULT,
- MRST_TIMER_APBT_ONLY,
- MRST_TIMER_LAPIC_APBT,
+enum intel_mid_timer_options {
+ INTEL_MID_TIMER_DEFAULT,
+ INTEL_MID_TIMER_APBT_ONLY,
+ INTEL_MID_TIMER_LAPIC_APBT,
};
-extern enum mrst_timer_options mrst_timer_options;
+extern enum intel_mid_timer_options intel_mid_timer_options;
/*
* Penwell uses spread spectrum clock, so the freq number is not exactly
@@ -76,6 +76,6 @@ extern void intel_scu_devices_destroy(void);
#define MRST_VRTC_MAP_SZ (1024)
/*#define MRST_VRTC_PGOFFSET (0xc00) */
-extern void mrst_rtc_init(void);
+extern void intel_mid_rtc_init(void);
#endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 3475554..59bcf4e 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -51,9 +51,9 @@ extern void i386_reserve_resources(void);
extern void setup_default_timer_irq(void);
#ifdef CONFIG_X86_INTEL_MID
-extern void x86_mrst_early_setup(void);
+extern void x86_intel_mid_early_setup(void);
#else
-static inline void x86_mrst_early_setup(void) { }
+static inline void x86_intel_mid_early_setup(void) { }
#endif
#ifdef CONFIG_X86_INTEL_CE
diff --git a/arch/x86/include/uapi/asm/boo
[PATCH v3 00/10] rework arch/x86/platform/[mrst => intel-mid]
This patch set does initial rework from arch/x86/platform/mrst to
arch/x86/platform/intel-mid.
These changes are necessary to update the obsolete Intel Atom Moorestown code
to support the newer Atom processors of this family (called 'intel-mid').
Kuppuswamy Sathyanarayanan (10):
mrst: Fixed printk/pr_* related issues
mrst: Fixed indentation issues
mrst: Fixed checkpatch warnings
intel_mid: Renamed *mrst* to *intel_mid*
intel_mid: Renamed *mrst* to *intel_mid*
intel_mid: Refactored sfi_parse_devs() function
intel_mid: Added custom device_handler support
intel_mid: Added custom handler for ipc devices
intel_mid: Moved board related code to a new file
intel_mid: Moved SFI related code to intel_mid_sfi.c
Documentation/kernel-parameters.txt|6 +-
arch/x86/include/asm/{mrst.h => intel-mid.h} | 62 +-
.../include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} |4 +-
arch/x86/include/asm/setup.h |4 +-
arch/x86/include/uapi/asm/bootparam.h |2 +-
arch/x86/kernel/apb_timer.c| 10 +-
arch/x86/kernel/early_printk.c |2 +-
arch/x86/kernel/head32.c |4 +-
arch/x86/kernel/rtc.c |4 +-
arch/x86/pci/Makefile |2 +-
arch/x86/pci/{mrst.c => intel_mid_pci.c} | 14 +-
arch/x86/platform/Makefile |2 +-
arch/x86/platform/intel-mid/Makefile |9 +
arch/x86/platform/intel-mid/board.c| 109 ++
arch/x86/platform/intel-mid/device_libs/Makefile | 21 +
.../intel-mid/device_libs/platform_emc1403.c | 33 +
.../intel-mid/device_libs/platform_emc1403.h | 16 +
.../intel-mid/device_libs/platform_gpio_keys.c | 82 ++
.../intel-mid/device_libs/platform_gpio_keys.h | 16 +
.../platform/intel-mid/device_libs/platform_ipc.c | 59 ++
.../platform/intel-mid/device_libs/platform_ipc.h | 17 +
.../intel-mid/device_libs/platform_lis331.c| 32 +
.../intel-mid/device_libs/platform_lis331.h| 16 +
.../intel-mid/device_libs/platform_max3111.c | 28 +
.../intel-mid/device_libs/platform_max3111.h | 16 +
.../intel-mid/device_libs/platform_max7315.c | 62 ++
.../intel-mid/device_libs/platform_max7315.h | 19 +
.../intel-mid/device_libs/platform_mpu3050.c | 28 +
.../intel-mid/device_libs/platform_mpu3050.h | 16 +
.../platform/intel-mid/device_libs/platform_msic.c | 87 ++
.../platform/intel-mid/device_libs/platform_msic.h | 19 +
.../intel-mid/device_libs/platform_msic_audio.c| 36 +
.../intel-mid/device_libs/platform_msic_audio.h| 16 +
.../intel-mid/device_libs/platform_msic_battery.c | 26 +
.../intel-mid/device_libs/platform_msic_battery.h | 17 +
.../intel-mid/device_libs/platform_msic_gpio.c | 37 +
.../intel-mid/device_libs/platform_msic_gpio.h | 16 +
.../intel-mid/device_libs/platform_msic_ocd.c | 39 +
.../intel-mid/device_libs/platform_msic_ocd.h | 16 +
.../device_libs/platform_msic_power_btn.c | 25 +
.../device_libs/platform_msic_power_btn.h | 17 +
.../intel-mid/device_libs/platform_msic_thermal.c | 26 +
.../intel-mid/device_libs/platform_msic_thermal.h | 17 +
.../intel-mid/device_libs/platform_pmic_gpio.c | 36 +
.../intel-mid/device_libs/platform_pmic_gpio.h | 16 +
.../intel-mid/device_libs/platform_tc35876x.c | 29 +
.../intel-mid/device_libs/platform_tc35876x.h | 16 +
.../intel-mid/device_libs/platform_tca6416.c | 45 +
.../intel-mid/device_libs/platform_tca6416.h | 20 +
.../early_printk_intel_mid.c} | 11 +-
arch/x86/platform/intel-mid/intel-mid.c| 213
arch/x86/platform/intel-mid/intel_mid_sfi.c| 485 +
.../{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c}| 19 +-
arch/x86/platform/intel-mid/intel_mid_weak_decls.h | 15 +
arch/x86/platform/mrst/Makefile|3 -
arch/x86/platform/mrst/mrst.c | 1052
drivers/gpu/drm/gma500/mdfld_dsi_output.h |2 +-
drivers/gpu/drm/gma500/oaktrail_device.c |2 +-
drivers/gpu/drm/gma500/oaktrail_lvds.c |2 +-
drivers/platform/x86/intel_scu_ipc.c |4 +-
drivers/rtc/rtc-mrst.c |4 +-
drivers/watchdog/intel_scu_watchdog.c |4 +-
62 files changed, 1944 insertions(+), 1123 deletions(-)
rename arch/x86/include/asm/{mrst.h => intel-mid.h} (50%)
rename arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} (81%)
rename arch/x86/pci/{mrst.c => intel_mid_pci.c} (96%)
create mode 100644 arch/x86/platform/intel-mid/Makefile
create mode 100644 arch/x86/platform/intel-mid/board.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile
create
[PATCH v3 02/10] mrst: Fixed indentation issues
From: Kuppuswamy Sathyanarayanan
Fixed indentation issues reported by checkpatch script in
mrst related files.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/mrst/early_printk_mrst.c | 3 ++-
arch/x86/platform/mrst/mrst.c | 24 +---
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/arch/x86/platform/mrst/early_printk_mrst.c
b/arch/x86/platform/mrst/early_printk_mrst.c
index 95880f7..39ecc27 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -219,7 +219,8 @@ static void early_mrst_spi_putc(char c)
}
/* Early SPI only uses polling mode */
-static void early_mrst_spi_write(struct console *con, const char *str,
unsigned n)
+static void early_mrst_spi_write(struct console *con, const char *str,
+ unsigned n)
{
int i;
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index b9aeb54..235a742 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -131,7 +131,7 @@ struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
int i;
if (hint < sfi_mtimer_num) {
if (!sfi_mtimer_usage[hint]) {
- pr_debug("hint taken for timer %d irq %d\n",\
+ pr_debug("hint taken for timer %d irq %d\n",
hint, sfi_mtimer_array[hint].irq);
sfi_mtimer_usage[hint] = 1;
return &sfi_mtimer_array[hint];
@@ -679,14 +679,14 @@ static void *msic_thermal_platform_data(void *info)
/* tc35876x DSI-LVDS bridge chip and panel platform data */
static void *tc35876x_platform_data(void *data)
{
- static struct tc35876x_platform_data pdata;
+ static struct tc35876x_platform_data pdata;
- /* gpio pins set to -1 will not be used by the driver */
- pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
- pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
- pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
+ /* gpio pins set to -1 will not be used by the driver */
+ pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
+ pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
+ pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
- return &pdata;
+ return &pdata;
}
static const struct devs_id __initconst device_ids[] = {
@@ -729,7 +729,7 @@ static int i2c_next_dev;
static void __init intel_scu_device_register(struct platform_device *pdev)
{
- if(ipc_next_dev == MAX_IPCDEVS)
+ if (ipc_next_dev == MAX_IPCDEVS)
pr_err("too many SCU IPC devices");
else
ipc_devs[ipc_next_dev++] = pdev;
@@ -872,7 +872,8 @@ static void __init sfi_handle_spi_dev(struct spi_board_info
*spi_info)
while (dev->name[0]) {
if (dev->type == SFI_DEV_TYPE_SPI &&
- !strncmp(dev->name, spi_info->modalias,
SFI_NAME_LEN)) {
+ !strncmp(dev->name, spi_info->modalias,
+ SFI_NAME_LEN)) {
pdata = dev->get_platform_data(spi_info);
break;
}
@@ -904,7 +905,7 @@ static void __init sfi_handle_i2c_dev(int bus, struct
i2c_board_info *i2c_info)
intel_scu_i2c_device_register(bus, i2c_info);
else
i2c_register_board_info(bus, i2c_info, 1);
- }
+}
static int __init sfi_parse_devs(struct sfi_table_header *table)
@@ -1034,7 +1035,8 @@ static int __init pb_keys_init(void)
num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
for (i = 0; i < num; i++) {
gb[i].gpio = get_gpio_by_name(gb[i].desc);
- pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
gb[i].gpio);
+ pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
+ gb[i].gpio);
if (gb[i].gpio == -1)
continue;
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 07/10] intel_mid: Added custom device_handler support
From: Kuppuswamy Sathyanarayanan
This patch provides a means to add custom handler for
SFI devices. If you set device_handler as NULL in
device_id table standard SFI device handler will be used.
If its not NULL custom handler will be called.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/intel-mid/intel-mid.c | 75 ++---
1 file changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index f9c4be8..65c7bca 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -396,6 +396,9 @@ struct devs_id {
u8 type;
u8 delay;
void *(*get_platform_data)(void *info);
+ /* Custom handler for devices */
+ void (*device_handler)(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev);
};
/* the offset for the mapping of global gpio pin to irq */
@@ -690,27 +693,29 @@ static void *tc35876x_platform_data(void *data)
}
static const struct devs_id __initconst device_ids[] = {
- {"bma023", SFI_DEV_TYPE_I2C, 1, &no_platform_data},
- {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, &pmic_gpio_platform_data},
- {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, &pmic_gpio_platform_data},
- {"spi_max3111", SFI_DEV_TYPE_SPI, 0, &max3111_platform_data},
- {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, &max7315_platform_data},
- {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, &max7315_platform_data},
- {"tca6416", SFI_DEV_TYPE_I2C, 1, &tca6416_platform_data},
- {"emc1403", SFI_DEV_TYPE_I2C, 1, &emc1403_platform_data},
- {"i2c_accel", SFI_DEV_TYPE_I2C, 0, &lis331dl_platform_data},
- {"pmic_audio", SFI_DEV_TYPE_IPC, 1, &no_platform_data},
- {"mpu3050", SFI_DEV_TYPE_I2C, 1, &mpu3050_platform_data},
- {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, &tc35876x_platform_data},
+ {"bma023", SFI_DEV_TYPE_I2C, 1, &no_platform_data, NULL},
+ {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, &pmic_gpio_platform_data, NULL},
+ {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, &pmic_gpio_platform_data, NULL},
+ {"spi_max3111", SFI_DEV_TYPE_SPI, 0, &max3111_platform_data, NULL},
+ {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, &max7315_platform_data, NULL},
+ {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, &max7315_platform_data, NULL},
+ {"tca6416", SFI_DEV_TYPE_I2C, 1, &tca6416_platform_data, NULL},
+ {"emc1403", SFI_DEV_TYPE_I2C, 1, &emc1403_platform_data, NULL},
+ {"i2c_accel", SFI_DEV_TYPE_I2C, 0, &lis331dl_platform_data, NULL},
+ {"pmic_audio", SFI_DEV_TYPE_IPC, 1, &no_platform_data, NULL},
+ {"mpu3050", SFI_DEV_TYPE_I2C, 1, &mpu3050_platform_data, NULL},
+ {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, &tc35876x_platform_data, NULL},
/* MSIC subdevices */
- {"msic_battery", SFI_DEV_TYPE_IPC, 1, &msic_battery_platform_data},
- {"msic_gpio", SFI_DEV_TYPE_IPC, 1, &msic_gpio_platform_data},
- {"msic_audio", SFI_DEV_TYPE_IPC, 1, &msic_audio_platform_data},
- {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, &msic_power_btn_platform_data},
- {"msic_ocd", SFI_DEV_TYPE_IPC, 1, &msic_ocd_platform_data},
- {"msic_thermal", SFI_DEV_TYPE_IPC, 1, &msic_thermal_platform_data},
-
+ {"msic_battery", SFI_DEV_TYPE_IPC, 1, &msic_battery_platform_data,
+ NULL},
+ {"msic_gpio", SFI_DEV_TYPE_IPC, 1, &msic_gpio_platform_data, NULL},
+ {"msic_audio", SFI_DEV_TYPE_IPC, 1, &msic_audio_platform_data, NULL},
+ {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, &msic_power_btn_platform_data,
+ NULL},
+ {"msic_ocd", SFI_DEV_TYPE_IPC, 1, &msic_ocd_platform_data, NULL},
+ {"msic_thermal", SFI_DEV_TYPE_IPC, 1, &msic_thermal_platform_data,
+ NULL},
{},
};
@@ -965,20 +970,24 @@ static int __init sfi_parse_devs(struct sfi_table_header
*table)
if ((dev == NULL) || (dev->get_platform_data == NULL))
continue;
- switch (pentry->type) {
- case SFI_DEV_TYPE_IPC:
- sfi_handle_ipc_dev(pentry, dev);
- break;
- case SFI_DEV_TYPE_SPI:
- sfi_handle_spi_dev(pentry, dev);
- break;
- case SFI_DEV_TYPE_I2C:
- sfi_handle_i2c_dev(pentry, dev);
- break;
- case SFI_DEV_TYPE_UART:
- case SFI_DEV_TYPE_HSI:
- default:
- break;
+ if (dev->device_handler) {
+ dev->device_handler(pentry, dev);
+ } else {
+ switch (pentry->type) {
+ case SFI_DEV_TYPE_IPC:
+ sfi_handle_ipc_dev(pentry, dev);
+
[PATCH v3 01/10] mrst: Fixed printk/pr_* related issues
From: Kuppuswamy Sathyanarayanan
Fixed printk and pr_* related issues in mrst related files.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/mrst/early_printk_mrst.c | 2 +-
arch/x86/platform/mrst/mrst.c | 2 +-
arch/x86/platform/mrst/vrtc.c | 5 ++---
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/platform/mrst/early_printk_mrst.c
b/arch/x86/platform/mrst/early_printk_mrst.c
index 028454f..95880f7 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -213,7 +213,7 @@ static void early_mrst_spi_putc(char c)
}
if (!timeout)
- pr_warning("MRST earlycon: timed out\n");
+ pr_warn("MRST earlycon: timed out\n");
else
max3110_write_data(c);
}
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 3ca5957..b9aeb54 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -328,7 +328,7 @@ static inline int __init setup_x86_mrst_timer(char *arg)
else if (strcmp("lapic_and_apbt", arg) == 0)
mrst_timer_options = MRST_TIMER_LAPIC_APBT;
else {
- pr_warning("X86 MRST timer option %s not recognised"
+ pr_warn("X86 MRST timer option %s not recognised"
" use x86_mrst_timer=apbt_only or lapic_and_apbt\n",
arg);
return -EINVAL;
diff --git a/arch/x86/platform/mrst/vrtc.c b/arch/x86/platform/mrst/vrtc.c
index 5e355b1..ca4f7d9 100644
--- a/arch/x86/platform/mrst/vrtc.c
+++ b/arch/x86/platform/mrst/vrtc.c
@@ -79,7 +79,7 @@ void vrtc_get_time(struct timespec *now)
/* vRTC YEAR reg contains the offset to 1972 */
year += 1972;
- printk(KERN_INFO "vRTC: sec: %d min: %d hour: %d day: %d "
+ pr_info("vRTC: sec: %d min: %d hour: %d day: %d "
"mon: %d year: %d\n", sec, min, hour, mday, mon, year);
now->tv_sec = mktime(year, mon, mday, hour, min, sec);
@@ -109,8 +109,7 @@ int vrtc_set_mmss(const struct timespec *now)
vrtc_cmos_write(tm.tm_sec, RTC_SECONDS);
spin_unlock_irqrestore(&rtc_lock, flags);
} else {
- printk(KERN_ERR
- "%s: Invalid vRTC value: write of %lx to vRTC failed\n",
+ pr_err("%s: Invalid vRTC value: write of %lx to vRTC failed\n",
__FUNCTION__, now->tv_sec);
retval = -EINVAL;
}
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: spear: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-spear/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-spear/time.c b/arch/arm/mach-spear/time.c
index d449673..218ba5b 100644
--- a/arch/arm/mach-spear/time.c
+++ b/arch/arm/mach-spear/time.c
@@ -172,7 +172,7 @@ static irqreturn_t spear_timer_interrupt(int irq, void
*dev_id)
static struct irqaction spear_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = spear_timer_interrupt
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 08/10] intel_mid: Added custom handler for ipc devices
From: Kuppuswamy Sathyanarayanan
Added a custom handler for medfield based ipc devices and
moved devs_id structure defintion to header file.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/include/asm/intel-mid.h| 15 ++
arch/x86/platform/intel-mid/intel-mid.c | 87 +
2 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index beb7a5f..ad236ae 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -19,6 +19,21 @@ extern int sfi_mrtc_num;
extern struct sfi_rtc_table_entry sfi_mrtc_array[];
/*
+ * Here defines the array of devices platform data that IAFW would export
+ * through SFI "DEVS" table, we use name and type to match the device and
+ * its platform data.
+ */
+struct devs_id {
+ char name[SFI_NAME_LEN + 1];
+ u8 type;
+ u8 delay;
+ void *(*get_platform_data)(void *info);
+ /* Custom handler for devices */
+ void (*device_handler)(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev);
+};
+
+/*
* Medfield is the follow-up of Moorestown, it combines two chip solution into
* one. Other than that it also added always-on and constant tsc and lapic
* timers. Medfield is the platform name, and the chip name is called Penwell
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 65c7bca..3a210d9 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -78,6 +78,8 @@ int sfi_mtimer_num;
struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
EXPORT_SYMBOL_GPL(sfi_mrtc_array);
int sfi_mrtc_num;
+static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev);
static void intel_mid_power_off(void)
{
@@ -386,21 +388,6 @@ static int get_gpio_by_name(const char *name)
return -1;
}
-/*
- * Here defines the array of devices platform data that IAFW would export
- * through SFI "DEVS" table, we use name and type to match the device and
- * its platform data.
- */
-struct devs_id {
- char name[SFI_NAME_LEN + 1];
- u8 type;
- u8 delay;
- void *(*get_platform_data)(void *info);
- /* Custom handler for devices */
- void (*device_handler)(struct sfi_device_table_entry *pentry,
- struct devs_id *dev);
-};
-
/* the offset for the mapping of global gpio pin to irq */
#define INTEL_MID_IRQ_OFFSET 0x100
@@ -695,27 +682,32 @@ static void *tc35876x_platform_data(void *data)
static const struct devs_id __initconst device_ids[] = {
{"bma023", SFI_DEV_TYPE_I2C, 1, &no_platform_data, NULL},
{"pmic_gpio", SFI_DEV_TYPE_SPI, 1, &pmic_gpio_platform_data, NULL},
- {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, &pmic_gpio_platform_data, NULL},
+ {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, &pmic_gpio_platform_data,
+ &ipc_device_handler},
{"spi_max3111", SFI_DEV_TYPE_SPI, 0, &max3111_platform_data, NULL},
{"i2c_max7315", SFI_DEV_TYPE_I2C, 1, &max7315_platform_data, NULL},
{"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, &max7315_platform_data, NULL},
{"tca6416", SFI_DEV_TYPE_I2C, 1, &tca6416_platform_data, NULL},
{"emc1403", SFI_DEV_TYPE_I2C, 1, &emc1403_platform_data, NULL},
{"i2c_accel", SFI_DEV_TYPE_I2C, 0, &lis331dl_platform_data, NULL},
- {"pmic_audio", SFI_DEV_TYPE_IPC, 1, &no_platform_data, NULL},
+ {"pmic_audio", SFI_DEV_TYPE_IPC, 1, &no_platform_data,
+ &ipc_device_handler},
{"mpu3050", SFI_DEV_TYPE_I2C, 1, &mpu3050_platform_data, NULL},
{"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, &tc35876x_platform_data, NULL},
/* MSIC subdevices */
{"msic_battery", SFI_DEV_TYPE_IPC, 1, &msic_battery_platform_data,
- NULL},
- {"msic_gpio", SFI_DEV_TYPE_IPC, 1, &msic_gpio_platform_data, NULL},
- {"msic_audio", SFI_DEV_TYPE_IPC, 1, &msic_audio_platform_data, NULL},
+ &ipc_device_handler},
+ {"msic_gpio", SFI_DEV_TYPE_IPC, 1, &msic_gpio_platform_data,
+ &ipc_device_handler},
+ {"msic_audio", SFI_DEV_TYPE_IPC, 1, &msic_audio_platform_data,
+ &ipc_device_handler},
{"msic_power_btn", SFI_DEV_TYPE_IPC, 1, &msic_power_btn_platform_data,
- NULL},
- {"msic_ocd", SFI_DEV_TYPE_IPC, 1, &msic_ocd_platform_data, NULL},
+ &ipc_device_handler},
+ {"msic_ocd", SFI_DEV_TYPE_IPC, 1, &msic_ocd_platform_data,
+ &ipc_device_handler},
{"msic_thermal", SFI_DEV_TYPE_IPC, 1, &msic_thermal_p
[PATCH v3 04/10] intel_mid: Renamed *mrst* to *intel_mid*
From: Kuppuswamy Sathyanarayanan
Following files contains code that is common to all intel mid
soc's. So renamed them as below.
mrst/mrst.c -> intel-mid/intel-mid.c
mrst/vrtc.c -> intel-mid/intel_mid_vrtc.c
mrst/early_printk_mrst.c -> intel-mid/intel_mid_vrtc.c
pci/mrst.c -> pci/intel_mid_pci.c
Also, renamed the corresponding header files and made changes
to the driver files that included these header files.
To ensure that there are no functional changes, I have compared
the objdump of renamed files before and after rename and found
that the only difference is file name change.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/include/asm/{mrst.h => intel-mid.h} | 8
arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h}| 4 ++--
arch/x86/kernel/apb_timer.c | 2 +-
arch/x86/kernel/early_printk.c| 2 +-
arch/x86/kernel/rtc.c | 2 +-
arch/x86/pci/Makefile | 2 +-
arch/x86/pci/{mrst.c => intel_mid_pci.c} | 2 +-
arch/x86/platform/Makefile| 2 +-
arch/x86/platform/intel-mid/Makefile | 3 +++
.../early_printk_intel_mid.c} | 4 ++--
arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c} | 11 ++-
arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} | 6 +++---
arch/x86/platform/mrst/Makefile | 3 ---
drivers/gpu/drm/gma500/mdfld_dsi_output.h | 2 +-
drivers/gpu/drm/gma500/oaktrail_device.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_lvds.c| 2 +-
drivers/platform/x86/intel_scu_ipc.c | 2 +-
drivers/rtc/rtc-mrst.c| 4 ++--
drivers/watchdog/intel_scu_watchdog.c | 2 +-
19 files changed, 33 insertions(+), 32 deletions(-)
rename arch/x86/include/asm/{mrst.h => intel-mid.h} (93%)
rename arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} (81%)
rename arch/x86/pci/{mrst.c => intel_mid_pci.c} (99%)
create mode 100644 arch/x86/platform/intel-mid/Makefile
rename arch/x86/platform/{mrst/early_printk_mrst.c =>
intel-mid/early_printk_intel_mid.c} (98%)
rename arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c} (99%)
rename arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} (97%)
delete mode 100644 arch/x86/platform/mrst/Makefile
diff --git a/arch/x86/include/asm/mrst.h b/arch/x86/include/asm/intel-mid.h
similarity index 93%
rename from arch/x86/include/asm/mrst.h
rename to arch/x86/include/asm/intel-mid.h
index fc18bf3..cc79a4f 100644
--- a/arch/x86/include/asm/mrst.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -1,5 +1,5 @@
/*
- * mrst.h: Intel Moorestown platform specific setup code
+ * intel-mid.h: Intel MID specific setup code
*
* (C) Copyright 2009 Intel Corporation
*
@@ -8,8 +8,8 @@
* as published by the Free Software Foundation; version 2
* of the License.
*/
-#ifndef _ASM_X86_MRST_H
-#define _ASM_X86_MRST_H
+#ifndef _ASM_X86_INTEL_MID_H
+#define _ASM_X86_INTEL_MID_H
#include
@@ -78,4 +78,4 @@ extern void intel_scu_devices_destroy(void);
extern void mrst_rtc_init(void);
-#endif /* _ASM_X86_MRST_H */
+#endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/mrst-vrtc.h
b/arch/x86/include/asm/intel_mid_vrtc.h
similarity index 81%
rename from arch/x86/include/asm/mrst-vrtc.h
rename to arch/x86/include/asm/intel_mid_vrtc.h
index 1e69a75..86ff468 100644
--- a/arch/x86/include/asm/mrst-vrtc.h
+++ b/arch/x86/include/asm/intel_mid_vrtc.h
@@ -1,5 +1,5 @@
-#ifndef _MRST_VRTC_H
-#define _MRST_VRTC_H
+#ifndef _INTEL_MID_VRTC_H
+#define _INTEL_MID_VRTC_H
extern unsigned char vrtc_cmos_read(unsigned char reg);
extern void vrtc_cmos_write(unsigned char val, unsigned char reg);
diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index c9876ef..9154836 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -40,7 +40,7 @@
#include
#include
-#include
+#include
#include
#define APBT_CLOCKEVENT_RATING 110
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index d15f575..38ca398 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 0aa2939..a1b52fe 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include
#ifdef CONFIG_X86_32
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index ee0af58..e063eed 100644
--- a/arch/
[PATCH v3 10/10] intel_mid: Moved SFI related code to intel_mid_sfi.c
From: Kuppuswamy Sathyanarayanan
Moved SFI specific parsing/handling code to intel_mid_sfi.c. This will enable
us to reuse our intel-mid code for platforms that supports firmware interfaces
other than SFI (like ACPI).
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/include/asm/intel-mid.h| 1 +
arch/x86/platform/intel-mid/Makefile| 5 +-
arch/x86/platform/intel-mid/intel-mid.c | 450 --
arch/x86/platform/intel-mid/intel_mid_sfi.c | 485
4 files changed, 489 insertions(+), 452 deletions(-)
create mode 100644 arch/x86/platform/intel-mid/intel_mid_sfi.c
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index afc282a..358e0d2 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -18,6 +18,7 @@ extern int intel_mid_pci_init(void);
extern int get_gpio_by_name(const char *name);
extern void intel_scu_device_register(struct platform_device *pdev);
extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
+extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
extern int sfi_mrtc_num;
extern struct sfi_rtc_table_entry sfi_mrtc_array[];
diff --git a/arch/x86/platform/intel-mid/Makefile
b/arch/x86/platform/intel-mid/Makefile
index 36323ee..9a6b6c3 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,8 +1,9 @@
obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o
obj-$(CONFIG_X86_INTEL_MID)+= intel_mid_vrtc.o
obj-$(CONFIG_EARLY_PRINTK_INTEL_MID) += early_printk_intel_mid.o
-
+# SFI specific code
+obj-$(CONFIG_SFI) += intel_mid_sfi.o
# BOARD files
obj-$(CONFIG_X86_INTEL_MID) += board.o
# platform configuration for board devices
-obj-y += device_libs/
\ No newline at end of file
+obj-y += device_libs/
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 0ac2bd6..a08541a 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -18,19 +18,9 @@
#include
#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
#include
#include
-#include
-#include
-#include
#include
#include
@@ -69,17 +59,9 @@
enum intel_mid_timer_options intel_mid_timer_options;
-static u32 sfi_mtimer_usage[SFI_MTMR_MAX_NUM];
-static struct sfi_timer_table_entry sfi_mtimer_array[SFI_MTMR_MAX_NUM];
enum intel_mid_cpu_type __intel_mid_cpu_chip;
EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
-int sfi_mtimer_num;
-
-struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
-EXPORT_SYMBOL_GPL(sfi_mrtc_array);
-int sfi_mrtc_num;
-
static void intel_mid_power_off(void)
{
}
@@ -89,114 +71,6 @@ static void intel_mid_reboot(void)
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
}
-/* parse all the mtimer info to a static mtimer array */
-static int __init sfi_parse_mtmr(struct sfi_table_header *table)
-{
- struct sfi_table_simple *sb;
- struct sfi_timer_table_entry *pentry;
- struct mpc_intsrc mp_irq;
- int totallen;
-
- sb = (struct sfi_table_simple *)table;
- if (!sfi_mtimer_num) {
- sfi_mtimer_num = SFI_GET_NUM_ENTRIES(sb,
- struct sfi_timer_table_entry);
- pentry = (struct sfi_timer_table_entry *) sb->pentry;
- totallen = sfi_mtimer_num * sizeof(*pentry);
- memcpy(sfi_mtimer_array, pentry, totallen);
- }
-
- pr_debug("SFI MTIMER info (num = %d):\n", sfi_mtimer_num);
- pentry = sfi_mtimer_array;
- for (totallen = 0; totallen < sfi_mtimer_num; totallen++, pentry++) {
- pr_debug("timer[%d]: paddr = 0x%08x, freq = %dHz,"
- " irq = %d\n", totallen, (u32)pentry->phys_addr,
- pentry->freq_hz, pentry->irq);
- if (!pentry->irq)
- continue;
- mp_irq.type = MP_INTSRC;
- mp_irq.irqtype = mp_INT;
-/* triggering mode edge bit 2-3, active high polarity bit 0-1 */
- mp_irq.irqflag = 5;
- mp_irq.srcbus = MP_BUS_ISA;
- mp_irq.srcbusirq = pentry->irq; /* IRQ */
- mp_irq.dstapic = MP_APIC_ALL;
- mp_irq.dstirq = pentry->irq;
- mp_save_irq(&mp_irq);
- }
-
- return 0;
-}
-
-struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
-{
- int i;
- if (hint < sfi_mtimer_num) {
- if (!sfi_mtimer_usage[hint]) {
- pr_debug("hint taken for timer %d irq %d\n",
- hint, sfi_mtimer_array[hint].irq);
- sfi_mtimer_usage[hint] = 1;
- return &sfi_mtimer_array[hint];
- }
- }
- /* tak
[PATCH v3 03/10] mrst: Fixed checkpatch warnings
From: Kuppuswamy Sathyanarayanan Fixed checkpatch warnings in mrst related files. Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: David Cohen --- arch/x86/platform/mrst/mrst.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c index 235a742..2a45eab 100644 --- a/arch/x86/platform/mrst/mrst.c +++ b/arch/x86/platform/mrst/mrst.c @@ -977,7 +977,7 @@ static int __init sfi_parse_devs(struct sfi_table_header *table) case SFI_DEV_TYPE_UART: case SFI_DEV_TYPE_HSI: default: - ; + break; } } return 0; -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 06/10] intel_mid: Refactored sfi_parse_devs() function
From: Kuppuswamy Sathyanarayanan
SFI device_id[] table parsing code is duplicated in every SFI
device handler. This patch removes this code duplication, by
adding a seperate function get_device_id() to parse through the
device table. Also this patch moves the SPI, I2C, IPC info code from
sfi_parse_devs() to respective device handlers.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/intel-mid/intel-mid.c | 141
1 file changed, 71 insertions(+), 70 deletions(-)
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 742b7bf..f9c4be8 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -831,20 +831,15 @@ static void __init install_irq_resource(struct
platform_device *pdev, int irq)
platform_device_add_resources(pdev, &res, 1);
}
-static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *entry)
+static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev)
{
- const struct devs_id *dev = device_ids;
struct platform_device *pdev;
void *pdata = NULL;
- while (dev->name[0]) {
- if (dev->type == SFI_DEV_TYPE_IPC &&
- !strncmp(dev->name, entry->name, SFI_NAME_LEN)) {
- pdata = dev->get_platform_data(entry);
- break;
- }
- dev++;
- }
+ pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
+ pentry->name, pentry->irq);
+ pdata = dev->get_platform_data(pentry);
/*
* On Medfield the platform device creation is handled by the MSIC
@@ -853,68 +848,94 @@ static void __init sfi_handle_ipc_dev(struct
sfi_device_table_entry *entry)
if (intel_mid_has_msic())
return;
- pdev = platform_device_alloc(entry->name, 0);
+ pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
pr_err("out of memory for SFI platform device '%s'.\n",
- entry->name);
+ pentry->name);
return;
}
- install_irq_resource(pdev, entry->irq);
+ install_irq_resource(pdev, pentry->irq);
pdev->dev.platform_data = pdata;
intel_scu_device_register(pdev);
}
-static void __init sfi_handle_spi_dev(struct spi_board_info *spi_info)
+static void __init sfi_handle_spi_dev(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev)
{
- const struct devs_id *dev = device_ids;
+ struct spi_board_info spi_info;
void *pdata = NULL;
- while (dev->name[0]) {
- if (dev->type == SFI_DEV_TYPE_SPI &&
- !strncmp(dev->name, spi_info->modalias,
- SFI_NAME_LEN)) {
- pdata = dev->get_platform_data(spi_info);
- break;
- }
- dev++;
- }
- spi_info->platform_data = pdata;
+ memset(&spi_info, 0, sizeof(spi_info));
+ strncpy(spi_info.modalias, pentry->name, SFI_NAME_LEN);
+ spi_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+ spi_info.bus_num = pentry->host_num;
+ spi_info.chip_select = pentry->addr;
+ spi_info.max_speed_hz = pentry->max_freq;
+ pr_debug("SPI bus=%d, name=%16.16s, irq=0x%2x, max_freq=%d, cs=%d\n",
+ spi_info.bus_num,
+ spi_info.modalias,
+ spi_info.irq,
+ spi_info.max_speed_hz,
+ spi_info.chip_select);
+
+ pdata = dev->get_platform_data(&spi_info);
+
+ spi_info.platform_data = pdata;
if (dev->delay)
- intel_scu_spi_device_register(spi_info);
+ intel_scu_spi_device_register(&spi_info);
else
- spi_register_board_info(spi_info, 1);
+ spi_register_board_info(&spi_info, 1);
}
-static void __init sfi_handle_i2c_dev(int bus, struct i2c_board_info *i2c_info)
+static void __init sfi_handle_i2c_dev(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev)
{
- const struct devs_id *dev = device_ids;
+ struct i2c_board_info i2c_info;
void *pdata = NULL;
+ memset(&i2c_info, 0, sizeof(i2c_info));
+ strncpy(i2c_info.type, pentry->name, SFI_NAME_LEN);
+ i2c_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+ i2c_info.addr = pentry->addr;
+ pr_debug("I2C bus = %d, name = %16.16s, irq = 0x%2x, addr = 0x%x\n",
+ pentry->host_num,
+ i2c_info.type,
+ i2c_info.irq,
+ i2c_info.addr);
+ pdata = dev->get_platform_data(&i2c_info);
+ i2c_info.platform_data = pdata;
+
+
[PATCH] ARM: SAMSUNG: remove IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-s3c24xx/dma.c | 2 +-
arch/arm/mach-s3c24xx/simtec-usb.c | 3 +--
arch/arm/mach-s3c64xx/mach-smartq.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma.c b/arch/arm/mach-s3c24xx/dma.c
index 4a65cba..a8dafc1 100644
--- a/arch/arm/mach-s3c24xx/dma.c
+++ b/arch/arm/mach-s3c24xx/dma.c
@@ -742,7 +742,7 @@ int s3c2410_dma_request(enum dma_ch channel,
chan->irq_claimed = 1;
local_irq_restore(flags);
- err = request_irq(chan->irq, s3c2410_dma_irq, IRQF_DISABLED,
+ err = request_irq(chan->irq, s3c2410_dma_irq, 0,
client->name, (void *)chan);
local_irq_save(flags);
diff --git a/arch/arm/mach-s3c24xx/simtec-usb.c
b/arch/arm/mach-s3c24xx/simtec-usb.c
index 2ed2e32..bb3eac6 100644
--- a/arch/arm/mach-s3c24xx/simtec-usb.c
+++ b/arch/arm/mach-s3c24xx/simtec-usb.c
@@ -78,8 +78,7 @@ static void usb_simtec_enableoc(struct s3c2410_hcd_info
*info, int on)
if (on) {
ret = request_irq(BAST_IRQ_USBOC, usb_simtec_ocirq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB Over-current", info);
if (ret != 0) {
printk(KERN_ERR "failed to request usb oc irq\n");
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index 86d980b..389cc49 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -106,7 +106,7 @@ static void smartq_usb_host_enableoc(struct
s3c2410_hcd_info *info, int on)
if (on) {
ret = request_irq(gpio_to_irq(S3C64XX_GPL(10)),
- smartq_usb_host_ocirq, IRQF_DISABLED |
+ smartq_usb_host_ocirq,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB host overcurrent", info);
if (ret != 0)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Hi Stephan,
I haven't had a chance to look at your paper in detail, yet, but a
quick scan has found a huge red flag for me that puts the rest of your
analysis in severe doubt for me.
You say that you got really good results and perfect statistical
entropy on a number of platforms, including on an MIPS embedded
system. You also say that you are harvesting jitter by using
get_cycles() yes?
Well, on the MIPS platform, here is the definition of get_cycles:
static inline cycles_t get_cycles(void)
{
return 0;
}
So if you are getting great entropy results when in effect you
couldn't possibly be harvesting any jitter at all, then something is
really, Really, REALLY wrong with your tests.
One might be that you are just getting great statistical results
because of the whitening step. This is why I have very little faith
in statistical tests of randomness, given that they will return
perfect results for the following "random number generator"
AES_ENCRYPT(i++, NSA_KEY)
Regards,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: mmp: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-mmp/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 7ac41e8..6aacc9b 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -186,7 +186,7 @@ static void __init timer_config(void)
static struct irqaction timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= timer_interrupt,
.dev_id = &ckevt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: fix false return check from "regulator_set_voltage"
On 09/10/2013, Manish Badarkhe wrote:
> Currently, code checks false return value from "regulator_set_voltage"
> to show failure message. Modify the code to check proper return
> value from "regulator_set_voltage".
>
> Signed-off-by: Manish Badarkhe
> ---
> Based on master branch of linux-mainline.
>
> :100644 100644 0fac344... 1537f32... Mdrivers/cpufreq/exynos-cpufreq.c
> drivers/cpufreq/exynos-cpufreq.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index 0fac344..1537f32 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -141,7 +141,7 @@ post_notify:
> if ((freqs.new < freqs.old) ||
> ((freqs.new > freqs.old) && safe_arm_volt)) {
> /* down the voltage after frequency change */
> - regulator_set_voltage(arm_regulator, arm_volt,
> + ret = regulator_set_voltage(arm_regulator, arm_volt,
> arm_volt);
> if (ret) {
> pr_err("%s: failed to set cpu voltage to %d\n",
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: LPC32xx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-lpc32xx/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-lpc32xx/timer.c b/arch/arm/mach-lpc32xx/timer.c
index 20eab63..4e58372 100644
--- a/arch/arm/mach-lpc32xx/timer.c
+++ b/arch/arm/mach-lpc32xx/timer.c
@@ -90,7 +90,7 @@ static irqreturn_t lpc32xx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction lpc32xx_timer_irq = {
.name = "LPC32XX Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= lpc32xx_timer_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: IXP4xx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-ixp4xx/common.c| 2 +-
arch/arm/mach-ixp4xx/dsmg600-setup.c | 3 +--
arch/arm/mach-ixp4xx/fsg-setup.c | 6 ++
arch/arm/mach-ixp4xx/nas100d-setup.c | 3 +--
arch/arm/mach-ixp4xx/nslu2-setup.c | 6 ++
5 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 5327dec..a2b21f6 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -285,7 +285,7 @@ static irqreturn_t ixp4xx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction ixp4xx_timer_irq = {
.name = "timer1",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= ixp4xx_timer_interrupt,
.dev_id = &clockevent_ixp4xx,
};
diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c
b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 63de1b3..053a564 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -253,8 +253,7 @@ static void __init dsmg600_init(void)
pm_power_off = dsmg600_power_off;
if (request_irq(gpio_to_irq(DSMG600_RB_GPIO), &dsmg600_reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "DSM-G600 reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "DSM-G600 reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(DSMG600_RB_GPIO));
diff --git a/arch/arm/mach-ixp4xx/fsg-setup.c b/arch/arm/mach-ixp4xx/fsg-setup.c
index 429966b7..5c4b0c4 100644
--- a/arch/arm/mach-ixp4xx/fsg-setup.c
+++ b/arch/arm/mach-ixp4xx/fsg-setup.c
@@ -208,16 +208,14 @@ static void __init fsg_init(void)
platform_add_devices(fsg_devices, ARRAY_SIZE(fsg_devices));
if (request_irq(gpio_to_irq(FSG_RB_GPIO), &fsg_reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "FSG reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "FSG reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(FSG_RB_GPIO));
}
if (request_irq(gpio_to_irq(FSG_SB_GPIO), &fsg_power_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "FSG power button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "FSG power button", NULL) < 0) {
printk(KERN_DEBUG "Power Button IRQ %d not available\n",
gpio_to_irq(FSG_SB_GPIO));
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c
b/arch/arm/mach-ixp4xx/nas100d-setup.c
index ed667ce..008d792 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -271,8 +271,7 @@ static void __init nas100d_init(void)
pm_power_off = nas100d_power_off;
if (request_irq(gpio_to_irq(NAS100D_RB_GPIO), &nas100d_reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "NAS100D reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "NAS100D reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(NAS100D_RB_GPIO));
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c
b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 7e55236..01a85e4 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -258,16 +258,14 @@ static void __init nslu2_init(void)
pm_power_off = nslu2_power_off;
if (request_irq(gpio_to_irq(NSLU2_RB_GPIO), &nslu2_reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "NSLU2 reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "NSLU2 reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(NSLU2_RB_GPIO));
}
if (request_irq(gpio_to_irq(NSLU2_PB_GPIO), &nslu2_power_handler,
- IRQF_DISABLED | IRQF_TRIGGER_HIGH,
- "NSLU2 power button", NULL) < 0) {
+ IRQF_TRIGGER_HIGH, "NSLU2 power button", NULL) < 0) {
printk(KERN_DEBUG "Power Button IRQ %d not available\n",
gpio_to_irq(NSLU2_PB_GPIO));
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Question]should we not ignore the masked interrupt in regmap?
Hi, Mark: Sorry to trouble you, I have a question about the interrupt handling of regmap framework; in the regmap_irq_thread(), from the following code, we only handle the unmasked interrupt; 256 data->status_buf[i] &= ~data->mask_buf[i]; but in the following sequence, irq storm will happen; do you think we should do a change here to handle all the interrupt here? thanks very much; 1) interrupt is triggered; 2) a thread disables it(then the mask bit is set); 3) _Then_ the interrupt thread is executed, it _ignore _ and doesn’t handle this interrupt; because the interrupt is not ACKed, the interrupt status is not cleared; 4) in Marvell's PMIC, the interrupt line to SOC is always asserted, then irq storm happens; Yi Zhang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: ep93xx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-ep93xx/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 3f12b88..fcc965f 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -136,7 +136,7 @@ static irqreturn_t ep93xx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction ep93xx_timer_irq = {
.name = "ep93xx timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= ep93xx_timer_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: cns3xxx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-cns3xxx/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
index e38b279..384dc85 100644
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -155,7 +155,7 @@ static irqreturn_t cns3xxx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction cns3xxx_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= cns3xxx_timer_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cgroup: fix to break the while loop in cgroup_attach_task() correctly
From: Anjana V Kumar
Both Anjana and Eunki reported a stall in the while_each_thread loop
in cgroup_attach_task().
It's because, when we attach a single thread to a cgroup, if the cgroup
is exiting or is already in that cgroup, we won't break the loop.
If the task is already in the cgroup, the bug can lead to another thread
being attached to the cgroup unexpectedly:
# echo 5207 > tasks
# cat tasks
5207
# echo 5207 > tasks
# cat tasks
5207
5215
What's worse, if the task to be attached isn't the leader of the thread
group, we might never exit the loop, hence cpu stall. Thanks for Oleg's
analysis.
This bug was introduced by commit 081aa458c38ba576bdd4265fc807fa95b48b9e79
("cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()")
Cc: # 3.9+
Reported-by: Eunki Kim
Reported-by: Anjana V Kumar
Signed-off-by: Anjana V Kumar
[ lizf: - fixed the first continue, pointed out by Oleg,
- rewrote changelog. ]
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a5629f1..3db1d2e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2002,7 +2002,7 @@ static int cgroup_attach_task(struct cgroup *cgrp, struct
task_struct *tsk,
/* @tsk either already exited or can't exit until the end */
if (tsk->flags & PF_EXITING)
- continue;
+ goto next;
/* as per above, nr_threads may decrease, but not increase. */
BUG_ON(i >= group_size);
@@ -2010,7 +2010,7 @@ static int cgroup_attach_task(struct cgroup *cgrp, struct
task_struct *tsk,
ent.cgrp = task_cgroup_from_root(tsk, root);
/* nothing to do if this task is already in the cgroup */
if (ent.cgrp == cgrp)
- continue;
+ goto next;
/*
* saying GFP_ATOMIC has no effect here because we did prealloc
* earlier, but it's good form to communicate our expectations.
@@ -2018,7 +2018,7 @@ static int cgroup_attach_task(struct cgroup *cgrp, struct
task_struct *tsk,
retval = flex_array_put(group, i, &ent, GFP_ATOMIC);
BUG_ON(retval != 0);
i++;
-
+next:
if (!threadgroup)
break;
} while_each_thread(leader, tsk);
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 3/7] sched: power: go_faster/slower power driver hints
Hi, Morten
On 10/12/2013 01:19 AM, Morten Rasmussen wrote:
[snip]
>
> @@ -5743,6 +5772,7 @@ static void run_rebalance_domains(struct softirq_action
> *h)
>*/
> nohz_idle_balance(this_cpu, idle);
>
> + inc_cpu_capacity(this_cpu);
Just wondering is this check necessary here? if rq get more tasks during
the balance, enqueue_task() should already do the check each time when
we move_task(), isn't it?
Regards,
Michael Wang
> power_late_callback(this_cpu);
> }
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 907a967..88e7968 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1367,8 +1367,26 @@ static inline u64 irq_time_read(int cpu)
>
> #ifdef CONFIG_SCHED_POWER
> extern void power_late_callback(int cpu);
> +extern int at_max_capacity(int cpu);
> +extern int go_faster(int cpu, int hint);
> +extern int go_slower(int cpu, int hint);
> #else
> static inline void power_late_callback(int cpu)
> {
> }
> +
> +static inline int at_max_capacity(int cpu)
> +{
> + return 1;
> +}
> +
> +static inline int go_faster(int cpu, int hint)
> +{
> + return 0;
> +}
> +
> +static inline int go_slower(int cpu, int hint)
> +{
> + return 0;
> +}
> #endif /* CONFIG_SCHED_POWER */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [ARM] floppy.h: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker --- arch/arm/include/asm/floppy.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/floppy.h b/arch/arm/include/asm/floppy.h index c9f03ec..f488255 100644 --- a/arch/arm/include/asm/floppy.h +++ b/arch/arm/include/asm/floppy.h @@ -25,7 +25,7 @@ #define fd_inb(port) inb((port)) #define fd_request_irq() request_irq(IRQ_FLOPPYDISK,floppy_interrupt,\ - IRQF_DISABLED,"floppy",NULL) + 0,"floppy",NULL) #define fd_free_irq() free_irq(IRQ_FLOPPYDISK,NULL) #define fd_disable_irq() disable_irq(IRQ_FLOPPYDISK) #define fd_enable_irq()enable_irq(IRQ_FLOPPYDISK) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: timer-sp: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/common/timer-sp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index e901d0f..ce922d0 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -175,7 +175,7 @@ static struct clock_event_device sp804_clockevent = {
static struct irqaction sp804_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= sp804_timer_interrupt,
.dev_id = &sp804_clockevent,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] mm/zswap: bugfix: memory leak when invalidate and reclaim occur concurrently
On Fri, Oct 11, 2013 at 3:13 PM, Minchan Kim wrote:
> On Thu, Sep 26, 2013 at 11:42:17AM +0800, Weijie Yang wrote:
>> On Tue, Sep 24, 2013 at 9:03 AM, Minchan Kim wrote:
>> > On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote:
>> > >
>> > > Modify:
>> > > - check the refcount in fail path, free memory if it is not referenced.
>> >
>> > Hmm, I don't like this because zswap refcount routine is already mess for
>> > me.
>> > I'm not sure why it was designed from the beginning. I hope we should fix
>> > it first.
>> >
>> > 1. zswap_rb_serach could include zswap_entry_get semantic if it founds a
>> > entry from
>> >the tree. Of course, we should ranme it as find_get_zswap_entry like
>> > find_get_page.
>> > 2. zswap_entry_put could hide resource free function like zswap_free_entry
>> > so that
>> >all of caller can use it easily following pattern.
>> >
>> > find_get_zswap_entry
>> > ...
>> > ...
>> > zswap_entry_put
>> >
>> > Of course, zswap_entry_put have to check the entry is in the tree or not
>> > so if someone already removes it from the tree, it should avoid double
>> > remove.
>> >
>> > One of the concern I can think is that approach extends critical section
>> > but I think it would be no problem because more bottleneck would be
>> > [de]compress
>> > functions. If it were really problem, we can mitigate a problem with moving
>> > unnecessary functions out of zswap_free_entry because it seem to be rather
>> > over-enginnering.
>>
>> I refactor the zswap refcount routine according to Minchan's idea.
>> Here is the new patch, Any suggestion is welcomed.
>>
>> To Seth and Bob, would you please review it again?
>
> Yeah, Seth, Bob. You guys are right persons to review this because this
> scheme was suggested by me who is biased so it couldn't be a fair. ;-)
> But anyway, I will review code itself.
>
>>
>> mm/zswap.c | 116
>>
>> 1 file changed, 52 insertions(+), 64 deletions(-)
>>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> old mode 100644
>> new mode 100755
>> index deda2b6..bd04910
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -217,6 +217,7 @@ static struct zswap_entry *zswap_entry_cache_alloc(gfp_t
>> gfp)
>> if (!entry)
>> return NULL;
>> entry->refcount = 1;
>> + RB_CLEAR_NODE(&entry->rbnode);
>> return entry;
>> }
>>
>> @@ -232,10 +233,20 @@ static void zswap_entry_get(struct zswap_entry *entry)
>> }
>>
>> /* caller must hold the tree lock */
>> -static int zswap_entry_put(struct zswap_entry *entry)
>> +static int zswap_entry_put(struct zswap_tree *tree, struct zswap_entry
>> *entry)
>
> Why should we have return value? If we really need it, it mitigates
> get/put semantic's whole point so I'd like to just return void.
>
> Let me see.
>
>> {
>> - entry->refcount--;
>> - return entry->refcount;
>> + int refcount = --entry->refcount;
>> +
>> + if (refcount <= 0) {
>
> Hmm, I don't like minus refcount, really.
> I hope we could do following as
>
> BUG_ON(refcount < 0);
> if (refcount == 0) {
> ...
> }
>
>
>
>> + if (!RB_EMPTY_NODE(&entry->rbnode)) {
>> + rb_erase(&entry->rbnode, &tree->rbroot);
>> + RB_CLEAR_NODE(&entry->rbnode);
>
> Minor,
> You could make new function zswap_rb_del or zswap_rb_remove which detach the
> node
> from rb tree and clear node because we have already zswap_rb_insert.
>
>
>> + }
>> +
>> + zswap_free_entry(tree, entry);
>> + }
>> +
>> + return refcount;
>> }
>>
>> /*
>> @@ -258,6 +269,17 @@ static struct zswap_entry *zswap_rb_search(struct
>> rb_root *root, pgoff_t offset)
>> return NULL;
>> }
>>
>
> Add function description.
>
>> +static struct zswap_entry *zswap_entry_find_get(struct rb_root *root,
>> pgoff_t offset)
>> +{
>> + struct zswap_entry *entry = NULL;
>> +
>> + entry = zswap_rb_search(root, offset);
>> + if (entry)
>> + zswap_entry_get(entry);
>> +
>> + return entry;
>> +}
>> +
>> /*
>> * In the case that a entry with the same offset is found, a pointer to
>> * the existing entry is stored in dupentry and the function returns -EEXIST
>> @@ -387,7 +409,7 @@ static void zswap_free_entry(struct zswap_tree *tree,
>> struct zswap_entry *entry)
>> enum zswap_get_swap_ret {
>> ZSWAP_SWAPCACHE_NEW,
>> ZSWAP_SWAPCACHE_EXIST,
>> - ZSWAP_SWAPCACHE_NOMEM
>> + ZSWAP_SWAPCACHE_FAIL,
>> };
>>
>> /*
>> @@ -401,9 +423,9 @@ enum zswap_get_swap_ret {
>> * added to the swap cache, and returned in retpage.
>> *
>> * If success, the swap cache page is returned in retpage
>> - * Returns 0 if page was already in the swap cache, page is not locked
>> - * Returns 1 if the new page needs to be populated, page is locked
>> - * Returns <0 on error
>> + * Returns
Re: [PATCH] wdt: sunxi: Fix section mismatch
On 10/11/2013 12:15 PM, Maxime Ripard wrote: Hi Wim, On Sat, Oct 05, 2013 at 04:20:17PM +0200, Maxime Ripard wrote: This driver has a section mismatch, for probe and remove functions, leading to the following warning during the compilation. WARNING: drivers/watchdog/built-in.o(.data+0x24): Section mismatch in reference from the variable sunxi_wdt_driver to the function .init.text:sunxi_wdt_probe() The variable sunxi_wdt_driver references the function __init sunxi_wdt_probe() Signed-off-by: Maxime Ripard It would be great if it could go in 3.12. Hi Maxime, Just wondering - is this a nuisance or does it cause a real problem ? Do you want to take it, or can I merge it through my tree, with your Acked-by? In addition to this patch, the following two would also be good to have in 3.12. http://www.spinics.net/lists/linux-watchdog/msg02867.html http://www.spinics.net/lists/linux-watchdog/msg02950.html Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] mm/zswap: bugfix: memory leak when invalidate and reclaim occur concurrently
On Thu, Sep 26, 2013 at 11:42 AM, Weijie Yang wrote: > On Tue, Sep 24, 2013 at 9:03 AM, Minchan Kim wrote: >> On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote: >> > >> > Modify: >> > - check the refcount in fail path, free memory if it is not referenced. >> >> Hmm, I don't like this because zswap refcount routine is already mess for me. >> I'm not sure why it was designed from the beginning. I hope we should fix it >> first. >> >> 1. zswap_rb_serach could include zswap_entry_get semantic if it founds a >> entry from >>the tree. Of course, we should ranme it as find_get_zswap_entry like >> find_get_page. >> 2. zswap_entry_put could hide resource free function like zswap_free_entry >> so that >>all of caller can use it easily following pattern. >> >> find_get_zswap_entry >> ... >> ... >> zswap_entry_put >> >> Of course, zswap_entry_put have to check the entry is in the tree or not >> so if someone already removes it from the tree, it should avoid double >> remove. >> >> One of the concern I can think is that approach extends critical section >> but I think it would be no problem because more bottleneck would be >> [de]compress >> functions. If it were really problem, we can mitigate a problem with moving >> unnecessary functions out of zswap_free_entry because it seem to be rather >> over-enginnering. > > I refactor the zswap refcount routine according to Minchan's idea. > Here is the new patch, Any suggestion is welcomed. > > To Seth and Bob, would you please review it again? > I have nothing in addition to Minchan's review. Since the code is a bit complex, I'd suggest you to split it into two patches. [1/2]: fix the memory leak [2/2]: clean up the entry_put And run some testing.. Thanks, -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
[Fixing incorrent mail addresses and dropping the old DT ML.]
On Saturday 12 of October 2013 04:22:04 Tomasz Figa wrote:
> Hi Naveen,
>
> On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
> > The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
> > therefore is completely independent of the cpu frequency.
> > Thus, registering for a CPU freq notifier is very wasteful.
> >
> > This patch modifes the code such that, i2c bus registers to
> > cpu_freq_transition only for non Exynos SoCs.
> >
> > This change should save a bunch of cpufreq transitions calls
> > which does not apply to exynos SoCs.
>
> The idea is fine, although...
>
> > Signed-off-by: Naveen Krishna Chatradhi
> > ---
> > drivers/i2c/busses/i2c-s3c2410.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> > b/drivers/i2c/busses/i2c-s3c2410.c
> > index cab1c91..d062fa7 100644
> > --- a/drivers/i2c/busses/i2c-s3c2410.c
> > +++ b/drivers/i2c/busses/i2c-s3c2410.c
> > @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
> > struct s3c2410_platform_i2c *pdata;
> > int gpios[2];
> > struct pinctrl *pctrl;
> > -#ifdef CONFIG_CPU_FREQ
> > +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
>
> ...this is not a good coding practice, especially when already having
> multiplatform kernels in sight.
>
> The best way would be to check on which SoC we are running at runtime,
> but since this might need changing a lot of code, then at least I would
> change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
> compiled in when S3C24XX support is not enabled and if it's enabled then
> the notifier will be registered as a safe fallback that will run correctly
> on all platforms.
>
> Best regards,
> Tomasz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
On Thu, Oct 10, 2013 at 12:05:32PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 10, 2013 at 04:04:22AM +0200, Hannes Frederic Sowa wrote:
> > On Wed, Oct 09, 2013 at 05:28:33PM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 09, 2013 at 05:12:40PM -0700, Eric Dumazet wrote:
> > > > On Wed, 2013-10-09 at 16:40 -0700, Josh Triplett wrote:
> > > >
> > > > > that. Constructs like list_del_rcu are much clearer, and not
> > > > > open-coded. Open-coding synchronization code is almost always a Bad
> > > > > Idea.
> > > >
> > > > OK, so you think there is synchronization code.
> > > >
> > > > I will shut up then, no need to waste time.
> > >
> > > As you said earlier, we should at least get rid of the memory barrier
> > > as long as we are changing the code.
> >
> > Interesting thread!
> >
> > Sorry to chime in and asking a question:
> >
> > Why do we need an ACCESS_ONCE here if rcu_assign_pointer can do without one?
> > In other words I wonder why rcu_assign_pointer is not a static inline
> > function
> > to use the sequence point in argument evaluation (if I remember correctly
> > this
> > also holds for inline functions) to not allow something like this:
> >
> > E.g. we want to publish which lock to take first to prevent an ABBA problem
> > (extreme example):
> >
> > rcu_assign_pointer(lockptr, min(lptr1, lptr2));
> >
> > Couldn't a compiler spill the lockptr memory location as a temporary buffer
> > if the compiler is under register pressure? (yes, this seems unlikely if we
> > flushed out most registers to memory because of the barrier, but still...
> > ;) )
> >
> > This seems to be also the case if we publish a multi-dereferencing pointers
> > e.g. ptr->ptr->ptr.
>
> IIRC, sequence points only confine volatile accesses. For non-volatile
> accesses, the so-called "as-if rule" allows compiler writers to do some
> surprisingly global reordering.
>
> The reason that rcu_assign_pointer() isn't an inline function is because
> it needs to be type-generic, in other words, it needs to be OK to use
> it on any type of pointers as long as the C types of the two pointers
> match (the sparse types can vary a bit).
>
> One of the reasons for wanting a volatile cast in rcu_assign_pointer() is
> to prevent compiler mischief such as you described in your last two
> paragraphs. That said, it would take a very brave compiler to pull
> a pointer-referenced memory location into a register and keep it there.
> Unfortunately, increasing compiler bravery seems to be a solid long-term
> trend.
I saw your patch regarding making rcu_assign_pointer volatile and wonder if we
can still make it a bit more safe to use if we force the evaluation of the
to-be-assigned pointer before the write barrier. This is what I have in mind:
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index f1f1bc3..79eccc3 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -550,8 +550,9 @@ static inline void rcu_preempt_sleep_check(void)
})
#define __rcu_assign_pointer(p, v, space) \
do { \
+ typeof(v) ___v = (v); \
smp_wmb(); \
- (p) = (typeof(*v) __force space *)(v); \
+ (p) = (typeof(*___v) __force space *)(___v); \
} while (0)
I don't think ___v must be volatile for this case because the memory barrier
will force the evaluation of v first.
This would guard against cases where rcu_assign_pointer is used like:
rcu_assign_pointer(ptr, compute_ptr_with_side_effects());
Greetings,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
Hi Naveen,
On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
> The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
> therefore is completely independent of the cpu frequency.
> Thus, registering for a CPU freq notifier is very wasteful.
>
> This patch modifes the code such that, i2c bus registers to
> cpu_freq_transition only for non Exynos SoCs.
>
> This change should save a bunch of cpufreq transitions calls
> which does not apply to exynos SoCs.
The idea is fine, although...
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> drivers/i2c/busses/i2c-s3c2410.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c
> index cab1c91..d062fa7 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
> struct s3c2410_platform_i2c *pdata;
> int gpios[2];
> struct pinctrl *pctrl;
> -#ifdef CONFIG_CPU_FREQ
> +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
...this is not a good coding practice, especially when already having
multiplatform kernels in sight.
The best way would be to check on which SoC we are running at runtime,
but since this might need changing a lot of code, then at least I would
change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
compiled in when S3C24XX support is not enabled and if it's enabled then
the notifier will be registered as a safe fallback that will run correctly
on all platforms.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/12] EFI: Runtime services virtual mapping
CCing Peter Jones .., Peter, any idea about the grub related problem? On 10/11/13 at 09:42am, Dave Young wrote: > Matt, > > The kernel I referring is the boot kernel aka the 1st kernel, > the boot loader is grub2 from Fedora 19. > > [sorry for top reply because of using webmail] > > > - Original Message - > From: "Matt Fleming" > To: "Dave Young" > Cc: "Borislav Petkov" , "X86 ML" , "LKML" > , "Borislav Petkov" , "Matthew > Garrett" , "H. Peter Anvin" , "James > Bottomley" , "Vivek Goyal" > , linux-...@vger.kernel.org, fwts-de...@lists.ubuntu.com > Sent: Friday, October 11, 2013 6:27:06 PM > Subject: Re: [PATCH 12/12] EFI: Runtime services virtual mapping > > On Fri, 11 Oct, at 02:24:37PM, Dave Young wrote: > > For the boot efi_reserve_boot_services code, it's mainly for the > > SetVirtualAddressMap callback use, so boot regions should not be reused > > before SetVirtualAddressMap, but the overlapping happens before the > > efi_reserve_boot_services, isn't it a problem? > > Hang on, which kernel are you referring to here? The boot kernel or the > kexec'd kernel? I thought you were saying you noticed the overlap when > running in the second (kexec'd) kernel? > > The only reason that you would see this overlap in the first (boot) > kernel is if the bootloader messed up and allocated the kernel text as > EfiBootServicesCode/Data. I'd like to believe no bootloaders are still > doing that. > > -- > Matt Fleming, Intel Open Source Technology Center > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h"
On 10/12/2013 09:36 AM, Chen Gang wrote: > On 10/11/2013 09:03 PM, Richard Weinberger wrote: >> Am 11.10.2013 14:28, schrieb Will Deacon: >>> On Fri, Oct 11, 2013 at 01:08:17PM +0100, Richard Weinberger wrote: On Fri, Oct 11, 2013 at 1:47 PM, Chen Gang wrote: > In current kernel wide source code, except other architectures, only > s390 scsi drivers use atomic_clear_mask(), and arm/arm64 need not > support s390 drivers. > > So remove atomic_clear_mask() from "arm[64]/include/asm/atomic.h". Is it really worth removing such a primitive? If someone needs it later he has to implement it from scratch and introduces bugs... >>> >>> The version we have (on ARM64 anyway) already has bugs. Given the choice >>> between fixing code that has no callers and simply removing it, I'd go for >>> the latter. >> >> Yeah, if it's broken and has no real users, send it to hell. :) >> > > OK, thanks. > > > Hmm... at least, the original API definition is not well enough: "need > use 'unsigned int' and 'atomic_t' instead of 'unsigned long' for the > type of parameters". > > But can we say "under arm64, it must be a bug"? (although I agree it is > very easy to let callers miss using it -- then may cause issue). > > In my opinion, it belongs to "API definition issue" not implementation > bug: "if all callers are carefully enough, it will not make issues" > (e.g. in "./kernel" sub-system, we can meet many such kinds of things). > For "./kernel" sub-system, it really it is, if necessary, I can provide 3 samples. ;-) > > > Thanks. > >> Thanks, >> //richard >> >> >> > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: NULL pointer dereference in autofs4_expire_wait
On Fri, 2013-10-11 at 07:29 -0600, David Ahern wrote:
> On 10/11/13 3:55 AM, Ian Kent wrote:
> > On Fri, 2013-10-11 at 10:06 +0800, Ian Kent wrote:
> >> On Thu, 2013-10-10 at 17:22 -0600, David Ahern wrote:
> >>> Running 3.12-rc3 just hit BUG in autofs4_expire_wait
> >>
> >> It doesn't look like this could be due to Al's change to the locking in
> >> autos4_wait() and that the only change to autofs that I'm aware of.
> >>
> >> Could you do a bisect please?
> >
> > Of course that assumes it's repeatable.
> > Is it?
> >
> > Can you provide any information about the environment and activity that
> > was happening at the time of the BUG()?
>
> The system was up and running for 9 days before hitting the BUG. After
> that with 3 cpus on softlockup I had to do a reboot (forced). After the
> reboot I continued the workload again without a repeat incident (yet),
> so I am not sure bisect is going to be possible.
Yeah, it isn't repeatable.
>
> This is a corporate environment where practically everything is in an
> automount. Specific to this problem I was repeatedly building a
> workspace in one window, using cscope in another and checking code
> against a different workspace in a third -- all 3 of those were
> different automounts and different NAS servers.
>
> From objdump on vmlinux the line in question is fs/autofs4/expire.c:465
>
> if (ino->flags & AUTOFS_INF_EXPIRING) {
Right, there haven't been changes to the autofs kernel code that affect
the reference counting of dentrys so I have to conclude this is being
caused by other changes.
When walking an autofs path, the walk should always be put into refwalk
mode, so the function containing this line should always have a dentry
with a reference held. Which just means that the autofs info struct (ino
here) won't be invalid.
Now ->d_release() (which frees ino) is only called after the dentry
reference count falls to zero and the dentry is going away.
We can't check ino for NULL here because the dentry pointer to it isn't
set to NULL when it's freed in ->d_release(). Setting the dentry field
to NULL is futile because the next thing the VFS does is to free the
dentry itself. Well, it calls RCU to schedule the free anyway.
The fact that ->d_release() has been called makes me think there's a
reference counting problem somewhere in the VFS.
Al, is my thinking correct here?
There were some significant changes to this area of the VFS in 3.11 by
the look of it.
So more history please, had you used 3.11 for an extended amount of
time, before using the 3.12-rc? IOW what's your kernel version use
history please?
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h"
On 10/12/2013 12:55 AM, Will Deacon wrote:
> On Fri, Oct 11, 2013 at 12:47:05PM +0100, Chen Gang wrote:
>> In current kernel wide source code, except other architectures, only
>> s390 scsi drivers use atomic_clear_mask(), and arm/arm64 need not
>> support s390 drivers.
>>
>> So remove atomic_clear_mask() from "arm[64]/include/asm/atomic.h".
>
> Acked-by: Will Deacon
>
Thank you for your whole work.
> Catalin, are you happy for me to send this via the ARM tree?
>
> Will
>
Thanks.
--
Chen Gang
>>
>> Signed-off-by: Chen Gang
>> ---
>> arch/arm/include/asm/atomic.h | 24
>> arch/arm64/include/asm/atomic.h | 14 --
>> 2 files changed, 0 insertions(+), 38 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
>> index da1c77d..3b3ae49fa 100644
>> --- a/arch/arm/include/asm/atomic.h
>> +++ b/arch/arm/include/asm/atomic.h
>> @@ -134,21 +134,6 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int
>> old, int new)
>> return oldval;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long
>> *addr)
>> -{
>> -unsigned long tmp, tmp2;
>> -
>> -__asm__ __volatile__("@ atomic_clear_mask\n"
>> -"1: ldrex %0, [%3]\n"
>> -" bic %0, %0, %4\n"
>> -" strex %1, %0, [%3]\n"
>> -" teq %1, #0\n"
>> -" bne 1b"
>> -: "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
>> -: "r" (addr), "Ir" (mask)
>> -: "cc");
>> -}
>> -
>> #else /* ARM_ARCH_6 */
>>
>> #ifdef CONFIG_SMP
>> @@ -197,15 +182,6 @@ static inline int atomic_cmpxchg(atomic_t *v, int old,
>> int new)
>> return ret;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long
>> *addr)
>> -{
>> -unsigned long flags;
>> -
>> -raw_local_irq_save(flags);
>> -*addr &= ~mask;
>> -raw_local_irq_restore(flags);
>> -}
>> -
>> #endif /* __LINUX_ARM_ARCH__ */
>>
>> #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
>> diff --git a/arch/arm64/include/asm/atomic.h
>> b/arch/arm64/include/asm/atomic.h
>> index 8363644..01de5aa 100644
>> --- a/arch/arm64/include/asm/atomic.h
>> +++ b/arch/arm64/include/asm/atomic.h
>> @@ -126,20 +126,6 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int
>> old, int new)
>> return oldval;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long
>> *addr)
>> -{
>> -unsigned long tmp, tmp2;
>> -
>> -asm volatile("// atomic_clear_mask\n"
>> -"1: ldxr%0, %2\n"
>> -" bic %0, %0, %3\n"
>> -" stxr%w1, %0, %2\n"
>> -" cbnz%w1, 1b"
>> -: "=&r" (tmp), "=&r" (tmp2), "+Q" (*addr)
>> -: "Ir" (mask)
>> -: "cc");
>> -}
>> -
>> #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
>>
>> static inline int __atomic_add_unless(atomic_t *v, int a, int u)
>> --
>> 1.7.7.6
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller wrote: I like the basic idea. Here I'm alternately reading the email and the page you link to & commenting on both. A nitpick in the paper is that you cite RFC 1750. That was superceded some years back by RFC 4086 http://tools.ietf.org/html/rfc4086 (Ted's comments in the actual driver had the same problem last I looked. That is excusable since they were written long ago.) I think you may be missing some other citations that should be there, to previous work along similar lines. One is the HAVEGE work, another: McGuire, Okech & Schiesser, Analysis of inherent randomness of the Linux kernel, http://lwn.net/images/conf/rtlws11/random-hardware.pdf Paper has: " the time delta is partitioned into chunks of 1 bit starting at the lowest bit " The 64 1 bit chunks of the time value are XORed with each other to " form a 1 bit value. As I read that, you are just taking the parity. Why not use that simpler description & possibly one of several possible optimised algorithms for the task: http://graphics.stanford.edu/~seander/bithacks.html If what you are doing is not a parity computation, then you need a better description so people like me do not misread it. A bit later you have: " After obtaining the 1 bit folded and unbiased time stamp, " how is it mixed into the entropy pool? ... The 1 bit folded " value is XORed with 1 bit from the entropy pool. This appears to be missing the cryptographically strong mixing step which most RNG code includes. If that is what you are doing, you need to provide some strong arguments to justify it. Sometimes doing without is justified; for example my code along these lines ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ does more mixing than I see in yours, but probably not enough overall. That's OK because I am just feeding into /dev/random which has plenty of mixing. It is OK for your code too if you are feeding into /dev/random, but it looks problematic if your code is expected to stand alone. Ah! You talk about whitening a bit later. However, you seem to make it optional, up to the user. I cannot see that that is a good idea. At the very least I think you need something like the linear transform from the ARIA cipher -- fast and cheap, 128 bits in & 128 out and it makes every output bit depend on every input bit. That might not be enough, though. You require compilation without optimisation. How does that interact with kernel makefiles? Can you avoid undesirable optimisations in some other way, such as volatile declartions? > I am asking whether this RNG would good as an inclusion into the Linux > kernel for: > > - kernel crypto API to provide a true random number generator as part of > this API (see [2] appendix B for a description) My first reaction is no. We have /dev/random for the userspace API and there is a decent kernel API too. I may change my mind here as I look more at your appendix & maybe the code. > - inclusion into /dev/random as an entropy provider of last resort when > the entropy estimator falls low. Why only 'of last resort'? If it can provide good entropy, we should use it often. > I will present the RNG at the Linux Symposium in Ottawa this year. There > I can give a detailed description of the design and testing. I live in Ottawa, don't know if I'll make it to the Symposium this year. Ted; I saw you at one Symposium; are you coming this year? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/3] vfs: Allow rmdir to remove mounts in all but the current mount namespace
ebied...@xmission.com (Eric W. Biederman) writes:
> Miklos Szeredi writes:
>
>> On Thu, Oct 10, 2013 at 1:43 PM, Eric W. Biederman
>>> Miklos if you as the fuse maintainer aren't worried about network
>>> filesystems, and multiple namespaces I won't worry either. Especially
>>> since modern versions of fuse aren't affected.
>>
>> I think the above conditions (local mount blocks unlink/rename) are
>> enough to prevent most of the problems, of which there aren't many in
>> any case.
>
> Dumb question.
>
> What prevents someone setting up a race between the fusermount
> permission checks and replacing the destination with a symlink, perhaps
> to /etc/shadow?
>
> Do we need a MS_NOFOLLOW?
Doh! mount(".",...) works just fine..
My apologies for the silly question.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h"
On 10/11/2013 09:03 PM, Richard Weinberger wrote: > Am 11.10.2013 14:28, schrieb Will Deacon: >> On Fri, Oct 11, 2013 at 01:08:17PM +0100, Richard Weinberger wrote: >>> On Fri, Oct 11, 2013 at 1:47 PM, Chen Gang wrote: In current kernel wide source code, except other architectures, only s390 scsi drivers use atomic_clear_mask(), and arm/arm64 need not support s390 drivers. So remove atomic_clear_mask() from "arm[64]/include/asm/atomic.h". >>> >>> Is it really worth removing such a primitive? >>> If someone needs it later he has to implement it from scratch and >>> introduces bugs... >> >> The version we have (on ARM64 anyway) already has bugs. Given the choice >> between fixing code that has no callers and simply removing it, I'd go for >> the latter. > > Yeah, if it's broken and has no real users, send it to hell. :) > OK, thanks. Hmm... at least, the original API definition is not well enough: "need use 'unsigned int' and 'atomic_t' instead of 'unsigned long' for the type of parameters". But can we say "under arm64, it must be a bug"? (although I agree it is very easy to let callers miss using it -- then may cause issue). In my opinion, it belongs to "API definition issue" not implementation bug: "if all callers are carefully enough, it will not make issues" (e.g. in "./kernel" sub-system, we can meet many such kinds of things). Thanks. > Thanks, > //richard > > > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq: acpi: Add comment under ACPI_ADR_SPACE_SYSTEM_IO case
policy->cur is now set by cpufreq core when cpufreq_driver->get() is defined and
so drivers aren't required to set it. When space_id is ACPI_ADR_SPACE_SYSTEM_IO
for acpi cpufreq driver it doesn't set ->get to a valid function pointer and so
policy->cur is required to be set by driver.
This is already followed in acpi-cpufreq driver. This patch adds a comment
describing why we need to set policy->cur from driver.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Viresh Kumar
---
This change was requested by Rafael here:
http://www.spinics.net/lists/linux-acpi/msg46748.html
drivers/cpufreq/acpi-cpufreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index a8dac7b..8ecd74e 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -838,6 +838,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
*policy)
switch (perf->control_register.space_id) {
case ACPI_ADR_SPACE_SYSTEM_IO:
/* Current speed is unknown and not detectable by IO port */
+ /* ->cur wouldn't be set by core as ->get() is NULL */
policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: trivial: fix typos
On 10/07/13 09:23, Seth Jennings wrote:
> Fix comment typos in swapfile.c
>
> Signed-off-by: Seth Jennings
> ---
> mm/swapfile.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 3963fc2..7968c1b 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1179,7 +1179,7 @@ static int unuse_pte_range(struct vm_area_struct *vma,
> pmd_t *pmd,
>* some architectures (e.g. x86_32 with PAE) we might catch a glimpse
>* of unmatched parts which look like swp_pte, so unuse_pte must
>* recheck under pte lock. Scanning without pte lock lets it be
> - * preemptible whenever CONFIG_PREEMPT but not CONFIG_HIGHPTE.
> + * preemptable whenever CONFIG_PREEMPT but not CONFIG_HIGHPTE.
Do you have a dictionary source that backs this one up?
The kernel source uses either spelling.
dict.org doesn't find either spelling.
m-w.com doesn't find either spelling.
However, dictionary.com finds preemptible but not preemptable.
>*/
> pte = pte_offset_map(pmd, addr);
> do {
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: When USB PHY framework should be used?
> > > I think you should have a wrapper driver to EHCI/OHCI to handle this > reset. > > Thank you Kishon and Peter for the quick replies. Is there any good > example of such a wrapper driver in the kernel already? > chipidea, dwc3, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/3] vfs: Allow rmdir to remove mounts in all but the current mount namespace
Miklos Szeredi writes: > On Thu, Oct 10, 2013 at 1:43 PM, Eric W. Biederman >> Miklos if you as the fuse maintainer aren't worried about network >> filesystems, and multiple namespaces I won't worry either. Especially >> since modern versions of fuse aren't affected. > > I think the above conditions (local mount blocks unlink/rename) are > enough to prevent most of the problems, of which there aren't many in > any case. Dumb question. What prevents someone setting up a race between the fusermount permission checks and replacing the destination with a symlink, perhaps to /etc/shadow? Do we need a MS_NOFOLLOW? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/4] percpu_ida: add an API to return free tags
On Fri, Oct 11, 2013 at 01:35:36PM -0700, Kent Overstreet wrote: > On Fri, Oct 11, 2013 at 03:18:05PM +0800, Shaohua Li wrote: > > add an API to return free tags, blk-mq-tag will use it > > Can you explain how this is going to be used? Seems like something that > could be prone to misuse, try and convince me there isn't a better way > to do what it's for. There are two usages. One is for sysfs info output, which can be used for diagnosis. The other one is blk-mq wants to determine if it's possible a request can be queued. Neither requires precise data. Yes, caller should be aware returned data isn't very precise. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Btrfs
Hi Linus, We've got more bug fixes in my for-linus branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus One of these fixes another corner of the compression oops from last time. Miao nailed down some problems with concurrent snapshot deletion and drive balancing. I kept out one of his patches for more testing, but these are all stable. Josef Bacik (2) commits (+5/-9): Btrfs: limit delalloc pages outside of find_delalloc_range (+4/-8) Btrfs: use right root when checking for hash collision (+1/-1) Miao Xie (2) commits (+20/-12): Btrfs: fix oops caused by the space balance and dead roots (+17/-7) Btrfs: insert orphan roots into fs radix tree (+3/-5) Total: (4) commits (+25/-21) fs/btrfs/disk-io.c| 9 + fs/btrfs/disk-io.h| 13 +++-- fs/btrfs/extent_io.c | 12 fs/btrfs/inode.c | 2 +- fs/btrfs/relocation.c | 2 +- fs/btrfs/root-tree.c | 8 +++- 6 files changed, 25 insertions(+), 21 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/
Re: [patch 1/4] percpu_ida: make percpu_ida percpu size/batch configurable
On Fri, Oct 11, 2013 at 01:31:52PM -0700, Kent Overstreet wrote: > On Fri, Oct 11, 2013 at 03:18:03PM +0800, Shaohua Li wrote: > > Make percpu_ida percpu size/batch configurable. The block-mq-tag will use > > it. > > Can you explain the justification for this? Performance...? The performance using percpu_ida for tag management? Please see the patch 4 thread. If you ask the justification of making the size/batch configurable, the answer is we might have no enough tags, and default cache size/batch is too aggressive. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/39] 3.0.100-stable review
On Fri, Oct 11, 2013 at 03:14:05PM -0700, Greg Kroah-Hartman wrote: > On Fri, Oct 11, 2013 at 12:34:44PM -0700, Greg Kroah-Hartman wrote: > > > > NOTE: This is going to be the next-to-last 3.0.x release that I do. > > You should be moving off to the 3.4.x or 3.10.x longterm kernels > > by now, and not use the 3.0.x kernel unless you have to for some > > reason. If anyone has any problems with this, please let me know. > > > > > > This is the start of the stable review cycle for the 3.0.100 release. > > There are 39 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Oct 13 19:30:52 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.100-rc1.gz > > and the diffstat can be found below. > > Due to a powerpc build breakage in -rc1, I've reverted one patch and > created a -rc2 patch: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.100-rc2.gz > Build results for -rc2: total: 98 pass: 71 skipped: 16 fail: 11 qemu tests all pass. Results are as expected. Details are at http://server.roeck-us.net:8010/builders. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/48] 3.4.66-stable review
On Fri, Oct 11, 2013 at 03:12:41PM -0700, Greg Kroah-Hartman wrote: > On Fri, Oct 11, 2013 at 02:56:19PM -0700, Guenter Roeck wrote: > > On Fri, Oct 11, 2013 at 12:36:07PM -0700, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.4.66 release. > > > There are 48 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sun Oct 13 19:35:35 UTC 2013. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.66-rc1.gz > > > and the diffstat can be found below. > > > > > Less than perfect test results: > > total: 103 pass: 83 skipped: 10 fail: 10 > > > > New failures appear to be due to: > > 'powerpc: Restore registers on error exit from > > csum_partial_copy_generic()'. > > which causes six of the powerpc builds to fail. > > Ick, that also looks to break the 3.0 build. I'll go drop it from both > trees and do a -rc2 release, thanks for letting me know. > -rc2 looks better: total: 103 pass: 89 skipped: 10 fail: 4 qemu tests all pass. This matches previous results. Please see http://server.roeck-us.net:8010/builders for details. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/4] blk-mq: switch to percpu-ida for tag menagement
On Fri, Oct 11, 2013 at 08:28:54AM -0600, Jens Axboe wrote: > On 10/11/2013 01:18 AM, Shaohua Li wrote: > > Using percpu-ida to manage blk-mq tags. the percpu-ida has similar algorithm > > like the blk-mq-tag. The difference is when a cpu can't allocate tags > > blk-mq-tag uses ipi to purge remote cpu cache and percpu-ida directly purges > > remote cpu cache. In practice (testing null_blk), the percpu-ida approach is > > much faster when total tags aren't enough. > > I'm not surprised it's a lot faster the the pathological case of needing > to prune tags, the IPI isn't near ideal for that. I'm assuming the > general performance is the same for the non-full case? Yep. My test is done in a 2 sockets machine, 12 process cross the 2 sockets. So if there is lock contention or ipi, should be stressed heavily. Testing is done for null-blk. hw_queue_depth nopatch iopspatch iops 64 ~800k/s ~1470k/s 2048~4470k/s~4340k/s In the 2048 case, perf doesn't should any percpu-ida function is hot (no one use > 1% cpu time), so the small difference should be drift. So yes, the general performance is the same. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] xhci: Ensure a command structure points to the correct trb on the command ring
Sarah,
As you said, I make a mistake and send wrong patch. I am sorry for it.
On Fri, 2013-10-11 at 10:28 -0700, Sarah Sharp wrote:
> On Fri, Oct 11, 2013 at 10:25:23AM -0700, Sarah Sharp wrote:
> > Hi Xiao,
> >
> > I think you did something odd when you tried to send me the latest
> > revision of your patch "xhci: correct the usage of
> > USB_CTRL_SET_TIMEOUT". You sent this patch instead. On the plus side,
> > it looks like git-send-email works.
> >
> > Can you try again?
>
> Ah, nevermind, I saw the v2 patch you sent later.
>
> Sarah
>
> > On Fri, Oct 11, 2013 at 08:47:54AM +0800, xiao jin wrote:
> > > From: Mathias Nyman
> > >
> > > If a command on the command ring needs to be cancelled before it is
> > > handled
> > > it can be turned to a no-op operation when the ring is stopped.
> > > We want to store the command ring enqueue pointer in the command structure
> > > when the command in enqueued for the cancellation case.
> > >
> > > Some commands used to store the command ring dequeue pointers instead of
> > > enqueue
> > > (these often worked because enqueue happends to equal dequeue quite often)
> > >
> > > Other commands correctly used the enqueue pointer but did not check if it
> > > pointed
> > > to a valid trb or a link trb, this caused for example stop endpoint
> > > command to timeout in
> > > xhci_stop_device() in about 2% of suspend/resume cases.
> > >
> > > This should also solve some weird behavior happening in command
> > > cancellation cases.
> > >
> > > This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
> > > then forgotten:
> > > http://marc.info/?l=linux-usb&m=136269803207465&w=2
> > >
> > > This patch should be backported to kernels as old as 3.7, that contain
> > > the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
> > > command ring function"
> > >
> > > Signed-off-by: Mathias Nyman
> > > Signed-off-by: Sarah Sharp
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > drivers/usb/host/xhci-hub.c |2 +-
> > > drivers/usb/host/xhci-ring.c | 10 ++
> > > drivers/usb/host/xhci.c | 25 +
> > > drivers/usb/host/xhci.h |1 +
> > > 4 files changed, 17 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > > index fae697e..ccf0a06 100644
> > > --- a/drivers/usb/host/xhci-hub.c
> > > +++ b/drivers/usb/host/xhci-hub.c
> > > @@ -287,7 +287,7 @@ static int xhci_stop_device(struct xhci_hcd *xhci,
> > > int slot_id, int suspend)
> > > if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
> > > xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
> > > }
> > > - cmd->command_trb = xhci->cmd_ring->enqueue;
> > > + cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
> > > list_add_tail(&cmd->cmd_list, &virt_dev->cmd_list);
> > > xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
> > > xhci_ring_cmd_db(xhci);
> > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > > index aaa2906..9ac9672 100644
> > > --- a/drivers/usb/host/xhci-ring.c
> > > +++ b/drivers/usb/host/xhci-ring.c
> > > @@ -123,6 +123,16 @@ static int enqueue_is_link_trb(struct xhci_ring
> > > *ring)
> > > return TRB_TYPE_LINK_LE32(link->control);
> > > }
> > >
> > > +union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
> > > +{
> > > + /* Enqueue pointer can be left pointing to the link TRB,
> > > + * we must handle that
> > > + */
> > > + if (TRB_TYPE_LINK_LE32(ring->enqueue->link.control))
> > > + return ring->enq_seg->next->trbs;
> > > + return ring->enqueue;
> > > +}
> > > +
> > > /* Updates trb to point to the next TRB in the ring, and updates seg if
> > > the next
> > > * TRB is in a new segment. This does not skip over link TRBs, and it
> > > does not
> > > * effect the ring dequeue or enqueue pointers.
> > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > > index 49b6edb..1e36dbb 100644
> > > --- a/drivers/usb/host/xhci.c
> > > +++ b/drivers/usb/host/xhci.c
> > > @@ -2598,15 +2598,7 @@ static int xhci_configure_endpoint(struct xhci_hcd
> > > *xhci,
> > > if (command) {
> > > cmd_completion = command->completion;
> > > cmd_status = &command->status;
> > > - command->command_trb = xhci->cmd_ring->enqueue;
> > > -
> > > - /* Enqueue pointer can be left pointing to the link TRB,
> > > - * we must handle that
> > > - */
> > > - if (TRB_TYPE_LINK_LE32(command->command_trb->link.control))
> > > - command->command_trb =
> > > - xhci->cmd_ring->enq_seg->next->trbs;
> > > -
> > > + command->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
> > > list_add_tail(&command->cmd_list, &virt_dev->cmd_list);
> > > } else {
> > > cmd_completion = &virt_dev->cmd_completion;
> > > @@ -2614,7 +2606,7
[patch 2/2] hung_task: add method to reset detector
In certain occasions it is possible for a hung task detector
positive to be false: continuation from a paused VM, for example.
Add a method to reset detection, similar as is done
with other kernel watchdogs.
Signed-off-by: Marcelo Tosatti
Index: kvm/kernel/hung_task.c
===
--- kvm.orig/kernel/hung_task.c
+++ kvm/kernel/hung_task.c
@@ -203,6 +203,14 @@ int proc_dohung_task_timeout_secs(struct
return ret;
}
+static atomic_t reset_hung_task = ATOMIC_INIT(0);
+
+void reset_hung_task_detector(void)
+{
+ atomic_set(&reset_hung_task, 1);
+}
+EXPORT_SYMBOL_GPL(reset_hung_task_detector);
+
/*
* kthread which checks for tasks stuck in D state
*/
@@ -216,6 +224,9 @@ static int watchdog(void *dummy)
while (schedule_timeout_interruptible(timeout_jiffies(timeout)))
timeout = sysctl_hung_task_timeout_secs;
+ if (atomic_xchg(&reset_hung_task, 0))
+ continue;
+
check_hung_uninterruptible_tasks(timeout);
}
Index: kvm/include/linux/sched.h
===
--- kvm.orig/include/linux/sched.h
+++ kvm/include/linux/sched.h
@@ -285,6 +285,14 @@ static inline void lockup_detector_init(
}
#endif
+#ifdef CONFIG_DETECT_HUNG_TASK
+void reset_hung_task_detector(void);
+#else
+static inline void reset_hung_task_detector(void)
+{
+}
+#endif
+
/* Attach to any functions which should be ignored in wchan output. */
#define __sched__attribute__((__section__(".sched.text")))
Index: kvm/arch/x86/kernel/pvclock.c
===
--- kvm.orig/arch/x86/kernel/pvclock.c
+++ kvm/arch/x86/kernel/pvclock.c
@@ -48,6 +48,7 @@ void pvclock_touch_watchdogs(void)
touch_softlockup_watchdog_sync();
clocksource_touch_watchdog();
rcu_cpu_stall_reset();
+ reset_hung_task_detector();
}
static atomic64_t last_value = ATOMIC64_INIT(0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/2] generic kernel watchdog reset at pvclock read (v2)
v2: - do not create hung_task.h, move defines to sched.h (Don Zickus) - switch patch order (Paolo) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] writeback: fix negative bdi max pause
Toralf runs trinity on UML/i386.
After some time it hangs and the last message line is
BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:1521]
It's found that pages_dirtied becomes very large.
More than 10 pages in this case:
period = HZ * pages_dirtied / task_ratelimit;
BUG_ON(pages_dirtied > 20);
BUG_ON(pages_dirtied > 10); <-
UML debug printf shows that we got negative pause here:
ick: pause : -984
ick: pages_dirtied : 0
ick: task_ratelimit: 0
pause:
+ if (pause < 0) {
+ extern int printf(char *, ...);
+ printf("ick : pause : %li\n", pause);
+ printf("ick: pages_dirtied : %lu\n", pages_dirtied);
+ printf("ick: task_ratelimit: %lu\n", task_ratelimit);
+ BUG_ON(1);
+ }
trace_balance_dirty_pages(bdi,
Since pause is bounded by [min_pause, max_pause] where min_pause is also
bounded by max_pause. It's suspected and demonstrated that the max_pause
calculation goes wrong:
ick: pause : -717
ick: min_pause : -177
ick: max_pause : -717
ick: pages_dirtied : 14
ick: task_ratelimit: 0
The problem lies in the two "long = unsigned long" assignments in
bdi_max_pause() which might go negative if the highest bit is 1, and
the min_t(long, ...) check failed to protect it falling under 0. Fix
all of them by using "unsigned long" throughout the function.
Reported-by: Toralf Förster
Tested-by: Toralf Förster
Signed-off-by: Fengguang Wu
---
mm/page-writeback.c | 10 +-
mm/readahead.c |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 3f0c895..241a746 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1104,11 +1104,11 @@ static unsigned long dirty_poll_interval(unsigned long
dirty,
return 1;
}
-static long bdi_max_pause(struct backing_dev_info *bdi,
- unsigned long bdi_dirty)
+static unsigned long bdi_max_pause(struct backing_dev_info *bdi,
+ unsigned long bdi_dirty)
{
- long bw = bdi->avg_write_bandwidth;
- long t;
+ unsigned long bw = bdi->avg_write_bandwidth;
+ unsigned long t;
/*
* Limit pause time for small memory systems. If sleeping for too long
@@ -1120,7 +1120,7 @@ static long bdi_max_pause(struct backing_dev_info *bdi,
t = bdi_dirty / (1 + bw / roundup_pow_of_two(1 + HZ / 8));
t++;
- return min_t(long, t, MAX_PAUSE);
+ return min_t(unsigned long, t, MAX_PAUSE);
}
static long bdi_min_pause(struct backing_dev_info *bdi,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pvclock: detect watchdog reset at pvclock read
Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.
This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.
Suggested by Don Zickus.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kernel/kvmclock.c
===
--- kvm.orig/arch/x86/kernel/kvmclock.c
+++ kvm/arch/x86/kernel/kvmclock.c
@@ -139,6 +139,7 @@ bool kvm_check_and_clear_guest_paused(vo
src = &hv_clock[cpu].pvti;
if ((src->flags & PVCLOCK_GUEST_STOPPED) != 0) {
src->flags &= ~PVCLOCK_GUEST_STOPPED;
+ pvclock_touch_watchdogs();
ret = true;
}
Index: kvm/arch/x86/kernel/pvclock.c
===
--- kvm.orig/arch/x86/kernel/pvclock.c
+++ kvm/arch/x86/kernel/pvclock.c
@@ -43,6 +43,13 @@ unsigned long pvclock_tsc_khz(struct pvc
return pv_tsc_khz;
}
+void pvclock_touch_watchdogs(void)
+{
+ touch_softlockup_watchdog_sync();
+ clocksource_touch_watchdog();
+ rcu_cpu_stall_reset();
+}
+
static atomic64_t last_value = ATOMIC64_INIT(0);
void pvclock_resume(void)
@@ -74,6 +81,11 @@ cycle_t pvclock_clocksource_read(struct
version = __pvclock_read_cycles(src, &ret, &flags);
} while ((src->version & 1) || version != src->version);
+ if (unlikely((flags & PVCLOCK_GUEST_STOPPED) != 0)) {
+ src->flags &= ~PVCLOCK_GUEST_STOPPED;
+ pvclock_touch_watchdogs();
+ }
+
if ((valid_flags & PVCLOCK_TSC_STABLE_BIT) &&
(flags & PVCLOCK_TSC_STABLE_BIT))
return ret;
Index: kvm/arch/x86/include/asm/pvclock.h
===
--- kvm.orig/arch/x86/include/asm/pvclock.h
+++ kvm/arch/x86/include/asm/pvclock.h
@@ -14,6 +14,8 @@ void pvclock_read_wallclock(struct pvclo
struct timespec *ts);
void pvclock_resume(void);
+void pvclock_touch_watchdogs(void);
+
/*
* Scale a 64-bit delta by scaling and multiplying by a 32-bit fraction,
* yielding a 64-bit result.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks
On Fri, 11 Oct 2013 20:18:58 -0400 Scott Lovenberg wrote: > > On Oct 11, 2013, at 19:49, Jeremy Allison wrote: > > > On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: > >>> > >>> At this point, my main questions are: > >>> > >>> 1) does this look useful, particularly for fileserver implementors? > > > > Yes from the Samba perspective. We'll have to keep the old > > code around for compatibility with non-Linux OS'es, but this > > will allow Linux Samba to short-circuit a bunch of logic > > we have to get around the insane POSIX locking semantics > > on close. > > > > Jeremy. > > From the peanut gallery, IIRC from college a few years back, wasn't the POSIX > file locking stuff passed by all parties because they intended to do their > own thing regardless of the standard? The reason that all locks are blown on > a release is mostly because there were already implementations and no one > wanted to push the issue, or am I misunderstanding/forgetting the history of > file locks in POSIX? This blog post of Jeremy's explains some of the history: http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html See the section entitled "First Implementation Past the Post". -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks
On Oct 11, 2013, at 19:49, Jeremy Allison wrote: > On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: >>> >>> At this point, my main questions are: >>> >>> 1) does this look useful, particularly for fileserver implementors? > > Yes from the Samba perspective. We'll have to keep the old > code around for compatibility with non-Linux OS'es, but this > will allow Linux Samba to short-circuit a bunch of logic > we have to get around the insane POSIX locking semantics > on close. > > Jeremy. >From the peanut gallery, IIRC from college a few years back, wasn't the POSIX >file locking stuff passed by all parties because they intended to do their own >thing regardless of the standard? The reason that all locks are blown on a >release is mostly because there were already implementations and no one wanted >to push the issue, or am I misunderstanding/forgetting the history of file >locks in POSIX?-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/6] drivers: usb: core: Adapt source to styleguide
On Thu, Oct 10, 2013 at 11:41:26PM +0200, Matthias Beyer wrote: > Hi, > > I patches several files in drivers/usb/core/ to adapt them to the kernel > styleguide. > > Most of these patches are whitespace/indention fixes. > > As these patches are only style-patches, I just compiled the kernel, no > compile > errors or warnings. So I think everything seems to be okay! > > Note: I did not fix all ERROR messages from the scripts/checkpatch.pl script, > as > I don't know what to do with "do not use assignments in if-condition" > messages. You can fix those up if you want. An example would be: bad code: if ((x = foo() == NULL) do_something(); good code: x = foo(); if (x == NULL) do_something(); Hope this helps, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] drivers: usb: core: devio.c: Braces around switch
On Thu, Oct 10, 2013 at 11:41:31PM +0200, Matthias Beyer wrote: > Added braces around switch statement as the styleguide tells us. > Indented the switch-block for it and split a function call > (driver->unlocked_ioctl() on line 1876) arguments to several lines to > fit the 80-column convention. > > Signed-off-by: Matthias Beyer > --- > drivers/usb/core/devio.c | 60 > ++-- This patch has fuzz, due to me not applying your previous one, so I can't apply it. Can you fix it up, and resend the remaining patches that I didn't apply in this series? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] drivers: usb: core: devio.c: Coding style fixes
On Thu, Oct 10, 2013 at 11:41:30PM +0200, Matthias Beyer wrote:
> @@ -1838,9 +1838,10 @@ static int proc_ioctl(struct dev_state *ps, struct
> usbdevfs_ioctl *ctl)
> return -ENODEV;
> }
>
> - if (ps->dev->state != USB_STATE_CONFIGURED)
> + if (ps->dev->state != USB_STATE_CONFIGURED) {
> retval = -EHOSTUNREACH;
> - else if (!(intf = usb_ifnum_to_if(ps->dev, ctl->ifno)))
> + }
> + else if (!(intf = usb_ifnum_to_if(ps->dev, ctl->ifno))) {
> retval = -EINVAL;
> else switch (ctl->ioctl_code) {
I don't think you actually built the code after you made this change :(
drivers/usb/core/devio.c: In function ‘proc_ioctl’:
drivers/usb/core/devio.c:1844:2: error: expected ‘}’ before ‘else’
Please be more careful.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 000/135] 3.11.5-stable review
On Fri, Oct 11, 2013 at 04:58:06PM -0700, Guenter Roeck wrote: > On Fri, Oct 11, 2013 at 12:38:01PM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.11.5 release. > > There are 135 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Oct 13 19:38:31 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.5-rc1.gz > > and the diffstat can be found below. > > > Build test looks good: > total: 110 pass: 108 skipped: 2 fail: 0 > > qemu tests all pass (with the known warning for the sh target). Great, thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 000/135] 3.11.5-stable review
On Fri, Oct 11, 2013 at 12:38:01PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.11.5 release. > There are 135 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Oct 13 19:38:31 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.5-rc1.gz > and the diffstat can be found below. > Build test looks good: total: 110 pass: 108 skipped: 2 fail: 0 qemu tests all pass (with the known warning for the sh target). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/6] PowerCap: Documentation
Added power cap framework documentation. This explains the use of power capping framework, sysfs and programming interface. There are two documents: Documentation/power/powercap/powercap.txt : Explains use case and APIs. Documentation/ABI/testing/sysfs-class-powercap: Explains ABIs. Reviewed-by: Rafael J. Wysocki Reviewed-by: Len Brown Signed-off-by: Srinivas Pandruvada Signed-off-by: Jacob Pan Signed-off-by: Arjan van de Ven --- Documentation/ABI/testing/sysfs-class-powercap | 152 Documentation/power/powercap/powercap.txt | 236 + 2 files changed, 388 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-powercap create mode 100644 Documentation/power/powercap/powercap.txt diff --git a/Documentation/ABI/testing/sysfs-class-powercap b/Documentation/ABI/testing/sysfs-class-powercap new file mode 100644 index 000..db3b3ff --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-powercap @@ -0,0 +1,152 @@ +What: /sys/class/powercap/ +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + The powercap/ class sub directory belongs to the power cap + subsystem. Refer to + Documentation/power/powercap/powercap.txt for details. + +What: /sys/class/powercap/ +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + A is a unique name under /sys/class/powercap. + Here determines how the power is going to be + controlled. A can contain multiple power zones. + +What: /sys/class/powercap//enabled +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + This allows to enable/disable power capping for a "control type". + This status affects every power zone using this "control_type. + +What: /sys/class/powercap// +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + A power zone is a single or a collection of devices, which can + be independently monitored and controlled. A power zone sysfs + entry is qualified with the name of the . + E.g. intel-rapl:0:1:1. + +What: /sys/class/powercap/// +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Power zones may be organized in a hierarchy in which child + power zones provide monitoring and control for a subset of + devices under the parent. For example, if there is a parent + power zone for a whole CPU package, each CPU core in it can + be a child power zone. + +What: /sys/class/powercap/...//name +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Specifies the name of this power zone. + +What: /sys/class/powercap/...//energy_uj +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Current energy counter in micro-joules. Write "0" to reset. + If the counter can not be reset, then this attribute is + read-only. + +What: /sys/class/powercap/...//max_energy_range_uj +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Range of the above energy counter in micro-joules. + + +What: /sys/class/powercap/...//power_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Current power in micro-watts. + +What: /sys/class/powercap/...//max_power_range_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Range of the above power value in micro-watts. + +What: /sys/class/powercap/...//constraint_X_name +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Each power zone can define one or more constraints. Each + constraint can have an optional name. Here "X" can have values + from 0 to max integer. + +What: /sys/class/powercap/...//constraint_X_power_limit_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Power limit in micro-watts should be applicable for + the time window specified by "constraint_X_time_window_us". + Here "X" can have values from 0 to max integer. + +What: /sys/class/powercap/...//constraint_X_time_window_us +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Desc
[PATCH v3 6/6] Introduce Intel RAPL power capping driver
From: Jacob Pan
The Intel Running Average Power Limit(RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied.
In RAPL, power control is divided into domains, which include
package, DRAM controller, CPU core (Power Plane 0), graphics uncore
(power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in
that platform level power capping controls are exposed via this
generic interface.
This driver is based on an earlier patch from Zhang Rui.
https://lkml.org/lkml/2011/5/26/93
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Srinivas Pandruvada
Signed-off-by: Jacob Pan
---
drivers/powercap/Kconfig | 12 +
drivers/powercap/Makefile |1 +
drivers/powercap/intel_rapl.c | 1395 +
3 files changed, 1408 insertions(+)
create mode 100644 drivers/powercap/intel_rapl.c
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index a37055e..dd6a4bf 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -15,5 +15,17 @@ menuconfig POWERCAP
if POWERCAP
# Client driver configurations go here.
+config INTEL_RAPL
+ tristate "Intel RAPL Support"
+ default n
+ ---help---
+ This enables support for the Intel Running Average Power Limit (RAPL)
+ technology which allows power limits to be enforced and monitored on
+ modern Intel processors (Sandy Bridge and later).
+
+ In RAPL, the platform level settings are divided into domains for
+ fine grained control. These domains include processor package, DRAM
+ controller, CPU core (Power Plance 0), graphics uncore (Power Plane
+ 1), etc.
endif
diff --git a/drivers/powercap/Makefile b/drivers/powercap/Makefile
index 6defbc8..0a21ef3 100644
--- a/drivers/powercap/Makefile
+++ b/drivers/powercap/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_POWERCAP) += powercap_sys.o
+obj-$(CONFIG_INTEL_RAPL) += intel_rapl.o
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
new file mode 100644
index 000..887a492
--- /dev/null
+++ b/drivers/powercap/intel_rapl.c
@@ -0,0 +1,1395 @@
+/*
+ * Intel Running Average Power Limit (RAPL) Driver
+ * Copyright (c) 2013, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.
+ *
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/* bitmasks for RAPL MSRs, used by primitive access functions */
+#define ENERGY_STATUS_MASK 0x
+
+#define POWER_LIMIT1_MASK 0x7FFF
+#define POWER_LIMIT1_ENABLE BIT(15)
+#define POWER_LIMIT1_CLAMP BIT(16)
+
+#define POWER_LIMIT2_MASK (0x7FFFULL<<32)
+#define POWER_LIMIT2_ENABLE BIT_ULL(47)
+#define POWER_LIMIT2_CLAMP BIT_ULL(48)
+#define POWER_PACKAGE_LOCK BIT_ULL(63)
+#define POWER_PP_LOCK BIT(31)
+
+#define TIME_WINDOW1_MASK (0x7FULL<<17)
+#define TIME_WINDOW2_MASK (0x7FULL<<49)
+
+#define POWER_UNIT_OFFSET 0
+#define POWER_UNIT_MASK0x0F
+
+#define ENERGY_UNIT_OFFSET 0x08
+#define ENERGY_UNIT_MASK 0x1F00
+
+#define TIME_UNIT_OFFSET 0x10
+#define TIME_UNIT_MASK 0xF
+
+#define POWER_INFO_MAX_MASK (0x7fffULL<<32)
+#define POWER_INFO_MIN_MASK (0x7fffULL<<16)
+#define POWER_INFO_MAX_TIME_WIN_MASK (0x3fULL<<48)
+#define POWER_INFO_THERMAL_SPEC_MASK 0x7fff
+
+#define PERF_STATUS_THROTTLE_TIME_MASK 0x
+#define PP_POLICY_MASK 0x1F
+
+/* Non HW constants */
+#define RAPL_PRIMITIVE_DERIVED BIT(1) /* not from raw data */
+#define RAPL_PRIMITIVE_DUMMY BIT(2)
+
+/* scale RAPL units to avoid floating point math inside kernel */
+#define POWER_UNIT_SCALE (100)
+#define ENERGY_UNIT_SCALE(100)
+#define TIME_UNIT_SCALE (100)
+
+#define TIME_WINDOW_MAX_MSEC 4
+#define TIME_WINDOW_MIN_MSEC 250
+
+enum unit_type {
+ ARBITRARY_UNIT, /* no trans
Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks
On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: > > > > At this point, my main questions are: > > > > 1) does this look useful, particularly for fileserver implementors? Yes from the Samba perspective. We'll have to keep the old code around for compatibility with non-Linux OS'es, but this will allow Linux Samba to short-circuit a bunch of logic we have to get around the insane POSIX locking semantics on close. Jeremy. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/6] Power Capping Framework and RAPL Driver
Overview With the evolution of technologies, which enables power monitoring and limiting, more and more devices are able to constrain their power consumption under certain limits. There are several use cases for such technologies: - Power monitoring: Each device can report its power consumption. - Power Limiting: Setting power limits on the devices allows users to guard against platform reaching max system power level. - Maximize performance: While staying below a power limit, it allows devices to automatically adjust performance to meet demands - Dynamic control and re-budgeting: If each device can be constrained to some power, extra power can redistributed to other devices, which needs additional performance. One such example of technologies is RAPL (Running Average Power Limit) mechanism available in the latest Intel processors. Intel is slowly adding many devices under RAPL control. Also there are other technologies available, for power capping various devices. Soon it is very likely that other vendors are also adding or considering such implementation. Power Capping framework is an effort to have a uniform interface available to Linux drivers, which will enable - A uniform sysfs interface for all devices which can offer power capping - A common API for drivers, which will avoid code duplication and easy implementation of client drivers. Also submitting Intel RAPL driver using power capping framework. History: v3 As suggested changed DEVICE_ATTR to DEVICE_ATTR_RO/RW Minor change in RAPL driver for TIME_WINDOW1_MASK to change to ULL v2 As suggested, added BIT_ULL_MASK and BIT_ULL_WORD v1 Incorporated changes suggested during RFC stage Jacob Pan (2): x86/msr: add 64bit _on_cpu access functions Introduce Intel RAPL power capping driver Srinivas Pandruvada (4): PowerCap: Documentation PowerCap: Add class driver PowerCap: Added to drivers build bitops: Introduce BIT_ULL Documentation/ABI/testing/sysfs-class-powercap | 152 +++ Documentation/power/powercap/powercap.txt | 236 arch/x86/include/asm/msr.h | 22 + arch/x86/lib/msr-smp.c | 62 ++ drivers/Kconfig|2 + drivers/Makefile |1 + drivers/powercap/Kconfig | 31 + drivers/powercap/Makefile |2 + drivers/powercap/intel_rapl.c | 1395 drivers/powercap/powercap_sys.c| 683 include/linux/bitops.h |3 + include/linux/powercap.h | 325 ++ 12 files changed, 2914 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-powercap create mode 100644 Documentation/power/powercap/powercap.txt create mode 100644 drivers/powercap/Kconfig create mode 100644 drivers/powercap/Makefile create mode 100644 drivers/powercap/intel_rapl.c create mode 100644 drivers/powercap/powercap_sys.c create mode 100644 include/linux/powercap.h -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
