Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Thu, 6 Sep 2012 16:26:06 +0300 Felipe Balbi wrote:
> Hi,
>
> On Thu, Sep 06, 2012 at 05:02:45PM +1000, NeilBrown wrote:
> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> > wrote:
> >
> > > On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> > > > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
> > > > wrote:
> >
> > > >> After thinking bit more on this, the problem seems to be coming
> > > >> mainly because the gpio device is runtime suspended bit early than
> > > >> it should be. Similar issue seen with i2c driver as well. The i2c issue
> > > >> was discussed with Rafael at LPC last week. The idea is to move
> > > >> the pm_runtime_enable/disable() calls entirely up to the
> > > >> _late/_early stage of device suspend/resume.
> > > >> Will update this thread once I have further update.
> > > >
> > > > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after
> > > > all
> > > > the _late callbacks have been called.
> > > > I, too, spoke to Rafael about this in San Diego. He seemed to agree
> > > > with me
> > > > that the interrupt needs to be masked in the ->suspend callback. any
> > > > later
> > > > is too late.
> > > >
> > > Thanks for information about your discussion. Will wait for the patch
> > > then.
> > >
> > > Regards
> > > santosh
> >
> > I already sent a patch - that is what started this thread :-)
> >
> > I include it below.
> > You said "The patch doesn't seems to be correct" but didn't expand on why.
> > Do you still think it is not correct? I wouldn't be surprised if there is
> > some case that it doesn't handle quite right, but it seems right to me.
> >
> > Thanks,
> > NeilBrown
> >
> >
> > From: NeilBrown
> > Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
> >
> > Current kernel will wake from suspend on an event on any active
> > GPIO even if enable_irq_wake() wasn't called.
> >
> > There are two reasons that the hardware wake-enable bit should be set:
> >
> > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> > in which the wake-enable bit is needed for an interrupt to be
> > recognised.
> > 2/ while suspended the GPIO interrupt should wake from suspend if and
> >only if irq_wake as been enabled.
> >
> > The code currently doesn't keep these two reasons separate so they get
> > confused and sometimes the wakeup flags is set incorrectly.
> >
> > This patch reverts:
> > commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> > gpio/omap: remove suspend/resume callbacks
> > and
> > commit 0aa2727399c0b78225021413022c164cb99fbc5e
> > gpio/omap: remove suspend_wakeup field from struct gpio_bank
> >
> > and makes some minor changes so that we have separate flags for "GPIO
> > should wake from deep idle" and "GPIO should wake from suspend".
> >
> > With this patch, the GPIO from my touch screen doesn't wake my device
> > any more, which is what I want.
> >
> > Cc: Kevin Hilman
> > Cc: Tony Lindgren
> > Cc: Santosh Shilimkar
> > Cc: Cousson Benoit
> > Cc: Grant Likely
> > Cc: Tarun Kanti DebBarma
> > Cc: Felipe Balbi
> > Cc: Govindraj.R
> >
> > Signed-off-by: NeilBrown
> >
> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> > index 4fbc208..fdbad70 100644
> > --- a/drivers/gpio/gpio-omap.c
> > +++ b/drivers/gpio/gpio-omap.c
> > @@ -57,6 +57,7 @@ struct gpio_bank {
> > u16 irq;
> > int irq_base;
> > struct irq_domain *domain;
> > + u32 suspend_wakeup;
> > u32 non_wakeup_gpios;
> > u32 enabled_non_wakeup_gpios;
> > struct gpio_regs context;
> > @@ -522,11 +523,12 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
> > int gpio, int enable)
> >
> > spin_lock_irqsave(&bank->lock, flags);
> > if (enable)
> > - bank->context.wake_en |= gpio_bit;
> > + bank->suspend_wakeup |= gpio_bit;
> > else
> > - bank->context.wake_en &= ~gpio_bit;
> > + bank->suspend_wakeup &= ~gpio_bit;
> >
> > - __raw_writel(bank->context.wake_en, bank->base + bank->regs->wkup_en);
> > + if (!bank->loses_context)
> > + __raw_writel(bank->suspend_wakeup, bank->base +
> > bank->regs->wkup_en);
> > spin_unlock_irqrestore(&bank->lock, flags);
> >
> > return 0;
> > @@ -1157,6 +1159,51 @@ static int __devinit omap_gpio_probe(struct
> > platform_device *pdev)
> > #ifdef CONFIG_ARCH_OMAP2PLUS
> >
> > #if defined(CONFIG_PM_RUNTIME)
> > +
> > +#if defined(CONFIG_PM_SLEEP)
> > +static int omap_gpio_suspend(struct device *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct gpio_bank *bank = platform_get_drvdata(pdev);
> > + void __iomem *base = bank->base;
> > + unsigned long flags;
> > +
> > + if (!bank->mod_usage || !bank->loses_context)
> > + return 0;
> > +
> > + if (!bank->regs->wkup_en || !bank->context.wake_en)
> > + return 0;
> > +
> > + spin_lock_irqsave(&bank->lock, flags);
>
> shouldn't you be using
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
Il 10/09/2012 08:47, Michael S. Tsirkin ha scritto:
> On Mon, Sep 10, 2012 at 08:38:09AM +0200, Paolo Bonzini wrote:
>> Il 10/09/2012 08:03, Michael S. Tsirkin ha scritto:
>>> On Mon, Sep 10, 2012 at 07:50:13AM +0200, Paolo Bonzini wrote:
Il 09/09/2012 00:22, Michael S. Tsirkin ha scritto:
>> Almost. One is "the guest, if really needed, can tell the host of
>> pages". If not negotiated, and the host does not support it, the host
>> must break the guest (e.g. fail to offer any virtqueues).
>
> There is no way in spec to break the guest.
> You can not fail to offer virtqueues.
You can always return 0 for the first queue.
>>>
>>> I don't think guest drivers recover gracefully from this.
>>> Do they?
>>
>> No, that's the point ("break the guest" is really "break the driver").
>
> You can just stop VM then. No need for a side channel.
Keeping the VM running, just with no balloon driver is preferrable.
>> The other is "the guest, though, would prefer not to do so". It is
>> different because the guest can proceed in a fallback mode even if the
>> host doesn't offer it.
>
> I think I get what your proposed SILENT means what I do not get
> is the motivation. It looks like a premature optimization to me.
The motivation is to let the driver choose between two behaviors: the
current one where ballooning is only done on request, and a more
aggressive one.
>>>
>>> Yes but why is being silent any good? Optimization?
>>> Any data to show that it will help some workload?
>>
>> Idle guests can move cache pages to the balloon. You can overcommit
>> more aggressively, because the host can madvise away a lot more memory.
>
> IMHO this feature needs more thought. E.g. how will this work with assignment?
Revert to normal cooperative ballooning.
> If we build something let's build it in a way that plays nicely
> with other features.
Yes, that's the point of SILENT. :)
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Seeking clarity on IRQCHIP_MASK_ON_SUSPEND
The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so either I'm understanding it wrongly, or it could be made easier to use. If the first case, I'm hoping that some improvement to documentation might result. If the second, then maybe we can fix the code. As I understand it, the need for IRQCHIP_MASK_ON_SUSPEND comes from the fact that interrupt masking happens lazily. When an interrupt is disabled the hardware isn't told about that immediately, only internal data structures are updated. If/when the interrupt actually happens, only then is it masked and ignored. This cannot really work in suspend as masking after the interrupt fires means that we have already woken from suspend. So suspend_device_irqs() (called between the suspend_late handlers and the suspend_noirq handlers) just disables all interrupts and check_wakeup_irqs() (which is called very late) is left to talk to the hardware and actually mask those which should not cause a wake-from-suspend. The problem is that check_wakeup_irqs() is called so late that it might not be possible to talk to the hardware. For example, on the OMAP3 platform, runtime power management will gate the 'iclk' (interface clock) and possibly other clocks so that it is no longer possible to talk over an i2c bus or even directly to the GPIO SoC module to effect the masking. As runtime PM is disabled at this stage of the suspend cycle it is not even possible to turn the iclk back on, mask the interrupt, then turn it off again. So it seems to me that either: 1/ irq_chip devices need to mask any non-wakeup interrupts in ->suspend or possibly in ->suspend_late before runtimePM has switched the interface off, making IRQCHIP_MASK_ON_SUSPEND essentially useless except for some rare cases. or 2/ IRQCHIP_MASK_ON_SUSPEND needs to happen much earlier, probably before the suspend_late callbacks. It might be tempting to change suspend_device_irqs() to disable interrupts in such a way that the 'mask' happen synchronously (for non-wakeup interrupts). However I don't think that would work as it happens after suspend_late and I think suspend_late is allowed to power_down devices (and iclks). I *think* the correct answer is '1'. In that case I would love to know when IRQCHIP_MASK_ON_SUSPEND can be used correctly (if ever). I'm hoping someone who works with interrupts and power management more than I can help me understand... There are currently only two drivers that set IRQCHIP_MASK_ON_SUSPEND: arch/arm/mach-omap2/omap-wakeupgen.c and drivers/mfd/pm8xxx-irq.c The former is in an 'always-on' power domain so the interaction with runtime PM presumably doesn't affect it. The later ... I don't think will compile. It is only used by pm8921-core.c, and that requires #include , which doesn't exist in mainline. Is anyone able to give a definitive answer on this? Should IRQCHIP_MASK_ON_SUSPEND be removed? Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH RESEND] thermal: add generic cpufreq cooling implementation
Hello Rui and Amit, On Mon, Sep 10, 2012 at 9:25 AM, Zhang Rui wrote: > Refreshed to remove the notifier mechanism as we do not have a real user of > it. > if there is no problem, I'll apply the whole patch set to thermal next tree. > > From: Amit Daniel Kachhap > Date: Thu, 16 Aug 2012 17:11:40 +0530 > > This patchset introduces a new generic cooling device based on cpufreq > that can be used on non-ACPI platforms. As a proof of concept, we have > drivers for the following platforms using this mechanism now: > > * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. > * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git > imx6q_thermal) > > There is a small change in cpufreq cooling registration APIs, so a minor > change is needed for Freescale platforms. > > Brief Description: > > 1) The generic cooling devices code is placed inside driver/thermal/* >as placing inside acpi folder will need un-necessary enabling of acpi >code. This code is architecture independent. > > 2) This patchset adds generic cpu cooling low level implementation >through frequency clipping. In future, other cpu related cooling >devices may be added here. An ACPI version of this already exists >(drivers/acpi/processor_thermal.c) .But this will be useful for >platforms like ARM using the generic thermal interface along with the >generic cpu cooling devices. The cooling device registration API's >return cooling device pointers which can be easily binded with the >thermal zone trip points. The important APIs exposed are, > >a) struct thermal_cooling_device *cpufreq_cooling_register( > struct cpumask *clip_cpus) >b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) > > 3) Samsung exynos platform thermal implementation is done using the >generic cpu cooling APIs and the new trip type. The temperature sensor >driver present in the hwmon folder(registered as hwmon driver) is moved >to thermal folder and registered as a thermal driver. > > A simple data/control flow diagrams is shown below, > > Core Linux thermal <-> Exynos thermal interface <- Temperature Sensor > | | > \|/| > Cpufreq cooling device <--- > > TODO: > *Will send the DT enablement patches later after the driver is merged. > > This patch: > > Add support for generic cpu thermal cooling low level implementations > using frequency scaling up/down based on the registration parameters. > Different cpu related cooling devices can be registered by the user and > the binding of these cooling devices to the corresponding trip points can > be easily done as the registration APIs return the cooling device pointer. > The user of these APIs are responsible for passing clipping frequency . > The drivers can also register to recieve notification about any cooling > action called. > > Cc: Guenter Roeck > Cc: SangWook Ju > Cc: Durgadoss > Cc: Len Brown > Cc: Jean Delvare > Cc: Kyungmin Park > Cc: Kukjin Kim > Signed-off-by: Zhang Rui > Signed-off-by: Andrew Morton > Signed-off-by: Amit Daniel Kachhap can you please include my Reviewed-by? Also on your patch series I have reviewed. Reviewed-by: Eduardo Valentin > --- > Documentation/thermal/cpu-cooling-api.txt | 33 ++ > drivers/thermal/Kconfig | 11 + > drivers/thermal/Makefile |1 + > drivers/thermal/cpu_cooling.c | 450 > + > include/linux/cpu_cooling.h | 58 > 5 files changed, 553 insertions(+), 0 deletions(-) > create mode 100644 Documentation/thermal/cpu-cooling-api.txt > create mode 100644 drivers/thermal/cpu_cooling.c > create mode 100644 include/linux/cpu_cooling.h > > diff --git a/Documentation/thermal/cpu-cooling-api.txt > b/Documentation/thermal/cpu-cooling-api.txt > new file mode 100644 > index 000..6fe9cdb > --- /dev/null > +++ b/Documentation/thermal/cpu-cooling-api.txt > @@ -0,0 +1,33 @@ > +CPU cooling APIs How To > +=== > + > +Written by Amit Daniel Kachhap > + > +Updated: 12 May 2012 > + > +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) > + > +0. Introduction > + > +The generic cpu cooling(freq clipping) provides registration/unregistration > APIs > +to the caller. The binding of the cooling devices to the trip point is left > for > +the user. The registration APIs returns the cooling device pointer. > + > +1. cpu cooling APIs > + > +1.1 cpufreq registration/unregistration APIs > +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( > + struct cpumask *clip_cpus) > + > +This interface function registers the cpufreq cooling device with the > name > +"thermal-cpufreq-%x". This api can support multiple instances of cpufreq > +cooling devices. > + > + clip_cpus: cpumask of cpus where the frequenc
Re: [ 35/95] dccp: check ccid before dereferencing
From: Mathias Krause Date: Mon, 10 Sep 2012 08:17:06 +0200 > Hi Ben, > > On Mon, Sep 10, 2012 at 12:42 AM, Ben Hutchings wrote: >> 3.2-stable review patch. If anyone has any objections, please let me know. > > No objections, but could you please consider including the following > commits, too?: They will be included when I next push my networking -stable queue to the stable maintainers, and no sooner. You never need to ask if and when a networking patch will be submitted to stable, my pending queue is always available for you to inspect here: http://patchwork.ozlabs.org/bundle/davem/stable/?state=* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] watchdog: omap_wdt: convert to new watchdog core
On Sat, 8 Sep 2012 21:04:01 +0300 Aaro Koskinen wrote: > Convert omap_wdt to new watchdog core. On OMAP boards, there are usually > multiple watchdogs. Since the new watchdog core supports multiple > watchdogs, all watchdog drivers used on OMAP should be converted. > > The legacy watchdog device node is still created, so this should not > break existing users. > > Signed-off-by: Aaro Koskinen > --- > > v2: Fix a bug in the first version of the patch: __omap_wdt_disable() > in probe was mistakenly moved outside PM runtime calls. This caused a > crash as device was probably accessed with some clocks off. Thanks to > Jarkko Nikula for reporting this. > > drivers/watchdog/Kconfig|1 + > drivers/watchdog/omap_wdt.c | 266 > ++- > 2 files changed, 114 insertions(+), 153 deletions(-) > Tested-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
On Mon, Sep 10, 2012 at 08:38:09AM +0200, Paolo Bonzini wrote:
> Il 10/09/2012 08:03, Michael S. Tsirkin ha scritto:
> > On Mon, Sep 10, 2012 at 07:50:13AM +0200, Paolo Bonzini wrote:
> >> Il 09/09/2012 00:22, Michael S. Tsirkin ha scritto:
> Almost. One is "the guest, if really needed, can tell the host of
> pages". If not negotiated, and the host does not support it, the host
> must break the guest (e.g. fail to offer any virtqueues).
> >>>
> >>> There is no way in spec to break the guest.
> >>> You can not fail to offer virtqueues.
> >>
> >> You can always return 0 for the first queue.
> >
> > I don't think guest drivers recover gracefully from this.
> > Do they?
>
> No, that's the point ("break the guest" is really "break the driver").
You can just stop VM then. No need for a side channel.
...
> The other is "the guest, though, would prefer not to do so". It is
> different because the guest can proceed in a fallback mode even if the
> host doesn't offer it.
> >>>
> >>> I think I get what your proposed SILENT means what I do not get
> >>> is the motivation. It looks like a premature optimization to me.
> >>
> >> The motivation is to let the driver choose between two behaviors: the
> >> current one where ballooning is only done on request, and a more
> >> aggressive one.
> >
> > Yes but why is being silent any good? Optimization?
> > Any data to show that it will help some workload?
>
> Idle guests can move cache pages to the balloon. You can overcommit
> more aggressively, because the host can madvise away a lot more memory.
IMHO this feature needs more thought. E.g. how will this work with assignment?
If we build something let's build it in a way that plays nicely
with other features.
> >>> OK so TELL says *when* to notify host, SILENT if set allows guest
> >>> to skip leak notifications? In this case TELL should just be ignored
> >>> when SILENT is set.
> >>
> >> Yeah, that was my first idea. However, there are existing drivers that
> >> ignore SILENT, so that would not be 100% exact.
> >
> > Not sure I follow the logic.
> > They don't ack SILENT so that would be 100% exact.
>
> Hmm, then I'm not sure I follow yours. We agreed that delaying
> notifications or skipping them is really the same thing, right?
>
> I think we're just stuck in a linguistic problem, with "must not" being
> wrong and "does not have to" being too verbose. Calling it
> VIRTIO_BALLOON_F_SILENT_DEFLATE was a workaround for this, but perhaps
> it adds more confusion.
>
> Paolo
Looks like it does :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump with iommu
(2012/09/10 11:34), Kaneshige, Kenji wrote: >> -Original Message- >> From: linux-pci-ow...@vger.kernel.org >> [mailto:linux-pci-ow...@vger.kernel.org] On Behalf Of Takao Indoh >> Sent: Wednesday, September 05, 2012 8:10 PM >> To: vgo...@redhat.com >> Cc: ke...@lists.infradead.org; linux-kernel@vger.kernel.org; >> linux-...@vger.kernel.org; bhelg...@google.com; hb...@us.ibm.com; Ishii, >> Hironobu/石井 宏延; martin.wi...@ts.fujitsu.com >> Subject: Re: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump >> with iommu >> >> (2012/08/07 5:39), Vivek Goyal wrote: >>> On Mon, Aug 06, 2012 at 01:30:47PM +0900, Takao Indoh wrote: Hi Vivek, (2012/08/03 20:46), Vivek Goyal wrote: > On Fri, Aug 03, 2012 at 08:24:31PM +0900, Takao Indoh wrote: >> Hi all, >> >> This patch adds kernel parameter "reset_pcie_devices" which resets >> PCIe >> devices at boot time to address DMA problem on kdump with iommu. When >> this parameter is specified, a hot reset is triggered on each PCIe >> root >> port and downstream port to reset its downstream endpoint. > > Hi Takao, > > Why not use existing "reset_devices" parameter instead of introducing > a new one? "reset_devices" is used for each driver to reset their own device, and this patch resets all devices forcibly, so I thought they were different things. >>> >>> Yes reset_devices currently is used for driver to reset its device. I >>> thought one could very well extend its reach to reset pci express devices >>> at bus level. >>> >>> Having them separate is not going to be much useful from kdump >>> perspective. We will end up passing both reset_devices and >>> reset_pcie_devices to second kernel whill lead to bus level reset as well >>> as device level reset. >>> >>> Ideal situation would be that somehow detect that bus level reset has >> been >>> done and skip device level reset (assuming bus level reset obviates the >>> need of device level reset, please correct me if that's not the case). >>> >>> After pcie reset, can we store the state in a variable and drivers can >>> use that variable to check if PCIe level reset was done or not. If yes, >>> skip device level reset (Assuming driver knows that device is on a >>> PCIe slot). >>> >>> In that case we will not have to introduce new kernel command line, and >>> also avoid double reset? >> >> I found a problem when testing my patch on some machines. >> >> Originally there are two problems in kdump kernel when iommu is enabled; >> DMAR error and PCI SERR. I thought they are fixed by my patch, but I >> noticed that PCI SERR is still detected after applying the patch. It >> seems that something happens when Interrupt Remapping is initialized in >> kdump kernel. > > I'm not sure, but I guess the PCI SERR might be caused as follows. > > - The 1st kernel enables interrupt remapping. The MSI(-X) address and >data registers of PCI devices are programmed in remappable format. > > - At the beginning of 2nd kernel, interrupt remapping is still active. >And then it is disabled by enable_IR() function for initialization. > > - PCI device generate an interrupt. At this moment, interrupt remapping >is not enabled yet. On the other hand, MSI(-X) address and data of this >interrupt is in remappable format because those are programmed by 1st >kernel. I guess this might be a cause of PCI SERR. > > I guess clearing command register or disabling MSI before interrupt > remapping initialization in 2nd kernel might solve the PCI SERR problem. Thank you for your comment. That makes sense. Though I think clearing bus master bit is enough, do you think I need to clear all command register bit not only bus master? Thanks, Takao Indoh > Regards, > Kenji Kaneshige > > >> >> Therefore resetting devices has to be done before enable_IR() is >> called. I have three ideas for it. >> >>(i) Resetting devices in 1st kernel(panic kernel) >>We can reset devices before jumping into 2nd kernel. Of course it may >>be dangerous to scan pci device tree and call PCI functions in panic'd >>kernel. Beforehand we need to collect device information so that only >>minimal code could run on panic. >> >>(ii) Resetting devices in purgatory >>It seems to be be appropriate place to do this, but I'm not sure >>where I can save/restore PCI config when resetting devices in >>purgatory. >> >>(iii) Resetting devices in 2nd kernel(kdump kernel) >>Important point is to do reset before enable_IR() is called as I wrote >>above. I think I should add new function to do reset into >>arch/x86/pci/early.c and call it in setup_arch like >>early_dump_pci_devices() or early_quirks(). >> >> Any comments? >> >> Thanks, >> Takao Indoh >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/maj
[PATCH] btrfs: fix disk-io.c/btrfs_read_dev_super with BTRFS_SUPER_MIRROR_MAX to control the loops
To check the duplicated super blocks, use BTRFS_SUPER_MIRROR_MAX
as the loops limit.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/disk-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 22e98e0..a431144 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2723,7 +2723,7 @@ struct buffer_head *btrfs_read_dev_super(struct
block_device *bdev)
* So, we need to add a special mount option to scan for
* later supers, using BTRFS_SUPER_MIRROR_MAX instead
*/
- for (i = 0; i < 1; i++) {
+ for (i = 0; i < BTRFS_SUPER_MIRROR_MAX; i++) {
bytenr = btrfs_sb_offset(i);
if (bytenr + 4096 >= i_size_read(bdev->bd_inode))
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/
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
Il 10/09/2012 08:03, Michael S. Tsirkin ha scritto:
> On Mon, Sep 10, 2012 at 07:50:13AM +0200, Paolo Bonzini wrote:
>> Il 09/09/2012 00:22, Michael S. Tsirkin ha scritto:
Almost. One is "the guest, if really needed, can tell the host of
pages". If not negotiated, and the host does not support it, the host
must break the guest (e.g. fail to offer any virtqueues).
>>>
>>> There is no way in spec to break the guest.
>>> You can not fail to offer virtqueues.
>>
>> You can always return 0 for the first queue.
>
> I don't think guest drivers recover gracefully from this.
> Do they?
No, that's the point ("break the guest" is really "break the driver").
>>> Besides, there is no guarantee that virtqueue setup
>>> happens after feature negotiation.
>>
>> It is the only way that makes sense though (unless the guest would write
>> 0 for its features). Should we change that?
>
> I do think it would be nice to add a generic way for device to
> notify guest about an internal failure.
> This can only happen after DRIVER_OK status is written though,
> and since existing drivers do not expect such failure, it might
> be too late.
Agreed.
The other is "the guest, though, would prefer not to do so". It is
different because the guest can proceed in a fallback mode even if the
host doesn't offer it.
>>>
>>> I think I get what your proposed SILENT means what I do not get
>>> is the motivation. It looks like a premature optimization to me.
>>
>> The motivation is to let the driver choose between two behaviors: the
>> current one where ballooning is only done on request, and a more
>> aggressive one.
>
> Yes but why is being silent any good? Optimization?
> Any data to show that it will help some workload?
Idle guests can move cache pages to the balloon. You can overcommit
more aggressively, because the host can madvise away a lot more memory.
>>> OK so TELL says *when* to notify host, SILENT if set allows guest
>>> to skip leak notifications? In this case TELL should just be ignored
>>> when SILENT is set.
>>
>> Yeah, that was my first idea. However, there are existing drivers that
>> ignore SILENT, so that would not be 100% exact.
>
> Not sure I follow the logic.
> They don't ack SILENT so that would be 100% exact.
Hmm, then I'm not sure I follow yours. We agreed that delaying
notifications or skipping them is really the same thing, right?
I think we're just stuck in a linguistic problem, with "must not" being
wrong and "does not have to" being too verbose. Calling it
VIRTIO_BALLOON_F_SILENT_DEFLATE was a workaround for this, but perhaps
it adds more confusion.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] thermal: add generic cpufreq cooling implementation
Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. From: Amit Daniel Kachhap Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal <-> Exynos thermal interface <- Temperature Sensor | | \|/| Cpufreq cooling device <--- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck Cc: SangWook Ju Cc: Durgadoss Cc: Len Brown Cc: Jean Delvare Cc: Kyungmin Park Cc: Kukjin Kim Signed-off-by: Zhang Rui Signed-off-by: Andrew Morton Signed-off-by: Amit Daniel Kachhap --- Documentation/thermal/cpu-cooling-api.txt | 33 ++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 450 + include/linux/cpu_cooling.h | 58 5 files changed, 553 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..6fe9cdb --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,33 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +"thermal-cpufreq-%x". This api can support multiple instances of cpufreq +cooling devices. + + clip_cpus: cpumask of cpus where the frequency constraints will happen. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the "thermal-cpufreq-%x" cooling device. + +cdev: Cooling device pointer which has to be unregistered. + diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 7dd8c34..996003b 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -19,6 +
[PATCH 1/2] mtd: add helpers to set/get features for ONFI nand
Add the set-features(0xef)/get-features(0xee) helpers for ONFI nand.
Also add the necessary macros.
Signed-off-by: Huang Shijie
---
drivers/mtd/nand/nand_base.c | 50 ++
include/linux/mtd/nand.h | 14 +++
2 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 88f671c..fbc49cc 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2700,6 +2700,50 @@ static int nand_block_markbad(struct mtd_info *mtd,
loff_t ofs)
}
/**
+ * nand_onfi_set_features- [REPLACEABLE] set features for ONFI nand
+ * @mtd: MTD device structure
+ * @chip: nand chip info structure
+ * @feature_addr: feature address.
+ * @subfeature_para: the subfeature parameters, a four bytes array.
+ */
+static int nand_onfi_set_features(struct mtd_info *mtd, struct nand_chip *chip,
+ int feature_addr, uint8_t *subfeature_para)
+{
+ int status;
+
+ if (!chip->onfi_version)
+ return -EINVAL;
+
+ chip->cmdfunc(mtd, NAND_CMD_SET_FEATURES, feature_addr, -1);
+ chip->write_buf(mtd, subfeature_para, ONFI_SUBFEATURE_PARA_LEN);
+ status = chip->waitfunc(mtd, chip);
+ if (status & NAND_STATUS_FAIL)
+ return -EIO;
+ return 0;
+}
+
+/**
+ * nand_onfi_get_features- [REPLACEABLE] get features for ONFI nand
+ * @mtd: MTD device structure
+ * @chip: nand chip info structure
+ * @feature_addr: feature address.
+ * @subfeature_para: the subfeature parameters, a four bytes array.
+ */
+static int nand_onfi_get_features(struct mtd_info *mtd, struct nand_chip *chip,
+ int feature_addr, uint8_t *subfeature_para)
+{
+ if (!chip->onfi_version)
+ return -EINVAL;
+
+ /* clear the sub feature parameters */
+ memset(subfeature_para, 0, ONFI_SUBFEATURE_PARA_LEN);
+
+ chip->cmdfunc(mtd, NAND_CMD_GET_FEATURES, feature_addr, -1);
+ chip->read_buf(mtd, subfeature_para, ONFI_SUBFEATURE_PARA_LEN);
+ return 0;
+}
+
+/**
* nand_suspend - [MTD Interface] Suspend the NAND flash
* @mtd: MTD device structure
*/
@@ -3223,6 +3267,12 @@ int nand_scan_tail(struct mtd_info *mtd)
if (!chip->write_page)
chip->write_page = nand_write_page;
+ /* set for ONFI nand */
+ if (!chip->onfi_set_features)
+ chip->onfi_set_features = nand_onfi_set_features;
+ if (!chip->onfi_get_features)
+ chip->onfi_get_features = nand_onfi_get_features;
+
/*
* Check ECC mode, default to software if 3byte/512byte hardware ECC is
* selected and we have 256 byte pagesize fallback to software ECC
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 8f99d36..641794c 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -92,6 +92,8 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs,
uint64_t len);
#define NAND_CMD_READID0x90
#define NAND_CMD_ERASE20xd0
#define NAND_CMD_PARAM 0xec
+#define NAND_CMD_GET_FEATURES 0xee
+#define NAND_CMD_SET_FEATURES 0xef
#define NAND_CMD_RESET 0xff
#define NAND_CMD_LOCK 0x2a
@@ -229,6 +231,12 @@ typedef enum {
/* Keep gcc happy */
struct nand_chip;
+/* ONFI feature address */
+#define ONFI_FEATURE_ADDR_TIMING_MODE 0x1
+
+/* ONFI subfeature parameters length */
+#define ONFI_SUBFEATURE_PARA_LEN 4
+
struct nand_onfi_params {
/* rev info and features block */
/* 'O' 'N' 'F' 'I' */
@@ -452,6 +460,8 @@ struct nand_buffers {
* non 0 if ONFI supported.
* @onfi_params: [INTERN] holds the ONFI page parameter when ONFI is
* supported, 0 otherwise.
+ * @onfi_set_features [REPLACEABLE] set the features for ONFI nand
+ * @onfi_get_features [REPLACEABLE] get the features for ONFI nand
* @ecclayout: [REPLACEABLE] the default ECC placement scheme
* @bbt: [INTERN] bad block table pointer
* @bbt_td:[REPLACEABLE] bad block table descriptor for flash
@@ -494,6 +504,10 @@ struct nand_chip {
int (*write_page)(struct mtd_info *mtd, struct nand_chip *chip,
const uint8_t *buf, int oob_required, int page,
int cached, int raw);
+ int (*onfi_set_features)(struct mtd_info *mtd, struct nand_chip *chip,
+ int feature_addr, uint8_t *subfeature_para);
+ int (*onfi_get_features)(struct mtd_info *mtd, struct nand_chip *chip,
+ int feature_addr, uint8_t *subfeature_para);
int chip_delay;
unsigned int options;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tu
[PATCH 2/2] mtd: add helpers to get the supportted ONFI timing mode
add onfi_get_async_timing_mode() to get the supportted asynchronous
timing mode.
add onfi_get_sync_timing_mode() to get the supportted synchronous
timing mode.
Also add the neccessary macros : the timing modes.
Signed-off-by: Huang Shijie
---
include/linux/mtd/nand.h | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 641794c..83b85a1 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -231,6 +231,14 @@ typedef enum {
/* Keep gcc happy */
struct nand_chip;
+/* ONFI timing mode, used in both asynchronous and synchronous mode */
+#define ONFI_TIMING_MODE_0 (1 << 0)
+#define ONFI_TIMING_MODE_1 (1 << 1)
+#define ONFI_TIMING_MODE_2 (1 << 2)
+#define ONFI_TIMING_MODE_3 (1 << 3)
+#define ONFI_TIMING_MODE_4 (1 << 4)
+#define ONFI_TIMING_MODE_5 (1 << 5)
+
/* ONFI feature address */
#define ONFI_FEATURE_ADDR_TIMING_MODE 0x1
@@ -682,4 +690,16 @@ struct platform_nand_chip *get_platform_nandchip(struct
mtd_info *mtd)
return chip->priv;
}
+/* return the supported asynchronous timing mode. */
+static inline int onfi_get_async_timing_mode(struct nand_chip *chip)
+{
+ return le16_to_cpu(chip->onfi_params.async_timing_mode);
+}
+
+/* return the supported synchronous timing mode. */
+static inline int onfi_get_sync_timing_mode(struct nand_chip *chip)
+{
+ return le16_to_cpu(chip->onfi_params.src_sync_timing_mode);
+}
+
#endif /* __LINUX_MTD_NAND_H */
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] devfreq: Add suspend and resume apis
On 10 September 2012 03:21, Rafael J. Wysocki wrote:
> On Monday, September 03, 2012, Rajagopal Venkat wrote:
>> Add devfreq suspend/resume apis for devfreq users. This patch
>> supports suspend and resume of devfreq load monitoring, required
>> for devices which can idle.
>>
>> Signed-off-by: Rajagopal Venkat
>
> I'd call the new functions devfreq_dev_suspend() and devfreq_dev_resume(),
> respectively, because the names you're using currently suggest that the
> device itself is suspended/resumed, which isn't the case.
devfreq_add_device() and devfreq_remove_device() are two existing APIs.
I did follow same naming pattern to maintain uniformity and introduced
devfreq_suspend_device() and devfreq_resume_device() functions.
Do you suggest to follow devfreq_dev_xxx pattern even for existing APIs?
>
> Thanks,
> Rafael
>
>
>> ---
>> drivers/devfreq/devfreq.c | 26 ++
>> drivers/devfreq/governor.h| 2 ++
>> drivers/devfreq/governor_simpleondemand.c | 9 +
>> include/linux/devfreq.h | 12
>> 4 files changed, 49 insertions(+)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index be524c7..3a5f126 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -365,6 +365,32 @@ int devfreq_remove_device(struct devfreq *devfreq)
>> }
>> EXPORT_SYMBOL(devfreq_remove_device);
>>
>> +/**
>> + * devfreq_suspend_device() - Suspend devfreq of a device.
>> + * @devfreq the devfreq instance to be suspended
>> + */
>> +int devfreq_suspend_device(struct devfreq *devfreq)
>> +{
>> + if (!devfreq)
>> + return -EINVAL;
>> +
>> + return devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_SUSPEND);
>> +}
>> +EXPORT_SYMBOL(devfreq_suspend_device);
>> +
>> +/**
>> + * devfreq_resume_device() - Resume devfreq of a device.
>> + * @devfreq the devfreq instance to be resumed
>> + */
>> +int devfreq_resume_device(struct devfreq *devfreq)
>> +{
>> + if (!devfreq)
>> + return -EINVAL;
>> +
>> + return devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_RESUME);
>> +}
>> +EXPORT_SYMBOL(devfreq_resume_device);
>> +
>> static ssize_t show_governor(struct device *dev,
>>struct device_attribute *attr, char *buf)
>> {
>> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
>> index 4a86af7..7dbbdfc 100644
>> --- a/drivers/devfreq/governor.h
>> +++ b/drivers/devfreq/governor.h
>> @@ -22,6 +22,8 @@
>> #define DEVFREQ_GOV_START0x1
>> #define DEVFREQ_GOV_STOP 0x2
>> #define DEVFREQ_GOV_INTERVAL 0x3
>> +#define DEVFREQ_GOV_SUSPEND 0x4
>> +#define DEVFREQ_GOV_RESUME 0x5
>>
>> /* Caution: devfreq->lock must be locked before calling update_devfreq */
>> extern int update_devfreq(struct devfreq *devfreq);
>> diff --git a/drivers/devfreq/governor_simpleondemand.c
>> b/drivers/devfreq/governor_simpleondemand.c
>> index 9802bf9..35b8e8e 100644
>> --- a/drivers/devfreq/governor_simpleondemand.c
>> +++ b/drivers/devfreq/governor_simpleondemand.c
>> @@ -113,6 +113,15 @@ int devfreq_simple_ondemand_handler(struct devfreq
>> *devfreq,
>> else
>> ret = devfreq_monitor_resume(devfreq);
>> break;
>> +
>> + case DEVFREQ_GOV_SUSPEND:
>> + ret = devfreq_monitor_suspend(devfreq);
>> + break;
>> +
>> + case DEVFREQ_GOV_RESUME:
>> + ret = devfreq_monitor_resume(devfreq);
>> + break;
>> +
>> default:
>> break;
>> }
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index 7a11c3e..7c7e179 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -155,6 +155,8 @@ extern struct devfreq *devfreq_add_device(struct device
>> *dev,
>> const struct devfreq_governor *governor,
>> void *data);
>> extern int devfreq_remove_device(struct devfreq *devfreq);
>> +extern int devfreq_suspend_device(struct devfreq *devfreq);
>> +extern int devfreq_resume_device(struct devfreq *devfreq);
>>
>> /* Helper functions for devfreq user device driver with OPP. */
>> extern struct opp *devfreq_recommended_opp(struct device *dev,
>> @@ -208,6 +210,16 @@ static int devfreq_remove_device(struct devfreq
>> *devfreq)
>> return 0;
>> }
>>
>> +static int devfreq_suspend_device(struct devfreq *devfreq)
>> +{
>> + return 0;
>> +}
>> +
>> +static int devfreq_resume_device(struct devfreq *devfreq)
>> +{
>> + return 0;
>> +}
>> +
>> static struct opp *devfreq_recommended_opp(struct device *dev,
>> unsigned long *freq, u32 flags)
>> {
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordom
Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer
On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote:
>I've seen a couple examples recently where we've gotten this wrong.
>Maybe something like this would help? Is there some better way?
>(Approximation due to Jim Rees).
>
>+/*
>+ * length of the decimal representation of an unsigned integer. Just an
>+ * approximation, but it's right for types of size 1 to 36 bytes:
>+ */
>+#define base10len(i) (sizeof(i) * 24 / 10 + 1)
gcc provides... "interesting" features at times.
/* for unsigned "i"s */
#define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[i])
But enumerating it (using your ULONG_MAX_STR proposal) should be
sufficient, since there is only a limited number of types that get e.g.
sprintf'ed into a buffer.
Something else tho, it seems some don't know that sizeof("") is already
1, and an extra \0 is often unneeded, like in:
arch/um/drivers/net_user.c: char addr_buf[sizeof("255.255.255.255\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/3] devfreq: core updates to support devices which can idle
On 10 September 2012 03:16, Rafael J. Wysocki wrote:
> On Monday, September 03, 2012, Rajagopal Venkat wrote:
>> Prepare devfreq core framework to support devices which
>> can idle. When device idleness is detected perhaps through
>> runtime-pm, need some mechanism to suspend devfreq load
>> monitoring and resume back when device is online. Present
>> code continues monitoring unless device is removed from
>> devfreq core.
>>
>> This patch introduces following design changes,
>>
>> - use per device work instead of global work to monitor device
>> load. This enables suspend/resume of device devfreq and
>> reduces monitoring code complexity.
>> - decouple delayed work based load monitoring logic from core
>> by introducing helpers functions to be used by governors. This
>> provides flexibility for governors either to use delayed work
>> based monitoring functions or to implement their own mechanism.
>> - devfreq core interacts with governors via events to perform
>> specific actions. These events include start/stop devfreq.
>> This sets ground for adding suspend/resume events.
>>
>> The devfreq apis are not modified and are kept intact.
>>
>> Signed-off-by: Rajagopal Venkat
>
> This one looks like a nice simplification. I wonder if everyone in the CC
> list
> is fine with it?
>
> One remark below.
>
>> ---
>> drivers/devfreq/devfreq.c | 376
>> ++
>> drivers/devfreq/governor.h| 9 +
>> drivers/devfreq/governor_performance.c| 16 +-
>> drivers/devfreq/governor_powersave.c | 16 +-
>> drivers/devfreq/governor_simpleondemand.c | 33 +++
>> drivers/devfreq/governor_userspace.c | 23 +-
>> include/linux/devfreq.h | 31 +--
>> 7 files changed, 220 insertions(+), 284 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index b146d76..be524c7 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -30,17 +30,11 @@
>> struct class *devfreq_class;
>>
>> /*
>> - * devfreq_work periodically monitors every registered device.
>> - * The minimum polling interval is one jiffy. The polling interval is
>> - * determined by the minimum polling period among all polling devfreq
>> - * devices. The resolution of polling interval is one jiffy.
>> + * devfreq core provides delayed work based load monitoring helper
>> + * functions. Governors can use these or can implement their own
>> + * monitoring mechanism.
>> */
>> -static bool polling;
>> static struct workqueue_struct *devfreq_wq;
>> -static struct delayed_work devfreq_work;
>> -
>> -/* wait removing if this is to be removed */
>> -static struct devfreq *wait_remove_device;
>>
>> /* The list of all device-devfreq */
>> static LIST_HEAD(devfreq_list);
>> @@ -72,6 +66,8 @@ static struct devfreq *find_device_devfreq(struct device
>> *dev)
>> return ERR_PTR(-ENODEV);
>> }
>>
>> +/* Load monitoring helper functions for governors use */
>> +
>> /**
>> * update_devfreq() - Reevaluate the device and configure frequency.
>> * @devfreq: the devfreq instance.
>> @@ -121,6 +117,90 @@ int update_devfreq(struct devfreq *devfreq)
>> }
>>
>> /**
>> + * devfreq_monitor() - Periodically poll devfreq objects.
>> + * @work: the work struct used to run devfreq_monitor periodically.
>> + *
>> + */
>> +static void devfreq_monitor(struct work_struct *work)
>> +{
>> + int err;
>> + struct devfreq *devfreq = container_of(work,
>> + struct devfreq, work.work);
>> +
>> + mutex_lock(&devfreq->lock);
>> + err = update_devfreq(devfreq);
>> + mutex_unlock(&devfreq->lock);
>> + if (err)
>> + dev_err(&devfreq->dev, "dvfs failed with (%d) error\n", err);
>> +
>> + queue_delayed_work(devfreq_wq, &devfreq->work,
>> +
>> msecs_to_jiffies(devfreq->profile->polling_ms));
>> +}
>> +
>> +/**
>> + * devfreq_monitor_start() - Start load monitoring of devfreq instance
>> + * using default delayed work
>> + * @devfreq: the devfreq instance.
>> + *
>> + * Returns 0 if monitoring started, non-zero otherwise.
>> + * Note: This function is exported for governors.
>> + */
>> +int devfreq_monitor_start(struct devfreq *devfreq)
>> +{
>> + INIT_DEFERRABLE_WORK(&devfreq->work, devfreq_monitor);
>> + return !queue_delayed_work(devfreq_wq, &devfreq->work,
>> + msecs_to_jiffies(devfreq->profile->polling_ms));
>> +}
>> +
>> +/**
>> + * devfreq_monitor_stop() - Stop load monitoring of a devfreq instance
>> + * @devfreq: the devfreq instance.
>> + *
>> + * Note: This function is exported for governors.
>> + */
>> +void devfreq_monitor_stop(struct devfreq *devfreq)
>> +{
>> + cancel_delayed_work_sync(&devfreq->work);
>> +}
>> +
>> +/**
>> + * devfreq_monitor_suspend() - Suspend load monitoring of a devfreq instance
>> + * @devfreq:the devfreq instance.
>> + *
>> + * Note: This fun
Re: [ 35/95] dccp: check ccid before dereferencing
Hi Ben, On Mon, Sep 10, 2012 at 12:42 AM, Ben Hutchings wrote: > 3.2-stable review patch. If anyone has any objections, please let me know. No objections, but could you please consider including the following commits, too?: e862f1a atm: fix info leak in getsockopt(SO_ATMPVC) 3c0c5cf atm: fix info leak via getsockname() e15ca9a Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER) 3f68ba0 Bluetooth: HCI - Fix info leak via getsockname() 9ad2de4 Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY) f9432c5 Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST) 9344a97 Bluetooth: RFCOMM - Fix info leak via getsockname() 792039c Bluetooth: L2CAP - Fix info leak via getsockname() 04d4fbc l2tp: fix info leak via getsockname() 3592aae llc: fix info leak via getsockname() 7b07f8e dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO) 2d8a041 ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT) 43da5f2 net: fix info leak in compat dev_ifconf() Those were not CCed to stable but David wanted to queue them anyway. See http://marc.info/?l=linux-kernel&m=134509201708293&w=2 Thanks, Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 clk tree with the arm-soc tree
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
arch/arm/mach-ux500/clock.c between commit 79964bcd792f ("ARM: ux500:
Correct Ux500 family names usage") from the arm-soc tree and commit
ebc96db7632f ("ARM: ux500: Switch to use common clock framework") from
the clk tree.
The latter removed the file so I did that - there may be more fixup
required.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpLDDFJvClxd.pgp
Description: PGP signature
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
On Mon, Sep 10, 2012 at 07:50:13AM +0200, Paolo Bonzini wrote: > Il 09/09/2012 00:22, Michael S. Tsirkin ha scritto: > >> Almost. One is "the guest, if really needed, can tell the host of > >> pages". If not negotiated, and the host does not support it, the host > >> must break the guest (e.g. fail to offer any virtqueues). > > > > There is no way in spec to break the guest. > > You can not fail to offer virtqueues. > > You can always return 0 for the first queue. I don't think guest drivers recover gracefully from this. Do they? > > Besides, there is no guarantee that virtqueue setup > > happens after feature negotiation. > > It is the only way that makes sense though (unless the guest would write > 0 for its features). > Should we change that? Not sure. This was not always the case. Further setup can fail with e.g ENOMEM and driver could retry with a set of more conservative features. I do think it would be nice to add a generic way for device to notify guest about an internal failure. This can only happen after DRIVER_OK status is written though, and since existing drivers do not expect such failure, it might be too late. > >> The other is "the guest, though, would prefer not to do so". It is > >> different because the guest can proceed in a fallback mode even if the > >> host doesn't offer it. > > > > I think I get what your proposed SILENT means what I do not get > > is the motivation. It looks like a premature optimization to me. > > The motivation is to let the driver choose between two behaviors: the > current one where ballooning is only done on request, and a more > aggressive one. Yes but why is being silent any good? Optimization? Any data to show that it will help some workload? ... > > OK so TELL says *when* to notify host, SILENT if set allows guest > > to skip leak notifications? In this case TELL should just be ignored > > when SILENT is set. > > Yeah, that was my first idea. However, there are existing drivers that > ignore SILENT, so that would not be 100% exact. Not sure I follow the logic. They don't ack SILENT so that would be 100% exact. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: v4l2-ctrls: add control for dpcm predictor
From: Lad, Prabhakar
add V4L2_CID_DPCM_PREDICTOR control of type menu, which
determines the dpcm predictor. The predictor can be either
simple or advanced.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Acked-by: Hans Verkuil
Reviewed-by: Sylwester Nawrocki
Cc: Sakari Ailus
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Hans de Goede
Cc: Kyungmin Park
Cc: Rob Landley
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.
Changes for v5:
1: Changed the control's name to 'Simple' and 'Advanced'
as pointed by Sakari.
2: Changed the description of DPCM. Thanks to Sakari for
providing the description.
Changes for v4:
1: Aligned the description to fit appropriately in the
para tag, pointed by Sylwester.
Changes for v3:
1: Added better explanation for DPCM, pointed by Hans.
Changes for v2:
1: Added documentaion in controls.xml pointed by Sylwester.
2: Chnaged V4L2_DPCM_PREDICTOR_ADVANCE to V4L2_DPCM_PREDICTOR_ADVANCED
pointed by Sakari.
Documentation/DocBook/media/v4l/controls.xml | 39 +-
drivers/media/v4l2-core/v4l2-ctrls.c |9 ++
include/linux/videodev2.h|5 +++
3 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 93b9c68..2c1599f 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4267,7 +4267,44 @@ interface and may change in the future.
pixels / second.
-
+
+ V4L2_CID_DPCM_PREDICTOR
+ menu
+
+
+Differential pulse-code modulation (DPCM)
compression can
+ be used to compress the samples into fewer bits than they would
otherwise require.
+ This is done by calculating the difference between consecutive
samples and outputting
+ the difference which in average is much smaller than the values of
the samples
+ themselves since there is generally lots of correlation between
adjacent pixels. In
+ decompression the original samples are reconstructed. The process
isn't lossless as
+ the encoded sample size in bits is less than the original.
+
+ Formats using DPCM compression include .
+
+ This control is used to select the predictor used to encode
the samples.
+
+ The main difference between the simple and the advanced
predictors is image quality,
+ with advanced predictor supposed to produce better quality images
as a result. Simple
+ predictor can be used e.g. for testing purposes. For more
information about DPCM see http://en.wikipedia.org/wiki/Differential_pulse-code_modulation";>Wikipedia.
+
+
+
+
+
+
+V4L2_DPCM_PREDICTOR_SIMPLE
+ Predictor type is simple
+
+
+
V4L2_DPCM_PREDICTOR_ADVANCED
+ Predictor type is advanced
+
+
+
+
+
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6a2ee7..8f2f40b 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -425,6 +425,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Gray",
NULL,
};
+ static const char * const dpcm_predictor[] = {
+ "Simple",
+ "Advanced",
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +507,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DPCM_PREDICTOR:
+ return dpcm_predictor;
default:
return NULL;
@@ -732,6 +739,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IMAGE_PROC_CLASS: return "Image Processing
Controls";
case V4L2_CID_LINK_FREQ:return "Link Frequency";
case V4L2_CID_PIXEL_RATE: return "Pixel Rate";
+ case V4L2_CID_DPCM_PREDICTOR: return "DPCM Predictor";
default:
return NULL;
@@ -832,6 +840,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DPCM_PREDICTOR:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 6d6
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > +4. Call the kernel image > > > + > > > + > > > +Requirement: MANDATORY > > > + > > > +The decompressed kernel image contains a 32-byte header as follows: > > > + > > > + u32 magic = 0x1408; /* branch to stext, little-endian */ > > > + u32 res0 = 0;/* reserved */ > > > + u64 text_offset; /* Image load offset */ > > > + u64 res1 = 0;/* reserved */ > > > + u64 res2 = 0;/* reserved */ > > we need to have a magic to known it's a arm64 kernel > > You have it: it's 0x1408 at the beginning. fragile > > > > + > > > +The image must be placed at the specified offset (currently 0x8) > > > +from the start of the system RAM and called there. The start of the > > > +system RAM must be aligned to 2MB. > > can we drop this > > Drop what? > And why? This contrain the must be loadable at any address Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
Il 10/09/2012 03:43, Rusty Russell ha scritto: >> Now that vfio is upstream and work on qemu integration >> is being worked on, we might finally see people using this bit >> to allow memory overcommit with device assignment. > That was left-field so you're saying some guest might pull a page > from the balloon and DMA to it, and the vfio device needs to know in > advance that it's going to do it? Not the vfio device, but the page needs to be pinned with mlock so the effect is the same. > But what will we do if the guest doesn't ack the bit? Just pin the whole memory. Paolo > ie. I don't think it can really be optional. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: manual merge of the hid tree with Linus' tree
Dear Stephen Rothwell,
> Hi Jiri,
>
> Today's linux-next merge of the hid tree got a conflict in
> drivers/hid/usbhid/hid-quirks.c between commit 67ddbb3e6568 ("HID: add
> NOGET quirk for Eaton Ellipse MAX UPS") from Linus' tree and commit
> 2843b673d034 ("HID: add quirk for Freescale i.MX28 ROM recovery") from
> the hid tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary (no action is required).
Looks obviously correct, thank you Stephen!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
On Mon, Sep 10, 2012 at 11:13:12AM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" writes: > > On Sat, Sep 08, 2012 at 02:36:00PM +0930, Rusty Russell wrote: > >> "Michael S. Tsirkin" writes: > >> > On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote: > >> >> > So it looks like a bug: we should teach driver to tell host first on > >> >> > leak? > >> >> > Yan, Vadim, can you comment please? > >> >> > > >> >> > Also if true, looks like this bit will be useful to detect a fixed > >> >> > driver on > >> >> > the hypervisor side - to avoid unmapping such pages? Rusty what do you > >> >> > think? > >> >> > >> >> So, feature is unimplemented in qemu, and broken in drivers. I starting > >> >> to share Paolo's dislike of it. > >> > > >> > What is broken in drivers? > >> > >> Because supporting the feature is *not* optional for a driver. > >> > >> If the device said MUST_TELL_HOST, it meant that the driver *had* to > >> tell the host before it touched the page, otherwise Bad Things might > >> happen. It was in the original spec precisely to allow devices to > >> actually *remove* pages. > >> > >> Noone ever noticed the windows driver didn't support it, because qemu > >> never requires MUST_TELL_HOST. > >> > >> So in practice, it's now an optional feature. Since no device used it > >> anyway, we're better off discarding it than trying to fix it. > > > > I trust you this was not the intent. But it seems to be > > the intent in spec, because almost all features are optional. > > > > And so windows driver authors interpreted it > > this way. And it is *useful* like this. See below. > > ... > > > Suggested use is for device assignment which needs all guest memory > > locked. hypervisor can unlock pages in balloon but guest must wait for > > hypervisor to lock them back before use. > > > > when a hypervisor implements this, > > this will work with linux guests but not windows > > guests and the existing bit fits exactly the purpose. > > If a hypervisor needs this, and the guest doesn't support it, then > the hypervisor can only abandon the balloon device. That's not my > definition of "optional". > > >> > Do we really know there are no hypervisors implementing it? > >> > >> As much as can be known. Qemu doesn't, lkvm doesn't. > > > > But we can add it in qemu and it will be a useful feature. > > > >> > As I said above drivers do have support. > >> > >> Not the windows drivers. So it's optional, thus removing it will likely > >> harm noone. > >> > >> Cheers, > >> Rusty. > > > > I think the issue is that kvm always locked all guest memory > > for assignment. This restriction is removed > > with vfio which has separate page tables. > > Now that vfio is upstream and work on qemu integration > > is being worked on, we might finally see people using this bit > > to allow memory overcommit with device assignment. > > That was left-field so you're saying some guest might pull a page > from the balloon and DMA to it, and the vfio device needs to know in > advance that it's going to do it? > > But what will we do if the guest doesn't ack the bit? > ie. I don't think it can really be optional. > > Cheers, > Rusty. We have several options: 1. No memory overcommit feature. This is always the case ATM! 2. Do not hot-plug assigned device. 3. Hot-unplug assigned device. 4. Some assigned devices can be able to handle memory errors e.g. using ATS. Limit hotplug to these. > I don't think it can really be optional. It is optional *for the device*. But I don't insist on my patch. I am merely saying that 1. The bit is useful for host to detect guests which can't combine memory overcommit with device assignment, and this set of guests is not empty. 2. The fact that this bit is not optional for drivers is not well documented. The only hint seems the use of words "feature is set" as opposed to "feature is negoticated" as with other features. The spec intended "feature is set in Device Features bits". Drivers interpreted this as "feature is set in Guest Features bits". Hard to blame them, let us give them time to address this. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
Il 09/09/2012 00:22, Michael S. Tsirkin ha scritto: >> Almost. One is "the guest, if really needed, can tell the host of >> pages". If not negotiated, and the host does not support it, the host >> must break the guest (e.g. fail to offer any virtqueues). > > There is no way in spec to break the guest. > You can not fail to offer virtqueues. You can always return 0 for the first queue. > Besides, there is no guarantee that virtqueue setup > happens after feature negotiation. It is the only way that makes sense though (unless the guest would write 0 for its features). Should we change that? >> The other is "the guest, though, would prefer not to do so". It is >> different because the guest can proceed in a fallback mode even if the >> host doesn't offer it. > > I think I get what your proposed SILENT means what I do not get > is the motivation. It looks like a premature optimization to me. The motivation is to let the driver choose between two behaviors: the current one where ballooning is only done on request, and a more aggressive one. > The spec is pretty clear that if guest acks feature it > is a contract that dictates behaviour. > If it doesn't it is either ignored or just informative > depending on feature. > >> You could negotiate VIRTIO_BLK_F_TOPOLOGY >> and end up never reading the fields; you could negotiate >> VIRTIO_NET_F_GUEST_ANNOUNCE and never send a guest announcement. > > Block example is just informative. It does not need to be > negotiated even to be used. But last example is wrong. > If you ack GUEST_ANNOUNCE hypervisor assumes guest will > announce self, if guest does not do it this break migration. It is wrong indeed, sorry. Better example: the driver can negotiate VIRTIO_NET_F_CTRL_RX and never set promiscuous mode. The device has to obey if it does. Similarly, if you set VIRTIO_BALLOON_F_SILENT_DEFLATE and only do chatty deflate later, that's fine. If you do silent deflate, and the device negotiated the feature, it has to work. >> Delaying or avoiding is the same in the end. The spec says it well: "In >> this case, deflation advice is merely a courtesy". > > So it looks like we don't need a new bit to leak in atomic ctx. > Just do not ack MUST_TELL_HOST and delay telling host to a wq. > IMO we should not add random stuff to spec like this just because it > seems like a good idea. But this way you have to choose all-or-none. If the host cannot do silent deflate, you cannot balloon anymore, not even in the normal "cooperative" mode. > OK so TELL says *when* to notify host, SILENT if set allows guest > to skip leak notifications? In this case TELL should just be ignored > when SILENT is set. Yeah, that was my first idea. However, there are existing drivers that ignore SILENT, so that would not be 100% exact. > IMHO, renaming is fine since there is confusion. > But WILL_TELL is also not all that clear imho. > I think the confusion is that TELL_HOST seems to > imply we can avoid telling host at all. > How about being explicit? > > VIRTIO_BALLOON_F_HOST_ACK_BEFORE_DEFLATE Makes sense. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the samsung tree with the mips tree
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
drivers/pinctrl/Makefile between commit 3fa68afc3d77 ("OF: pinctrl: MIPS:
lantiq: implement lantiq/xway pinctrl support") from the mips tree and
commit 30574f0db1b1 ("pinctrl: add samsung pinctrl and gpiolib driver")
from the samsung tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/pinctrl/Makefile
index 26a86c7,6a88113..000
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@@ -33,7 -29,7 +33,9 @@@ obj-$(CONFIG_PINCTRL_TEGRA20) += pinctr
obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_U300)+= pinctrl-u300.o
obj-$(CONFIG_PINCTRL_COH901) += pinctrl-coh901.o
+obj-$(CONFIG_PINCTRL_XWAY)+= pinctrl-xway.o
+obj-$(CONFIG_PINCTRL_LANTIQ) += pinctrl-lantiq.o
+ obj-$(CONFIG_PINCTRL_SAMSUNG) += pinctrl-samsung.o
+ obj-$(CONFIG_PINCTRL_EXYNOS4) += pinctrl-exynos.o
obj-$(CONFIG_PLAT_SPEAR) += spear/
pgpwV092jOAGy.pgp
Description: PGP signature
[git pull] drm fixes
Hi Linus, just noticed I hadn't send these out, nothing majorly urgent, I know AMD guys have some regression fixes coming soon, This contains: 2 nouveau fixes so it loads on the retina MBP systems properly, 2 vmwgfx fixes to load the driver earlier, and allow distros config it 1 error->debug fix in ast and Keith was playing with 32-on-64 and decided we may as well stick the compat ioctl in all the drivers. It fixes udl for him. Dave. The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to c4903429a92be60e6fe59868924a65eca4cd1a38: drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot (2012-09-07 13:25:34 +1000) Ben Skeggs (2): drm/nvd0/disp: hopefully fix selection of 6/8bpc mode on DP outputs drm/nv50-/gpio: initialise to vbios defaults during init Dave Airlie (4): Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/nouveau/linux-2.6 into drm-fixes drm/ast: drop debug level on error printk drm/vmwgfx: allow a kconfig option to choose if fbcon is enabled drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot Keith Packard (1): drm: use drm_compat_ioctl for 32-bit apps drivers/gpu/drm/ast/ast_drv.c |3 +++ drivers/gpu/drm/ast/ast_mode.c |2 +- drivers/gpu/drm/cirrus/cirrus_drv.c |3 +++ drivers/gpu/drm/exynos/exynos_drm_drv.c |3 +++ drivers/gpu/drm/i810/i810_dma.c |3 +++ drivers/gpu/drm/i810/i810_drv.c |3 +++ drivers/gpu/drm/mgag200/mgag200_drv.c |3 +++ drivers/gpu/drm/nouveau/nv50_gpio.c |3 +++ drivers/gpu/drm/nouveau/nvd0_display.c |4 ++-- drivers/gpu/drm/savage/savage_drv.c |3 +++ drivers/gpu/drm/sis/sis_drv.c |3 +++ drivers/gpu/drm/tdfx/tdfx_drv.c |3 +++ drivers/gpu/drm/udl/udl_drv.c |3 +++ drivers/gpu/drm/via/via_drv.c |3 +++ drivers/gpu/drm/vmwgfx/Kconfig |8 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |3 ++- 16 files changed, 49 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] backlight: add new lm3639 backlight driver
On 09/09/2012 08:16 PM, G.Shark Jeong wrote: > From: "G.Shark Jeong" > > This driver is a general version for LM3639 backlgiht driver chip of TI. > > Put NEW_LEDS and LEDS_CLASS into Kconfig file to reduce additional > configuration works in LEDs. > > www.ti.com eh? > > Signed-off-by: G.Shark Jeong Linus has asked patch committers to use Reported-by when appropriate. Reported-by: Randy Dunlap Acked-by: Randy Dunlap > --- > drivers/video/backlight/Kconfig |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig > index 2ed68bd..e6c78cd 100644 > --- a/drivers/video/backlight/Kconfig > +++ b/drivers/video/backlight/Kconfig > @@ -356,6 +356,8 @@ config BACKLIGHT_LM3639 > tristate "Backlight Driver for LM3639" > depends on BACKLIGHT_CLASS_DEVICE && I2C > select REGMAP_I2C > + select NEW_LEDS > + select LEDS_CLASS > help > This supports TI LM3639 Backlight + 1.5A Flash LED Driver > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!
On 09/09/2012 06:56 PM, H. Peter Anvin wrote: >> >> Anyway, that means that the BUG_ON() is likely bogus, but so is the >> whole calling convention. >> >> The 4kB range starting at 0xf000 sounds like a *valid* >> range, but that requires that we fix the calling convention to not >> have that "end" (exclusive) thing. It should either be "end" >> (inclusive), or just "len". >> > > On x86, it is definitely NOT a valid range. There is no physical addresses > there, and there will never be any. This reminds me a similar issue: If you try to mmap /dev/kmem at an offset which is not kernel owned (such as 0), you'll get all the way to __pa() before getting a BUG() about addresses not making sense. How come there's no arch-specific validation of attempts to access virtual/physical addresses? In the kmem example I'd assume that something very early on should be yelling at me about doing something like that, but for some reason I get all the way to __pa() before getting a BUG() (!). Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] brd: RAM block module is called 'brd'
On Tuesday 2012-08-21 17:10, Paul Bolle wrote: > >2) "modinfo rd" doesn't work. Apparently one needs to feed modinfo the >actual module name and not an alias. Is that by design? I would say so, because you can call modprobe --resolve-alias rd to figure out the actual module to any given string. If this modprobe call returns nothing, you know you found the terminal name. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] configfs: move the dereference below the NULL test
From: Wei Yongjun
The dereference should be moved below the NULL test.
spatch with a semantic match is used to found this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
fs/configfs/dir.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 7414ae2..3f15991 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1037,10 +1037,11 @@ static int configfs_dump(struct configfs_dirent *sd,
int level)
static int configfs_depend_prep(struct dentry *origin,
struct config_item *target)
{
- struct configfs_dirent *child_sd, *sd = origin->d_fsdata;
+ struct configfs_dirent *child_sd, *sd;
int ret = 0;
- BUG_ON(!origin || !sd);
+ BUG_ON(!origin || !origin->d_fsdata);
+ sd = origin->d_fsdata;
if (sd->s_element == target) /* Boo-yah */
goto out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] memstick: move the dereference below the NULL test
From: Wei Yongjun
The dereference should be moved below the NULL test.
spatch with a semantic match is used to found this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
drivers/memstick/host/r592.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/memstick/host/r592.c b/drivers/memstick/host/r592.c
index 29b2172..a7c5b31 100644
--- a/drivers/memstick/host/r592.c
+++ b/drivers/memstick/host/r592.c
@@ -454,7 +454,7 @@ static int r592_transfer_fifo_pio(struct r592_device *dev)
/* Executes one TPC (data is read/written from small or large fifo) */
static void r592_execute_tpc(struct r592_device *dev)
{
- bool is_write = dev->req->tpc >= MS_TPC_SET_RW_REG_ADRS;
+ bool is_write;
int len, error;
u32 status, reg;
@@ -463,6 +463,7 @@ static void r592_execute_tpc(struct r592_device *dev)
return;
}
+ is_write = dev->req->tpc >= MS_TPC_SET_RW_REG_ADRS;
len = dev->req->long_data ?
dev->req->sg.length : dev->req->data_len;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwspinlock/core: move the dereference below the NULL test
From: Wei Yongjun
The dereference should be moved below the NULL test.
spatch with a semantic match is used to found this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
drivers/hwspinlock/hwspinlock_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 1201a15..db713c0 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -552,7 +552,7 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
*/
int hwspin_lock_free(struct hwspinlock *hwlock)
{
- struct device *dev = hwlock->bank->dev;
+ struct device *dev;
struct hwspinlock *tmp;
int ret;
@@ -561,6 +561,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
return -EINVAL;
}
+ dev = hwlock->bank->dev;
mutex_lock(&hwspinlock_tree_lock);
/* make sure the hwspinlock is used */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: davinci: dm644x: move the dereference below the NULL test
From: Wei Yongjun
The dereference should be moved below the NULL test.
spatch with a semantic match is used to found this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
arch/arm/mach-davinci/board-dm644x-evm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d34ed55..b54dc03 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -518,13 +518,11 @@ static int dm6444evm_msp430_get_pins(void)
char buf[4];
struct i2c_msg msg[2] = {
{
- .addr = dm6446evm_msp->addr,
.flags = 0,
.len = 2,
.buf = (void __force *)txbuf,
},
{
- .addr = dm6446evm_msp->addr,
.flags = I2C_M_RD,
.len = 4,
.buf = buf,
@@ -535,6 +533,9 @@ static int dm6444evm_msp430_get_pins(void)
if (!dm6446evm_msp)
return -ENXIO;
+ msg[0].addr = dm6446evm_msp->addr;
+ msg[1].addr = dm6446evm_msp->addr;
+
/* Command 4 == get input state, returns port 2 and port3 data
* S Addr W [A] len=2 [A] cmd=4 [A]
* RS Addr R [A] [len=4] A [cmd=4] A [port2] A [port3] N P
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] kernel/resource.c: fix stack overflow in __reserve_region_with_split
On Fri, Sep 07, 2012 at 04:08:19PM -0600, T Makphaibulchoke wrote:
> Using recurvise call to try adding a non-conflicting region in the function
> __reserve_region_with_split() could result in a stack overflow in the case
> that the recursive calls are too deep. Convert the recursive calls to
> an iterative loop to avoid the problem.
>
> Tested on a machine containing 135 regions. The kernel no longer panicked
> with stack overflow.
>
> Also tested with code arbitrarily adding regions with no conflict, embedding
> two consecutive conflicts and embedding two non-consecutive conflicts.
>
> Signed-off-by: T Makphaibulchoke
>
> ---
> Change since v2:
> * Initializing both the name and flags fileds of the newly allocated region
> request.
>
> Change since v1:
> * Fixing __resrve_region_with_split() to ensure a reqion reserve request is
> satisfied to the fullest extent, minus any overlapping conflicting regions.
> ---
> kernel/resource.c | 50 ++
> 1 files changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 34d4588..73f35d4 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -763,6 +763,7 @@ static void __init __reserve_region_with_split(struct
> resource *root,
> struct resource *parent = root;
> struct resource *conflict;
> struct resource *res = kzalloc(sizeof(*res), GFP_ATOMIC);
> + struct resource *next_res = NULL;
>
> if (!res)
> return;
> @@ -772,21 +773,46 @@ static void __init __reserve_region_with_split(struct
> resource *root,
> res->end = end;
> res->flags = IORESOURCE_BUSY;
>
> - conflict = __request_resource(parent, res);
> - if (!conflict)
> - return;
> + while (1) {
>
> - /* failed, split and try again */
> - kfree(res);
> + conflict = __request_resource(parent, res);
> + if (!conflict) {
> + if (!next_res)
> + break;
> + res = next_res;
> + next_res = NULL;
> + continue;
> + }
>
> - /* conflict covered whole area */
> - if (conflict->start <= start && conflict->end >= end)
> - return;
> + /* conflict covered whole area */
> + if (conflict->start <= res->start &&
> + conflict->end >= res->end) {
> + kfree(res);
> + WARN_ON(next_res);
> + break;
> + }
> +
> + /* failed, split and try again */
> + if (conflict->start > res->start) {
> + end = res->end;
> + res->end = conflict->start - 1;
> + if (conflict->end < end) {
> + next_res = kzalloc(sizeof(*next_res),
> + GFP_ATOMIC);
> + if (!next_res) {
> + kfree(res);
> + break;
> + }
> + next_res->name = name;
> + next_res->start = conflict->end + 1;
> + next_res->end = end;
> + next_res->flags = IORESOURCE_BUSY;
> + }
> + } else {
> + res->start = conflict->end + 1;
> + }
> + }
>
> - if (conflict->start > start)
> - __reserve_region_with_split(root, start, conflict->start-1,
> name);
> - if (conflict->end < end)
> - __reserve_region_with_split(root, conflict->end+1, end, name);
> }
>
> void __init reserve_region_with_split(struct resource *root,
Reviewed-by: Ram Pai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] irqdomain: move the dereference below the NULL test
From: Wei Yongjun
The dereference should be moved below the NULL test.
spatch with a semantic match is used to found this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
kernel/irq/irqdomain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 49a7772..3e5d3fc 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -374,11 +374,12 @@ static void irq_domain_disassociate_many(struct
irq_domain *domain,
while (count--) {
int irq = irq_base + count;
struct irq_data *irq_data = irq_get_irq_data(irq);
- irq_hw_number_t hwirq = irq_data->hwirq;
+ irq_hw_number_t hwirq;
if (WARN_ON(!irq_data || irq_data->domain != domain))
continue;
+ hwirq = irq_data->hwirq;
irq_set_status_flags(irq, IRQ_NOREQUEST);
/* remove chip and handler */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ocfs2: move the dereference below the NULL test
From: Wei Yongjun
The dereference should be moved below the NULL test.
spatch with a semantic match is used to found this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
fs/ocfs2/move_extents.c | 3 ++-
fs/ocfs2/journal.c | 3 ++-
fs/ocfs2/dlmglue.c | 15 ++-
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/fs/ocfs2/move_extents.c b/fs/ocfs2/move_extents.c
index 6083432..c7631ee 100644
--- a/fs/ocfs2/move_extents.c
+++ b/fs/ocfs2/move_extents.c
@@ -975,11 +975,12 @@ static int ocfs2_move_extents(struct
ocfs2_move_extents_context *context)
struct inode *inode = context->inode;
struct ocfs2_dinode *di;
struct buffer_head *di_bh = NULL;
- struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
+ struct ocfs2_super *osb;
if (!inode)
return -ENOENT;
+ osb = OCFS2_SB(inode->i_sb);
if (ocfs2_is_hard_readonly(osb) || ocfs2_is_soft_readonly(osb))
return -EROFS;
diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c
index 2dd36af..a0c2e8a 100644
--- a/fs/ocfs2/journal.c
+++ b/fs/ocfs2/journal.c
@@ -340,11 +340,12 @@ finally:
handle_t *ocfs2_start_trans(struct ocfs2_super *osb, int max_buffs)
{
- journal_t *journal = osb->journal->j_journal;
+ journal_t *journal;
handle_t *handle;
BUG_ON(!osb || !osb->journal->j_journal);
+ journal = osb->journal->j_journal;
if (ocfs2_is_hard_readonly(osb))
return ERR_PTR(-EROFS);
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 4f7795f..65fc2f6 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -1596,7 +1596,7 @@ static int ocfs2_create_new_lock(struct ocfs2_super *osb,
int ocfs2_create_new_inode_locks(struct inode *inode)
{
int ret;
- struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
+ struct ocfs2_super *osb;
BUG_ON(!inode);
BUG_ON(!ocfs2_inode_is_new(inode));
@@ -1611,6 +1611,7 @@ int ocfs2_create_new_inode_locks(struct inode *inode)
* on a resource which has an invalid one -- we'll set it
* valid when we release the EX. */
+ osb = OCFS2_SB(inode->i_sb);
ret = ocfs2_create_new_lock(osb, &OCFS2_I(inode)->ip_rw_lockres, 1, 1);
if (ret) {
mlog_errno(ret);
@@ -1641,7 +1642,7 @@ int ocfs2_rw_lock(struct inode *inode, int write)
{
int status, level;
struct ocfs2_lock_res *lockres;
- struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
+ struct ocfs2_super *osb;
BUG_ON(!inode);
@@ -1649,6 +1650,7 @@ int ocfs2_rw_lock(struct inode *inode, int write)
(unsigned long long)OCFS2_I(inode)->ip_blkno,
write ? "EXMODE" : "PRMODE");
+ osb = OCFS2_SB(inode->i_sb);
if (ocfs2_mount_local(osb))
return 0;
@@ -1685,13 +1687,14 @@ int ocfs2_open_lock(struct inode *inode)
{
int status = 0;
struct ocfs2_lock_res *lockres;
- struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
+ struct ocfs2_super *osb;
BUG_ON(!inode);
mlog(0, "inode %llu take PRMODE open lock\n",
(unsigned long long)OCFS2_I(inode)->ip_blkno);
+ osb = OCFS2_SB(inode->i_sb);
if (ocfs2_is_hard_readonly(osb) || ocfs2_mount_local(osb))
goto out;
@@ -1710,7 +1713,7 @@ int ocfs2_try_open_lock(struct inode *inode, int write)
{
int status = 0, level;
struct ocfs2_lock_res *lockres;
- struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
+ struct ocfs2_super *osb;
BUG_ON(!inode);
@@ -1718,6 +1721,7 @@ int ocfs2_try_open_lock(struct inode *inode, int write)
(unsigned long long)OCFS2_I(inode)->ip_blkno,
write ? "EXMODE" : "PRMODE");
+ osb = OCFS2_SB(inode->i_sb);
if (ocfs2_is_hard_readonly(osb)) {
if (write)
status = -EROFS;
@@ -2288,7 +2292,7 @@ int ocfs2_inode_lock_full_nested(struct inode *inode,
int status, level, acquired;
u32 dlm_flags;
struct ocfs2_lock_res *lockres = NULL;
- struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
+ struct ocfs2_super *osb;
struct buffer_head *local_bh = NULL;
BUG_ON(!inode);
@@ -2299,6 +2303,7 @@ int ocfs2_inode_lock_full_nested(struct inode *inode,
status = 0;
acquired = 0;
+ osb = OCFS2_SB(inode->i_sb);
/* We'll allow faking a readonly metadata lock for
* rodevices. */
if (ocfs2_is_hard_readonly(osb)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/14] ARM: VIC: Add a couple of low-level FIQ management helpers
Just a couple of calls to manage VIC FIQ routing. We'll use them for
KGDB FIQ support on ARM Versatile machines.
Signed-off-by: Anton Vorontsov
---
arch/arm/common/vic.c | 28
arch/arm/include/asm/hardware/vic.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c
index e0d5388..df2fc82 100644
--- a/arch/arm/common/vic.c
+++ b/arch/arm/common/vic.c
@@ -66,6 +66,34 @@ static struct vic_device vic_devices[CONFIG_ARM_VIC_NR];
static int vic_id;
+static void __iomem *vic_base(struct irq_data *d)
+{
+ return (void __iomem *)irq_data_get_irq_chip_data(d);
+}
+
+void vic_fiq_select(unsigned int irq, bool on)
+{
+ void __iomem *base = vic_base(&irq_to_desc(irq)->irq_data);
+ void __iomem *sel = base + VIC_INT_SELECT;
+ u32 msk = 1 << irq;
+ u32 val;
+
+ pr_debug("rerouting VIC vector %d to %s\n", irq, on ? "FIQ" : "IRQ");
+
+ val = readl(sel);
+ val &= ~msk;
+ if (on)
+ val |= msk;
+ writel(val, sel);
+}
+
+bool vic_is_fiq_rised(unsigned int irq)
+{
+ void __iomem *base = vic_base(&irq_to_desc(irq)->irq_data);
+
+ return readl(base + VIC_FIQ_STATUS) & (1 << irq);
+}
+
/**
* vic_init2 - common initialisation code
* @base: Base of the VIC.
diff --git a/arch/arm/include/asm/hardware/vic.h
b/arch/arm/include/asm/hardware/vic.h
index e14af1a..2728975 100644
--- a/arch/arm/include/asm/hardware/vic.h
+++ b/arch/arm/include/asm/hardware/vic.h
@@ -52,6 +52,8 @@ void __vic_init(void __iomem *base, unsigned int irq_start,
u32 vic_sources,
void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources, u32
resume_sources);
int vic_of_init(struct device_node *node, struct device_node *parent);
void vic_handle_irq(struct pt_regs *regs);
+void vic_fiq_select(unsigned int irq, bool on);
+bool vic_is_fiq_rised(unsigned int irq);
#endif /* __ASSEMBLY__ */
#endif
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/14] ARM: versatile: Make able to use UART ports for KGDB FIQ debugger
If enabled, kernel will able to enter KGDB upon serial line activity on
UART ports.
Note that even with this patch and CONFIG_KGDB_FIQ is enabled, you still
need to pass kgdb_fiq.enable=1 kernel command line option, otherwise UART
will behave in a normal way.
By default UART0 is used, but this can be changed via kgdb_fiq.uart_num
kernel command line option.
Signed-off-by: Anton Vorontsov
---
arch/arm/Kconfig | 1 +
arch/arm/mach-versatile/Makefile | 1 +
arch/arm/mach-versatile/kgdb_fiq.c | 31 +++
3 files changed, 33 insertions(+)
create mode 100644 arch/arm/mach-versatile/kgdb_fiq.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 66f4f81..5972886 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -336,6 +336,7 @@ config ARCH_VERSATILE
select PLAT_VERSATILE_CLCD
select PLAT_VERSATILE_FPGA_IRQ
select ARM_TIMER_SP804
+ select ARCH_MIGHT_HAVE_KGDB_FIQ
help
This enables support for ARM Ltd Versatile board.
diff --git a/arch/arm/mach-versatile/Makefile b/arch/arm/mach-versatile/Makefile
index 81fa3fe..bfd761f 100644
--- a/arch/arm/mach-versatile/Makefile
+++ b/arch/arm/mach-versatile/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_ARCH_VERSATILE_PB) += versatile_pb.o
obj-$(CONFIG_MACH_VERSATILE_AB)+= versatile_ab.o
obj-$(CONFIG_MACH_VERSATILE_DT)+= versatile_dt.o
obj-$(CONFIG_PCI) += pci.o
+obj-$(CONFIG_KGDB_FIQ) += kgdb_fiq.o
diff --git a/arch/arm/mach-versatile/kgdb_fiq.c
b/arch/arm/mach-versatile/kgdb_fiq.c
new file mode 100644
index 000..3cdf71d
--- /dev/null
+++ b/arch/arm/mach-versatile/kgdb_fiq.c
@@ -0,0 +1,31 @@
+/*
+ * KGDB FIQ board support
+ *
+ * Copyright 2012 Linaro Ltd.
+ * Anton Vorontsov
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int kgdb_fiq;
+module_param_named(uart_num, kgdb_fiq, int, 0600);
+MODULE_PARM_DESC(uart_num, "UART port to use for KGDB FIQ");
+
+static int __init kgdb_fiq_init(void)
+{
+ WARN_ON(kgdb_fiq > INT_UARTINT2 - INT_UARTINT0);
+
+ return kgdb_register_fiq(INT_UARTINT0 + kgdb_fiq,
+vic_fiq_select,
+vic_is_fiq_rised);
+}
+console_initcall(kgdb_fiq_init);
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/14] ARM: Add KGDB/KDB FIQ debugger generic code
The FIQ debugger may be used to debug situations when the kernel stuck
in uninterruptable sections, e.g. the kernel infinitely loops or
deadlocked in an interrupt or with interrupts disabled.
By default KGDB FIQ is disabled in runtime, but can be enabled with
kgdb_fiq.enable=1 kernel command line option.
Signed-off-by: Anton Vorontsov
---
arch/arm/Kconfig | 18
arch/arm/include/asm/kgdb.h | 8
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/kgdb_fiq.c | 99
arch/arm/kernel/kgdb_fiq_entry.S | 87 +++
5 files changed, 213 insertions(+)
create mode 100644 arch/arm/kernel/kgdb_fiq.c
create mode 100644 arch/arm/kernel/kgdb_fiq_entry.S
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c5f9ae5..66f4f81 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -171,6 +171,24 @@ config GENERIC_ISA_DMA
config FIQ
bool
+config ARCH_MIGHT_HAVE_KGDB_FIQ
+ bool
+
+config KGDB_FIQ
+ bool "KGDB/KDB FIQ debugger"
+ depends on KGDB_KDB && ARCH_MIGHT_HAVE_KGDB_FIQ && !THUMB2_KERNEL
+ select FIQ
+ help
+ The FIQ debugger may be used to debug situations when the
+ kernel stuck in uninterruptable sections, e.g. the kernel
+ infinitely loops or deadlocked in an interrupt or with
+ interrupts disabled.
+
+ By default KGDB FIQ is disabled in runtime, but can be
+ enabled with kgdb_fiq.enable=1 kernel command line option.
+
+ If unsure, say N.
+
config NEED_RET_TO_USER
bool
diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
index 48066ce..807e547 100644
--- a/arch/arm/include/asm/kgdb.h
+++ b/arch/arm/include/asm/kgdb.h
@@ -11,6 +11,8 @@
#define __ARM_KGDB_H__
#include
+#include
+#include
/*
* GDB assumes that we're a user process being debugged, so
@@ -47,6 +49,12 @@ static inline void arch_kgdb_breakpoint(void)
extern void kgdb_handle_bus_error(void);
extern int kgdb_fault_expected;
+extern char kgdb_fiq_handler;
+extern char kgdb_fiq_handler_end;
+asmlinkage void __exception_irq_entry kgdb_fiq_do_handle(struct pt_regs *regs);
+extern int __init kgdb_register_fiq(unsigned int mach_kgdb_fiq,
+void (*mach_kgdb_enable_fiq)(unsigned int irq, bool on),
+bool (*mach_is_kgdb_fiq)(unsigned int irq));
#endif /* !__ASSEMBLY__ */
/*
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 7ad2d5c..5aa079b 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_ATAGS_PROC) += atags.o
obj-$(CONFIG_OABI_COMPAT) += sys_oabi-compat.o
obj-$(CONFIG_ARM_THUMBEE) += thumbee.o
obj-$(CONFIG_KGDB) += kgdb.o
+obj-$(CONFIG_KGDB_FIQ) += kgdb_fiq_entry.o kgdb_fiq.o
obj-$(CONFIG_ARM_UNWIND) += unwind.o
obj-$(CONFIG_HAVE_TCM) += tcm.o
obj-$(CONFIG_OF) += devtree.o
diff --git a/arch/arm/kernel/kgdb_fiq.c b/arch/arm/kernel/kgdb_fiq.c
new file mode 100644
index 000..8443af1
--- /dev/null
+++ b/arch/arm/kernel/kgdb_fiq.c
@@ -0,0 +1,99 @@
+/*
+ * KGDB FIQ
+ *
+ * Copyright 2010 Google, Inc.
+ * Arve Hjønnevåg
+ * Colin Cross
+ * Copyright 2012 Linaro Ltd.
+ * Anton Vorontsov
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int kgdb_fiq_enabled;
+module_param_named(enable, kgdb_fiq_enabled, int, 0600);
+MODULE_PARM_DESC(enable, "set to 1 to enable FIQ KGDB");
+
+static unsigned int kgdb_fiq;
+static bool (*is_kgdb_fiq)(unsigned int irq);
+
+asmlinkage void __exception_irq_entry kgdb_fiq_do_handle(struct pt_regs *regs)
+{
+ if (!is_kgdb_fiq(kgdb_fiq))
+ return;
+ if (!kgdb_nmi_poll_knock())
+ return;
+
+ nmi_enter();
+ kgdb_handle_exception(1, 0, 0, regs);
+ nmi_exit();
+}
+
+static struct fiq_handler kgdb_fiq_desc = {
+ .name = "kgdb",
+};
+
+static long kgdb_fiq_setup_stack(void *info)
+{
+ struct pt_regs regs;
+
+ regs.ARM_sp = __get_free_pages(GFP_KERNEL, THREAD_SIZE_ORDER) +
+ THREAD_START_SP;
+ WARN_ON(!regs.ARM_sp);
+
+ set_fiq_regs(®s);
+ return 0;
+}
+
+static void (*kgdb_enable_fiq)(unsigned int irq, bool on);
+
+void kgdb_arch_enable_nmi(bool on)
+{
+ if (!kgdb_enable_fiq)
+ return;
+ kgdb_enable_fiq(kgdb_fiq, on);
+}
+
+int __init kgdb_register_fiq(unsigned int mach_kgdb_fiq,
+ void (*mach_kgdb_enable_fiq)(unsigned int irq, bool on),
+ bool (*mach_is_kgdb_fiq)(unsigned int irq))
+{
+ int err;
+ int cpu;
+
+ if (!k
[PATCH 11/14] ARM: Move some macros from entry-armv to entry-header
Just move the macros into header file as we would want to use them for
KGDB FIQ entry code.
The following macros were moved:
- svc_entry
- usr_entry
- kuser_cmpxchg_check
- vector_stub
To make kuser_cmpxchg_check actually work across different files, we
also have to make kuser_cmpxchg64_fixup global.
Signed-off-by: Anton Vorontsov
---
arch/arm/kernel/entry-armv.S | 167 +---
arch/arm/kernel/entry-header.S | 170 +
2 files changed, 171 insertions(+), 166 deletions(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 0f82098..0f15368 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -136,57 +136,6 @@ common_invalid:
b bad_mode
ENDPROC(__und_invalid)
-/*
- * SVC mode handlers
- */
-
-#if defined(CONFIG_AEABI) && (__LINUX_ARM_ARCH__ >= 5)
-#define SPFIX(code...) code
-#else
-#define SPFIX(code...)
-#endif
-
- .macro svc_entry, stack_hole=0
- UNWIND(.fnstart )
- UNWIND(.save {r0 - pc})
- sub sp, sp, #(S_FRAME_SIZE + \stack_hole - 4)
-#ifdef CONFIG_THUMB2_KERNEL
- SPFIX(str r0, [sp]) @ temporarily saved
- SPFIX(mov r0, sp )
- SPFIX(tst r0, #4 ) @ test original stack alignment
- SPFIX(ldr r0, [sp]) @ restored
-#else
- SPFIX(tst sp, #4 )
-#endif
- SPFIX(subeq sp, sp, #4 )
- stmia sp, {r1 - r12}
-
- ldmia r0, {r3 - r5}
- add r7, sp, #S_SP - 4 @ here for interlock avoidance
- mov r6, #-1 @ "" "" "" ""
- add r2, sp, #(S_FRAME_SIZE + \stack_hole - 4)
- SPFIX(addeq r2, r2, #4 )
- str r3, [sp, #-4]! @ save the "real" r0 copied
- @ from the exception stack
-
- mov r3, lr
-
- @
- @ We are now ready to fill in the remaining blanks on the stack:
- @
- @ r2 - sp_svc
- @ r3 - lr_svc
- @ r4 - lr_, already fixed up for correct return/restart
- @ r5 - spsr_
- @ r6 - orig_r0 (see pt_regs definition in ptrace.h)
- @
- stmia r7, {r2 - r6}
-
-#ifdef CONFIG_TRACE_IRQFLAGS
- bl trace_hardirqs_off
-#endif
- .endm
-
.align 5
__dabt_svc:
svc_entry
@@ -348,71 +297,8 @@ ENDPROC(__pabt_svc)
/*
* User mode handlers
- *
- * EABI note: sp_svc is always 64-bit aligned here, so should S_FRAME_SIZE
*/
-#if defined(CONFIG_AEABI) && (__LINUX_ARM_ARCH__ >= 5) && (S_FRAME_SIZE & 7)
-#error "sizeof(struct pt_regs) must be a multiple of 8"
-#endif
-
- .macro usr_entry
- UNWIND(.fnstart )
- UNWIND(.cantunwind) @ don't unwind the user space
- sub sp, sp, #S_FRAME_SIZE
- ARM( stmib sp, {r1 - r12} )
- THUMB(stmia sp, {r0 - r12} )
-
- ldmia r0, {r3 - r5}
- add r0, sp, #S_PC @ here for interlock avoidance
- mov r6, #-1 @ "" "" """"
-
- str r3, [sp]@ save the "real" r0 copied
- @ from the exception stack
-
- @
- @ We are now ready to fill in the remaining blanks on the stack:
- @
- @ r4 - lr_, already fixed up for correct return/restart
- @ r5 - spsr_
- @ r6 - orig_r0 (see pt_regs definition in ptrace.h)
- @
- @ Also, separately save sp_usr and lr_usr
- @
- stmia r0, {r4 - r6}
- ARM( stmdb r0, {sp, lr}^ )
- THUMB(store_user_sp_lr r0, r1, S_SP - S_PC)
-
- @
- @ Enable the alignment trap while in kernel mode
- @
- alignment_trap r0
-
- @
- @ Clear FP to mark the first stack frame
- @
- zero_fp
-
-#ifdef CONFIG_IRQSOFF_TRACER
- bl trace_hardirqs_off
-#endif
- .endm
-
- .macro kuser_cmpxchg_check
-#if !defined(CONFIG_CPU_32v6K) && !defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
-#ifndef CONFIG_MMU
-#warning "NPTL on non MMU needs fixing"
-#else
- @ Make sure our user space atomic helper is restarted
- @ if it was interrupted in a critical region. Here we
- @ perform a quick test inline since it should be false
- @ 99.% of the time. The rest is done out of line.
- cmp r4, #TASK_SIZE
- blhskuser_cmpxchg64_fixup
-#endif
-#endif
- .endm
-
.align 5
__dabt_usr:
usr_entry
@@ -846,6 +732,7 @@ __kuser_cmpxchg64: @ 0x0f60
ldmfd sp!, {r4, r5, r6, pc}
.text
+ .global kuser_cmpxchg64_fixup
kuser_cmpxchg64_fixup:
@ Called from kuser_cmpxchg_fixup.
@ r4 = address of interrupted insn (must be preserved).
@@ -976,58 +863,6 @@ __kuser_helper_end:
THUMB(.thumb )
-/*
- * Vecto
[PATCH 10/14] tty/serial: Add kgdb_nmi driver
This special driver makes it possible to temporary use NMI debugger port as a normal console by issuing 'nmi_console' command (assuming that the port is attached to KGDB). Unlike KDB's disable_nmi command, with this driver you are always able to go back to the debugger using KGDB escape sequence ($3#33). This is because this console driver processes the input in NMI context, and thus is able to intercept the magic sequence. Note that since the console interprets input and uses polling communication methods, for things like PPP it is still better to fully detach debugger port from the KGDB NMI (i.e. disable_nmi), and use raw console. Usually, to enter the debugger one have to type the magic sequence, so initially the kernel will print the following prompt on the NMI debugger console: Type $3#33 to enter the debugger> For convenience, there is a kgdb_fiq.knock kernel command line option, when set to 0, this turns the special command to just a return key press, so the kernel will be printing this: Hit to enter the debugger> This is more convenient for long debugging sessions, although it makes nmi_console feature somewhat useless. And for the cases when NMI connected to a dedicated button, the knocking can be disabled altogether by setting kgdb_fiq.knock to -1. Suggested-by: Colin Cross Signed-off-by: Anton Vorontsov --- drivers/tty/serial/Kconfig| 19 +++ drivers/tty/serial/Makefile | 1 + drivers/tty/serial/kgdb_nmi.c | 352 ++ drivers/tty/serial/kgdboc.c | 6 + include/linux/kgdb.h | 10 ++ 5 files changed, 388 insertions(+) create mode 100644 drivers/tty/serial/kgdb_nmi.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 4720b4b..32d6d3f 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -141,6 +141,25 @@ config SERIAL_ATMEL_TTYAT Say Y if you have an external 8250/16C550 UART. If unsure, say N. +config SERIAL_KGDB_NMI + bool "Serial console over KGDB NMI debugger port" + depends on KGDB_SERIAL_CONSOLE + help + This special driver allows you to temporary use NMI debugger port + as a normal console (assuming that the port is attached to KGDB). + + Unlike KDB's disable_nmi command, with this driver you are always + able to go back to the debugger using KGDB escape sequence ($3#33). + This is because this console driver processes the input in NMI + context, and thus is able to intercept the magic sequence. + + Note that since the console interprets input and uses polling + communication methods, for things like PPP you still must fully + detach debugger port from the KGDB NMI (i.e. disable_nmi), and + use raw console. + + If unsure, say N. + config SERIAL_KS8695 bool "Micrel KS8695 (Centaur) serial port support" depends on ARCH_KS8695 diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index 7257c5d..7a61d52 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -59,6 +59,7 @@ obj-$(CONFIG_SERIAL_MSM_HS) += msm_serial_hs.o obj-$(CONFIG_SERIAL_NETX) += netx-serial.o obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o +obj-$(CONFIG_SERIAL_KGDB_NMI) += kgdb_nmi.o obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o diff --git a/drivers/tty/serial/kgdb_nmi.c b/drivers/tty/serial/kgdb_nmi.c new file mode 100644 index 000..697cf13 --- /dev/null +++ b/drivers/tty/serial/kgdb_nmi.c @@ -0,0 +1,352 @@ +/* + * KGDB NMI serial console + * + * Copyright 2010 Google, Inc. + * Arve Hjønnevåg + * Colin Cross + * Copyright 2012 Linaro Ltd. + * Anton Vorontsov + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int kgdb_nmi_knock = 1; +module_param_named(knock, kgdb_nmi_knock, int, 0600); +MODULE_PARM_DESC(knock, "if set to 1 (default), the special '$3#33' command " + "must be used to enter the debugger; when set to 0, " + "hitting return key is enough to enter the debugger; " + "when set to -1, the debugger is entered immediately " + "upon NMI"); + +static char *kgdb_nmi_magic = "$3#33"; +module_param_named(magic, kgdb_nmi_magic, charp, 0600); +MODULE_PARM_DESC(magic, "magic sequence to enter NMI debugger (default $3#33)"); + +static bool kgdb_nmi_tty_enabled; + +static void k
[PATCH 09/14] tty/serial/amba-pl011: Implement clear_irqs callback
It's all pretty straightforward, except for TXIM interrupt. The interrupt
has meaning "ready to transmit", so it's almost always raised, and the
only way to silence it is to mask it. But that's OK, ops->start_tx will
unmask it.
Signed-off-by: Anton Vorontsov
---
drivers/tty/serial/amba-pl011.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 88e2df2..7522d97 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1308,6 +1308,18 @@ static void pl011_put_poll_char(struct uart_port *port,
writew(ch, uap->port.membase + UART01x_DR);
}
+static void pl011_clear_irqs(struct uart_port *port)
+{
+ struct uart_amba_port *uap = (struct uart_amba_port *)port;
+ unsigned char __iomem *regs = uap->port.membase;
+
+ writew(readw(regs + UART011_MIS), regs + UART011_ICR);
+ /*
+* There is no way to clear TXIM, this is "ready to transmit IRQ", so
+* we simply mask it. ops->start_tx will unmask it.
+*/
+ writew(readw(regs + UART011_IMSC) & ~UART011_TXIM, regs + UART011_IMSC);
+}
#endif /* CONFIG_CONSOLE_POLL */
static int pl011_hwinit(struct uart_port *port)
@@ -1713,6 +1725,7 @@ static struct uart_ops amba_pl011_pops = {
.poll_init = pl011_hwinit,
.poll_get_char = pl011_get_poll_char,
.poll_put_char = pl011_put_poll_char,
+ .clear_irqs= pl011_clear_irqs,
#endif
};
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/14] tty/serial/kgdboc: Add and wire up clear_irqs callback
This patch implements a new callback: clear_irqs. It is used for the
cases when KDB-entry (e.g. NMI) and KDB IO (e.g. serial port) shares the
same interrupt. To get the idea, let's take some real example (ARM
machine): we have a serial port which interrupt is routed to an NMI, and
the interrupt is used to enter KDB. Once there is some activity on the
serial port, the CPU receives NMI exception, and we fall into KDB shell.
So, it is our "debug console", and it is able to interrupt (and thus
debug) even IRQ handlers themselves.
When used that way, the interrupt never reaches serial driver's IRQ
handler routine, which means that serial driver will not silence the
interrupt. NMIs behaviour are quite arch-specific, and we can't assume
that we can use them as ordinary IRQs, e.g. on some arches (like ARM) we
can't handle data aborts, the behaviour is undefined then. So we can't
just handle execution to serial driver's IRQ handler from the NMI
context once we're done with KDB (plus this would defeat the debugger's
purpose: we want the NMI handler be as simple as possible, so it will
have less chances to hang).
So, given that have to deal with it somehow, we have two options:
1. Implement something that clears the interrupt; 2. Implement a whole
new concept of grabbing tty for exclusive KDB use, plus implement
mask/unmask callbacks, i.e.:
- Since consoles might use ttys w/o opending them, we would have to
make kdb respect CON_ENABLED flag (maybe a good idea to do it
anyway);
- Add 'bool exclusive' argument to tty_find_polling_driver(), if set
to 1, the function will refuse to return an already opened tty; and
will use the flag in tty_reopen() to not allow multiple users
(there are already checks for pty masters, which are "open once"
ttys);
- Once we got the tty exclusively, we would need to call some new
uart->mask_all_but_rx_interrupts call before we want to use the
port for NMI/KDB, and unmask_all_but_rx_interrupts after we're done
with it.
The second option is obviously more complex, needlessly so, and less
generic. So I went with the first one: we just consume all the
interrupts. The tty becomes silently unusable for the rest of the world
when we use it with KDB; but once we reroute the serial IRQ source back
from NMI to an ordinary IRQ (in KDB this can be done with 'disable_nmi'
command), it will behave as normal.
p.s. Since the callback is so far used only by polling users, we place
it under the appropriate #ifdef.
Signed-off-by: Anton Vorontsov
---
drivers/tty/serial/kgdboc.c | 10 ++
drivers/tty/serial/serial_core.c | 15 +++
include/linux/kgdb.h | 1 +
include/linux/serial_core.h | 1 +
include/linux/tty_driver.h | 1 +
5 files changed, 28 insertions(+)
diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
index 2b42a01..0aa08c8 100644
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -227,6 +227,15 @@ static int kgdboc_get_char(void)
kgdb_tty_line);
}
+static void kgdboc_clear_irqs(void)
+{
+ if (!kgdb_tty_driver)
+ return;
+ if (kgdb_tty_driver->ops->clear_irqs)
+ kgdb_tty_driver->ops->clear_irqs(kgdb_tty_driver,
+kgdb_tty_line);
+}
+
static void kgdboc_put_char(u8 chr)
{
if (!kgdb_tty_driver)
@@ -298,6 +307,7 @@ static struct kgdb_io kgdboc_io_ops = {
.name = "kgdboc",
.read_char = kgdboc_get_char,
.write_char = kgdboc_put_char,
+ .clear_irqs = kgdboc_clear_irqs,
.pre_exception = kgdboc_pre_exp_handler,
.post_exception = kgdboc_post_exp_handler,
};
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index cba8443..908d108 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2169,6 +2169,20 @@ static void uart_poll_put_char(struct tty_driver
*driver, int line, char ch)
port = state->uart_port;
port->ops->poll_put_char(port, ch);
}
+
+static void uart_clear_irqs(struct tty_driver *driver, int line)
+{
+ struct uart_driver *drv = driver->driver_state;
+ struct uart_state *state = drv->state + line;
+ struct uart_port *port;
+
+ if (!state || !state->uart_port)
+ return;
+
+ port = state->uart_port;
+ if (port->ops->clear_irqs)
+ port->ops->clear_irqs(port);
+}
#endif
static const struct tty_operations uart_ops = {
@@ -2201,6 +2215,7 @@ static const struct tty_operations uart_ops = {
.poll_init = uart_poll_init,
.poll_get_char = uart_poll_get_char,
.poll_put_char = uart_poll_put_char,
+ .clear_irqs = uart_clear_irqs,
#endif
};
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index 3b111a6..1fd
[PATCH 07/14] tty/serial/amba-pl011: Implement poll_init callback
The callback is used to initialize the hardware, nothing else should be
done, i.e. we should not request interrupts (but we can and do unmask
some of them, as they might be useful for NMI entry).
As a side-effect, the patch also fixes a division by zero[1] when booting
with kgdboc options specified (e.g. kgdboc=ttyAMA0,115200n8). The issue
happens because serial core calls set_termios callback, but the driver
doesn't know clock frequency, and thus cannot calculate proper baud rate
values.
[1]
WARNING: at drivers/tty/serial/serial_core.c:400 uart_get_baud_rate+0xe8/0x14c()
Modules linked in:
[] (unwind_backtrace+0x0/0xf0) from []
(warn_slowpath_common+0x4c/0x64)
[] (warn_slowpath_common+0x4c/0x64) from []
(warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null+0x1c/0x24) from []
(uart_get_baud_rate+0xe8/0x14c)
[] (uart_get_baud_rate+0xe8/0x14c) from []
(pl011_set_termios+0x48/0x278)
[] (pl011_set_termios+0x48/0x278) from []
(uart_set_options+0xe8/0x114)
[] (uart_set_options+0xe8/0x114) from []
(uart_poll_init+0xd4/0xe0)
[] (uart_poll_init+0xd4/0xe0) from []
(tty_find_polling_driver+0x100/0x17c)
[] (tty_find_polling_driver+0x100/0x17c) from []
(configure_kgdboc+0xc8/0x1b8)
[] (configure_kgdboc+0xc8/0x1b8) from []
(do_one_initcall+0x30/0x168)
[] (do_one_initcall+0x30/0x168) from []
(do_basic_setup+0x94/0xc8)
[] (do_basic_setup+0x94/0xc8) from []
(kernel_init+0x60/0xf4)
[] (kernel_init+0x60/0xf4) from []
(kernel_thread_exit+0x0/0x8)
---[ end trace 7d41c9186f342c40 ]---
Division by zero in kernel.
[] (unwind_backtrace+0x0/0xf0) from [] (Ldiv0+0x8/0x10)
[] (Ldiv0+0x8/0x10) from [] (pl011_set_termios+0x68/0x278)
[] (pl011_set_termios+0x68/0x278) from []
(uart_set_options+0xe8/0x114)
[] (uart_set_options+0xe8/0x114) from []
(uart_poll_init+0xd4/0xe0)
[] (uart_poll_init+0xd4/0xe0) from []
(tty_find_polling_driver+0x100/0x17c)
[] (tty_find_polling_driver+0x100/0x17c) from []
(configure_kgdboc+0xc8/0x1b8)
[] (configure_kgdboc+0xc8/0x1b8) from []
(do_one_initcall+0x30/0x168)
[] (do_one_initcall+0x30/0x168) from []
(do_basic_setup+0x94/0xc8)
[] (do_basic_setup+0x94/0xc8) from []
(kernel_init+0x60/0xf4)
[] (kernel_init+0x60/0xf4) from []
(kernel_thread_exit+0x0/0x8)
Division by zero in kernel.
[] (unwind_backtrace+0x0/0xf0) from [] (Ldiv0+0x8/0x10)
[] (Ldiv0+0x8/0x10) from [] (uart_update_timeout+0x4c/0x5c)
[] (uart_update_timeout+0x4c/0x5c) from []
(pl011_set_termios+0xc8/0x278)
[] (pl011_set_termios+0xc8/0x278) from []
(uart_set_options+0xe8/0x114)
[] (uart_set_options+0xe8/0x114) from []
(uart_poll_init+0xd4/0xe0)
[] (uart_poll_init+0xd4/0xe0) from []
(tty_find_polling_driver+0x100/0x17c)
[] (tty_find_polling_driver+0x100/0x17c) from []
(configure_kgdboc+0xc8/0x1b8)
[] (configure_kgdboc+0xc8/0x1b8) from []
(do_one_initcall+0x30/0x168)
[] (do_one_initcall+0x30/0x168) from []
(do_basic_setup+0x94/0xc8)
[] (do_basic_setup+0x94/0xc8) from []
(kernel_init+0x60/0xf4)
[] (kernel_init+0x60/0xf4) from []
(kernel_thread_exit+0x0/0x8)
Signed-off-by: Anton Vorontsov
---
drivers/tty/serial/amba-pl011.c | 44 ++---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 3322023..88e2df2 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1310,10 +1310,9 @@ static void pl011_put_poll_char(struct uart_port *port,
#endif /* CONFIG_CONSOLE_POLL */
-static int pl011_startup(struct uart_port *port)
+static int pl011_hwinit(struct uart_port *port)
{
struct uart_amba_port *uap = (struct uart_amba_port *)port;
- unsigned int cr;
int retval;
/* Optionaly enable pins to be muxed in and configured */
@@ -1338,6 +1337,37 @@ static int pl011_startup(struct uart_port *port)
UART011_RTIS | UART011_RXIS, uap->port.membase + UART011_ICR);
/*
+* Save interrupts enable mask, and enable RX interrupts in case if
+* the interrupt is used for NMI entry.
+*/
+ uap->im = readw(uap->port.membase + UART011_IMSC);
+ writew(UART011_RTIM | UART011_RXIM, uap->port.membase + UART011_IMSC);
+
+ if (uap->port.dev->platform_data) {
+ struct amba_pl011_data *plat;
+
+ plat = uap->port.dev->platform_data;
+ if (plat->init)
+ plat->init();
+ }
+ return 0;
+ out:
+ return retval;
+}
+
+static int pl011_startup(struct uart_port *port)
+{
+ struct uart_amba_port *uap = (struct uart_amba_port *)port;
+ unsigned int cr;
+ int retval;
+
+ retval = pl011_hwinit(port);
+ if (retval)
+ goto clk_dis;
+
+ writew(uap->im, uap->port.membase + UART011_IMSC);
+
+ /*
* Allocate the IRQ
*/
retval = request_irq(uap->port.irq, pl011_int, 0, "uart-pl011", uap);
@@ -1396,19 +1426,10 @@ static int pl011_startup(struct uart_port *port)
writ
[PATCH 06/14] tty/serial/core: Introduce poll_init callback
It was noticed that polling drivers (like KGDB) are not able to use
serial ports if the ports were not previously initialized via console.
I.e. when booting with console=ttyAMA0 kgdboc=ttyAMA0, everything works
fine, but with console=ttyFOO kgdboc=ttyAMA0, the kgdboc doesn't work.
This is because we don't initialize the hardware. Calling ->startup() is
not an option, because drivers request interrupts there, and drivers
fail to handle situations when tty isn't opened with interrupts enabled.
So, we have to implement a new callback (actually, tty_ops already have
a similar callback), which does everything needed to initialize just the
hardware.
Signed-off-by: Anton Vorontsov
---
drivers/tty/serial/serial_core.c | 15 +++
include/linux/serial_core.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index a21dc8e..cba8443 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2108,11 +2108,13 @@ static int uart_poll_init(struct tty_driver *driver,
int line, char *options)
{
struct uart_driver *drv = driver->driver_state;
struct uart_state *state = drv->state + line;
+ struct tty_port *tport;
struct uart_port *port;
int baud = 9600;
int bits = 8;
int parity = 'n';
int flow = 'n';
+ int ret;
if (!state || !state->uart_port)
return -1;
@@ -2121,6 +2123,19 @@ static int uart_poll_init(struct tty_driver *driver, int
line, char *options)
if (!(port->ops->poll_get_char && port->ops->poll_put_char))
return -1;
+ tport = &state->port;
+ if (!(tport->flags & ASYNC_INITIALIZED) && port->ops->poll_init) {
+ mutex_lock(&tport->mutex);
+ ret = port->ops->poll_init(port);
+ /*
+* We don't set ASYNCB_INITIALIZED as we only initialized the
+* hw, e.g. state->xmit is still uninitialized.
+*/
+ mutex_unlock(&tport->mutex);
+ if (ret)
+ return ret;
+ }
+
if (options) {
uart_parse_options(options, &baud, &parity, &bits, &flow);
return uart_set_options(port, NULL, baud, parity, bits, flow);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 0253c20..3642710 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -274,6 +274,7 @@ struct uart_ops {
int (*verify_port)(struct uart_port *, struct serial_struct
*);
int (*ioctl)(struct uart_port *, unsigned int, unsigned
long);
#ifdef CONFIG_CONSOLE_POLL
+ int (*poll_init)(struct uart_port *);
void(*poll_put_char)(struct uart_port *, unsigned char);
int (*poll_get_char)(struct uart_port *);
#endif
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/14] kdb: Turn KGDB_KDB=n stubs into static inlines
This makes the stubs actually usable, since e.g. 'foo = kdb_register();'
leads to build errors in !KGDB_KDB case. Plus, with static inlines we
do type checking.
Signed-off-by: Anton Vorontsov
---
include/linux/kdb.h | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/include/linux/kdb.h b/include/linux/kdb.h
index 42d9e86..7f6fe6e 100644
--- a/include/linux/kdb.h
+++ b/include/linux/kdb.h
@@ -13,6 +13,14 @@
* Copyright (C) 2009 Jason Wessel
*/
+typedef enum {
+ KDB_REPEAT_NONE = 0,/* Do not repeat this command */
+ KDB_REPEAT_NO_ARGS, /* Repeat the command without arguments */
+ KDB_REPEAT_WITH_ARGS, /* Repeat the command including its arguments */
+} kdb_repeat_t;
+
+typedef int (*kdb_func_t)(int, const char **);
+
#ifdef CONFIG_KGDB_KDB
#include
#include
@@ -32,14 +40,6 @@ extern atomic_t kdb_event;
#define KDB_MAXARGS16 /* Maximum number of arguments to a function */
-typedef enum {
- KDB_REPEAT_NONE = 0,/* Do not repeat this command */
- KDB_REPEAT_NO_ARGS, /* Repeat the command without arguments */
- KDB_REPEAT_WITH_ARGS, /* Repeat the command including its arguments */
-} kdb_repeat_t;
-
-typedef int (*kdb_func_t)(int, const char **);
-
/* KDB return codes from a command or internal kdb function */
#define KDB_NOTFOUND (-1)
#define KDB_ARGCOUNT (-2)
@@ -149,11 +149,14 @@ extern int kdb_register_repeat(char *, kdb_func_t, char
*, char *,
short, kdb_repeat_t);
extern int kdb_unregister(char *);
#else /* ! CONFIG_KGDB_KDB */
-#define kdb_printf(...)
-#define kdb_init(x)
-#define kdb_register(...)
-#define kdb_register_repeat(...)
-#define kdb_uregister(x)
+static inline __printf(1, 2) int kdb_printf(const char *fmt, ...) { return 0; }
+static inline void kdb_init(int level) {}
+static inline int kdb_register(char *cmd, kdb_func_t func, char *usage,
+ char *help, short minlen) { return 0; }
+static inline int kdb_register_repeat(char *cmd, kdb_func_t func, char *usage,
+ char *help, short minlen,
+ kdb_repeat_t repeat) { return 0; }
+static inline int kdb_unregister(char *cmd) { return 0; }
#endif /* CONFIG_KGDB_KDB */
enum {
KDB_NOT_INITIALIZED,
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/14] kdb: Implement disable_nmi command
This command disables NMI-entry. If NMI source has been previously shared
with a serial console ("debug port"), this effectively releases the port
from KDB exclusive use, and makes the console available for normal use.
Of course, NMI can be reenabled, enable_nmi modparam is used for that:
echo 1 > /sys/module/kdb/parameters/enable_nmi
Signed-off-by: Anton Vorontsov
---
kernel/debug/kdb/kdb_main.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 31df170..9fadff1 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2107,6 +2108,32 @@ static int kdb_dmesg(int argc, const char **argv)
return 0;
}
#endif /* CONFIG_PRINTK */
+
+/* Make sure we balance enable/disable calls, must disable first. */
+static atomic_t kdb_nmi_disabled;
+
+static int kdb_disable_nmi(int argc, const char *argv[])
+{
+ if (atomic_read(&kdb_nmi_disabled))
+ return 0;
+ atomic_set(&kdb_nmi_disabled, 1);
+ kgdb_enable_nmi(0);
+ return 0;
+}
+
+static int kdb_param_enable_nmi(const char *val, const struct kernel_param *kp)
+{
+ if (!atomic_add_unless(&kdb_nmi_disabled, -1, 0))
+ return -EINVAL;
+ kgdb_enable_nmi(1);
+ return 0;
+}
+
+static const struct kernel_param_ops kdb_param_ops_enable_nmi = {
+ .set = kdb_param_enable_nmi,
+};
+module_param_cb(enable_nmi, &kdb_param_ops_enable_nmi, NULL, 0600);
+
/*
* kdb_cpu - This function implements the 'cpu' command.
* cpu []
@@ -2851,6 +2878,8 @@ static void __init kdb_inittab(void)
kdb_register_repeat("dmesg", kdb_dmesg, "[lines]",
"Display syslog buffer", 0, KDB_REPEAT_NONE);
#endif
+ kdb_register_repeat("disable_nmi", kdb_disable_nmi, "",
+ "Disable NMI entry to KDB", 0, KDB_REPEAT_NONE);
kdb_register_repeat("defcmd", kdb_defcmd, "name \"usage\" \"help\"",
"Define a set of commands, down to endefcmd", 0, KDB_REPEAT_NONE);
kdb_register_repeat("kill", kdb_kill, "<-signal> ",
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/14] kernel/debug: Mask KGDB NMI upon entry
The new arch callback should manage NMIs that usually cause KGDB to
enter. That is, not all NMIs should be enabled/disabled, but only
those that issue kgdb_handle_exception().
We must mask it as serial-line interrupt can be used as an NMI, so
if the original KGDB-entry cause was say a breakpoint, then every
input to KDB console will cause KGDB to reenter, which we don't want.
Signed-off-by: Anton Vorontsov
---
include/linux/kgdb.h | 23 +++
kernel/debug/debug_core.c | 36 +---
2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index c4d2fc1..3b111a6 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -221,6 +221,29 @@ extern int kgdb_arch_remove_breakpoint(struct kgdb_bkpt
*bpt);
*/
extern void kgdb_arch_late(void);
+/**
+ * kgdb_arch_enable_nmi - Enable or disable KGDB-entry NMI
+ * @on: Flag to either enable or disable an NMI
+ *
+ * This is an architecture-specific "back-end" for kgdb_enable_nmi(). The
+ * call does not count disable/enable requests, do not use it directly.
+ */
+extern void kgdb_arch_enable_nmi(bool on);
+
+/**
+ * kgdb_enable_nmi - Enable or disable KGDB-entry NMI
+ * @on: Flag to either enable or disable an NMI
+ *
+ * This function manages NMIs that usually cause KGDB to enter. That is,
+ * not all NMIs should be enabled or disabled, but only those that issue
+ * kgdb_handle_exception().
+ *
+ * The call counts disable requests, and thus allows to nest disables.
+ * But trying to enable already enabled NMI is an error. The call returns
+ * 1 if NMI has been actually enabled after the call, and a value <= 0 if
+ * it is still disabled.
+ */
+extern int kgdb_enable_nmi(bool on);
/**
* struct kgdb_arch - Describe architecture specific values.
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 0557f24..b621d1e 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -214,6 +214,30 @@ int __weak kgdb_skipexception(int exception, struct
pt_regs *regs)
return 0;
}
+void __weak kgdb_arch_enable_nmi(bool on)
+{
+}
+
+int kgdb_enable_nmi(bool on)
+{
+ static atomic_t cnt;
+ int ret;
+
+ ret = atomic_add_return(on ? 1 : -1, &cnt);
+ if (ret > 1 && on) {
+ /*
+* There should be only one instance that calls this function
+* in "enable, disable" order. All other users must call
+* disable first, then enable. If not, something is wrong.
+*/
+ WARN_ON(1);
+ return 1;
+ }
+
+ kgdb_arch_enable_nmi(ret > 0);
+ return ret;
+}
+
/*
* Some architectures need cache flushes when we set/clear a
* breakpoint:
@@ -672,6 +696,9 @@ kgdb_handle_exception(int evector, int signo, int ecode,
struct pt_regs *regs)
{
struct kgdb_state kgdb_var;
struct kgdb_state *ks = &kgdb_var;
+ int ret = 0;
+
+ kgdb_enable_nmi(0);
ks->cpu = raw_smp_processor_id();
ks->ex_vector = evector;
@@ -681,11 +708,14 @@ kgdb_handle_exception(int evector, int signo, int ecode,
struct pt_regs *regs)
ks->linux_regs = regs;
if (kgdb_reenter_check(ks))
- return 0; /* Ouch, double exception ! */
+ goto out; /* Ouch, double exception ! */
if (kgdb_info[ks->cpu].enter_kgdb != 0)
- return 0;
+ goto out;
- return kgdb_cpu_enter(ks, regs, DCPU_WANT_MASTER);
+ ret = kgdb_cpu_enter(ks, regs, DCPU_WANT_MASTER);
+out:
+ kgdb_enable_nmi(1);
+ return ret;
}
int kgdb_nmicallback(int cpu, void *regs)
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/14] drivers/tty/serial/amba-pl0{10,11}.c: use clk_prepare_enable and clk_disable_unprepare
From: Julia Lawall
Clk_prepare_enable and clk_disable_unprepare combine clk_prepare and
clk_enable, and clk_disable and clk_unprepare. The9 make the code more
concise, and ensure that clk_unprepare is called when clk_enable fails.
A simplified version of the semantic patch that introduces calls to these
functions is as follows: (http://coccinelle.lip6.fr/)
//
@@
expression e;
@@
- clk_prepare(e);
- clk_enable(e);
+ clk_prepare_enable(e);
@@
expression e;
@@
- clk_disable(e);
- clk_unprepare(e);
+ clk_disable_unprepare(e);
//
Signed-off-by: Julia Lawall
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Anton Vorontsov
---
The patch was taken from the TTY tree.
If this patch rejects because 'already applied', this means that your
tree is probably based on TTY tree or -next (e.g. -mm). In which case
you don't need this patch, just drop it.
If your tree is based on Linus' tree, you need this patch to not bring
horrible conflicts into -next.
drivers/tty/serial/amba-pl010.c | 15 ---
drivers/tty/serial/amba-pl011.c | 15 ---
2 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/amba-pl010.c b/drivers/tty/serial/amba-pl010.c
index 0d91a54..22317dd 100644
--- a/drivers/tty/serial/amba-pl010.c
+++ b/drivers/tty/serial/amba-pl010.c
@@ -312,16 +312,12 @@ static int pl010_startup(struct uart_port *port)
struct uart_amba_port *uap = (struct uart_amba_port *)port;
int retval;
- retval = clk_prepare(uap->clk);
- if (retval)
- goto out;
-
/*
* Try to enable the clock producer.
*/
- retval = clk_enable(uap->clk);
+ retval = clk_prepare_enable(uap->clk);
if (retval)
- goto clk_unprep;
+ goto out;
uap->port.uartclk = clk_get_rate(uap->clk);
@@ -346,9 +342,7 @@ static int pl010_startup(struct uart_port *port)
return 0;
clk_dis:
- clk_disable(uap->clk);
- clk_unprep:
- clk_unprepare(uap->clk);
+ clk_disable_unprepare(uap->clk);
out:
return retval;
}
@@ -375,8 +369,7 @@ static void pl010_shutdown(struct uart_port *port)
/*
* Shut down the clock producer
*/
- clk_disable(uap->clk);
- clk_unprepare(uap->clk);
+ clk_disable_unprepare(uap->clk);
}
static void
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 92b1ac8..3322023 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1324,16 +1324,12 @@ static int pl011_startup(struct uart_port *port)
"could not set default pins\n");
}
- retval = clk_prepare(uap->clk);
- if (retval)
- goto out;
-
/*
* Try to enable the clock producer.
*/
- retval = clk_enable(uap->clk);
+ retval = clk_prepare_enable(uap->clk);
if (retval)
- goto clk_unprep;
+ goto out;
uap->port.uartclk = clk_get_rate(uap->clk);
@@ -1411,9 +1407,7 @@ static int pl011_startup(struct uart_port *port)
return 0;
clk_dis:
- clk_disable(uap->clk);
- clk_unprep:
- clk_unprepare(uap->clk);
+ clk_disable_unprepare(uap->clk);
out:
return retval;
}
@@ -1473,8 +1467,7 @@ static void pl011_shutdown(struct uart_port *port)
/*
* Shut down the clock producer
*/
- clk_disable(uap->clk);
- clk_unprepare(uap->clk);
+ clk_disable_unprepare(uap->clk);
/* Optionally let pins go into sleep states */
if (!IS_ERR(uap->pins_sleep)) {
retval = pinctrl_select_state(uap->pinctrl, uap->pins_sleep);
--
1.7.11.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/14] serial/amba-pl011: fix ages old copy-paste errors
From: Linus Walleij
The PL011 driver has a number of symbols referring to "pl01x"
(probably once shared with the pl010 driver) and some even named
"pl010" (probably a pure copy-paste artifact). Lets name all
local static functions with the prefix pl011_* for clarity.
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Anton Vorontsov
---
The patch was taken from the TTY tree.
If this patch rejects because 'already applied', this means that your
tree is probably based on TTY tree or -next (e.g. -mm). In which case
you don't need this patch, just drop it.
If your tree is based on Linus' tree, you need this patch to not bring
horrible conflicts into -next.
drivers/tty/serial/amba-pl011.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index d3553b5..92b1ac8 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1215,14 +1215,14 @@ static irqreturn_t pl011_int(int irq, void *dev_id)
return IRQ_RETVAL(handled);
}
-static unsigned int pl01x_tx_empty(struct uart_port *port)
+static unsigned int pl011_tx_empty(struct uart_port *port)
{
struct uart_amba_port *uap = (struct uart_amba_port *)port;
unsigned int status = readw(uap->port.membase + UART01x_FR);
return status & (UART01x_FR_BUSY|UART01x_FR_TXFF) ? 0 : TIOCSER_TEMT;
}
-static unsigned int pl01x_get_mctrl(struct uart_port *port)
+static unsigned int pl011_get_mctrl(struct uart_port *port)
{
struct uart_amba_port *uap = (struct uart_amba_port *)port;
unsigned int result = 0;
@@ -1285,7 +1285,7 @@ static void pl011_break_ctl(struct uart_port *port, int
break_state)
}
#ifdef CONFIG_CONSOLE_POLL
-static int pl010_get_poll_char(struct uart_port *port)
+static int pl011_get_poll_char(struct uart_port *port)
{
struct uart_amba_port *uap = (struct uart_amba_port *)port;
unsigned int status;
@@ -1297,7 +1297,7 @@ static int pl010_get_poll_char(struct uart_port *port)
return readw(uap->port.membase + UART01x_DR);
}
-static void pl010_put_poll_char(struct uart_port *port,
+static void pl011_put_poll_char(struct uart_port *port,
unsigned char ch)
{
struct uart_amba_port *uap = (struct uart_amba_port *)port;
@@ -1637,7 +1637,7 @@ static const char *pl011_type(struct uart_port *port)
/*
* Release the memory region(s) being used by 'port'
*/
-static void pl010_release_port(struct uart_port *port)
+static void pl011_release_port(struct uart_port *port)
{
release_mem_region(port->mapbase, SZ_4K);
}
@@ -1645,7 +1645,7 @@ static void pl010_release_port(struct uart_port *port)
/*
* Request the memory region(s) being used by 'port'
*/
-static int pl010_request_port(struct uart_port *port)
+static int pl011_request_port(struct uart_port *port)
{
return request_mem_region(port->mapbase, SZ_4K, "uart-pl011")
!= NULL ? 0 : -EBUSY;
@@ -1654,18 +1654,18 @@ static int pl010_request_port(struct uart_port *port)
/*
* Configure/autoconfigure the port.
*/
-static void pl010_config_port(struct uart_port *port, int flags)
+static void pl011_config_port(struct uart_port *port, int flags)
{
if (flags & UART_CONFIG_TYPE) {
port->type = PORT_AMBA;
- pl010_request_port(port);
+ pl011_request_port(port);
}
}
/*
* verify the new serial_struct (for TIOCSSERIAL).
*/
-static int pl010_verify_port(struct uart_port *port, struct serial_struct *ser)
+static int pl011_verify_port(struct uart_port *port, struct serial_struct *ser)
{
int ret = 0;
if (ser->type != PORT_UNKNOWN && ser->type != PORT_AMBA)
@@ -1678,9 +1678,9 @@ static int pl010_verify_port(struct uart_port *port,
struct serial_struct *ser)
}
static struct uart_ops amba_pl011_pops = {
- .tx_empty = pl01x_tx_empty,
+ .tx_empty = pl011_tx_empty,
.set_mctrl = pl011_set_mctrl,
- .get_mctrl = pl01x_get_mctrl,
+ .get_mctrl = pl011_get_mctrl,
.stop_tx= pl011_stop_tx,
.start_tx = pl011_start_tx,
.stop_rx= pl011_stop_rx,
@@ -1691,13 +1691,13 @@ static struct uart_ops amba_pl011_pops = {
.flush_buffer = pl011_dma_flush_buffer,
.set_termios= pl011_set_termios,
.type = pl011_type,
- .release_port = pl010_release_port,
- .request_port = pl010_request_port,
- .config_port= pl010_config_port,
- .verify_port= pl010_verify_port,
+ .release_port = pl011_release_port,
+ .request_port = pl011_request_port,
+ .config_port= pl011_config_port,
+ .verify_port= pl011_verify_port,
#ifdef CONFIG_CONSOLE_POLL
- .poll_get_char = pl010_get_poll_char,
- .poll_put_char = pl010_put_poll_char,
+
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Fri, 07 Sep 2012 14:37:16 -0700 Kevin Hilman
wrote:
> Hi Neil,
>
> NeilBrown writes:
>
> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> > wrote:
> >
> >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> >> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
> >> > wrote:
> >
> >> >> After thinking bit more on this, the problem seems to be coming
> >> >> mainly because the gpio device is runtime suspended bit early than
> >> >> it should be. Similar issue seen with i2c driver as well. The i2c issue
> >> >> was discussed with Rafael at LPC last week. The idea is to move
> >> >> the pm_runtime_enable/disable() calls entirely up to the
> >> >> _late/_early stage of device suspend/resume.
> >> >> Will update this thread once I have further update.
> >> >
> >> > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after
> >> > all
> >> > the _late callbacks have been called.
> >> > I, too, spoke to Rafael about this in San Diego. He seemed to agree
> >> > with me
> >> > that the interrupt needs to be masked in the ->suspend callback. any
> >> > later
> >> > is too late.
> >> >
> >> Thanks for information about your discussion. Will wait for the patch then.
> >>
> >> Regards
> >> santosh
> >
> > I already sent a patch - that is what started this thread :-)
> >
> > I include it below.
> > You said "The patch doesn't seems to be correct" but didn't expand on why.
> > Do you still think it is not correct? I wouldn't be surprised if there is
> > some case that it doesn't handle quite right, but it seems right to me.
> >
> > Thanks,
> > NeilBrown
> >
> >
> > From: NeilBrown
> > Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
> >
> > Current kernel will wake from suspend on an event on any active
> > GPIO even if enable_irq_wake() wasn't called.
> >
> > There are two reasons that the hardware wake-enable bit should be set:
> >
> > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> > in which the wake-enable bit is needed for an interrupt to be
> > recognised.
> > 2/ while suspended the GPIO interrupt should wake from suspend if and
> >only if irq_wake as been enabled.
> >
> > The code currently doesn't keep these two reasons separate so they get
> > confused and sometimes the wakeup flags is set incorrectly.
> >
> > This patch reverts:
> > commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> > gpio/omap: remove suspend/resume callbacks
> > and
> > commit 0aa2727399c0b78225021413022c164cb99fbc5e
> > gpio/omap: remove suspend_wakeup field from struct gpio_bank
> >
> > and makes some minor changes so that we have separate flags for "GPIO
> > should wake from deep idle" and "GPIO should wake from suspend".
> >
> > With this patch, the GPIO from my touch screen doesn't wake my device
> > any more, which is what I want.
>
> I think the direction is right here. We never should've separated the
> handling of idle vs suspend wakeups. However, I have a few
> questions/doubts below...
>
> > Cc: Kevin Hilman
> > Cc: Tony Lindgren
> > Cc: Santosh Shilimkar
> > Cc: Cousson Benoit
> > Cc: Grant Likely
> > Cc: Tarun Kanti DebBarma
> > Cc: Felipe Balbi
> > Cc: Govindraj.R
> >
> > Signed-off-by: NeilBrown
> >
> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> > index 4fbc208..fdbad70 100644
> > --- a/drivers/gpio/gpio-omap.c
> > +++ b/drivers/gpio/gpio-omap.c
> > @@ -57,6 +57,7 @@ struct gpio_bank {
> > u16 irq;
> > int irq_base;
> > struct irq_domain *domain;
> > + u32 suspend_wakeup;
> > u32 non_wakeup_gpios;
> > u32 enabled_non_wakeup_gpios;
> > struct gpio_regs context;
> > @@ -522,11 +523,12 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
> > int gpio, int enable)
> >
> > spin_lock_irqsave(&bank->lock, flags);
> > if (enable)
> > - bank->context.wake_en |= gpio_bit;
> > + bank->suspend_wakeup |= gpio_bit;
> > else
> > - bank->context.wake_en &= ~gpio_bit;
> > + bank->suspend_wakeup &= ~gpio_bit;
> >
> > - __raw_writel(bank->context.wake_en, bank->base + bank->regs->wkup_en);
> > + if (!bank->loses_context)
> > + __raw_writel(bank->suspend_wakeup, bank->base +
> > bank->regs->wkup_en);
>
> This doesn't look right for bank 1 (the only one that doesn't lose
> context.) If I'm not mistaken, this will overrides the idle wake_en
> settings (from context.wake_en), will disable GPIO IRQ triggering for
> any of the non IRQ wake-enabled GPIO IRQs in this bank...
Yes... I was clearly confused when writing that. There was a good reason at
the time, but I doesn't seem to stand up to the cold light of day..
>
> > spin_unlock_irqrestore(&bank->lock, flags);
> >
> > return 0;
> > @@ -1157,6 +1159,51 @@ static int __devinit omap_gpio_probe(struct
> > platform_device *pdev)
> > #ifdef CONFIG_ARCH_OMAP2PLUS
> >
> > #if defined(CONFIG_PM_RUNTIME)
> > +
> > +#if defined(CONFIG_PM_SLEEP)
>
[PATCH v5 0/14] KGDB/KDB FIQ (NMI) debugger
Hi all, There wasn't much feedback on v4, the only comment was from Brian Swetland concerning async console (I explained how we deal with it). It would be really great if the core functionality could make it into v3.7. Which raises the question: if the patches are OK, who should take them? They touch 3 subsystems: KGDB, TTY and ARM. Taking the patches via -mm or TTY trees would be the easiest way as this way we'll avoid having to deal with conflicts (see changelog*). But merging via ARM or KDB will also work. Russell, Jason, naively presuming that the ARM & KDB patches are OK, would you be willing to ack ARM/KDB patches? Or, in case if it goes via KDB or ARM tree, we'll need acks from Greg and Alan on tty patches... Anyways, here goes the shiny v5: - *I took two amba-pl1011 patches from Greg's tty tree. This is needed to ease Stephen Rothwell's life in case if this goes into -next via non-tty or non-mm tree. The problem is that we now touch the same lines as tty tree, and conflicts are not trivial. But by taking the two patches and rebasing my work on top, we turn the conflicts into trivial ones. - There were some concerns that '$3#33' might be not lengthy enough (i.e., it's a bit shorter than '\nreboot\n'). Reading 2GB of /dev/urandom couldn't find $3#33 sequence, but I made the magic phrase configurable via kgdb_nmi.magic kernel command line option, just in case. These patches can be found in the following repo: git://git.infradead.org/users/cbou/linux-nmi-kdb.git master Boilerplate: These patches introduce KGDB FIQ debugger support. The idea (and some code, of course) comes from Google's FIQ debugger[2]. There are some differences (mostly implementation details, feature-wise they're almost equivalent, or can be made equivalent, if desired). The FIQ debugger is a facility that can be used to debug situations when the kernel stuck in uninterruptable sections, e.g. the kernel infinitely loops or deadlocked in an interrupt or with interrupts disabled. On some development boards there is even a special NMI button, which is very useful for debugging weird kernel hangs. And FIQ is basically an NMI, it has a higher priority than IRQs, and upon IRQ exception FIQs are not disabled. It is still possible to disable FIQs (as well as some "NMIs" on other architectures), but via special means. So, here FIQs and NMIs are synonyms, but in the code I use NMI term for arch-independent code, and FIQs for ARM code. A few years ago KDB wasn't yet ready for production, or even not well-known, so originally Google implemented its own FIQ debugger that included its own shell, ring-buffer, commands, dumping, backtracing logic and whatnot. This is very much like PowerPC's xmon (arch/powerpc/xmon), except that xmon was there for a decade, so it even predates KDB. Anyway, nowadays KGDB/KDB is the cross-platform debugger, and the only feature that was missing is NMI handling. This is now fixed for ARM. There are a few differences comparing to the original (Google's) FIQ debugger: - Doing stuff in FIQ context is dangerous, as there we are not allowed to cause aborts or faults. In the original FIQ debugger there was a "signal" software-induced interrupt, upon exit from FIQ it would fire, and we would continue to execute "dangerous" commands from there. In KGDB/KDB we don't use signal interrupts. We can do easier: set up a breakpoint, continue, and you'll trap into KGDB again in a safe context. It works for most cases, but I can imagine cases when you can't set up a breakpoint. For these cases we'd better introduce a KDB command "exit_nmi", that will rise the SW IRQ, after which we're allowed to do anything. - KGDB/KDB FIQ debugger shell is synchronous. In Google's version you could have a dedicated shell always running in the FIQ context, so when you type something on a serial line, you won't actually cause any debugging actions, FIQ would save the characters in its own buffer and continue execution normally. But when you hit return key after the command, then the command is executed. In KGDB/KDB FIQ debugger it is different. Once you enter KGDB, the kernel will stop until you instruct it to continue. This might look as a drastic change, but it is not. There is actually no difference whether you have sync or async shell, or at least I couldn't find any use-case where this would matter at all. Anyways, it is still possible to do async shell in KDB, just don't see any need for this. - Original FIQ debugger used a custom FIQ vector handling code, w/ a lot of logic in it. In this approach I'm using the fact that FIQs are basically IRQs, except that we there are a bit more registers banked, and we can actually trap from the IRQ context. But this all does not prevent us from using a simple jump-table based approach as used in the generic ARM entry code. So, here I just reuse the generic approach. Note that I test the code on a m
Re: Question about failure in PCI power-state change
On 09/09/2012 07:24 PM, Huang Ying wrote: On Fri, 2012-09-07 at 15:48 -0700, Bjorn Helgaas wrote: +cc Rafael, Huang, linux-pm On Fri, Sep 7, 2012 at 3:44 PM, Larry Finger wrote: Hi, On occasion when I unload and reload driver rtl8192ce, I get the message "Refused to change power state, currently in D3" Hi, Larry, We fixed a similar issue recently. And the patch has been merged by v3.6-rc5. Can you try v3.6-rc5? V3.6-rc5 was merged with wireless-testing today. It did not change my symptoms, but I think I have identified another problem with my driver. Thanks for the heads-up. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: fan53555: remove vsel_max not used
2012/9/10 Yunfan Zhang : > The max voltage will be bounded by min_uV, uV_step and n_voltages, so > remove it to avoid confusing. > > Signed-off-by: Yunfan Zhang Acked-by: Axel Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: mtrr: Constrain WB MTRR to max phys mem prior to cleanup
于 2012-09-08 02:40, H. Peter Anvin 写道: On 09/07/2012 10:44 AM, Peter Hurley wrote: \> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c I really don't like it as it introduces yet another user of max_pfn, which should be going away. Furthermore, the better question is what remaining needs there are for MTRR cleanup; historically the reason was that it prevented the display from being mapped WC via MTRR due to the MTRR conflict resolution rules favoring UC. For a large memory system, mtrr_cleanup offten fail in most case. Even if it succeed, it often occupy all of MTRR entrys. How was display mapped as WC in above case? Why did bios give a lot of space then real mem, for hotplug? However, the right way to fix that is to use the PAT interfaces, which doesn't have this drawback -- then MTRR cleanup becomes entirely superfluous and the problem goes away. Do you mean disable MTRR totally here? Regards zduan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: fan53555: remove vsel_max not used
The max voltage will be bounded by min_uV, uV_step and n_voltages, so
remove it to avoid confusing.
Signed-off-by: Yunfan Zhang
---
drivers/regulator/fan53555.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/fan53555.c b/drivers/regulator/fan53555.c
index 890f2b3..339f4d7 100644
--- a/drivers/regulator/fan53555.c
+++ b/drivers/regulator/fan53555.c
@@ -74,7 +74,6 @@ struct fan53555_device_info {
unsigned int sleep_reg;
/* Voltage range and step(linear) */
unsigned int vsel_min;
- unsigned int vsel_max;
unsigned int vsel_step;
/* Voltage slew rate limiting */
unsigned int slew_rate;
@@ -180,12 +179,10 @@ static int fan53555_device_setup(struct
fan53555_device_info *di,
case FAN53555_CHIP_ID_03:
case FAN53555_CHIP_ID_05:
di->vsel_min = 60;
- di->vsel_max = 123;
di->vsel_step = 1;
break;
case FAN53555_CHIP_ID_04:
di->vsel_min = 603000;
- di->vsel_max = 1411000;
di->vsel_step = 12826;
break;
default:
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: Fix build warning in do_alignment.
Fix the following build warning:
arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: warning: 'offset.un' may be used
uninitialized in this function [-Wuninitialized]
arch/arm/mm/alignment.c:749:21: note: 'offset.un' was declared here
Signed-off-by: Chanho Min
---
arch/arm/mm/alignment.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 9107231..f83b38c 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -746,7 +746,7 @@ do_alignment_t32_to_handler(unsigned long *pinstr,
struct pt_regs *regs,
static int
do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
{
- union offset_union offset;
+ union offset_union offset = {0};
unsigned long instr = 0, instrptr;
int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs
*regs);
unsigned int type;
--
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/
linux-next: build failure after merge of the regulator tree
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "regulator_allow_bypass" [drivers/extcon/extcon-arizona.ko] undefined!
Caused by commit e6647c416e4f ("extcon: arizona: Use bypass mode for MICVDD").
I have used the regulator tree from next-20120907 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpMkCqOspiYd.pgp
Description: PGP signature
RE: regulator: fan53555: vsel_max does not match with the max voltage?
> -Original Message-
> From: Axel Lin [mailto:axel@gmail.com]
> Sent: 2012年9月10日 11:05
> To: Yunfan Zhang
> Cc: Liam Girdwood; Mark Brown; linux-kernel@vger.kernel.org
> Subject: regulator: fan53555: vsel_max does not match with the max voltage?
>
> Hi Yunfan,
> Just found below issue while reading the code:
>
> For FAN53555_CHIP_ID_04,
> di->vsel_min = 603000;
> di->vsel_max = 1411000;
> di->vsel_step = 12826;
> volt[63] = 1411038
>
> Then volt[63] is greater than the vsel_max now.
> This looks does not make sense.
Axel, Thanks for your findings!
Yes, the volt[63] is GT the vsel_max. Actually vsel_max is not used... The max
voltage will be bounded by desc->n_voltages. I will make a patch to remove it
to avoid confusing. Thanks a lot!
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 07/13] overlay: overlay filesystem documentation
On Mon, 10 Sep 2012 03:47:04 +0200 (CEST) Jan Engelhardt wrote: > > On Wednesday 2012-08-15 17:48, Miklos Szeredi wrote: > >[...] > >+This is most obvious from the 'st_dev' field returned by stat(2). > >+ > >+While directories will report an st_dev from the overlay-filesystem, > >+all non-directory objects will report an st_dev from the lower or > >+upper filesystem that is providing the object. > > That would seem to render `rsync --one-filesystem` unusable? > (or similar options in other tools) > Would it? Have you tested? or examine source code? or just guessed? I quick look at rsync and du suggest that you only consider --one-file-system when looking at a directory - they assume files are in the same filesystem as their parent. I cannot promise that everything would work exactly as expected, but I suspect most things will. though that might depend on your expectations. NeilBrown signature.asc Description: PGP signature
[PATCH 2/2] backlight: add new lm3639 backlight driver
From: "G.Shark Jeong" This driver is a general version for LM3639 backlgiht driver chip of TI. Put NEW_LEDS and LEDS_CLASS into Kconfig file to reduce additional configuration works in LEDs. www.ti.com Signed-off-by: G.Shark Jeong --- drivers/video/backlight/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index 2ed68bd..e6c78cd 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -356,6 +356,8 @@ config BACKLIGHT_LM3639 tristate "Backlight Driver for LM3639" depends on BACKLIGHT_CLASS_DEVICE && I2C select REGMAP_I2C + select NEW_LEDS + select LEDS_CLASS help This supports TI LM3639 Backlight + 1.5A Flash LED Driver -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] backlight: add new lm3630 backlight driver
From: "G.Shark Jeong" This driver is a general version for LM3630 backlgiht driver chip of TI. Put NEW_LEDS and LEDS_CLASS into Kconfig file to reduce additional configuration works in LEDs. www.ti.com Signed-off-by: G.Shark Jeong --- drivers/video/backlight/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index b9008b5..2f3646d 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -356,6 +356,8 @@ config BACKLIGHT_LM3630 tristate "Backlight Driver for LM3630" depends on BACKLIGHT_CLASS_DEVICE && I2C select REGMAP_I2C + select NEW_LEDS + select LEDS_CLASS help This supports TI LM3630 Backlight Driver -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Make the managed clk functions generically available
Hi Lars-Peter,
On 10/09/12 01:01, Lars-Peter Clausen wrote:
The managed clk functions are currently only available when the generic clk
lookup framework is build. But the managed clk functions are merely wrappers
around clk_get and clk_put and do not depend on any specifics of the generic
lookup functions and there are still quite a few custom implementations of the
clk API. So make the managed functions available whenever the clk API is
implemented.
The patch also removes the custom implementation of devm_clk_get for the
coldfire platform.
Signed-off-by: Lars-Peter Clausen
Nice work, thanks.
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/platform/coldfire/clk.c |6
drivers/clk/Makefile |1 +
drivers/clk/clk-devres.c | 55 +
drivers/clk/clkdev.c | 45 --
4 files changed, 56 insertions(+), 51 deletions(-)
create mode 100644 drivers/clk/clk-devres.c
diff --git a/arch/m68k/platform/coldfire/clk.c
b/arch/m68k/platform/coldfire/clk.c
index 75f9ee9..9cd13b4 100644
--- a/arch/m68k/platform/coldfire/clk.c
+++ b/arch/m68k/platform/coldfire/clk.c
@@ -146,9 +146,3 @@ struct clk_ops clk_ops1 = {
};
#endif /* MCFPM_PPMCR1 */
#endif /* MCFPM_PPMCR0 */
-
-struct clk *devm_clk_get(struct device *dev, const char *id)
-{
- return NULL;
-}
-EXPORT_SYMBOL(devm_clk_get);
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 6327536..b7b8620 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -1,4 +1,5 @@
# common clock types
+obj-$(CONFIG_HAVE_CLK) += clk-devres.o
obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \
clk-mux.o clk-divider.o clk-fixed-factor.o
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
new file mode 100644
index 000..f1e7a83
--- /dev/null
+++ b/drivers/clk/clk-devres.c
@@ -0,0 +1,55 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+static void devm_clk_release(struct device *dev, void *res)
+{
+ clk_put(*(struct clk **)res);
+}
+
+struct clk *devm_clk_get(struct device *dev, const char *id)
+{
+ struct clk **ptr, *clk;
+
+ ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ clk = clk_get(dev, id);
+ if (!IS_ERR(clk)) {
+ *ptr = clk;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return clk;
+}
+EXPORT_SYMBOL(devm_clk_get);
+
+static int devm_clk_match(struct device *dev, void *res, void *data)
+{
+ struct clk **c = res;
+ if (!c || !*c) {
+ WARN_ON(!c || !*c);
+ return 0;
+ }
+ return *c == data;
+}
+
+void devm_clk_put(struct device *dev, struct clk *clk)
+{
+ int ret;
+
+ ret = devres_destroy(dev, devm_clk_release, devm_clk_match, clk);
+
+ WARN_ON(ret);
+}
+EXPORT_SYMBOL(devm_clk_put);
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index d423c9b..442a313 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -171,51 +171,6 @@ void clk_put(struct clk *clk)
}
EXPORT_SYMBOL(clk_put);
-static void devm_clk_release(struct device *dev, void *res)
-{
- clk_put(*(struct clk **)res);
-}
-
-struct clk *devm_clk_get(struct device *dev, const char *id)
-{
- struct clk **ptr, *clk;
-
- ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
- if (!ptr)
- return ERR_PTR(-ENOMEM);
-
- clk = clk_get(dev, id);
- if (!IS_ERR(clk)) {
- *ptr = clk;
- devres_add(dev, ptr);
- } else {
- devres_free(ptr);
- }
-
- return clk;
-}
-EXPORT_SYMBOL(devm_clk_get);
-
-static int devm_clk_match(struct device *dev, void *res, void *data)
-{
- struct clk **c = res;
- if (!c || !*c) {
- WARN_ON(!c || !*c);
- return 0;
- }
- return *c == data;
-}
-
-void devm_clk_put(struct device *dev, struct clk *clk)
-{
- int ret;
-
- ret = devres_destroy(dev, devm_clk_release, devm_clk_match, clk);
-
- WARN_ON(ret);
-}
-EXPORT_SYMBOL(devm_clk_put);
-
void clkdev_add(struct clk_lookup *cl)
{
mutex_lock(&clocks_mutex);
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
--
To un
regulator: fan53555: vsel_max does not match with the max voltage?
Hi Yunfan, Just found below issue while reading the code: For FAN53555_CHIP_ID_04, di->vsel_min = 603000; di->vsel_max = 1411000; di->vsel_step = 12826; So we have below voltage list for FAN53555_CHIP_ID_04: volt[0] = 603000 volt[1] = 615826 volt[2] = 628652 volt[3] = 641478 volt[4] = 654304 volt[5] = 667130 ... volt[60] = 1372560 volt[61] = 1385386 volt[62] = 1398212 volt[63] = 1411038 Then volt[63] is greater than the vsel_max now. This looks does not make sense. Regards, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] efikamx: remove Efika MX-specific CHRGVBUS hack from the USB driver
On Wed, Aug 1, 2012 at 2:49 PM, Matt Sealey wrote: > Since we're removing Efika MX support from the tree (for now), remove > the hack present in the USB host driver since it will never run and > isn't useful on any other systems. > > Signed-off-by: Matt Sealey You should Cc linux-usb list and the USB maintainer on this one. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH][v3] sata_fsl: add workaround for data length mismatch on freescale V2 controller
> > + /* Workaround for data length mismatch errata */
> > + if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
> > + for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
> > + qc = ata_qc_from_tag(ap, tag);
> > + if (qc && ata_is_atapi(qc->tf.protocol)) {
> > + u32 hcontrol;
> > +#define HCONTROL_CLEAR_ERROR (1 << 27)
>
> shouldn't we have this #define be part of the enum that the other
> HCONTROL_ bits/flags are part of?
[S.H] do you mean this?
#ifdef SATA_FSL_XXX_ERRATUAM
#define HCONTROL_CLEAR_ERROR(1 << 27)
#endif
Then we need to decide where to put "#define SATA_FSL_XXX_ERRATUAM".
It's only a readable definition of a register bit which avoiding magic number.
Best Regards,
Shaohui Xie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] hashtable: introduce a small and naive hashtable
* Sasha Levin (levinsasha...@gmail.com) wrote:
> This hashtable implementation is using hlist buckets to provide a simple
> hashtable to prevent it from getting reimplemented all over the kernel.
>
> Signed-off-by: Sasha Levin
> ---
>
> I'll send just the hashtable patch itself to avoid spamming a bunch of people
> until
> it's stable again.
>
> include/linux/hashtable.h | 183
> ++
> 1 file changed, 183 insertions(+)
> create mode 100644 include/linux/hashtable.h
>
> diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h
> new file mode 100644
> index 000..2d2fd14
> --- /dev/null
> +++ b/include/linux/hashtable.h
> @@ -0,0 +1,183 @@
> +/*
> + * Hash table implementation
> + * (C) 2012 Sasha Levin
> + */
> +
> +#ifndef _LINUX_HASHTABLE_H
> +#define _LINUX_HASHTABLE_H
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEFINE_HASHTABLE(name, bits)
> \
> + struct hlist_head name[HASH_SIZE(bits)] =
> \
> + { [0 ... HASH_SIZE(bits) - 1] = HLIST_HEAD_INIT };
I think the final ";" should not be here.
> +
> +#define DECLARE_HASHTABLE(name, bits)
> \
> + struct hlist_head name[1 << bits];
Is the operator priority always OK here, or should we put bits between
parenthesis ?
The final ";" should not be here.
> +
> +#define HASH_SIZE(name) (1 << (HASH_BITS(name)))
Parenthesis around HASH_BITS(name) seem useless.
> +#define HASH_BITS(name) (ilog2(ARRAY_SIZE(name)))
Parenthesis around ilog2(ARRAY_SIZE(name)) seem useless too.
> +
> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit
> kernels. */
> +#define hash_min(val, bits) ({
> \
hash_init has a newline before ({, but not here. Please use a consistent
style.
> + sizeof(val) <= 4 ?
> \
> + hash_32(val, bits) :
> \
> + hash_long(val, bits);
> \
> +})
> +
> +/**
> + * hash_init - initialize a hash table
> + * @hashtable: hashtable to be initialized
> + *
> + * Calculates the size of the hashtable from the given parameter, otherwise
> + * same as hash_init_size.
> + */
> +#define hash_init(hashtable)
> \
> +({
> \
> + int __i;
> \
> +
> \
> + for (__i = 0; __i < HASH_BITS(hashtable); __i++)
> \
> + INIT_HLIST_HEAD(hashtable + __i);
> \
I suspect that hashtable will be a pointer, and you use the "+" operator
to do an offset on this pointer. Any thought on using:
INIT_HLIST_HEAD(&hashtable[__i]);
instead ? It would provide the same result, but would ensure that the
user is indeed passing a pointer, and not an integer.
Also, why isn't it a static inline ? I'm probably missing something. If
there is a reason why it needs to stay a #define, please document it in
the comment.
> +})
> +
> +/**
> + * hash_add - add an object to a hashtable
> + * @hashtable: hashtable to add to
> + * @node: the &struct hlist_node of the object to be added
> + * @key: the key of the object to be added
> + */
> +#define hash_add(hashtable, node, key)
> \
> + hlist_add_head(node, &hashtable[hash_min(key, HASH_BITS(hashtable))]);
> +
> +/**
> + * hash_add_rcu - add an object to a rcu enabled hashtable
> + * @hashtable: hashtable to add to
> + * @node: the &struct hlist_node of the object to be added
> + * @key: the key of the object to be added
> + */
> +#define hash_add_rcu(hashtable, node, key)
> \
> + hlist_add_head_rcu(node, &hashtable[hash_min(key,
> HASH_BITS(hashtable))]);
> +
> +/**
> + * hash_hashed - check whether an object is in any hashtable
> + * @node: the &struct hlist_node of the object to be checked
> + */
> +#define hash_hashed(node) (!hlist_unhashed(node))
> +
> +/**
> + * hash_empty - check whether a hashtable is empty
> + * @hashtable: hashtable to check
> + */
> +#define hash_empty(hashtable)
> \
> +({
> \
> + int __i;
> \
> + bool __ret = true;
> \
> +
> \
> + for (__i = 0; __i < HASH_SIZE(hashtable); __i++)
Re: [ 84/95] virtio_blk: fix config handler race
On 09/10/2012 10:26 AM, Rusty Russell wrote: > Ben Hutchings writes: > >> 3.2-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> From: "Michael S. Tsirkin" >> >> commit 4678d6f970c2f7c0cbfefc0cc666432d153b321b upstream. >> >> Fix a theoretical race related to config work > > ??? > > From Documentation/stable_kernel_rules.txt: > > - No "theoretical race condition" issues, unless an explanation of how the >race can be exploited is also provided. > > Similarly, '[ 85/95] virtio_blk: Drop unused request tracking list' > is a marginal perf improvement, why is it in there? This also drops the following line which may trigger a BUG in hot -unplug path. /* Nothing should be pending. */ BUG_ON(!list_empty(&vblk->reqs)); So, this patch is needed to fix up the hot-unplug bug along with the others. > > Neither of these were cc:stable; did someone request them specifically? > > Confused, > Rusty. > -- Asias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/6] ARM: dove: DT support for Marvell Dove
On Wed, Aug 15, 2012 at 07:07:29PM +0200, Sebastian Hesselbarth wrote: > This patch set adds DT support for Marvell Dove SoC and three boards > equipped with this SoC. The work is based on device tree support for > Marvell Orion based SoCs introduced in 3.6-rc1. > > The first three patches move mach-dove closer to Marvell Kirkwood's > setup code by unifying the clock setup routines, adding clock gating > control, and support for Marvell's crypto engine to mach-dove. > > Patches 4 and 5 add a generic DT machine descriptor to mach-dove and > corresponding DT descriptors for the SoC and already supported boards. > > Finally, the last patch adds a DT descriptor for the SolidRun CuBox, > a plug computer based on Marvell Dove. > > This patch set relies on a DT support patch for sdhci-dove that has > been accepted on mmc-next for 3.7 as commit > b2293055c1e1200acbb46523976852d1686fdfa4. > > Changes: > v2: removed clk_prepare_enable for tclk and updated subsequent patches > v3: fixed a typo in clk_gate name for pex0 > removed device name macros from clk gate names > > Sebastian Hesselbarth (6): > ARM: dove: unify clock setup > ARM: dove: add clock gating control > ARM: dove: add crypto engine > ARM: dove: add device tree based machine descriptor > ARM: dove: add device tree descriptors > ARM: dove: SolidRun CuBox DT > > arch/arm/boot/dts/dove-cm-a510.dts | 38 + > arch/arm/boot/dts/dove-cubox.dts | 42 + > arch/arm/boot/dts/dove-dove-db.dts | 38 + > arch/arm/boot/dts/dove.dtsi | 143 +++ > arch/arm/mach-dove/Kconfig |7 ++ > arch/arm/mach-dove/Makefile.boot |4 + > arch/arm/mach-dove/common.c | 156 > +++--- > arch/arm/mach-dove/include/mach/pm.h | 54 > 8 files changed, 452 insertions(+), 30 deletions(-) > create mode 100644 arch/arm/boot/dts/dove-cm-a510.dts > create mode 100644 arch/arm/boot/dts/dove-cubox.dts > create mode 100644 arch/arm/boot/dts/dove-dove-db.dts > create mode 100644 arch/arm/boot/dts/dove.dtsi > > Signed-off-by: Sebastian Hesselbarth > Acked-by: Arnd Bergmann Whole series applied to: git://git.infradead.org/users/jcooper/linux.git kirkwood/boards thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump with iommu
> -Original Message- > From: linux-pci-ow...@vger.kernel.org > [mailto:linux-pci-ow...@vger.kernel.org] On Behalf Of Takao Indoh > Sent: Wednesday, September 05, 2012 8:10 PM > To: vgo...@redhat.com > Cc: ke...@lists.infradead.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org; bhelg...@google.com; hb...@us.ibm.com; Ishii, > Hironobu/石井 宏延; martin.wi...@ts.fujitsu.com > Subject: Re: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump > with iommu > > (2012/08/07 5:39), Vivek Goyal wrote: > > On Mon, Aug 06, 2012 at 01:30:47PM +0900, Takao Indoh wrote: > >> Hi Vivek, > >> > >> (2012/08/03 20:46), Vivek Goyal wrote: > >>> On Fri, Aug 03, 2012 at 08:24:31PM +0900, Takao Indoh wrote: > Hi all, > > This patch adds kernel parameter "reset_pcie_devices" which resets > PCIe > devices at boot time to address DMA problem on kdump with iommu. When > this parameter is specified, a hot reset is triggered on each PCIe > root > port and downstream port to reset its downstream endpoint. > >>> > >>> Hi Takao, > >>> > >>> Why not use existing "reset_devices" parameter instead of introducing > >>> a new one? > >> > >> "reset_devices" is used for each driver to reset their own device, and > >> this patch resets all devices forcibly, so I thought they were different > >> things. > > > > Yes reset_devices currently is used for driver to reset its device. I > > thought one could very well extend its reach to reset pci express devices > > at bus level. > > > > Having them separate is not going to be much useful from kdump > > perspective. We will end up passing both reset_devices and > > reset_pcie_devices to second kernel whill lead to bus level reset as well > > as device level reset. > > > > Ideal situation would be that somehow detect that bus level reset has > been > > done and skip device level reset (assuming bus level reset obviates the > > need of device level reset, please correct me if that's not the case). > > > > After pcie reset, can we store the state in a variable and drivers can > > use that variable to check if PCIe level reset was done or not. If yes, > > skip device level reset (Assuming driver knows that device is on a > > PCIe slot). > > > > In that case we will not have to introduce new kernel command line, and > > also avoid double reset? > > I found a problem when testing my patch on some machines. > > Originally there are two problems in kdump kernel when iommu is enabled; > DMAR error and PCI SERR. I thought they are fixed by my patch, but I > noticed that PCI SERR is still detected after applying the patch. It > seems that something happens when Interrupt Remapping is initialized in > kdump kernel. I'm not sure, but I guess the PCI SERR might be caused as follows. - The 1st kernel enables interrupt remapping. The MSI(-X) address and data registers of PCI devices are programmed in remappable format. - At the beginning of 2nd kernel, interrupt remapping is still active. And then it is disabled by enable_IR() function for initialization. - PCI device generate an interrupt. At this moment, interrupt remapping is not enabled yet. On the other hand, MSI(-X) address and data of this interrupt is in remappable format because those are programmed by 1st kernel. I guess this might be a cause of PCI SERR. I guess clearing command register or disabling MSI before interrupt remapping initialization in 2nd kernel might solve the PCI SERR problem. Regards, Kenji Kaneshige > > Therefore resetting devices has to be done before enable_IR() is > called. I have three ideas for it. > > (i) Resetting devices in 1st kernel(panic kernel) > We can reset devices before jumping into 2nd kernel. Of course it may > be dangerous to scan pci device tree and call PCI functions in panic'd > kernel. Beforehand we need to collect device information so that only > minimal code could run on panic. > > (ii) Resetting devices in purgatory > It seems to be be appropriate place to do this, but I'm not sure > where I can save/restore PCI config when resetting devices in > purgatory. > > (iii) Resetting devices in 2nd kernel(kdump kernel) > Important point is to do reset before enable_IR() is called as I wrote > above. I think I should add new function to do reset into > arch/x86/pci/early.c and call it in setup_arch like > early_dump_pci_devices() or early_quirks(). > > Any comments? > > Thanks, > Takao Indoh > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
"Michael S. Tsirkin" writes: > On Sat, Sep 08, 2012 at 02:36:00PM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" writes: >> > On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote: >> >> > So it looks like a bug: we should teach driver to tell host first on >> >> > leak? >> >> > Yan, Vadim, can you comment please? >> >> > >> >> > Also if true, looks like this bit will be useful to detect a fixed >> >> > driver on >> >> > the hypervisor side - to avoid unmapping such pages? Rusty what do you >> >> > think? >> >> >> >> So, feature is unimplemented in qemu, and broken in drivers. I starting >> >> to share Paolo's dislike of it. >> > >> > What is broken in drivers? >> >> Because supporting the feature is *not* optional for a driver. >> >> If the device said MUST_TELL_HOST, it meant that the driver *had* to >> tell the host before it touched the page, otherwise Bad Things might >> happen. It was in the original spec precisely to allow devices to >> actually *remove* pages. >> >> Noone ever noticed the windows driver didn't support it, because qemu >> never requires MUST_TELL_HOST. >> >> So in practice, it's now an optional feature. Since no device used it >> anyway, we're better off discarding it than trying to fix it. > > I trust you this was not the intent. But it seems to be > the intent in spec, because almost all features are optional. > > And so windows driver authors interpreted it > this way. And it is *useful* like this. See below. ... > Suggested use is for device assignment which needs all guest memory > locked. hypervisor can unlock pages in balloon but guest must wait for > hypervisor to lock them back before use. > > when a hypervisor implements this, > this will work with linux guests but not windows > guests and the existing bit fits exactly the purpose. If a hypervisor needs this, and the guest doesn't support it, then the hypervisor can only abandon the balloon device. That's not my definition of "optional". >> > Do we really know there are no hypervisors implementing it? >> >> As much as can be known. Qemu doesn't, lkvm doesn't. > > But we can add it in qemu and it will be a useful feature. > >> > As I said above drivers do have support. >> >> Not the windows drivers. So it's optional, thus removing it will likely >> harm noone. >> >> Cheers, >> Rusty. > > I think the issue is that kvm always locked all guest memory > for assignment. This restriction is removed > with vfio which has separate page tables. > Now that vfio is upstream and work on qemu integration > is being worked on, we might finally see people using this bit > to allow memory overcommit with device assignment. That was left-field so you're saying some guest might pull a page from the balloon and DMA to it, and the vfio device needs to know in advance that it's going to do it? But what will we do if the guest doesn't ack the bit? ie. I don't think it can really be optional. 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 1/2] module: add syscall to load module from fd
Kees Cook writes: > On Fri, Sep 7, 2012 at 10:12 AM, Mimi Zohar wrote: >> This method is a consistent and extensible approach to verifying the >> integrity of file data/metadata, including kernel modules. The only >> downside to this approach, I think, is that it requires changes to the >> userspace tool. > > I'm fine with this -- it's an expected change that I'll pursue with > glibc, kmod, etc. Without the userspace changes, nothing will use the > new syscall. :) I've already got kmod (and older module-init-tools) > patched to do this locally. A syscall is the right way to do this. But does it need to be done? 1) Do the LSM guys really want this hook? 2) Do we have a userspace which uses it? If yes to both, and noone comes up with any creative complaints, I will take the patch. 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: [ 84/95] virtio_blk: fix config handler race
Ben Hutchings writes: > 3.2-stable review patch. If anyone has any objections, please let me know. > > -- > > From: "Michael S. Tsirkin" > > commit 4678d6f970c2f7c0cbfefc0cc666432d153b321b upstream. > > Fix a theoretical race related to config work ??? >From Documentation/stable_kernel_rules.txt: - No "theoretical race condition" issues, unless an explanation of how the race can be exploited is also provided. Similarly, '[ 85/95] virtio_blk: Drop unused request tracking list' is a marginal perf improvement, why is it in there? Neither of these were cc:stable; did someone request them specifically? Confused, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio: console: fix error handling in init() function
Amit Shah writes: > On (Sat) 01 Sep 2012 [23:49:37], Alexey Khoroshilov wrote: >> If register_virtio_driver() fails, virtio-ports class is not destroyed. >> The patch adds error handling of register_virtio_driver(). >> >> Found by Linux Driver Verification project (linuxtesting.org). >> >> Signed-off-by: Alexey Khoroshilov > > Acked-by: Amit Shah > > Rusty, please pick this up. Thanks for the CC. Applied, 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/
[PATCH 2/2 V7 for-3.6-fixes] workqueue: fix idle worker depletion
If hotplug code grabbed the manager_mutex and worker_thread try to create
a worker, the manage_worker() will return false and worker_thread go to
process work items. Now, on the CPU, all workers are processing work items,
no idle_worker left/ready for managing. It breaks the concept of workqueue
and it is bug.
So when manage_worker() failed to grab the manager_mutex, it should
release gcwq->lock and then grab manager_mutex.
After gcwq->lock is released, hotplug can happen. but the hoplug code
can't unbind/rebind the manager, so the manager should try to rebind
itself unconditionaly, if it fails, unbind itself.
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 383548e..74434c8 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1825,10 +1825,39 @@ static bool manage_workers(struct worker *worker)
struct worker_pool *pool = worker->pool;
bool ret = false;
- if (!mutex_trylock(&pool->manager_mutex))
+ if (pool->flags & POOL_MANAGING_WORKERS)
return ret;
pool->flags |= POOL_MANAGING_WORKERS;
+
+ if (unlikely(!mutex_trylock(&pool->manager_mutex))) {
+ /*
+* Ouch! rebind_workers() or gcwq_unbind_fn() beats it.
+* it can't return false here, otherwise it will lead to
+* worker depletion. So we release gcwq->lock and then
+* grab manager_mutex again.
+*/
+ spin_unlock_irq(&pool->gcwq->lock);
+ mutex_lock(&pool->manager_mutex);
+
+ /*
+* The hotplug had happened after the previous releasing
+* of gcwq->lock. So we can't assume that this worker is
+* still associated or not. And we have to try to rebind it
+* via worker_maybe_bind_and_lock(). If it returns false,
+* we can conclude that the whole gcwq is disassociated,
+* and we must unbind this worker. (hotplug code can't
+* unbind/rebind the manager, because hotplug code can't
+* iterate the manager)
+*/
+ if (worker_maybe_bind_and_lock(worker))
+ worker->flags &= ~WORKER_UNBOUND;
+ else
+ worker->flags |= WORKER_UNBOUND;
+
+ ret = true;
+ }
+
pool->flags &= ~POOL_MANAGE_WORKERS;
/*
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 V7 for-3.6-fixes] workqueue: add POOL_MANAGING_WORKERS
When hotplug happens, the plug code will also grab the manager_mutex,
it will break too_many_workers()'s assumption, and make too_many_workers()
ugly(kick the timer wrongly, no found bug).
To avoid assumption-coruption, we add the original POOL_MANAGING_WORKERS back.
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index dc7b845..383548e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -66,6 +66,7 @@ enum {
/* pool flags */
POOL_MANAGE_WORKERS = 1 << 0, /* need to manage workers */
+ POOL_MANAGING_WORKERS = 1 << 1, /* managing workers */
/* worker flags */
WORKER_STARTED = 1 << 0, /* started */
@@ -652,7 +653,7 @@ static bool need_to_manage_workers(struct worker_pool *pool)
/* Do we have too many workers and should some go away? */
static bool too_many_workers(struct worker_pool *pool)
{
- bool managing = mutex_is_locked(&pool->manager_mutex);
+ bool managing = pool->flags & POOL_MANAGING_WORKERS;
int nr_idle = pool->nr_idle + managing; /* manager is considered idle */
int nr_busy = pool->nr_workers - nr_idle;
@@ -1827,6 +1828,7 @@ static bool manage_workers(struct worker *worker)
if (!mutex_trylock(&pool->manager_mutex))
return ret;
+ pool->flags |= POOL_MANAGING_WORKERS;
pool->flags &= ~POOL_MANAGE_WORKERS;
/*
@@ -1836,6 +1838,7 @@ static bool manage_workers(struct worker *worker)
ret |= maybe_destroy_workers(pool);
ret |= maybe_create_worker(pool);
+ pool->flags &= ~POOL_MANAGING_WORKERS;
mutex_unlock(&pool->manager_mutex);
return ret;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] UV: fix incorrect tlb flush all issue
On 09/07/2012 03:10 PM, Jan Beulich wrote: On 07.09.12 at 07:37, Alex Shi wrote: >> @@ -1113,7 +1114,10 @@ const struct cpumask *uv_flush_tlb_others(const >> struct >> cpumask *cpumask, >> >> record_send_statistics(stat, locals, hubs, remotes, bau_desc); >> >> -bau_desc->payload.address = start; >> +if (!end) > > So despite having made a very similar mistake on the Xen side, > you're again not following your own code adjustments here: > The indicator for a multi-page flush is not 'end' being zero, nor > would it be okay to use the proper indicator (TLB_FLUSH_ALL) > here. Instead, to yield correct code, you need to check for the > range covering more than one page. Improvements to do finer > grained flushing (if worthwhile on UV) could then be done on > top of this. > Thanks for catching this typo. The patch was updated: == >From bccb5f34834986fbd36c069640237296a9b1fe37 Mon Sep 17 00:00:00 2001 From: Alex Shi Date: Fri, 7 Sep 2012 10:38:36 +0800 Subject: [PATCH] x86/uv: fix incorrect tlb flush issue The flush tlb optimization code has logical issue on UV platform. It doesn't flush the full range at all, since it simply ignores its 'end' parameter (and hence also the "all" indicator) in uv_flush_tlb_others() function. I have tried to embed the start/end on UV code, but finally find the 'payload' message format embedded hardware filled vector. So be lacking the enough knowledge of the hardware, I just check the start/end fair in uv_flush_tlb_others(): except single page flush, will flush all TLB entries for other situations. Reported-by: Jan Beulich Signed-off-by: Alex Shi Cc: Jack Steiner Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" --- arch/x86/platform/uv/tlb_uv.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c index b8b3a37..582836e 100644 --- a/arch/x86/platform/uv/tlb_uv.c +++ b/arch/x86/platform/uv/tlb_uv.c @@ -1034,7 +1034,8 @@ static int set_distrib_bits(struct cpumask *flush_mask, struct bau_control *bcp, * globally purge translation cache of a virtual address or all TLB's * @cpumask: mask of all cpu's in which the address is to be removed * @mm: mm_struct containing virtual address range - * @va: virtual address to be removed (or TLB_FLUSH_ALL for all TLB's on cpu) + * @start: start virtual address to be removed from TLB + * @end: end virtual address to be remove from TLB * @cpu: the current cpu * * This is the entry point for initiating any UV global TLB shootdown. @@ -1113,7 +1114,10 @@ const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask, record_send_statistics(stat, locals, hubs, remotes, bau_desc); - bau_desc->payload.address = start; + if (!end || (end - start) <= PAGE_SIZE) + bau_desc->payload.address = start; + else + bau_desc->payload.address = TLB_FLUSH_ALL; bau_desc->payload.sending_cpu = cpu; /* * uv_flush_send_and_wait returns 0 if all cpu's were messaged, -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] regulator: Fairchild fan53555 support
On Sat, Sep 08, 2012 at 03:52:18AM -0700, Yunfan Zhang wrote: > This driver supports Fairchild FAN53555 Digitally Programmable > TinyBuck Regulator. The FAN53555 is a step-down switching voltage > regulator that delivers a digitally programmable output from an > input voltage supply of 2.5V to 5.5V. The output voltage is > programmed through an I2C interface. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clock: max77686: Add driver for Maxim 77686 32Khz crystal oscillator.
On 2012년 09월 07일 09:04, Mike Turquette wrote:
> Quoting Jonghwa Lee (2012-08-28 01:54:28)
>> This patch supports max77686 mfd's clock driver using common clock frame
>> work.
>> max77686 has 3 clock ouputs which all are generated from crystal oscillator
>> and
>> SOC can enable/disable them via I2C bus. All clocks are fixed-rate clock
>> sources
>> so that it doesn't supply interface for changing clock rate.
>> Driver uses regmap API to communicate with internal register.
>>
>> Signed-off-by: Jonghwa Lee
>
> Looks good. I've taken this into clk-next.
>
> Regards,
> Mike
>
Thanks,
Best Regards,
Jonghwa
>> ---
>> v5
>> - Add registering failure handle for each clocks to prevent memory leak.
>> - Update to use the latest clk_register. (Add clk_init_data).
>> - Rename Kconfig menu's name and replace its position.
>>
>> v4
>> https://lkml.org/lkml/2012/6/27/183
>>
>> drivers/clk/Kconfig|6 +
>> drivers/clk/Makefile |1 +
>> drivers/clk/clk-max77686.c | 244
>>
>> 3 files changed, 251 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/clk/clk-max77686.c
>>
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index 7f0b5ca..f300ec7 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -40,4 +40,10 @@ config COMMON_CLK_WM831X
>>Supports the clocking subsystem of the WM831x/2x series of
>> PMICs from Wolfson Microlectronics.
>>
>> +config COMMON_CLK_MAX77686
>> + tristate "Clock driver for Maxim 77686 MFD"
>> + depends on MFD_MAX77686
>> + ---help---
>> + This driver supports Maxim 77686 crystal oscillator clock.
>> +
>> endmenu
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 5869ea3..97f5c57 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -13,3 +13,4 @@ obj-$(CONFIG_ARCH_INTEGRATOR) += versatile/
>>
>> # Chip specific
>> obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>> +obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
>> diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
>> new file mode 100644
>> index 000..ac5f543
>> --- /dev/null
>> +++ b/drivers/clk/clk-max77686.c
>> @@ -0,0 +1,244 @@
>> +/*
>> + * clk-max77686.c - Clock driver for Maxim 77686
>> + *
>> + * Copyright (C) 2012 Samsung Electornics
>> + * Jonghwa Lee
>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +enum {
>> + MAX77686_CLK_AP = 0,
>> + MAX77686_CLK_CP,
>> + MAX77686_CLK_PMIC,
>> + MAX77686_CLKS_NUM,
>> +};
>> +
>> +struct max77686_clk {
>> + struct max77686_dev *iodev;
>> + u32 mask;
>> + struct clk_hw hw;
>> + struct clk_lookup *lookup;
>> +};
>> +
>> +static struct max77686_clk *get_max77686_clk(struct clk_hw *hw)
>> +{
>> + return container_of(hw, struct max77686_clk, hw);
>> +}
>> +
>> +static int max77686_clk_prepare(struct clk_hw *hw)
>> +{
>> + struct max77686_clk *max77686;
>> + int ret;
>> +
>> + max77686 = get_max77686_clk(hw);
>> + if (!max77686)
>> + return -ENOMEM;
>> +
>> + ret = regmap_update_bits(max77686->iodev->regmap,
>> + MAX77686_REG_32KHZ, max77686->mask, max77686->mask);
>> +
>> + return ret;
>> +}
>> +
>> +static void max77686_clk_unprepare(struct clk_hw *hw)
>> +{
>> + struct max77686_clk *max77686;
>> +
>> + max77686 = get_max77686_clk(hw);
>> + if (!max77686)
>> + return;
>> +
>> + regmap_update_bits(max77686->iodev->regmap,
>> + MAX77686_REG_32KHZ, max77686->mask, ~max77686->mask);
>> +}
>> +
>> +static int max77686_clk_is_enabled(struct clk_hw *hw)
>> +{
>> + struct max77686_clk *max77686;
>> + int ret;
>> + u32 val;
>> +
>> + max77686 = get_max77686_clk(hw);
>> + if (!max77686)
>> + return -ENOMEM;
>> +
>> + ret = regmap_read(max77686->iodev->regmap,
>> + MAX77686_REG_32KHZ, &val);
>> +
>> + if (ret < 0)
>> + return -EINVAL;
>> +
>> +
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/09/01 5:49, Andrew Morton wrote:
>> On Tue, 28 Aug 2012 18:00:07 +0800
>> we...@cn.fujitsu.com wrote:
>>
>>> This patch series aims to support physical memory hot-remove.
>>
>> Have you had much review and testing feedback yet?
>>
>>> The patches can free/remove the following things:
>>>
>>>- acpi_memory_info : [RFC PATCH 4/19]
>>>- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
>>>- iomem_resource: [RFC PATCH 9/19]
>>>- mem_section and related sysfs files : [RFC PATCH 10-11,
>>> 13-16/19]
>>>- page table of removed memory : [RFC PATCH 12/19]
>>>- node and related sysfs files : [RFC PATCH 18-19/19]
>>>
>>> If you find lack of function for physical memory hot-remove, please
>>> let me
>>> know.
>>
>
>> I doubt if many people have hardware which permits physical memory
>> removal? How would you suggest that people with regular hardware can
>> test these chagnes?
>
> How do you test the patch? As Andrew says, for hot-removing memory,
> we need a particular hardware. I think so too. So many people may want
> to know how to test the patch.
> If we apply following patch to kvm guest, can we hot-remove memory on
> kvm guest?
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
Yes, if we apply this patchset, we can test hot-remove memory on kvm guest.
But that patchset doesn't implement _PS3, so there is some restriction.
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>>> Known problems:
>>> 1. memory can't be offlined when CONFIG_MEMCG is selected.
>>
>> That's quite a problem! Do you have a description of why this is the
>> case, and a plan for fixing it?
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi Wen,
2012/09/01 5:49, Andrew Morton wrote:
On Tue, 28 Aug 2012 18:00:07 +0800
we...@cn.fujitsu.com wrote:
This patch series aims to support physical memory hot-remove.
Have you had much review and testing feedback yet?
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please let me
know.
I doubt if many people have hardware which permits physical memory
removal? How would you suggest that people with regular hardware can
test these chagnes?
How do you test the patch? As Andrew says, for hot-removing memory,
we need a particular hardware. I think so too. So many people may want
to know how to test the patch.
If we apply following patch to kvm guest, can we hot-remove memory on
kvm guest?
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
Thanks,
Yasuaki Ishimatsu
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
That's quite a problem! Do you have a description of why this is the
case, and a plan for fixing it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/13] overlay: overlay filesystem documentation
On Wednesday 2012-08-15 17:48, Miklos Szeredi wrote: >[...] >+This is most obvious from the 'st_dev' field returned by stat(2). >+ >+While directories will report an st_dev from the overlay-filesystem, >+all non-directory objects will report an st_dev from the lower or >+upper filesystem that is providing the object. That would seem to render `rsync --one-filesystem` unusable? (or similar options in other tools) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/7] perf ui/browser: Add browser for perf script
Hi Feng, On Fri, 7 Sep 2012 16:42:22 +0800, Feng Tang wrote: > Hi Arnaldo and all, > > This is a patch set mainly to add a browser for perf script, which > will be integrated into the main hists and annotation browser. > > Patch 1-4 are some preparation for adding the script > patch 5 introduce the script browser > patch 6-7 integrate the browser to hists browser and annotation browser > > The patches are on top of current perf/core branch of your git tree. > Please help to review. > > Namhyung, > > Many thanks for providing many good comments for the v1 patch sets. In > this v2, I addressed most of those comments, for the suggestion to use > browser for "perf script -l", I'll handle it later, and would post the > v2 first for review. > > Changelog: > Since v1: > * Add filter for scripts can't be run in script browser > * Fix some bugs about buffer handling and error check For whole series, Reviewed-by: Namhyung Kim Thanks for your work! Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] genalloc: make possible to use a custom allocation algorithm
On Fri, 2012-09-07 at 11:16 +0200, Benjamin Gaignard wrote:
> From: Benjamin Gaignard
>
> This patch allow to use another algorithm than the default first-fit one.
> For example a custom algorithm could be used to manage alignment requirements.
>
> Add of best-fit algorithm function:
> most of the time best-fit is slower then first-fit but memory fragmentation
> is lower.
> Random buffer allocation/free tests don't show any arithmetic relation between
> allocation time and fragmentation but best-fit algorithm is sometime able to
> perform the allocation when first-fit can't.
>
> This new algorithm help to solve fragmentation issues on ESRAM shared by
> multiple
> hardware IP allocating and freeing dynamically memory region of various sizes.
>
> Signed-off-by: Benjamin Gaignard
> ---
> include/linux/genalloc.h | 15
> lib/genalloc.c | 86
> +++---
> 2 files changed, 97 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
> index 5e98eeb..b8570a7 100644
> --- a/include/linux/genalloc.h
> +++ b/include/linux/genalloc.h
> @@ -36,6 +36,10 @@ struct gen_pool {
> spinlock_t lock;
> struct list_head chunks;/* list of chunks in this pool */
> int min_alloc_order;/* minimum allocation order */
> +
> + unsigned long (*algo)(unsigned long *, unsigned long,
> + unsigned long, unsigned int, void *);
> + void *data;
> };
>
> /*
> @@ -78,4 +82,15 @@ extern void gen_pool_for_each_chunk(struct gen_pool *,
> void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
> extern size_t gen_pool_avail(struct gen_pool *);
> extern size_t gen_pool_size(struct gen_pool *);
> +
> +extern void gen_pool_set_algo(struct gen_pool *,
> + unsigned long (*)(unsigned long *, unsigned long, unsigned long,
> + unsigned int, void *), void *);
> +
> +extern unsigned long gen_pool_first_fit(unsigned long *, unsigned long,
> + unsigned long, unsigned int, void *);
> +
> +extern unsigned long gen_pool_best_fit(unsigned long *, unsigned long,
> + unsigned long, unsigned int, void *);
> +
> #endif /* __GENALLOC_H__ */
> diff --git a/lib/genalloc.c b/lib/genalloc.c
> index 6bc04aa..a0d73c8 100644
> --- a/lib/genalloc.c
> +++ b/lib/genalloc.c
> @@ -152,6 +152,8 @@ struct gen_pool *gen_pool_create(int min_alloc_order, int
> nid)
> spin_lock_init(&pool->lock);
> INIT_LIST_HEAD(&pool->chunks);
> pool->min_alloc_order = min_alloc_order;
> + pool->algo = gen_pool_first_fit;
> + pool->data = NULL;
> }
> return pool;
> }
> @@ -255,8 +257,9 @@ EXPORT_SYMBOL(gen_pool_destroy);
> * @size: number of bytes to allocate from the pool
> *
> * Allocate the requested number of bytes from the specified pool.
> - * Uses a first-fit algorithm. Can not be used in NMI handler on
> - * architectures without NMI-safe cmpxchg implementation.
> + * Uses the pool allocation function (with first-fit algorithm by default).
> + * Can not be used in NMI handler on architectures without
> + * NMI-safe cmpxchg implementation.
> */
> unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
> {
> @@ -280,8 +283,8 @@ unsigned long gen_pool_alloc(struct gen_pool *pool,
> size_t size)
>
> end_bit = (chunk->end_addr - chunk->start_addr) >> order;
> retry:
> - start_bit = bitmap_find_next_zero_area(chunk->bits, end_bit,
> -start_bit, nbits, 0);
> + start_bit = pool->algo(chunk->bits, end_bit, start_bit, nbits,
> + pool->data);
> if (start_bit >= end_bit)
> continue;
> remain = bitmap_set_ll(chunk->bits, start_bit, nbits);
> @@ -400,3 +403,78 @@ size_t gen_pool_size(struct gen_pool *pool)
> return size;
> }
> EXPORT_SYMBOL_GPL(gen_pool_size);
> +
> +/**
> + * gen_pool_set_algo - set the allocation algorithm
> + * @pool: pool to change allocation algorithm
> + * @priv: private data to be pass to algorithm function
> + * @algo: custom algorithm function
> + */
> +void gen_pool_set_algo(struct gen_pool *pool,
> + unsigned long (*algo)(unsigned long *map, unsigned long size,
> + unsigned long start, unsigned int nr, void *data), void *data)
> +{
> + rcu_read_lock();
IMHO, you can use pool->lock here. _set_algo need not to be lock-less.
> +
> + pool->algo = algo;
> + if (!pool->algo)
> + pool->algo = gen_pool_first_fit;
Why not check input parameter algo?
> +
> + pool->data = data;
> +
> + rcu_read_unlock();
> +}
> +EXPORT_SYMBOL(gen_pool_set_algo);
[snip]
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
linux-next: manual merge of the hid tree with Linus' tree
Hi Jiri,
Today's linux-next merge of the hid tree got a conflict in
drivers/hid/usbhid/hid-quirks.c between commit 67ddbb3e6568 ("HID: add
NOGET quirk for Eaton Ellipse MAX UPS") from Linus' tree and commit
2843b673d034 ("HID: add quirk for Freescale i.MX28 ROM recovery") from
the hid tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/hid/usbhid/hid-quirks.c
index 991e85c,9af530e..000
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@@ -70,7 -70,7 +70,8 @@@ static const struct hid_blacklist
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2,
HID_QUIRK_NO_INIT_REPORTS },
pgpQCQSeJTpZC.pgp
Description: PGP signature
Re: [signal] WARNING: at kernel/lockdep.c:2623 trace_hardirqs_off_caller()
On Mon, Sep 10, 2012 at 02:13:32AM +0100, Al Viro wrote: > On Mon, Sep 10, 2012 at 09:07:07AM +0800, Fengguang Wu wrote: > > Not sure if it's an unrelated warning, but anyway. > > > > commit: c2865bb326476f031ce7121e876c656cdc12c894 [13/18] x86, um/x86: > > switch to generic sys_execve and kernel_execve > > [commit in experimental-kernel_thread, not one in execve2/for-next/master] > > Again, experimental-kernel_thread is build-only for now. Is there any OK. > regular way to tell your script that it should be either skipped or > only build-tested? The build for the entire branch will be auto skipped if any of its commits has this line in the changelog: Dont-Auto-Build Perhaps we can do a similar Dont-Auto-Boot to skip the boot tests. Or I can simply blacklist any branches matching *experimental* and skip both build/boot tests for them. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/9] Prep work for immutable bio vecs
On Sat, Sep 08, 2012 at 12:41:15PM -0700, Tejun Heo wrote: > Hello, Kent. > > On Fri, Sep 07, 2012 at 03:59:11PM -0700, Kent Overstreet wrote: > > Random assortment of refactoring and trivial cleanups. > > > > Immutable bio vecs and efficient bio splitting require auditing and removing > > pretty much all bi_idx uses, among other things. > > > > The reason is that with immutable bio vecs we can't use the bvec array > > directly; if we have a partially completed bvec, that'll be indicated with a > > field in struct bvec_iter (which gets embedded in struct bio) - > > bi_bvec_done. > > > > bio_for_each_segments() will handle this transparently, so code needs to be > > converted to use it or some other generic accessor. > > > > Also, bio splitting means that when a driver gets a bio, bi_idx and > > bi_bvec_done may both be nonzero. Again, just need to use generic accessors. > > There are three pending patchsets and I don't know how they're > supposed to come together. Please explain on which tree the patches > are based and how they stack and preferably provide a git branch. Both of the new ones depend on the block cleanups series, but they shouldn't depend on each other (bar perhaps some trivial merge conflicts in bio.h) Git repo - block_stuff branch on http://evilpiepirate.org/git/linux-bcache.git/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [signal] WARNING: at kernel/lockdep.c:2623 trace_hardirqs_off_caller()
On Mon, Sep 10, 2012 at 09:07:07AM +0800, Fengguang Wu wrote: > Not sure if it's an unrelated warning, but anyway. > > commit: c2865bb326476f031ce7121e876c656cdc12c894 [13/18] x86, um/x86: switch > to generic sys_execve and kernel_execve [commit in experimental-kernel_thread, not one in execve2/for-next/master] Again, experimental-kernel_thread is build-only for now. Is there any regular way to tell your script that it should be either skipped or only build-tested? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [signal] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
On Mon, Sep 10, 2012 at 08:47:53AM +0800, Fengguang Wu wrote: > Al, > > Something bad happens since the below commit. Because commit [12/18] f411932 > was not tested, it might also be the first bad commit. There's a damn good reason why the branch is called the way it's called ;-) It's missing a lot of kernel_thread() stuff; I'm still not sure if it's worth going that way, but there are some very attractive aspects. Basically, if we had guaranteed that pt_regs instance on the bottom of the stack will _not_ overlap anything for a kernel thread, we can move copying pt_regs into kernel_execve() itself. Which simplifies the hell out of ret_from_kernel_execve() instances... The price is that we need to leave that space aside for kernel threads. It's not _that_ much and kernel threads are generally less stack-hungry than the worst cases of syscalls (note that for userland process in the middle of syscall that pt_regs instance *will* be there, no matter what). FWIW, the plan for that branch is to do the following trick: either split ret_from_kernel_thread away from ret_from_fork, setting the right one to be used at copy_thread() time or make ret_from_fork itself check if it's returning to kernel. Either way, do *not* go through return from syscall in return to kernel case; instead of that, have ret_from_kernel_thread: schedule_tail(); get the function to be called and its argument from regs and call it pass return value to do_exit() (BTW, I'm not at all sure we wouldn't be better off if we took those do_exit() calls into 3--5 places in callbacks; kernel_thread() is really very low-level and has few immediate callers). Of course, such patches would have to go before the ret_from_kernel_execve() ones. Right now this branch is guaranteed to be broken; build testing does make sense, but trying to boot it... Not yet. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] NFS: Remove unnecessary semicolons (fs/nfs/client.c)
From: Yanchuan Nian There are some unnecessary semicolons in function find_nfs_version. Just remove them. Signed-off-by: Yanchuan Nian --- fs/nfs/client.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/nfs/client.c b/fs/nfs/client.c index 9969444..d2e1612 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -93,10 +93,10 @@ static struct nfs_subversion *find_nfs_version(unsigned int version) spin_unlock(&nfs_version_lock); return nfs; } - }; + } spin_unlock(&nfs_version_lock); - return ERR_PTR(-EPROTONOSUPPORT);; + return ERR_PTR(-EPROTONOSUPPORT); } struct nfs_subversion *get_nfs_version(unsigned int version) -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core
On Sun, Sep 02, 2012 at 10:27:29AM +0200, Sebastian Hesselbarth wrote: > there is a v3 of the patch under internal review right now. Sebastian, What is the status of v3? I'd like to get it (and gpio, which depends on this work) in for v3.7, but it's getting close... thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: Make the managed clk functions generically available
On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote: > On Mon, Sep 10, 2012 at 01:15:24AM +0100, Russell King - ARM Linux wrote: > > Note that the patch system doesn't always return error messages anymore > > (it used to do that reliably, but as it's now a favourite target for > > spammers and was creating soo much backscatter, which was then filling > > my mailbox with bounces... that had to change.) > > Hrm, that's not ideal. It'd be nice if it were able to do something > like always reply if there were patch contents, or if it found things > like the KernelVersion line in there. Obviously e-mail is also not time > guaranteed so deciding it's not responded (and then working out why it > did that) is going to be unreliable too. It tries to - if it finds what it thinks is a patch in the right place in the email. If it doesn't think it found a patch then it won't reply. In other words, if you include a patch without a PATCH FOLLOWS or the --- commit message/diffstat break marker preceding it, it will ignore you. > I do recall seeing the patch in the database but it's not showing up any > more so perhaps I was thinking of a different patch. Well, no patch ever gets deleted from the database... the only way even I can do that is to manually issue the SQL. > OK, that's what I'd thought was going on - it was the fact that you'd > just acked the patch rather than asked for it to go to the patch tracker > or something which made me wonder if things had changed. I kind'a forgot because it's been soo long since I took any of those patches... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block: Avoid deadlocks with bio allocation by stacking drivers
On Sat, Sep 08, 2012 at 12:36:41PM -0700, Tejun Heo wrote:
> (Restoring cc list from the previous discussion. Please retain the cc
> list of the people who discussed in the previous postings.)
>
> On Fri, Sep 07, 2012 at 03:12:53PM -0700, Kent Overstreet wrote:
> > But this is tricky and not a generic solution. This patch solves it for
> > all users by inverting the previously described technique. We allocate a
> > rescuer workqueue for each bio_set, and then in the allocation code if
> > there are bios on current->bio_list we would be blocking, we punt them
> > to the rescuer workqueue to be submitted.
>
> It would be great if this explanation can be expanded a bit. Why does
> it make the deadlock condition go away? What are the restrictions -
> e.g. using other mempools for additional per-bio data structure
> wouldn't work, right?
Ok, I'll do that. New patch below.
> > +static void punt_bios_to_rescuer(struct bio_set *bs)
> > +{
> > + struct bio_list punt, nopunt;
> > + struct bio *bio;
> > +
> > + bio_list_init(&punt);
> > + bio_list_init(&nopunt);
> > +
> > + while ((bio = bio_list_pop(current->bio_list)))
> > + bio_list_add(bio->bi_pool == bs ? &punt : &nopunt, bio);
> > +
> > + *current->bio_list = nopunt;
>
> Why this is necessary needs explanation and it's done in rather
> unusual way. I suppose the weirdness is from bio_list API
> restriction?
It's because bio_lists are singly linked, so deleting an entry from the
middle of the list would be a real pain - just much cleaner/simpler to
do it this way.
> > + spin_lock(&bs->rescue_lock);
> > + bio_list_merge(&bs->rescue_list, &punt);
> > + spin_unlock(&bs->rescue_lock);
> > +
> > + queue_work(bs->rescue_workqueue, &bs->rescue_work);
> > +}
> > +
> > /**
> > * bio_alloc_bioset - allocate a bio for I/O
> > * @gfp_mask: the GFP_ mask given to the slab allocator
> > @@ -317,6 +354,7 @@ EXPORT_SYMBOL(bio_reset);
> > */
> > struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set
> > *bs)
> > {
> > + gfp_t saved_gfp = gfp_mask;
> > unsigned front_pad;
> > unsigned inline_vecs;
> > unsigned long idx = BIO_POOL_NONE;
> > @@ -334,13 +372,37 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int
> > nr_iovecs, struct bio_set *bs)
> > front_pad = 0;
> > inline_vecs = nr_iovecs;
> > } else {
> > + /*
> > +* generic_make_request() converts recursion to iteration; this
> > +* means if we're running beneath it, any bios we allocate and
> > +* submit will not be submitted (and thus freed) until after we
> > +* return.
> > +*
> > +* This exposes us to a potential deadlock if we allocate
> > +* multiple bios from the same bio_set() while running
> > +* underneath generic_make_request(). If we were to allocate
> > +* multiple bios (say a stacking block driver that was splitting
> > +* bios), we would deadlock if we exhausted the mempool's
> > +* reserve.
> > +*
> > +* We solve this, and guarantee forward progress, with a rescuer
> > +* workqueue per bio_set. If we go to allocate and there are
> > +* bios on current->bio_list, we first try the allocation
> > +* without __GFP_WAIT; if that fails, we punt those bios we
> > +* would be blocking to the rescuer workqueue before we retry
> > +* with the original gfp_flags.
> > +*/
> > +
> > + if (current->bio_list && !bio_list_empty(current->bio_list))
> > + gfp_mask &= ~__GFP_WAIT;
> > +retry:
> > p = mempool_alloc(bs->bio_pool, gfp_mask);
> > front_pad = bs->front_pad;
> > inline_vecs = BIO_INLINE_VECS;
> > }
>
> Wouldn't the following be better?
>
> p = mempool_alloc(bs->bi_pool, gfp_mask);
> if (unlikely(!p) && gfp_mask != saved_gfp) {
> punt_bios_to_rescuer(bs);
> p = mempool_alloc(bs->bi_pool, saved_gfp);
> }
That'd require duplicating the error handling in two different places -
once for the initial allocation, once for the bvec allocation. And I
really hate that writing code that does
alloc_something()
if (fail) {
alloc_something_again()
}
it just screams ugly to me.
> I really hope the usage restriction (don't mix with mempool) for
> bioset is clearly documented somewhere appropriate.
Good point, I'm adding it to bio_alloc_bioset's documentation.
commit 4edb21e0b749fc098c72edcb4f9abdeca6fc62cd
Author: Kent Overstreet
Date: Sun Sep 9 17:23:29 2012 -0700
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in gen
Re: Question about failure in PCI power-state change
On Fri, 2012-09-07 at 15:48 -0700, Bjorn Helgaas wrote: > +cc Rafael, Huang, linux-pm > > On Fri, Sep 7, 2012 at 3:44 PM, Larry Finger > wrote: > > Hi, > > > > On occasion when I unload and reload driver rtl8192ce, I get the message > > > > "Refused to change power state, currently in D3" Hi, Larry, We fixed a similar issue recently. And the patch has been merged by v3.6-rc5. Can you try v3.6-rc5? Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: Make the managed clk functions generically available
On Mon, Sep 10, 2012 at 01:15:24AM +0100, Russell King - ARM Linux wrote: > On Mon, Sep 10, 2012 at 12:50:59AM +0100, Mark Brown wrote: > > I posted a patch for this (clk: Move devm_ APIs out of clkdev into > > HAVE_CLK) towards the end of the last release cycle and I think reposted > > it since and it had been sent to the patch tracker too (though I can't > > find any record of anything except the submission mail now). It would > > be *really* good to get this merged. > Note that the patch system doesn't always return error messages anymore > (it used to do that reliably, but as it's now a favourite target for > spammers and was creating soo much backscatter, which was then filling > my mailbox with bounces... that had to change.) Hrm, that's not ideal. It'd be nice if it were able to do something like always reply if there were patch contents, or if it found things like the KernelVersion line in there. Obviously e-mail is also not time guaranteed so deciding it's not responded (and then working out why it did that) is going to be unreliable too. I do recall seeing the patch in the database but it's not showing up any more so perhaps I was thinking of a different patch. > > Who's looking after clkdev these days? Mike doesn't seem to take > > patches as he's expecting Russell to take them which was happening for a > > while but I'm not sure that's the case any more, especially given > > Russell's followup here. Due to the patch tracker the usual things for > > following up on unapplied patches don't work terribly well, it's much > > less likely that it's just an oversight there. > Well, in theory I'm the maintainer for clkdev and clk API, so I should > take the patch... OK, that's what I'd thought was going on - it was the fact that you'd just acked the patch rather than asked for it to go to the patch tracker or something which made me wonder if things had changed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: Make the managed clk functions generically available
On Mon, Sep 10, 2012 at 12:50:59AM +0100, Mark Brown wrote: > On Sun, Sep 09, 2012 at 05:01:02PM +0200, Lars-Peter Clausen wrote: > > > The managed clk functions are currently only available when the generic clk > > lookup framework is build. But the managed clk functions are merely wrappers > > around clk_get and clk_put and do not depend on any specifics of the generic > > lookup functions and there are still quite a few custom implementations of > > the > > clk API. So make the managed functions available whenever the clk API is > > implemented. > > > The patch also removes the custom implementation of devm_clk_get for the > > coldfire platform. > > I posted a patch for this (clk: Move devm_ APIs out of clkdev into > HAVE_CLK) towards the end of the last release cycle and I think reposted > it since and it had been sent to the patch tracker too (though I can't > find any record of anything except the submission mail now). It would > be *really* good to get this merged. Note that the patch system doesn't always return error messages anymore (it used to do that reliably, but as it's now a favourite target for spammers and was creating soo much backscatter, which was then filling my mailbox with bounces... that had to change.) However, it will always return a message for a patch that it adds to the database, so if you don't get that then it means something went wrong somewhere and you should check to see whether it exists in the database in case it's the emailed response which got lost. Email today still remains an unreliable transmission medium - there is no guarantee that any message sent will get to its destination, and in the same way, there is no guarantee that any acknowledgement (or NDR) will get back to the originator. > Who's looking after clkdev these days? Mike doesn't seem to take > patches as he's expecting Russell to take them which was happening for a > while but I'm not sure that's the case any more, especially given > Russell's followup here. Due to the patch tracker the usual things for > following up on unapplied patches don't work terribly well, it's much > less likely that it's just an oversight there. Well, in theory I'm the maintainer for clkdev and clk API, so I should take the patch... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mmotm 2012-09-06-16-46 uploaded (drivers/video/backlight/lm3639_bl)
Hi Randy. LM3630/9 have the pins for led so these depend on BACKLIGHT_CLASS_DEVICE and I2C. So we need to set LEDS_CLASS and NEW_LEDS. I will put these two into driver/video/backlight/Kconfig file and patch it so that you don't need to do it. 2012년 09월 08일 09:39, Randy Dunlap 쓴 글: On 09/06/2012 04:47 PM, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2012-09-06-16-46 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ on x86_64: ERROR: "led_classdev_register" [drivers/video/backlight/lm3639_bl.ko] undefined! ERROR: "led_classdev_unregister" [drivers/video/backlight/lm3639_bl.ko] undefined! Full randconfig file is attached. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 'msm' tree to linux-next.
Hi David, On Fri, 7 Sep 2012 15:04:04 -0700 David Brown wrote: > > I'd like to add the msm soc tree to Linux next. > > git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git for-next > > I had removed it when the creation of the ARM SoC tree, but now that > msm is getting a bit more active, I'd like to get it included in next > to get it in a bit earlier. Added 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. pgp7jxaaTa9u5.pgp Description: PGP signature
Re: [PATCH] clk: Make the managed clk functions generically available
On Sun, Sep 09, 2012 at 05:01:02PM +0200, Lars-Peter Clausen wrote: > The managed clk functions are currently only available when the generic clk > lookup framework is build. But the managed clk functions are merely wrappers > around clk_get and clk_put and do not depend on any specifics of the generic > lookup functions and there are still quite a few custom implementations of the > clk API. So make the managed functions available whenever the clk API is > implemented. > The patch also removes the custom implementation of devm_clk_get for the > coldfire platform. I posted a patch for this (clk: Move devm_ APIs out of clkdev into HAVE_CLK) towards the end of the last release cycle and I think reposted it since and it had been sent to the patch tracker too (though I can't find any record of anything except the submission mail now). It would be *really* good to get this merged. Who's looking after clkdev these days? Mike doesn't seem to take patches as he's expecting Russell to take them which was happening for a while but I'm not sure that's the case any more, especially given Russell's followup here. Due to the patch tracker the usual things for following up on unapplied patches don't work terribly well, it's much less likely that it's just an oversight there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
