[GIT PULL] pwm: Changes for v3.11-rc1
Hi Linus, The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75: Linux 3.10-rc2 (2013-05-20 14:37:38 -0700) are available in the git repository at: git://gitorious.org/linux-pwm/linux-pwm.git tags/for-3.11-rc1 for you to fetch changes up to b388f15fd14c3ae62deb9a059464aa99b524ea4a: pwm: pwm-tiehrpwm: Use clk_enable/disable instead clk_prepare/unprepare. (2013-06-26 23:23:54 +0200) Thanks, Thierry pwm: Changes for v3.11-rc1 A new driver supports driving PWM signals using the TPU unit found on various Renesas SoCs. Furthermore support is added for the NXP PCA9685 LED controller. Another big chunk is the sysfs interface which has been in the works for quite some time. The remaining patches are a random assortment of cleanups and fixes. Axel Lin (2): pwm: renesas-tpu: Add MODULE_ALIAS to make module auto loading work pwm: pca9685: Fix wrong argument to set MODE1_SLEEP bit Boris BREZILLON (1): pwm: atmel-tcb: prepare clk before calling enable Fabio Estevam (1): pwm: mxs: Let device core handle pinctrl H Hartley Sweeten (1): pwm: Add sysfs interface Laurent Pinchart (1): pwm: Add Renesas TPU PWM driver Marek Belisko (1): pwm: pwm-tiehrpwm: Use clk_enable/disable instead clk_prepare/unprepare. Steffen Trumtrar (1): pwm: add pca9685 driver Thierry Reding (2): MAINTAINERS: Update PWM subsystem entry pwm: Fill in missing .owner fields Wei Yongjun (1): pwm: renesas-tpu: fix return value check in tpu_probe() Wolfram Sang (1): pwm: devm: alloc correct pointer size Documentation/ABI/testing/sysfs-class-pwm | 79 .../devicetree/bindings/pwm/nxp,pca9685-pwm.txt| 27 ++ Documentation/pwm.txt | 37 ++ MAINTAINERS| 4 +- drivers/pwm/Kconfig| 23 + drivers/pwm/Makefile | 3 + drivers/pwm/core.c | 29 +- drivers/pwm/pwm-atmel-tcb.c| 5 +- drivers/pwm/pwm-bfin.c | 1 + drivers/pwm/pwm-imx.c | 1 + drivers/pwm/pwm-lpc32xx.c | 1 + drivers/pwm/pwm-mxs.c | 7 +- drivers/pwm/pwm-pca9685.c | 300 + drivers/pwm/pwm-puv3.c | 1 + drivers/pwm/pwm-renesas-tpu.c | 474 + drivers/pwm/pwm-spear.c| 1 + drivers/pwm/pwm-tegra.c| 1 + drivers/pwm/pwm-tiehrpwm.c | 13 +- drivers/pwm/sysfs.c| 352 +++ include/linux/platform_data/pwm-renesas-tpu.h | 16 + include/linux/pwm.h| 29 +- 21 files changed, 1387 insertions(+), 17 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-pwm create mode 100644 Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt create mode 100644 drivers/pwm/pwm-pca9685.c create mode 100644 drivers/pwm/pwm-renesas-tpu.c create mode 100644 drivers/pwm/sysfs.c create mode 100644 include/linux/platform_data/pwm-renesas-tpu.h pgplAwHC0w836.pgp Description: PGP signature
Re: [PATCH v6 3/5] vmcore: Introduce remap_oldmem_pfn_range()
(2013/07/08 23:28), Vivek Goyal wrote:
On Mon, Jul 08, 2013 at 11:28:39AM +0200, Michael Holzheu wrote:
On Mon, 08 Jul 2013 14:32:09 +0900
HATAYAMA Daisuke wrote:
(2013/07/02 4:32), Michael Holzheu wrote:
For zfcpdump we can't map the HSA storage because it is only available
via a read interface. Therefore, for the new vmcore mmap feature we have
introduce a new mechanism to create mappings on demand.
This patch introduces a new architecture function remap_oldmem_pfn_range()
that should be used to create mappings with remap_pfn_range() for oldmem
areas that can be directly mapped. For zfcpdump this is everything besides
of the HSA memory. For the areas that are not mapped by remap_oldmem_pfn_range()
a generic vmcore a new generic vmcore fault handler mmap_vmcore_fault()
is called.
This fault handler is only for s390 specific issue. Other architectures don't
need
this for the time being.
Also, from the same reason, I'm doing this review based on source code only.
I cannot run the fault handler on meaningful system, which is currently s390
only.
You can test the code on other architectures if you do not map anything in
advance.
For example you could just "return 0" in remap_oldmem_pfn_range():
/*
* Architectures may override this function to map oldmem
*/
int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
unsigned long from, unsigned long pfn,
unsigned long size, pgprot_t prot)
{
return 0;
}
In that case for all pages the new mechanism would be used.
I'm also concerned about the fault handler covers a full range of vmcore, which
could hide some kind of mmap() bug that results in page fault.
So, the fault handler should be enclosed by ifdef CONFIG_S390 for the time
being.
I personally do not like that, but if Vivek and you prefer this, of course we
can do that.
What about something like:
#ifdef CONFIG_S390
static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
...
}
#else
static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
BUG();
}
#endif
I personally perfer not to special case it for s390 only and let the
handler be generic.
If there is a bug in remap_old_pfn_range(), only side affect is that
we will fault in the page when it is accessed and that will be slow. BUG()
sounds excessive. At max it could be WARN_ONCE().
In regular cases for x86, this path should not even hit. So special casing
it to detect issues with remap_old_pfn_range() does not sound very good
to me. I would rather leave it as it is and if there are bugs and mmap()
slows down, then somebody needs to debug it.
I agree to WARN_ONCE(). Then, we can notice bug at least if it occurs.
Interface is like this?
[generic]
bool __weak in_valid_fault_range(pgoff_t pgoff)
{
return false;
}
[s390]
bool in_valid_fault_range(pgoff_t pgoff)
{
loff_t offset = pgoff << PAGE_CACHE_SHIFT;
u64 paddr = vmcore_offset_to_paddr(offset);
return paddr < ZFCPDUMP_HSA_SIZE;
}
assuming vmcore_offset_to_paddr() that looks up vmcore_list and returns physical
address corresponding to given offset of vmcore. I guess this could return error
value if there's no entry corresponding to given offset in vmcore_list.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ia64/pci: set mmio decoding on for some host bridge
Hi Bjorn,
Thank you for reviewing this patch. I have created a new one and sent it
out.
And your questions are answered in that new wmail.
Regards
ZhenHua
On 07/09/2013 04:35 AM, Bjorn Helgaas wrote:
On Sun, Jul 7, 2013 at 6:16 PM, Li, Zhen-Hua wrote:
On some IA64 platforms with intel PCI bridge, for example, HP BL890c i2
with Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port,
when kernel tries to disable the mmio decoding on the PCI bridge devices,
kernel may crash.
And in the comment of function quirk_mmio_always_on, it also says:
"But doing so (disable the mmio decoding) may cause problems on host bridge
and perhaps other key system devices"
So, for these PCI bridges, dev->mmio_always_on bit should be set to 1.
Signed-off-by: Li, Zhen-Hua
---
drivers/pci/quirks.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e85d230..24b8024 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -44,6 +44,21 @@ static void quirk_mmio_always_on(struct pci_dev *dev)
DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_BRIDGE_HOST, 8,
quirk_mmio_always_on);
+#ifdef CONFIG_IA64
+/*
+ * On some IA64 platforms, for some intel PCI bridge devices, for example,
+ * the Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port,
+ * disable the mmio decoding on these devices may cause system crash.
+ * So dev->mmio_always_on bit should be set to 1.
+ */
+static void quirk_mmio_on_intel_pcibridge(struct pci_dev *dev)
+{
+ dev->mmio_always_on = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_BRIDGE_PCI, 8, quirk_mmio_on_intel_pcibridge);
+#endif
The changelog and comment suggest an issue specific to Intel
5520/5500/X58, but the patch sets mmio_always_on for *all* PCI
bridges.
It claims to be specific to ia64 (and is only compiled there), but the
chipset is also used for x86. You need to explain why the problem
only affects ia64.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ia64/pci: set mmio decoding on for some host bridge
On some IA64 platforms with intel PCI bridge, for example, HP BL890c i2
with Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port,
when kernel tries to disable the mmio decoding on the PCI bridge devices,
kernel may crash.
And in the comment of function quirk_mmio_always_on, it also says:
"But doing so (disable the mmio decoding) may cause problems on host bridge
and perhaps other key system devices"
So, for this PCI bridge, dev->mmio_always_on bit should be set to 1.
To avoid affecting the use of quirk_mmio_always_on, a new function is created.
Signed-off-by: Li, Zhen-Hua
---
drivers/pci/quirks.c| 17 +
include/linux/pci_ids.h |1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e85d230..665af3e 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -44,6 +44,23 @@ static void quirk_mmio_always_on(struct pci_dev *dev)
DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_BRIDGE_HOST, 8, quirk_mmio_always_on);
+#ifdef CONFIG_IA64
+/*
+ * On some IA64 platforms, for some intel PCI bridge devices, for example,
+ * the Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port,
+ * disable the mmio decoding on this device may cause system crash.
+ * So dev->mmio_always_on bit should be set to 1.
+ */
+static void quirk_mmio_on_intel_pcibridge(struct pci_dev *dev)
+{
+ dev->mmio_always_on = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL,
+ PCI_DEVICE_ID_INTEL_5520_5550_X58,
+ PCI_CLASS_BRIDGE_PCI,
+ 8, quirk_mmio_on_intel_pcibridge);
+#endif
+
/* The Mellanox Tavor device gives false positive parity errors
* Mark this device with a broken_parity_status, to allow
* PCI scanning code to "skip" this now blacklisted device.
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 3bed2e8..d8c60b7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2742,6 +2742,7 @@
#define PCI_DEVICE_ID_INTEL_LYNNFIELD_MC_CH2_RANK_REV2 0x2db2
#define PCI_DEVICE_ID_INTEL_LYNNFIELD_MC_CH2_TC_REV20x2db3
#define PCI_DEVICE_ID_INTEL_82855PM_HB 0x3340
+#define PCI_DEVICE_ID_INTEL_5520_5550_X58 0x3408
#define PCI_DEVICE_ID_INTEL_IOAT_TBG4 0x3429
#define PCI_DEVICE_ID_INTEL_IOAT_TBG5 0x342a
#define PCI_DEVICE_ID_INTEL_IOAT_TBG6 0x342b
--
1.7.10.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 3/8] vfio: add external user support
On 07/09/2013 07:52 AM, Alex Williamson wrote:
> On Sun, 2013-07-07 at 01:07 +1000, Alexey Kardashevskiy wrote:
>> VFIO is designed to be used via ioctls on file descriptors
>> returned by VFIO.
>>
>> However in some situations support for an external user is required.
>> The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to
>> use the existing VFIO groups for exclusive access in real/virtual mode
>> on a host to avoid passing map/unmap requests to the user space which
>> would made things pretty slow.
>>
>> The proposed protocol includes:
>>
>> 1. do normal VFIO init stuff such as opening a new container, attaching
>> group(s) to it, setting an IOMMU driver for a container. When IOMMU is
>> set for a container, all groups in it are considered ready to use by
>> an external user.
>>
>> 2. pass a fd of the group we want to accelerate to KVM. KVM calls
>> vfio_group_get_external_user() to verify if the group is initialized,
>> IOMMU is set for it and increment the container user counter to prevent
>> the VFIO group from disposal prior to KVM exit.
>> The current TCE IOMMU driver marks the whole IOMMU table as busy when
>> IOMMU is set for a container what prevents other DMA users from
>> allocating from it so it is safe to grant user space access to it.
>>
>> 3. KVM calls vfio_external_user_iommu_id() to obtian an IOMMU ID which
>> KVM uses to get an iommu_group struct for later use.
>>
>> 4. When KVM is finished, it calls vfio_group_put_external_user() to
>> release the VFIO group by decrementing the container user counter.
>> Everything gets released.
>>
>> The "vfio: Limit group opens" patch is also required for the consistency.
>>
>> Signed-off-by: Alexey Kardashevskiy
>> ---
>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>> index c488da5..57aa191 100644
>> --- a/drivers/vfio/vfio.c
>> +++ b/drivers/vfio/vfio.c
>> @@ -1370,6 +1370,62 @@ static const struct file_operations vfio_device_fops
>> = {
>> };
>>
>> /**
>> + * External user API, exported by symbols to be linked dynamically.
>> + *
>> + * The protocol includes:
>> + * 1. do normal VFIO init operation:
>> + * - opening a new container;
>> + * - attaching group(s) to it;
>> + * - setting an IOMMU driver for a container.
>> + * When IOMMU is set for a container, all groups in it are
>> + * considered ready to use by an external user.
>> + *
>> + * 2. The user space passed a group fd which we want to accelerate in
>> + * KVM. KVM uses vfio_group_get_external_user() to verify that:
>> + * - the group is initialized;
>> + * - IOMMU is set for it.
>> + * Then vfio_group_get_external_user() increments the container user
>> + * counter to prevent the VFIO group from disposal prior to KVM exit.
>> + *
>> + * 3. KVM calls vfio_external_user_iommu_id() to know an IOMMU ID which
>> + * KVM uses to get an iommu_group struct for later use.
>> + *
>> + * 4. When KVM is finished, it calls vfio_group_put_external_user() to
>> + * release the VFIO group by decrementing the container user counter.
>
> nit, the interface is for any external user, not just kvm.
s/KVM/An external user/ ?
Or add "the description below uses KVM just as an example of an external user"?
>> + */
>> +struct vfio_group *vfio_group_get_external_user(struct file *filep)
>> +{
>> +struct vfio_group *group = filep->private_data;
>> +
>> +if (filep->f_op != _group_fops)
>> +return NULL;
>
> ERR_PTR(-EINVAL)
>
> There also needs to be a vfio_group_get(group) here and put in error
> cases.
Is that because I do not hold a reference to the file anymore?
>> +
>> +if (!atomic_inc_not_zero(>container_users))
>> +return NULL;
>
> ERR_PTR(-EINVAL)
>
>> +
>> +if (!group->container->iommu_driver ||
>> +!vfio_group_viable(group)) {
>> +atomic_dec(>container_users);
>> +return NULL;
>
> ERR_PTR(-EINVAL)
>
>> +}
>> +
>> +return group;
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_group_get_external_user);
>> +
>> +void vfio_group_put_external_user(struct vfio_group *group)
>> +{
>> +vfio_group_try_dissolve_container(group);
>
> And a vfio_group_put(group) here
>
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_group_put_external_user);
>> +
>> +int vfio_external_user_iommu_id(struct vfio_group *group)
>> +{
>> +return iommu_group_id(group->iommu_group);
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_external_user_iommu_id);
>> +
>> +/**
>> * Module/class support
>> */
>> static char *vfio_devnode(struct device *dev, umode_t *mode)
>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>> index ac8d488..24579a0 100644
>> --- a/include/linux/vfio.h
>> +++ b/include/linux/vfio.h
>> @@ -90,4 +90,11 @@ extern void vfio_unregister_iommu_driver(
>> TYPE tmp; \
>> offsetof(TYPE, MEMBER) + sizeof(tmp.MEMBER); }) \
>>
>> +/*
>> + * External user API
>> + */
>> +extern struct vfio_group *vfio_group_get_external_user(struct file *filep);
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
On 7/9/2013 1:14 AM, Sebastian Andrzej Siewior wrote: On 07/08/2013 12:43 PM, George Cherian wrote: This patch series adds phy support for AM335X platform. This patch series is based on Generic PHY framework [1]. This series has - adds dual musb instances support for am335x platform (just for testing) - adds phy-am-usb driver used in AM platforms - adds dt bindings for the phys - removes usb-phy and replaced with generic phy apis in glue layer No, I don't like this all. You did the one thing I tried to avoid while posting my quick-and-dirty phy driver recently: You duplicated a lot of code which can be served by the nop driver and added only power on/power off callbacks. I wanted to add phy wakeup control also, but currently phy_ops dont have an op for wkup_ctrl Kishon, Can we add one? In numbers: 7 files changed, 316 insertions(+), 70 deletions(-) vs 2 files changed, 117 insertions, 12 deletions I assumed you had also the OTG callbacks (set host/device mode) and wake up but I don't see it there. Adding a power regulator would do the same job, wouldn't it? If the phy driver remains just doing power on/off I suggest simply adding a power regulator. If it will do more I would move the am35xx specific bits into a separate file and glue it to the nop driver. What else? The abstraction in device tree is wrong. It remains wrong if add stuff on top to it. Yes definitely , I liked the way you split the device node. Probably I should base on your dt patch and add phy nodes. We need two nodes each one with a glue layer and a musb child node. The instances crap in kernel has to vanish. Same as above I just did it for quick testing (mentioned in the commit log). Also that means your phy nodes are wrong. This is not musb with two ports but two musb instances each with one port. yes true. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6 3/5] vmcore: Introduce remap_oldmem_pfn_range()
(2013/07/08 18:28), Michael Holzheu wrote:
On Mon, 08 Jul 2013 14:32:09 +0900
HATAYAMA Daisuke wrote:
(2013/07/02 4:32), Michael Holzheu wrote:
For zfcpdump we can't map the HSA storage because it is only available
via a read interface. Therefore, for the new vmcore mmap feature we have
introduce a new mechanism to create mappings on demand.
This patch introduces a new architecture function remap_oldmem_pfn_range()
that should be used to create mappings with remap_pfn_range() for oldmem
areas that can be directly mapped. For zfcpdump this is everything besides
of the HSA memory. For the areas that are not mapped by remap_oldmem_pfn_range()
a generic vmcore a new generic vmcore fault handler mmap_vmcore_fault()
is called.
This fault handler is only for s390 specific issue. Other architectures don't
need
this for the time being.
Also, from the same reason, I'm doing this review based on source code only.
I cannot run the fault handler on meaningful system, which is currently s390
only.
You can test the code on other architectures if you do not map anything in
advance.
For example you could just "return 0" in remap_oldmem_pfn_range():
/*
* Architectures may override this function to map oldmem
*/
int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
unsigned long from, unsigned long pfn,
unsigned long size, pgprot_t prot)
{
return 0;
}
In that case for all pages the new mechanism would be used.
I meant without modifying source code at all. You say I need to define some
function.
+static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+{
+ struct address_space *mapping = vma->vm_file->f_mapping;
+ pgoff_t index = vmf->pgoff;
+ struct page *page;
+ loff_t src;
+ char *buf;
+ int rc;
+
You should check where faulting address points to valid range.
If the fault happens on invalid range, return VM_FAULT_SIGBUS.
On s390 case, I think the range except for HSA should be thought of as invalid.
Hmmm, this would require another architecture backend interface. If we get a
fault
for a page outside of the HSA this would be a programming error in our code. Not
sure if we should introduce new architecture interfaces just for sanity checks.
I think you need to introduce the backend interface since it's bug if it
happens.
The current implementation hides such erroneous path due to generic
implementation.
I also don't think it's big change from this version since you have already been
about to introduce several backend interfaces.
+ page = find_or_create_page(mapping, index, GFP_KERNEL);
+ if (!page)
+ return VM_FAULT_OOM;
+ if (!PageUptodate(page)) {
+ src = index << PAGE_CACHE_SHIFT;
src = (loff_t)index << PAGE_CACHE_SHIFT;
loff_t has long long while index has unsigned long.
Ok.
On s390 both might have the same byte length.
On s390x both are 64 bit. On our 32 bit s390 archtecture long long is 64 bit
and unsigned long 32 bit.
Also I prefer offset to src, but this is minor suggestion.
Yes, I agree.
+ buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);
I found page_to_virt() macro.
Looks like page_to_virt() is not usable on most architectures and probably
pfn_to_kaddr(pfn) would be the correct thing here. Unfortunately is also not
defined on s390.
But when I discussed your comment with Martin, we found out that the current
buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);
is not correct on x86. It should be:
buf = __va((page_to_pfn(page) << PAGE_SHIFT));
It seems OK for this.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dell_rbu: Select CONFIG_FW_LOADER_USER_HELPER explicitly
At Tue, 9 Jul 2013 11:15:20 +0800, Ming Lei wrote: > > On Mon, Jul 8, 2013 at 5:05 PM, Takashi Iwai wrote: > > At Sat, 6 Jul 2013 15:30:03 -0700, > > Greg KH wrote: > >> > >> On Sat, Jul 06, 2013 at 06:14:01PM -0400, Dave Jones wrote: > >> > On Tue, Jul 02, 2013 at 07:27:49PM +, Linux Kernel wrote: > >> > > Gitweb: > >> > http://git.kernel.org/linus/;a=commit;h=d05c39ea67f5786a549ac9d672d2951992b658c6 > >> > > Commit: d05c39ea67f5786a549ac9d672d2951992b658c6 > >> > > Parent: a3b2c8c7aa1ca860edcf0b0afa371d9eb2269c3c > >> > > Author: Takashi Iwai > >> > > AuthorDate: Wed May 22 18:28:37 2013 +0200 > >> > > Committer: Greg Kroah-Hartman > >> > > CommitDate: Mon Jun 3 13:57:29 2013 -0700 > >> > > > >> > > dell_rbu: Select CONFIG_FW_LOADER_USER_HELPER explicitly > >> > > > >> > > The usermode helper is mandatory for this driver. > >> > > > >> > > Signed-off-by: Takashi Iwai > >> > > Signed-off-by: Greg Kroah-Hartman > >> > > --- > >> > > drivers/firmware/Kconfig |1 + > >> > > 1 files changed, 1 insertions(+), 0 deletions(-) > >> > > > >> > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > >> > > index 9387630..0747872 100644 > >> > > --- a/drivers/firmware/Kconfig > >> > > +++ b/drivers/firmware/Kconfig > >> > > @@ -64,6 +64,7 @@ config DELL_RBU > >> > > tristate "BIOS update support for DELL systems via sysfs" > >> > > depends on X86 > >> > > select FW_LOADER > >> > > +select FW_LOADER_USER_HELPER > >> > > help > >> > > Say m if you want to have the option of updating the BIOS > >> > for your > >> > > DELL system. Note you need a Dell OpenManage or Dell Update > >> > package (DUP) > >> > > >> > > >> > This is pretty crappy. Now every distro kernel has to have that enabled, > >> > which screws up for eg, the x86 microcode driver. (It takes 1 minute per > >> > cpu > >> > when this is enabled). > >> > >> I'll let you and Takashi battle this one out, for some reason I thought > >> he added it _because_ a distro kernel needed it... > > > > The reason is that dell_rbu driver requires it. Without the kconfig > > option, this driver won't work at all. So, it's a right fix for > > dell_rbu. > > > > AFAIK, the consensus in the kernel side is that this too long fw > > loading time is basically a regression of user-space (udev or > > whatever). There is no change in the kernel behavior. The problem > > must exist even with the older kernels. > > > > But, looking at the development, we can't expect that udev will be > > fixed soon, and this breakage persists already way too long. Maybe a > > better solution is to kill the fallback to udev for normal f/w loading > > (i.e. for distro kernels). > > > > The patch below is an untested quick hack. It adds a new Kconfig and > > a new function request_firmware_via_user_helper(). Distro kernels may > > set CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n for avoiding 60 seconds > > I understand your proposed approach is basically equal to unset DELL_RBU, > don't I? > > Actually if DELL_RBU is set, FW_LOADER_USER_HELPER is still set, and > it won't avoid the fallback to loading from userspace. No, it changes the behavior. The fallback is now checked explicitly via #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK (this is the only place where this kconfig is referred to). The patch isn't great and can be rewritten better, but the idea is to split the fallback behavior (for normal drivers) and the firmware loading that mandates the user-mode helper (for dell_rbu). > > stall for non-existing firmware file access -- as distributions know > > that the firmware files should be placed in the right path. > > > > Thoughts? > > I suggest not to introduce new config options in firmware loader any more, > and the current options are too many already and it is very easy to trigger > build problem, and introduce extra complexity to users at the same time. Yeah, I hate adding a new kconfig, too. But, in this case, I couldn't have other idea for solving in a reasonable amount of change. > About Dave's problem, I think distribution may not trigger it since > cpu microcode > should exist, It doesn't have to exist -- imagine a brand new CPU that is shipped without errata (I guess it's the case Dave hit). > so I am wondering if Dave can disable DELL_RBU to work around > the problem in his system? Or fake a one byte microcode file to fool the > driver? Well, the kernel cannot know whether the microcode f/w exists or not beforehand. It needs to probe. And the probing itself stalls for 60 seconds... > Also looks the problem should be handled inside x86 microcode driver because > the usage is unique in x86 microcode driver. Other drivers either need one > firmware or stop to work without a firmware, but this driver can work > well no matter > the firmware loading is satisfied or not. Not really specific to microcode driver. Other
Re: [PATCH v1 4/4] spi/xilinx: Use of_property_read_u32 for reading value from node
Hi Mark, On 07/08/2013 04:51 PM, Mark Brown wrote: > On Mon, Jul 08, 2013 at 03:29:17PM +0200, Michal Simek wrote: >> It simplifies driver probing. > > Applied, thanks. have you applied this patch? I can't see it in your topic/xilinx branch. https://git.kernel.org/cgit/linux/kernel/git/broonie/spi.git/log/?h=topic/xilinx Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/4] Minor perf build fixes
Hi Ramkumar, On Fri, 5 Jul 2013 15:46:13 +0530, Ramkumar Ramachandra wrote: > Hi, > > After Namhyung's review of the first iteration, I realized that I'd > made a few mistakes. This iteration should be much better. > > [1/4] is the same as before. > > [2/4] is new, and is used in [4/4]. > > [3/4] introduces a util/perf-perl.h to include with #pragma > statements, hence eliminating duplication. It then updates Context.xs > and trace-event-perl.c to use this new header. I prefer the name being "perl.h" and use #include_next as we include the 'util' directory in the compiler search path. Other than that, the change looks good to me. > > Also, notice that feature-tests.mak has not been touched in this > iteration: the Perl check passes without needing the #pragma > statements (although I'm not sure why exactly). I guess it's because FLAGS_PERL_EMBED doesn't contain the usual perf CFLAGS which has -Werror. Thanks, Namhyung > > Thanks. > > Ramkumar Ramachandra (4): > perf/Makefile: do not open-code shell-sq > perf/Perf-Trace-Util: fix broken include in Context.xs > perf: squelch warnings from perl.h to compile-pass > perf/Perf-Trace-Util: regenerate Context.c > > tools/perf/Makefile| 2 +- > tools/perf/config/Makefile | 23 ++- > tools/perf/scripts/perl/Perf-Trace-Util/Context.c | 215 > + > tools/perf/scripts/perl/Perf-Trace-Util/Context.xs | 6 +- > tools/perf/util/perf-perl.h| 10 + > .../perf/util/scripting-engines/trace-event-perl.c | 2 +- > 6 files changed, 199 insertions(+), 59 deletions(-) > create mode 100644 tools/perf/util/perf-perl.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-net: put virtio net header inline with data
On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" writes: > > For small packets we can simplify xmit processing > > by linearizing buffers with the header: > > most packets seem to have enough head room > > we can use for this purpose. > > Since existing hypervisors require that header > > is the first s/g element, we need a feature bit > > for this. > > > > Signed-off-by: Michael S. Tsirkin > > --- > > > > Note: this needs to be applied on top of patch > > defining VIRTIO_F_ANY_LAYOUT - bit to be > > selected by Rusty. > > > > The following patch should work for any definition of > > VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing. > > Rusty, could you please pick a valid bit for VIRTIO_F_ANY_LAYOUT > > and squeeze this patch into 3.11? > > Sorry, it's too late. > > First, I've been a bit lax in sending patches via DaveM, and this is > definitely his territory (ie. more net than virtio). Let's do this: I'll send a patch series, you ack and we see what happens? > Secondly, it needs baking and testing time. > > Cheers, > Rusty. I did some testing on this. But proper testing just isn't happening out of tree. -- 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 v2 2/2] virtio_net: fix race in RX VQ processing
virtio net called virtqueue_enable_cq on RX path after napi_complete, so
with NAPI_STATE_SCHED clear - outside the implicit napi lock.
This violates the requirement to synchronize virtqueue_enable_cq wrt
virtqueue_add_buf. In particular, used event can move backwards,
causing us to lose interrupts.
In a debug build, this can trigger panic within START_USE.
Jason Wang reports that he can trigger the races artificially,
by adding udelay() in virtqueue_enable_cb() after virtio_mb().
However, we must call napi_complete to clear NAPI_STATE_SCHED before
polling the virtqueue for used buffers, otherwise napi_schedule_prep in
a callback will fail, causing us to lose RX events.
To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
set (under napi lock), later call virtqueue_poll with
NAPI_STATE_SCHED clear (outside the lock).
Reported-by: Jason Wang
Tested-by: Jason Wang
Acked-by: Jason Wang
Signed-off-by: Michael S. Tsirkin
---
drivers/net/virtio_net.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5305bd1..27f79dd 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -605,7 +605,7 @@ static int virtnet_poll(struct napi_struct *napi, int
budget)
container_of(napi, struct receive_queue, napi);
struct virtnet_info *vi = rq->vq->vdev->priv;
void *buf;
- unsigned int len, received = 0;
+ unsigned int r, len, received = 0;
again:
while (received < budget &&
@@ -622,8 +622,9 @@ again:
/* Out of packets? */
if (received < budget) {
+ r = virtqueue_enable_cb_prepare(rq->vq);
napi_complete(napi);
- if (unlikely(!virtqueue_enable_cb(rq->vq)) &&
+ if (unlikely(virtqueue_poll(rq->vq, r)) &&
napi_schedule_prep(napi)) {
virtqueue_disable_cb(rq->vq);
__napi_schedule(napi);
--
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 v2 1/2] virtio: support unlocked queue poll
This adds a way to check ring empty state after enable_cb outside any
locks. Will be used by virtio_net.
Note: there's room for more optimization: caller is likely to have a
memory barrier already, which means we might be able to get rid of a
barrier here. Deferring this optimization until we do some
benchmarking.
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_ring.c | 56 ++--
include/linux/virtio.h | 4
2 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 5217baf..37d58f8 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -607,19 +607,21 @@ void virtqueue_disable_cb(struct virtqueue *_vq)
EXPORT_SYMBOL_GPL(virtqueue_disable_cb);
/**
- * virtqueue_enable_cb - restart callbacks after disable_cb.
+ * virtqueue_enable_cb_prepare - restart callbacks after disable_cb
* @vq: the struct virtqueue we're talking about.
*
- * This re-enables callbacks; it returns "false" if there are pending
- * buffers in the queue, to detect a possible race between the driver
- * checking for more work, and enabling callbacks.
+ * This re-enables callbacks; it returns current queue state
+ * in an opaque unsigned value. This value should be later tested by
+ * virtqueue_poll, to detect a possible race between the driver checking for
+ * more work, and enabling callbacks.
*
* Caller must ensure we don't call this with other virtqueue
* operations at the same time (except where noted).
*/
-bool virtqueue_enable_cb(struct virtqueue *_vq)
+unsigned virtqueue_enable_cb_prepare(struct virtqueue *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
+ u16 last_used_idx;
START_USE(vq);
@@ -629,15 +631,45 @@ bool virtqueue_enable_cb(struct virtqueue *_vq)
* either clear the flags bit or point the event index at the next
* entry. Always do both to keep code simple. */
vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT;
- vring_used_event(>vring) = vq->last_used_idx;
+ vring_used_event(>vring) = last_used_idx = vq->last_used_idx;
+ END_USE(vq);
+ return last_used_idx;
+}
+EXPORT_SYMBOL_GPL(virtqueue_enable_cb_prepare);
+
+/**
+ * virtqueue_poll - query pending used buffers
+ * @vq: the struct virtqueue we're talking about.
+ * @last_used_idx: virtqueue state (from call to virtqueue_enable_cb_prepare).
+ *
+ * Returns "true" if there are pending used buffers in the queue.
+ *
+ * This does not need to be serialized.
+ */
+bool virtqueue_poll(struct virtqueue *_vq, unsigned last_used_idx)
+{
+ struct vring_virtqueue *vq = to_vvq(_vq);
+
virtio_mb(vq->weak_barriers);
- if (unlikely(more_used(vq))) {
- END_USE(vq);
- return false;
- }
+ return (u16)last_used_idx != vq->vring.used->idx;
+}
+EXPORT_SYMBOL_GPL(virtqueue_poll);
- END_USE(vq);
- return true;
+/**
+ * virtqueue_enable_cb - restart callbacks after disable_cb.
+ * @vq: the struct virtqueue we're talking about.
+ *
+ * This re-enables callbacks; it returns "false" if there are pending
+ * buffers in the queue, to detect a possible race between the driver
+ * checking for more work, and enabling callbacks.
+ *
+ * Caller must ensure we don't call this with other virtqueue
+ * operations at the same time (except where noted).
+ */
+bool virtqueue_enable_cb(struct virtqueue *_vq)
+{
+ unsigned last_used_idx = virtqueue_enable_cb_prepare(_vq);
+ return !virtqueue_poll(_vq, last_used_idx);
}
EXPORT_SYMBOL_GPL(virtqueue_enable_cb);
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 9ff8645..72398ee 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -70,6 +70,10 @@ void virtqueue_disable_cb(struct virtqueue *vq);
bool virtqueue_enable_cb(struct virtqueue *vq);
+unsigned virtqueue_enable_cb_prepare(struct virtqueue *vq);
+
+bool virtqueue_poll(struct virtqueue *vq, unsigned);
+
bool virtqueue_enable_cb_delayed(struct virtqueue *vq);
void *virtqueue_detach_unused_buf(struct virtqueue *vq);
--
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 v2 0/2] virtio_net: fix race in RX VQ processing
Jason Wang reported a race in RX VQ processing: virtqueue_enable_cb is called outside napi lock, violating virtio serialization rules. The race has been there from day 1, but it got especially nasty in 3.0 when commit a5c262c5fd83ece01bd649fb08416c501d4c59d7 "virtio_ring: support event idx feature" added more dependency on vq state. Please review, and consider for 3.11 and stable. Changes from v1: - Added Jason's Tested-by tag - minor coding style fix -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib: One less subtraction in binary search iterations.
On Mon, Jul 8, 2013 at 9:12 PM, Joe Perches wrote: >> There is no functional change, but this change eliminates a subtraction that >> the compiler doesn't optimize out (as of gcc 4.7.3). > > That's flatly incorrect. I'm not arguing this. I in fact already acknowledged that the statement is incorrect. > I don't mind if you change it, for just the reason > you wrote, but you still have to now say under what > conditions the test works and when it doesn't. Yes, I'll update and respin the patch as also suggested by Rusty. Thanks for the review. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cris: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from CRIS
architecture code. It's a NOOP since 2.6.35 and it will be removed
one day.
Comments mentioning IRQF_DISABLED are also updated, knowing
that all interrupts are now "fast interrupts", their handlers
running with interrupts disabled.
Don't hesitate to let me know if you have other ways of
rephrasing the comments!
Signed-off-by: Michael Opdenacker
---
arch/cris/arch-v10/drivers/gpio.c | 4 ++--
arch/cris/arch-v10/drivers/sync_serial.c | 4 ++--
arch/cris/arch-v10/kernel/time.c | 6 ++
arch/cris/arch-v32/drivers/mach-a3/gpio.c | 2 +-
arch/cris/arch-v32/drivers/mach-fs/gpio.c | 4 ++--
arch/cris/arch-v32/kernel/fasttimer.c | 2 +-
arch/cris/arch-v32/kernel/irq.c | 10 +-
arch/cris/arch-v32/kernel/smp.c | 2 +-
arch/cris/arch-v32/kernel/time.c | 6 ++
arch/cris/arch-v32/mach-a3/arbiter.c | 4 ++--
arch/cris/arch-v32/mach-fs/arbiter.c | 2 +-
arch/cris/include/arch-v10/arch/irq.h | 6 +++---
arch/cris/include/arch-v32/arch/irq.h | 6 +++---
arch/cris/kernel/irq.c| 3 ---
14 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/arch/cris/arch-v10/drivers/gpio.c
b/arch/cris/arch-v10/drivers/gpio.c
index 609d551..f4374ba 100644
--- a/arch/cris/arch-v10/drivers/gpio.c
+++ b/arch/cris/arch-v10/drivers/gpio.c
@@ -838,13 +838,13 @@ static int __init gpio_init(void)
* in some tests.
*/
res = request_irq(TIMER0_IRQ_NBR, gpio_poll_timer_interrupt,
- IRQF_SHARED | IRQF_DISABLED, "gpio poll", gpio_name);
+ IRQF_SHARED, "gpio poll", gpio_name);
if (res) {
printk(KERN_CRIT "err: timer0 irq for gpio\n");
return res;
}
res = request_irq(PA_IRQ_NBR, gpio_interrupt,
- IRQF_SHARED | IRQF_DISABLED, "gpio PA", gpio_name);
+ IRQF_SHARED, "gpio PA", gpio_name);
if (res)
printk(KERN_CRIT "err: PA irq for gpio\n");
diff --git a/arch/cris/arch-v10/drivers/sync_serial.c
b/arch/cris/arch-v10/drivers/sync_serial.c
index a1c498d..04d39e0 100644
--- a/arch/cris/arch-v10/drivers/sync_serial.c
+++ b/arch/cris/arch-v10/drivers/sync_serial.c
@@ -580,7 +580,7 @@ static int sync_serial_open(struct inode *inode, struct
file *file)
if (port == [0]) {
if (request_irq(8,
manual_interrupt,
- IRQF_SHARED | IRQF_DISABLED,
+ IRQF_SHARED,
"synchronous serial manual irq",
[0])) {
printk(KERN_CRIT "Can't alloc "
@@ -590,7 +590,7 @@ static int sync_serial_open(struct inode *inode, struct
file *file)
} else if (port == [1]) {
if (request_irq(8,
manual_interrupt,
- IRQF_SHARED | IRQF_DISABLED,
+ IRQF_SHARED,
"synchronous serial manual irq",
[1])) {
printk(KERN_CRIT "Can't alloc "
diff --git a/arch/cris/arch-v10/kernel/time.c b/arch/cris/arch-v10/kernel/time.c
index fce7c54..e6a7227 100644
--- a/arch/cris/arch-v10/kernel/time.c
+++ b/arch/cris/arch-v10/kernel/time.c
@@ -178,13 +178,11 @@ timer_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-/* timer is IRQF_SHARED so drivers can add stuff to the timer irq chain
- * it needs to be IRQF_DISABLED to make the jiffies update work properly
- */
+/* timer is IRQF_SHARED so drivers can add stuff to the timer irq chain */
static struct irqaction irq2 = {
.handler = timer_interrupt,
- .flags = IRQF_SHARED | IRQF_DISABLED,
+ .flags = IRQF_SHARED,
.name = "timer",
};
diff --git a/arch/cris/arch-v32/drivers/mach-a3/gpio.c
b/arch/cris/arch-v32/drivers/mach-a3/gpio.c
index 0b86dee..74f9fe8 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/gpio.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/gpio.c
@@ -978,7 +978,7 @@ static int __init gpio_init(void)
CRIS_LED_DISK_WRITE(0);
int res2 = request_irq(GIO_INTR_VECT, gpio_interrupt,
- IRQF_SHARED | IRQF_DISABLED, "gpio", );
+ IRQF_SHARED, "gpio", );
if (res2) {
printk(KERN_ERR "err: irq for gpio\n");
return res2;
diff --git a/arch/cris/arch-v32/drivers/mach-fs/gpio.c
b/arch/cris/arch-v32/drivers/mach-fs/gpio.c
index a2ac091..9e54273 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/gpio.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/gpio.c
@@
RE: [linuxppc-dev] Unbinding device from a driver
> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, July 09, 2013 5:04 AM > To: Gupta Ruchika-R66431 > Cc: linuxppc-...@linux.freescale.net; linux-kernel@vger.kernel.org > Subject: Re: [linuxppc-dev] Unbinding device from a driver > > On 07/04/2013 05:35:28 AM, Gupta Ruchika-R66431 wrote: > > Hi, > > > > > > > > I am trying to unbind a platform device from a driver. Even when the > > remove function of the device returns an EBUSY error, the device is > > unbound from the driver. Is this the right behavior ? Why does kernel > > forcefully unbind the device even if device remove function returns an > > error ? > > From looking at the code, it seems it's not allowed for a driver to refuse > the unbinding. If you can't unbind yet, you need to block until you can > (and take measures to ensure that it won't take too long). > > I don't know the history of why the remove method can return an error even > though nothing seems to check it. > > > root@p4080ds: ls > > > > bind ffe301000.jr ffe302000.jr ffe303000.jr ffe304000.jr uevent > > unbind > > > > > > > > root@p4080ds: echo ffe301000.jr > unbind > > > > In caam_jr_remove > > > > caam_jr ffe301000.jr: Device Busy > > Is the caam_jr driver printing this, or the device model infrastructure? This is being printed by jr driver. Ruchika > > -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
kernel/irq/generic-chip.c between commit 1aa0dd94ca07 ("irqdomain:
Eliminate revmap type") from Linus' tree and commit 002fca5df168
("genirq: generic chip: Use DIV_ROUND_UP to calculate numchips") from the
tip tree.
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 kernel/irq/generic-chip.c
index 10e663a,2f274f3..000
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@@ -275,7 -275,10 +275,7 @@@ int irq_alloc_domain_generic_chips(stru
if (d->gc)
return -EBUSY;
- numchips = d->revmap_size / irqs_per_chip;
- if (d->revmap_type != IRQ_DOMAIN_MAP_LINEAR)
- return -EINVAL;
-
- numchips = DIV_ROUND_UP(d->revmap_data.linear.size, irqs_per_chip);
++ numchips = DIV_ROUND_UP(d->revmap_size, irqs_per_chip);
if (!numchips)
return -EINVAL;
pgp6McMrFph2Y.pgp
Description: PGP signature
Re: [PATCH 0/2] powerpc: allow kvm to use kerel debug framework
Alexander Graf wrote: > > On 04.07.2013, at 08:15, Bharat Bhushan wrote: > > > From: Bharat Bhushan > > > > This patchset moves the debug registers in a structure, which allows > > kvm to use same structure for debug emulation. > > > > Note: Earilier a patchset > > "https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-June/108132.html; > > was sent which is a bunch of six patches. That patchset is divided into two > > parts: > > 1) powerpc specific changes (These 2 patches are actually have those > > changes) > > 2) KVM specific changes (will send separate patch on agraf repository) > > Mikey, if you like those could you please apply the into a topic > branch and get that one merged with Ben? I'd also pull it into my tree > then. benh would pull these directly. I'll have a chat with him to see if he wants my ACK before he does that. Mikey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: footbridge: remove obsolete IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from footbridge
code. It's a NOOP since 2.6.35.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-footbridge/dc21285-timer.c | 2 +-
arch/arm/mach-footbridge/dc21285.c | 10 +-
arch/arm/mach-footbridge/isa-timer.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-footbridge/dc21285-timer.c
b/arch/arm/mach-footbridge/dc21285-timer.c
index 9ee78f7..892d550 100644
--- a/arch/arm/mach-footbridge/dc21285-timer.c
+++ b/arch/arm/mach-footbridge/dc21285-timer.c
@@ -86,7 +86,7 @@ static irqreturn_t timer1_interrupt(int irq, void *dev_id)
static struct irqaction footbridge_timer_irq = {
.name = "dc21285_timer1",
.handler= timer1_interrupt,
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.dev_id = _dc21285,
};
diff --git a/arch/arm/mach-footbridge/dc21285.c
b/arch/arm/mach-footbridge/dc21285.c
index a7cd2cf..d5ad2aa 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -338,15 +338,15 @@ void __init dc21285_preinit(void)
/*
* We don't care if these fail.
*/
- dc21285_request_irq(IRQ_PCI_SERR, dc21285_serr_irq, IRQF_DISABLED,
+ dc21285_request_irq(IRQ_PCI_SERR, dc21285_serr_irq, 0,
"PCI system error", _timer);
- dc21285_request_irq(IRQ_PCI_PERR, dc21285_parity_irq, IRQF_DISABLED,
+ dc21285_request_irq(IRQ_PCI_PERR, dc21285_parity_irq, 0,
"PCI parity error", _timer);
- dc21285_request_irq(IRQ_PCI_ABORT, dc21285_abort_irq, IRQF_DISABLED,
+ dc21285_request_irq(IRQ_PCI_ABORT, dc21285_abort_irq, 0,
"PCI abort", NULL);
- dc21285_request_irq(IRQ_DISCARD_TIMER, dc21285_discard_irq,
IRQF_DISABLED,
+ dc21285_request_irq(IRQ_DISCARD_TIMER, dc21285_discard_irq, 0,
"Discard timer", NULL);
- dc21285_request_irq(IRQ_PCI_DPERR, dc21285_dparity_irq, IRQF_DISABLED,
+ dc21285_request_irq(IRQ_PCI_DPERR, dc21285_dparity_irq, 0,
"PCI data parity", NULL);
if (cfn_mode) {
diff --git a/arch/arm/mach-footbridge/isa-timer.c
b/arch/arm/mach-footbridge/isa-timer.c
index d9301dd..b73f52e 100644
--- a/arch/arm/mach-footbridge/isa-timer.c
+++ b/arch/arm/mach-footbridge/isa-timer.c
@@ -27,7 +27,7 @@ static irqreturn_t pit_timer_interrupt(int irq, void *dev_id)
static struct irqaction pit_timer_irq = {
.name = "pit",
.handler= pit_timer_interrupt,
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.dev_id = _clockevent,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC nohz_full 2/7] nohz_full: Add rcu_dyntick data for scalable detection of all-idle state
From: "Paul E. McKenney"
This commit adds fields to the rcu_dyntick structure that are used to
detect idle CPUs. These new fields differ from the existing ones in
that the existing ones consider a CPU executing in user mode to be idle,
where the new ones consider CPUs executing in user mode to be busy.
The handling of these new fields is otherwise quite similar to that for
the exiting fields. This commit also adds the initialization required
for these fields.
So, why is usermode execution treated differently, with RCU considering
it a quiescent state equivalent to idle, while in contrast the new
full-system idle state detection considers usermode execution to be
non-idle?
It turns out that although one of RCU's quiescent states is usermode
execution, it is not a full-system idle state. This is because the
purpose of the full-system idle state is not RCU, but rather determining
when accurate timekeeping can safely be disabled. Whenever accurate
timekeeping is required in a CONFIG_NO_HZ_FULL kernel, at least one
CPU must keep the scheduling-clock tick going. If even one CPU is
executing in user mode, accurate timekeeping is requires, particularly for
architectures where gettimeofday() and friends do not enter the kernel.
Only when all CPUs are really and truly idle can accurate timekeeping be
disabled, allowing all CPUs to turn off the scheduling clock interrupt,
thus greatly improving energy efficiency.
This naturally raises the question "Why is this code in RCU rather than in
timekeeping?", and the answer is that RCU has the data and infrastructure
to efficiently make this determination.
Signed-off-by: Paul E. McKenney
Cc: Frederic Weisbecker
Cc: Steven Rostedt
---
kernel/rcutree.c| 5 +
kernel/rcutree.h| 9 +
kernel/rcutree_plugin.h | 19 +++
3 files changed, 33 insertions(+)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 78745ae..259e300 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -209,6 +209,10 @@ EXPORT_SYMBOL_GPL(rcu_note_context_switch);
DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
.dynticks_nesting = DYNTICK_TASK_EXIT_IDLE,
.dynticks = ATOMIC_INIT(1),
+#ifdef CONFIG_NO_HZ_FULL_SYSIDLE
+ .dynticks_idle_nesting = DYNTICK_TASK_NEST_VALUE,
+ .dynticks_idle = ATOMIC_INIT(1),
+#endif /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
};
static long blimit = 10; /* Maximum callbacks per rcu_do_batch. */
@@ -2902,6 +2906,7 @@ rcu_init_percpu_data(int cpu, struct rcu_state *rsp, int
preemptible)
rdp->blimit = blimit;
init_callback_list(rdp); /* Re-enable callbacks on this CPU. */
rdp->dynticks->dynticks_nesting = DYNTICK_TASK_EXIT_IDLE;
+ rcu_sysidle_init_percpu_data(rdp->dynticks);
atomic_set(>dynticks->dynticks,
(atomic_read(>dynticks->dynticks) & ~0x1) + 1);
raw_spin_unlock(>lock);/* irqs remain disabled. */
diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index b383258..bd99d59 100644
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@ -88,6 +88,14 @@ struct rcu_dynticks {
/* Process level is worth LLONG_MAX/2. */
int dynticks_nmi_nesting; /* Track NMI nesting level. */
atomic_t dynticks; /* Even value for idle, else odd. */
+#ifdef CONFIG_NO_HZ_FULL_SYSIDLE
+ long long dynticks_idle_nesting;
+ /* irq/process nesting level from idle. */
+ atomic_t dynticks_idle; /* Even value for idle, else odd. */
+ /* "Idle" excludes userspace execution. */
+ unsigned long dynticks_idle_jiffies;
+ /* End of last non-NMI non-idle period. */
+#endif /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
#ifdef CONFIG_RCU_FAST_NO_HZ
bool all_lazy; /* Are all CPU's CBs lazy? */
unsigned long nonlazy_posted;
@@ -545,6 +553,7 @@ static void rcu_boot_init_nocb_percpu_data(struct rcu_data
*rdp);
static void rcu_spawn_nocb_kthreads(struct rcu_state *rsp);
static void rcu_kick_nohz_cpu(int cpu);
static bool init_nocb_callback_list(struct rcu_data *rdp);
+static void rcu_sysidle_init_percpu_data(struct rcu_dynticks *rdtp);
#endif /* #ifndef RCU_TREE_NONCORE */
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 769e12e..6937eb6 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -2375,3 +2375,22 @@ static void rcu_kick_nohz_cpu(int cpu)
smp_send_reschedule(cpu);
#endif /* #ifdef CONFIG_NO_HZ_FULL */
}
+
+
+#ifdef CONFIG_NO_HZ_FULL_SYSIDLE
+
+/*
+ * Initialize dynticks sysidle state for CPUs coming online.
+ */
+static void rcu_sysidle_init_percpu_data(struct rcu_dynticks *rdtp)
+{
+ rdtp->dynticks_idle_nesting = DYNTICK_TASK_NEST_VALUE;
+}
+
+#else /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
+
+static void rcu_sysidle_init_percpu_data(struct rcu_dynticks *rdtp)
+{
+}
+
+#endif
[PATCH RFC nohz_full 6/7] nohz_full: Add full-system-idle state machine
From: "Paul E. McKenney"
This commit adds the state machine that takes the per-CPU idle data
as input and produces a full-system-idle indication as output. This
state machine is driven out of RCU's quiescent-state-forcing
mechanism, which invokes rcu_sysidle_check_cpu() to collect per-CPU
idle state and then rcu_sysidle_report() to drive the state machine.
The full-system-idle state is sampled using rcu_sys_is_idle(), which
also drives the state machine if RCU is idle (and does so by forcing
RCU to become non-idle). This function returns true if all but the
timekeeping CPU (tick_do_timer_cpu) are idle and have been idle long
enough to avoid memory contention on the full_sysidle_state state
variable. The rcu_sysidle_force_exit() may be called externally
to reset the state machine back into non-idle state.
Signed-off-by: Paul E. McKenney
Cc: Frederic Weisbecker
Cc: Steven Rostedt
Conflicts:
kernel/rcutree.h
kernel/rcutree_plugin.h
---
include/linux/rcupdate.h | 18
kernel/rcutree.c | 16 ++-
kernel/rcutree.h | 5 +
kernel/rcutree_plugin.h | 275 ++-
4 files changed, 307 insertions(+), 7 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 48f1ef9..1aa8d8c 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -1011,4 +1011,22 @@ static inline bool rcu_is_nocb_cpu(int cpu) { return
false; }
#endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */
+/* Only for use by adaptive-ticks code. */
+#ifdef CONFIG_NO_HZ_FULL_SYSIDLE
+extern bool rcu_sys_is_idle(void);
+extern void rcu_sysidle_force_exit(void);
+#else /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
+
+static inline bool rcu_sys_is_idle(void)
+{
+ return false;
+}
+
+static inline void rcu_sysidle_force_exit(void)
+{
+}
+
+#endif /* #else #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
+
+
#endif /* __LINUX_RCUPDATE_H */
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 9971f86..06cfd75 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -718,6 +718,7 @@ static int dyntick_save_progress_counter(struct rcu_data
*rdp,
bool *isidle, unsigned long *maxj)
{
rdp->dynticks_snap = atomic_add_return(0, >dynticks->dynticks);
+ rcu_sysidle_check_cpu(rdp, isidle, maxj);
return (rdp->dynticks_snap & 0x1) == 0;
}
@@ -1356,11 +1357,17 @@ int rcu_gp_fqs(struct rcu_state *rsp, int fqs_state_in)
rsp->n_force_qs++;
if (fqs_state == RCU_SAVE_DYNTICK) {
/* Collect dyntick-idle snapshots. */
+ if (is_sysidle_rcu_state(rsp)) {
+ isidle = 1;
+ maxj = jiffies - ULONG_MAX / 4;
+ }
force_qs_rnp(rsp, dyntick_save_progress_counter,
, );
+ rcu_sysidle_report(rsp, isidle, maxj);
fqs_state = RCU_FORCE_QS;
} else {
/* Handle dyntick-idle and offline CPUs. */
+ isidle = 0;
force_qs_rnp(rsp, rcu_implicit_dynticks_qs, , );
}
/* Clear flag to prevent immediate re-entry. */
@@ -2087,9 +2094,12 @@ static void force_qs_rnp(struct rcu_state *rsp,
cpu = rnp->grplo;
bit = 1;
for (; cpu <= rnp->grphi; cpu++, bit <<= 1) {
- if ((rnp->qsmask & bit) != 0 &&
- f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj))
- mask |= bit;
+ if ((rnp->qsmask & bit) != 0) {
+ if ((rnp->qsmaskinit & bit) != 0)
+ *isidle = 0;
+ if (f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj))
+ mask |= bit;
+ }
}
if (mask != 0) {
diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index 1895043..7326a3c 100644
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@ -555,6 +555,11 @@ static void rcu_kick_nohz_cpu(int cpu);
static bool init_nocb_callback_list(struct rcu_data *rdp);
static void rcu_sysidle_enter(struct rcu_dynticks *rdtp, int irq);
static void rcu_sysidle_exit(struct rcu_dynticks *rdtp, int irq);
+static void rcu_sysidle_check_cpu(struct rcu_data *rdp, bool *isidle,
+ unsigned long *maxj);
+static bool is_sysidle_rcu_state(struct rcu_state *rsp);
+static void rcu_sysidle_report(struct rcu_state *rsp, int isidle,
+ unsigned long maxj);
static void rcu_sysidle_init_percpu_data(struct rcu_dynticks *rdtp);
#endif /* #ifndef RCU_TREE_NONCORE */
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 3edae39..b47ffb0 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include "time/tick-internal.h"
Re: [PATCH] lib: One less subtraction in binary search iterations.
On Mon, 2013-07-08 at 20:51 -0700, Wedson Almeida Filho wrote:
> On Sat, Jul 6, 2013 at 9:59 PM, Joe Perches wrote:
> >
> > Not correct.
> >
> >> while (start < end) {
> >> - size_t mid = start + (end - start) / 2;
> >> + size_t mid = (start + end) / 2;
> >
> > size_t start = 0x8000;
> > size_t end = 0x8001;
>
> Good point, they aren't equivalent in all cases.
>
> For the overflow to happen though, we need an array with at least
> N/2+1 entries, where N is the address space size. The array wouldn't
> fit in addressable memory if the element size is greater than 1, so
> this can only really happen when the element size is 1. Even then, it
> would require the kernel range to be greater than half of all
> addressable memory, and allow an allocation taking that much memory. I
> don't know all architectures where linux runs, but I don't think such
> configuration is likely to exist.
Nor do I but that wasn't what you wrote.
> There is no functional change, but this change eliminates a subtraction that
> the compiler doesn't optimize out (as of gcc 4.7.3).
That's flatly incorrect.
I don't mind if you change it, for just the reason
you wrote, but you still have to now say under what
conditions the test works and when it doesn't.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: /sys/module/pcie_aspm/parameters/policy not writable?
On Tue, Jul 09, 2013 at 03:26:11AM +0200, Pavel Machek wrote: > Hi! > > My thinkpad has rather high ping latencies... and perhaps it is due to > PCIE ASPM. Why would that be the problem? The odds that the PCIE bus is the issue seems strange to me. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] f2fs: Modify do_garbage_collect() to collect all the segs in once
Current do_garbage_collect() collect per segment per time. If there are more
than one segments in section, we need to call do_garbage_collect() many times to
collect all the segments(current is a for loop). We can move the loop into the
do_garbage_collect(), so that we can collect all the segs of section in one
time.
Signed-off-by: Gu Zheng
---
fs/f2fs/gc.c | 59 -
1 files changed, 33 insertions(+), 26 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 35f9b1a..ccde9f7 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -634,42 +634,50 @@ static int __get_victim(struct f2fs_sb_info *sbi, unsigned
int *victim,
return ret;
}
-static void do_garbage_collect(struct f2fs_sb_info *sbi, unsigned int segno,
- struct list_head *ilist, int gc_type)
+static void do_garbage_collect(struct f2fs_sb_info *sbi,
+ unsigned int start_segno, struct list_head *ilist, int gc_type)
{
- struct page *sum_page;
- struct f2fs_summary_block *sum;
- struct blk_plug plug;
+ unsigned int segno = start_segno;
- /* read segment summary of victim */
- sum_page = get_sum_page(sbi, segno);
- if (IS_ERR(sum_page))
- return;
+ for (; sbi->segs_per_sec--; segno++) {
+ struct page *sum_page;
+ struct f2fs_summary_block *sum;
+ struct blk_plug plug;
- blk_start_plug();
+ /* read segment summary of victim */
+ sum_page = get_sum_page(sbi, segno);
+ if (IS_ERR(sum_page))
+ continue;
- sum = page_address(sum_page);
+ blk_start_plug();
- switch (GET_SUM_TYPE((>footer))) {
- case SUM_TYPE_NODE:
- gc_node_segment(sbi, sum->entries, segno, gc_type);
- break;
- case SUM_TYPE_DATA:
- gc_data_segment(sbi, sum->entries, ilist, segno, gc_type);
- break;
- }
- blk_finish_plug();
+ sum = page_address(sum_page);
- stat_inc_seg_count(sbi, GET_SUM_TYPE((>footer)));
- stat_inc_call_count(sbi->stat_info);
+ switch (GET_SUM_TYPE((>footer))) {
+ case SUM_TYPE_NODE:
+ gc_node_segment(sbi, sum->entries,
+ segno, gc_type);
+ break;
+ case SUM_TYPE_DATA:
+ gc_data_segment(sbi, sum->entries, ilist,
+ segno, gc_type);
+ break;
+ default:
+ BUG();
+ }
+ blk_finish_plug();
+
+ stat_inc_seg_count(sbi, GET_SUM_TYPE((>footer)));
+ stat_inc_call_count(sbi->stat_info);
- f2fs_put_page(sum_page, 1);
+ f2fs_put_page(sum_page, 1);
+ }
}
int f2fs_gc(struct f2fs_sb_info *sbi)
{
struct list_head ilist;
- unsigned int segno, i;
+ unsigned int segno;
int gc_type = BG_GC;
int nfree = 0;
int ret = -1;
@@ -688,8 +696,7 @@ gc_more:
goto stop;
ret = 0;
- for (i = 0; i < sbi->segs_per_sec; i++)
- do_garbage_collect(sbi, segno + i, , gc_type);
+ do_garbage_collect(sbi, segno, , gc_type);
if (gc_type == FG_GC) {
sbi->cur_victim_sec = NULL_SEGNO;
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] virtio_net: fix race in RX VQ processing
From: "Michael S. Tsirkin" Date: Mon, 8 Jul 2013 12:05:26 +0300 > Jason Wang reported a race in RX VQ processing: > virtqueue_enable_cb is called outside napi lock, > violating virtio serialization rules. > The race has been there from day 1, but it got especially nasty in 3.0 > when commit a5c262c5fd83ece01bd649fb08416c501d4c59d7 > "virtio_ring: support event idx feature" > added more dependency on vq state. > > Please review, and consider for 3.11 and for stable. > > Jason, could you please report whether this fixes the issues for you? Please resubmit with the minor coding style fix and Jason's Acked-by/Tested-by 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] lib: One less subtraction in binary search iterations.
On Sat, Jul 6, 2013 at 9:59 PM, Joe Perches wrote:
>
> Not correct.
>
>> while (start < end) {
>> - size_t mid = start + (end - start) / 2;
>> + size_t mid = (start + end) / 2;
>
> size_t start = 0x8000;
> size_t end = 0x8001;
Good point, they aren't equivalent in all cases.
For the overflow to happen though, we need an array with at least
N/2+1 entries, where N is the address space size. The array wouldn't
fit in addressable memory if the element size is greater than 1, so
this can only really happen when the element size is 1. Even then, it
would require the kernel range to be greater than half of all
addressable memory, and allow an allocation taking that much memory. I
don't know all architectures where linux runs, but I don't think such
configuration is likely to exist.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel/params.c: print failure information instead of 'KOBJ_ADD' to user space, when sysfs_create_file() fails.
When sysfs_create_file() fails, recommend to print the related failure
information. And it is useless to still 'KOBJ_ADD' to user space.
Signed-off-by: Chen Gang
---
kernel/params.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index 440e65d..f5299c1 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -845,7 +845,13 @@ static void __init version_sysfs_builtin(void)
mk = locate_module_kobject(vattr->module_name);
if (mk) {
err = sysfs_create_file(>kobj, >mattr.attr);
- kobject_uevent(>kobj, KOBJ_ADD);
+ if (err)
+ printk(KERN_WARNING
+ "%s (%d): sysfs_create_file fail for %s,
err: %d\n",
+ __FILE__, __LINE__,
+ vattr->module_name, err);
+ else
+ kobject_uevent(>kobj, KOBJ_ADD);
kobject_put(>kobj);
}
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote: > On Tue, 9 Jul 2013, Michael Ellerman wrote: > > > On Thu, Jul 04, 2013 at 02:57:00PM +0200, Peter Zijlstra wrote: > > > > > > Right; I think Stephane and Jiri are in favour of creating a 'new' > > > project that > > > includes just the event definitions in a plain text format and a little > > > library > > > with parser to be used by all interested parties. > > > > OK that would be great. > > > > The part that seems to be missing to make that work is we have no way of > > matching the PMU that appears in /sys with a list of events. > > > > Eg. on my system I have /sys/bus/event_source/devices/cpu - but there's > > nothing in there to identify that it's a Sandy Bridge. > > So something like they have on ARM? > > vince@pandaboard:/sys/bus/event_source/devices$ ls -l > lrwxrwxrwx 1 root root 0 Jul 8 21:57 ARMv7 Cortex-A9 -> > ../../../devices/ARMv7 Cortex-A9 > lrwxrwxrwx 1 root root 0 Jul 8 21:57 breakpoint -> > ../../../devices/breakpoint > lrwxrwxrwx 1 root root 0 Jul 8 21:57 software -> ../../../devices/software > lrwxrwxrwx 1 root root 0 Jul 8 21:57 tracepoint -> > ../../../devices/tracepoint Sort of. I wasn't thinking of using the name, rather adding an attribute with a well defined list of values. > > For the cpu you can obviously just detect what processor you're on with > > cpuid or whatever, but it's a bit of a hack. And that really doesn't > > work for non-cpu PMUs. > > why is it a hack to use cpuid? Because you're assuming that the PMU the kernel has exposed is for the cpu you happen to be executing on. But the real issue is with PMUs that are not in the CPU - there is no easy way for userspace to detect them and determine which event list it should be consulting. > People have done event lists in userspace for years. Why must it be the > kernel's job? This whole thread is about making the event list not the kernel's job? The part that _is_ the kernels job is detecting the hardware and providing an API to access it. What I'm saying is that the kernel API should include some sort of identifier so that userspace can reliably determine the event list to use. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] virtio_net: fix race in RX VQ processing
On 07/08/2013 05:04 PM, Michael S. Tsirkin wrote:
> virtio net called virtqueue_enable_cq on RX path after napi_complete, so
> with NAPI_STATE_SCHED clear - outside the implicit napi lock.
> This violates the requirement to synchronize virtqueue_enable_cq wrt
> virtqueue_add_buf. In particular, used event can move backwards,
> causing us to lose interrupts.
> In a debug build, this can trigger panic within START_USE.
>
> Jason Wang reports that he can trigger the races artificially,
> by adding udelay() in virtqueue_enable_cb() after virtio_mb().
>
> However, we must call napi_complete to clear NAPI_STATE_SCHED before
> polling the virtqueue for used buffers, otherwise napi_schedule_prep in
> a callback will fail, causing us to lose RX events.
>
> To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
> set (under napi lock), later call virtqueue_poll with
> NAPI_STATE_SCHED clear (outside the lock).
>
> Reported-by: Jason Wang
> Signed-off-by: Michael S. Tsirkin
> ---
Tested-by: Jason Wang
Acked-by: Jason Wang
> drivers/net/virtio_net.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 5305bd1..fbdd79a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -622,8 +622,9 @@ again:
>
> /* Out of packets? */
> if (received < budget) {
> + unsigned r = virtqueue_enable_cb_prepare(rq->vq);
> napi_complete(napi);
> - if (unlikely(!virtqueue_enable_cb(rq->vq)) &&
> + if (unlikely(virtqueue_poll(rq->vq, r)) &&
> napi_schedule_prep(napi)) {
> virtqueue_disable_cb(rq->vq);
> __napi_schedule(napi);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio: support unlocked queue poll
On 07/08/2013 05:04 PM, Michael S. Tsirkin wrote:
> This adds a way to check ring empty state after enable_cb outside any
> locks. Will be used by virtio_net.
>
> Note: there's room for more optimization: caller is likely to have a
> memory barrier already, which means we might be able to get rid of a
> barrier here. Deferring this optimization until we do some
> benchmarking.
>
> Signed-off-by: Michael S. Tsirkin
> ---
Tested-by: Jason Wang
Acked-by: Jason Wang
> drivers/virtio/virtio_ring.c | 56
> ++--
> include/linux/virtio.h | 4
> 2 files changed, 48 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 5217baf..37d58f8 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -607,19 +607,21 @@ void virtqueue_disable_cb(struct virtqueue *_vq)
> EXPORT_SYMBOL_GPL(virtqueue_disable_cb);
>
> /**
> - * virtqueue_enable_cb - restart callbacks after disable_cb.
> + * virtqueue_enable_cb_prepare - restart callbacks after disable_cb
> * @vq: the struct virtqueue we're talking about.
> *
> - * This re-enables callbacks; it returns "false" if there are pending
> - * buffers in the queue, to detect a possible race between the driver
> - * checking for more work, and enabling callbacks.
> + * This re-enables callbacks; it returns current queue state
> + * in an opaque unsigned value. This value should be later tested by
> + * virtqueue_poll, to detect a possible race between the driver checking for
> + * more work, and enabling callbacks.
> *
> * Caller must ensure we don't call this with other virtqueue
> * operations at the same time (except where noted).
> */
> -bool virtqueue_enable_cb(struct virtqueue *_vq)
> +unsigned virtqueue_enable_cb_prepare(struct virtqueue *_vq)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
> + u16 last_used_idx;
>
> START_USE(vq);
>
> @@ -629,15 +631,45 @@ bool virtqueue_enable_cb(struct virtqueue *_vq)
>* either clear the flags bit or point the event index at the next
>* entry. Always do both to keep code simple. */
> vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT;
> - vring_used_event(>vring) = vq->last_used_idx;
> + vring_used_event(>vring) = last_used_idx = vq->last_used_idx;
> + END_USE(vq);
> + return last_used_idx;
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_enable_cb_prepare);
> +
> +/**
> + * virtqueue_poll - query pending used buffers
> + * @vq: the struct virtqueue we're talking about.
> + * @last_used_idx: virtqueue state (from call to
> virtqueue_enable_cb_prepare).
> + *
> + * Returns "true" if there are pending used buffers in the queue.
> + *
> + * This does not need to be serialized.
> + */
> +bool virtqueue_poll(struct virtqueue *_vq, unsigned last_used_idx)
> +{
> + struct vring_virtqueue *vq = to_vvq(_vq);
> +
> virtio_mb(vq->weak_barriers);
> - if (unlikely(more_used(vq))) {
> - END_USE(vq);
> - return false;
> - }
> + return (u16)last_used_idx != vq->vring.used->idx;
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_poll);
>
> - END_USE(vq);
> - return true;
> +/**
> + * virtqueue_enable_cb - restart callbacks after disable_cb.
> + * @vq: the struct virtqueue we're talking about.
> + *
> + * This re-enables callbacks; it returns "false" if there are pending
> + * buffers in the queue, to detect a possible race between the driver
> + * checking for more work, and enabling callbacks.
> + *
> + * Caller must ensure we don't call this with other virtqueue
> + * operations at the same time (except where noted).
> + */
> +bool virtqueue_enable_cb(struct virtqueue *_vq)
> +{
> + unsigned last_used_idx = virtqueue_enable_cb_prepare(_vq);
> + return !virtqueue_poll(_vq, last_used_idx);
> }
> EXPORT_SYMBOL_GPL(virtqueue_enable_cb);
>
> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> index 9ff8645..72398ee 100644
> --- a/include/linux/virtio.h
> +++ b/include/linux/virtio.h
> @@ -70,6 +70,10 @@ void virtqueue_disable_cb(struct virtqueue *vq);
>
> bool virtqueue_enable_cb(struct virtqueue *vq);
>
> +unsigned virtqueue_enable_cb_prepare(struct virtqueue *vq);
> +
> +bool virtqueue_poll(struct virtqueue *vq, unsigned);
> +
> bool virtqueue_enable_cb_delayed(struct virtqueue *vq);
>
> void *virtqueue_detach_unused_buf(struct virtqueue *vq);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 vhost tree with the target-updates tree
Hi Nicholas,
On Mon, 08 Jul 2013 18:13:26 -0700 "Nicholas A. Bellinger"
wrote:
>
> On Mon, 2013-07-08 at 13:47 +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the vhost tree got a conflict in
> > drivers/vhost/scsi.c between commit 084ed45b3846 ("vhost/scsi: Convert to
> > se_cmd->cmd_kref TARGET_SCF_ACK_KREF usage") from the target-updates tree
> > and commit 3c63f66a0dcd ("vhost-scsi: Rename struct tcm_vhost_cmd *tv_cmd
> > to *cmd") from the vhost tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> >
>
> Can you briefly refresh my memory how the process of 'carrying the fix'
> in linux-next should work..?
That means that (assuming my fix is correct), I will continue to apply
that fix until your trees are merged into Linus' tree. (git rerere is my
friend :-))
> So once I send a -rc1 PULL request to Linus over the next days, and MST
> sends one shortly there-after and hits a conflict, you'll include this
> patch in a separate next-fixes branch for Linus to PULL..?
No, Linus will figure it out just as I did. If you want to give him a
hint, that 's fine. The main intention of my "I fixed it up and can
carry the fix as necessary (no action is required)" is to just get you
guys to check that what I did was correct, and to dissuade you from
merging/rebasing/rewriting your tree(s) to eliminate the conflict.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp2Ik3MXND3n.pgp
Description: PGP signature
Re: [PATCH 0/2] virtio_net: fix race in RX VQ processing
On 07/08/2013 05:05 PM, Michael S. Tsirkin wrote: > Jason Wang reported a race in RX VQ processing: > virtqueue_enable_cb is called outside napi lock, > violating virtio serialization rules. > The race has been there from day 1, but it got especially nasty in 3.0 > when commit a5c262c5fd83ece01bd649fb08416c501d4c59d7 > "virtio_ring: support event idx feature" > added more dependency on vq state. > > Please review, and consider for 3.11 and for stable. > > Jason, could you please report whether this fixes the issues for you? Yes, I confirm this fixes the issue. Since I can only reproduce it by adding udelay in virtqueue_enable_cb() after virtio_mb(). I validate this also with this. 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: dell_rbu: Select CONFIG_FW_LOADER_USER_HELPER explicitly
On Mon, Jul 8, 2013 at 5:05 PM, Takashi Iwai wrote: > At Sat, 6 Jul 2013 15:30:03 -0700, > Greg KH wrote: >> >> On Sat, Jul 06, 2013 at 06:14:01PM -0400, Dave Jones wrote: >> > On Tue, Jul 02, 2013 at 07:27:49PM +, Linux Kernel wrote: >> > > Gitweb: >> > http://git.kernel.org/linus/;a=commit;h=d05c39ea67f5786a549ac9d672d2951992b658c6 >> > > Commit: d05c39ea67f5786a549ac9d672d2951992b658c6 >> > > Parent: a3b2c8c7aa1ca860edcf0b0afa371d9eb2269c3c >> > > Author: Takashi Iwai >> > > AuthorDate: Wed May 22 18:28:37 2013 +0200 >> > > Committer: Greg Kroah-Hartman >> > > CommitDate: Mon Jun 3 13:57:29 2013 -0700 >> > > >> > > dell_rbu: Select CONFIG_FW_LOADER_USER_HELPER explicitly >> > > >> > > The usermode helper is mandatory for this driver. >> > > >> > > Signed-off-by: Takashi Iwai >> > > Signed-off-by: Greg Kroah-Hartman >> > > --- >> > > drivers/firmware/Kconfig |1 + >> > > 1 files changed, 1 insertions(+), 0 deletions(-) >> > > >> > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig >> > > index 9387630..0747872 100644 >> > > --- a/drivers/firmware/Kconfig >> > > +++ b/drivers/firmware/Kconfig >> > > @@ -64,6 +64,7 @@ config DELL_RBU >> > > tristate "BIOS update support for DELL systems via sysfs" >> > > depends on X86 >> > > select FW_LOADER >> > > +select FW_LOADER_USER_HELPER >> > > help >> > > Say m if you want to have the option of updating the BIOS for >> > your >> > > DELL system. Note you need a Dell OpenManage or Dell Update >> > package (DUP) >> > >> > >> > This is pretty crappy. Now every distro kernel has to have that enabled, >> > which screws up for eg, the x86 microcode driver. (It takes 1 minute per >> > cpu >> > when this is enabled). >> >> I'll let you and Takashi battle this one out, for some reason I thought >> he added it _because_ a distro kernel needed it... > > The reason is that dell_rbu driver requires it. Without the kconfig > option, this driver won't work at all. So, it's a right fix for > dell_rbu. > > AFAIK, the consensus in the kernel side is that this too long fw > loading time is basically a regression of user-space (udev or > whatever). There is no change in the kernel behavior. The problem > must exist even with the older kernels. > > But, looking at the development, we can't expect that udev will be > fixed soon, and this breakage persists already way too long. Maybe a > better solution is to kill the fallback to udev for normal f/w loading > (i.e. for distro kernels). > > The patch below is an untested quick hack. It adds a new Kconfig and > a new function request_firmware_via_user_helper(). Distro kernels may > set CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n for avoiding 60 seconds I understand your proposed approach is basically equal to unset DELL_RBU, don't I? Actually if DELL_RBU is set, FW_LOADER_USER_HELPER is still set, and it won't avoid the fallback to loading from userspace. > stall for non-existing firmware file access -- as distributions know > that the firmware files should be placed in the right path. > > Thoughts? I suggest not to introduce new config options in firmware loader any more, and the current options are too many already and it is very easy to trigger build problem, and introduce extra complexity to users at the same time. About Dave's problem, I think distribution may not trigger it since cpu microcode should exist, so I am wondering if Dave can disable DELL_RBU to work around the problem in his system? Or fake a one byte microcode file to fool the driver? Also looks the problem should be handled inside x86 microcode driver because the usage is unique in x86 microcode driver. Other drivers either need one firmware or stop to work without a firmware, but this driver can work well no matter the firmware loading is satisfied or not. Or could we force dell rbu to use uevent based loading now? thanks -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: ce4100: add head file for reboot type
From: Xiong Zhou Add head file for reboot type stuff to fix this: error: ‘reboot_type’ undeclared (first use in this function) error: ‘BOOT_KBD’ undeclared (first use in this function) Signed-off-by: Xiong Zhou --- arch/x86/platform/ce4100/ce4100.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/platform/ce4100/ce4100.c b/arch/x86/platform/ce4100/ce4100.c index baec704..643b8b5e 100644 --- a/arch/x86/platform/ce4100/ce4100.c +++ b/arch/x86/platform/ce4100/ce4100.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include
Re: [PATCH] btusb: fix overflow return values
On Mon, Jul 08, 2013 at 11:50:54AM -0700, Marcel Holtmann wrote:
> Hi Adam,
>
> > PTR_ERR() returns a long type value, but btusb_setup_intel() and
> > btusb_setup_intel_patching() should return an int type value.
> >
> > This bug makes the judgement "if (ret < 0)" not working on x86_64
> > architecture systems, leading to failure as below, even panic.
> > ...
> > For not affecting other modules, I choose to modify the return values
> > but not extend btusb_setup_intel() and btusb_setup_intel_patching()'s
> > return types. This is harmless, because the return values were only
> > used to comparing number 0.
>
> there are tons of examples in various subsystems and drivers where we
> return PTR_ERR from a function calls returning int.
>
> So I wonder what is actually going wrong here. If this is x86_64
> specific problem with PTR_ERR vs int, then we should have this problem
> everywhere in the kernel.
Hi, Marcel
I see you point, the difference between here and other subsystems are:
1, it returns -PTR_ERR() here but all other places return PTR_ERR(), I
checked.
2, the judgement is "if (ret < 0)" here but other places are "if (ret)".
I'm not saying other subsystems are 100% right, but here, returning
-PTR_ERR() and checking "if (ret < 0)" make the judgement broken much
much more easily.
I attached a testing C file, run it on x86_64, you will see the bug.
PS, about other subsystems, I also think returning PTR_ERR() from a
function calls returning int considered harmful sometimes, will talk
about that in other thread.
Great thanks.
--
Regards,
Adam Lee
Hardware Enablement
#include
static inline long PTR_ERR(const void *ptr)
{
return (long) ptr;
}
int main(int argc, const char *argv[])
{
printf("sizeof(char) = %lu, sizeof(int) = %lu, sizeof(long) = %lu\n\n",
sizeof(char), sizeof(int), sizeof(long));
/*This address is in kernel space, check Documentation/x86/x86_64/mm.txt*/
void *ptr = (void *)0X8900f000;
printf("ptr = %p, PTR_ERR(ptr) = %lx, (int)(-PTR_ERR(ptr)) = %d\n\n",
ptr, PTR_ERR(ptr), (int)(-PTR_ERR(ptr)));
if ((int)(-PTR_ERR(ptr)) < 0)
printf("That's what the codes want.\n");
else
printf("Bug happens!\n");
return 0;
}
Re: [PATCH] sched: smart wake-affine
On 07/09/2013 10:36 AM, Davidlohr Bueso wrote: [snip] >> 2. is the 3.10-rc5 in image also disabled the hyperthreading? > > Yes, I happened to have data already collected for 3.10-rc5. While the > runs with this patch was with -rc7, unless there was some performance > related commit I missed, I don't think the performance difference was > because of that. > >> 3. is the v3 patch set show the same issue? > > Uhmmm shoot, I didn't realize there was a v3, sorry about that. > > /me takes another look at the thread. V3 will reduce the overhead, should make things better, especially when workload is high and platform is big (your box is really what I desired ;-), honestly). And if it is possible, comparison based on the same basement will be better :) Regards, Michael Wang > > Thanks, > Davidlohr > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Mon, 08 Jul 2013 09:38:29 +0300 Eliezer Tamir wrote: > On 08/07/2013 06:14, David Miller wrote: > > From: Linus Torvalds > > Date: Sun, 7 Jul 2013 15:33:31 -0700 > > > >> End result: I think the code is salvageable and people who want this > >> kind of busy-looping can have it. But I really don't want to merge it > >> as-is. I think it was badly done, I think it was badly documented, and > >> I think somebody over-sold the feature by emphasizing the upsides and > >> not the problems. > > > > Fair enough, Eliezer, please address all of Linus's feedback. > > > > It's holding the entire net-next merge up. > > > > OK The feature should also be documented in the Linux manpages, please. A way to do that is to Cc linux-...@vger.kernel.org and Michael Kerrisk , and to work with Michael on developing that documentation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: smart wake-affine
On Tue, 2013-07-09 at 10:30 +0800, Michael Wang wrote: > Hi, Davidlohr > > Thanks for the testing :) > > On 07/09/2013 02:59 AM, Davidlohr Bueso wrote: > [snip] > >> > >> OK, I'll apply the patches, we'll see what happens. If there significant > >> fallout we'll immediately have more information anyway ;-) > > > > So I gave the v2 a spin on my aim7 benchmark on an 80-core 8 socket > > DL980. Not much changed, most numbers are in the noise range, however, > > with HT off, the high_systime workload suffered in throughput with this > > patch with higher concurrency (after 600 users). Image attached. > > To make sure I'm not on the wrong way... HT here means hyperthreading, > correct? Yep :) > > I have some questions like: > 1. how do you disable the hyperthreading? by manual or some other way? Manually, from the BIOS. > 2. is the 3.10-rc5 in image also disabled the hyperthreading? Yes, I happened to have data already collected for 3.10-rc5. While the runs with this patch was with -rc7, unless there was some performance related commit I missed, I don't think the performance difference was because of that. > 3. is the v3 patch set show the same issue? Uhmmm shoot, I didn't realize there was a v3, sorry about that. /me takes another look at the thread. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: smart wake-affine
Hi, Davidlohr Thanks for the testing :) On 07/09/2013 02:59 AM, Davidlohr Bueso wrote: [snip] >> >> OK, I'll apply the patches, we'll see what happens. If there significant >> fallout we'll immediately have more information anyway ;-) > > So I gave the v2 a spin on my aim7 benchmark on an 80-core 8 socket > DL980. Not much changed, most numbers are in the noise range, however, > with HT off, the high_systime workload suffered in throughput with this > patch with higher concurrency (after 600 users). Image attached. To make sure I'm not on the wrong way... HT here means hyperthreading, correct? I have some questions like: 1. how do you disable the hyperthreading? by manual or some other way? 2. is the 3.10-rc5 in image also disabled the hyperthreading? 3. is the v3 patch set show the same issue? Regards, Michael Wang > > Thanks, > Davidlohr > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On 07/07/2013 04:27:54 PM, Linus Torvalds wrote: And dammit, I'd expect the VFS people to be cc'd on changes to the VFS layer functions. I wasn't, Al wasn't. Um, does that mean I should have cc'd you on the initmpfs patch series back before the merge window opened? http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/04204.html (I cc'd the scripts/get_maintainer.pl list, but only one person replied this time around. I got more on the initial RFC submission back in https://lwn.net/Articles/545740/) Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] net: rename low latency sockets functions to busy poll
From: Linus Torvalds Date: Mon, 8 Jul 2013 12:37:06 -0700 > I think it's getting closer, and I'm ok with the last final details > being sorted out later. I just can't reasonably test any of my > suggestions, so I'd like to get it to a point where when I pull, I > don't feel like I'm pulling core code that I really detest. And the > VFS layer in particular I'm pretty attached to. So I've applied Eliezer's rename patch and will send another pull request once he also takes care of the reduction of the number and size of the variables used to track the poll timestamps. 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: Bluez with uclibc
On 07/08/2013 03:06:15 AM, l...@serverphorums.com wrote: Hi, Today, I need to cross compile Bluez for arm with uclibc library into Buildroot environment. However, I meet some dependencies between bluez-utils package and MMU deactivation due to dBus. Do you know a way to use Bluez with uclibc library? Dunno about buildroot, but if you just want to statically link something against uClibc on arm, you could grab either the cross or native "armv5l" compiler from http://landley.net/aboriginal/bin and add its "bin" subdirectory to your $PATH. I just updated that toolchain so it's using the 3.10 headers (yes, with the patch for http://lkml.indiana.edu/hypermail/linux/kernel/1305.2/01452.html the kernel developers never did fix), and it's the last release version of uClibc (from a year and change ago, but that's uClibc for you). As for fixing dependencies beyond "building against uClibc", that's a buildroot question. They have their own mailing list... Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Tue, 9 Jul 2013, Michael Ellerman wrote: > On Thu, Jul 04, 2013 at 02:57:00PM +0200, Peter Zijlstra wrote: > > > > Right; I think Stephane and Jiri are in favour of creating a 'new' project > > that > > includes just the event definitions in a plain text format and a little > > library > > with parser to be used by all interested parties. > > OK that would be great. > > The part that seems to be missing to make that work is we have no way of > matching the PMU that appears in /sys with a list of events. > > Eg. on my system I have /sys/bus/event_source/devices/cpu - but there's > nothing in there to identify that it's a Sandy Bridge. So something like they have on ARM? vince@pandaboard:/sys/bus/event_source/devices$ ls -l lrwxrwxrwx 1 root root 0 Jul 8 21:57 ARMv7 Cortex-A9 -> ../../../devices/ARMv7 Cortex-A9 lrwxrwxrwx 1 root root 0 Jul 8 21:57 breakpoint -> ../../../devices/breakpoint lrwxrwxrwx 1 root root 0 Jul 8 21:57 software -> ../../../devices/software lrwxrwxrwx 1 root root 0 Jul 8 21:57 tracepoint -> ../../../devices/tracepoint > For the cpu you can obviously just detect what processor you're on with > cpuid or whatever, but it's a bit of a hack. And that really doesn't > work for non-cpu PMUs. why is it a hack to use cpuid? People have done event lists in userspace for years. Why must it be the kernel's job? Vince Weaver vincent.wea...@maine.edu http://www.eece.maine.edu/~vweaver/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/vmscan.c: 'lru' may be used without initialized after the patch "3abf380..." in next-20130607 tree
On 07/08/2013 02:43 PM, Chen Gang wrote:
> On 07/05/2013 12:06 PM, Chen Gang wrote:
>> On 06/19/2013 03:19 PM, Chen Gang wrote:
>>> On 06/19/2013 03:10 PM, Andrew Morton wrote:
On Wed, 19 Jun 2013 14:55:13 +0800 Chen Gang wrote:
>>
>> 'lru' may be used without initialized, so need regressing part of the
>> related patch.
>>
>> The related patch:
>> "3abf380 mm: remove lru parameter from __lru_cache_add and
>> lru_cache_add_lru"
>>
>> ...
>>
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -595,6 +595,7 @@ redo:
>> * unevictable page on [in]active list.
>> * We know how to handle that.
>> */
>> +lru = !!TestClearPageActive(page) +
>> page_lru_base_type(page);
>> lru_cache_add(page);
>> } else {
>> /*
That looks right. Why the heck didn't gcc-4.4.4 (at least) warn about it?
>>>
>>> Sorry I don't know either, I find it by reading code, this time.
>>>
>>> It is really necessary to continue analyzing why. In 2nd half of 2013, I
>>> have planned to make some patches outside kernel but related with kernel
>>> (e.g. LTP, gcc patches).
>>>
>>> This kind of issue is a good chance for me to start in 2nd half of 2013
>>> (start from next month).
>>>
>>> So if no others reply for it, I will start analyzing it in the next
>>> month, and plan to finish within a month (before 2013-07-31).
>>>
>>>
>>> Welcome additional suggestions or completions.
>>>
>>> Thanks.
>>>
I create a related bug for it in gcc, please reference:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856
Next, I will communicate about it with gcc guys, if any member is
interested in it, please tracing it in gcc bugzilla (bug57856).
Now, truly end of this thread in kernel mailing list.
Thanks.
>
> Under the gcc which from the source code in svn. it still has this
> issue. I should communicate with gcc mailing list (or their bugzilla)
> for it.
>
> I got gcc source code from svn, "configure && make && make install".
>
> [root@gchenlinux linux-next]# which gcc
> /usr/local/bin/gcc
> [root@gchenlinux linux-next]# gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ./configure
> Thread model: posix
> gcc version 4.9.0 20130704 (experimental) (GCC)
>
>
> I think, this thread is the end under kernel mailing list. ;-)
>
> Thanks.
>
>>
>> Under gcc 4.7.2 20120921 (Red Hat 4.7.2-2) also cause this issue.
>>
>> The root cause is:
>>
>> for putback_lur_page() in mm/vmscan.c for next-20130621 tree.
>> the compiler assumes "lru == LRU_UNEVICTABLE" instead of report warnings
>> (uninitializing lru)
>>
>> The details are below, and the related info and warn are in
>> attachments, please check, thanks.
>>
>> Next, I will compile gcc compiler with the gcc latest code, if also has
>> this issue, I should communicate with gcc mailing list for it.
>>
>> Thanks.
>>
>> --analyzing
>> begin-
>>
>> /* source code in mm/vmscan.c for next-20130621 */
>>
>> 580 void putback_lru_page(struct page *page)
>> 581 {
>> 582 int lru;
>> 583 int was_unevictable = PageUnevictable(page);
>> 584
>> 585 VM_BUG_ON(PageLRU(page));
>> 586
>> 587 redo:
>> 588 ClearPageUnevictable(page);
>> 589
>> 590 if (page_evictable(page)) {
>> 591 /*
>> 592 * For evictable pages, we can use the cache.
>> 593 * In event of a race, worst case is we end up with an
>> 594 * unevictable page on [in]active list.
>> 595 * We know how to handle that.
>> 596 */
>> 597 lru_cache_add(page);
>> 598 } else {
>> 599 /*
>> 600 * Put unevictable pages directly on zone's unevictable
>> 601 * list.
>> 602 */
>> 603 lru = LRU_UNEVICTABLE;
>> 604 add_page_to_unevictable_list(page);
>> 605 /*
>> 606 * When racing with an mlock or AS_UNEVICTABLE clearing
>> 607 * (page is unlocked) make sure that if the other thread
>> 608 * does not observe our setting of PG_lru and fails
>> 609 * isolation/check_move_unevictable_pages,
>> 610 * we see PG_mlocked/AS_UNEVICTABLE cleared below and
>> move
>> 611 * the page back to the evictable list.
>> 612 *
>> 613 * The other side is TestClearPageMlocked() or
>> shmem_lock().
>> 614 */
>> 615 smp_mb();
>> 616 }
>> 617
>> 618 /*
>> 619 * page's status can
Re: [PATCH] virtio-net: put virtio net header inline with data
"Michael S. Tsirkin" writes: > For small packets we can simplify xmit processing > by linearizing buffers with the header: > most packets seem to have enough head room > we can use for this purpose. > Since existing hypervisors require that header > is the first s/g element, we need a feature bit > for this. > > Signed-off-by: Michael S. Tsirkin > --- > > Note: this needs to be applied on top of patch > defining VIRTIO_F_ANY_LAYOUT - bit to be > selected by Rusty. > > The following patch should work for any definition of > VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing. > Rusty, could you please pick a valid bit for VIRTIO_F_ANY_LAYOUT > and squeeze this patch into 3.11? Sorry, it's too late. First, I've been a bit lax in sending patches via DaveM, and this is definitely his territory (ie. more net than virtio). Secondly, it needs baking and testing time. 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: [v3.10 regression] deadlock on cpu hotplug
Hi, Bartlomiej
On 07/08/2013 11:26 PM, Bartlomiej Zolnierkiewicz wrote:
[snip]
>
> # echo 0 > /sys/devices/system/cpu/cpu3/online
> # echo 0 > /sys/devices/system/cpu/cpu2/online
> # echo 0 > /sys/devices/system/cpu/cpu1/online
> # while true;do echo 1 > /sys/devices/system/cpu/cpu1/online;echo 0 >
> /sys/devices/system/cpu/cpu1/online;done
>
> The commit in question (2f7021a8) was merged in v3.10-rc5 as a fix for
> commit 031299b ("cpufreq: governors: Avoid unnecessary per cpu timer
> interrupts") which was causing a kernel warning to show up.
>
> Michael/Viresh: do you have some idea how to fix the issue?
Thanks for the report :) would you like to take a try
on below patch and see whether it solve the issue?
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 5af40ad..aa05eaa 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -229,6 +229,8 @@ static void set_sampling_rate(struct dbs_data *dbs_data,
}
}
+static struct lock_class_key j_cdbs_key;
+
int cpufreq_governor_dbs(struct cpufreq_policy *policy,
struct common_dbs_data *cdata, unsigned int event)
{
@@ -366,6 +368,8 @@ int (struct cpufreq_policy *policy,
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
mutex_init(_cdbs->timer_mutex);
+ lockdep_set_class(_cdbs->timer_mutex, _cdbs_key);
+
INIT_DEFERRABLE_WORK(_cdbs->work,
dbs_data->cdata->gov_dbs_timer);
}
Regards,
Michael Wang
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC nohz_full 7/7] nohz_full: Force RCU's grace-period kthreads onto timekeeping CPU
From: "Paul E. McKenney"
Because RCU's quiescent-state-forcing mechanism is used to drive the
full-system-idle state machine, and because this mechanism is executed
by RCU's grace-period kthreads, this commit forces these kthreads to
run on the timekeeping CPU (tick_do_timer_cpu). To do otherwise would
mean that the RCU grace-period kthreads would force the system into
non-idle state every time they drove the state machine, which would
be just a bit on the futile side.
Signed-off-by: Paul E. McKenney
Cc: Frederic Weisbecker
Cc: Steven Rostedt
---
kernel/rcutree.c| 1 +
kernel/rcutree.h| 1 +
kernel/rcutree_plugin.h | 20 +++-
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 06cfd75..ad9a5ec 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1286,6 +1286,7 @@ static int rcu_gp_init(struct rcu_state *rsp)
struct rcu_data *rdp;
struct rcu_node *rnp = rcu_get_root(rsp);
+ rcu_bind_gp_kthread();
raw_spin_lock_irq(>lock);
rsp->gp_flags = 0; /* Clear all flags: New grace period. */
diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index 7326a3c..1602c21 100644
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@ -558,6 +558,7 @@ static void rcu_sysidle_exit(struct rcu_dynticks *rdtp, int
irq);
static void rcu_sysidle_check_cpu(struct rcu_data *rdp, bool *isidle,
unsigned long *maxj);
static bool is_sysidle_rcu_state(struct rcu_state *rsp);
+static void rcu_bind_gp_kthread(void);
static void rcu_sysidle_report(struct rcu_state *rsp, int isidle,
unsigned long maxj);
static void rcu_sysidle_init_percpu_data(struct rcu_dynticks *rdtp);
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index b47ffb0..a4d44c3 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -2544,7 +2544,7 @@ static void rcu_sysidle_check_cpu(struct rcu_data *rdp,
bool *isidle,
if (!*isidle || rdp->rsp != rcu_sysidle_state ||
cpu_is_offline(rdp->cpu) || rdp->cpu == tick_do_timer_cpu)
return;
- /* WARN_ON_ONCE(smp_processor_id() != tick_do_timer_cpu); */
+ WARN_ON_ONCE(smp_processor_id() != tick_do_timer_cpu);
/* Pick up current idle and NMI-nesting counter and check. */
cur = atomic_read(>dynticks_idle);
@@ -2570,6 +2570,20 @@ static bool is_sysidle_rcu_state(struct rcu_state *rsp)
}
/*
+ * Bind the grace-period kthread for the sysidle flavor of RCU to the
+ * timekeeping CPU.
+ */
+static void rcu_bind_gp_kthread(void)
+{
+ int cpu = ACCESS_ONCE(tick_do_timer_cpu);
+
+ if (cpu < 0 || cpu >= nr_cpu_ids)
+ return;
+ if (raw_smp_processor_id() != cpu)
+ set_cpus_allowed_ptr(current, cpumask_of(cpu));
+}
+
+/*
* Return a delay in jiffies based on the number of CPUs, rcu_node
* leaf fanout, and jiffies tick rate. The idea is to allow larger
* systems more time to transition to full-idle state in order to
@@ -2758,6 +2772,10 @@ static bool is_sysidle_rcu_state(struct rcu_state *rsp)
return false;
}
+static void rcu_bind_gp_kthread(void)
+{
+}
+
static void rcu_sysidle_report(struct rcu_state *rsp, int isidle,
unsigned long maxj)
{
--
1.8.1.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 RFC nohz_full 5/7] nohz_full: Add full-system-idle arguments to API
From: "Paul E. McKenney"
This commit adds an isidle and jiffies argument to force_qs_rnp(),
dyntick_save_progress_counter(), and rcu_implicit_dynticks_qs() to enable
RCU's force-quiescent-state process to check for full-system idle.
Signed-off-by: Paul E. McKenney
Cc: Frederic Weisbecker
Cc: Steven Rostedt
---
kernel/rcutree.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index ed9a36a..9971f86 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -231,7 +231,9 @@ module_param(jiffies_till_next_fqs, ulong, 0644);
static void rcu_start_gp_advanced(struct rcu_state *rsp, struct rcu_node *rnp,
struct rcu_data *rdp);
-static void force_qs_rnp(struct rcu_state *rsp, int (*f)(struct rcu_data *));
+static void force_qs_rnp(struct rcu_state *rsp,
+int (*f)(struct rcu_data *, bool *, unsigned long *),
+bool *isidle, unsigned long *maxj);
static void force_quiescent_state(struct rcu_state *rsp);
static int rcu_pending(int cpu);
@@ -712,7 +714,8 @@ static int rcu_is_cpu_rrupt_from_idle(void)
* credit them with an implicit quiescent state. Return 1 if this CPU
* is in dynticks idle mode, which is an extended quiescent state.
*/
-static int dyntick_save_progress_counter(struct rcu_data *rdp)
+static int dyntick_save_progress_counter(struct rcu_data *rdp,
+bool *isidle, unsigned long *maxj)
{
rdp->dynticks_snap = atomic_add_return(0, >dynticks->dynticks);
return (rdp->dynticks_snap & 0x1) == 0;
@@ -724,7 +727,8 @@ static int dyntick_save_progress_counter(struct rcu_data
*rdp)
* idle state since the last call to dyntick_save_progress_counter()
* for this same CPU, or by virtue of having been offline.
*/
-static int rcu_implicit_dynticks_qs(struct rcu_data *rdp)
+static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
+ bool *isidle, unsigned long *maxj)
{
unsigned int curr;
unsigned int snap;
@@ -1345,16 +1349,19 @@ static int rcu_gp_init(struct rcu_state *rsp)
int rcu_gp_fqs(struct rcu_state *rsp, int fqs_state_in)
{
int fqs_state = fqs_state_in;
+ bool isidle = 0;
+ unsigned long maxj;
struct rcu_node *rnp = rcu_get_root(rsp);
rsp->n_force_qs++;
if (fqs_state == RCU_SAVE_DYNTICK) {
/* Collect dyntick-idle snapshots. */
- force_qs_rnp(rsp, dyntick_save_progress_counter);
+ force_qs_rnp(rsp, dyntick_save_progress_counter,
+, );
fqs_state = RCU_FORCE_QS;
} else {
/* Handle dyntick-idle and offline CPUs. */
- force_qs_rnp(rsp, rcu_implicit_dynticks_qs);
+ force_qs_rnp(rsp, rcu_implicit_dynticks_qs, , );
}
/* Clear flag to prevent immediate re-entry. */
if (ACCESS_ONCE(rsp->gp_flags) & RCU_GP_FLAG_FQS) {
@@ -2055,7 +2062,9 @@ void rcu_check_callbacks(int cpu, int user)
*
* The caller must have suppressed start of new grace periods.
*/
-static void force_qs_rnp(struct rcu_state *rsp, int (*f)(struct rcu_data *))
+static void force_qs_rnp(struct rcu_state *rsp,
+int (*f)(struct rcu_data *, bool *, unsigned long *),
+bool *isidle, unsigned long *maxj)
{
unsigned long bit;
int cpu;
@@ -2079,7 +2088,7 @@ static void force_qs_rnp(struct rcu_state *rsp, int
(*f)(struct rcu_data *))
bit = 1;
for (; cpu <= rnp->grphi; cpu++, bit <<= 1) {
if ((rnp->qsmask & bit) != 0 &&
- f(per_cpu_ptr(rsp->rda, cpu)))
+ f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj))
mask |= bit;
}
if (mask != 0) {
--
1.8.1.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 RFC nohz_full 0/7] v3 Provide infrastructure for full-system idle
Whenever there is at least one non-idle CPU, it is necessary to periodically update timekeeping information. Before NO_HZ_FULL, this updating was carried out by the scheduling-clock tick, which ran on every non-idle CPU. With the advent of NO_HZ_FULL, it is possible to have non-idle CPUs that are not receiving scheduling-clock ticks. This possibility is handled by assigning a timekeeping CPU that continues taking scheduling-clock ticks. Unfortunately, timekeeping CPU continues taking scheduling-clock interrupts even when all other CPUs are completely idle, which is not so good for energy efficiency and battery lifetime. Clearly, it would be good to turn off the timekeeping CPU's scheduling-clock tick when all CPUs are completely idle. This is conceptually simple, but we also need good performance and scalability on large systems, which rules out implementations based on frequently updated global counts of non-idle CPUs as well as implementations that frequently scan all CPUs. Nevertheless, we need a single global indicator in order to keep the overhead of checking acceptably low. The chosen approach is to enforce hysteresis on the non-idle to full-system-idle transition, with the amount of hysteresis increasing linearly with the number of CPUs, thus keeping contention acceptably low. This approach piggybacks on RCU's existing force-quiescent-state scanning of idle CPUs, which has the advantage of avoiding the scan entirely on busy systems that have high levels of multiprogramming. This scan takes per-CPU idleness information and feeds it into a state machine that applies the level of hysteresis required to arrive at a single full-system-idle indicator. The individual patches are as follows: 1. Add a CONFIG_NO_HZ_FULL_SYSIDLE Kconfig parameter to enable this feature. Kernels built with CONFIG_NO_HZ_FULL_SYSIDLE=n act exactly as they do today. 2. Add new fields to the rcu_dynticks structure that track CPU-idle information. These fields consider CPUs running usermode to be non-idle, in contrast with the existing fields in that structure. 3. Track per-CPU idle states. 4. Add full-system idle states and state variables. 5. Expand force_qs_rnp(), dyntick_save_progress_counter(), and rcu_implicit_dynticks_qs() APIs to enable passing full-system idle state information. 6. Add full-system-idle state machine. 7. Force RCU's grace-period kthreads onto the timekeeping CPU. Changes since v2: o Completed removing NMI support (thanks to Frederic for spotting the remaining cruft). o Fix a state-machine bug, again spotted by Frederic. See http://lists-archives.com/linux-kernel/27865835-nohz_full-add-full-system-idle-state-machine.html for the full details of the bug. o Updated commit log and comment as suggested by Josh Triplett. Changes since v1: o Removed NMI support because NMI handlers cannot safely read the time anyway (thanks to Thomas Gleixner and Peter Zijlstra). Thanx, Paul b/include/linux/rcupdate.h | 18 + b/kernel/rcutree.c | 49 - b/kernel/rcutree.h | 17 + b/kernel/rcutree_plugin.h | 421 - b/kernel/time/Kconfig | 23 ++ 5 files changed, 513 insertions(+), 15 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/
[GIT PULL] battery-2.6.git
Hello Linus,
Please pull battery-2.6 git tree to receive changes prepared for the v3.11
release. This time there is nothing exciting in there, just assorted fixes
and cleanups.
Thanks!
Anton
The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:
Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)
are available in the git repository at:
git://git.infradead.org/battery-2.6.git tags/for-v3.11
for you to fetch changes up to 5a6c2208455f25b3e6f939adc2da59aa00d4806e:
charger-manager: Fix regulator_get() return check (2013-06-28 18:37:03 -0700)
Andrew Chew (1):
tps65090-charger: Fix AC detect
Anton Vorontsov (2):
MAINTAINERS: Update email address for Anton Vorontsov
power_supply: Move of_node out of the #ifdef CONFIG_OF
Axel Lin (3):
pm2301_charger: Fix NULL pointer dereference
pm2301_charger: Return error if create_singlethread_workqueue fails
generic-adc-battery: Fix checking if none of the channels are supported
Jingoo Han (10):
88pm860x_battery: Remove unnecessary platform_set_drvdata()
88pm860x_charger: Remove unnecessary platform_set_drvdata()
ab8500_bm: Remove unnecessary platform_set_drvdata()
bq27x00_battery: Remove unnecessary platform_set_drvdata()
gpio-charger: Remove unnecessary platform_set_drvdata()
jz4740-battery: Remove unnecessary platform_set_drvdata()
rx51_battery: Remove unnecessary platform_set_drvdata()
twl4030_charger: Remove unnecessary platform_set_drvdata()
power: Use platform_{get,set}_drvdata()
power_supply: Replace strict_strtoul() with kstrtoul()
Joe Perches (1):
charger-manager: Add missing newlines, fix a couple of typos, add pr_fmt
Jonghwa Lee (2):
charger-manager: Fix a bug when it unregisters notifier block of extcon
charger-manager: Fix regulator_get() return check
Kees Cook (1):
charger-manager: Ensure event is not used as format string
Kim, Milo (1):
lp8727_charger: Support the device tree feature
Pawel Moll (1):
power/reset: Make the vexpress driver optional on arm and arm64
Rhyland Klein (3):
power_supply: Add of_node_put to fix refcount
sbs-battery: Add dt to power_supply struct
tps65090-charger: Add dt node to power_supply
.../bindings/power_supply/lp8727_charger.txt | 44 +++
MAINTAINERS| 8 +-
drivers/power/88pm860x_battery.c | 1 -
drivers/power/88pm860x_charger.c | 1 -
drivers/power/ab8500_btemp.c | 1 -
drivers/power/ab8500_charger.c | 2 -
drivers/power/ab8500_fg.c | 7 +-
drivers/power/abx500_chargalg.c| 1 -
drivers/power/bq27x00_battery.c| 2 -
drivers/power/charger-manager.c| 146 +
drivers/power/generic-adc-battery.c| 4 +-
drivers/power/gpio-charger.c | 2 -
drivers/power/intel_mid_battery.c | 2 +-
drivers/power/jz4740-battery.c | 4 +-
drivers/power/lp8727_charger.c | 68 ++
drivers/power/pcf50633-charger.c | 8 +-
drivers/power/pm2301_charger.c | 11 +-
drivers/power/power_supply_core.c | 4 +
drivers/power/reset/Kconfig| 3 +-
drivers/power/rx51_battery.c | 5 +-
drivers/power/sbs-battery.c| 1 +
drivers/power/tps65090-charger.c | 40 +-
drivers/power/twl4030_charger.c| 2 -
include/linux/power_supply.h | 4 +-
24 files changed, 241 insertions(+), 130 deletions(-)
create mode 100644
Documentation/devicetree/bindings/power_supply/lp8727_charger.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC nohz_full 1/7] nohz_full: Add Kconfig parameter for scalable detection of all-idle state
From: "Paul E. McKenney" At least one CPU must keep the scheduling-clock tick running for timekeeping purposes whenever there is a non-idle CPU. However, with the new nohz_full adaptive-idle machinery, it is difficult to distinguish between all CPUs really being idle as opposed to all non-idle CPUs being in adaptive-ticks mode. This commit therefore adds a Kconfig parameter as a first step towards enabling a scalable detection of full-system idle state. Signed-off-by: Paul E. McKenney Cc: Frederic Weisbecker Cc: Steven Rostedt --- kernel/time/Kconfig | 23 +++ 1 file changed, 23 insertions(+) diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig index 70f27e8..a613c2a 100644 --- a/kernel/time/Kconfig +++ b/kernel/time/Kconfig @@ -134,6 +134,29 @@ config NO_HZ_FULL_ALL Note the boot CPU will still be kept outside the range to handle the timekeeping duty. +config NO_HZ_FULL_SYSIDLE + bool "Detect full-system idle state for full dynticks system" + depends on NO_HZ_FULL + default n + help +At least one CPU must keep the scheduling-clock tick running +for timekeeping purposes whenever there is a non-idle CPU, +where "non-idle" includes CPUs with a single runnable task +in adaptive-idle mode. Because the underlying adaptive-tick +support cannot distinguish between all CPUs being idle and +all CPUs each running a single task in adaptive-idle mode, +the underlying support simply ensures that there is always +a CPU handling the scheduling-clock tick, whether or not all +CPUs are idle. This Kconfig option enables scalable detection +of the all-CPUs-idle state, thus allowing the scheduling-clock +tick to be disabled when all CPUs are idle. Note that scalable +detection of the all-CPUs-idle state means that larger systems +will be slower to declare the all-CPUs-idle state. + +Say Y if you would like to help debug all-CPUs-idle detection. + +Say N if you are unsure. + config NO_HZ bool "Old Idle dynticks config" depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Thu, Jul 04, 2013 at 02:57:00PM +0200, Peter Zijlstra wrote: > On Thu, Jul 04, 2013 at 10:52:18PM +1000, Michael Ellerman wrote: > > I don't think it even needs libpfm4, just some csv files in tools/perf > > would do the trick. > > Right; I think Stephane and Jiri are in favour of creating a 'new' project > that > includes just the event definitions in a plain text format and a little > library > with parser to be used by all interested parties. OK that would be great. The part that seems to be missing to make that work is we have no way of matching the PMU that appears in /sys with a list of events. Eg. on my system I have /sys/bus/event_source/devices/cpu - but there's nothing in there to identify that it's a Sandy Bridge. For the cpu you can obviously just detect what processor you're on with cpuid or whatever, but it's a bit of a hack. And that really doesn't work for non-cpu PMUs. So it seems to me we need to add an attribute to the PMU in sysfs so that we can identify it and match it up with a list of events? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC nohz_full 4/7] nohz_full: Add full-system idle states and variables
From: "Paul E. McKenney" This commit adds control variables and states for full-system idle. The system will progress through the states in numerical order when the system is fully idle (other than the timekeeping CPU), and reset down to the initial state if any non-timekeeping CPU goes non-idle. The current state is kept in full_sysidle_state. A RCU_SYSIDLE_SMALL macro is defined, and systems with this number of CPUs or fewer move through the states more aggressively. The idea is that the resulting memory contention is less of a problem on small systems. Architectures can adjust this value (which defaults to 8) using CONFIG_ARCH_RCU_SYSIDLE_SMALL. One flavor of RCU will be in charge of driving the state machine, defined by rcu_sysidle_state. This should be the busiest flavor of RCU. Signed-off-by: Paul E. McKenney Cc: Frederic Weisbecker Cc: Steven Rostedt --- kernel/rcutree_plugin.h | 28 1 file changed, 28 insertions(+) diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h index 814ff47..3edae39 100644 --- a/kernel/rcutree_plugin.h +++ b/kernel/rcutree_plugin.h @@ -2380,6 +2380,34 @@ static void rcu_kick_nohz_cpu(int cpu) #ifdef CONFIG_NO_HZ_FULL_SYSIDLE /* + * Handle small systems specially, accelerating their transition into + * full idle state. Allow arches to override this code's idea of + * what constitutes a "small" system. + */ +#ifdef CONFIG_ARCH_RCU_SYSIDLE_SMALL +#define RCU_SYSIDLE_SMALL CONFIG_ARCH_RCU_SYSIDLE_SMALL +#else /* #ifdef CONFIG_ARCH_RCU_SYSIDLE_SMALL */ +#define RCU_SYSIDLE_SMALL 8 +#endif + +/* + * Define RCU flavor that holds sysidle state. This needs to be the + * most active flavor of RCU. + */ +#ifdef CONFIG_PREEMPT_RCU +static struct rcu_state __maybe_unused *rcu_sysidle_state = _preempt_state; +#else /* #ifdef CONFIG_PREEMPT_RCU */ +static struct rcu_state __maybe_unused *rcu_sysidle_state = _sched_state; +#endif /* #else #ifdef CONFIG_PREEMPT_RCU */ + +static int __maybe_unused full_sysidle_state; /* Current system-idle state. */ +#define RCU_SYSIDLE_NOT0 /* Some CPU is not idle. */ +#define RCU_SYSIDLE_SHORT 1 /* All CPUs idle for brief period. */ +#define RCU_SYSIDLE_LONG 2 /* All CPUs idle for long enough. */ +#define RCU_SYSIDLE_FULL 3 /* All CPUs idle, ready for sysidle. */ +#define RCU_SYSIDLE_FULL_NOTED 4 /* Actually entered sysidle state. */ + +/* * Invoked to note exit from irq or task transition to idle. Note that * usermode execution does -not- count as idle here! After all, we want * to detect full-system idle states, not RCU quiescent states and grace -- 1.8.1.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/
/sys/module/pcie_aspm/parameters/policy not writable?
Hi! My thinkpad has rather high ping latencies... and perhaps it is due to PCIE ASPM. Its help text says: CONFIG_PCIEASPM: This enables OS control over PCI Express ASPM (Active State Power Management) and Clock Power Management. ASPM supports state L0/L0s/L1. ... ASPM can be disabled or enabled at runtime via /sys/module/pcie_aspm/parameters/policy So I tried setting the parameter, but it seems to be broken :-( root@amd:/data/pavel# cat /sys/module/pcie_aspm/parameters/policy [default] performance powersave root@amd:/data/pavel# echo performance > /sys/module/pcie_aspm/parameters/policy bash: echo: write error: Operation not permitted root@amd:/data/pavel# echo -n performance > /sys/module/pcie_aspm/parameters/policy bash: echo: write error: Operation not permitted root@amd:/data/pavel# ls -al /sys/module/pcie_aspm/parameters/policy -rw-r--r-- 1 root root 4096 Jul 9 03:16 /sys/module/pcie_aspm/parameters/policy root@amd:/data/pavel# cat /sys/module/pcie_aspm/parameters/policy [default] performance powersave root@amd:/data/pavel# echo powersave > /sys/module/pcie_aspm/parameters/policy bash: echo: write error: Operation not permitted root@amd:/data/pavel# echo -n powersave > /sys/module/pcie_aspm/parameters/policy bash: echo: write error: Operation not permitted root@amd:/data/pavel# echo -n default > /sys/module/pcie_aspm/parameters/policy bash: echo: write error: Operation not permitted Hmm: CONFIG_PCIEASPM_DEFAULT=y # CONFIG_PCIEASPM_POWERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set Should we avoid displaying options that can't be selected? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 06/14] coda-fs: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code should be changed to use the new d_count() helper as they shouldn't access its value directly. There is no change in logic and everything should just work. Signed-off-by: Waiman Long --- fs/coda/dir.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/coda/dir.c b/fs/coda/dir.c index 14a1480..190effc 100644 --- a/fs/coda/dir.c +++ b/fs/coda/dir.c @@ -526,7 +526,7 @@ static int coda_dentry_revalidate(struct dentry *de, unsigned int flags) if (cii->c_flags & C_FLUSH) coda_flag_inode_children(inode, C_FLUSH); - if (de->d_count > 1) + if (d_count(de) > 1) /* pretend it's valid, but don't change the flags */ goto out; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 05/14] ceph-fs: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code
should be changed to use the new d_count() helper as they shouldn't
access its value directly. There is no change in logic and everything
should just work.
Signed-off-by: Waiman Long
---
fs/ceph/inode.c |4 ++--
fs/ceph/mds_client.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
index be0f7e2..bd2289a 100644
--- a/fs/ceph/inode.c
+++ b/fs/ceph/inode.c
@@ -903,8 +903,8 @@ static struct dentry *splice_dentry(struct dentry *dn,
struct inode *in,
} else if (realdn) {
dout("dn %p (%d) spliced with %p (%d) "
"inode %p ino %llx.%llx\n",
-dn, dn->d_count,
-realdn, realdn->d_count,
+dn, d_count(dn),
+realdn, d_count(realdn),
realdn->d_inode, ceph_vinop(realdn->d_inode));
dput(dn);
dn = realdn;
diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
index 74fd289..99890b0 100644
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -1553,7 +1553,7 @@ retry:
*base = ceph_ino(temp->d_inode);
*plen = len;
dout("build_path on %p %d built %llx '%.*s'\n",
-dentry, dentry->d_count, *base, len, path);
+dentry, d_count(dentry), *base, len, path);
return path;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 00/14] Lockless update of reference count protected by spinlock
v5->v6: - Add a new GENERIC_SPINLOCK_REFCOUNT config parameter for using the generic implementation. - Add two parameters LOCKREF_WAIT_SHIFT and LOCKREF_RETRY_COUNT which can be specified differently for each architecture. - Update various spinlock_refcount.* files to incorporate review comments. - Replace reference of d_refcount() macro in Lustre filesystem code in the staging tree to use the new d_count() helper function. v4->v5: - Add a d_count() helper for readonly access of reference count and change all references to d_count outside of dcache.c, dcache.h and namei.c to use d_count(). v3->v4: - Replace helper function access to d_lock and d_count by using macros to redefine the old d_lock name to the spinlock and new d_refcount name to the reference count. This greatly reduces the size of this patchset from 25 to 12 and make it easier to review. v2->v3: - Completely revamp the packaging by adding a new lockref data structure that combines the spinlock with the reference count. Helper functions are also added to manipulate the new data structure. That results in modifying over 50 files, but the changes were trivial in most of them. - Change initial spinlock wait to use a timeout. - Force 64-bit alignment of the spinlock & reference count structure. - Add a new way to use the combo by using a new union and helper functions. v1->v2: - Add one more layer of indirection to LOCK_WITH_REFCOUNT macro. - Add __LINUX_SPINLOCK_REFCOUNT_H protection to spinlock_refcount.h. - Add some generic get/put macros into spinlock_refcount.h. This patchset supports a generic mechanism to atomically update a reference count that is protected by a spinlock without actually acquiring the lock itself. If the update doesn't succeeed, the caller will have to acquire the lock and update the reference count in the the old way. This will help in situation where there is a lot of spinlock contention because of frequent reference count update. The d_lock and d_count fields of the struct dentry in dcache.h was modified to use the new lockref data structure and the d_lock name is now a macro to the actual spinlock. The d_count name, however, cannot be reused as it has collision elsewhere in the kernel. So a new d_refcount macro is now used for the reference count and files outside of dcache.c, dcache.h and namei.c are modified to use the d_count() helper function. The various patches were applied and built one-by-one to make sure that there were no broken build. This patch set causes significant performance improvement in the short workload of the AIM7 benchmark on a 8-socket x86-64 machine with 80 cores. patch 1:Introduce the new lockref data structure patch 2:Enable x86 architecture to use the feature patch 3:Introduce the new d_count() helper function patches 4-11: Rename all d_count references to d_count() helper patch 12: Replace d_refcount() macro to d_count() helper patch 13: Rename the d_count field to d_refcount patch 14: Change the dentry structure to use the lockref structure to improve performance for high contention cases Thank to Thomas Gleixner, Andi Kleen and Linus for their valuable input in shaping this patchset. Signed-off-by: Waiman Long Waiman Long (14): spinlock: A new lockref structure for lockless update of refcount spinlock: Enable x86 architecture to do lockless refcount update dcache: Add a new helper function d_count() to return refcount auto-fs: replace direct access of d_count with the d_count() helper ceph-fs: replace direct access of d_count with the d_count() helper coda-fs: replace direct access of d_count with the d_count() helper config-fs: replace direct access of d_count with the d_count() helper ecrypt-fs: replace direct access of d_count with the d_count() helper file locking: replace direct access of d_count with the d_count() helper nfs: replace direct access of d_count with the d_count() helper nilfs2: replace direct access of d_count with the d_count() helper lustre-fs: Use the standard d_count() helper to access refcount dcache: rename d_count field of dentry to d_refcount dcache: Enable lockless update of refcount in dentry structure arch/x86/Kconfig |3 + .../lustre/include/linux/lustre_patchless_compat.h |2 - drivers/staging/lustre/lustre/include/linux/lvfs.h |2 +- drivers/staging/lustre/lustre/llite/dcache.c |8 +- .../staging/lustre/lustre/llite/llite_internal.h |4 +- drivers/staging/lustre/lustre/llite/llite_lib.c|2 +- drivers/staging/lustre/lustre/llite/namei.c|4 +- drivers/staging/lustre/lustre/lvfs/lvfs_linux.c|4 +- fs/autofs4/expire.c|8 +- fs/autofs4/root.c |2 +- fs/ceph/inode.c|4 +-
[PATCH v6 07/14] config-fs: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code
should be changed to use the new d_count() helper as they shouldn't
access its value directly. There is no change in logic and everything
should just work.
Signed-off-by: Waiman Long
---
fs/configfs/dir.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 64e5323..1d75ec5 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -387,7 +387,7 @@ static void remove_dir(struct dentry * d)
if (d->d_inode)
simple_rmdir(parent->d_inode,d);
- pr_debug(" o %s removing done (%d)\n",d->d_name.name, d->d_count);
+ pr_debug(" o %s removing done (%d)\n", d->d_name.name, d_count(d));
dput(parent);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 04/14] auto-fs: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code
should be changed to use the new d_count() helper as they shouldn't
access its value directly. There is no change in logic and everything
should just work.
Signed-off-by: Waiman Long
---
fs/autofs4/expire.c |8
fs/autofs4/root.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index 13ddec9..aac0006 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -109,7 +109,7 @@ cont:
spin_lock_nested(>d_lock, DENTRY_D_LOCK_NESTED);
/* Already gone or negative dentry (under construction) - try next */
- if (q->d_count == 0 || !simple_positive(q)) {
+ if (d_count(q) == 0 || !simple_positive(q)) {
spin_unlock(>d_lock);
next = q->d_u.d_child.next;
goto cont;
@@ -267,7 +267,7 @@ static int autofs4_tree_busy(struct vfsmount *mnt,
else
ino_count++;
- if (p->d_count > ino_count) {
+ if (d_count(p) > ino_count) {
top_ino->last_used = jiffies;
dput(p);
return 1;
@@ -409,7 +409,7 @@ struct dentry *autofs4_expire_indirect(struct super_block
*sb,
if (!exp_leaves) {
/* Path walk currently on this dentry? */
ino_count = atomic_read(>count) + 1;
- if (dentry->d_count > ino_count)
+ if (d_count(dentry) > ino_count)
goto next;
if (!autofs4_tree_busy(mnt, dentry, timeout, do_now)) {
@@ -423,7 +423,7 @@ struct dentry *autofs4_expire_indirect(struct super_block
*sb,
} else {
/* Path walk currently on this dentry? */
ino_count = atomic_read(>count) + 1;
- if (dentry->d_count > ino_count)
+ if (d_count(dentry) > ino_count)
goto next;
expired = autofs4_check_leaves(mnt, dentry, timeout,
do_now);
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index ca8e555..78f9b0a 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -179,7 +179,7 @@ static struct dentry *autofs4_lookup_active(struct dentry
*dentry)
spin_lock(>d_lock);
/* Already gone? */
- if (active->d_count == 0)
+ if (d_count(active) == 0)
goto next;
qstr = >d_name;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 03/14] dcache: Add a new helper function d_count() to return refcount
This patch adds a new helper function d_count() in dcache.h for
returning the current reference count of the dentry object. It
should be used by all the files outside of the core dcache.c and
namei.c files.
Signed-off-by: Waiman Long
---
include/linux/dcache.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index f42dbe1..7c6bbf0 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -258,6 +258,16 @@ extern int have_submounts(struct dentry *);
extern void d_rehash(struct dentry *);
/**
+ * d_count - return the reference count in dentry
+ * @entry: dentry pointer
+ * Returns: current value of reference count
+ */
+static inline unsigned int d_count(struct dentry *entry)
+{
+ return entry->d_count;
+}
+
+/**
* d_add - add dentry to hash queues
* @entry: dentry to add
* @inode: The inode to attach to this dentry
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 08/14] ecrypt-fs: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code should be changed to use the new d_count() helper as they shouldn't access its value directly. There is no change in logic and everything should just work. Signed-off-by: Waiman Long --- fs/ecryptfs/inode.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index a2f2bb2..67e9b63 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -358,7 +358,7 @@ static int ecryptfs_lookup_interpose(struct dentry *dentry, lower_mnt = mntget(ecryptfs_dentry_to_lower_mnt(dentry->d_parent)); fsstack_copy_attr_atime(dir_inode, lower_dentry->d_parent->d_inode); - BUG_ON(!lower_dentry->d_count); + BUG_ON(!d_count(lower_dentry)); ecryptfs_set_dentry_private(dentry, dentry_info); ecryptfs_set_dentry_lower(dentry, lower_dentry); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 13/14] dcache: rename d_count field of dentry to d_refcount
Before converting the d_lock and d_count field of the dentry data
structure to the new lockref structure, we need to consider the
implication of such a change. All current references of d_count and
d_lock have to be changed accordingly.
One way to minimize the changes is to redefine the original field
names as macros to the new names. For d_lock, it is possible to do
so saving a lot of changes as this name is not used anywhere else in
the kernel. For d_count, this is not possible as this name is used
somewhere else in the kernel for different things.
The dcache.c and namei.c files need to change the reference count
value. They will be modified to use a different reference count name
"d_refcount" which is unique in the kernel source code.
Signed-off-by: Waiman Long
---
fs/dcache.c| 54
fs/namei.c |6 ++--
include/linux/dcache.h |8 +++---
3 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 87bdb53..20def64 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -54,7 +54,7 @@
* - d_flags
* - d_name
* - d_lru
- * - d_count
+ * - d_refcount
* - d_unhashed()
* - d_parent and d_subdirs
* - childrens' d_child and d_parent
@@ -229,7 +229,7 @@ static void __d_free(struct rcu_head *head)
*/
static void d_free(struct dentry *dentry)
{
- BUG_ON(dentry->d_count);
+ BUG_ON(dentry->d_refcount);
this_cpu_dec(nr_dentry);
if (dentry->d_op && dentry->d_op->d_release)
dentry->d_op->d_release(dentry);
@@ -467,7 +467,7 @@ relock:
}
if (ref)
- dentry->d_count--;
+ dentry->d_refcount--;
/*
* inform the fs via d_prune that this dentry is about to be
* unhashed and destroyed.
@@ -513,12 +513,12 @@ void dput(struct dentry *dentry)
return;
repeat:
- if (dentry->d_count == 1)
+ if (dentry->d_refcount == 1)
might_sleep();
spin_lock(>d_lock);
- BUG_ON(!dentry->d_count);
- if (dentry->d_count > 1) {
- dentry->d_count--;
+ BUG_ON(!dentry->d_refcount);
+ if (dentry->d_refcount > 1) {
+ dentry->d_refcount--;
spin_unlock(>d_lock);
return;
}
@@ -535,7 +535,7 @@ repeat:
dentry->d_flags |= DCACHE_REFERENCED;
dentry_lru_add(dentry);
- dentry->d_count--;
+ dentry->d_refcount--;
spin_unlock(>d_lock);
return;
@@ -590,7 +590,7 @@ int d_invalidate(struct dentry * dentry)
* We also need to leave mountpoints alone,
* directory or not.
*/
- if (dentry->d_count > 1 && dentry->d_inode) {
+ if (dentry->d_refcount > 1 && dentry->d_inode) {
if (S_ISDIR(dentry->d_inode->i_mode) || d_mountpoint(dentry)) {
spin_unlock(>d_lock);
return -EBUSY;
@@ -606,7 +606,7 @@ EXPORT_SYMBOL(d_invalidate);
/* This must be called with d_lock held */
static inline void __dget_dlock(struct dentry *dentry)
{
- dentry->d_count++;
+ dentry->d_refcount++;
}
static inline void __dget(struct dentry *dentry)
@@ -634,8 +634,8 @@ repeat:
goto repeat;
}
rcu_read_unlock();
- BUG_ON(!ret->d_count);
- ret->d_count++;
+ BUG_ON(!ret->d_refcount);
+ ret->d_refcount++;
spin_unlock(>d_lock);
return ret;
}
@@ -718,7 +718,7 @@ restart:
spin_lock(>i_lock);
hlist_for_each_entry(dentry, >i_dentry, d_alias) {
spin_lock(>d_lock);
- if (!dentry->d_count) {
+ if (!dentry->d_refcount) {
__dget_dlock(dentry);
__d_drop(dentry);
spin_unlock(>d_lock);
@@ -734,7 +734,7 @@ EXPORT_SYMBOL(d_prune_aliases);
/*
* Try to throw away a dentry - free the inode, dput the parent.
- * Requires dentry->d_lock is held, and dentry->d_count == 0.
+ * Requires dentry->d_lock is held, and dentry->d_refcount == 0.
* Releases dentry->d_lock.
*
* This may fail if locks cannot be acquired no problem, just try again.
@@ -764,8 +764,8 @@ static void try_prune_one_dentry(struct dentry *dentry)
dentry = parent;
while (dentry) {
spin_lock(>d_lock);
- if (dentry->d_count > 1) {
- dentry->d_count--;
+ if (dentry->d_refcount > 1) {
+ dentry->d_refcount--;
spin_unlock(>d_lock);
return;
}
@@ -793,7 +793,7 @@ static void shrink_dentry_list(struct list_head *list)
* the LRU because of laziness during lookup. Do not free
* it - just keep it off the LRU list.
*/
- if (dentry->d_count) {
+ if (dentry->d_refcount)
[PATCH v6 10/14] nfs: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code
should be changed to use the new d_count() helper as they shouldn't
access its value directly. There is no change in logic and everything
should just work.
Signed-off-by: Waiman Long
---
fs/nfs/dir.c|6 +++---
fs/nfs/unlink.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index d7ed697..c933bdf 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1721,7 +1721,7 @@ int nfs_unlink(struct inode *dir, struct dentry *dentry)
dir->i_ino, dentry->d_name.name);
spin_lock(>d_lock);
- if (dentry->d_count > 1) {
+ if (d_count(dentry) > 1) {
spin_unlock(>d_lock);
/* Start asynchronous writeout of the inode */
write_inode_now(dentry->d_inode, 0);
@@ -1866,7 +1866,7 @@ int nfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
dfprintk(VFS, "NFS: rename(%s/%s -> %s/%s, ct=%d)\n",
old_dentry->d_parent->d_name.name, old_dentry->d_name.name,
new_dentry->d_parent->d_name.name, new_dentry->d_name.name,
-new_dentry->d_count);
+d_count(new_dentry));
/*
* For non-directories, check whether the target is busy and if so,
@@ -1884,7 +1884,7 @@ int nfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
rehash = new_dentry;
}
- if (new_dentry->d_count > 2) {
+ if (d_count(new_dentry) > 2) {
int err;
/* copy the target dentry's name */
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 1f1f38f..60395ad 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -479,7 +479,7 @@ nfs_sillyrename(struct inode *dir, struct dentry *dentry)
dfprintk(VFS, "NFS: silly-rename(%s/%s, ct=%d)\n",
dentry->d_parent->d_name.name, dentry->d_name.name,
- dentry->d_count);
+ d_count(dentry));
nfs_inc_stats(dir, NFSIOS_SILLYRENAME);
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 09/14] file locking: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code should be changed to use the new d_count() helper as they shouldn't access its value directly. There is no change in logic and everything should just work. Signed-off-by: Waiman Long --- fs/locks.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 04e2c1f..c98e1a1 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1454,7 +1454,7 @@ static int generic_add_lease(struct file *filp, long arg, struct file_lock **flp if ((arg == F_RDLCK) && (atomic_read(>i_writecount) > 0)) goto out; if ((arg == F_WRLCK) - && ((dentry->d_count > 1) + && ((d_count(dentry) > 1) || (atomic_read(>i_count) > 1))) goto out; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 12/14] lustre-fs: Use the standard d_count() helper to access refcount
The Lustre FS should use the newly defined d_count() helper function
to access the dentry's reference count instead of defining its own
d_refcount() macro for the same purpose. Since the current lustre
code is marked as broken, no build test was attempted for this change.
Signed-off-by: Waiman Long
---
.../lustre/include/linux/lustre_patchless_compat.h |2 --
drivers/staging/lustre/lustre/include/linux/lvfs.h |2 +-
drivers/staging/lustre/lustre/llite/dcache.c |8
.../staging/lustre/lustre/llite/llite_internal.h |4 ++--
drivers/staging/lustre/lustre/llite/llite_lib.c|2 +-
drivers/staging/lustre/lustre/llite/namei.c|4 ++--
drivers/staging/lustre/lustre/lvfs/lvfs_linux.c|4 ++--
7 files changed, 12 insertions(+), 14 deletions(-)
diff --git
a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
index f050808..a8e9c0c 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
@@ -60,8 +60,6 @@ truncate_complete_page(struct address_space *mapping, struct
page *page)
ll_delete_from_page_cache(page);
}
-# define d_refcount(d) ((d)->d_count)
-
#ifdef ATTR_OPEN
# define ATTR_FROM_OPEN ATTR_OPEN
#else
diff --git a/drivers/staging/lustre/lustre/include/linux/lvfs.h
b/drivers/staging/lustre/lustre/include/linux/lvfs.h
index b4db6cb..eb59ac7 100644
--- a/drivers/staging/lustre/lustre/include/linux/lvfs.h
+++ b/drivers/staging/lustre/lustre/include/linux/lvfs.h
@@ -99,7 +99,7 @@ static inline void l_dput(struct dentry *de)
if (!de || IS_ERR(de))
return;
//shrink_dcache_parent(de);
- LASSERT(d_refcount(de) > 0);
+ LASSERT(d_count(de) > 0);
dput(de);
}
diff --git a/drivers/staging/lustre/lustre/llite/dcache.c
b/drivers/staging/lustre/lustre/llite/dcache.c
index 7d6abff..ff0d085 100644
--- a/drivers/staging/lustre/lustre/llite/dcache.c
+++ b/drivers/staging/lustre/lustre/llite/dcache.c
@@ -98,7 +98,7 @@ int ll_dcompare(const struct dentry *parent, const struct
inode *pinode,
CDEBUG(D_DENTRY, "found name %.*s(%p) flags %#x refc %d\n",
name->len, name->name, dentry, dentry->d_flags,
- d_refcount(dentry));
+ d_count(dentry));
/* mountpoint is always valid */
if (d_mountpoint((struct dentry *)dentry))
@@ -165,7 +165,7 @@ static int ll_ddelete(const struct dentry *de)
list_empty(>d_subdirs) ? "" : "subdirs");
/* kernel >= 2.6.38 last refcount is decreased after this function. */
- LASSERT(d_refcount(de) == 1);
+ LASSERT(d_count(de) == 1);
/* Disable this piece of code temproarily because this is called
* inside dcache_lock so it's not appropriate to do lots of work
@@ -190,7 +190,7 @@ static int ll_set_dd(struct dentry *de)
CDEBUG(D_DENTRY, "ldd on dentry %.*s (%p) parent %p inode %p refc %d\n",
de->d_name.len, de->d_name.name, de, de->d_parent, de->d_inode,
- d_refcount(de));
+ d_count(de));
if (de->d_fsdata == NULL) {
struct ll_dentry_data *lld;
@@ -540,7 +540,7 @@ out:
CDEBUG(D_DENTRY, "revalidated dentry %.*s (%p) parent %p "
"inode %p refc %d\n", de->d_name.len,
de->d_name.name, de, de->d_parent, de->d_inode,
- d_refcount(de));
+ d_count(de));
ll_set_lock_data(exp, de->d_inode, it, );
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 992cd20..5227c5c 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -1529,12 +1529,12 @@ static inline void d_lustre_invalidate(struct dentry
*dentry, int nested)
{
CDEBUG(D_DENTRY, "invalidate dentry %.*s (%p) parent %p inode %p "
"refc %d\n", dentry->d_name.len, dentry->d_name.name, dentry,
- dentry->d_parent, dentry->d_inode, d_refcount(dentry));
+ dentry->d_parent, dentry->d_inode, d_count(dentry));
spin_lock_nested(>d_lock,
nested ? DENTRY_D_LOCK_NESTED : DENTRY_D_LOCK_NORMAL);
__d_lustre_invalidate(dentry);
- if (d_refcount(dentry) == 0)
+ if (d_count(dentry) == 0)
__d_drop(dentry);
spin_unlock(>d_lock);
}
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 2311b20..afae801 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -659,7 +659,7 @@ void lustre_dump_dentry(struct dentry *dentry, int recur)
[PATCH v6 14/14] dcache: Enable lockless update of refcount in dentry structure
The current code takes the dentry's d_lock lock whenever the d_refcount is being updated. In reality, nothing big really happens until d_refcount goes to 0 in dput(). So it is not necessary to take the lock if the reference count won't go to 0. On the other hand, there are cases where d_refcount should not be updated or was not expected to be updated while d_lock was acquired by another thread. To use the new lockref infrastructure to do lockless reference count update, the d_lock and d_refcount field of the dentry structure was combined into a new d_lockcnt field. The offsets of the new d_lockcnt field are at byte 72 and 88 for 32-bit and 64-bit SMP systems respectively. In both cases, they are 8-byte aligned and their combination into a single 8-byte word will not introduce a hole that increase the size of the dentry structure. This patch has a particular big impact on the short workload of the AIM7 benchmark with ramdisk filesystem. The table below show the performance improvement to the JPM (jobs per minutes) throughput due to this patch on an 8-socket 80-core x86-64 system with a 3.10 kernel in a 1/2/4/8 node configuration by using numactl to restrict the execution of the workload on certain nodes. +-++-+--+ | Configuration |Mean JPM|Mean JPM | % Change | | | Rate w/o patch | Rate with patch | | +-+-+ | | User Range 10 - 100| +-+-+ | 8 nodes, HT off |1650355 | 5191497 | +214.6% | | 4 nodes, HT off |1665137 | 5204267 | +212.5% | | 2 nodes, HT off |1667552 | 3815637 | +128.8% | | 1 node , HT off |2442998 | 2352103 | -3.7% | +-+-+ | | User Range 200 - 1000 | +-+-+ | 8 nodes, HT off |1008604 | 5972142 | +492.1% | | 4 nodes, HT off |1317284 | 7190302 | +445.8% | | 2 nodes, HT off |1048363 | 4516400 | +330.8% | | 1 node , HT off |2461802 | 2466583 | +0.2% | +-+-+ | | User Range 1100 - 2000 | +-+-+ | 8 nodes, HT off | 995149 | 6424182 | +545.6% | | 4 nodes, HT off |1313386 | 7012193 | +433.9% | | 2 nodes, HT off |1041411 | 4478519 | +330.0% | | 1 node , HT off |2511186 | 2482650 | -1.1% | +-++-+--+ It can be seen that with 20 CPUs (2 nodes) or more, this patch can significantly improve the short workload performance. With only 1 node, the performance is similar with or without the patch. The short workload also scales pretty well up to 4 nodes with this patch. The following table shows the short workload performance difference of the original 3.10 kernel versus the one with the patch but have SPINLOCK_REFCOUNT config variable disabled. +-++-+--+ | Configuration |Mean JPM|Mean JPM | % Change | | | Rate w/o patch | Rate with patch | | +-+-+ | | User Range 10 - 100| +-+-+ | 8 nodes, HT off |1650355 | 1634232 | -1.0% | | 4 nodes, HT off |1665137 | 1675791 | +0.6% | | 2 nodes, HT off |1667552 | 2985552 | +79.0% | | 1 node , HT off |2442998 | 2396091 | -1.9% | +-+-+ | | User Range 200 - 1000 | +-+-+ | 8 nodes, HT off |1008604 | 1005153 | -0.3% | | 4 nodes, HT off |1317284 | 1330782 | +1.0% | | 2 nodes, HT off |1048363 | 2056871 | +96.2% | | 1 node , HT off |2461802 | 2463877 | +0.1% | +-+-+ | | User Range 1100 - 2000 | +-+-+ | 8 nodes, HT off | 995149 | 991157 | -0.4% | | 4 nodes, HT off |1313386 | 1321806 | +0.6% | | 2 nodes, HT off |1041411 | 2032808 | +95.2% | | 1 node , HT off |2511186 | 2483815 | -1.1% | +-++-+--+ There are some
[PATCH v6 11/14] nilfs2: replace direct access of d_count with the d_count() helper
All readonly references to d_count outside of the core dcache code
should be changed to use the new d_count() helper as they shouldn't
access its value directly. There is no change in logic and everything
should just work.
Signed-off-by: Waiman Long
Acked-by: Ryusuke Konishi
---
fs/nilfs2/super.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nilfs2/super.c b/fs/nilfs2/super.c
index 1427de5..af3ba04 100644
--- a/fs/nilfs2/super.c
+++ b/fs/nilfs2/super.c
@@ -996,7 +996,7 @@ static int nilfs_attach_snapshot(struct super_block *s,
__u64 cno,
static int nilfs_tree_was_touched(struct dentry *root_dentry)
{
- return root_dentry->d_count > 1;
+ return d_count(root_dentry) > 1;
}
/**
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 02/14] spinlock: Enable x86 architecture to do lockless refcount update
This patch enables the x86 architecture to do lockless reference count update using the generic lockref implementation with default parameters. Only the x86/Kconfig file needs to be changed. Signed-off-by: Waiman Long --- arch/x86/Kconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 265c672..6a86061 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -261,6 +261,9 @@ config ARCH_CPU_PROBE_RELEASE config ARCH_SUPPORTS_UPROBES def_bool y +config GENERIC_SPINLOCK_REFCOUNT + def_bool y + source "init/Kconfig" source "kernel/Kconfig.freezer" -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 01/14] spinlock: A new lockref structure for lockless update of refcount
This patch introduces a new set of spinlock_refcount.h header files to
be included by kernel codes that want to do a faster lockless update
of reference count protected by a spinlock.
The new lockref structure consists of just the spinlock and the
reference count data. Helper functions are defined in the new
header file to access the content of
the new structure. There is a generic structure defined for all
architecture, but each architecture can also optionally define its
own structure and use its own helper functions.
Three new config parameters are introduced:
1. SPINLOCK_REFCOUNT
2. GENERIC_SPINLOCK_REFCOUNT
2. ARCH_SPINLOCK_REFCOUNT
The first one is defined in the kernel/Kconfig.locks which is used
to enable or disable the faster lockless reference count update
optimization. The second and third one have to be defined in each of
the architecture's Kconfig file to enable the optimization for that
architecture. Therefore, each architecture has to opt-in for this
optimization or it won't get it. This allows each architecture plenty
of time to test it out before deciding to use it or replace it with
a better architecture specific solution. The architecture should set
only GENERIC_SPINLOCK_REFCOUNT to use the generic implementation
without customization. By setting only ARCH_SPINLOCK_REFCOUNT,
the architecture will have to provide its own implementation. By
setting both, an architecture uses the generic implementation with
customized parameters.
This optimization won't work for non-SMP system or when spinlock
debugging is turned on. As a result, it is turned off each any of
them is true. It also won't work for full preempt-RT and so should
be turned off in this case.
To maximize the chance of doing lockless update in the generic version,
the inlined __lockref_add_unless() function will wait for a certain
amount of time if the lock is not free before trying to do the update.
The amount of time is controlled by the LOCKREF_WAIT_SHIFT macro.
The new code also attempts to do lockless atomic update a few
time before falling back to the old code path of acquiring a lock
before doing the update. Similarly, this is controlled by the
LOCKREF_RETRY_COUNT macro.
Signed-off-by: Waiman Long
---
include/asm-generic/spinlock_refcount.h | 46 +++
include/linux/spinlock_refcount.h | 142
kernel/Kconfig.locks| 15 ++
lib/Makefile|2 +
lib/spinlock_refcount.c | 218 +++
5 files changed, 423 insertions(+), 0 deletions(-)
create mode 100644 include/asm-generic/spinlock_refcount.h
create mode 100644 include/linux/spinlock_refcount.h
create mode 100644 lib/spinlock_refcount.c
diff --git a/include/asm-generic/spinlock_refcount.h
b/include/asm-generic/spinlock_refcount.h
new file mode 100644
index 000..d3a4119
--- /dev/null
+++ b/include/asm-generic/spinlock_refcount.h
@@ -0,0 +1,46 @@
+/*
+ * Spinlock with reference count combo
+ *
+ * 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.
+ *
+ * (c) Copyright 2013 Hewlett-Packard Development Company, L.P.
+ *
+ * Authors: Waiman Long
+ */
+#ifndef __ASM_GENERIC_SPINLOCK_REFCOUNT_H
+#define __ASM_GENERIC_SPINLOCK_REFCOUNT_H
+
+/*
+ * The lockref structure defines a combined spinlock with reference count
+ * data structure to be embedded in a larger structure. The combined data
+ * structure is always 8-byte aligned. So proper placement of this structure
+ * in the larger embedding data structure is needed to ensure that there is
+ * no hole in it.
+ */
+struct __aligned(sizeof(u64)) lockref {
+ union {
+ u64 lock_count;
+ struct {
+ unsigned intrefcnt; /* Reference count */
+ spinlock_t lock;
+ };
+ };
+};
+
+/*
+ * Struct lockref helper functions
+ */
+extern void lockref_get(struct lockref *lockcnt);
+extern int lockref_put(struct lockref *lockcnt);
+extern int lockref_get_not_zero(struct lockref *lockcnt);
+extern int lockref_put_or_lock(struct lockref *lockcnt);
+
+#endif /* __ASM_GENERIC_SPINLOCK_REFCOUNT_H */
diff --git a/include/linux/spinlock_refcount.h
b/include/linux/spinlock_refcount.h
new file mode 100644
index 000..32389a9
--- /dev/null
+++ b/include/linux/spinlock_refcount.h
@@ -0,0 +1,142 @@
+/*
+ * Spinlock with reference count combo data structure
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the
Re: [PATCH] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Friday, July 05, 2013 7:46 PM, Arnd Bergmann wrote:
> On Friday 05 July 2013, Jingoo Han wrote:
>
> > --- /dev/null
> > +++ b/drivers/pci/host/pcie-exynos.c
>
> > +
> > +/* PCIe ELBI registers */
> > +#define PCIE_IRQ_PULSE 0x000
> > +#define IRQ_INTA_ASSERT(0x1 << 0)
> > +#define IRQ_INTB_ASSERT(0x1 << 2)
> > +#define IRQ_INTC_ASSERT(0x1 << 4)
> > +#define IRQ_INTD_ASSERT(0x1 << 6)
> > +#define PCIE_IRQ_LEVEL 0x004
> > +#define PCIE_IRQ_SPECIAL 0x008
> > +#define PCIE_IRQ_EN_PULSE 0x00c
> > +#define PCIE_IRQ_EN_LEVEL 0x010
> > +#define PCIE_IRQ_EN_SPECIAL0x014
> > +#define PCIE_PWR_RESET 0x018
> > +#define PCIE_CORE_RESET0x01c
> > +#define PCIE_CORE_RESET_ENABLE (0x1 << 0)
> > +#define PCIE_STICKY_RESET 0x020
> > +#define PCIE_NONSTICKY_RESET 0x024
> > +#define PCIE_APP_INIT_RESET0x028
> > +#define PCIE_APP_LTSSM_ENABLE 0x02c
> > +#define PCIE_ELBI_RDLH_LINKUP 0x064
> > +#define PCIE_ELBI_LTSSM_ENABLE 0x1
> > +#define PCIE_ELBI_SLV_AWMISC 0x11c
> > +#define PCIE_ELBI_SLV_ARMISC 0x120
> > +#define PCIE_ELBI_SLV_DBI_ENABLE (0x1 << 21)
> > +
> > +/* PCIe Purple registers */
> > +#define PCIE_PHY_GLOBAL_RESET 0x000
> > +#define PCIE_PHY_COMMON_RESET 0x004
> > +#define PCIE_PHY_CMN_REG 0x008
> > +#define PCIE_PHY_MAC_RESET 0x00c
> > +#define PCIE_PHY_PLL_LOCKED0x010
> > +#define PCIE_PHY_TRSVREG_RESET 0x020
> > +#define PCIE_PHY_TRSV_RESET0x024
> > +
> > +/* PCIe PHY registers */
> > +#define PCIE_PHY_IMPEDANCE 0x004
> > +#define PCIE_PHY_PLL_DIV_0 0x008
> > +#define PCIE_PHY_PLL_BIAS 0x00c
> > +#define PCIE_PHY_DCC_FEEDBACK 0x014
> > +#define PCIE_PHY_PLL_DIV_1 0x05c
> > +#define PCIE_PHY_TRSV0_EMP_LVL 0x084
> > +#define PCIE_PHY_TRSV0_DRV_LVL 0x088
> > +#define PCIE_PHY_TRSV0_RXCDR 0x0ac
> > +#define PCIE_PHY_TRSV0_LVCC0x0dc
> > +#define PCIE_PHY_TRSV1_EMP_LVL 0x144
> > +#define PCIE_PHY_TRSV1_RXCDR 0x16c
> > +#define PCIE_PHY_TRSV1_LVCC0x19c
> > +#define PCIE_PHY_TRSV2_EMP_LVL 0x204
> > +#define PCIE_PHY_TRSV2_RXCDR 0x22c
> > +#define PCIE_PHY_TRSV2_LVCC0x25c
> > +#define PCIE_PHY_TRSV3_EMP_LVL 0x2c4
> > +#define PCIE_PHY_TRSV3_RXCDR 0x2ec
> > +#define PCIE_PHY_TRSV3_LVCC0x31c
>
> Are you sure these are all exynos specific? Maybe they are licensed
> from someone else?
Samsung specific.
I asked our hardware engineer, and he confirmed it.
>
> > +
> > + pp->dbi_base = devm_ioremap(>dev, pp->cfg.start,
> > + resource_size(>cfg));
> > + if (!pp->dbi_base) {
> > + dev_err(>dev, "error with ioremap\n");
> > + return -ENOMEM;
> > + }
> > +
> > + pp->root_bus_nr = -1;
> > + pp->ops = _pcie_host_ops;
> > +
> > + spin_lock_init(>conf_lock);
> > + dw_pcie_host_init(pp);
> > + pp->va_cfg0_base = devm_ioremap(>dev, pp->cfg0_base,
> > + pp->config.cfg0_size);
> > + if (!pp->va_cfg0_base) {
> > + dev_err(pp->dev, "error with ioremap in function\n");
> > + return -ENOMEM;
> > + }
> > + pp->va_cfg1_base = devm_ioremap(>dev, pp->cfg1_base,
> > + pp->config.cfg1_size);
> > + if (!pp->va_cfg1_base) {
> > + dev_err(pp->dev, "error with ioremap\n");
> > + return -ENOMEM;
> > + }
>
> I think the configuration space handling should go into the
> dw_pcie_host_init function, as that part would be needed by all drivers.
OK.
I will move it to dw_pcie_host_init().
>
> > +static int __init exynos_pcie_probe(struct platform_device *pdev)
> > +{
> > + struct pcie_port *pp;
> > + struct device_node *np = pdev->dev.of_node;
> > + struct of_pci_range range;
> > + struct of_pci_range_parser parser;
> > + int ret;
> > +
> > + pp = devm_kzalloc(>dev, sizeof(*pp), GFP_KERNEL);
> > + if (!pp) {
> > + dev_err(>dev, "no memory for pcie port\n");
> > + return -ENOMEM;
> > + }
> > +
> > + pp->dev = >dev;
> > +
> > + if (of_pci_range_parser_init(, np)) {
> > + dev_err(>dev, "missing ranges property\n");
> > + return -EINVAL;
> > + }
> > +
> > + /* Get the I/O and memory ranges from DT */
> > + for_each_of_pci_range(, ) {
> > + unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> > + if (restype == IORESOURCE_IO) {
> > + of_pci_range_to_resource(, np, >io);
> > + pp->io.name = "I/O";
> > +
Re: sending SEGV to qemu crashes host kernel in Fedora 19
On Tue, Jul 9, 2013 at 10:35 AM, Dave Airlie wrote: > Hi, > > F19 > kernel-3.9.8-300.fc19.x86_64 > qemu-kvm-1.4.2-4.fc19.x86_64 > > If I start a complete F19 install in the guest and send the qemu > process a SEGV signal, the host kernel starts giving me random kmalloc > errors soon after, if I send a normal kill signal things seem fine. > > CPU is Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, on a HP 220z workstation. > > I initially blamed bad RAM but this reproduces everytime, and I > swapped DIMMs around > > I haven't tested with upstream kernel/qemu yet, but I wondered if > anyone else has seen this. > > I noticed this because some work I was doing was segfaulting my qemu > and then my machine would die a few mins later. Of course now I read my fedora kernel emails and notice vhost_net does bad things, disabling vhost_net seems to make it work fine, hopefully the next Fedora kernel will bring the magic fixes. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the vhost tree with the target-updates tree
On Mon, 2013-07-08 at 13:47 +1000, Stephen Rothwell wrote:
> Hi Michael,
>
> Today's linux-next merge of the vhost tree got a conflict in
> drivers/vhost/scsi.c between commit 084ed45b3846 ("vhost/scsi: Convert to
> se_cmd->cmd_kref TARGET_SCF_ACK_KREF usage") from the target-updates tree
> and commit 3c63f66a0dcd ("vhost-scsi: Rename struct tcm_vhost_cmd *tv_cmd
> to *cmd") from the vhost tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Hi Stephen,
Can you briefly refresh my memory how the process of 'carrying the fix'
in linux-next should work..?
So once I send a -rc1 PULL request to Linus over the next days, and MST
sends one shortly there-after and hits a conflict, you'll include this
patch in a separate next-fixes branch for Linus to PULL..?
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] powerpc: allow kvm to use kerel debug framework
On 04.07.2013, at 08:15, Bharat Bhushan wrote: > From: Bharat Bhushan > > This patchset moves the debug registers in a structure, which allows > kvm to use same structure for debug emulation. > > Note: Earilier a patchset > "https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-June/108132.html; > was sent which is a bunch of six patches. That patchset is divided into two > parts: > 1) powerpc specific changes (These 2 patches are actually have those > changes) > 2) KVM specific changes (will send separate patch on agraf repository) Mikey, if you like those could you please apply the into a topic branch and get that one merged with Ben? I'd also pull it into my tree then. Alex > > Bharat Bhushan (2): > powerpc: remove unnecessary line continuations > powerpc: move debug registers in a structure > > arch/powerpc/include/asm/processor.h | 38 + > arch/powerpc/include/asm/reg_booke.h |8 +- > arch/powerpc/kernel/asm-offsets.c|2 +- > arch/powerpc/kernel/process.c| 42 +- > arch/powerpc/kernel/ptrace.c | 154 +- > arch/powerpc/kernel/ptrace32.c |2 +- > arch/powerpc/kernel/signal_32.c |6 +- > arch/powerpc/kernel/traps.c | 35 > 8 files changed, 147 insertions(+), 140 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 v2] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()
On 07/09/2013 08:46 AM, Wang YanQing wrote:
> On Tue, Jul 09, 2013 at 08:43:05AM +0800, Chen Gang wrote:
>> > When failure occurs in hotplug_cfd(), need release related resources,
>> > or will cause memory leak.
>> >
>> > Signed-off-by: Chen Gang
>> > ---
>> > kernel/smp.c |5 -
>> > 1 files changed, 4 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/kernel/smp.c b/kernel/smp.c
>> > index 02a885d..2a3a017 100644
>> > --- a/kernel/smp.c
>> > +++ b/kernel/smp.c
>> > @@ -49,10 +49,13 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long
>> > action, void *hcpu)
>> >cpu_to_node(cpu)))
>> >return notifier_from_errno(-ENOMEM);
>> >if (!zalloc_cpumask_var_node(>cpumask_ipi, GFP_KERNEL,
>> > - cpu_to_node(cpu)))
>> > + cpu_to_node(cpu))) {
>> > + free_cpumask_var(cfd->cpumask);
>> >return notifier_from_errno(-ENOMEM);
>> > + }
>> >cfd->csd = alloc_percpu(struct call_single_data);
>> >if (!cfd->csd) {
>> > + free_cpumask_var(cfd->cpumask_ipi);
>> >free_cpumask_var(cfd->cpumask);
>> >return notifier_from_errno(-ENOMEM);
>> >}
>> > --
>> > 1.7.7.6
> Acked-by: Wang YanQing
>
>
Thanks :-)
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()
On Tue, Jul 09, 2013 at 08:43:05AM +0800, Chen Gang wrote:
> When failure occurs in hotplug_cfd(), need release related resources,
> or will cause memory leak.
>
> Signed-off-by: Chen Gang
> ---
> kernel/smp.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/smp.c b/kernel/smp.c
> index 02a885d..2a3a017 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -49,10 +49,13 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long
> action, void *hcpu)
> cpu_to_node(cpu)))
> return notifier_from_errno(-ENOMEM);
> if (!zalloc_cpumask_var_node(>cpumask_ipi, GFP_KERNEL,
> - cpu_to_node(cpu)))
> + cpu_to_node(cpu))) {
> + free_cpumask_var(cfd->cpumask);
> return notifier_from_errno(-ENOMEM);
> + }
> cfd->csd = alloc_percpu(struct call_single_data);
> if (!cfd->csd) {
> + free_cpumask_var(cfd->cpumask_ipi);
> free_cpumask_var(cfd->cpumask);
> return notifier_from_errno(-ENOMEM);
> }
> --
> 1.7.7.6
Acked-by: Wang YanQing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()
When failure occurs in hotplug_cfd(), need release related resources,
or will cause memory leak.
Signed-off-by: Chen Gang
---
kernel/smp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index 02a885d..2a3a017 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -49,10 +49,13 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long
action, void *hcpu)
cpu_to_node(cpu)))
return notifier_from_errno(-ENOMEM);
if (!zalloc_cpumask_var_node(>cpumask_ipi, GFP_KERNEL,
- cpu_to_node(cpu)))
+ cpu_to_node(cpu))) {
+ free_cpumask_var(cfd->cpumask);
return notifier_from_errno(-ENOMEM);
+ }
cfd->csd = alloc_percpu(struct call_single_data);
if (!cfd->csd) {
+ free_cpumask_var(cfd->cpumask_ipi);
free_cpumask_var(cfd->cpumask);
return notifier_from_errno(-ENOMEM);
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
sending SEGV to qemu crashes host kernel in Fedora 19
Hi, F19 kernel-3.9.8-300.fc19.x86_64 qemu-kvm-1.4.2-4.fc19.x86_64 If I start a complete F19 install in the guest and send the qemu process a SEGV signal, the host kernel starts giving me random kmalloc errors soon after, if I send a normal kill signal things seem fine. CPU is Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, on a HP 220z workstation. I initially blamed bad RAM but this reproduces everytime, and I swapped DIMMs around I haven't tested with upstream kernel/qemu yet, but I wondered if anyone else has seen this. I noticed this because some work I was doing was segfaulting my qemu and then my machine would die a few mins later. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFT][PATCH 2/2] irqchip: vt8500: Support 'rising and falling edge' trigger mode
This chip supports below interrupt request trigger mode: Destination Control Register: BIT[5:4] Interrupt Request Trigger Mode. 00: High level trigger 01: Posedge trigger 10: Negedge trigger 11: Both posedge and negedge trigger This patch adds support for setting 'posedge and negedge trigger' mode. Signed-off-by: Axel Lin --- Current code does not correctly handle the case if a driver request irq with "IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING" flag. I'm not sure if we have such use case in current code. drivers/irqchip/irq-vt8500.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/irqchip/irq-vt8500.c b/drivers/irqchip/irq-vt8500.c index eb6d05a..e040994 100644 --- a/drivers/irqchip/irq-vt8500.c +++ b/drivers/irqchip/irq-vt8500.c @@ -136,6 +136,10 @@ static int vt8500_irq_set_type(struct irq_data *d, unsigned int flow_type) dctr |= VT8500_TRIGGER_RISING; __irq_set_handler_locked(d->irq, handle_edge_irq); break; + case IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING: + dctr |= VT8500_EDGE; + __irq_set_handler_locked(d->irq, handle_edge_irq); + break; } writeb(dctr, base + VT8500_ICDC + d->hwirq); -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()
On 07/09/2013 08:28 AM, Wang YanQing wrote:
> On Mon, Jul 08, 2013 at 04:50:24PM +0800, Chen Gang wrote:
>> > When failure occurs in hotplug_cfd(), need release related resources,
>> > or will cause memory leak.
>> >
>> > Also beautify the related code.
>> >
>> > Signed-off-by: Chen Gang
>> > ---
>> > kernel/smp.c | 13 +
>> > 1 files changed, 9 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/kernel/smp.c b/kernel/smp.c
>> > index 02a885d..c264623 100644
>> > --- a/kernel/smp.c
>> > +++ b/kernel/smp.c
>> > @@ -45,15 +45,20 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long
>> > action, void *hcpu)
>> >switch (action) {
>> >case CPU_UP_PREPARE:
>> >case CPU_UP_PREPARE_FROZEN:
>> > - if (!zalloc_cpumask_var_node(>cpumask, GFP_KERNEL,
>> > - cpu_to_node(cpu)))
>> > + if (!zalloc_cpumask_var_node(>cpumask,
>> > + GFP_KERNEL, cpu_to_node(cpu)))
>> >return notifier_from_errno(-ENOMEM);
> What did you fixed here? code style?
> You can drop this part.
>
Yes, I should drop.
>> > - if (!zalloc_cpumask_var_node(>cpumask_ipi, GFP_KERNEL,
>> > - cpu_to_node(cpu)))
>> > +
>> > + if (!zalloc_cpumask_var_node(>cpumask_ipi,
>> > + GFP_KERNEL, cpu_to_node(cpu))) {
>> > + free_cpumask_var(cfd->cpumask);
>> >return notifier_from_errno(-ENOMEM);
>> > + }
>> > +
>> >cfd->csd = alloc_percpu(struct call_single_data);
>> >if (!cfd->csd) {
>> >free_cpumask_var(cfd->cpumask);
>> > + free_cpumask_var(cfd->cpumask_ipi);
>> >return notifier_from_errno(-ENOMEM);
>> >}
>> >break;
> Yes, we need this fix.
>
> If you resend the v2, I will give acked-by :)
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()
On Mon, Jul 08, 2013 at 04:50:24PM +0800, Chen Gang wrote:
> When failure occurs in hotplug_cfd(), need release related resources,
> or will cause memory leak.
>
> Also beautify the related code.
>
> Signed-off-by: Chen Gang
> ---
> kernel/smp.c | 13 +
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/smp.c b/kernel/smp.c
> index 02a885d..c264623 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -45,15 +45,20 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long
> action, void *hcpu)
> switch (action) {
> case CPU_UP_PREPARE:
> case CPU_UP_PREPARE_FROZEN:
> - if (!zalloc_cpumask_var_node(>cpumask, GFP_KERNEL,
> - cpu_to_node(cpu)))
> + if (!zalloc_cpumask_var_node(>cpumask,
> + GFP_KERNEL, cpu_to_node(cpu)))
> return notifier_from_errno(-ENOMEM);
What did you fixed here? code style?
You can drop this part.
> - if (!zalloc_cpumask_var_node(>cpumask_ipi, GFP_KERNEL,
> - cpu_to_node(cpu)))
> +
> + if (!zalloc_cpumask_var_node(>cpumask_ipi,
> + GFP_KERNEL, cpu_to_node(cpu))) {
> + free_cpumask_var(cfd->cpumask);
> return notifier_from_errno(-ENOMEM);
> + }
> +
> cfd->csd = alloc_percpu(struct call_single_data);
> if (!cfd->csd) {
> free_cpumask_var(cfd->cpumask);
> + free_cpumask_var(cfd->cpumask_ipi);
> return notifier_from_errno(-ENOMEM);
> }
> break;
Yes, we need this fix.
If you resend the v2, I will give acked-by :)
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] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()
On 07/08/2013 10:26 PM, Paul Gortmaker wrote: > [[PATCH] kernel/smp.c: free related resources when failure occurs in > hotplug_cfd()] On 08/07/2013 (Mon 16:50) Chen Gang wrote: > >> > When failure occurs in hotplug_cfd(), need release related resources, >> > or will cause memory leak. >> > >> > Also beautify the related code. > No. Please do not mix real fixes with trivial whitespace changes. > It makes it harder for the reviewer to find the actual fix, and it > makes the fix less portable to other releases (i.e. stable trees.) > OH, at least, need delete white spaces. > Also, you say "beautify", but that is a matter of opinion. You > shuffle around the tabs in your whitespace change, and yet even > then you don't manage to adapt it to the general coding style of > having multi-line args align with where the 1st arg starts. So > you have done nothing but pollute the "git blame" history of that > file for other users. > OK, I will send patch v2 for it (which will remove the waste 'beautifying' operation). > You might want to slow down on the quantity of patches you send, > and spend more time reading the comments from other people on > reviewed patches and learning some of the implicit requirements > from those. No, that only means I still need improving my patch sending. Hmm... for 'learning', I think: "learn with each other, never too old to learn, never stop learning", so we can learn from most of patches or replies which sent by many members. e.g. I understand that for beautifying code, I need more consideration: not only about coding style rules, but also the readers from 'git' and the reviewers from 'diff'. > I've noticed that you are already dangerously close > to annoying several key subsystem maintainers, and that is not > the right long term approach to working with the linux community. If no reply, I will(of cause) no reply either. Especially, every members' time resource is always expensive. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen: remove unused Kconfig parameter
Paul Bolle wrote: >On Mon, 2013-07-08 at 22:58 +0200, Borislav Petkov wrote: >> On Mon, Jul 08, 2013 at 01:29:40PM -0700, H. Peter Anvin wrote: >> > What. The. Fuck. >> >> This is just marvellous: grub2 has a bunch of scripts in /etc/grub.d >> which rely on the presence of kernel config files in /boot or / and >> greps them in order to do the menu entries based on the built-in >> features it finds in them. > >0) I've raised this issue a few months ago, but not on the LKML (see >http://thread.gmane.org/gmane.linux.kernel.virtualization/19126 ). > >1) And I also asked whether "userspace [can] require the build system >to >keep using some Kconfig symbol" (see >http://article.gmane.org/gmane.linux.kernel.virtualization/19129 ). >Peter and you clearly think userspace can't. > >2) But anyhow, unless that grub2 configuration file has changed, this >Kconfig symbol can still be dropped, because grub2's check for it is >actually superfluous. > > >Paul Bolle Not so fast please. Linus absolutely abhors breaking user space and I am not comfortable with that idea either. I am not sure if that falls in that category but I am sure we can rope him after rc0 madness has stopped. Could you explain to me please why the check in the scripts is superfluous? Especially as the grand plan is to get rid of CONFIG_XEN_DOM0 and more or less have a backend and fronted config option (since that makes more sense nowadays). And that would make the XEN_DOM0 be obsolete and the XEN_PRIV would be the one that turns a lot of the options needed to compile a kernel that can provide backend driver support. (I am hand waving here). I recall (and thank you for pointing to the link) that this raised some questions that never got answered such as are there tools that check /proc/config.gz for example for features? Otherwise should that be eliminated as well? -- Sent from my Android phone. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFT][PATCH 1/2] irqchip: vt8500: Fix implementation for irq_ack and irq_mask
Current code sets both irq_ack and irq_mask callbacks to vt8500_irq_mask().
However, vt8500_irq_mask does not clear interrupt enable bit when the interrupt
trigger mode is edge trigger.
This patch moves the code clearing Interrupt Status Register bit to irq_ack().
irq_mask() always clear interrupt enable bit for all interrupt trigger mode.
According to the datasheet, the Interrupt Status Register is written one to
clear(Write 0 has no effect). So we don't need a read-modify-write operation
for clearing a bit in interrupt status register.
Signed-off-by: Axel Lin
---
Hi Tony,
I don't have the hardware to test, just found this issue while reading the code.
I'd appreciate if you can review and test this patch serial.
Thanks,
Axel
drivers/irqchip/irq-vt8500.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/irqchip/irq-vt8500.c b/drivers/irqchip/irq-vt8500.c
index d970595..eb6d05a 100644
--- a/drivers/irqchip/irq-vt8500.c
+++ b/drivers/irqchip/irq-vt8500.c
@@ -81,25 +81,24 @@ struct vt8500_irq_data {
static struct vt8500_irq_data intc[VT8500_INTC_MAX];
static u32 active_cnt = 0;
-static void vt8500_irq_mask(struct irq_data *d)
+static void vt8500_irq_ack(struct irq_data *d)
{
struct vt8500_irq_data *priv = d->domain->host_data;
void __iomem *base = priv->base;
void __iomem *stat_reg = base + VT8500_ICIS + (d->hwirq < 32 ? 0 : 4);
- u8 edge, dctr;
- u32 status;
-
- edge = readb(base + VT8500_ICDC + d->hwirq) & VT8500_EDGE;
- if (edge) {
- status = readl(stat_reg);
-
- status |= (1 << (d->hwirq & 0x1f));
- writel(status, stat_reg);
- } else {
- dctr = readb(base + VT8500_ICDC + d->hwirq);
- dctr &= ~VT8500_INT_ENABLE;
- writeb(dctr, base + VT8500_ICDC + d->hwirq);
- }
+
+ writel(1 << (d->hwirq & 0x1f), stat_reg);
+}
+
+static void vt8500_irq_mask(struct irq_data *d)
+{
+ struct vt8500_irq_data *priv = d->domain->host_data;
+ void __iomem *base = priv->base;
+ u8 dctr;
+
+ dctr = readb(base + VT8500_ICDC + d->hwirq);
+ dctr &= ~VT8500_INT_ENABLE;
+ writeb(dctr, base + VT8500_ICDC + d->hwirq);
}
static void vt8500_irq_unmask(struct irq_data *d)
@@ -145,7 +144,7 @@ static int vt8500_irq_set_type(struct irq_data *d, unsigned
int flow_type)
static struct irq_chip vt8500_irq_chip = {
.name = "vt8500",
- .irq_ack = vt8500_irq_mask,
+ .irq_ack = vt8500_irq_ack,
.irq_mask = vt8500_irq_mask,
.irq_unmask = vt8500_irq_unmask,
.irq_set_type = vt8500_irq_set_type,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 8/8] ACPI / hotplug / PCI: Merge hotplug event handling functions
From: Rafael J. Wysocki
There are separate handling event functions for hotplug bridges and
for hotplug functions, but they may be combined into one common
hotplug event handling function which simplifies the code slightly.
That also allows a theoretical bug to be dealt with which in
principle may occur if a hotplug bridge is a docking station
device, because in that case the bridge-specific notification should
be used instead of the device-specific one.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 156 +++--
1 file changed, 66 insertions(+), 90 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -61,7 +61,7 @@ static DEFINE_MUTEX(bridge_mutex);
static void handle_hotplug_event(acpi_handle handle, u32 type, void *data);
static void acpiphp_sanitize_bus(struct pci_bus *bus);
static void acpiphp_set_hpp_values(struct pci_bus *bus);
-static void hotplug_event_func(acpi_handle handle, u32 type, void *context);
+static void hotplug_event(acpi_handle handle, u32 type, void *data);
static void free_bridge(struct kref *kref);
/* callback routine to check for the existence of a pci dock device */
@@ -210,7 +210,7 @@ static int post_dock_fixups(struct notif
static const struct acpi_dock_ops acpiphp_dock_ops = {
- .handler = hotplug_event_func,
+ .handler = hotplug_event,
};
/* Check whether the PCI device is managed by native PCIe hotplug driver */
@@ -244,16 +244,24 @@ static bool device_is_managed_by_native_
static void acpiphp_dock_init(void *data)
{
- struct acpiphp_func *func = data;
+ struct acpiphp_context *context = data;
+
+ if (context->func)
+ get_bridge(context->func->slot->bridge);
- get_bridge(func->slot->bridge);
+ if (context->bridge)
+ get_bridge(context->bridge);
}
static void acpiphp_dock_release(void *data)
{
- struct acpiphp_func *func = data;
+ struct acpiphp_context *context = data;
+
+ if (context->bridge)
+ put_bridge(context->bridge);
- put_bridge(func->slot->bridge);
+ if (context->func)
+ put_bridge(context->func->slot->bridge);
}
/* callback routine to register each ACPI PCI slot object */
@@ -390,7 +398,7 @@ static acpi_status register_slot(acpi_ha
*/
newfunc->flags &= ~FUNC_HAS_EJ0;
if (register_hotplug_dock_device(handle,
- _dock_ops, newfunc,
+ _dock_ops, context,
acpiphp_dock_init, acpiphp_dock_release))
dbg("failed to register dock device\n");
@@ -982,24 +990,14 @@ void acpiphp_check_host_bridge(acpi_hand
acpiphp_put_context(context);
}
-static void _handle_hotplug_event_bridge(struct work_struct *work)
+static void hotplug_event(acpi_handle handle, u32 type, void *data)
{
- struct acpiphp_context *context;
- struct acpiphp_bridge *bridge;
+ struct acpiphp_context *context = data;
+ struct acpiphp_bridge *bridge = context->bridge;
+ struct acpiphp_func *func = context->func;
char objname[64];
struct acpi_buffer buffer = { .length = sizeof(objname),
.pointer = objname };
- struct acpi_hp_work *hp_work;
- acpi_handle handle;
- u32 type;
-
- hp_work = container_of(work, struct acpi_hp_work, work);
- handle = hp_work->handle;
- type = hp_work->type;
- context = hp_work->context;
- bridge = context->bridge;
-
- acpi_scan_lock_acquire();
acpi_get_name(handle, ACPI_FULL_PATHNAME, );
@@ -1008,15 +1006,24 @@ static void _handle_hotplug_event_bridge
/* bus re-enumerate */
dbg("%s: Bus check notify on %s\n", __func__, objname);
dbg("%s: re-enumerating slots under %s\n", __func__, objname);
- acpiphp_check_bridge(bridge);
- acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
- ACPI_UINT32_MAX, check_sub_bridges, NULL, NULL, NULL);
+ if (bridge) {
+ acpiphp_check_bridge(bridge);
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
+ ACPI_UINT32_MAX, check_sub_bridges,
+ NULL, NULL, NULL);
+ } else {
+ acpiphp_enable_slot(func->slot);
+ }
break;
case ACPI_NOTIFY_DEVICE_CHECK:
/* device check */
dbg("%s: Device check notify on %s\n", __func__, objname);
- acpiphp_check_bridge(bridge);
+ if (bridge)
+
[RFC][PATCH 4/8] ACPI / hotplug / PCI: Hotplug context objects for bridges and functions
From: Rafael J. Wysocki
When either a new hotplug brigde or a new hotplug function is added
by the ACPI-based PCI hotplug (acpiphp) code, attach a context object
to its ACPI handle to store hotplug-related information in it. To
start with, put the handle's bridge and function pointers into that
object. Count references to the context objects and drop them when
they are not needed any more.
First of all, this makes it possible to find out if the given bridge
has been registered as a function already in a much more
straightforward way and acpiphp_bridge_handle_to_function() can be
dropped (Yay!).
This also will allow some more simplifications to be made going
forward.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h | 10 ++
drivers/pci/hotplug/acpiphp_glue.c | 154 ++---
2 files changed, 121 insertions(+), 43 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp.h
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
+++ linux-pm/drivers/pci/hotplug/acpiphp.h
@@ -49,6 +49,7 @@
#define info(format, arg...) printk(KERN_INFO "%s: " format, MY_NAME , ## arg)
#define warn(format, arg...) printk(KERN_WARNING "%s: " format, MY_NAME , ##
arg)
+struct acpiphp_context;
struct acpiphp_bridge;
struct acpiphp_slot;
@@ -77,6 +78,7 @@ struct acpiphp_bridge {
struct kref ref;
acpi_handle handle;
+ struct acpiphp_context *context;
/* Ejectable PCI-to-PCI bridge (PCI bridge and PCI function) */
struct acpiphp_func *func;
@@ -119,6 +121,7 @@ struct acpiphp_slot {
* typically 8 objects per slot (i.e. for each PCI function)
*/
struct acpiphp_func {
+ struct acpiphp_context *context;
struct acpiphp_slot *slot; /* parent */
struct list_head sibling;
@@ -129,6 +132,13 @@ struct acpiphp_func {
u32 flags; /* see below */
};
+struct acpiphp_context {
+ struct kref kref;
+ acpi_handle handle;
+ struct acpiphp_func *func;
+ struct acpiphp_bridge *bridge;
+};
+
/*
* struct acpiphp_attention_info - device specific attention registration
*
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -79,6 +79,61 @@ is_pci_dock_device(acpi_handle handle, u
}
}
+static void acpiphp_context_handler(acpi_handle handle, void *context)
+{
+ /* Intentionally empty. */
+}
+
+static struct acpiphp_context *acpiphp_init_context(acpi_handle handle)
+{
+ struct acpiphp_context *context;
+ acpi_status status;
+
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
+ if (!context)
+ return NULL;
+
+ context->handle = handle;
+ kref_init(>kref);
+ status = acpi_attach_data(handle, acpiphp_context_handler, context);
+ if (ACPI_FAILURE(status)) {
+ kfree(context);
+ return NULL;
+ }
+ return context;
+}
+
+static struct acpiphp_context *acpiphp_get_context(acpi_handle handle)
+{
+ struct acpiphp_context *context = NULL;
+ acpi_status status;
+ void *data;
+
+ status = acpi_get_data(handle, acpiphp_context_handler, );
+ if (ACPI_SUCCESS(status)) {
+ context = data;
+ kref_get(>kref);
+ } else if (status == AE_NOT_FOUND) {
+ context = acpiphp_init_context(handle);
+ }
+ return context;
+}
+
+static void acpiphp_release_context(struct kref *kref)
+{
+ struct acpiphp_context *context;
+
+ context = container_of(kref, struct acpiphp_context, kref);
+ WARN_ON(context->func || context->bridge);
+ acpi_detach_data(context->handle, acpiphp_context_handler);
+ kfree(context);
+}
+
+static void acpiphp_put_context(struct acpiphp_context *context)
+{
+ kref_put(>kref, acpiphp_release_context);
+}
+
static inline void get_bridge(struct acpiphp_bridge *bridge)
{
kref_get(>ref);
@@ -91,6 +146,7 @@ static inline void put_bridge(struct acp
static void free_bridge(struct kref *kref)
{
+ struct acpiphp_context *context;
struct acpiphp_bridge *bridge;
struct acpiphp_slot *slot, *next;
struct acpiphp_func *func, *tmp;
@@ -99,17 +155,24 @@ static void free_bridge(struct kref *kre
list_for_each_entry_safe(slot, next, >slots, node) {
list_for_each_entry_safe(func, tmp, >funcs, sibling) {
+ context = func->context;
+ context->func = NULL;
kfree(func);
+ acpiphp_put_context(context);
}
kfree(slot);
}
- /* Release reference acquired by acpiphp_bridge_handle_to_function() */
+ /* Release reference
[RFC][PATCH 6/8] ACPI / hotplug / PCI: Drop acpiphp_handle_to_bridge()
From: Rafael J. Wysocki
Using the hotplug context objects introduced previously rework the
ACPI-based PCI hotplug (acpiphp) core code to get to acpiphp_bridge
objects associated with hotplug bridges from those context objects
rather than from the global list of hotplug bridges.
After that the acpiphp_handle_to_bridge() is not necessary any more,
so drop it.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 54 +
1 file changed, 25 insertions(+), 29 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -441,22 +441,6 @@ static int detect_ejectable_slots(acpi_h
return found;
}
-static struct acpiphp_bridge *acpiphp_handle_to_bridge(acpi_handle handle)
-{
- struct acpiphp_bridge *bridge;
-
- mutex_lock(_mutex);
- list_for_each_entry(bridge, _list, list)
- if (bridge->handle == handle) {
- get_bridge(bridge);
- mutex_unlock(_mutex);
- return bridge;
- }
- mutex_unlock(_mutex);
-
- return NULL;
-}
-
static void cleanup_bridge(struct acpiphp_bridge *bridge)
{
struct acpiphp_slot *slot;
@@ -953,37 +937,49 @@ static void acpiphp_sanitize_bus(struct
* ACPI event handlers
*/
-static acpi_status
-check_sub_bridges(acpi_handle handle, u32 lvl, void *context, void **rv)
+static acpi_status check_sub_bridges(acpi_handle handle, u32 lvl, void *data,
+void **rv)
{
- struct acpiphp_bridge *bridge;
- char objname[64];
- struct acpi_buffer buffer = { .length = sizeof(objname),
- .pointer = objname };
+ struct acpiphp_context *context = acpiphp_get_context(handle);
+
+ if (!context)
+ return AE_OK;
- bridge = acpiphp_handle_to_bridge(handle);
- if (bridge) {
+ if (context->bridge) {
+ struct acpiphp_bridge *bridge = context->bridge;
+ char objname[64];
+ struct acpi_buffer buffer = { .length = sizeof(objname),
+ .pointer = objname };
+
+ get_bridge(bridge);
acpi_get_name(handle, ACPI_FULL_PATHNAME, );
- dbg("%s: re-enumerating slots under %s\n",
- __func__, objname);
+ dbg("%s: re-enumerating slots under %s\n", __func__, objname);
acpiphp_check_bridge(bridge);
put_bridge(bridge);
}
+ acpiphp_put_context(context);
return AE_OK ;
}
void acpiphp_check_host_bridge(acpi_handle handle)
{
- struct acpiphp_bridge *bridge;
+ struct acpiphp_context *context = acpiphp_get_context(handle);
- bridge = acpiphp_handle_to_bridge(handle);
- if (bridge) {
+ if (!context)
+ return;
+
+ if (context->bridge) {
+ struct acpiphp_bridge *bridge = context->bridge;
+
+ get_bridge(bridge);
acpiphp_check_bridge(bridge);
put_bridge(bridge);
}
acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
ACPI_UINT32_MAX, check_sub_bridges, NULL, NULL, NULL);
+
+ acpiphp_put_context(context);
}
static void _handle_hotplug_event_bridge(struct work_struct *work)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 3/8] ACPI / hotplug / PCI: Always return success after adding a function
From: Rafael J. Wysocki
When a new ACPIPHP function is added by register_slot() and the
notify handler cannot be installed for it, register_slot() returns an
error status without cleaning up, which causes the entire namespace
walk in acpiphp_enumerate_slots() to be aborted, although it still
may be possible to successfully install the function notify handler
for other device objects under the given brigde.
To address this issue make register_slot() return success after
a new function has been added, even if the addition of the notify
handler for it has failed.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -335,10 +335,9 @@ register_slot(acpi_handle handle, u32 lv
if (ACPI_FAILURE(status))
err("failed to register interrupt notify handler\n");
- } else
- status = AE_OK;
+ }
- return status;
+ return AE_OK;
err_exit:
bridge->nr_slots--;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 5/8] ACPI / hotplug / PCI: Unified notify handler for hotplug events
From: Rafael J. Wysocki
Using the hotplug context objects introduced previously rework the
ACPI-based PCI hotplug (acpiphp) core code so that all notifications
for ACPI device objects corresponding to the hotplug PCI devices are
handled by one function, handle_hotplug_event(), which recognizes
whether it has to handle a bridge or a function.
In addition to code size reduction it allows some ugly pieces of code
where notify handlers have to be uninstalled and installed again to
go away.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |1
drivers/pci/hotplug/acpiphp_glue.c | 127 +
2 files changed, 48 insertions(+), 80 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -58,11 +58,10 @@ static DEFINE_MUTEX(bridge_mutex);
#define MY_NAME "acpiphp_glue"
-static void handle_hotplug_event_bridge (acpi_handle, u32, void *);
+static void handle_hotplug_event(acpi_handle handle, u32 type, void *data);
static void acpiphp_sanitize_bus(struct pci_bus *bus);
static void acpiphp_set_hpp_values(struct pci_bus *bus);
static void hotplug_event_func(acpi_handle handle, u32 type, void *context);
-static void handle_hotplug_event_func(acpi_handle handle, u32 type, void
*context);
static void free_bridge(struct kref *kref);
/* callback routine to check for the existence of a pci dock device */
@@ -163,13 +162,13 @@ static void free_bridge(struct kref *kre
kfree(slot);
}
+ context = bridge->context;
/* Release reference acquired by acpiphp_enumerate_slots(). */
- if ((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func)
+ if (context->handler_for_func)
put_bridge(bridge->func->slot->bridge);
put_device(>pci_bus->dev);
pci_dev_put(bridge->pci_dev);
- context = bridge->context;
context->bridge = NULL;
kfree(bridge);
acpiphp_put_context(context);
@@ -406,12 +405,12 @@ static acpi_status register_slot(acpi_ha
/* install notify handler */
if (!(newfunc->flags & FUNC_HAS_DCK)) {
- status = acpi_install_notify_handler(handle,
-ACPI_SYSTEM_NOTIFY,
-handle_hotplug_event_func,
-newfunc);
-
- if (ACPI_FAILURE(status))
+ status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+handle_hotplug_event,
+context);
+ if (ACPI_SUCCESS(status))
+ context->handler_for_func = true;
+ else
err("failed to register interrupt notify handler\n");
}
@@ -465,23 +464,13 @@ static void cleanup_bridge(struct acpiph
acpi_status status;
acpi_handle handle = bridge->handle;
- if (!pci_is_root_bus(bridge->pci_bus)) {
- status = acpi_remove_notify_handler(handle,
- ACPI_SYSTEM_NOTIFY,
- handle_hotplug_event_bridge);
+ if (!bridge->context->handler_for_func) {
+ status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ handle_hotplug_event);
if (ACPI_FAILURE(status))
err("failed to remove notify handler\n");
}
- if ((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func) {
- status = acpi_install_notify_handler(bridge->func->handle,
- ACPI_SYSTEM_NOTIFY,
- handle_hotplug_event_func,
- bridge->func);
- if (ACPI_FAILURE(status))
- err("failed to install interrupt notify handler\n");
- }
-
list_for_each_entry(slot, >slots, node) {
list_for_each_entry(func, >funcs, sibling) {
if (is_dock_device(func->handle)) {
@@ -489,9 +478,10 @@ static void cleanup_bridge(struct acpiph
unregister_dock_notifier(>nb);
}
if (!(func->flags & FUNC_HAS_DCK)) {
+ func->context->handler_for_func = false;
status =
acpi_remove_notify_handler(func->handle,
- ACPI_SYSTEM_NOTIFY,
- handle_hotplug_event_func);
+ ACPI_SYSTEM_NOTIFY,
+
[RFC][PATCH 7/8] ACPI / hotplug / PCI: Pass hotplug context object to event handlers
From: Rafael J. Wysocki
Modify handle_hotplug_event() to pass the entire context object
(instead of its fields individually) to work functions started by it.
This change makes the subsequent consolidation of the event handling
work functions a bit more straightforward.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -984,6 +984,7 @@ void acpiphp_check_host_bridge(acpi_hand
static void _handle_hotplug_event_bridge(struct work_struct *work)
{
+ struct acpiphp_context *context;
struct acpiphp_bridge *bridge;
char objname[64];
struct acpi_buffer buffer = { .length = sizeof(objname),
@@ -995,7 +996,8 @@ static void _handle_hotplug_event_bridge
hp_work = container_of(work, struct acpi_hp_work, work);
handle = hp_work->handle;
type = hp_work->type;
- bridge = (struct acpiphp_bridge *)hp_work->context;
+ context = hp_work->context;
+ bridge = context->bridge;
acpi_scan_lock_acquire();
@@ -1100,18 +1102,18 @@ static void hotplug_event_func(acpi_hand
static void _handle_hotplug_event_func(struct work_struct *work)
{
+ struct acpiphp_context *context;
struct acpi_hp_work *hp_work;
- struct acpiphp_func *func;
hp_work = container_of(work, struct acpi_hp_work, work);
- func = hp_work->context;
+ context = hp_work->context;
acpi_scan_lock_acquire();
- hotplug_event_func(hp_work->handle, hp_work->type, func);
+ hotplug_event_func(hp_work->handle, hp_work->type, context->func);
acpi_scan_lock_release();
kfree(hp_work); /* allocated in handle_hotplug_event_func */
- put_bridge(func->slot->bridge);
+ put_bridge(context->func->slot->bridge);
}
/**
@@ -1129,11 +1131,9 @@ static void handle_hotplug_event(acpi_ha
if (context->bridge) {
get_bridge(context->bridge);
- data = context->bridge;
work_func = _handle_hotplug_event_bridge;
} else if (context->func) {
get_bridge(context->func->slot->bridge);
- data = context->func;
work_func = _handle_hotplug_event_func;
} else {
return;
@@ -1146,7 +1146,7 @@ static void handle_hotplug_event(acpi_ha
* For now just re-add this work to the kacpi_hotplug_wq so we
* don't deadlock on hotplug actions.
*/
- alloc_acpi_hp_work(handle, type, data, work_func);
+ alloc_acpi_hp_work(handle, type, context, work_func);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/8] ACPI / PCI: Make bus registration and unregistration symmetric
From: Rafael J. Wysocki
Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get
the ACPI device handle they need from bus->bridge, it is not
necessary to pass that handle to them as an argument.
Drop the second argument of acpi_pci_slot_enumerate() and
acpiphp_enumerate_slots(), rework them to obtain the ACPI handle
from bus->bridge and make acpi_pci_add_bus() and
acpi_pci_remove_bus() entirely symmetrical.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/pci_slot.c| 14 +-
drivers/pci/hotplug/acpiphp_glue.c |7 ---
drivers/pci/pci-acpi.c | 16
include/linux/pci-acpi.h | 10 --
4 files changed, 21 insertions(+), 26 deletions(-)
Index: linux-pm/drivers/acpi/pci_slot.c
===
--- linux-pm.orig/drivers/acpi/pci_slot.c
+++ linux-pm/drivers/acpi/pci_slot.c
@@ -159,12 +159,16 @@ register_slot(acpi_handle handle, u32 lv
return AE_OK;
}
-void acpi_pci_slot_enumerate(struct pci_bus *bus, acpi_handle handle)
+void acpi_pci_slot_enumerate(struct pci_bus *bus)
{
- mutex_lock(_list_lock);
- acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
- register_slot, NULL, bus, NULL);
- mutex_unlock(_list_lock);
+ acpi_handle handle = ACPI_HANDLE(bus->bridge);
+
+ if (handle) {
+ mutex_lock(_list_lock);
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
+ register_slot, NULL, bus, NULL);
+ mutex_unlock(_list_lock);
+ }
}
void acpi_pci_slot_remove(struct pci_bus *bus)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -1169,15 +1169,16 @@ static void handle_hotplug_event_func(ac
* Create hotplug slots for the PCI bus.
* It should always return 0 to avoid skipping following notifiers.
*/
-void acpiphp_enumerate_slots(struct pci_bus *bus, acpi_handle handle)
+void acpiphp_enumerate_slots(struct pci_bus *bus)
{
- acpi_handle dummy_handle;
+ acpi_handle handle, dummy_handle;
struct acpiphp_bridge *bridge;
if (acpiphp_disabled)
return;
- if (detect_ejectable_slots(handle) <= 0)
+ handle = ACPI_HANDLE(bus->bridge);
+ if (!handle || detect_ejectable_slots(handle) <= 0)
return;
bridge = kzalloc(sizeof(struct acpiphp_bridge), GFP_KERNEL);
Index: linux-pm/drivers/pci/pci-acpi.c
===
--- linux-pm.orig/drivers/pci/pci-acpi.c
+++ linux-pm/drivers/pci/pci-acpi.c
@@ -290,24 +290,16 @@ static struct pci_platform_pm_ops acpi_p
void acpi_pci_add_bus(struct pci_bus *bus)
{
- acpi_handle handle = NULL;
-
- if (bus->bridge)
- handle = ACPI_HANDLE(bus->bridge);
- if (acpi_pci_disabled || handle == NULL)
+ if (acpi_pci_disabled || !bus->bridge)
return;
- acpi_pci_slot_enumerate(bus, handle);
- acpiphp_enumerate_slots(bus, handle);
+ acpi_pci_slot_enumerate(bus);
+ acpiphp_enumerate_slots(bus);
}
void acpi_pci_remove_bus(struct pci_bus *bus)
{
- /*
-* bus->bridge->acpi_node.handle has already been reset to NULL
-* when acpi_pci_remove_bus() is called, so don't check ACPI handle.
-*/
- if (acpi_pci_disabled)
+ if (acpi_pci_disabled || !bus->bridge)
return;
acpiphp_remove_slots(bus);
Index: linux-pm/include/linux/pci-acpi.h
===
--- linux-pm.orig/include/linux/pci-acpi.h
+++ linux-pm/include/linux/pci-acpi.h
@@ -47,24 +47,22 @@ void acpi_pci_remove_bus(struct pci_bus
#ifdef CONFIG_ACPI_PCI_SLOT
void acpi_pci_slot_init(void);
-void acpi_pci_slot_enumerate(struct pci_bus *bus, acpi_handle handle);
+void acpi_pci_slot_enumerate(struct pci_bus *bus);
void acpi_pci_slot_remove(struct pci_bus *bus);
#else
static inline void acpi_pci_slot_init(void) { }
-static inline void acpi_pci_slot_enumerate(struct pci_bus *bus,
- acpi_handle handle) { }
+static inline void acpi_pci_slot_enumerate(struct pci_bus *bus) { }
static inline void acpi_pci_slot_remove(struct pci_bus *bus) { }
#endif
#ifdef CONFIG_HOTPLUG_PCI_ACPI
void acpiphp_init(void);
-void acpiphp_enumerate_slots(struct pci_bus *bus, acpi_handle handle);
+void acpiphp_enumerate_slots(struct pci_bus *bus);
void acpiphp_remove_slots(struct pci_bus *bus);
void acpiphp_check_host_bridge(acpi_handle handle);
#else
static inline void acpiphp_init(void) { }
-static inline void acpiphp_enumerate_slots(struct pci_bus *bus,
- acpi_handle handle) { }
+static inline
[RFC][PATCH 2/8] ACPI / hotplug / PCI: Consolidate acpiphp_enumerate_slots()
From: Rafael J. Wysocki
The acpiphp_enumerate_slots() function is now split into two parts,
acpiphp_enumerate_slots() proper and init_bridge_misc() which is
only called by the former. If these functions are combined,
it is possible to make the code easier to follow and to clean up
the error handling (to prevent memory leaks on error from
happening in particular), so do that.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 94 ++---
1 file changed, 46 insertions(+), 48 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -363,46 +363,6 @@ static int detect_ejectable_slots(acpi_h
return found;
}
-/* initialize miscellaneous stuff for both root and PCI-to-PCI bridge */
-static void init_bridge_misc(struct acpiphp_bridge *bridge)
-{
- acpi_status status;
-
- /* must be added to the list prior to calling register_slot */
- mutex_lock(_mutex);
- list_add(>list, _list);
- mutex_unlock(_mutex);
-
- /* register all slot objects under this bridge */
- status = acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge->handle, (u32)1,
-register_slot, NULL, bridge, NULL);
- if (ACPI_FAILURE(status)) {
- mutex_lock(_mutex);
- list_del(>list);
- mutex_unlock(_mutex);
- return;
- }
-
- /* install notify handler for P2P bridges */
- if (!pci_is_root_bus(bridge->pci_bus)) {
- if ((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func) {
- status =
acpi_remove_notify_handler(bridge->func->handle,
- ACPI_SYSTEM_NOTIFY,
- handle_hotplug_event_func);
- if (ACPI_FAILURE(status))
- err("failed to remove notify handler\n");
- }
- status = acpi_install_notify_handler(bridge->handle,
-ACPI_SYSTEM_NOTIFY,
-handle_hotplug_event_bridge,
-bridge);
-
- if (ACPI_FAILURE(status)) {
- err("failed to register interrupt notify handler\n");
- }
- }
-}
-
/* find acpiphp_func from acpiphp_bridge */
static struct acpiphp_func *acpiphp_bridge_handle_to_function(acpi_handle
handle)
@@ -1171,8 +1131,9 @@ static void handle_hotplug_event_func(ac
*/
void acpiphp_enumerate_slots(struct pci_bus *bus)
{
- acpi_handle handle, dummy_handle;
struct acpiphp_bridge *bridge;
+ acpi_handle handle;
+ acpi_status status;
if (acpiphp_disabled)
return;
@@ -1200,15 +1161,52 @@ void acpiphp_enumerate_slots(struct pci_
*/
get_device(>dev);
- if (!pci_is_root_bus(bridge->pci_bus) &&
- ACPI_SUCCESS(acpi_get_handle(bridge->handle,
- "_EJ0", _handle))) {
- dbg("found ejectable p2p bridge\n");
- bridge->flags |= BRIDGE_HAS_EJ0;
- bridge->func = acpiphp_bridge_handle_to_function(handle);
+ /* must be added to the list prior to calling register_slot */
+ mutex_lock(_mutex);
+ list_add(>list, _list);
+ mutex_unlock(_mutex);
+
+ /* register all slot objects under this bridge */
+ status = acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge->handle, 1,
+register_slot, NULL, bridge, NULL);
+ if (ACPI_FAILURE(status)) {
+ acpi_handle_err(bridge->handle, "failed to register slots\n");
+ goto err;
}
- init_bridge_misc(bridge);
+ if (pci_is_root_bus(bridge->pci_bus))
+ return;
+
+ /* install notify handler for P2P bridges */
+ status = acpi_install_notify_handler(bridge->handle, ACPI_SYSTEM_NOTIFY,
+handle_hotplug_event_bridge,
+bridge);
+ if (ACPI_FAILURE(status)) {
+ acpi_handle_err(bridge->handle,
+ "failed to register notify handler\n");
+ goto err;
+ }
+
+ status = acpi_get_handle(bridge->handle, "_EJ0", );
+ if (ACPI_FAILURE(status))
+ return;
+
+ dbg("found ejectable p2p bridge\n");
+ bridge->flags |= BRIDGE_HAS_EJ0;
+ bridge->func = acpiphp_bridge_handle_to_function(bridge->handle);
+ if (bridge->func) {
+ status = acpi_remove_notify_handler(bridge->func->handle,
+ ACPI_SYSTEM_NOTIFY,
+
[RFC][PATCH 0/8] ACPI / hotplug / PCI: Consolidation of handling notifications (in progress)
Hi, Following is the current set of acpiphp updates targeted at the consolidation of device notifications handling and removal of suprefluous infrastructure. Still on top of 3.10 with ACPI+PM 3.11 material merged on top (I'll rebase it on top of linux-pm.git/bleeding-edge eventually). [1/8] Make bus registration and unregistration symmetric. [Resend] [2/8] Consolidate acpiphp_enumerate_slots(). [Resend] [3/8] Fix error code path in register_slot(). [Resend] [4/8] Introduce hotplug context objects for ACPI device objects corresponding to PCI hotplug devices. [Update] [5/8] Unified notify handler for hotplug events. [Resend] [6/8] Drop acpiphp_handle_to_bridge() and use context objects instead of it. [7/8] Pass entire hotplug context objects (instead of their fields individually) to event handling work functions. [8/8] Merge hotplug event handling functions. Comments welcome. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] drivers: input: touchscreen: Initial support for SYNAPTICS_I2C_RMI touchscreen
Sorry if this is a duplicate - there's some email issues here at work. On 07/08/2013 03:39 PM, Dmitry Torokhov wrote: > On Monday, July 08, 2013 10:21:16 PM Christopher Heiny wrote: >> On 07/08/2013 01:25 AM, Balint Czobor wrote: >>> Add initial support for Synaptics RMI over I2C based touchscreens. >> >> This is pretty old code - it looks like a modification of patches we >> submitted last year. Is there some reason you're not basing it off the >> latest checkins in synaptics-rmi4 branch of Dmitry's input tree? > > That branch is fairly old as well, I believe you have much never > version on Github? Yes, I do, but I figured your branch was the reference. Balint - there newest code is here: https://github.com/mightybigcar/synaptics-rmi4 There are two branches. The main branch tracks work intended for the next submission.The development branch is a superset of that work, including all currently supported and in development RMI4 function implementations. If you would like to integrate that work into your kernel, I'll be happy to help out with that (and I suspect Dmitry and others would be too). Thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Xen-devel] [PATCH] xen: remove unused Kconfig parameter
On Mon, 2013-07-08 at 22:58 +0200, Borislav Petkov wrote: > On Mon, Jul 08, 2013 at 01:29:40PM -0700, H. Peter Anvin wrote: > > What. The. Fuck. > > This is just marvellous: grub2 has a bunch of scripts in /etc/grub.d > which rely on the presence of kernel config files in /boot or / and > greps them in order to do the menu entries based on the built-in > features it finds in them. 0) I've raised this issue a few months ago, but not on the LKML (see http://thread.gmane.org/gmane.linux.kernel.virtualization/19126 ). 1) And I also asked whether "userspace [can] require the build system to keep using some Kconfig symbol" (see http://article.gmane.org/gmane.linux.kernel.virtualization/19129 ). Peter and you clearly think userspace can't. 2) But anyhow, unless that grub2 configuration file has changed, this Kconfig symbol can still be dropped, because grub2's check for it is actually superfluous. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linuxppc-dev] Unbinding device from a driver
On 07/04/2013 05:35:28 AM, Gupta Ruchika-R66431 wrote: Hi, I am trying to unbind a platform device from a driver. Even when the remove function of the device returns an EBUSY error, the device is unbound from the driver. Is this the right behavior ? Why does kernel forcefully unbind the device even if device remove function returns an error ? From looking at the code, it seems it's not allowed for a driver to refuse the unbinding. If you can't unbind yet, you need to block until you can (and take measures to ensure that it won't take too long). I don't know the history of why the remove method can return an error even though nothing seems to check it. root@p4080ds: ls bind ffe301000.jr ffe302000.jr ffe303000.jr ffe304000.jr uevent unbind root@p4080ds: echo ffe301000.jr > unbind In caam_jr_remove caam_jr ffe301000.jr: Device Busy Is the caam_jr driver printing this, or the device model infrastructure? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ACPI / hotplug / PCI: Hotplug context objects for bridges and functions
On Monday, July 08, 2013 03:30:16 PM Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> When either a new hotplug brigde or a new hotplug function is added
> by the ACPI-based PCI hotplug (acpiphp) code, attach a context object
> to its ACPI handle to store hotplug-related information in it. To
> start with, put the handle's bridge and function pointers into that
> object. Count references to the context objects and drop them when
> they are not needed any more.
>
> First of all, this makes it possible to find out if the given bridge
> has been registered as a function already in a much more
> straightforward way and acpiphp_bridge_handle_to_function() can be
> dropped (Yay!).
>
> This also will allow some more simplifications to be made going
> forward.
Unfortunately, this one is buggy. ->
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/pci/hotplug/acpiphp.h | 10 ++
> drivers/pci/hotplug/acpiphp_glue.c | 149
> ++---
> 2 files changed, 116 insertions(+), 43 deletions(-)
>
> Index: linux-pm/drivers/pci/hotplug/acpiphp.h
> ===
> --- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
> +++ linux-pm/drivers/pci/hotplug/acpiphp.h
> @@ -49,6 +49,7 @@
> #define info(format, arg...) printk(KERN_INFO "%s: " format, MY_NAME , ##
> arg)
> #define warn(format, arg...) printk(KERN_WARNING "%s: " format, MY_NAME , ##
> arg)
>
> +struct acpiphp_context;
> struct acpiphp_bridge;
> struct acpiphp_slot;
>
> @@ -77,6 +78,7 @@ struct acpiphp_bridge {
> struct kref ref;
> acpi_handle handle;
>
> + struct acpiphp_context *context;
> /* Ejectable PCI-to-PCI bridge (PCI bridge and PCI function) */
> struct acpiphp_func *func;
>
> @@ -119,6 +121,7 @@ struct acpiphp_slot {
> * typically 8 objects per slot (i.e. for each PCI function)
> */
> struct acpiphp_func {
> + struct acpiphp_context *context;
> struct acpiphp_slot *slot; /* parent */
>
> struct list_head sibling;
> @@ -129,6 +132,13 @@ struct acpiphp_func {
> u32 flags; /* see below */
> };
>
> +struct acpiphp_context {
> + struct kref kref;
> + acpi_handle handle;
> + struct acpiphp_func *func;
> + struct acpiphp_bridge *bridge;
> +};
> +
> /*
> * struct acpiphp_attention_info - device specific attention registration
> *
> Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> ===
> --- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
> +++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> @@ -79,6 +79,61 @@ is_pci_dock_device(acpi_handle handle, u
> }
> }
>
> +static void acpiphp_context_handler(acpi_handle handle, void *context)
> +{
> + /* Intentionally empty. */
> +}
> +
> +static struct acpiphp_context *acpiphp_init_context(acpi_handle handle)
> +{
> + struct acpiphp_context *context;
> + acpi_status status;
> +
> + context = kzalloc(sizeof(*context), GFP_KERNEL);
> + if (!context)
> + return NULL;
> +
> + context->handle = handle;
> + kref_init(>kref);
> + status = acpi_attach_data(handle, acpiphp_context_handler, context);
> + if (ACPI_FAILURE(status)) {
> + kfree(context);
> + return NULL;
> + }
> + return context;
> +}
> +
> +static struct acpiphp_context *acpiphp_get_context(acpi_handle handle)
> +{
> + struct acpiphp_context *context = NULL;
> + acpi_status status;
> + void *data;
> +
> + status = acpi_get_data(handle, acpiphp_context_handler, );
> + if (ACPI_SUCCESS(status)) {
> + context = data;
> + kref_get(>kref);
> + } else if (status == AE_NOT_FOUND) {
> + context = acpiphp_init_context(handle);
> + }
> + return context;
> +}
> +
> +static void acpiphp_release_context(struct kref *kref)
> +{
> + struct acpiphp_context *context;
> +
> + context = container_of(kref, struct acpiphp_context, kref);
> + WARN_ON(context->func || context->bridge);
> + acpi_detach_data(context->handle, acpiphp_context_handler);
> + kfree(context);
> +}
> +
> +static void acpiphp_put_context(struct acpiphp_context *context)
> +{
> + kref_put(>kref, acpiphp_release_context);
> +}
> +
> static inline void get_bridge(struct acpiphp_bridge *bridge)
> {
> kref_get(>ref);
> @@ -91,6 +146,7 @@ static inline void put_bridge(struct acp
>
> static void free_bridge(struct kref *kref)
> {
> + struct acpiphp_context *context;
> struct acpiphp_bridge *bridge;
> struct acpiphp_slot *slot, *next;
> struct acpiphp_func *func, *tmp;
> @@ -99,17 +155,24 @@ static void free_bridge(struct kref *kre
>
> list_for_each_entry_safe(slot, next, >slots, node) {
> list_for_each_entry_safe(func, tmp, >funcs, sibling) {
> + context = func->context;
> +
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On Monday 08 July 2013, Srinivas KANDAGATLA wrote: > From: Srinivas Kandagatla > > This patch series fixes 2 configuration issues and adds ethernet support to > STiH415, STiH416 based B2000, B2020 boards. > With this patchset B2000 and B2020 can have basic ethernet support in > MII and RGMII modes. > > Thanks, > srini > > Srinivas Kandagatla (4): > ARM: dts: STi: Fix pinconf setup for STiH416 serial2 > ARM: STi: Set correct ARM ERRATAs. > ARM: STi: Add STiH415 ethernet support. > ARM: STi: Add STiH416 ethernet support. Hi Srini, You really have to send those things separately, as the bug fixes should probably go into 3.11, while the rest is new features and needs to be reviewed for merging into 3.12. I'm also puzzled by the fact that you add auxdata and callback functions for the ether part in the platform code. Those should probably all be properties added to the stmmac binding. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 00/30] thermal: exynos: Re-structure driver and add support for exynos5440
On 24-06-2013 06:50, Amit Daniel Kachhap wrote: > Submitting V7 version with all comments fixed. Most of the patches are acked > by > Eduardo. All the un-acked patches are modified according to the review > comments. > If any comments please let me know. Applied on linux-soc-thermal branch for_3.12/exynos. It will be queued for next merge window. Too late for this one, sorry. > > Thanks, > Amit Daniel > > Changes in V7: > * Fixed all the coding guidelines comments given by Eduardo. > * Moved the request irq call below the core thermal registration as per > discussion > with Eduardo. > * Appropriate logs/TODO's/comments added for some review comments which are > still > same as before, > 1) calibration register setting still uses enums. > 2) very few soc check's still left in the driver. > 3) Cooling devices stored in an array in the exynos core thermal layer. > > Changes in V6: > * Uses ARCH_HAS_BANDGAP config flag which is merged now in arm tree. > (http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7758/1). > * In this version patches 1, 2, 3, 4 and 30 are modified. Others are same as > V5. > * Added acked by from Jonghwa Lee. > * Rebased against Thermal Maintainer next tree. > > Changes in V5: > * Most of the changes in this version is as per suggestion from Jonghwa Lee. I > have retained one to one mapping of platform data with TMU instances as the > TMU's are different devices. In exynos5440 soc there is some register > sharing across multiple TMU's but in exynos5420 there is no register between > multiple TMU's, so the current implementation is useful to support both of > the > above. > This patch uses localized ARCH_HAS_TMU Kconfig option and is a temporary > solution > until a more generic macro ARCH_HAS_BANDGAP is introduced as per discussion > in > the link https://patchwork.kernel.org/patch/2659001/. > * trip type is passed as platform data. > * HW trip is allowed only for maximum level. > * Platform data structure is now abstracted inside 1 more structure to support > multiple sensor TMU data. > > Changes in V4: > Almost all the changes in this version is as per suggestion from Eduardo.The > major ones are listed below, > * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by platform. > With > this change existing symbol EXYNOS_TMU_DATA is not needed. > * Movement of freq_clip_table from exynos_tmu.h to exynos_thermal_common.h is > explained in the commit logs. > * Wrote all register description documentation. > * Split 5440 TMU support patch into controller change, configuration data and > feature addition patches. > * Remove all *LINUX_* in the header files. > * Still regulator enable is kept optional but a TODO: comment is added to fix > it later. > > Changes in V3: > * Added proper dependency of different exynos thermal Kconfig symbols. > Basically 3 > Kconfig can be enabled now and corresponds to tmu driver. exynos common part > and exynos configuration data. This issue was raised by Rui Zhang. > > Changes in V2: > * Separated SOC data from TMU driver. This is as per suggestion from Eduardo. > * Merged the new file created for exynos5440 TMU controller with the existing > TMU controller code. > * Removed the DT parsing code as now the SOC specific data are cleanly put > inside the data specific file. > * Even the register definations/bitfields are treated as data as there is > some variation across SOC's. > > This patchset adds TMU(Thermal management Unit) driver support for > exynos5440 platform. There are 3 instances of the TMU controllers so > necessary cleanup/re-structure is done to handle multiple thermal zone. > > Patch (exynos4: Add documentation for Exynos SoC thermal bindings) from > Lukasz Majewski is already posted to mainline. Using it as it is needed. > (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17817.html) > > Patch (thermal: exynos: Support thermal tripping ) from Jonghwan Choi is > added here with some changes. > (https://patchwork.kernel.org/patch/1668371/) > > Patch (thermal: exynos: Support for TMU regulator defined at device tree) > is a repost of my earlier > patch(https://patchwork-mail1.kernel.org/patch/2510771/) > and adds regulator support. > > Patch (ARM: dts: Add device tree node for exynos5440 TMU controller) and > patch (arm: exynos: enable ARCH_HAS_BANDGAP) can be merged through exynos > platform > maintainer as this can cause merge conflict. > > All these patches are based on thermal maintainers git tree, > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next. > > Amit Daniel Kachhap (30): > thermal: exynos: Moving exynos thermal files into samsung directory > thermal: exynos: Use ARCH_HAS_BANDGAP config to know the supported > soc's > thermal: exynos: Remove un-necessary CPU_THERMAL dependency > thermal: exynos: Bifurcate exynos thermal common and tmu controller > code > thermal: exynos: Rename exynos_thermal.c
Re: [PATCH] menuconfig: Allow j/k to move down/up the menu
On Sat, Jul 06, 2013 at 06:00:05PM -0500, Rob Landley wrote: > On 07/05/2013 06:32:59 AM, Ramkumar Ramachandra wrote: > >Like in Vim. > > > >Cc: Michal Marek > >Signed-off-by: Ramkumar Ramachandra > >--- > > Unsure why nobody has done this yet. > > While you're at it, why don't you add the ws up and down bindings > from World of Warcraft? > > The reason nobody has done this yet is that vi predates the > invention of cursor keys. They keyboards Bill Joy was using in the > 1970's did not have standardized cursor keys, in large part because > you can't cursor around on a teletype printer. Once people started > using "glass tty" devices (vt100 and such) cursor keys got > standardized within a few years. They were reasonably ubiquitous by > the time the IBM PC showed up (the vic 20 and commodore 64 and such > all had them; anything that displayed to a television instead of > through a daisy wheel). > > They also didn't have ALT or control keys. The vi modal interface is > a legacy of not having any standardized keys on the keyboard except > letters, numbers, and (for 8 bit machines) shift. (There's a song > "double bucky" to the tune of "Rubber Ducky" that commemorates a > particular bespoke keyboard design from MIT in the 1970's.) Even the > punctuation was potluck for a while there, although they could copy > manual typewriters and the IBM selectric and such for some of that. > > And now you know _why_ Linux is over 20 years old and has never > needed this. Well, one advantage of these key bindings is, that you don't have to move your hands away from the base line. And as vim user I find myself using vim key sequences in all tools. I cannot even count how many processes I accidentally killed because I tried to scroll using 'k' in htop where it does 'kill'. In a nutshell: I'm all for vim key bindings everywhere! But on the other hand, I can see that it might lead straight to chaos when everybody pushes his favorite key bindings. Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
