Re: [PATCH v5 2/3] extcon: Palmas Extcon Driver
Hi, On Monday 27 May 2013 11:04 AM, Chanwoo Choi wrote: Hi Kishon, I have some comment about this patch and upload modified patch to following repository (extcon-for-palmas). - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmas=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c This patchset include patch related to other module ,so I need your opinion to apply this patchset to git repository. yeah.. Still there is some confusion with palmas_set_switch_smps10(). I think we can remove it for now and add it separately later. By this at least we can have device mode fully functional in OMAP5. What do you think? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch: frv: kernel: using vsnprintf() instead of vsprintf()
Since die_if_kernel() is an extern common used function, better always check the buffer length to avoid memory overflow by a long 'str'. Signed-off-by: Chen Gang --- arch/frv/kernel/traps.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/frv/kernel/traps.c b/arch/frv/kernel/traps.c index 4bff48c..a6d105d 100644 --- a/arch/frv/kernel/traps.c +++ b/arch/frv/kernel/traps.c @@ -523,7 +523,7 @@ void die_if_kernel(const char *str, ...) return; va_start(va, str); - vsprintf(buffer, str, va); + vsnprintf(buffer, sizeof(buffer), str, va); va_end(va); console_verbose(); -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: BUG_ON in virtio-ring.c
Dave Airlie writes:
>>> correct.
>>>
>>> If I have an indirect ring and I'm adding sgs to it and the host is
>>> delayed (say I've got a thread consuming things from the vring and its
>>> off doing something interesting),
>>> I'd really like to get ENOSPC back from virtqueue_add. However if the
>>> indirect addition fails due to free_sg being 0, we hit the BUG_ON
>>> before we ever get to the ENOSPC check.
>>
>> It is correct for the moment: drivers can't assume indirect buffer
>> support in the transport.
>>
>> BUT for a new device, we could say "this depends on indirect descriptor
>> support", put the appropriate check in the device init, and then remove
>> the BUG_ON().
>
> But if the transport has indirect buffer support, can it change its
> mind at runtime?
It's a layering violation. The current rule is simple:
A driver should never submit a buffer which can't fit in the
ring.
This has the nice property that OOM (ie. indirect buffer alloction
fail) just slows things down, doesn't break things.
> In this case we have vq->indirect set, but the device has run out of
> free buffers,
> but it isn't a case that in+out would overflow it if it had free
> buffers since it would use
> an indirect and succeed.
OK, but when do you re-xmit? What if the ring is empty, and you
submitted a buffer that needs indirect? You won't get interrupted
again, because the device has consumed all the buffers. You need to
have your own timer or something equally hackish.
> Getting -ENOSPC is definitely what should happen from what I can see,
> not a BUG_ON,
> I should get a BUG_ON only if the device reports no indirect support.
I think we should return -ENOMEM if we can't indirect because of failed
allocation and it doesn't fit in the ring, ie:
This:
BUG_ON(total_sg > vq->vring.num);
BUG_ON(total_sg == 0);
if (vq->vq.num_free < total_sg) {
pr_debug("Can't add buf len %i - avail = %i\n",
total_sg, vq->vq.num_free);
/* FIXME: for historical reasons, we force a notify here if
* there are outgoing parts to the buffer. Presumably the
* host should service the ring ASAP. */
if (out_sgs)
vq->notify(>vq);
END_USE(vq);
return -ENOSPC;
}
Becomes (untested):
BUG_ON(total_sg == 0);
if (vq->vq.num_free < total_sg) {
if (total_sg > vq->vring.num) {
BUG_ON(!vq->indirect);
/* Return -ENOMEM only if we have nothing else to do */
if (vq->vq.num_free == vq->vring.num)
return -ENOMEM;
}
pr_debug("Can't add buf len %i - avail = %i\n",
total_sg, vq->vq.num_free);
/* FIXME: for historical reasons, we force a notify here if
* there are outgoing parts to the buffer. Presumably the
* host should service the ring ASAP. */
if (out_sgs)
vq->notify(>vq);
END_USE(vq);
return -ENOSPC;
}
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] usb: dwc3: use extcon fwrk to receive connect/disconnect notification
On 05/24/2013 11:31 PM, Kishon Vijay Abraham I wrote: > Modified dwc3-omap to receive connect and disconnect notification using > extcon framework. Also did the necessary cleanups required after > adapting to extcon framework. > > Signed-off-by: Kishon Vijay Abraham I > --- > drivers/usb/dwc3/dwc3-omap.c | 80 > +-- > include/linux/usb/dwc3-omap.h | 30 > 2 files changed, 62 insertions(+), 48 deletions(-) > delete mode 100644 include/linux/usb/dwc3-omap.h > > I check the code about extcon framework. Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/3] extcon: Palmas Extcon Driver
Hi Kishon,
I have some comment about this patch
and upload modified patch to following repository (extcon-for-palmas).
-
http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmas=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c
This patchset include patch related to other module
,so I need your opinion to apply this patchset to git repository.
On 05/24/2013 11:31 PM, Kishon Vijay Abraham I wrote:
> From: Graeme Gregory
>
> This is the driver for the USB comparator built into the palmas chip. It
> handles the various USB OTG events that can be generated by cable
> insertion/removal.
>
> Signed-off-by: Graeme Gregory
> Signed-off-by: Moiz Sonasath
> Signed-off-by: Ruchika Kharwar
> Signed-off-by: Kishon Vijay Abraham I
> Signed-off-by: George Cherian
> [kis...@ti.com: adapted palmas usb driver to use the extcon framework]
> Signed-off-by: Sebastien Guiriec
> ---
> Changes from v4:
> * removed no_control_vbus property (to be used if the platform wants to use
> its own vbus control.
> * removed unnecessary headers
> * moved the palmas_usb_state to palmas.h
> * misc cleanups
> *A checkpatch warning "WARNING: static const char * array should
> probably be static const char * const"is ignored since it introduces a
> compilation warning.
> Changes from v3:
> * adapted the driver to extcon framework (so moved to drivers/extcon)
> * removed palmas_usb_(write/read) and replaced all calls with
> palmas_(read/write).
> * ignored a checkpatch warning in the line
> static const char *palmas_extcon_cable[] = {
> as it seemed to be incorrect?
> * removed all references to OMAP in this driver.
> * couldn't test this driver with mainline as omap5 panda is not booting
> with mainline.
> * A comment to change to platform_get_irq from regmap is not done as I felt
> the data should come from regmap in this case. Graeme?
> Changes from v2:
> * Moved the driver to drivers/usb/phy/
> * Added a bit more explanation in Kconfig
> .../devicetree/bindings/extcon/extcon-twl.txt | 16 +
> drivers/extcon/Kconfig | 7 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-palmas.c | 341
> +
> include/linux/mfd/palmas.h | 25 +-
> 5 files changed, 380 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/extcon/extcon-twl.txt
> create mode 100644 drivers/extcon/extcon-palmas.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
> b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
> new file mode 100644
> index 000..8ffdeed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
> @@ -0,0 +1,15 @@
> +EXTCON FOR TWL CHIPS
> +
> +PALMAS USB COMPARATOR
> +Required Properties:
> + - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb"
> + - vbus-supply : phandle to the regulator device tree node.
> +
> +Optional Properties:
> + - ti,wakeup : To enable the wakeup comparator in probe
> +
> +palmas-usb {
> + compatible = "ti,twl6035-usb", "ti,palmas-usb";
> + vbus-supply = <_reg>;
> + ti,wakeup;
> +};
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 3297301..63f454e 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -53,4 +53,11 @@ config EXTCON_ARIZONA
> with Wolfson Arizona devices. These are audio CODECs with
> advanced audio accessory detection support.
>
> +config EXTCON_PALMAS
> + tristate "Palmas USB EXTCON support"
> + depends on MFD_PALMAS
You should add REGULATOR_PALMAS dependency because
palmas_set_switch_smps10() is defined in palmas regulator driver.
+depends on MFD_PALMAS && REGULATOR_PALMAS
> + help
> + Say Y here to enable support for USB peripheral and USB host
> + detection by palmas usb.
> +
> endif # MULTISTATE_SWITCH
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index f98a3c4..540e2c3 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> +obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> new file mode 100644
> index 000..9e613e9
> --- /dev/null
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -0,0 +1,341 @@
> +/*
> + * Palmas USB transceiver driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> +
Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results
On 24 May 2013 16:50, Lukasz Majewski wrote: >> On 24 May 2013 14:00, Lukasz Majewski wrote: > This is not safe IMHO to add permanently overclocked frequency to the > freq table. Since, for example, thermal framework also asks for > reference to this table. Yes, its wrong. Even adding it permanently this way would be a problem if governor is changed to performance. :) > The idea beneath overclocking is to add "dangerous" frequency to the > frequency table only when necessary (and remove it when not needed). Hmm.. probably the idea beneath is to use dangerous frequency only when we are assured that we will not break system.. It doesn't have anything to do with cpufreq table entries :) > In this way, the thermal framework (as it is done at our platform) will > decrease the frequency (according to thermal governor :-) ) to safe > level. > > Overclocking is disabled in 2 ways (at our setup): > - thermal framework is here to help us > - lab governor disables the overclocking when favorable conditions are > gone. I don't want to discuss OR think about LAB for now.. Want to get overclocking feature in first. > One more remark - enabling tb_en_over_clk at sysfs (echo 1 >> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk) > adds overclock frequency to frequency table and updates policy. What if it is enabled and governor is changed to performance without disabling it... Who will take care of disabling dangerous frequencies? One thing I am certain about is to make overclocking a generic and core feature, rather than platform specific... What about adding overdrive frequencies in freq table permanently but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ?? This way we will use frequencies marked with CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking enabled. And not at other times? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fans at full speed after resume
On Thu, 2013-05-23 at 22:22 +0200, Michael Großhäuser wrote: > Zhang Rui wrote: > > > On Wed, 2013-05-22 at 20:46 +0200, Michael Großhäuser wrote: > >> Zhang Rui wrote: > >> > >> > On Wed, 2013-05-15 at 12:26 +0800, Zhang Rui wrote: > >> >> please > >> >> > >> >> On Tue, 2013-05-14 at 21:18 -0700, Sonny Rao wrote: > >> >> > Hi, I've seen a regression in kernels since 3.7 on x86 devices where > >> >> > the kernel turns the system fans on to max speed after resuming from > >> >> > ram. Other people have noticed it as well, for example see > >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=895276 > >> >> > > >> >> please check if this is a duplicate of bug > >> >> https://bugzilla.kernel.org/show_bug.cgi?id=56591 > >> > or you can try 3.10-rc1 to see if the problem still exists or not. > >> > > >> > thanks, > >> > rui > >> > >> > >> Hi, > >> > >> I can confirm the same problem on a HP/Compaq 2510p with 3.10-rc2. > >> > > please check if this is a duplicate of bug > > https://bugzilla.kernel.org/show_bug.cgi?id=58301 > > > > please try the patch at comment #7 and see if it helps or not. > > Good to know. then could you please try the four patches in comment #10, #11, #12 and #13 in https://bugzilla.kernel.org/show_bug.cgi?id=58301 without the previous patch and check if they help? These four patches are the fixes that I would push for upstream. thanks, rui > > thanks, > > rui > > Hi, > > the patch fixes the problem for me. > > Thanks, > Michael > > > >> Best Regards, > >> Michael > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-pm" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch: parisc: kernel: memory overflow, 'name' length is too short for using
'path.bc[i]' can be asigned by PCI_SLOT() which can '> 10', so sizeof(6
* "%u:" + "%u" + '\0') may be 21.
Since 'name' length is 20, it may be memory overflow.
And 'path.bc[i]' is 'unsigned char' for printing, we can be sure the
max length of 'name' must be less than 28.
So simplify thinking, we can use 28 instead of 20 directly, and do not
think of whether 'patchc.bc[i]' can '> 100'.
Signed-off-by: Chen Gang
---
arch/parisc/kernel/drivers.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/parisc/kernel/drivers.c b/arch/parisc/kernel/drivers.c
index 5709c5e..14285ca 100644
--- a/arch/parisc/kernel/drivers.c
+++ b/arch/parisc/kernel/drivers.c
@@ -394,7 +394,7 @@ EXPORT_SYMBOL(print_pci_hwpath);
static void setup_bus_id(struct parisc_device *padev)
{
struct hardware_path path;
- char name[20];
+ char name[28];
char *output = name;
int i;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] f2fs: add sysfs support for controlling the gc_thread
2013/5/27, Jaegeuk Kim : > Hi Namjae, Hi Jaegeuk. First, Thanks for your interest. > > This is an interesting functionality. > Could you describe why and when we need to do this? > What are pros and cons? > How can we use this? As the default size of the F2FS parameter can vary as per the storage size, so we can figure out the default values for Garbage collection on each device. It will be good if we can provide an interface which helps in tunning these timing parameters to optimize the behavior of GC thread. As you know, we can see performance dropping suddenly by GC thread. GC thread is working more roughly for big size disk. And on other hand, it is more work hard for very small partition. And If App didn't access f2fs partition for a while. We can use this time to make possible valid blocks using foregound gc thread working. So we should need gc thread fg start and stop functionality. We will describe how to use it and more detail in patch changelog(v2). > > IMO, when users try to control IO latencies, it seems that they can > trigger such the explicit GCs, but in order to do that, they also need > to know the status of current f2fs in more precisely. Does the debugfs > show it enoughly? First important thing before running the GC thread forecefully from the user level ‘sysfs’ is to have diagnostic values of the FLASH partition. So, we are trying to figure out how we can check the stats regarding running the GC thread. I have thought more after getting your reply. f2fs_cleaner(a tentative name) is that provide the following several options to control gc thread. 1. start forground gc thread to clean all invalid blocks. 2. stop number 1(fg) working. 3. set new tunning parameter (min/max/no_gc). 4. get status of current f2fs. We will provide user level util in f2fs tools and sysfs at the same time. It is useful if the console level user/App user can change them easily. > > Afterwards, it is worth to add some information to > Document/filesystems/f2fs.txt. Yes, It will be included in next series patches. How do you think ? If you agree my suggestion, I will start to work the above jobs. Let me know your opinion. Thanks. > > Thanks, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code
於 一，2013-05-27 於 12:27 +0800，joeyli 提到： > Hi Dave, > > 於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到： > > On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote: > > > On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote: > > > > Russ, > > > > > > > > Can we open a bug for the BIOS folks and see if we can get this > > addressed? > > > > > > I already talked with them. It is not in an area that we > > > normally change, so if there is a bug may be in the Intel > > > reference code. More investigation is needed to track down > > > the actual problem, and that could take help from Intel. > > > > > > Regardless of that, it is a kernel patch that triggers the > > > problem. This isn't the first time a kernel change does > > > the "right thing" but trips across questionable bios/EFI/bootloader > > > implementation. That still makes it a kernel bug. > > > > > > I'm still digging to better understand the root problem. > > > > When we rebased the Fedora 18 kernel to 3.9 we had a bunch of reports > > from people who can no longer boot with what looks like similar symptoms. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=964335 > > > > Dave > > > > The oops on the above bug is similar to my problem on Acer machine, > could you please ask the reporter try the eccaf52f patch in urgent > branch on Matt's efi git tree: > > https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=urgent=eccaf52fee8305d5207ff110950a82c100e459bc > > > Thanks! > Joey Lee Looks there have a couple of different machines on this bug. The oops similar to my machine is reported by josephhenryblack. Thanks Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [regression, bisected] x86: efi: Pass boot services variable info to runtime code
Hi Dave, 於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到： > On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote: > > On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote: > > > Russ, > > > > > > Can we open a bug for the BIOS folks and see if we can get this > addressed? > > > > I already talked with them. It is not in an area that we > > normally change, so if there is a bug may be in the Intel > > reference code. More investigation is needed to track down > > the actual problem, and that could take help from Intel. > > > > Regardless of that, it is a kernel patch that triggers the > > problem. This isn't the first time a kernel change does > > the "right thing" but trips across questionable bios/EFI/bootloader > > implementation. That still makes it a kernel bug. > > > > I'm still digging to better understand the root problem. > > When we rebased the Fedora 18 kernel to 3.9 we had a bunch of reports > from people who can no longer boot with what looks like similar symptoms. > > https://bugzilla.redhat.com/show_bug.cgi?id=964335 > > Dave > The oops on the above bug is similar to my problem on Acer machine, could you please ask the reporter try the eccaf52f patch in urgent branch on Matt's efi git tree: https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=urgent=eccaf52fee8305d5207ff110950a82c100e459bc Thanks! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rtc: rtc-ds1307: use devm_*() functions
On Mon, May 27, 2013 at 6:32 AM, Jingoo Han wrote:
> On Saturday, May 25, 2013 10:51 AM, Devendra Naga wrote:
>> On Sat, May 25, 2013 at 10:41 AM, Nikolay Balandin wrote:
>> > From: Nikolay Balandin
>
> [.]
>
>> >
>> > - ds1307->rtc = rtc_device_register(client->name, >dev,
>> > + ds1307->rtc = devm_rtc_device_register(>dev, client->name,
>> > _rtc_ops, THIS_MODULE);
>
> Hi Nikolay Baladin, Devendra Naga,
>
> Here, "devm"_rtc_device_register() is used.
> Thus, rtc_device_unregister() will be called after remove() or
> on probe failure.
>
You are correct, I am not aware of the new API that is added by you
in c100a5e0255.
Very sorry Nikolay Baladin, I would really have seen and commented on the patch.
Thanks for letting me know. :)
>
>> > if (IS_ERR(ds1307->rtc)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 PATCHv4 1/6] arm: TI-Nspire platform code
On 27/05/2013, at 6:46 AM, Arnd Bergmann wrote:
>
>
>> +{
>> +.virtual= NSPIRE_PWR_VIRT_BASE,
>> +.pfn= __phys_to_pfn(NSPIRE_PWR_PHYS_BASE),
>> +.length = SZ_4K,
>> +.type = MT_DEVICE
>> +}
>> +};
>
> And I think this one can be replaced with a call to of_iomap:
Does of_iomap work that early in the boot process?
Cheers,
Daniel Tang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 PATCHv4 0/6] arm: Initial TI-Nspire support
On 27/05/2013, at 7:23 AM, Arnd Bergmann wrote: > On Saturday 25 May 2013, Daniel Tang wrote: >> Changes between v3 and v4: >> * Remove redundant clock-names in device tree >> * Re-enable bus access to some peripherals on bootup >> * Clean up nspire-classic-timer code. >> - Implement a nspire_timer_set_mode function >> - Removed messy IO_MATCHx and CNTL_MATCHx macros >> - Timer starts disabled to begin with >> - Interrupt handling code return IRQ_NONE for spurious interrupts >> - Delete unnessecary shift >> * Change clk-nspire to use compatible property to determine IO type >> * Change device tree bindings to have appropriate vendor prefixes >> * Added device tree binding documentation >> * Fix incorrect register addresses for clocks >> * Use more specific .caps for CLCD > > Looks really good now. I have a few more comments for the first patch, > mostly for stuff that can be simplified based on stuff we merged in 3.10. > > The one remaining bit that sticks out is the clcd platform data. As I > said before, I won't require you to convert that to DT in order to > get your code merged, but I'd also really like to see that happen, > as we will also need that to get rid of auxdata on the ARM reference > platforms (integrator, versatile, realview, vexpress). How would you like me to convert the platform data to DT? AFAIK, the clcd driver isn't aware of DT so the only way is to use the AUXDATA right now. > > Are you motivated to look into those after the base patch gets > merged into arm-soc? Of course. > > One comment on the merge path: While we can put any of the patches > into the arm-soc tree, my preference is definitely for the clk, > clksource, irqchip and input drivers to go through the respective > maintainer trees. There are no dependencies to worry about, since > each patch can compile standalone, and we just need to make sure > they all get into 3.11 for your platform to work. Yeah that's totally fine. > > Arnd Cheers, Daniel Tang-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] video: simplefb: add mode parsing function
The naming scheme of simplefb's mode is precise enough to allow building
the mode structure from it instead of using a static list of modes. This
patch introduces a function that does this. In case exotic modes that
cannot be represented from their name alone are needed, the static list
of modes is still available as a backup.
It also changes the order in which colors are declared from MSB first to
the more standard LSB first.
Signed-off-by: Alexandre Courbot
---
Changes from v1:
- amended documentation following Stephen's suggestion
- allow parsing of bitfields larger than 9 bits
- made it clear that the parsing order of bits is changed with respect
to the original patch
Andrew, since this patch introduces a (small) change in the DT bindings,
could we try to merge it during the -rc cycle so we don't have to come
with a more complex solution in the future?
.../bindings/video/simple-framebuffer.txt | 12 +++-
drivers/video/simplefb.c | 72 +-
2 files changed, 80 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 3ea4605..18d03e2 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -10,8 +10,16 @@ Required properties:
- width: The width of the framebuffer in pixels.
- height: The height of the framebuffer in pixels.
- stride: The number of bytes in each line of the framebuffer.
-- format: The format of the framebuffer surface. Valid values are:
- - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+- format: The format of the framebuffer surface. Described as a sequence of
+ channel/num-bits pairs, where each pair describes how many bits are used
+ by a given color channel. Value channels are "r" (red), "g" (green),
+ "b" (blue), "a" (alpha) and "x" (unused). Channels are listed in bit
+ order, starting from the LSB. For instance, a format named "r5g6b5"
+ describes a 16-bit format where red is encoded in the 5 less significant
+ bits, green in the 6 following ones, and blue in the 5 last:
+ BGGG GGGR
+ ^ ^
+ MSB LSB
Example:
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index e2e9e3e..1430752 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -21,6 +21,7 @@
*/
#include
+#include
#include
#include
#include
@@ -82,8 +83,72 @@ struct simplefb_format {
struct fb_bitfield transp;
};
+static struct simplefb_format *simplefb_parse_format(struct device *dev,
+const char *str)
+{
+ struct simplefb_format *format;
+ unsigned int offset = 0;
+ unsigned int i = 0;
+
+ format = devm_kzalloc(dev, sizeof(*format), GFP_KERNEL);
+ if (!format)
+ return ERR_PTR(-ENOMEM);
+
+ while (str[i] != 0) {
+ struct fb_bitfield *field = NULL;
+ int length = 0;
+
+ switch (str[i++]) {
+ case 'r':
+ case 'R':
+ field = >red;
+ break;
+ case 'g':
+ case 'G':
+ field = >green;
+ break;
+ case 'b':
+ case 'B':
+ field = >blue;
+ break;
+ case 'a':
+ case 'A':
+ field = >transp;
+ break;
+ case 'x':
+ case 'X':
+ break;
+ default:
+ goto error;
+ }
+
+ if (!isdigit(str[i]))
+ goto error;
+
+ while (isdigit(str[i])) {
+ length = length * 10 + (str[i++] - '0');
+ }
+
+ if (field) {
+ field->offset = offset;
+ field->length = length;
+ }
+
+ offset += length;
+ }
+
+ format->bits_per_pixel = (offset + 7) & ~0x7;
+ format->name = str;
+ return format;
+
+error:
+ dev_err(dev, "Invalid format string\n");
+ return ERR_PTR(-EINVAL);
+}
+
+/* if you use exotic modes that simplefb_parse_format cannot decode, you can
+ specify them here. */
static struct simplefb_format simplefb_formats[] = {
- { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
};
struct simplefb_params {
@@ -131,7 +196,10 @@ static int simplefb_parse_dt(struct platform_device *pdev,
params->format = _formats[i];
break;
}
- if (!params->format) {
+ if (!params->format)
+
Re: linux-next: build failure after merge of the crypto tree
On Mon, May 27, 2013 at 01:43:01PM +1000, Stephen Rothwell wrote: > Hi Herbert, > > On Mon, 27 May 2013 10:19:18 +0800 Herbert Xu > wrote: > > > > Hi Stephen, did you get a chance to switch back to the current > > cryptodev tree? > > Not quite sure what you mean? I fetch your tree every morning (that I > build linux-next) so I got an update from you this morning. I haven't > got to merging and building it yet, but it looks good. Great! The reason I asked is because I got a build failure from the kbuild robot over the weekend that was using a two-week old version of cryptodev. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the crypto tree
Hi Herbert, On Mon, 27 May 2013 10:19:18 +0800 Herbert Xu wrote: > > Hi Stephen, did you get a chance to switch back to the current > cryptodev tree? Not quite sure what you mean? I fetch your tree every morning (that I build linux-next) so I got an update from you this morning. I haven't got to merging and building it yet, but it looks good. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpyqq3aGJnZy.pgp Description: PGP signature
Re: [GIT PULL v2] f2fs updates for v3.10
Hi, Thank you for the report. I'm not able to reproduce this at all. In my runs, there was no regression. Can you do that? Thanks, 2013-05-15 (수), 12:09 +0300, Anca Emanuel: > Regresions: > http://www.phoronix.com/scan.php?page=article=linux_310_f2fs=3 > > The most notable one is PostgreSQL pgbench v8.4.11 > Transactions per second: 3032 in kernel 3.9 > down to 832 in kernel 3.10-rc1 > > On Wed, May 8, 2013 at 2:10 PM, Jaegeuk Kim wrote: > > Hi Linus, > > > > I've rebased one of patches, so could you consider the following pull > > request? > > Sorry for the noise. > > > > The following changes since commit > > 47b3bc907328db968bc9b43c41f48f8d1e140750: > > > > Merge branch 'x86-urgent-for-linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2013-03-07 > > 15:57:38 -0800) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > > tags/f2fs-for-v3.10 > > > > for you to fetch changes up to 59bbd474abb9dd6a0c1a74df758ec29c7a8b150f: > > > > f2fs: cover free_nid management with spin_lock (2013-05-08 19:54:22 > > +0900) > > > > > > f2fs updates for v3.10 > > > > This patch-set includes the following major enhancement patches. > > o introduce a new gloabl lock scheme > > o add tracepoints on several major functions > > o fix the overall cleaning process focused on victim selection > > o apply the block plugging to merge IOs as much as possible > > o enhance management of free nids and its list > > o enhance the readahead mode for node pages > > o address several cretical deadlock conditions > > o reduce lock_page calls > > > > The other minor bug fixes and enhancements are as follows. > > o calculation mistakes: overflow > > o bio types: READ, READA, and READ_SYNC > > o fix the recovery flow, data races, and null pointer errors > > > > > > Alexandru Gheorghiu (1): > > f2fs: use kmemdup > > > > Changman Lee (3): > > f2fs: fix overflow when calculating utilization on 32-bit > > f2fs: check the level before calling get_nid function > > f2fs: update f2fs.txt related with discard at mkfs > > > > Chris Fries (2): > > f2fs: continue to mount after failing recovery > > f2fs: recover when journal contains deleted files > > > > Haicheng Li (5): > > f2fs: fix inconsistent using of NM_WOUT_THRESHOLD > > f2fs: remove useless #include as we're now using > > sysfs as debug entry. > > f2fs: bugfix for alloc_nid_failed() > > f2fs: code cleanup for scan_nat_page() and build_free_nids() > > f2fs: optimize scan_nat_page() > > > > Jaegeuk Kim (35): > > f2fs: fix to unlock node page when it was truncated > > f2fs: read with READ_SYNC when getting dnode page > > f2fs: introduce readahead mode of node pages > > f2fs: align f2fs maximum name length to linux based filesystem > > f2fs: reduce unncessary locking pages during read > > f2fs: should check the node page was truncated first > > f2fs: scan next nat page to reuse free nids in there > > f2fs: fix return value of releasepage for node and data > > f2fs: fix not to allocate max_nid > > f2fs: fix to call WRITE_FLUSH at the end of fsync > > f2fs: fix the recovery flow to handle errors correctly > > f2fs: do not skip writing file meta during fsync > > f2fs: remain nat cache entries for further free nid allocation > > f2fs: fix to give correct parent inode number for roll forward > > f2fs: do not use duplicate names in a macro > > f2fs: introduce TOTAL_SECS macro > > f2fs: remove redundant lock_page calls > > f2fs: allocate new segment aligned with sections > > f2fs: change GC bitmaps to apply the section granularity > > f2fs: check completion of foreground GC > > f2fs: allocate remained free segments in the LFS mode > > f2fs: avoid race for summary information > > f2fs: fix the bitmap consistency of dirty segments > > f2fs: reduce redundant spin_lock operations > > f2fs: introduce a new global lock scheme > > f2fs: write checkpoint before starting FG_GC > > f2fs: avoid frequent background GC > > f2fs: give a chance to merge IOs by IO scheduler > > f2fs: check nid == 0 in add_free_nid > > f2fs: add a tracepoint on f2fs_new_inode > > f2fs: enhance alloc_nid and build_free_nids flows > > f2fs: check truncation of mapping after lock_page > > f2fs: modify the number of issued pages to merge IOs > > f2fs: avoid deadlock during evict after f2fs_gc > > f2fs: cover free_nid management with spin_lock > > > > Jason Hrycay (1): > > f2fs: move f2fs_balance_fs from truncate to punch_hole > > > > Masanari Iida (1): > > f2fs: fix typo in comments > > > > Namjae Jeon (17): > > f2fs: optimize
Re: BUG_ON in virtio-ring.c
>> correct. >> >> If I have an indirect ring and I'm adding sgs to it and the host is >> delayed (say I've got a thread consuming things from the vring and its >> off doing something interesting), >> I'd really like to get ENOSPC back from virtqueue_add. However if the >> indirect addition fails due to free_sg being 0, we hit the BUG_ON >> before we ever get to the ENOSPC check. > > It is correct for the moment: drivers can't assume indirect buffer > support in the transport. > > BUT for a new device, we could say "this depends on indirect descriptor > support", put the appropriate check in the device init, and then remove > the BUG_ON(). But if the transport has indirect buffer support, can it change its mind at runtime? In this case we have vq->indirect set, but the device has run out of free buffers, but it isn't a case that in+out would overflow it if it had free buffers since it would use an indirect and succeed. Getting -ENOSPC is definitely what should happen from what I can see, not a BUG_ON, I should get a BUG_ON only if the device reports no indirect support. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND 01/24] drivers/scsi/a100u2w: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/scsi/a100u2w.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
* add "Signed-off-by: Libo Chen "
diff --git a/drivers/scsi/a100u2w.c b/drivers/scsi/a100u2w.c
old mode 100644
new mode 100755
index 0163457..db3710f
--- a/drivers/scsi/a100u2w.c
+++ b/drivers/scsi/a100u2w.c
@@ -1227,19 +1227,9 @@ static struct pci_driver inia100_pci_driver = {
.remove = inia100_remove_one,
};
-static int __init inia100_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit inia100_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
+module_pci_driver(inia100_pci_driver);
MODULE_DESCRIPTION("Initio A100U2W SCSI driver");
MODULE_AUTHOR("Initio Corporation");
MODULE_LICENSE("Dual BSD/GPL");
-module_init(inia100_init);
-module_exit(inia100_exit);
--
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 02/24] drivers/scsi/dc395x: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/scsi/dc395x.c | 24 +---
1 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
old mode 100644
new mode 100755
index 694e13c..e73445b
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -4882,29 +4882,7 @@ static struct pci_driver dc395x_driver = {
.remove = dc395x_remove_one,
};
-
-/**
- * dc395x_module_init - Module initialization function
- *
- * Used by both module and built-in driver to initialise this driver.
- **/
-static int __init dc395x_module_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-
-/**
- * dc395x_module_exit - Module cleanup function.
- **/
-static void __exit dc395x_module_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-
-module_init(dc395x_module_init);
-module_exit(dc395x_module_exit);
+module_pci_driver(dc395x_driver);
MODULE_AUTHOR("C.L. Huang / Erich Chen / Kurt Garloff");
MODULE_DESCRIPTION("SCSI host adapter driver for Tekram TRM-S1040 based
adapters: Tekram DC395 and DC315 series");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG_ON in virtio-ring.c
Dave Airlie writes: > Hi Rusty, > > current virtio-ring.c has a BUG_ON in virtqueue_add that checks > total_sg > vg->vring.num, however I'm not sure it really is 100% > correct. > > If I have an indirect ring and I'm adding sgs to it and the host is > delayed (say I've got a thread consuming things from the vring and its > off doing something interesting), > I'd really like to get ENOSPC back from virtqueue_add. However if the > indirect addition fails due to free_sg being 0, we hit the BUG_ON > before we ever get to the ENOSPC check. It is correct for the moment: drivers can't assume indirect buffer support in the transport. BUT for a new device, we could say "this depends on indirect descriptor support", put the appropriate check in the device init, and then remove the BUG_ON(). > the BUG_ON is quite valid in the no indirect case, but when we have > indirect buffers it doesn't seem like it always makes sense. > > Not sure best way to fix it, I'm just a virtio newbie :) Mailing me and the list was the right thing, since this raises question of the spec as well as the Linux implementation. Good luck! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/25/2013 12:45 PM, David Gibson wrote:
> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
>> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
>>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>>> index 8465c2a..da6bf61 100644
>>> --- a/arch/powerpc/kvm/powerpc.c
>>> @@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>> +++ b/arch/powerpc/kvm/powerpc.c
>>> break;
>>> #endif
>>> case KVM_CAP_SPAPR_MULTITCE:
>>> + case KVM_CAP_SPAPR_TCE_IOMMU:
>>> r = 1;
>>> break;
>>> default:
>>
>> Don't advertise SPAPR capabilities if it's not book3s -- and
>> probably there's some additional limitation that would be
>> appropriate.
>
> So, in the case of MULTITCE, that's not quite right. PR KVM can
> emulate a PAPR system on a BookE machine, and there's no reason not to
> allow TCE acceleration as well. We can't make it dependent on PAPR
> mode being selected, because that's enabled per-vcpu, whereas these
> capabilities are queried on the VM before the vcpus are created.
>
> CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable
> host side hardware (i.e. a PAPR style IOMMU), though.
The capability says that the ioctl is supported. If there is no IOMMU group
registered, than it will fail with a reasonable error and nobody gets hurt.
What is the problem?
>>
>>> @@ -1025,6 +1026,17 @@ long kvm_arch_vm_ioctl(struct file *filp,
>>> r = kvm_vm_ioctl_create_spapr_tce(kvm, _tce);
>>> goto out;
>>> }
>>> + case KVM_CREATE_SPAPR_TCE_IOMMU: {
>>> + struct kvm_create_spapr_tce_iommu create_tce_iommu;
>>> + struct kvm *kvm = filp->private_data;
>>> +
>>> + r = -EFAULT;
>>> + if (copy_from_user(_tce_iommu, argp,
>>> + sizeof(create_tce_iommu)))
>>> + goto out;
>>> + r = kvm_vm_ioctl_create_spapr_tce_iommu(kvm,
>>> _tce_iommu);
>>> + goto out;
>>> + }
>>> #endif /* CONFIG_PPC_BOOK3S_64 */
>>>
>>> #ifdef CONFIG_KVM_BOOK3S_64_HV
>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>> index 5a2afda..450c82a 100644
>>> --- a/include/uapi/linux/kvm.h
>>> +++ b/include/uapi/linux/kvm.h
>>> @@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
>>> #define KVM_CAP_PPC_RTAS 91
>>> #define KVM_CAP_IRQ_XICS 92
>>> #define KVM_CAP_SPAPR_MULTITCE (0x11 + 89)
>>> +#define KVM_CAP_SPAPR_TCE_IOMMU (0x11 + 90)
>>
>> Hmm...
>
> Ah, yeah, that needs to be fixed. Those were interim numbers so that
> we didn't have to keep changing our internal trees as new upstream
> ioctls got added to the list. We need to get a proper number for the
> merge, though.
>
>>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>>> kvm_device_attr)
>>> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
>>> kvm_device_attr)
>>>
>>> +/* ioctl for SPAPR TCE IOMMU */
>>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct
>>> kvm_create_spapr_tce_iommu)
>>
>> Shouldn't this go under the vm ioctl section?
The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated devices) is
in this section so I decided to keep them together. Wrong?
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/25] Convert to module_pci_driver replace init/exit
sorry, only 24! On 2013/5/27 10:28, Libo Chen wrote: > use module_pci_driver instead of init/exit, make code clean. > > Libo Chen (25): > drivers/scsi/a100u2w: Convert to module_pci_driver replace init/exit > drivers/scsi/dc395x: Convert to module_pci_driver > drivers/scsi/dmx3191d: Convert to module_pci_driver > drivers/scsi/initio: Convert to module_pci_driver > drivers/scsi/mvumi: Convert to module_pci_driver > drivers/net/irda/donauboe: Convert to module_pci_driver > drivers/ide/delkin_cb: Convert to module_pci_driver > drivers/atm/he: Convert to module_pci_driver > drivers/pci/ioapic: Convert to module_pci_driver > drivers/mfd/lpc_ich: Convert to module_pci_driver > drivers/ptp/ptp_pch: Convert to module_pci_driver > drivers/memstick/host/r592: Convert to module_pci_driver > drivers/parisc/superio: Convert to module_pci_driver please, drop it had been changed in upstream. > drivers/uwb/whci: Convert to module_pci_driver > drivers/platform/x86/intel_ips: Convert to module_pci_driver > drivers/memstick/host/jmb38x_ms: Convert to module_pci_driver > drivers/media/pci/mantis/mantis_cards: Convert to module_pci_driver > drivers/media/pci/dm1105/dm1105: Convert to module_pci_driver > drivers/media/pci/mantis/hopper_cards: Convert to module_pci_driver > drivers/media/pci/dm1105/dm1105: Convert to module_pci_driver2 > drivers/media/pci/pluto2/pluto2: Convert to module_pci_driver > drivers/media/pci/pt1/pt1: Convert to module_pci_driver > drivers/media/radio/radio-maxiradio: Convert to module_pci_driver > drivers/pcmcia/pd6729: Convert to module_pci_driver > drivers/pcmcia/yenta_socket: Convert to module_pci_driver > > drivers/atm/he.c| 13 + > drivers/ide/delkin_cb.c | 13 + > drivers/media/pci/b2c2/flexcop-pci.c| 13 + > drivers/media/pci/dm1105/dm1105.c | 13 + > drivers/media/pci/mantis/hopper_cards.c | 13 + > drivers/media/pci/mantis/mantis_cards.c | 13 + > drivers/media/pci/pluto2/pluto2.c | 13 + > drivers/media/pci/pt1/pt1.c | 15 +-- > drivers/media/radio/radio-maxiradio.c | 13 + > drivers/memstick/host/jmb38x_ms.c | 13 + > drivers/memstick/host/r592.c| 13 + > drivers/mfd/lpc_ich.c | 13 + > drivers/net/irda/donauboe.c | 15 +-- > drivers/parisc/superio.c|1 - > drivers/pci/ioapic.c| 13 + > drivers/pcmcia/pd6729.c | 13 + > drivers/pcmcia/yenta_socket.c | 16 +--- > drivers/platform/x86/intel_ips.c| 13 + > drivers/ptp/ptp_pch.c | 18 +- > drivers/scsi/a100u2w.c | 12 +--- > drivers/scsi/dc395x.c | 24 +--- > drivers/scsi/dmx3191d.c | 13 + > drivers/scsi/initio.c | 13 + > drivers/scsi/mvumi.c| 20 +--- > drivers/uwb/whci.c | 13 + > 25 files changed, 24 insertions(+), 318 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/
[PATCH 19/24] drivers/media/pci/dm1105/dm1105: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/media/pci/dm1105/dm1105.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/dm1105/dm1105.c
b/drivers/media/pci/dm1105/dm1105.c
index 026767b..ab797fe 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -1241,18 +1241,7 @@ static struct pci_driver dm1105_driver = {
.remove = dm1105_remove,
};
-static int __init dm1105_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-static void __exit dm1105_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-module_init(dm1105_init);
-module_exit(dm1105_exit);
+module_pci_driver(dm1105_driver);
MODULE_AUTHOR("Igor M. Liplianin ");
MODULE_DESCRIPTION("SDMC DM1105 DVB driver");
--
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 18/24] drivers/media/pci/mantis/hopper_cards: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/media/pci/mantis/hopper_cards.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/mantis/hopper_cards.c
b/drivers/media/pci/mantis/hopper_cards.c
index 6fe9fe5..104914a 100644
--- a/drivers/media/pci/mantis/hopper_cards.c
+++ b/drivers/media/pci/mantis/hopper_cards.c
@@ -260,18 +260,7 @@ static struct pci_driver hopper_pci_driver = {
.remove = hopper_pci_remove,
};
-static int hopper_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void hopper_exit(void)
-{
- return pci_unregister_driver(_pci_driver);
-}
-
-module_init(hopper_init);
-module_exit(hopper_exit);
+module_pci_driver(hopper_pci_driver);
MODULE_DESCRIPTION("HOPPER driver");
MODULE_AUTHOR("Manu Abraham");
--
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 13/24] drivers/uwb/whci: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/uwb/whci.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/uwb/whci.c b/drivers/uwb/whci.c
index f48093e..deeeba4 100644
--- a/drivers/uwb/whci.c
+++ b/drivers/uwb/whci.c
@@ -253,18 +253,7 @@ static struct pci_driver whci_driver = {
.remove = whci_remove,
};
-static int __init whci_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-static void __exit whci_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-module_init(whci_init);
-module_exit(whci_exit);
+module_pci_driver(whci_driver);
MODULE_DESCRIPTION("WHCI UWB Multi-interface Controller enumerator");
MODULE_AUTHOR("Cambridge Silicon Radio Ltd.");
--
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 15/24] drivers/memstick/host/jmb38x_ms: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/memstick/host/jmb38x_ms.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/memstick/host/jmb38x_ms.c
b/drivers/memstick/host/jmb38x_ms.c
index c37d375..aeabaa5 100644
--- a/drivers/memstick/host/jmb38x_ms.c
+++ b/drivers/memstick/host/jmb38x_ms.c
@@ -1046,20 +1046,9 @@ static struct pci_driver jmb38x_ms_driver = {
.resume = jmb38x_ms_resume
};
-static int __init jmb38x_ms_init(void)
-{
- return pci_register_driver(_ms_driver);
-}
-
-static void __exit jmb38x_ms_exit(void)
-{
- pci_unregister_driver(_ms_driver);
-}
+module_pci_driver(jmb38x_ms_driver);
MODULE_AUTHOR("Alex Dubov");
MODULE_DESCRIPTION("JMicron jmb38x MemoryStick driver");
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, jmb38x_ms_id_tbl);
-
-module_init(jmb38x_ms_init);
-module_exit(jmb38x_ms_exit);
--
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 08/24] drivers/atm/he: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/atm/he.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 507362a..80f9743 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -2872,15 +2872,4 @@ static struct pci_driver he_driver = {
.id_table = he_pci_tbl,
};
-static int __init he_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-static void __exit he_cleanup(void)
-{
- pci_unregister_driver(_driver);
-}
-
-module_init(he_init);
-module_exit(he_cleanup);
+module_pci_driver(he_driver);
--
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 17/24] drivers/media/pci/dm1105/dm1105: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/media/pci/b2c2/flexcop-pci.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/b2c2/flexcop-pci.c
b/drivers/media/pci/b2c2/flexcop-pci.c
index 44f8fb5..447afbd 100644
--- a/drivers/media/pci/b2c2/flexcop-pci.c
+++ b/drivers/media/pci/b2c2/flexcop-pci.c
@@ -432,18 +432,7 @@ static struct pci_driver flexcop_pci_driver = {
.remove = flexcop_pci_remove,
};
-static int __init flexcop_pci_module_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit flexcop_pci_module_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
-module_init(flexcop_pci_module_init);
-module_exit(flexcop_pci_module_exit);
+module_pci_driver(flexcop_pci_driver);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_NAME);
--
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 21/24] drivers/media/pci/pt1/pt1: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/media/pci/pt1/pt1.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
index e921108..75ce142 100644
--- a/drivers/media/pci/pt1/pt1.c
+++ b/drivers/media/pci/pt1/pt1.c
@@ -1225,20 +1225,7 @@ static struct pci_driver pt1_driver = {
.id_table = pt1_id_table,
};
-
-static int __init pt1_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-
-static void __exit pt1_cleanup(void)
-{
- pci_unregister_driver(_driver);
-}
-
-module_init(pt1_init);
-module_exit(pt1_cleanup);
+module_pci_driver(pt1_driver);
MODULE_AUTHOR("Takahito HIRANO ");
MODULE_DESCRIPTION("Earthsoft PT1/PT2 Driver");
--
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 22/24] drivers/media/radio/radio-maxiradio: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean
Signed-off-by: Libo Chen
---
drivers/media/radio/radio-maxiradio.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/radio/radio-maxiradio.c
b/drivers/media/radio/radio-maxiradio.c
index bd4d3a7..1d1c9e1 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -200,15 +200,4 @@ static struct pci_driver maxiradio_driver = {
.remove = maxiradio_remove,
};
-static int __init maxiradio_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-static void __exit maxiradio_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-module_init(maxiradio_init);
-module_exit(maxiradio_exit);
+module_pci_driver(maxiradio_driver);
--
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 24/24] drivers/pcmcia/yenta_socket: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/pcmcia/yenta_socket.c | 16 +---
1 files changed, 1 insertions(+), 15 deletions(-)
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index 6b4ff09..dc18a3a 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -1439,20 +1439,6 @@ static struct pci_driver yenta_cardbus_driver = {
.driver.pm = YENTA_PM_OPS,
};
-
-static int __init yenta_socket_init(void)
-{
- return pci_register_driver(_cardbus_driver);
-}
-
-
-static void __exit yenta_socket_exit(void)
-{
- pci_unregister_driver(_cardbus_driver);
-}
-
-
-module_init(yenta_socket_init);
-module_exit(yenta_socket_exit);
+module_pci_driver(yenta_cardbus_driver);
MODULE_LICENSE("GPL");
--
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 20/24] drivers/media/pci/pluto2/pluto2: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/media/pci/pluto2/pluto2.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/pluto2/pluto2.c
b/drivers/media/pci/pluto2/pluto2.c
index 2290fae..4938285 100644
--- a/drivers/media/pci/pluto2/pluto2.c
+++ b/drivers/media/pci/pluto2/pluto2.c
@@ -796,18 +796,7 @@ static struct pci_driver pluto2_driver = {
.remove = pluto2_remove,
};
-static int __init pluto2_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-static void __exit pluto2_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-module_init(pluto2_init);
-module_exit(pluto2_exit);
+module_pci_driver(pluto2_driver);
MODULE_AUTHOR("Andreas Oberritter ");
MODULE_DESCRIPTION("Pluto2 driver");
--
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 23/24] drivers/pcmcia/pd6729: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/pcmcia/pd6729.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/pcmcia/pd6729.c b/drivers/pcmcia/pd6729.c
index b29d97e..9a7fc88 100644
--- a/drivers/pcmcia/pd6729.c
+++ b/drivers/pcmcia/pd6729.c
@@ -775,15 +775,4 @@ static struct pci_driver pd6729_pci_driver = {
.remove = pd6729_pci_remove,
};
-static int pd6729_module_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void pd6729_module_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
-module_init(pd6729_module_init);
-module_exit(pd6729_module_exit);
+module_pci_driver(pd6729_pci_driver);
--
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 14/24] drivers/platform/x86/intel_ips: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/platform/x86/intel_ips.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c
index 5051aa9..18dcb58 100644
--- a/drivers/platform/x86/intel_ips.c
+++ b/drivers/platform/x86/intel_ips.c
@@ -1731,18 +1731,7 @@ static struct pci_driver ips_pci_driver = {
.shutdown = ips_shutdown,
};
-static int __init ips_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-module_init(ips_init);
-
-static void ips_exit(void)
-{
- pci_unregister_driver(_pci_driver);
- return;
-}
-module_exit(ips_exit);
+module_pci_driver(ips_pci_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jesse Barnes ");
--
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 16/24] drivers/media/pci/mantis/mantis_cards: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean
Signed-off-by: Libo Chen
---
drivers/media/pci/mantis/mantis_cards.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/mantis/mantis_cards.c
b/drivers/media/pci/mantis/mantis_cards.c
index 932a0d7..801fc55 100644
--- a/drivers/media/pci/mantis/mantis_cards.c
+++ b/drivers/media/pci/mantis/mantis_cards.c
@@ -290,18 +290,7 @@ static struct pci_driver mantis_pci_driver = {
.remove = mantis_pci_remove,
};
-static int mantis_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void mantis_exit(void)
-{
- return pci_unregister_driver(_pci_driver);
-}
-
-module_init(mantis_init);
-module_exit(mantis_exit);
+module_pci_driver(mantis_pci_driver);
MODULE_DESCRIPTION("MANTIS driver");
MODULE_AUTHOR("Manu Abraham");
--
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 10/24] drivers/mfd/lpc_ich: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/mfd/lpc_ich.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
index 9f12f91..06431df 100644
--- a/drivers/mfd/lpc_ich.c
+++ b/drivers/mfd/lpc_ich.c
@@ -973,18 +973,7 @@ static struct pci_driver lpc_ich_driver = {
.remove = lpc_ich_remove,
};
-static int __init lpc_ich_init(void)
-{
- return pci_register_driver(_ich_driver);
-}
-
-static void __exit lpc_ich_exit(void)
-{
- pci_unregister_driver(_ich_driver);
-}
-
-module_init(lpc_ich_init);
-module_exit(lpc_ich_exit);
+module_pci_driver(lpc_ich_driver);
MODULE_AUTHOR("Aaron Sierra ");
MODULE_DESCRIPTION("LPC interface for Intel ICH");
--
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 11/24] drivers/ptp/ptp_pch: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean
Signed-off-by: Libo Chen
---
drivers/ptp/ptp_pch.c | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index bea9451..e63ca00 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -705,23 +705,7 @@ static struct pci_driver pch_driver = {
.resume = pch_resume,
};
-static void __exit ptp_pch_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-static s32 __init ptp_pch_init(void)
-{
- s32 ret;
-
- /* register the driver with the pci core */
- ret = pci_register_driver(_driver);
-
- return ret;
-}
-
-module_init(ptp_pch_init);
-module_exit(ptp_pch_exit);
+module_pci_driver(pch_driver);
module_param_string(station,
pch_param.station, sizeof(pch_param.station), 0444);
--
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 04/24] drivers/scsi/initio: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/scsi/initio.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
old mode 100644
new mode 100755
index 280d5af..1befc26
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2995,19 +2995,8 @@ static struct pci_driver initio_pci_driver = {
.remove = initio_remove_one,
};
-static int __init initio_init_driver(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit initio_exit_driver(void)
-{
- pci_unregister_driver(_pci_driver);
-}
+module_pci_driver(initio_pci_driver);
MODULE_DESCRIPTION("Initio INI-9X00U/UW SCSI device driver");
MODULE_AUTHOR("Initio Corporation");
MODULE_LICENSE("GPL");
-
-module_init(initio_init_driver);
-module_exit(initio_exit_driver);
--
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 06/24] drivers/net/irda/donauboe: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/net/irda/donauboe.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/net/irda/donauboe.c b/drivers/net/irda/donauboe.c
old mode 100644
new mode 100755
index 510b9c8..c6bfc4a
--- a/drivers/net/irda/donauboe.c
+++ b/drivers/net/irda/donauboe.c
@@ -1755,17 +1755,4 @@ static struct pci_driver donauboe_pci_driver = {
.resume = toshoboe_wakeup
};
-static int __init
-donauboe_init (void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit
-donauboe_cleanup (void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
-module_init(donauboe_init);
-module_exit(donauboe_cleanup);
+module_pci_driver(donauboe_pci_driver);
--
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 01/24] drivers/scsi/a100u2w: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
---
drivers/scsi/a100u2w.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/a100u2w.c b/drivers/scsi/a100u2w.c
old mode 100644
new mode 100755
index 0163457..db3710f
--- a/drivers/scsi/a100u2w.c
+++ b/drivers/scsi/a100u2w.c
@@ -1227,19 +1227,9 @@ static struct pci_driver inia100_pci_driver = {
.remove = inia100_remove_one,
};
-static int __init inia100_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit inia100_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
+module_pci_driver(inia100_pci_driver);
MODULE_DESCRIPTION("Initio A100U2W SCSI driver");
MODULE_AUTHOR("Initio Corporation");
MODULE_LICENSE("Dual BSD/GPL");
-module_init(inia100_init);
-module_exit(inia100_exit);
--
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 05/24] drivers/scsi/mvumi: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/scsi/mvumi.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
old mode 100644
new mode 100755
index c3601b5..d0b6a03
--- a/drivers/scsi/mvumi.c
+++ b/drivers/scsi/mvumi.c
@@ -2735,22 +2735,4 @@ static struct pci_driver mvumi_pci_driver = {
#endif
};
-/**
- * mvumi_init - Driver load entry point
- */
-static int __init mvumi_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-/**
- * mvumi_exit - Driver unload entry point
- */
-static void __exit mvumi_exit(void)
-{
-
- pci_unregister_driver(_pci_driver);
-}
-
-module_init(mvumi_init);
-module_exit(mvumi_exit);
+module_pci_driver(mvumi_pci_driver);
--
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 07/24] drivers/ide/delkin_cb: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/ide/delkin_cb.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/ide/delkin_cb.c b/drivers/ide/delkin_cb.c
index 7e27d32..300daab 100644
--- a/drivers/ide/delkin_cb.c
+++ b/drivers/ide/delkin_cb.c
@@ -173,18 +173,7 @@ static struct pci_driver delkin_cb_pci_driver = {
.resume = delkin_cb_resume,
};
-static int __init delkin_cb_init(void)
-{
- return pci_register_driver(_cb_pci_driver);
-}
-
-static void __exit delkin_cb_exit(void)
-{
- pci_unregister_driver(_cb_pci_driver);
-}
-
-module_init(delkin_cb_init);
-module_exit(delkin_cb_exit);
+module_pci_driver(delkin_cb_pci_driver);
MODULE_AUTHOR("Mark Lord");
MODULE_DESCRIPTION("Basic support for Delkin/ASKA/Workbit Cardbus IDE");
--
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 09/24] drivers/pci/ioapic: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/pci/ioapic.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
index 3c6bbdd..1b90579 100644
--- a/drivers/pci/ioapic.c
+++ b/drivers/pci/ioapic.c
@@ -113,17 +113,6 @@ static struct pci_driver ioapic_driver = {
.remove = ioapic_remove,
};
-static int __init ioapic_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-static void __exit ioapic_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-module_init(ioapic_init);
-module_exit(ioapic_exit);
+module_pci_driver(ioapic_driver);
MODULE_LICENSE("GPL");
--
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 12/24] drivers/memstick/host/r592: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/memstick/host/r592.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/memstick/host/r592.c b/drivers/memstick/host/r592.c
index 9718661..1b6e913 100644
--- a/drivers/memstick/host/r592.c
+++ b/drivers/memstick/host/r592.c
@@ -884,18 +884,7 @@ static struct pci_driver r852_pci_driver = {
.driver.pm = _pm_ops,
};
-static __init int r592_module_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit r592_module_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
-module_init(r592_module_init);
-module_exit(r592_module_exit);
+module_pci_driver(r852_pci_driver);
module_param_named(enable_dma, r592_enable_dma, bool, S_IRUGO);
MODULE_PARM_DESC(enable_dma, "Enable usage of the DMA (default)");
--
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 03/24] drivers/scsi/dmx3191d: Convert to module_pci_driver
use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen
---
drivers/scsi/dmx3191d.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/dmx3191d.c b/drivers/scsi/dmx3191d.c
old mode 100644
new mode 100755
index 4b0dd8c..bb28062
--- a/drivers/scsi/dmx3191d.c
+++ b/drivers/scsi/dmx3191d.c
@@ -153,18 +153,7 @@ static struct pci_driver dmx3191d_pci_driver = {
.remove = dmx3191d_remove_one,
};
-static int __init dmx3191d_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit dmx3191d_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
-module_init(dmx3191d_init);
-module_exit(dmx3191d_exit);
+module_pci_driver(dmx3191d_pci_driver);
MODULE_AUTHOR("Massimo Piccioni ");
MODULE_DESCRIPTION("Domex DMX3191D SCSI driver");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 04/11] KVM: MMU: zap pages in batch
On 05/25/2013 04:34 AM, Marcelo Tosatti wrote: > On Thu, May 23, 2013 at 03:55:53AM +0800, Xiao Guangrong wrote: >> Zap at lease 10 pages before releasing mmu-lock to reduce the overload >> caused by requiring lock >> >> After the patch, kvm_zap_obsolete_pages can forward progress anyway, >> so update the comments >> >> [ It improves kernel building 0.6% ~ 1% ] > > Can you please describe the overload in more detail? Under what scenario > is kernel building improved? Yes. The scenario is we do kernel building, meanwhile, repeatedly read PCI rom every one second. [ echo 1 > /sys/bus/pci/devices/\:00\:03.0/rom cat /sys/bus/pci/devices/\:00\:03.0/rom > /dev/null ] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the crypto tree
On Fri, May 24, 2013 at 05:57:15PM +0800, Herbert Xu wrote:
> On Tue, May 21, 2013 at 11:45:48AM +1000, Stephen Rothwell wrote:
> > Hi Herbert,
> >
> > After merging the crypto tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > arch/x86/crypto/crct10dif-pclmul_glue.c: In function
> > 'crct10dif_intel_mod_init':
> > arch/x86/crypto/crct10dif-pclmul_glue.c:140:3: error: implicit declaration
> > of function 'crc_t10dif_update_lib' [-Werror=implicit-function-declaration]
> >crc_t10dif_update_lib();
> >^
> > cc1: some warnings being treated as errors
> >
> > Caused by commit b85ed9f056ee ("crypto: crct10dif - Glue code to cast
> > accelerated CRCT10DIF assembly as a crypto transform").
> >
> > I have used the version of the crypto tree from next-20130520 for today.
>
> Sorry for the late response, it should be fixed now.
Hi Stephen, did you get a chance to switch back to the current
cryptodev tree?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] Documentation/devices.txt: Mark /dev/oldmem obsolete
(2013/05/27 10:54), Zhang Yanfei wrote: 于 2013年05月27日 09:46, HATAYAMA Daisuke 写道: (2013/05/26 15:36), Zhang Yanfei wrote: From: Zhang Yanfei Signed-off-by: Zhang Yanfei Cc: Dave Jones --- Documentation/devices.txt |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 08f01e7..c8e4002 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -100,8 +100,7 @@ Your cooperation is appreciated. 10 = /dev/aioAsynchronous I/O notification interface 11 = /dev/kmsgWrites to this come out as printk's, reads export the buffered printk records. - 12 = /dev/oldmemUsed by crashdump kernels to access -the memory of the kernel that crashed. + 12 = /dev/oldmemOBSOLETE 1 blockRAM disk 0 = /dev/ram0First RAM disk This is the new patch. Looking at other parts of devices.txt, obsolete is sometimes used together with unused. I guess obsolete means this is old interface so don't use it as much as possible and unused means this is not used at all now. You remove old memory interface completely in this patch set, so is it better to add unused, too? Does obsolete also mean "not used anymore"? I don't know. I think we can wait for some native English speakers to comment on this. Yes. To be honest, I'm still suspecting "unused" doesn't include meaning of "removed"... -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3 v3] dcache: make it more scalable on large system
On Thu, May 23, 2013 at 05:34:23PM -0400, Waiman Long wrote: > On 05/23/2013 05:42 AM, Dave Chinner wrote: > >On Wed, May 22, 2013 at 09:37:25PM -0400, Waiman Long wrote: > >>Change log: > >> > >>v2->v3 > >> - Fix the RCU lock problem found by Al Viro. > >> - Rebase the code to the latest v3.10-rc1 linux mainline. > >> - Remove patch 4 which may be problematic if the dentry is deleted. > >> - Rerun performance measurement using 3.10-rc1 kernel. > >> > >>v1->v2 > >> - Include performance improvement in the AIM7 benchmark results because > >>of this patch. > >> - Modify dget_parent() to avoid taking the lock, if possible, to further > >>improve AIM7 benchmark results. > >> > >>During some perf-record sessions of the kernel running the high_systime > >>workload of the AIM7 benchmark, it was found that quite a large portion > >>of the spinlock contention was due to the perf_event_mmap_event() > >>function itself. This perf kernel function calls d_path() which, > >>in turn, call path_get() and dput() indirectly. These 3 functions > >>were the hottest functions shown in the perf-report output of > >>the _raw_spin_lock() function in an 8-socket system with 80 cores > >>(hyperthreading off) with a 3.10-rc1 kernel: > >What was it I said about this patchset when you posted it to speed > >up an Oracle benchmark back in february? I'll repeat: > > > >"Nobody should be doing reverse dentry-to-name lookups in a quantity > >sufficient for it to become a performance limiting factor." > > Thank for the comment, but my point is that it is the d_lock > contention is skewing the data about how much spin lock contention > had actually happened in the workload and it makes it harder to > pinpoint problem areas to look at. This is not about performance, it > is about accurate representation of performance data. Ideally, we > want the overhead of turning on perf instrumentation to be as low as > possible. Right. But d_path will never be "low overhead", and as such it shouldn't be used by perf. > >And that makes whatever that tracepoint is doing utterly stupid. > >Dumping out full paths in a tracepoint is hardly "low overhead", and > >that tracepoint should be stomped on from a great height. Sure, > >print the filename straight out of the dentry into a tracepoint, > >but repeated calculating the full path (probably for the same set of > >dentries) is just a dumb thing to do. > > > >Anyway, your numbers show that a single AIM7 microbenchmark goes > >better under tracing the specific mmap event that uses d_path(), but > >the others are on average a little bit slower. That doesn't convince > >me that this is worth doing. Indeed, what happens to performance > >when you aren't tracing? > > > >Indeed, have you analysed what makes that > >microbenchmark contend so much on the dentry lock while reverse > >lookups are occuring? Dentry lock contention does not necessarily > >indicate a problem with the dentry locks, and without knowing why > >there is contention occuring (esp. compared to the other benchmarks) > >we can't really determine if this is a good solution or not... > > What made it contend so much was the large number of CPUs available > in my test system which is a 8-socket Westmere EX machines with 80 > cores. As perf was collecting data from every core, the threads will > unavoidably bump into each other to translate dentries back to the > full paths. The current code only allows one CPU in the d_path() > critical path. My patch will allow all of them to be in the critical > path concurrently. Yes, I know *how* contention occurs and what your patch does. I'm asking you to explain *why* we need to fix this specific workload, and why the tracepoint that calls d_path() actually needs to do that. Your numbers indicate that your patchset decreases peformance in the common, non-d_path intensive workloads, so why should we add all this complexity to optimise a slow path at the expense of significant complexity and lower performance in the fast path? > The upcoming Ivy-Bridge EX can have up to 15 cores per socket. So > even a 4-socket machine will have up to 60 cores or 120 virtual CPUs > if hyperthreading is turned on. I don't see why that matters. I've been dealing with systems much larger than that since early 2002, adn the process for delaing with lock contention hasn't changed much in the last 10 years. First we need to determine what you are doing is something that is sane, determining whether there's a simpler fix than changing locking, and whether it's actually any faster in the common case we care about > >IOWs, you need more than one microbenchmark that interacts with > >some naive monitoring code to justify the complexity these locking > >changes introduce > The first patch can also independently improve the performance of a > number of AIM7 workloads including almost 7X improvement in the > short workload. More detailed information of these types of > performance benefit was discussed in the
[PATCH V2] ARM: EXYNOS: add PM dependency to PM_GENERIC_DOMAINS
PM_GENERIC_DOMAINS needs PM dependency. Fixed build warning as below: warning: (PLAT_S3C64XX && CPU_EXYNOS4210) selects PM_GENERIC_DOMAINS which has unmet direct dependencies (PM) warning: (PLAT_S3C64XX && CPU_EXYNOS4210) selects PM_GENERIC_DOMAINS which has unmet direct dependencies (PM) arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp] drivers/base/power/domain.c: In function '__pm_genpd_add_device': drivers/base/power/domain.c:1422:2: error: implicit declaration of function 'genpd_acquire_lock' [-Werror=implicit-function-declaration] drivers/base/power/domain.c:1466:2: error: implicit declaration of function 'genpd_release_lock' [-Werror=implicit-function-declaration] drivers/base/power/domain.c: In function 'pm_genpd_add_subdomain': drivers/base/power/domain.c:1649:3: error: implicit declaration of function 'genpd_sd_counter_inc' [-Werror=implicit-function-declaration] drivers/base/power/domain.c: In function 'pm_genpd_remove_subdomain': drivers/base/power/domain.c:1721:4: error: implicit declaration of function 'genpd_sd_counter_dec' [-Werror=implicit-function-declaration] drivers/base/power/domain.c: In function 'pm_genpd_attach_cpuidle': drivers/base/power/domain.c:1887:2: error: implicit declaration of function 'genpd_recalc_cpu_exit_latency' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Signed-off-by: Jingoo Han --- Changes since v1: - Fixed PLAT_S3C64XX together as Kukjin Kim mentioned arch/arm/mach-exynos/Kconfig |2 +- arch/arm/mach-s3c64xx/Kconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 6e77432..352e8d0 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -34,7 +34,7 @@ config CPU_EXYNOS4210 default y depends on ARCH_EXYNOS4 select ARM_CPU_SUSPEND if PM - select PM_GENERIC_DOMAINS + select PM_GENERIC_DOMAINS if PM select S5P_PM if PM select S5P_SLEEP if PM select SAMSUNG_DMADEV diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig index 2057853..c04c4ee 100644 --- a/arch/arm/mach-s3c64xx/Kconfig +++ b/arch/arm/mach-s3c64xx/Kconfig @@ -8,7 +8,7 @@ config PLAT_S3C64XX bool depends on ARCH_S3C64XX default y - select PM_GENERIC_DOMAINS + select PM_GENERIC_DOMAINS if PM select SAMSUNG_WAKEMASK help Base platform code for any Samsung S3C64XX device -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] ipc/sem.c: Bug fixes, regression fixes, v3
On Sun, May 26, 2013 at 11:08:51AM +0200, Manfred Spraul wrote: > I've split my patch into 4 parts: > - 1: Fix-missing-wakeups-in-do_smart_update > - 2: seperate-wait-for-zero-and-alter-tasks > - 3: Always-use-only-one-queue-for-alter-operations > - 4: Rename-try_atomic_semop-to-perform_atomic > > Linus: > - Patch 1 should be merged immediately: It fixes bugs, > the current code misses wakeups. Should this patch be backported to 3.9 and maybe older kernels as well? 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 v7 03/11] KVM: MMU: fast invalidate all pages
Hi Marcelo,
On 05/25/2013 04:23 AM, Marcelo Tosatti wrote:
>> +static void kvm_zap_obsolete_pages(struct kvm *kvm)
>> +{
>> +struct kvm_mmu_page *sp, *node;
>> +LIST_HEAD(invalid_list);
>> +
>> +restart:
>> +list_for_each_entry_safe_reverse(sp, node,
>> + >arch.active_mmu_pages, link) {
>> +/*
>> + * No obsolete page exists before new created page since
>> + * active_mmu_pages is the FIFO list.
>> + */
>> +if (!is_obsolete_sp(kvm, sp))
>> +break;
>
> Can you add a comment to list_add(x, active_mmu_pages) callsites
> mentioning this case?
>
> Because it'll break silently if people do list_add_tail().
Sure, I will do it in the next version.
And i totally agree with Gleb's points that reply your other questions
in this patch.
Thank you all!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch: arm64: kernel: sprintf(), 'str' needs additional 1 byte for failure processing
When failure occurs at the last looping cycle (when 'i == 0'), it will
print "bad PC value" instead of "(%08x) ", which needs additional 1
byte.
If not add 1 byte, the 'str' may be memory overflow.
Signed-off-by: Chen Gang
---
arch/arm64/kernel/traps.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 61d7dd2..c2f68d2 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -100,7 +100,7 @@ static void dump_instr(const char *lvl, struct pt_regs
*regs)
{
unsigned long addr = instruction_pointer(regs);
mm_segment_t fs;
- char str[sizeof(" ") * 5 + 2 + 1], *p = str;
+ char str[sizeof(" ") * 5 + 2 + 1 + 1], *p = str;
int i;
/*
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] Documentation/devices.txt: Mark /dev/oldmem obsolete
于 2013年05月27日 09:46, HATAYAMA Daisuke 写道: > (2013/05/26 15:36), Zhang Yanfei wrote: >> From: Zhang Yanfei >> >> Signed-off-by: Zhang Yanfei >> Cc: Dave Jones >> --- >> Documentation/devices.txt |3 +-- >> 1 files changed, 1 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devices.txt b/Documentation/devices.txt >> index 08f01e7..c8e4002 100644 >> --- a/Documentation/devices.txt >> +++ b/Documentation/devices.txt >> @@ -100,8 +100,7 @@ Your cooperation is appreciated. >>10 = /dev/aioAsynchronous I/O notification interface >>11 = /dev/kmsgWrites to this come out as printk's, reads >> export the buffered printk records. >> - 12 = /dev/oldmemUsed by crashdump kernels to access >> -the memory of the kernel that crashed. >> + 12 = /dev/oldmemOBSOLETE >> >> 1 blockRAM disk >> 0 = /dev/ram0First RAM disk >> > > This is the new patch. Looking at other parts of devices.txt, obsolete is > sometimes used together with unused. I guess obsolete means this is old > interface so > don't use it as much as possible and unused means this is not used at all now. > You remove old memory interface completely in this patch set, so is it better > to add > unused, too? > Does obsolete also mean "not used anymore"? I don't know. I think we can wait for some native English speakers to comment on this. Thanks 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/
Re: Weird disk idling
Am 26.05.2013 07:29, schrieb Fredrik Tolf: > I'm sure you all know what the various fields are (except the first, Hmm, I had to look at Documentation/block/stat.txt. > which is just a timestamp), so as you can see, there are 135 requests in > the queue, but no reads or writes happen, in this case, for at least 800 > ms. > > Is this behavior normal and expected, or is there something wrong here? > In the latter case, is it my hardware that is failing somehow, or can > there be some software weirdness that can be tweaked away or bugfixed? I would say thats how caches do work. You might have a look at sysctl vm which shows a lot of the knobs you can turn to change some of the aspects you see. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch: blackfin: kernel: using strlcpy() instead of strncpy()
For NULL terminated string, need always be sure of ended by zero.
Just use strlcpy() instead of strncpy().
Signed-off-by: Chen Gang
---
arch/blackfin/kernel/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index 107b306..c731ec7 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/kernel/setup.c
@@ -1458,5 +1458,5 @@ void __init cmdline_init(const char *r0)
{
early_shadow_stamp();
if (r0)
- strncpy(command_line, r0, COMMAND_LINE_SIZE);
+ strlcpy(command_line, r0, COMMAND_LINE_SIZE);
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: blackfin: kernel: using strlcpy instead of strncpy
On 05/26/2013 03:04 PM, Chen Gang wrote:
>
> For NULL terminated string, need always be sure of ended by zero.
>
> 'command_line' is a static variable which will be initialized
> automatically, and cmdline_init() is __init function, so need not
> initialize it again, can just use strlcpy instead of strncpy.
>
The 2nd paragraph comment is redundent, need delete. I will send patch v2.
>
> Signed-off-by: Chen Gang
> ---
> arch/blackfin/kernel/setup.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
> index 107b306..c731ec7 100644
> --- a/arch/blackfin/kernel/setup.c
> +++ b/arch/blackfin/kernel/setup.c
> @@ -1458,5 +1458,5 @@ void __init cmdline_init(const char *r0)
> {
> early_shadow_stamp();
> if (r0)
> - strncpy(command_line, r0, COMMAND_LINE_SIZE);
> + strlcpy(command_line, r0, COMMAND_LINE_SIZE);
> }
>
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 9/9] vmcore: support mmap() on /proc/vmcore
(2013/05/24 18:02), Maxim Uvarov wrote: 2013/5/24 Andrew Morton mailto:a...@linux-foundation.org>> On Thu, 23 May 2013 14:25:48 +0900 HATAYAMA Daisuke mailto:d.hatay...@jp.fujitsu.com>> wrote: > This patch introduces mmap_vmcore(). > > Don't permit writable nor executable mapping even with mprotect() > because this mmap() is aimed at reading crash dump memory. > Non-writable mapping is also requirement of remap_pfn_range() when > mapping linear pages on non-consecutive physical pages; see > is_cow_mapping(). > > Set VM_MIXEDMAP flag to remap memory by remap_pfn_range and by > remap_vmalloc_range_pertial at the same time for a single > vma. do_munmap() can correctly clean partially remapped vma with two > functions in abnormal case. See zap_pte_range(), vm_normal_page() and > their comments for details. > > On x86-32 PAE kernels, mmap() supports at most 16TB memory only. This > limitation comes from the fact that the third argument of > remap_pfn_range(), pfn, is of 32-bit length on x86-32: unsigned long. More reviewing and testing, please. Do you have git pull for both kernel and userland changes? I would like to do some more testing on my machines. Maxim. Thanks! That's very helpful. -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] f2fs: add sysfs support for controlling the gc_thread
Hi Namjae,
This is an interesting functionality.
Could you describe why and when we need to do this?
What are pros and cons?
How can we use this?
IMO, when users try to control IO latencies, it seems that they can
trigger such the explicit GCs, but in order to do that, they also need
to know the status of current f2fs in more precisely. Does the debugfs
show it enoughly?
Afterwards, it is worth to add some information to
Document/filesystems/f2fs.txt.
Thanks,
2013-05-26 (일), 11:05 +0900, Namjae Jeon:
> From: Namjae Jeon
>
> Add sysfs entries to control the timing parameters for
> f2fs gc thread and also provide a control flag, which will
> allow the user to forcefully start a FG garbage collection
> if required.
>
> Signed-off-by: Namjae Jeon
> Signed-off-by: Pankaj Kumar
> ---
> fs/f2fs/f2fs.h |6 +++
> fs/f2fs/gc.c| 20 +---
> fs/f2fs/gc.h| 33 +++--
> fs/f2fs/super.c | 147
> +++
> 4 files changed, 185 insertions(+), 21 deletions(-)
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 00c8c5f..40abd81 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -400,6 +400,8 @@ struct f2fs_sb_info {
> struct mutex gc_mutex; /* mutex for GC */
> struct f2fs_gc_kthread *gc_thread; /* GC thread */
> unsigned int cur_victim_sec;/* current victim section num */
> + unsigned int forced_fg; /* forced forgound gc */
> +
>
> /*
>* for stat information.
> @@ -415,6 +417,10 @@ struct f2fs_sb_info {
> #endif
> unsigned int last_victim[2];/* last victim segment # */
> spinlock_t stat_lock; /* lock for stat operations */
> +
> + /* For sysfs suppport */
> + struct kobject s_kobj;
> + struct completion s_kobj_unregister;
> };
>
> /*
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index ddc2c67..8041d70 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -29,10 +29,11 @@ static struct kmem_cache *winode_slab;
> static int gc_thread_func(void *data)
> {
> struct f2fs_sb_info *sbi = data;
> + struct f2fs_gc_kthread *gc_th = sbi->gc_thread;
> wait_queue_head_t *wq = >gc_thread->gc_wait_queue_head;
> long wait_ms;
>
> - wait_ms = GC_THREAD_MIN_SLEEP_TIME;
> + wait_ms = gc_th->min_sleep_time;
>
> do {
> if (try_to_freeze())
> @@ -45,7 +46,7 @@ static int gc_thread_func(void *data)
> break;
>
> if (sbi->sb->s_writers.frozen >= SB_FREEZE_WRITE) {
> - wait_ms = GC_THREAD_MAX_SLEEP_TIME;
> + wait_ms = gc_th->max_sleep_time;
> continue;
> }
>
> @@ -66,15 +67,15 @@ static int gc_thread_func(void *data)
> continue;
>
> if (!is_idle(sbi)) {
> - wait_ms = increase_sleep_time(wait_ms);
> + wait_ms = increase_sleep_time(gc_th, wait_ms);
> mutex_unlock(>gc_mutex);
> continue;
> }
>
> if (has_enough_invalid_blocks(sbi))
> - wait_ms = decrease_sleep_time(wait_ms);
> + wait_ms = decrease_sleep_time(gc_th, wait_ms);
> else
> - wait_ms = increase_sleep_time(wait_ms);
> + wait_ms = increase_sleep_time(gc_th, wait_ms);
>
> #ifdef CONFIG_F2FS_STAT_FS
> sbi->bg_gc++;
> @@ -82,7 +83,7 @@ static int gc_thread_func(void *data)
>
> /* if return value is not zero, no victim was selected */
> if (f2fs_gc(sbi))
> - wait_ms = GC_THREAD_NOGC_SLEEP_TIME;
> + wait_ms = gc_th->no_gc_sleep_time;
> } while (!kthread_should_stop());
> return 0;
> }
> @@ -101,7 +102,12 @@ int start_gc_thread(struct f2fs_sb_info *sbi)
> goto out;
> }
>
> + gc_th->min_sleep_time = DEF_GC_THREAD_MIN_SLEEP_TIME;
> + gc_th->max_sleep_time = DEF_GC_THREAD_MAX_SLEEP_TIME;
> + gc_th->no_gc_sleep_time = DEF_GC_THREAD_NOGC_SLEEP_TIME;
> +
> sbi->gc_thread = gc_th;
> +
> init_waitqueue_head(>gc_thread->gc_wait_queue_head);
> sbi->gc_thread->f2fs_gc_task = kthread_run(gc_thread_func, sbi,
> "f2fs_gc-%u:%u", MAJOR(dev), MINOR(dev));
> @@ -677,7 +683,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi)
> {
> struct list_head ilist;
> unsigned int segno, i;
> - int gc_type = BG_GC;
> + int gc_type = sbi->forced_fg ? FG_GC : BG_GC;
> int nfree = 0;
> int ret = -1;
>
> diff --git a/fs/f2fs/gc.h b/fs/f2fs/gc.h
> index 2c6a6bd..f4bf44c 100644
> --- a/fs/f2fs/gc.h
> +++ b/fs/f2fs/gc.h
> @@ -13,9 +13,9 @@
>* whether IO subsystem is idle
>* or not
>
Re: [PATCH v2 2/7] Documentation/devices.txt: Mark /dev/oldmem obsolete
(2013/05/26 15:36), Zhang Yanfei wrote: From: Zhang Yanfei Signed-off-by: Zhang Yanfei Cc: Dave Jones --- Documentation/devices.txt |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 08f01e7..c8e4002 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -100,8 +100,7 @@ Your cooperation is appreciated. 10 = /dev/aio Asynchronous I/O notification interface 11 = /dev/kmsg Writes to this come out as printk's, reads export the buffered printk records. -12 = /dev/oldmem Used by crashdump kernels to access - the memory of the kernel that crashed. +12 = /dev/oldmem OBSOLETE 1 block RAM disk 0 = /dev/ram0 First RAM disk This is the new patch. Looking at other parts of devices.txt, obsolete is sometimes used together with unused. I guess obsolete means this is old interface so don't use it as much as possible and unused means this is not used at all now. You remove old memory interface completely in this patch set, so is it better to add unused, too? -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: arm64: kernel: sprintf(), 'str' needs additional 1 byte for failure processing
On 05/26/2013 06:28 PM, Chen Gang wrote:
>
> When failure occurs at the last looping cycle (when 'i == 0'), it will
> print "bad PC value" instead of "(%08x) ", which needs additional 1
> byte.
>
> If not add 1 byte, the str will not be NUL terminated, and the next
> printk() will cause issue.
>
Oh, I type incorrect contents. It should be "If not add 1 byte, it will
memory overflow"
I will send patch v2.
> Signed-off-by: Chen Gang
> ---
> arch/arm64/kernel/traps.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 61d7dd2..c2f68d2 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -100,7 +100,7 @@ static void dump_instr(const char *lvl, struct pt_regs
> *regs)
> {
> unsigned long addr = instruction_pointer(regs);
> mm_segment_t fs;
> - char str[sizeof(" ") * 5 + 2 + 1], *p = str;
> + char str[sizeof(" ") * 5 + 2 + 1 + 1], *p = str;
> int i;
>
> /*
>
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] Documentation/devices.txt: Remove /dev/oldmem description
于 2013年05月27日 09:27, HATAYAMA Daisuke 写道: > (2013/05/26 9:58), Zhang Yanfei wrote: >> 于 2013年05月26日 07:20, Eric W. Biederman 写道: >>> Zhang Yanfei writes: >>> From: Zhang Yanfei >>> >>> Won't we want to keep this reservation around to so that this number >>> doesn't get reused, and cause people confusion when >>> upgrading/downgrading kernels? >> >> Ah, yes. I will just keep this and add a note to make people know that >> it is removed in the next version. >> > > It looks enough writing "obsolete" according to the other parts of the same > file. > I've sent the v2 version and actually did what you said. Thanks 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/
Re: [PATCH 2/7] Documentation/devices.txt: Remove /dev/oldmem description
(2013/05/26 9:58), Zhang Yanfei wrote: 于 2013年05月26日 07:20, Eric W. Biederman 写道: Zhang Yanfei writes: From: Zhang Yanfei Won't we want to keep this reservation around to so that this number doesn't get reused, and cause people confusion when upgrading/downgrading kernels? Ah, yes. I will just keep this and add a note to make people know that it is removed in the next version. It looks enough writing "obsolete" according to the other parts of the same file. -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.9-stable] NFSv4.1 Fix a pNFS session draining deadlock
On Mon, 2013-05-27 at 09:23 +0900, Jonghwan Choi wrote: > This patch looks like it should be in the 3.9-stable tree, should we apply > it? It's a condition which appears to be extremely rare: so far, we've only seen it during extreme stress testing at NetApp. For that reason, and because it is NFSv4.1 only, I'm inclined to wait until we see real-world cases before making it a stable patch. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.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 3.9-stable] cpufreq / intel_pstate: Add additional supported CPU ID
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Dirk Brandewie "
commit c96d53d600643ee0adfd1cb90814bd9510e62b71 upstream
Add CPU ID for Ivybrigde processor.
Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/intel_pstate.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index d8a8c9b..bd9fae6 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -570,6 +570,7 @@ static void intel_pstate_timer_func(unsigned long
__data)
static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
ICPU(0x2a, default_policy),
ICPU(0x2d, default_policy),
+ ICPU(0x3a, default_policy),
{}
};
MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] rtc: rtc-ds1307: use devm_*() functions
On Saturday, May 25, 2013 10:51 AM, Devendra Naga wrote:
> On Sat, May 25, 2013 at 10:41 AM, Nikolay Balandin wrote:
> > From: Nikolay Balandin
[.]
> >
> > - ds1307->rtc = rtc_device_register(client->name, >dev,
> > + ds1307->rtc = devm_rtc_device_register(>dev, client->name,
> > _rtc_ops, THIS_MODULE);
Hi Nikolay Baladin, Devendra Naga,
Here, "devm"_rtc_device_register() is used.
Thus, rtc_device_unregister() will be called after remove() or
on probe failure.
> > if (IS_ERR(ds1307->rtc)) {
> > err = PTR_ERR(ds1307->rtc);
> > dev_err(>dev,
> > "unable to register the class device\n");
> > - goto exit_free;
> > + return err;
> > }
[.]
> > -exit_nvram:
> > -exit_irq:
> > - rtc_device_unregister(ds1307->rtc);
>
> Please dont remove this unregister, there's no devm_* for the rtc subsystem.
Above mentioned, rtc_device_unregister() can be removed, because
"devm"_rtc_device_register() was already called.
If I am wrong, please let me know kindly. :)
See you.
Best regards,
Jingoo Han
>
>
> > -exit_free:
> > - kfree(ds1307);
> > - return err;
> > }
> >
> > static int ds1307_remove(struct i2c_client *client)
> > @@ -992,13 +981,9 @@ static int ds1307_remove(struct i2c_client *client)
> > cancel_work_sync(>work);
> > }
> >
> > - if (test_and_clear_bit(HAS_NVRAM, >flags)) {
> > + if (test_and_clear_bit(HAS_NVRAM, >flags))
> > sysfs_remove_bin_file(>dev.kobj, ds1307->nvram);
> > - kfree(ds1307->nvram);
> > - }
> >
> > - rtc_device_unregister(ds1307->rtc);
>
> Here too.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the parisc-hd tree with Linus' tree
Hi all,
Today's linux-next merge of the parisc-hd tree got conflicts in
arch/parisc/include/asm/processor.h and arch/parisc/kernel/irq.c between
commit d96b51ec1465 ("parisc: fix irq stack on UP and SMP") from Linus'
tree and commit 1c92ce8487f6 ("parisc: use arch_spinlock_t instead of
raw_spinlock_t in irqstacks") from the parisc-hd tree.
I just used the version of both files from Linus' tree and can carry the
fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpnDks64auTd.pgp
Description: PGP signature
[PATCH 3.9-stable] NFSv4.1 Fix a pNFS session draining deadlock
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Andy Adamson "
commit 774d5f14ee1ecac55f42a84ff35eb00b896b00b6 upstream
On a CB_RECALL the callback service thread flushes the inode using
filemap_flush prior to scheduling the state manager thread to return the
delegation. When pNFS is used and I/O has not yet gone to the data server
servicing the inode, a LAYOUTGET can preceed the I/O. Unlike the async
filemap_flush call, the LAYOUTGET must proceed to completion.
If the state manager starts to recover data while the inode flush is sending
the LAYOUTGET, a deadlock occurs as the callback service thread holds the
single callback session slot until the flushing is done which blocks the
state
manager thread, and the state manager thread has set the session draining
bit
which puts the inode flush LAYOUTGET RPC to sleep on the forechannel slot
table waitq.
Separate the draining of the back channel from the draining of the fore
channel
by moving the NFS4_SESSION_DRAINING bit from session scope into the fore
and back slot tables. Drain the back channel first allowing the LAYOUTGET
call to proceed (and fail) so the callback service thread frees the callback
slot. Then proceed with draining the forechannel.
Signed-off-by: Andy Adamson
Signed-off-by: Trond Myklebust
Signed-off-by: Jonghwan Choi
---
fs/nfs/callback_proc.c |2 +-
fs/nfs/callback_xdr.c |2 +-
fs/nfs/nfs4proc.c |2 +-
fs/nfs/nfs4session.c |4 ++--
fs/nfs/nfs4session.h | 13 -
fs/nfs/nfs4state.c | 15 +++
6 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c
index 2960512..339bfa3 100644
--- a/fs/nfs/callback_proc.c
+++ b/fs/nfs/callback_proc.c
@@ -414,7 +414,7 @@ __be32 nfs4_callback_sequence(struct cb_sequenceargs
*args,
spin_lock(>slot_tbl_lock);
/* state manager is resetting the session */
- if (test_bit(NFS4_SESSION_DRAINING,
>cl_session->session_state)) {
+ if (test_bit(NFS4_SLOT_TBL_DRAINING, >slot_tbl_state)) {
spin_unlock(>slot_tbl_lock);
status = htonl(NFS4ERR_DELAY);
/* Return NFS4ERR_BADSESSION if we're draining the session
diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c
index 59461c9..a35582c 100644
--- a/fs/nfs/callback_xdr.c
+++ b/fs/nfs/callback_xdr.c
@@ -763,7 +763,7 @@ static void nfs4_callback_free_slot(struct nfs4_session
*session)
* A single slot, so highest used slotid is either 0 or -1
*/
tbl->highest_used_slotid = NFS4_NO_SLOT;
- nfs4_session_drain_complete(session, tbl);
+ nfs4_slot_tbl_drain_complete(tbl);
spin_unlock(>slot_tbl_lock);
}
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 0086401..beb807c 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -559,7 +559,7 @@ int nfs41_setup_sequence(struct nfs4_session *session,
task->tk_timeout = 0;
spin_lock(>slot_tbl_lock);
- if (test_bit(NFS4_SESSION_DRAINING, >session_state) &&
+ if (test_bit(NFS4_SLOT_TBL_DRAINING, >slot_tbl_state) &&
!args->sa_privileged) {
/* The state manager will wait until the slot table is empty
*/
dprintk("%s session is draining\n", __func__);
diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
index ebda5f4..c4e225e 100644
--- a/fs/nfs/nfs4session.c
+++ b/fs/nfs/nfs4session.c
@@ -73,7 +73,7 @@ void nfs4_free_slot(struct nfs4_slot_table *tbl, struct
nfs4_slot *slot)
tbl->highest_used_slotid = new_max;
else {
tbl->highest_used_slotid = NFS4_NO_SLOT;
- nfs4_session_drain_complete(tbl->session, tbl);
+ nfs4_slot_tbl_drain_complete(tbl);
}
}
dprintk("%s: slotid %u highest_used_slotid %d\n", __func__,
@@ -226,7 +226,7 @@ static bool nfs41_assign_slot(struct rpc_task *task,
void *pslot)
struct nfs4_slot *slot = pslot;
struct nfs4_slot_table *tbl = slot->table;
- if (nfs4_session_draining(tbl->session) && !args->sa_privileged)
+ if (nfs4_slot_tbl_draining(tbl) && !args->sa_privileged)
return false;
slot->generation = tbl->generation;
args->sa_slot = slot;
diff --git a/fs/nfs/nfs4session.h b/fs/nfs/nfs4session.h
index 6f3cb39..ff7d9f0 100644
--- a/fs/nfs/nfs4session.h
+++ b/fs/nfs/nfs4session.h
@@ -25,6 +25,10 @@ struct nfs4_slot {
};
/* Sessions */
+enum nfs4_slot_tbl_state {
+ NFS4_SLOT_TBL_DRAINING,
+};
+
#define SLOT_TABLE_SZ DIV_ROUND_UP(NFS4_MAX_SLOT_TABLE, 8*sizeof(long))
struct nfs4_slot_table {
struct nfs4_session *session; /* Parent session */
@@ -43,6 +47,7 @@ struct nfs4_slot_table {
unsigned long generation; /* Generation counter for
Re: [PATCH v8 3/9] vmcore: treat memory chunks referenced by PT_LOAD program header entries in page-size boundary in vmcore_list
(2013/05/24 22:12), Vivek Goyal wrote: On Thu, May 23, 2013 at 02:49:28PM -0700, Andrew Morton wrote: On Thu, 23 May 2013 14:25:13 +0900 HATAYAMA Daisuke wrote: Treat memory chunks referenced by PT_LOAD program header entries in page-size boundary in vmcore_list. Formally, for each range [start, end], we set up the corresponding vmcore object in vmcore_list to [rounddown(start, PAGE_SIZE), roundup(end, PAGE_SIZE)]. This change affects layout of /proc/vmcore. Well, changing a userspace interface is generally unacceptable because it can break existing userspace code. If you think the risk is acceptable then please do explain why. In great detail! I think it should not be a problem as /proc/vmcore is useful only when one parses the elf headers and then accesses the contents of file based on the header information. This patch just introduces additional areas in /proc/vmcore file and ELF headers still point to right contents. So any tool parsing ELF headers and then accessing file contents based on that info should still be fine. AFAIK, no user space tool should be broken there. Thanks Vivek Yes, the changes are new introduction of holes between components of ELF and tools doesn't reach the holes as long as by looking up program header table and other tables. cp command touches the holes but trivially works well. -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Adding fscache branch to linux-next
Hi David, On Thu, 23 May 2013 16:20:28 +0100 David Howells wrote: > > Can you add: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache Please use git URL's when talking about git trees. > To linux-next please? Added git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git#fscache from today. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgpMnFsb0KpEE.pgp Description: PGP signature
Linux 3.10-rc3
Another week, another rc. A *big* one. I'm not thrilled about it, and -rc3 is much bigger than -rc2 was, although there isn't anything particularly scary that stands out. Just a lot of small details. A number of people apparently missed rc2, and then made rc3. Oh, well. I can pretty much guarantee that -rc4 is going to be smaller, because (a) I'm going to be grumpy if people try to push as much to rc4 as happened to rc3, and (b) I'm going to be traveling for most of next week (and part of the week after). I'll have internet, but I really really hope and expect that things should be calmer coming up. Right? RIGHT GUYS? Anyway, it's mostly fairly small changes, and mostly to drivers. Network, staging, usb, video, drm.. There's some arch updates too: arm, mips and powerpc. And random stuff all over. Go at it, Linus --- Alan Stern (6): USB: xHCI: override bogus bulk wMaxPacketSize values USB: fix Kconfig logic for USB_UHCI_HCD USB: UHCI: fix for suspend of virtual HP controller USB: fix latency in uhci-hcd and ohci-hcd USB: OHCI: fix logic for scheduling isochronous URBs USB: remove remaining instances of USB_SUSPEND Albert Pool (1): rtlwifi: rtl8192cu: Add new USB ID Alex Deucher (10): drm/radeon/dce2: use 10khz units for audio dto calculation drm/radeon: add chip family for Hainan drm/radeon: fill in GPU init for Hainan (v2) drm/radeon: don't touch DCE or VGA regs on Hainan (v3) drm/radeon: fill in ucode loading support for Hainan drm/radeon: radeon-asic updates for Hainan drm/radeon: track which asics have UVD drm/radeon: sun/hainan chips do not have UVD (v2) drm/radeon: add golden register settings for Hainan (v2) drm/radeon: add Hainan pci ids Alexander Bondar (1): iwlwifi: mvm: Prevent setting assoc flag in MAC_CONTEXT_CMD Alexander Shiyan (1): s390: remove non existent reference to GENERIC_KERNEL_THREAD Alexander Sverdlin (1): i2c: suppress lockdep warning on delete_device Alexandre Bounine (4): rapidio: make enumeration/discovery configurable rapidio: add enumeration/discovery start from user space rapidio: documentation update for enumeration changes rapidio/tsi721: fix bug in MSI interrupt handling Alexandre Courbot (1): ARM: tegra: defconfig fixes Andrew Lunn (2): ARM: Orion: Remove redundant init_dma_coherent_pool_size() mv643xx_eth: fix NAPI weight being > 64 Andrew Morton (1): revert "selftest: add simple test for soft-dirty bit" Andy Adamson (1): NFSv4.1 Fix a pNFS session draining deadlock Andy Shevchenko (1): dma: acpi-dma: parse CSRT to extract additional resources Aneesh Kumar K.V (1): mm/THP: use pmd_populate() to update the pmd with pgtable_t pointer Ard Biesheuvel (1): ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling Arend van Spriel (1): brcmfmac: announce P2P_DEVICE support in wiphy structure Arnd Bergmann (4): staging/drm: imx: add missing dependencies staging/solo6x10: depend on CONFIG_FONTS mfd: ab8500: Debugfs code depends on gpadc USB: EHCI: remove bogus #error Aron Xu (1): MIPS: N64: Wire getdents64(2) Axel Lin (5): wm831x_backup: Fix wrong kfree call for devdata->backup.name pm2301_charger: Fix module alias prefix gpio: mcp23s08: Fix build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m gpio: Don't override the error code in probe error handling iio: dac: Fix build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m Bastian Triller (1): ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist Ben Hutchings (7): sfc: Delete EFX_PAGE_IP_ALIGN, equivalent to NET_IP_ALIGN sfc: Reduce RX scatter buffer size, and reduce alignment if appropriate perf: net_dropmonitor: Fix trace parameter order perf: net_dropmonitor: Fix symbol-relative addresses perf: net_dropmonitor: Do not assume ordering of dictionaries perf: net_dropmonitor: Use bisection in symbol lookup perf: net_dropmonitor: Remove progress indicator Ben Skeggs (9): drm/nouveau/bios: fix thinko in ZM_MASK_ADD opcode drm/nvc0/ce: disable ce1 on a number of chipsets drm/nvc0/ltcg: fix handling of disabled partitions drm/nve0/ltcg: poke the partition count into yet another register drm/nve0/fifo: prevent races between clients updating playlists drm/nvc0/fifo: prevent races between clients updating playlists drm/nvc0/fifo: prevent CHAN_TABLE_ERROR:CHANNEL_PENDING on fifo fini drm/nv50/fifo: prevent races between clients updating playlists drm/nouveau: ensure channels are stopped before saving fences for suspend Benjamin Herrenschmidt (5): powerpc: Fix TLB cleanup at boot on POWER8 powerpc/pci: Fix bogus message at boot about empty memory resources powerpc/powernv: Fix condition for when to invalidate the
[PATCH v4 3/3] mm/hugetlb: remove hugetlb_prefault
Changelog:
v1 -> v2:
* add Michal reviewed-by
hugetlb_prefault are not used any more, this patch remove it.
Reviewed-by: Michal Hocko
Signed-off-by: Wanpeng Li
---
include/linux/hugetlb.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6b4890f..a811149 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -55,7 +55,6 @@ void __unmap_hugepage_range_final(struct mmu_gather *tlb,
void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
unsigned long start, unsigned long end,
struct page *ref_page);
-int hugetlb_prefault(struct address_space *, struct vm_area_struct *);
void hugetlb_report_meminfo(struct seq_file *);
int hugetlb_report_node_meminfo(int, char *);
void hugetlb_show_meminfo(void);
@@ -110,7 +109,6 @@ static inline unsigned long hugetlb_total_pages(void)
#define follow_hugetlb_page(m,v,p,vs,a,b,i,w) ({ BUG(); 0; })
#define follow_huge_addr(mm, addr, write) ERR_PTR(-EINVAL)
#define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
-#define hugetlb_prefault(mapping, vma) ({ BUG(); 0; })
static inline void hugetlb_report_meminfo(struct seq_file *m)
{
}
--
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 v4 1/3] mm/hugetlb: use already exist interface huge_page_shift
Changelog:
v1 -> v2:
* update alloc_bootmem_huge_page in powerpc
* add Michal reviewed-by
Use already exist interface huge_page_shift instead of h->order + PAGE_SHIFT.
Reviewed-by: Michal Hocko
Signed-off-by: Wanpeng Li
---
arch/powerpc/mm/hugetlbpage.c | 2 +-
mm/hugetlb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 237c8e5..cafec93 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -357,7 +357,7 @@ void add_gpage(u64 addr, u64 page_size, unsigned long
number_of_pages)
int alloc_bootmem_huge_page(struct hstate *hstate)
{
struct huge_bootmem_page *m;
- int idx = shift_to_mmu_psize(hstate->order + PAGE_SHIFT);
+ int idx = shift_to_mmu_psize(huge_page_shift(hstate));
int nr_gpages = gpage_freearray[idx].nr_gpages;
if (nr_gpages == 0)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f8feeec..b6ff0ee 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -319,7 +319,7 @@ unsigned long vma_kernel_pagesize(struct vm_area_struct
*vma)
hstate = hstate_vma(vma);
- return 1UL << (hstate->order + PAGE_SHIFT);
+ return 1UL << huge_page_shift(hstate);
}
EXPORT_SYMBOL_GPL(vma_kernel_pagesize);
--
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 v4 2/3] mm/pageblock: remove get/set_pageblock_flags
Changelog: v1 -> v2: * add Michal reviewed-by get_pageblock_flags and set_pageblock_flags are not used any more, this patch remove them. Reviewed-by: Michal Hocko Signed-off-by: Wanpeng Li --- include/linux/pageblock-flags.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-flags.h index be655e4..2ee8cd2 100644 --- a/include/linux/pageblock-flags.h +++ b/include/linux/pageblock-flags.h @@ -80,10 +80,4 @@ void set_pageblock_flags_group(struct page *page, unsigned long flags, PB_migrate_skip) #endif /* CONFIG_COMPACTION */ -#define get_pageblock_flags(page) \ - get_pageblock_flags_group(page, 0, PB_migrate_end) -#define set_pageblock_flags(page, flags) \ - set_pageblock_flags_group(page, flags, \ - 0, PB_migrate_end) - #endif /* PAGEBLOCK_FLAGS_H */ -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Add co-maintainer for fbdev
Hi Jean-Christophe, On 05/24/2013 06:56 PM, Arnd Bergmann wrote: > On Friday 24 May 2013, Olof Johansson wrote: >> [+akpm] > > [+florian] Thanks for CC'ing me. Lately I got dropped frequently from the mailinglist (after 1 or 2 days). Guess I should try subscribing via my own mail server. >> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD >> wrote: >>> Hi Florian, >>> >>> As you seems very busy I'd like to propose the help you to handle >>> the >>> fbdev subsystem to easier the rich of the fbdev patch to Linus >>> >>> As I'm working on fbdev on at91 and others and already Co-Maintain >>> the >>> at91 mach on ARM >>> >>> And if you are not willing to continue I could take over Yeah, it would be great if you could help, at the moment I get barely any sleep, let alone that I could keep up with the majority of mail I get. I'll let you decide whether you want to be sole maintainer or not. I still have interest in the subsystem, but it looks like VIA won't provide any information for their new VX11 chipset IGP for any open source driver and I'm still looking for a small, quiet mobile device as a replacement for my precious netbook that broke down last autumn to allow me working when I'm not at home. >> Andrew has been fallback fbdev maintainer for a while, we have the >> option of formalizing that as well. Adding him on cc so he sees this. At this point I'd like to thank all people who have helped out so far, especially Tomi and Andrew. Best regards, Florian Tobias Schandinat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/14] misc/ep93xx_pwm: cleanup driver for conversion to PWM framework
On 25/05/13 09:19, H Hartley Sweeten wrote:
> This driver needs to be converted to the new PWM framework.
>
> Before converting it clean up all the cruft,
>
> H Hartley Sweeten (14):
> misc/ep93xx_pwm: use managed device resources
> misc/ep93xx_pwm: use {read,write}* instead of __raw_* versions for io
> misc/ep93xx_pwm: remove ep93xx_pwm_{write,read}l() inline functions
> misc/ep93xx_pwm: remove ep93xx_pwm_write_tc() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_write_dc() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_enable() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_disable() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_invert() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_normal() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_read_tc() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_is_enabled() inline function
> misc/ep93xx_pwm: remove ep93xx_pwm_is_inverted() inline function
> misc/ep93xx_pwm: use module_platform_driver()
> misc/ep93xx_pwm: use kstrtol instead of strict_strtol
>
> drivers/misc/ep93xx_pwm.c | 187
> +-
> 1 file changed, 50 insertions(+), 137 deletions(-)
>
Series looks fine to me.
Reviewed-by: Ryan Mallon
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] ipc/sem.c: Bug fixes, regression fixes, v3
On Sun, May 26, 2013 at 1:50 PM, Davidlohr Bueso wrote: > > In lack of getting my swingbench DSS environment back, I ran these > changes against the semop-multi program on my laptop. For 256 threads, > with Manfred's patchset the ops/sec suffers around -7.3%. Hmm. That test program only tests simple ops, right? So the slowdown comes from either the code simply being that much slower due to extra complexity, or from the fair wakeups.. Anyway, I applied 1/4, we can continue to discuss the rest. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to get driver_data of struct ieee1394_device_id in kernel driver module?
On Sun, May 26, 2013 at 11:35:13PM +0200, Stefan Richter wrote: > I think your approach is sensible. There is of course just the little > problem that firewire-core keeps the matching device_id table entry as a > secret to itself. Therefore, struct ieee1394_device_id.driver_data is > currently totally useless. > > How about we make it available like in the following patch? > > Besides being useful to your presently out-of-tree work, the in-tree > sound/firewire/speakers.c::fwspk_detect() could be rewritten to use this > approach. Maybe I will post an expanded version of this patch which > incorporates such a first in-tree usage. Why not pass it in the probe() function, like USB and PCI does? That way, if the driver wants to save it for that device, it can. 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: How to get driver_data of struct ieee1394_device_id in kernel driver module?
On May 26 Stefan Richter wrote:
> (Adding LKML and Greg KH, in case that there are general opinions about
> how a bus_type should work.)
>
> On May 26 Takashi Sakamoto wrote:
> > Hi all,
> >
> > I'm a newbile for Linux Firewire subsystem and not used to IEEE 1394 bus
> > programing in Linux.
> > So I happy to get your advices.
> >
> > Currently I'm working for some drivers of ALSA in kernel land.
> > Then some devices to which the same module applies need to handle its
> > own operations.
> > To implement these operations, I think it good to utilize driver_data of
> > struct ieee1394_evice_id entry.
> >
> > This is example.
> > For entry:
> > https://github.com/takaswie/snd-firewire-improve/blob/f509e4587c3f7b18eda70d07b616ef01be3546ef/bebob/bebob.c#L462
> > For usage:
> > https://github.com/takaswie/snd-firewire-improve/blob/f509e4587c3f7b18eda70d07b616ef01be3546ef/bebob/bebob.c#L362
> >
> > (In this case, I use the cast between (kernel_ulong_t) and (struct
> > snd_bebob_ops *) but I have no confidence that this is better...)
> >
> > Anyway, this module need to know the id for the current device in
> > device_id table but I have no idea to get the id. Do you know good way
> > to get it in module's probing process?
> >
> >
> > Regards
> >
> > Takashi Sakamoto
>
> I think your approach is sensible. There is of course just the little
> problem that firewire-core keeps the matching device_id table entry as a
> secret to itself. Therefore, struct ieee1394_device_id.driver_data is
> currently totally useless.
>
> How about we make it available like in the following patch?
From: Stefan Richter
Subject: firewire: pass matching ieee1394_device_id to drivers via struct
fw_unit
FireWire audio unit drivers will need to apply various model-specific
operations. The struct ieee1394_device_id.driver_data member can be
used to store respective flags or function pointer tables.
But until now drivers had no way to know which driver->id_table index
was matched with an fw_unit instance. Other bus subsystems like pci or
usb pass this information via an own driver probe method, whereas the
firewire subsystem uses the stock struct device_driver.probe().
We could introduce a struct fw_driver.probe() which works similarly to
struct pci_driver.probe() or struct usb_driver.probe(). But it seems
simpler to just add a new member to struct fw_unit which caches the
matching ieee1394_device_id, so this is what is done here, and used in
the snd-firewire-speakers driver.
Signed-off-by: Stefan Richter
---
drivers/firewire/core-device.c |7 +++-
include/linux/firewire.h |5 ++-
sound/firewire/speakers.c | 65 -
3 files changed, 32 insertions(+), 45 deletions(-)
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -168,21 +168,24 @@ static bool match_ids(const struct ieee1
static bool is_fw_unit(struct device *dev);
static int fw_unit_match(struct device *dev, struct device_driver *drv)
{
+ struct fw_unit *unit = fw_unit(dev);
const struct ieee1394_device_id *id_table =
container_of(drv, struct fw_driver, driver)->id_table;
int id[] = {0, 0, 0, 0};
/* We only allow binding to fw_units. */
if (!is_fw_unit(dev))
return 0;
- get_modalias_ids(fw_unit(dev), id);
+ get_modalias_ids(unit, id);
for (; id_table->match_flags != 0; id_table++)
- if (match_ids(id_table, id))
+ if (match_ids(id_table, id)) {
+ unit->device_id = id_table;
return 1;
+ }
return 0;
}
--- a/include/linux/firewire.h
+++ b/include/linux/firewire.h
@@ -215,14 +215,17 @@ static inline int fw_device_is_shutdown(
}
int fw_device_enable_phys_dma(struct fw_device *device);
+struct ieee1394_device_id;
+
/*
* fw_unit.directory must not be accessed after device_del(_unit.device).
*/
struct fw_unit {
struct device device;
const u32 *directory;
+ const struct ieee1394_device_id *device_id;
struct fw_attribute_group attribute_group;
};
static inline struct fw_unit *fw_unit(struct device *dev)
@@ -246,10 +249,8 @@ static inline struct fw_device *fw_paren
{
return fw_device(unit->device.parent);
}
-struct ieee1394_device_id;
-
struct fw_driver {
struct device_driver driver;
/* Called when the parent device sits through a bus reset. */
void (*update)(struct fw_unit *unit);
--- a/sound/firewire/speakers.c
+++ b/sound/firewire/speakers.c
@@ -657,44 +657,8 @@ static void fwspk_card_free(struct snd_c
fw_unit_put(fwspk->unit);
mutex_destroy(>mutex);
}
-static const struct device_info *fwspk_detect(struct fw_device *dev)
-{
- static const struct device_info griffin_firewave = {
- .driver_name = "FireWave",
- .short_name = "FireWave",
-
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Thu, Apr 25, 2013 at 12:19 PM, Cong Ding wrote: > On Thu, Feb 14, 2013 at 12:43:15PM +0100, Cong Ding wrote: >> On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: >> > On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: >> > > On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: >> > > > On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch >> > > > wrote: >> > > > > On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: >> > > > >> In version 1, I forgot to modify the same bug in the first loop. >> > > > >> >> > > > >> we have to call kobject_put() to clean up the kobject after function >> > > > >> kobject_init(), kobject_add(), or kobject_uevent() is called. >> > > > >> >> > > > >> Signed-off-by: Cong Ding >> > > > > >> > > > > Signed-off-by: "Hans J. Koch" >> > > > >> > > > Hi Greg, is this patch stil in the queue? >> > > >> > > Hans is queueing up UIO patches to send to me, I'm waiting for him to >> > > send them as I don't have any in my trees. >> > >> > I'll set that up tonight or tomorrow. Sorry, I was delayed by illness >> > and a lot of other work. >> Hi Hans, what's this going on? >> >> Thanks, - cong Hi Hans, it's another month. What's the progress of this patch? - cong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v2 3/6] mm/memory_hotplug: Disable memory hotremove for 32bit
(5/26/13 2:09 PM), Michal Hocko wrote: > On Sun 26-05-13 07:58:42, KOSAKI Motohiro wrote: As KOSAKI Motohiro mentioned, memory hotplug don't support 32bit since it was born, >>> >>> Why? any reference? This reasoning is really weak. >> >> I have no seen any highmem support in memory hotplug code and I don't think >> this >> patch fixes all 32bit highmem issue. If anybody are interesting to >> support it, it is good thing. But in fact, _now_ it is broken when >> enable HIGHMEM. >> So, I just want to mark broken until someone want to support highmem >> and verify overall. >> >> And, yes, this patch is no good. Kconfig doesn't describe why disable >> when highmem. >> So, >> >> depends on 64BIT || !HIGHMEM || BROKEN >> >> maybe clear documentation more. > > I have no objection to disbale the feature for HIGHMEM configurations I > was merely complaining that the patch didn't describe _why_. No worry. I withdrew the claim because several people now willing to contribute 32bit highmem improvement. I don't want to block them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v1] skbuff: Hide GFP_ATOMIC page allocation failures for dropped packets
On Sun, 2013-05-26 at 20:28 +0400, Sergei Shtylyov wrote: > On 26-05-2013 17:17, atom...@redhat.com wrote: > > Failed GFP_ATOMIC allocations by the network stack result in dropped > > packets, which will be received on a subsequent retransmit, and an > > unnecessary, noisy warning with a kernel backtrace. > > > These warnings are harmless, but they still cause users to panic and > > file bug reports over dropped packets. It would be better to hide the > > failed allocation warnings and backtraces, and let retransmits handle > > dropped packets quietly. > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c [] > > @@ -236,7 +236,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t > > gfp_mask, > > ? skbuff_fclone_cache : skbuff_head_cache; > > > > if (sk_memalloc_socks() && (flags & SKB_ALLOC_RX)) > > - gfp_mask |= __GFP_MEMALLOC; > > + gfp_mask |= (__GFP_MEMALLOC|__GFP_NOWARN); > > Parens not needed here. Maybe add a pr_debug before the goto out instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
securebits: add exec_inherit flag to prevent changes to process credentials during execve
From: Stephen Mell
Currently, it is nearly impossible to give a capability to a non-root user that
will stick around after the first execve. This patch adds a new securebit,
exec_inherit, which causes all credential modification logic to be skipped.
This is already possible, in a hackish fashion, if a program reads another
program into memory and jumps into it. This patch would allow this to be done
in a more consistent and less hacky manner. Moreover, the sendmail exploit of
old would not happen again, as setuid and capability bits on programs are
disregarded when exec_inherit is active.
Use cases include allowing non-root users to bind to low numbered ports and use
chroot. The securebit could be set in a pam module.
Signed-off-by: Stephen Mell
---
include/uapi/linux/securebits.h | 12 +++-
security/commoncap.c| 5 +
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/securebits.h b/include/uapi/linux/securebits.h
index 985aac9..b779489 100644
--- a/include/uapi/linux/securebits.h
+++ b/include/uapi/linux/securebits.h
@@ -40,12 +40,22 @@
#define SECURE_KEEP_CAPS 4
#define SECURE_KEEP_CAPS_LOCKED5 /* make bit-4 immutable */
+/* When set, a process retains its capabilities when performing an
+ execve(). No modifications, such as those from suid bits or file
+ capabilities, are made. */
+#define SECURE_EXEC_INHERIT6
+#define SECURE_EXEC_INHERIT_LOCKED 7 /* make bit-6 immutable */
+
+#define SECBIT_EXEC_INHERIT(issecure_mask(SECURE_EXEC_INHERIT))
+#define SECBIT_EXEC_INHERIT_LOCKED (issecure_mask(SECURE_EXEC_INHERIT_LOCKED))
+
#define SECBIT_KEEP_CAPS (issecure_mask(SECURE_KEEP_CAPS))
#define SECBIT_KEEP_CAPS_LOCKED (issecure_mask(SECURE_KEEP_CAPS_LOCKED))
#define SECURE_ALL_BITS(issecure_mask(SECURE_NOROOT) | \
issecure_mask(SECURE_NO_SETUID_FIXUP) | \
-issecure_mask(SECURE_KEEP_CAPS))
+issecure_mask(SECURE_KEEP_CAPS) | \
+issecure_mask(SECURE_EXEC_INHERIT))
#define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1)
#endif /* _UAPI_LINUX_SECUREBITS_H */
diff --git a/security/commoncap.c b/security/commoncap.c
index c44b6fe..998ee6e 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -484,6 +484,11 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
int ret;
kuid_t root_uid;
+ if (issecure(SECURE_EXEC_INHERIT)) {
+ *new = *old;
+ return 0;
+ }
+
effective = false;
ret = get_file_caps(bprm, , _cap);
if (ret < 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting
(5/7/13 11:24 AM), Frederic Weisbecker wrote: > 2013/5/7 KOSAKI Motohiro : + /* + * After turning over se.sum_exec_runtime to sig->sum_sched_runtime + * in __exit_signal(), we must not account exec_runtime for consistency. + */ + if (unlikely(!tsk->sighand)) + return; >>> >>> Ok, if we want the clock and timer to be consistent, do we also want the >>> same check in >>> account_group_user_time() and account_group_system_time()? The task can >>> still account >>> a tick after autoreaping itself between release_task() and the final >>> schedule(). >> >> You are right. >> >> That said, current the man pages don't describe this linux specific >> extensions. So, nobody >> (glibc, ltp, and me) tested them. Please give me a couple of days. >> I'll test and fix this features >> too. >> >> timer_create(2): http://man7.org/linux/man-pages/man2/timer_create.2.html > > Ah, indeed timer_create() seem to only create CPUCLOCK_SCHED timers. So that > issue with timer_gettime becoming asynchonous with clock_gettime can't happen > with PROF and VIRT clocks > > I see itimers can use those clocks. But there don't seem to be a > similar issue with > getitimer/setitimer as they don't have matching clock reads. OK. I've found PROF and VIRT clock of posix timer have a bug and I could narrow down and fixed it. Please see my next iteration. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] posix-cpu-timers: fix cputimer initialization mistake for {u,s}time
From: KOSAKI Motohiro
When using CPUCLOCK_VIRT or CPUCLOCK_PROF, we need to round an expire up
because jiffies based accounting may point to one jiffy behind at maximum.
So, current code lead to wake up posix timer too early.
This patch adds one jiffy at timer initialization. itimer already has a
similar trick and it match a userland assumption.
Luckily, CPUCLOCK_VIRT and CPUCLOCK_PROF posix timer are undocumented,
standard undefined, and no libc support. So maybe nobody uses them.
However, it still would be nice to fix if possible.
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: KOSAKI Motohiro
---
kernel/posix-cpu-timers.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 34bb3f1..42874c2 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -339,6 +339,18 @@ static int cpu_timer_sample_group(const clockid_t
which_clock,
return do_cpu_clock_timer_sample(which_clock, p, true, false, cpu);
}
+static union cpu_time_count cpu_clock_resolution(clockid_t cpuid)
+{
+ union cpu_time_count ret;
+
+ if (CPUCLOCK_WHICH(cpuid) == CPUCLOCK_SCHED)
+ ret.sched = 1;
+ else
+ ret.cpu = cputime_one_jiffy;
+
+ return ret;
+}
+
static int posix_cpu_clock_get(const clockid_t which_clock, struct timespec
*tp)
{
const pid_t pid = CPUCLOCK_PID(which_clock);
@@ -806,7 +818,15 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int
flags,
cpu_clock_sample(timer->it_clock, p, );
else
cpu_clock_sample_group(timer->it_clock, p, );
+
cpu_time_add(timer->it_clock, _expires, now);
+
+ /*
+* When inaccurate timer, we need to adjust an expire time
+* because "now" may point to slightly past time.
+*/
+ cpu_time_add(timer->it_clock, _expires,
+cpu_clock_resolution(timer->it_clock));
}
/*
--
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 7/8] posix-cpu-timers: cleanup cpu_{clock,timer}_sample{,_group}
From: KOSAKI Motohiro
Now we have four similar timer related functions, cpu_clock_sample(),
cpu_clock_sample_group(), cpu_timer_sample() and cpu_timer_sample_group().
For readability, make do_cpu_clock_timer_sample() and thread_cputime()
helper functions and all *_sample functions use these.
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Acked-by: Peter Zijlstra
Signed-off-by: KOSAKI Motohiro
---
include/linux/sched.h |1 +
kernel/posix-cpu-timers.c | 132 +++-
kernel/sched/cputime.c| 11
3 files changed, 69 insertions(+), 75 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 4878579..ba36321 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2458,6 +2458,7 @@ static inline int spin_needbreak(spinlock_t *lock)
#endif
}
+void thread_cputime(struct task_struct *tsk, bool add_delta, struct
task_cputime *times);
/*
* Idle thread specific functions to determine the need_resched
* polling state. We have two versions, one based on TS_POLLING in
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 62466d4..34bb3f1 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -220,46 +220,6 @@ posix_cpu_clock_set(const clockid_t which_clock, const
struct timespec *tp)
return error;
}
-
-static int do_cpu_clock_timer_sample(const clockid_t which_clock,
-struct task_struct *p,
-bool add_delta,
-union cpu_time_count *cpu)
-{
- switch (CPUCLOCK_WHICH(which_clock)) {
- default:
- return -EINVAL;
- case CPUCLOCK_PROF:
- cpu->cpu = prof_ticks(p);
- break;
- case CPUCLOCK_VIRT:
- cpu->cpu = virt_ticks(p);
- break;
- case CPUCLOCK_SCHED:
- cpu->sched = task_sched_runtime(p, add_delta);
- break;
- }
- return 0;
-}
-
-/*
- * Sample a per-thread clock for the given task.
- */
-static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
- union cpu_time_count *cpu)
-{
- return do_cpu_clock_timer_sample(which_clock, p, true, cpu);
-}
-
-/*
- * Sample a per-thread timer clock for the given task.
- */
-static int cpu_timer_sample(const clockid_t which_clock, struct task_struct *p,
- union cpu_time_count *cpu)
-{
- return do_cpu_clock_timer_sample(which_clock, p, false, cpu);
-}
-
static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
{
if (b->utime > a->utime)
@@ -301,34 +261,83 @@ void thread_group_cputimer(struct task_struct *tsk,
struct task_cputime *times)
}
/*
- * Sample a process (thread group) clock for the given group_leader task.
- * Must be called with tasklist_lock held for reading.
+ * Sample time for the given task.
+ * @which_clock: Clock id.
+ * @p: Target task. Must be thread group leader when
+ * thread_group is true.
+ * @thread_group: True if want to get process time.
+ * @add_delta: True if want to get clock time,
+ * otherwise, get timer time.
*/
-static int cpu_clock_sample_group(const clockid_t which_clock,
- struct task_struct *p,
- union cpu_time_count *cpu)
+static int do_cpu_clock_timer_sample(const clockid_t which_clock,
+struct task_struct *p,
+bool thread_group,
+bool clock_time,
+union cpu_time_count *cpu)
{
struct task_cputime cputime;
+ if (thread_group) {
+ if (clock_time)
+ thread_group_cputime(p, true, );
+ else
+ thread_group_cputimer(p, );
+ } else
+ thread_cputime(p, clock_time, );
+
switch (CPUCLOCK_WHICH(which_clock)) {
default:
return -EINVAL;
case CPUCLOCK_PROF:
- thread_group_cputime(p, true, );
cpu->cpu = cputime.utime + cputime.stime;
break;
case CPUCLOCK_VIRT:
- thread_group_cputime(p, true, );
cpu->cpu = cputime.utime;
break;
case CPUCLOCK_SCHED:
- thread_group_cputime(p, true, );
cpu->sched = cputime.sum_exec_runtime;
break;
}
return 0;
}
+/*
+ * Sample a per-thread clock time for the given task.
+ */
+static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
+ union cpu_time_count *cpu)
+{
+ return do_cpu_clock_timer_sample(which_clock, p, false, true, cpu);
+}
+
+/*
+ *
[PATCH 5/8] posix-cpu-timers: check_thread_timers() uses task_sched_runtime()
From: KOSAKI Motohiro
A type of tsk->se.sum_exec_runtime is u64. Thus, reading it is racy when
running 32bit. We should use task_sched_runtime().
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Acked-by: Peter Zijlstra
Signed-off-by: KOSAKI Motohiro
---
kernel/posix-cpu-timers.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 1b33c77..62466d4 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -1008,7 +1008,8 @@ static void check_thread_timers(struct task_struct *tsk,
struct cpu_timer_list *t = list_first_entry(timers,
struct cpu_timer_list,
entry);
- if (!--maxfire || tsk->se.sum_exec_runtime < t->expires.sched) {
+ unsigned long long runtime = task_sched_runtime(tsk, false);
+ if (!--maxfire || runtime < t->expires.sched) {
tsk->cputime_expires.sched_exp = t->expires.sched;
break;
}
--
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 6/8] sched: task_sched_runtime introduce micro optimization
From: KOSAKI Motohiro rq lock in task_sched_runtime() is necessary for two reasons. 1) accessing se.sum_exec_runtime is not atomic on 32bit and 2) do_task_delta_exec() require it. So, 64bit can avoid holding rq lock when add_delta is false and delta_exec is 0. Cc: Olivier Langlois Cc: Thomas Gleixner Cc: Frederic Weisbecker Cc: Ingo Molnar Suggested-by: Paul Turner Acked-by: Peter Zijlstra Signed-off-by: KOSAKI Motohiro --- kernel/sched/core.c | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 96512e9..0f859cc 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2692,6 +2692,21 @@ unsigned long long task_sched_runtime(struct task_struct *p, bool add_delta) struct rq *rq; u64 ns = 0; +#ifdef CONFIG_64BIT + /* +* 64-bit doesn't need locks to atomically read a 64bit value. So we +* have two optimization chances, 1) when caller doesn't need +* delta_exec and 2) when the task's delta_exec is 0. The former is +* obvious. The latter is complicated. reading ->on_cpu is racy, but +* this is ok. If we race with it leaving cpu, we'll take a lock. So +* we're correct. If we race with it entering cpu, unaccounted time +* is 0. This is indistinguishable from the read occurring a few +* cycles earlier. +*/ + if (!add_delta || !p->on_cpu) + return p->se.sum_exec_runtime; +#endif + rq = task_rq_lock(p, ); ns = p->se.sum_exec_runtime; if (add_delta) -- 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 4/8] posix-cpu-timers: timer functions should use timer time instead of clock time
From: KOSAKI Motohiro
For process timers, we use cpu_clock_sample_group() and cpu_timer_sample_group()
correctly. However, for thread timers, we always use cpu_clock_sample(). This is
wrong because a cpu_clock_sample() accounts uncommitted delta_exec too. And this
is inconsistent against run_posix_cpu_tiemrs().
This is not big matter because the following workaround code in
posix_cpu_timer_get() hides the timer miscalculation issue. However, it makes
rq lock held wrongly and it would be better to fix it.
if (cpu_time_before(timer->it_clock, now, timer->it.cpu.expires)) {
...
} else {
/*
* The timer should have expired already, but the firing
* hasn't taken place yet. Say it's just about to expire.
*/
itp->it_value.tv_nsec = 1;
itp->it_value.tv_sec = 0;
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Acked-by: Peter Zijlstra
Signed-off-by: KOSAKI Motohiro
---
kernel/posix-cpu-timers.c | 37 +++--
1 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index d068808..1b33c77 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -221,11 +221,10 @@ posix_cpu_clock_set(const clockid_t which_clock, const
struct timespec *tp)
}
-/*
- * Sample a per-thread clock for the given task.
- */
-static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
- union cpu_time_count *cpu)
+static int do_cpu_clock_timer_sample(const clockid_t which_clock,
+struct task_struct *p,
+bool add_delta,
+union cpu_time_count *cpu)
{
switch (CPUCLOCK_WHICH(which_clock)) {
default:
@@ -237,12 +236,30 @@ static int cpu_clock_sample(const clockid_t which_clock,
struct task_struct *p,
cpu->cpu = virt_ticks(p);
break;
case CPUCLOCK_SCHED:
- cpu->sched = task_sched_runtime(p, true);
+ cpu->sched = task_sched_runtime(p, add_delta);
break;
}
return 0;
}
+/*
+ * Sample a per-thread clock for the given task.
+ */
+static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
+ union cpu_time_count *cpu)
+{
+ return do_cpu_clock_timer_sample(which_clock, p, true, cpu);
+}
+
+/*
+ * Sample a per-thread timer clock for the given task.
+ */
+static int cpu_timer_sample(const clockid_t which_clock, struct task_struct *p,
+ union cpu_time_count *cpu)
+{
+ return do_cpu_clock_timer_sample(which_clock, p, false, cpu);
+}
+
static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
{
if (b->utime > a->utime)
@@ -748,7 +765,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int
flags,
* check if it's already passed. In short, we need a sample.
*/
if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
- cpu_clock_sample(timer->it_clock, p, );
+ cpu_timer_sample(timer->it_clock, p, );
} else {
cpu_timer_sample_group(timer->it_clock, p, );
}
@@ -804,7 +821,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int
flags,
* we need exact current time.
*/
if (CPUCLOCK_PERTHREAD(timer->it_clock))
- now = val;
+ cpu_clock_sample(timer->it_clock, p, );
else
cpu_clock_sample_group(timer->it_clock, p, );
cpu_time_add(timer->it_clock, _expires, now);
@@ -894,7 +911,7 @@ static void posix_cpu_timer_get(struct k_itimer *timer,
struct itimerspec *itp)
* Sample the clock to take the difference with the expiry time.
*/
if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
- cpu_clock_sample(timer->it_clock, p, );
+ cpu_timer_sample(timer->it_clock, p, );
clear_dead = p->exit_state;
} else {
read_lock(_lock);
@@ -1203,7 +1220,7 @@ void posix_cpu_timer_schedule(struct k_itimer *timer)
* Fetch the current sample and update the timer's expiry time.
*/
if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
- cpu_clock_sample(timer->it_clock, p, );
+ cpu_timer_sample(timer->it_clock, p, );
bump_cpu_timer(timer, now);
if (unlikely(p->exit_state)) {
clear_dead_task(timer, now);
--
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 3/8] posix-cpu-timers: fix wrong timer initialization
From: KOSAKI Motohiro
Currently glibc's rt/tst-cputimer1 testcase sporadically fails because
a timer created by timer_create() may fire earlier than specified.
posix_cpu_timer_set() uses "val" as current time for three purpose. 1)
initialize sig->cputimer. 2) calculation "old" val. 3) calculations an
expires.
(1) and (2) should only use committed time (i.e. without delta_exec)
because run_posix_cpu_timers() don't care of delta_exec and we need
consistency, but (3) need exact current time (aka cpu clock time) because
an expires should be "now + timeout" by definition.
This patch distinguishes between two kinds of "now".
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Acked-by: Peter Zijlstra
Signed-off-by: KOSAKI Motohiro
---
include/linux/kernel_stat.h |5 -
kernel/posix-cpu-timers.c | 14 --
kernel/sched/core.c | 13 -
3 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/include/linux/kernel_stat.h b/include/linux/kernel_stat.h
index ed5f6ed..f5d4fdf 100644
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -117,11 +117,6 @@ static inline unsigned int kstat_cpu_irqs_sum(unsigned int
cpu)
return kstat_cpu(cpu).irqs_sum;
}
-/*
- * Lock/unlock the current runqueue - to extract task statistics:
- */
-extern unsigned long long task_delta_exec(struct task_struct *);
-
extern void account_user_time(struct task_struct *, cputime_t, cputime_t);
extern void account_system_time(struct task_struct *, int, cputime_t,
cputime_t);
extern void account_steal_time(cputime_t);
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 25447c5..d068808 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -652,7 +652,7 @@ static int cpu_timer_sample_group(const clockid_t
which_clock,
cpu->cpu = cputime.utime;
break;
case CPUCLOCK_SCHED:
- cpu->sched = cputime.sum_exec_runtime + task_delta_exec(p);
+ cpu->sched = cputime.sum_exec_runtime;
break;
}
return 0;
@@ -797,7 +797,17 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int
flags,
}
if (new_expires.sched != 0 && !(flags & TIMER_ABSTIME)) {
- cpu_time_add(timer->it_clock, _expires, val);
+ union cpu_time_count now;
+
+ /*
+* The expires is "now + timeout" by definition. So,
+* we need exact current time.
+*/
+ if (CPUCLOCK_PERTHREAD(timer->it_clock))
+ now = val;
+ else
+ cpu_clock_sample_group(timer->it_clock, p, );
+ cpu_time_add(timer->it_clock, _expires, now);
}
/*
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a1e823b..96512e9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2681,19 +2681,6 @@ static u64 do_task_delta_exec(struct task_struct *p,
struct rq *rq)
return ns;
}
-unsigned long long task_delta_exec(struct task_struct *p)
-{
- unsigned long flags;
- struct rq *rq;
- u64 ns = 0;
-
- rq = task_rq_lock(p, );
- ns = do_task_delta_exec(p, rq);
- task_rq_unlock(rq, p, );
-
- return ns;
-}
-
/*
* Return accounted runtime for the task.
* In case the task is currently running, return the runtime plus current's
--
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 2/8] posix-cpu-timers: fix acounting delta_exec twice
From: KOSAKI Motohiro
Currently glibc rt/tst-cpuclock2 test(*) sporadically fails because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up earlier than an argument. This is posix
violation. This issue was introduced by commit d670ec1317 (posix-cpu-timers:
Cure SMP wobbles).
(*)
http://sourceware.org/git/?p=glibc.git;a=blob;f=rt/tst-cpuclock2.c;h=6752721717f959e89c0d692b3f1ee082d507eec2;hb=HEAD
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Signed-off-by: Peter Zijlstra
Signed-off-by: KOSAKI Motohiro
---
fs/binfmt_elf.c |2 +-
fs/binfmt_elf_fdpic.c |2 +-
include/linux/sched.h |4 ++--
kernel/posix-cpu-timers.c | 15 ++-
kernel/sched/core.c |6 --
kernel/sched/cputime.c|6 +++---
6 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index f8a0b0e..9f7e13a 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1326,7 +1326,7 @@ static void fill_prstatus(struct elf_prstatus *prstatus,
* This is the record for the group leader. It shows the
* group-wide total, not its individual thread total.
*/
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cputime_to_timeval(cputime.utime, >pr_utime);
cputime_to_timeval(cputime.stime, >pr_stime);
} else {
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index c166f32..fbcaeeb 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1368,7 +1368,7 @@ static void fill_prstatus(struct elf_prstatus *prstatus,
* This is the record for the group leader. It shows the
* group-wide total, not its individual thread total.
*/
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cputime_to_timeval(cputime.utime, >pr_utime);
cputime_to_timeval(cputime.stime, >pr_stime);
} else {
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 178a8d9..4878579 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1841,7 +1841,7 @@ static inline void disable_sched_clock_irqtime(void) {}
#endif
extern unsigned long long
-task_sched_runtime(struct task_struct *task);
+task_sched_runtime(struct task_struct *task, bool add_delta);
/* sched_exec is called by processes performing an exec */
#ifdef CONFIG_SMP
@@ -2502,7 +2502,7 @@ static inline void current_clr_polling(void) { }
/*
* Thread group CPU time accounting.
*/
-void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times);
+void thread_group_cputime(struct task_struct *tsk, bool add_delta, struct
task_cputime *times);
void thread_group_cputimer(struct task_struct *tsk, struct task_cputime
*times);
static inline void thread_group_cputime_init(struct signal_struct *sig)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 42670e9..25447c5 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -237,7 +237,7 @@ static int cpu_clock_sample(const clockid_t which_clock,
struct task_struct *p,
cpu->cpu = virt_ticks(p);
break;
case CPUCLOCK_SCHED:
- cpu->sched = task_sched_runtime(p);
+ cpu->sched = task_sched_runtime(p, true);
break;
}
return 0;
@@ -267,8 +267,13 @@ void thread_group_cputimer(struct task_struct *tsk, struct
task_cputime *times)
* values through the TIMER_ABSTIME flag, therefore we have
* to synchronize the timer to the clock every time we start
* it.
+*
+* Do not add the current delta, because
+* account_group_exec_runtime() will also this delta and we
+* wouldn't want to double account time and get ahead of
+* ourselves.
*/
- thread_group_cputime(tsk, );
+ thread_group_cputime(tsk, false, );
raw_spin_lock_irqsave(>lock, flags);
cputimer->running = 1;
update_gt_cputime(>cputime, );
@@ -292,15 +297,15 @@ static int cpu_clock_sample_group(const clockid_t
which_clock,
default:
return -EINVAL;
case CPUCLOCK_PROF:
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cpu->cpu = cputime.utime + cputime.stime;
break;
case CPUCLOCK_VIRT:
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cpu->cpu = cputime.utime;
break;
case CPUCLOCK_SCHED:
- thread_group_cputime(p, );
+
[PATCH 2/8] posix-cpu-timers: fix acounting delta_exec twice
From: KOSAKI Motohiro
Currently glibc rt/tst-cpuclock2 test(*) sporadically fails because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().
Finally, clock_nanosleep() wakes up before an argument. This is posix
violation. This issue was introduced by commit d670ec1317 (posix-cpu-timers:
Cure SMP wobbles).
(*)
http://sourceware.org/git/?p=glibc.git;a=blob;f=rt/tst-cpuclock2.c;h=6752721717f959e89c0d692b3f1ee082d507eec2;hb=HEAD
Cc: Olivier Langlois
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Signed-off-by: Peter Zijlstra
Signed-off-by: KOSAKI Motohiro
---
fs/binfmt_elf.c |2 +-
fs/binfmt_elf_fdpic.c |2 +-
include/linux/sched.h |4 ++--
kernel/posix-cpu-timers.c | 15 ++-
kernel/sched/core.c |6 --
kernel/sched/cputime.c|6 +++---
6 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index f8a0b0e..9f7e13a 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1326,7 +1326,7 @@ static void fill_prstatus(struct elf_prstatus *prstatus,
* This is the record for the group leader. It shows the
* group-wide total, not its individual thread total.
*/
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cputime_to_timeval(cputime.utime, >pr_utime);
cputime_to_timeval(cputime.stime, >pr_stime);
} else {
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index c166f32..fbcaeeb 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1368,7 +1368,7 @@ static void fill_prstatus(struct elf_prstatus *prstatus,
* This is the record for the group leader. It shows the
* group-wide total, not its individual thread total.
*/
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cputime_to_timeval(cputime.utime, >pr_utime);
cputime_to_timeval(cputime.stime, >pr_stime);
} else {
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 178a8d9..4878579 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1841,7 +1841,7 @@ static inline void disable_sched_clock_irqtime(void) {}
#endif
extern unsigned long long
-task_sched_runtime(struct task_struct *task);
+task_sched_runtime(struct task_struct *task, bool add_delta);
/* sched_exec is called by processes performing an exec */
#ifdef CONFIG_SMP
@@ -2502,7 +2502,7 @@ static inline void current_clr_polling(void) { }
/*
* Thread group CPU time accounting.
*/
-void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times);
+void thread_group_cputime(struct task_struct *tsk, bool add_delta, struct
task_cputime *times);
void thread_group_cputimer(struct task_struct *tsk, struct task_cputime
*times);
static inline void thread_group_cputime_init(struct signal_struct *sig)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 42670e9..25447c5 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -237,7 +237,7 @@ static int cpu_clock_sample(const clockid_t which_clock,
struct task_struct *p,
cpu->cpu = virt_ticks(p);
break;
case CPUCLOCK_SCHED:
- cpu->sched = task_sched_runtime(p);
+ cpu->sched = task_sched_runtime(p, true);
break;
}
return 0;
@@ -267,8 +267,13 @@ void thread_group_cputimer(struct task_struct *tsk, struct
task_cputime *times)
* values through the TIMER_ABSTIME flag, therefore we have
* to synchronize the timer to the clock every time we start
* it.
+*
+* Do not add the current delta, because
+* account_group_exec_runtime() will also this delta and we
+* wouldn't want to double account time and get ahead of
+* ourselves.
*/
- thread_group_cputime(tsk, );
+ thread_group_cputime(tsk, false, );
raw_spin_lock_irqsave(>lock, flags);
cputimer->running = 1;
update_gt_cputime(>cputime, );
@@ -292,15 +297,15 @@ static int cpu_clock_sample_group(const clockid_t
which_clock,
default:
return -EINVAL;
case CPUCLOCK_PROF:
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cpu->cpu = cputime.utime + cputime.stime;
break;
case CPUCLOCK_VIRT:
- thread_group_cputime(p, );
+ thread_group_cputime(p, true, );
cpu->cpu = cputime.utime;
break;
case CPUCLOCK_SCHED:
- thread_group_cputime(p, );
+ thread_group_cputime(p,
[PATCH 1/8] posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting
From: KOSAKI Motohiro
When tsk->signal->cputimer->running is 1, signal->cputimer (i.e. per process
timer account) and tsk->sum_sched_runtime (i.e. per thread timer account)
increase at the same pace because update_curr() increases both accounting.
However, there is one exception. When thread exiting, __exit_signal() turns
over task's sum_shced_runtime to sig->sum_sched_runtime, but it doesn't stop
signal->cputimer accounting.
This inconsistency makes POSIX timer wake up too early. This patch fixes it.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Acked-by: Frederic Weisbecker
Acked-by: Peter Zijlstra
Signed-off-by: Olivier Langlois
Signed-off-by: KOSAKI Motohiro
---
kernel/sched/stats.h | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index 2ef90a5..8a0567f 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -162,6 +162,33 @@ sched_info_switch(struct task_struct *prev, struct
task_struct *next)
*/
/**
+ * cputimer_running - return true if cputimer is running
+ *
+ * @tsk: Pointer to target task.
+ */
+static inline bool cputimer_running(struct task_struct *tsk)
+
+{
+ struct thread_group_cputimer *cputimer = >signal->cputimer;
+
+ if (!cputimer->running)
+ return false;
+
+ /*
+* After turning over se.sum_exec_runtime's time accounting to
+* sig->sum_sched_runtime in __exit_signal(), a per-thread cputime
+* of the thread is going to be lost. We must not account exec_runtime
+* here too because we need to keep consistent cputime between
+* per-thread and per-process. Otherwise, the inconsistency is
+* observable when single thread program run.
+*/
+ if (unlikely(!tsk->sighand))
+ return false;
+
+ return true;
+}
+
+/**
* account_group_user_time - Maintain utime for a thread group.
*
* @tsk: Pointer to task structure.
@@ -176,7 +203,7 @@ static inline void account_group_user_time(struct
task_struct *tsk,
{
struct thread_group_cputimer *cputimer = >signal->cputimer;
- if (!cputimer->running)
+ if (!cputimer_running(tsk))
return;
raw_spin_lock(>lock);
@@ -199,7 +226,7 @@ static inline void account_group_system_time(struct
task_struct *tsk,
{
struct thread_group_cputimer *cputimer = >signal->cputimer;
- if (!cputimer->running)
+ if (!cputimer_running(tsk))
return;
raw_spin_lock(>lock);
@@ -222,7 +249,7 @@ static inline void account_group_exec_runtime(struct
task_struct *tsk,
{
struct thread_group_cputimer *cputimer = >signal->cputimer;
- if (!cputimer->running)
+ if (!cputimer_running(tsk))
return;
raw_spin_lock(>lock);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to get driver_data of struct ieee1394_device_id in kernel driver module?
(Adding LKML and Greg KH, in case that there are general opinions about
how a bus_type should work.)
On May 26 Takashi Sakamoto wrote:
> Hi all,
>
> I'm a newbile for Linux Firewire subsystem and not used to IEEE 1394 bus
> programing in Linux.
> So I happy to get your advices.
>
> Currently I'm working for some drivers of ALSA in kernel land.
> Then some devices to which the same module applies need to handle its
> own operations.
> To implement these operations, I think it good to utilize driver_data of
> struct ieee1394_evice_id entry.
>
> This is example.
> For entry:
> https://github.com/takaswie/snd-firewire-improve/blob/f509e4587c3f7b18eda70d07b616ef01be3546ef/bebob/bebob.c#L462
> For usage:
> https://github.com/takaswie/snd-firewire-improve/blob/f509e4587c3f7b18eda70d07b616ef01be3546ef/bebob/bebob.c#L362
>
> (In this case, I use the cast between (kernel_ulong_t) and (struct
> snd_bebob_ops *) but I have no confidence that this is better...)
>
> Anyway, this module need to know the id for the current device in
> device_id table but I have no idea to get the id. Do you know good way
> to get it in module's probing process?
>
>
> Regards
>
> Takashi Sakamoto
I think your approach is sensible. There is of course just the little
problem that firewire-core keeps the matching device_id table entry as a
secret to itself. Therefore, struct ieee1394_device_id.driver_data is
currently totally useless.
How about we make it available like in the following patch?
Besides being useful to your presently out-of-tree work, the in-tree
sound/firewire/speakers.c::fwspk_detect() could be rewritten to use this
approach. Maybe I will post an expanded version of this patch which
incorporates such a first in-tree usage.
8<
From: Stefan Richter
Subject: [PATCH] firewire: pass matching ieee1394_device_id to drivers via
struct fw_unit
FireWire audio unit drivers will need to apply various model-specific
operations. The struct ieee1394_device_id.driver_data member can be
used to store respective flags or function pointer tables.
But until now drivers had no way to know which driver->id_table index
was matched with an fw_unit instance. Other bus subsystems like pci or
usb pass this information via an own driver probe method, whereas the
firewire subsystem uses the stock struct device_driver.probe().
We could introduce a struct fw_driver.probe() which works similarly to
struct pci_driver.probe() or struct usb_driver.probe(). But it seems
simpler to just add a new member to struct fw_unit which caches the
matching ieee1394_device_id, so this is what is done here.
Signed-off-by: Stefan Richter
---
drivers/firewire/core-device.c |7 +--
include/linux/firewire.h |5 +++--
2 files changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -169,6 +169,7 @@ static bool is_fw_unit(struct device *de
static int fw_unit_match(struct device *dev, struct device_driver *drv)
{
+ struct fw_unit *unit = fw_unit(dev);
const struct ieee1394_device_id *id_table =
container_of(drv, struct fw_driver, driver)->id_table;
int id[] = {0, 0, 0, 0};
@@ -177,11 +178,13 @@ static int fw_unit_match(struct device *
if (!is_fw_unit(dev))
return 0;
- get_modalias_ids(fw_unit(dev), id);
+ get_modalias_ids(unit, id);
for (; id_table->match_flags != 0; id_table++)
- if (match_ids(id_table, id))
+ if (match_ids(id_table, id)) {
+ unit->device_id = id_table;
return 1;
+ }
return 0;
}
--- a/include/linux/firewire.h
+++ b/include/linux/firewire.h
@@ -216,12 +216,15 @@ static inline int fw_device_is_shutdown(
int fw_device_enable_phys_dma(struct fw_device *device);
+struct ieee1394_device_id;
+
/*
* fw_unit.directory must not be accessed after device_del(_unit.device).
*/
struct fw_unit {
struct device device;
const u32 *directory;
+ const struct ieee1394_device_id *device_id;
struct fw_attribute_group attribute_group;
};
@@ -247,8 +250,6 @@ static inline struct fw_device *fw_paren
return fw_device(unit->device.parent);
}
-struct ieee1394_device_id;
-
struct fw_driver {
struct device_driver driver;
/* Called when the parent device sits through a bus reset. */
--
Stefan Richter
-=-===-= -=-= ==-=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/8] posix timers fixlet
From: KOSAKI Motohiro
Glibc's posix timer testcase found a lot of bugs in posix timer code.
This series, hopefully, fixes all of them. All patches are independent
each other logically.
Changes from v4
- [1/8] comments colarification, fix account_group_{user_system}_time too.
- [8/8] added CPUCLOCK_VIRT and CPUCLOCK_PROF timer initialization fix
Changes from v3
- task_sched_runtime() micro optimization add to care tsk->on_cpu.
suggested Paul Turner.
- fixed several typo in changelogs.
KOSAKI Motohiro (8):
posix-cpu-timers: don't account cpu timer after stopped thread
runtime accounting
posix-cpu-timers: fix acounting delta_exec twice
posix-cpu-timers: fix wrong timer initialization
posix-cpu-timers: timer functions should use timer time instead of
clock time
posix-cpu-timers: check_thread_timers() uses task_sched_runtime()
sched: task_sched_runtime introduce micro optimization
posix-cpu-timers: cleanup cpu_{clock,timer}_sample{,_group}
posix-cpu-timers: fix cputimer initialization mistake for {u,s}time
fs/binfmt_elf.c |2 +-
fs/binfmt_elf_fdpic.c |2 +-
include/linux/kernel_stat.h |5 --
include/linux/sched.h |5 +-
kernel/posix-cpu-timers.c | 163 ++-
kernel/sched/core.c | 34 +
kernel/sched/cputime.c | 17 -
kernel/sched/stats.h| 33 -
8 files changed, 167 insertions(+), 94 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: [RFC PATCHv4 0/6] arm: Initial TI-Nspire support
On Saturday 25 May 2013, Daniel Tang wrote: > Changes between v3 and v4: > * Remove redundant clock-names in device tree > * Re-enable bus access to some peripherals on bootup > * Clean up nspire-classic-timer code. > - Implement a nspire_timer_set_mode function > - Removed messy IO_MATCHx and CNTL_MATCHx macros > - Timer starts disabled to begin with > - Interrupt handling code return IRQ_NONE for spurious interrupts > - Delete unnessecary shift > * Change clk-nspire to use compatible property to determine IO type > * Change device tree bindings to have appropriate vendor prefixes > * Added device tree binding documentation > * Fix incorrect register addresses for clocks > * Use more specific .caps for CLCD Looks really good now. I have a few more comments for the first patch, mostly for stuff that can be simplified based on stuff we merged in 3.10. The one remaining bit that sticks out is the clcd platform data. As I said before, I won't require you to convert that to DT in order to get your code merged, but I'd also really like to see that happen, as we will also need that to get rid of auxdata on the ARM reference platforms (integrator, versatile, realview, vexpress). Are you motivated to look into those after the base patch gets merged into arm-soc? One comment on the merge path: While we can put any of the patches into the arm-soc tree, my preference is definitely for the clk, clksource, irqchip and input drivers to go through the respective maintainer trees. There are no dependencies to worry about, since each patch can compile standalone, and we just need to make sure they all get into 3.11 for your platform to work. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/13] pwm: pwm-mxs: Let device core handle pinctrl
On Sun, May 26, 2013 at 06:02:16PM -0300, Fabio Estevam wrote: > Hi Thierry, > > On Mon, May 6, 2013 at 3:05 PM, Fabio Estevam > wrote: > > Since commit ab78029 (drivers/pinctrl: grab default handles from device > > core), > > we can rely on device core for handling pinctrl. > > > > So remove devm_pinctrl_get_select_default() from the driver. > > > > Cc: Thierry Reding > > Cc: > > Signed-off-by: Fabio Estevam > > Any comments on this one? Looks good. I've applied it to my for-next branch. Thanks for pinging me. Thierry pgpjEZ5zWfXq3.pgp Description: PGP signature
Re: [PATCH 06/13] pwm: pwm-mxs: Let device core handle pinctrl
Hi Thierry, On Mon, May 6, 2013 at 3:05 PM, Fabio Estevam wrote: > Since commit ab78029 (drivers/pinctrl: grab default handles from device core), > we can rely on device core for handling pinctrl. > > So remove devm_pinctrl_get_select_default() from the driver. > > Cc: Thierry Reding > Cc: > Signed-off-by: Fabio Estevam Any comments on this one? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
