Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro
On Wed, Apr 29, 2015 at 12:40:15PM -0400, Pranith Kumar wrote: > On Wed, Apr 29, 2015 at 10:59 AM, mancha security > wrote: > > > > The problem is that ICC defines __GNUC__ so barrier() gets defined > > in compiler-gcc.h. Your commit removed an #undef from > > compiler-intel.h so compiler.h will never define barrier to > > __memory_barrier(). > > > > OK, I see your point. But, ICC has support for GCC inline assembly. So > the change does not seem to be making any difference. We are using our > own asm barrier rather than the inbuilt one provided by ICC. > > -- Pranith Yes, I misspoke earlier and meant to say ECC rather than ICC. --mancha pgp1I_VYEEUcU.pgp Description: PGP signature
Re: linux-next: location of the jdelvare-hwmon quilt series
Hi Jean, On Thu, 30 Apr 2015 07:28:33 +0200 Jean Delvare wrote: > > Sorry I forgot to notify you. There is a permanent redirect from the > latter to the former so both are the same, no worry. Feel free to > update your source to the new location whenever you want. Done. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpETkqZ4MPkS.pgp Description: OpenPGP digital signature
Re: [PATCH] irqchip: irqc: Remove platform data support
On Tue, Apr 28, 2015 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> As of commit 914d7d148411997c ("ARM: shmobile: r8a73a4: Remove legacy
> code"), the Renesas R-Mobile/R-Car interrupt controller is used with DT
> only, and interrupt numbers are thus always assigned automatically.
>
> Drop the platform data declaration and all related support code.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
> ---
> drivers/irqchip/irq-renesas-irqc.c | 17 +---
> include/linux/platform_data/irq-renesas-irqc.h | 27
> --
> 2 files changed, 1 insertion(+), 43 deletions(-)
> delete mode 100644 include/linux/platform_data/irq-renesas-irqc.h
>
> diff --git a/drivers/irqchip/irq-renesas-irqc.c
> b/drivers/irqchip/irq-renesas-irqc.c
> index cdf80b7794cd738e..c8b15d1cd7c99d3e 100644
> --- a/drivers/irqchip/irq-renesas-irqc.c
> +++ b/drivers/irqchip/irq-renesas-irqc.c
> @@ -29,7 +29,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #define IRQC_IRQ_MAX 32 /* maximum 32 interrupts per driver instance */
> @@ -62,7 +61,6 @@ struct irqc_priv {
> void __iomem *iomem;
> void __iomem *cpu_int_base;
> struct irqc_irq irq[IRQC_IRQ_MAX];
> - struct renesas_irqc_config config;
> unsigned int number_of_irqs;
> struct platform_device *pdev;
> struct irq_chip irq_chip;
> @@ -175,7 +173,6 @@ static struct irq_domain_ops irqc_irq_domain_ops = {
>
> static int irqc_probe(struct platform_device *pdev)
> {
> - struct renesas_irqc_config *pdata = pdev->dev.platform_data;
> struct irqc_priv *p;
> struct resource *io;
> struct resource *irq;
> @@ -191,10 +188,6 @@ static int irqc_probe(struct platform_device *pdev)
> goto err0;
> }
>
> - /* deal with driver instance configuration */
> - if (pdata)
> - memcpy(>config, pdata, sizeof(*pdata));
> -
> p->pdev = pdev;
> platform_set_drvdata(pdev, p);
>
> @@ -251,8 +244,7 @@ static int irqc_probe(struct platform_device *pdev)
> irq_chip->flags = IRQCHIP_MASK_ON_SUSPEND;
>
> p->irq_domain = irq_domain_add_simple(pdev->dev.of_node,
> - p->number_of_irqs,
> - p->config.irq_base,
> + p->number_of_irqs, 0,
> _irq_domain_ops, p);
> if (!p->irq_domain) {
> ret = -ENXIO;
> @@ -272,13 +264,6 @@ static int irqc_probe(struct platform_device *pdev)
>
> dev_info(>dev, "driving %d irqs\n", p->number_of_irqs);
>
> - /* warn in case of mismatch if irq base is specified */
> - if (p->config.irq_base) {
> - if (p->config.irq_base != p->irq[0].domain_irq)
> - dev_warn(>dev, "irq base mismatch (%d/%d)\n",
> - p->config.irq_base, p->irq[0].domain_irq);
> - }
> -
> return 0;
> err3:
> while (--k >= 0)
> diff --git a/include/linux/platform_data/irq-renesas-irqc.h
> b/include/linux/platform_data/irq-renesas-irqc.h
> deleted file mode 100644
> index 3ae17b3e00ed653c..
> --- a/include/linux/platform_data/irq-renesas-irqc.h
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -/*
> - * Renesas IRQC Driver
> - *
> - * Copyright (C) 2013 Magnus Damm
> - *
> - * 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
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> - */
> -
> -#ifndef __IRQ_RENESAS_IRQC_H__
> -#define __IRQ_RENESAS_IRQC_H__
> -
> -struct renesas_irqc_config {
> - unsigned int irq_base;
> -};
> -
> -#endif /* __IRQ_RENESAS_IRQC_H__ */
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 9/9] zram: add dynamic device add/remove functionality
Hello Sergey, On Wed, Apr 29, 2015 at 04:23:28PM +0900, Sergey Senozhatsky wrote: > On (04/29/15 16:02), Sergey Senozhatsky wrote: > > sure. I was talking about this one: > > > > CPU0CPU1 > > umount > > zram_remove() > > lock ->bd_mutex > > zram_reset_device() > > unlock ->bd_mutex > > disksize_store > > mount > > echo 'test' > /mnt/test > > kfree zram > > zram write > > > > I'll take a look later today. currently I think of something like: > > > sysfs_remove_group() > lock ->bd_mutex > ... check ->bd_openers > > zram_reset_device() > blk_cleanup_queue() > del_gendisk() > put_disk() > > unlock ->bd_mutex > bdput bdev > > idr_remove() > kfree(zram) > > > iow, idr_remove() and kfree() are done outside of ->bd_mutex lock. > but I may be wrong. haven't tested yet. but seems reasonable: we > invalidate ->bdev, delete partitions, etc., holding ->bd_mutex and > then release ->bdev, which does final put. need to check that in > detail. > > -ss Isn't it related to bd_mutex? I think the problem of deadlock is that you are trying to remove sysfs file in sysfs handler. #> echo 1 > /sys/xxx/zram_remove kernfs_fop_write - hold s_active -> zram_remove_store -> zram_remove -> sysfs_remove_group - hold s_active *again* Right? -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] usb: gadget: composite: enable BESL support
>From a6615937bcd9234e6d6bb817c3701fce44d0a84d Mon Sep 17 00:00:00 2001 From: Felipe Balbi Date: Tue, 30 Sep 2014 16:08:03 -0500 Subject: [PATCH] usb: gadget: composite: enable BESL support commit a6615937bcd9234e6d6bb817c3701fce44d0a84d upstream. According to USB 2.0 ECN Errata for Link Power Management (USB2-LPM-Errata-final.pdf), BESL must be enabled if LPM is enabled. This helps with USB30CV TD 9.21 LPM L1 Suspend Resume Test. Cc: # 3.1+ Signed-off-by: Felipe Balbi Signed-off-by: Du, Changbin --- Hi, This patch was introduced on v3.18. However the issue fixed already existed on v3.1. Thank Balbi for pointing it out. So propose to backport it over all 3.1+ stable trees as well. Du, Changbin --- drivers/usb/gadget/composite.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index a8c18df..f6a51fd 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -560,7 +560,7 @@ static int bos_desc(struct usb_composite_dev *cdev) usb_ext->bLength = USB_DT_USB_EXT_CAP_SIZE; usb_ext->bDescriptorType = USB_DT_DEVICE_CAPABILITY; usb_ext->bDevCapabilityType = USB_CAP_TYPE_EXT; - usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT); + usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT | USB_BESL_SUPPORT); /* * The Superspeed USB Capability descriptor shall be implemented by all -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: location of the jdelvare-hwmon quilt series
Hi Stephen,
On Thu, 30 Apr 2015 10:44:49 +1000, Stephen Rothwell wrote:
> I noticed commit a95d7600d9c4 ("hwmon: Update the location of my quilt
> tree") in the hwmon-staging tree. It says that the quilt series is at
> http://jdelvare.nerim.net/devel/linux/jdelvare-hwmon/ but inlinux-next
> I am using http://jdelvare.nerim.net/devel/linux-3/jdelvare-hwmon/ . I
> hope that they are really the same place, but should I update where I
> fetch from?
Sorry I forgot to notify you. There is a permanent redirect from the
latter to the former so both are the same, no worry. Feel free to
update your source to the new location whenever you want.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] drivers: sh: Remove test for now unsupported sh7372
From: Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Simon Horman
---
drivers/sh/pm_runtime.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index 89b7785de1fc..fe8875f0d7be 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -91,8 +91,7 @@ static int __init sh_pm_runtime_init(void)
!of_machine_is_compatible("renesas,r8a7791") &&
!of_machine_is_compatible("renesas,r8a7792") &&
!of_machine_is_compatible("renesas,r8a7793") &&
- !of_machine_is_compatible("renesas,r8a7794") &&
- !of_machine_is_compatible("renesas,sh7372"))
+ !of_machine_is_compatible("renesas,r8a7794"))
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] drivers: sh: Disable PM runtime for multi-platform sh73a0 with genpd
From: Geert Uytterhoeven
If the default PM domain using PM_CLK is used for PM runtime, the real PM
domain(s) cannot be registered from DT later.
Hence do not enable it when running a multi-platform kernel with genpd
support on an sh73a0. The R-Mobile PM domain driver will take care of
PM runtime management of the module clocks.
The default PM domain is still needed for:
- platforms without genpd support,
- the legacy (non-DT) case, where genpd may take over later, except
for the C5 "always on" PM domain.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Simon Horman
---
drivers/sh/pm_runtime.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index cd4c293f0dd0..6b16a67ba618 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -83,6 +83,7 @@ static int __init sh_pm_runtime_init(void)
!of_machine_is_compatible("renesas,r8a73a4") &&
#ifndef CONFIG_PM_GENERIC_DOMAINS_OF
!of_machine_is_compatible("renesas,r8a7740") &&
+ !of_machine_is_compatible("renesas,sh73a0") &&
#endif
!of_machine_is_compatible("renesas,r8a7778") &&
!of_machine_is_compatible("renesas,r8a7779") &&
@@ -91,8 +92,7 @@ static int __init sh_pm_runtime_init(void)
!of_machine_is_compatible("renesas,r8a7792") &&
!of_machine_is_compatible("renesas,r8a7793") &&
!of_machine_is_compatible("renesas,r8a7794") &&
- !of_machine_is_compatible("renesas,sh7372") &&
- !of_machine_is_compatible("renesas,sh73a0"))
+ !of_machine_is_compatible("renesas,sh7372"))
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drivers: sh: Disable PM runtime for multi-platform r8a73a4 with genpd
From: Geert Uytterhoeven
If the default PM domain using PM_CLK is used for PM runtime, the real PM
domain(s) cannot be registered from DT later.
Hence do not enable it when running a multi-platform kernel with genpd
support on an r8a73a4. The R-Mobile PM domain driver will take care of
PM runtime management of the module clocks.
The default PM domain is still needed for:
- platforms without genpd support,
- the legacy (non-DT) case, where genpd may take over later, except
for the C5 "always on" PM domain.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Simon Horman
---
drivers/sh/pm_runtime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index 6b16a67ba618..89b7785de1fc 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -80,8 +80,8 @@ static int __init sh_pm_runtime_init(void)
if (IS_ENABLED(CONFIG_ARCH_SHMOBILE_MULTI)) {
if (!of_machine_is_compatible("renesas,emev2") &&
!of_machine_is_compatible("renesas,r7s72100") &&
- !of_machine_is_compatible("renesas,r8a73a4") &&
#ifndef CONFIG_PM_GENERIC_DOMAINS_OF
+ !of_machine_is_compatible("renesas,r8a73a4") &&
!of_machine_is_compatible("renesas,r8a7740") &&
!of_machine_is_compatible("renesas,sh73a0") &&
#endif
--
2.1.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: [lm-sensors][PATCH v2] hwmon: (ntc_thermistor) Add support for ncpXXwf104
On 04/30/2015 02:05 PM, Guenter Roeck wrote: > On 04/29/2015 09:07 PM, Beomho Seo wrote: >> This patch adds support for the ntc thermistor NCPXXWF104 serises. >> > > series :-) > >> Cc: Jean Delvare >> Cc: Guenter Roeck >> Signed-off-by: Beomho Seo > > Applied to -next. > > Thanks, > Guenter > > Thank you for your response. Best regards, Beomho Seo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] SH Drivers Updates for v4.1
Hi Linus, Please consider these SH drivers updates for v4.1. I am sending this change after v4.1-rc1 has been released as it depends on SoC changes which are present in that rc release. The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031: Linux 4.1-rc1 (2015-04-26 17:59:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-sh-drivers-for-v4.1 for you to fetch changes up to 00170528f0486c08a18475af7fefa0a7679e042d: drivers: sh: Remove test for now unsupported sh7372 (2015-04-27 13:08:14 +0900) SH Drivers Updates for v4.1 * Remove test for now unsupported sh7372 SoC * Disable PM runtime for multi-platform r8a73a4 and sh73a0 SoCs with genpd Geert Uytterhoeven (3): drivers: sh: Disable PM runtime for multi-platform sh73a0 with genpd drivers: sh: Disable PM runtime for multi-platform r8a73a4 with genpd drivers: sh: Remove test for now unsupported sh7372 drivers/sh/pm_runtime.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Apr 30
Hi all, Changes since 20150429: The sound-asoc tree gained a build failure so I used the version from next-20150429. The akpm-current tree gained a conflict against the livepatching tree. Non-merge commits (relative to Linus' tree): 1107 1110 files changed, 73625 insertions(+), 20304 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 214 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3d99e3fe13d4 Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (6c5c2a01fcfd ARM: proc-arm94*.S: fix setup function) Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array index in OSS IRQ source initialization) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (d33047fd7e7d powerpc/powernv: Fix early pci_controller_ops loading.) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (acc455cffa75 sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly) Merging net/master (7f0b8a56c978 cxgb4: Fix MC1 memory offset calculation) Merging ipsec/master (39376ccb1968 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging sound-current/for-linus (7241ea558c67 ALSA: emu10k1: Emu10k2 32 bit DMA mode) Merging pci-current/for-linus (b787f68c36d4 Linux 4.1-rc1) Merging wireless-drivers/master (414b7e3b9ce8 rtlwifi: rtl8192cu: Fix kernel deadlock) Merging driver-core.current/driver-core-linus (b787f68c36d4 Linux 4.1-rc1) Merging tty.current/tty-linus (96a5d18bc133 serial: 8250_pci: Add support for 16 port Exar boards) Merging usb.current/usb-linus (0d3bba0287d4 cdc-acm: prevent infinite loop when parsing CDC headers.) Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect __init/__exit annotations) Merging usb-serial-fixes/usb-linus (82ee3aeb9295 USB: visor: Match I330 phone more precisely) Merging staging.current/staging-linus (b787f68c36d4 Linux 4.1-rc1) Merging char-misc.current/char-misc-linus (f26443a8ab76 Merge tag 'extcon-fixes-for-4.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus) Merging input-current/for-linus (48853389f206 Merge branch 'next' into for-linus) Merging crypto-current/master (8c98ebd7a6ff crypto: img-hash - CRYPTO_DEV_IMGTEC_HASH should depend on HAS_DMA) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (41d9489319f2 drivers/of: Add empty ranges quirk for PA-Semi) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (82a0eaab980a vfio-pci: Log device requests more verbosely) Merging kselftest-fixes/fixes (67d8712dcc70 selftests: Fix build failures when invoked from kselftest target) Merging drm-intel-fixes/for-linux-next-fixes (a04f90a33fab drm/i915/chv: Implement WaDisableShadowRegForCpd) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-
[PATCH] overflow check calculation in mm/mmap.c is incorrect linux-3.12.38
When checking for overflow, the code in mm/mmap.c compares the first byte *after* the end of mapped region to the start of the region instead of the last byte of the mapped region. This prevents mapping a region which abuts the end of physical space, as mmap() incorrectly rejects the region with -EOVERFLOW, because pgoff + (len >> PAGE_SHIFT) will be 0, which is < pgoff. -reese Reese Faucette Cisco Systems, Inc. --- mm/mmap.c +++ mm/mmap.c @@ -1241,7 +1241,7 @@ return -ENOMEM; /* offset overflow? */ - if ((pgoff + (len >> PAGE_SHIFT)) < pgoff) + if ((pgoff + (len >> PAGE_SHIFT) - 1) < pgoff) return -EOVERFLOW; /* Too many mappings? */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [lm-sensors][PATCH v2] hwmon: (ntc_thermistor) Add support for ncpXXwf104
On 04/29/2015 09:07 PM, Beomho Seo wrote: This patch adds support for the ntc thermistor NCPXXWF104 serises. series :-) Cc: Jean Delvare Cc: Guenter Roeck Signed-off-by: Beomho Seo Applied to -next. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ocfs2-devel] [PATCH next] ocfs2: Reduce object size of mlog uses
On Tue, 2015-04-28 at 11:30 -0700, Mark Fasheh wrote: > On Thu, Apr 23, 2015 at 04:35:21PM -0700, Joe Perches wrote: > > On Thu, 2015-04-23 at 16:04 -0700, Mark Fasheh wrote: > > > On Wed, Apr 22, 2015 at 03:46:04PM -0700, Andrew Morton wrote: > > > > If you feel like undertaking such a rotorooting then go wild - that > > > > should > > > > wake 'em up ;) > > > Ok, I've taken the bait :) > > "Here fishy, fishy...", erm, "Here Fasheh, Fasheh..." > > With that out of the way: > :) Yeah. Sorry 'bout that. My own name is vaguely aquatic too so I thought I could get away with it. Bad Joe... > > A couple of possibilities: > > > > o I wonder whether or not file/func/line matter at all. > > I think they don't. > > Removing them would reduce code size ~90K > > They do to those that are debugging live Ocfs2 modules. I would like at > least one pair kept please. Your code, your choice. > > o There's a small logging improvement possible in tcp.c. > This part looks good to me though, thanks for it. Please submit something like it whenever you deem appropriate. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PCI] BUG: unable to handle kernel paging request at fffffffffffffff8
] [] ? rest_init+0x8c/0x8c
[0.888000] [] kernel_init+0xe/0xdf
[0.888000] [] ret_from_fork+0x42/0x70
[0.888000] [] ? rest_init+0x8c/0x8c
[0.888000] Code: d8 5b 41 5c 5d c3 0f 1f 44 00 00 55 48 89 f7 48 89 d6 48
89 e5 e8 91 ff ff ff 5d c3 0f 1f 44 00 00 55 48 89 e5 e8 63 e7 ff ff 5d <8b> 00
c3 0f 1f 44 00 00 31 c0 81 bf 28 03 00 00 00 01 00 00 0f
[0.888000] RIP [] pci_domain_nr+0xf/0x12
[0.888000] RSP
[0.888000] CR2: fff8
[0.888000] ---[ end trace eac89ddbfb4c36c7 ]---
[0.888000] Kernel panic - not syncing: Fatal exception
git bisect start 3e13c9fbd94599113876de94efbae2b36ea8f335
b787f68c36d49bb1d9236f403813641efa74a031 --
git bisect good a997927183cfd69fd3da8ab60475685544e5303a # 22:50 20+
22 PCI: Remove deprecated pci_scan_bus_parented()
git bisect good dbececfc2535f46ec98ad4559756cfb63baa0957 # 22:56 20+
24 PCI: Introduce pci_host_assign_domain_nr() to assign domain
git bisect good 128c719d41c556165e6f6921187c8b327d8e927b # 22:59 20+
19 PCI: Remove declaration for pci_get_new_domain_nr()
git bisect good dbb228bb60e4407f4d5c9afd297e5689754809e2 # 23:12 20+
21 PCI: Remove pci_bus_assign_domain_nr()
# first bad commit: [3e13c9fbd94599113876de94efbae2b36ea8f335] PCI: Remove
platform specific pci_domain_nr()
git bisect good dbb228bb60e4407f4d5c9afd297e5689754809e2 # 23:18 60+
81 PCI: Remove pci_bus_assign_domain_nr()
# extra tests with DEBUG_INFO
git bisect bad 3e13c9fbd94599113876de94efbae2b36ea8f335 # 23:22 0-
22 PCI: Remove platform specific pci_domain_nr()
# extra tests on HEAD of yijingwang-pci/enumer11
git bisect good 510ffebb71db123382b4efb2a62601360387bb4c # 23:27 60+
56 PCI: Rename __pci_create_root_bus() to pci_create_root_bus()
# extra tests on tree/branch yijingwang-pci/enumer11
git bisect good 510ffebb71db123382b4efb2a62601360387bb4c # 23:35 60+
116 PCI: Rename __pci_create_root_bus() to pci_create_root_bus()
# extra tests on tree/branch linus/master
git bisect good 3d99e3fe13d473ac4578c37f477a59b829530764 # 23:43 60+
58 Merge branch 'stable' of
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile
# extra tests on tree/branch next/master
git bisect good 6b1330a4f1b25f474aa2b9bcaf941e26abfe30af # 23:50 60+
80 Add linux-next specific files for 20150429
This script may reproduce the error.
#!/bin/bash
kernel=$1
kvm=(
qemu-system-x86_64
-enable-kvm
-cpu kvm64
-kernel $kernel
-m 300
-smp 2
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
rd.udev.log-priority=err
systemd.log_target=journal
systemd.log_level=warning
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
Thanks,
Fengguang
early console in setup code
Probing EDD (edd=off to disable)... ok
early console in decompress_kernel
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.1.0-rc1-00012-g3e13c9f (kbuild@roam) (gcc
version 4.9.2 (Debian 4.9.2-10) ) #18 SMP Tue Apr 28 13:29:43 CST 2015
[0.00] Command line: hung_task_panic=1 earlyprintk=ttyS0,115200
rd.udev.log-priority=err systemd.log_target=journal systemd.log_level=warning
debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal root=/dev/ram0
rw
link=/kbuild-tests/run-queue/kvm/x86_64-lkp/yijingwang-pci:enumer11:3e13c9fbd94599113876de94efbae2b36ea8f335:bisect-linux-9/.vmlinuz-3e13c9fbd94599113876de94efbae2b36ea8f335-20150429223647-9-ivb42
branch=yijingwang-pci/enumer11
BOOT_IMAGE=/kernel/x86_64-lkp/3e13c9fbd94599113876de94efbae2b36ea8f335/vmlinuz-4.1.0-rc1-00012-g3e13c9f
drbd.minor_count=8
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x
Re: [PATCH V2 linux-next] cpufreq: pxa: replace typedef pxa_freqs_t by structure
On Wed, 2015-04-29 at 21:32 +0200, Fabian Frederick wrote:
> typedef is not really useful here. Replace it by structure
> to improve readability.typedef should only be used in some cases.
> (See Documentation/CodingStyle Chapter 5 for details).
trivia:
> diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c
> b/drivers/cpufreq/pxa2xx-cpufreq.c
[]
> @@ -86,7 +86,7 @@ static unsigned int sdram_rows;
> /* Use the run mode frequencies for the CPUFREQ_POLICY_PERFORMANCE policy */
> #define CCLKCFG CCLKCFG_TURBO | CCLKCFG_FCS
>
> -static pxa_freqs_t pxa255_run_freqs[] =
> +static struct pxa_freqs pxa255_run_freqs[] =
Should these be const?
> {
> /* CPU MEMBUS CCCR DIV2 CCLKCFGrun turbo PXbus
> SDRAM */
> { 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50,
> 50 */
> @@ -98,7 +98,7 @@ static pxa_freqs_t pxa255_run_freqs[] =
> };
>
> /* Use the turbo mode frequencies for the CPUFREQ_POLICY_POWERSAVE policy */
> -static pxa_freqs_t pxa255_turbo_freqs[] =
> +static struct pxa_freqs pxa255_turbo_freqs[] =
> {
> /* CPU MEMBUS CCCR DIV2 CCLKCFGrun turbo PXbus SDRAM */
> { 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50,
> 50 */
> @@ -153,7 +153,7 @@ MODULE_PARM_DESC(pxa255_turbo_table, "Selects the
> frequency table (0 = run table
> ((HT) ? CCLKCFG_HALFTURBO : 0) | \
> ((T) ? CCLKCFG_TURBO : 0))
>
> -static pxa_freqs_t pxa27x_freqs[] = {
> +static struct pxa_freqs pxa27x_freqs[] = {
> {104000, 104000, PXA27x_CCCR(1, 8, 2), 0, CCLKCFG2(1, 0, 1), 90,
> 1705000 },
> {156000, 104000, PXA27x_CCCR(1, 8, 3), 0, CCLKCFG2(1, 0, 1), 100,
> 1705000 },
> {208000, 208000, PXA27x_CCCR(0, 16, 2), 1, CCLKCFG2(0, 0, 1), 118,
> 1705000 },
> @@ -171,7 +171,7 @@ extern unsigned get_clk_frequency_khz(int info);
>
> #ifdef CONFIG_REGULATOR
>
> -static int pxa_cpufreq_change_voltage(pxa_freqs_t *pxa_freq)
> +static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
> {
> int ret = 0;
> int vmin, vmax;
> @@ -202,7 +202,7 @@ static void __init pxa_cpufreq_init_voltages(void)
> }
> }
> #else
> -static int pxa_cpufreq_change_voltage(pxa_freqs_t *pxa_freq)
> +static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
> {
> return 0;
> }
> @@ -211,7 +211,7 @@ static void __init pxa_cpufreq_init_voltages(void) { }
> #endif
>
> static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
> - pxa_freqs_t **pxa_freqs)
> + struct pxa_freqs **pxa_freqs)
> {
> if (cpu_is_pxa25x()) {
> if (!pxa255_turbo_table) {
> @@ -270,7 +270,7 @@ static unsigned int pxa_cpufreq_get(unsigned int cpu)
> static int pxa_set_target(struct cpufreq_policy *policy, unsigned int idx)
> {
> struct cpufreq_frequency_table *pxa_freqs_table;
> - pxa_freqs_t *pxa_freq_settings;
> + struct pxa_freqs *pxa_freq_settings;
> unsigned long flags;
> unsigned int new_freq_cpu, new_freq_mem;
> unsigned int unused, preset_mdrefr, postset_mdrefr, cclkcfg;
> @@ -361,7 +361,7 @@ static int pxa_cpufreq_init(struct cpufreq_policy *policy)
> int i;
> unsigned int freq;
> struct cpufreq_frequency_table *pxa255_freq_table;
> - pxa_freqs_t *pxa255_freqs;
> + struct pxa_freqs *pxa255_freqs;
>
> /* try to guess pxa27x cpu */
> if (cpu_is_pxa27x())
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] clocksource: exynos_mct: Staticize struct clocksource
The struct clocksource 'mct_frc' is not exported and used outside so
make it static.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clocksource/exynos_mct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 87c2e558c465..8b2a9fc66dcc 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -209,7 +209,7 @@ static void exynos4_frc_resume(struct clocksource *cs)
exynos4_mct_frc_start();
}
-struct clocksource mct_frc = {
+static struct clocksource mct_frc = {
.name = "mct-frc",
.rating = 400,
.read = exynos4_frc_read,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] clocksource: exynos_mct: Remove old platform mct_init()
Since commit 228e3023eb04 ("Merge tag 'mct-exynos-for-v3.10' of ...") the
mct_init() was superseded by mct_init_dt() and is not referenced
anywhere. Remove it.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clocksource/exynos_mct.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 8b2a9fc66dcc..935b05936dbd 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -560,18 +560,6 @@ out_irq:
free_percpu_irq(mct_irqs[MCT_L0_IRQ], _mct_tick);
}
-void __init mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1)
-{
- mct_irqs[MCT_G0_IRQ] = irq_g0;
- mct_irqs[MCT_L0_IRQ] = irq_l0;
- mct_irqs[MCT_L1_IRQ] = irq_l1;
- mct_int_type = MCT_INT_SPI;
-
- exynos4_timer_resources(NULL, base);
- exynos4_clocksource_init();
- exynos4_clockevent_init();
-}
-
static void __init mct_init_dt(struct device_node *np, unsigned int int_type)
{
u32 nr_irqs, i;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] clocksource: exynos_mct: Change exynos4_mct_tick_clear return type to void
Return value of exynos4_mct_tick_clear() was never checked so it can
be safely changed to void.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clocksource/exynos_mct.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 83564c9cfdbe..87c2e558c465 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -413,7 +413,7 @@ static inline void exynos4_tick_set_mode(enum
clock_event_mode mode,
}
}
-static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
+static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
{
struct clock_event_device *evt = >evt;
@@ -426,12 +426,8 @@ static int exynos4_mct_tick_clear(struct
mct_clock_event_device *mevt)
exynos4_mct_tick_stop(mevt);
/* Clear the MCT tick interrupt */
- if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1) {
+ if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
- return 1;
- } else {
- return 0;
- }
}
static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus
On Thursday 30 April 2015 10:06 AM, Preeti Murthy wrote: > On Wed, Apr 29, 2015 at 10:49 PM, Shreyas B Prabhu > wrote: >> >> >> On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote: I am not sure if its worth the effort now. It doesn't look like any other trace point apart from the above use case will benefit from it. Only smbus_write and smbus_reply seem to come close. But even they need separate TP_fast_assign. >>> >>> It shouldn't be a problem to implement. But I'm currently cleaning up >>> those files, and any changes will cause nasty conflicts. >>> >>> Lets do this. Push the current changes as is, and when I get around to >>> adding a DEFINE_EVENT_PRINT_CONDITION(), we can modify that code to use >>> it. >>> >> Okay, sure. > > Looks good then. > > Reviewed-by: Preeti U Murthy Thanks a lot! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 15/32] powerpc/powernv/ioda/ioda2: Rework TCE invalidation in tce_build()/tce_free()
On Thu, Apr 30, 2015 at 12:58:12PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 01:18 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:39PM +1000, Alexey Kardashevskiy wrote:
> >>The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
> >>supposed to be called on IODA1/2 and not called on p5ioc2. It receives
> >>start and end host addresses of TCE table.
> >>
> >>IODA2 actually needs PCI addresses to invalidate the cache. Those
> >>can be calculated from host addresses but since we are going
> >>to implement multi-level TCE tables, calculating PCI address from
> >>a host address might get either tricky or ugly as TCE table remains flat
> >>on PCI bus but not in RAM.
> >>
> >>This moves pnv_pci_ioda_tce_invalidate() from generic pnv_tce_build/
> >>pnt_tce_free and defines IODA1/2-specific callbacks which call generic
> >>ones and do PHB-model-specific TCE cache invalidation. P5IOC2 keeps
> >>using generic callbacks as before.
> >>
> >>This changes pnv_pci_ioda2_tce_invalidate() to receives TCE index and
> >>number of pages which are PCI addresses shifted by IOMMU page shift.
> >>
> >>No change in behaviour is expected.
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >>---
> >>Changes:
> >>v9:
> >>* removed confusing comment from commit log about unintentional calling of
> >>pnv_pci_ioda_tce_invalidate()
> >>* moved mechanical changes away to "powerpc/iommu: Move tce_xxx callbacks
> >>from ppc_md to iommu_table"
> >>* fixed bug with broken invalidation in pnv_pci_ioda2_tce_invalidate -
> >>@index includes @tbl->it_offset but old code added it anyway which later
> >>broke
> >>DDW
> >>---
> >> arch/powerpc/platforms/powernv/pci-ioda.c | 86
> >> +--
> >> arch/powerpc/platforms/powernv/pci.c | 17 ++
> >> 2 files changed, 64 insertions(+), 39 deletions(-)
> >>
> >>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>index 718d5cc..f070c44 100644
> >>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>@@ -1665,18 +1665,20 @@ static void pnv_ioda_setup_bus_dma(struct
> >>pnv_ioda_pe *pe,
> >>}
> >> }
> >>
> >>-static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
> >>-struct iommu_table *tbl,
> >>-__be64 *startp, __be64 *endp, bool rm)
> >>+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
> >>+ unsigned long index, unsigned long npages, bool rm)
> >> {
> >>+ struct pnv_ioda_pe *pe = container_of(tbl->it_table_group,
> >>+ struct pnv_ioda_pe, table_group);
> >>__be64 __iomem *invalidate = rm ?
> >>(__be64 __iomem *)pe->tce_inval_reg_phys :
> >>(__be64 __iomem *)tbl->it_index;
> >>unsigned long start, end, inc;
> >>const unsigned shift = tbl->it_page_shift;
> >>
> >>- start = __pa(startp);
> >>- end = __pa(endp);
> >>+ start = __pa((__be64 *)tbl->it_base + index - tbl->it_offset);
> >>+ end = __pa((__be64 *)tbl->it_base + index - tbl->it_offset +
> >>+ npages - 1);
> >
> >This doesn't look right. The arguments to __pa don't appear to be
> >addresses (since index and if_offset are in units of (TCE) pages, not
> >bytes).
>
>
> tbl->it_base is an address and it is casted to __be64* which means:
>
> (char*)tbl->it_base + (index - tbl->it_offset)*sizeof(__be64).
>
> Which seems to be correct (I just removed extra braces compared to the old
> code), no?
Ah, yes, I'm just forgetting my C pointer arithmetic rules.
Reviewed-by: David Gibson
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpCrH0e_iS2X.pgp
Description: PGP signature
Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)
On Wed, 2015-04-29 at 14:12 -0700, Daniel Phillips wrote: > Btrfs appears to optimize tiny files by storing them in its big btree, > the equivalent of our itree, and Tux3 doesn't do that yet, so we are a > bit hobbled for a make load. That's not a build load, it's a git load. btrfs beat all others at the various git/quilt things I tried (since that's what I do lots of in real life), but tux3 looked quite good too. As Dave noted though, an orchard produces oodles of apples over its lifetime, these shiny new apples may lose luster over time ;-) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Bugfix v6] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716
An IO port or MMIO resource assigned to a PCI host bridge may be
consumed by the host bridge itself or available to its child
bus/devices. The ACPI specification defines a bit (Producer/Consumer)
to tell whether the resource is consumed by the host bridge itself,
but firmware hasn't used that bit consistently, so we can't rely on it.
Before commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
interfaces to simplify implementation"), arch/x86/pci/acpi.c ignored
all IO port resources defined by acpi_resource_io and
acpi_resource_fixed_io to filter out IO ports consumed by the host
bridge itself.
Commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces
to simplify implementation") started accepting all IO port and MMIO
resources, which caused a regression that IO port resources consumed
by the host bridge itself became available to its child devices.
Then commit 63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
host bridge itself") ignored resources consumed by the host bridge
itself by checking the IORESOURCE_WINDOW flag, which accidently removed
MMIO resources defined by acpi_resource_memory24, acpi_resource_memory32
and acpi_resource_fixed_memory32.
On x86 and IA64 platforms, all IO port and MMIO resources are assumed
to be available to child bus/devices except one special case:
IO port [0xCF8-0xCFF] is consumed by the host bridge itself
to access PCI configuration space.
So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF]. This solution
will also ease the way to consolidate ACPI PCI host bridge common code
from x86, ia64 and ARM64.
Related ACPI table are archived at:
https://bugzilla.kernel.org/show_bug.cgi?id=94221
Related discussions at:
http://patchwork.ozlabs.org/patch/461633/
https://lkml.org/lkml/2015/3/29/304
Fixes: 63f1789ec716("Ignore resources consumed by host bridge itself")
Reported-by: Bernhard Thaler
Signed-off-by: Jiang Liu
Cc: # 4.0
---
arch/x86/pci/acpi.c | 24 ++--
drivers/acpi/resource.c |2 +-
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index e4695985f9de..d93963340c3c 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -325,6 +325,26 @@ static void release_pci_root_info(struct pci_host_bridge
*bridge)
kfree(info);
}
+/*
+ * An IO port or MMIO resource assigned to a PCI host bridge may be
+ * consumed by the host bridge itself or available to its child
+ * bus/devices. The ACPI specification defines a bit (Producer/Consumer)
+ * to tell whether the resource is consumed by the host bridge itself,
+ * but firmware hasn't used that bit consistently, so we can't rely on it.
+ *
+ * On x86 and IA64 platforms, all IO port and MMIO resources are assumed
+ * to be available to child bus/devices except one special case:
+ * IO port [0xCF8-0xCFF] is consumed by the host bridge itself
+ * to access PCI configuration space.
+ *
+ * So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF].
+ */
+static bool resource_is_pcicfg_ioport(struct resource *res)
+{
+ return (res->flags & IORESOURCE_IO) &&
+ res->start == 0xCF8 && res->end == 0xCFF;
+}
+
static void probe_pci_root_info(struct pci_root_info *info,
struct acpi_device *device,
int busnum, int domain,
@@ -346,8 +366,8 @@ static void probe_pci_root_info(struct pci_root_info *info,
"no IO and memory resources present in _CRS\n");
else
resource_list_for_each_entry_safe(entry, tmp, list) {
- if ((entry->res->flags & IORESOURCE_WINDOW) == 0 ||
- (entry->res->flags & IORESOURCE_DISABLED))
+ if ((entry->res->flags & IORESOURCE_DISABLED) ||
+ resource_is_pcicfg_ioport(entry->res))
resource_list_destroy_entry(entry);
else
entry->res->name = info->name;
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 5589a6e2a023..8244f013f210 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -573,7 +573,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_get_resources);
* @ares: Input ACPI resource object.
* @types: Valid resource types of IORESOURCE_XXX
*
- * This is a hepler function to support acpi_dev_get_resources(), which filters
+ * This is a helper function to support acpi_dev_get_resources(), which filters
* ACPI resource objects according to resource types.
*/
int acpi_dev_filter_resource_type(struct acpi_resource *ares,
--
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 kernel v9 20/32] powerpc/powernv/ioda2: Introduce pnv_pci_create_table/pnv_pci_free_table
On Wed, Apr 29, 2015 at 07:12:37PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 02:39 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:44PM +1000, Alexey Kardashevskiy wrote:
> >>This is a part of moving TCE table allocation into an iommu_ops
> >>callback to support multiple IOMMU groups per one VFIO container.
> >>
> >>This moves a table creation window to the file with common powernv-pci
> >>helpers as it does not do anything IODA2-specific.
> >>
> >>This adds pnv_pci_free_table() helper to release the actual TCE table.
> >>
> >>This enforces window size to be a power of two.
> >>
> >>This should cause no behavioural change.
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >>Reviewed-by: David Gibson
> >>---
> >>Changes:
> >>v9:
> >>* moved helpers to the common powernv pci.c file from pci-ioda.c
> >>* moved bits from pnv_pci_create_table() to pnv_alloc_tce_table_pages()
> >>---
> >> arch/powerpc/platforms/powernv/pci-ioda.c | 36 ++
> >> arch/powerpc/platforms/powernv/pci.c | 61
> >> +++
> >> arch/powerpc/platforms/powernv/pci.h | 4 ++
> >> 3 files changed, 76 insertions(+), 25 deletions(-)
> >>
> >>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>index a80be34..b9b3773 100644
> >>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>@@ -1307,8 +1307,7 @@ static void pnv_pci_ioda2_release_dma_pe(struct
> >>pci_dev *dev, struct pnv_ioda_pe
> >>if (rc)
> >>pe_warn(pe, "OPAL error %ld release DMA window\n", rc);
> >>
> >>- iommu_reset_table(tbl, of_node_full_name(dev->dev.of_node));
> >>- free_pages(addr, get_order(TCE32_TABLE_SIZE));
> >>+ pnv_pci_free_table(tbl);
> >> }
> >>
> >> static void pnv_ioda_release_vf_PE(struct pci_dev *pdev, u16 num_vfs)
> >>@@ -2039,10 +2038,7 @@ static struct iommu_table_group_ops
> >>pnv_pci_ioda2_ops = {
> >> static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
> >> struct pnv_ioda_pe *pe)
> >> {
> >>- struct page *tce_mem = NULL;
> >>- void *addr;
> >>struct iommu_table *tbl = >table_group.tables[0];
> >>- unsigned int tce_table_size, end;
> >>int64_t rc;
> >>
> >>/* We shouldn't already have a 32-bit DMA associated */
> >>@@ -2053,29 +2049,20 @@ static void pnv_pci_ioda2_setup_dma_pe(struct
> >>pnv_phb *phb,
> >>
> >>/* The PE will reserve all possible 32-bits space */
> >>pe->tce32_seg = 0;
> >>- end = (1 << ilog2(phb->ioda.m32_pci_base));
> >>- tce_table_size = (end / 0x1000) * 8;
> >>pe_info(pe, "Setting up 32-bit TCE table at 0..%08x\n",
> >>- end);
> >>+ phb->ioda.m32_pci_base);
> >>
> >>- /* Allocate TCE table */
> >>- tce_mem = alloc_pages_node(phb->hose->node, GFP_KERNEL,
> >>- get_order(tce_table_size));
> >>- if (!tce_mem) {
> >>- pe_err(pe, "Failed to allocate a 32-bit TCE memory\n");
> >>- goto fail;
> >>+ rc = pnv_pci_create_table(>table_group, pe->phb->hose->node,
> >>+ 0, IOMMU_PAGE_SHIFT_4K, phb->ioda.m32_pci_base, tbl);
> >>+ if (rc) {
> >>+ pe_err(pe, "Failed to create 32-bit TCE table, err %ld", rc);
> >>+ return;
> >>}
> >>- addr = page_address(tce_mem);
> >>- memset(addr, 0, tce_table_size);
> >>-
> >>- /* Setup iommu */
> >>- tbl->it_table_group = >table_group;
> >>-
> >>- /* Setup linux iommu table */
> >>- pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
> >>- IOMMU_PAGE_SHIFT_4K);
> >>
> >>tbl->it_ops = _ioda2_iommu_ops;
> >>+
> >>+ /* Setup iommu */
> >>+ tbl->it_table_group = >table_group;
> >>iommu_init_table(tbl, phb->hose->node);
> >> #ifdef CONFIG_IOMMU_API
> >>pe->table_group.ops = _pci_ioda2_ops;
> >>@@ -2121,8 +2108,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
> >>*phb,
> >> fail:
> >>if (pe->tce32_seg >= 0)
> >>pe->tce32_seg = -1;
> >>- if (tce_mem)
> >>- __free_pages(tce_mem, get_order(tce_table_size));
> >>+ pnv_pci_free_table(tbl);
> >> }
> >>
> >> static void pnv_ioda_setup_dma(struct pnv_phb *phb)
> >>diff --git a/arch/powerpc/platforms/powernv/pci.c
> >>b/arch/powerpc/platforms/powernv/pci.c
> >>index e8802ac..6bcfad5 100644
> >>--- a/arch/powerpc/platforms/powernv/pci.c
> >>+++ b/arch/powerpc/platforms/powernv/pci.c
> >>@@ -20,7 +20,9 @@
> >> #include
> >> #include
> >> #include
> >>+#include
> >>
> >>+#include
> >> #include
> >> #include
> >> #include
> >>@@ -645,6 +647,65 @@ void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
> >>tbl->it_type = TCE_PCI;
> >> }
> >>
> >>+static __be64 *pnv_alloc_tce_table_pages(int nid, unsigned shift,
> >>+ unsigned long *tce_table_allocated)
> >
> >I'm a bit confused by the tce_table_allocated parameter. What's the
> >circumstance where more memory is
Re: [PATCH kernel v9 21/32] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_set_window
On Wed, Apr 29, 2015 at 07:26:28PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 02:45 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:45PM +1000, Alexey Kardashevskiy wrote:
> >>This is a part of moving DMA window programming to an iommu_ops
> >>callback. pnv_pci_ioda2_set_window() takes an iommu_table_group as
> >>a first parameter (not pnv_ioda_pe) as it is going to be used as
> >>a callback for VFIO DDW code.
> >>
> >>This adds pnv_pci_ioda2_tvt_invalidate() to invalidate TVT as it is
> >>a good thing to do.
> >
> >What's the TVT and why is invalidating it a good thing?
>
>
> "TCE Validation Table". Yeah, I need to rephrase it. Will do.
>
>
> >Also, it looks like it didn't add it, just move it.
>
> Agrh. Lost it in rebases. Will fix.
>
>
> >>It does not have immediate effect now as the table
> >>is never recreated after reboot but it will in the following patches.
> >>
> >>This should cause no behavioural change.
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >>Reviewed-by: David Gibson
> >
> >Really? I don't remember this one.
>
>
> Message-ID: <20150416064351.gk3...@voom.redhat.com>
> :)
>
> But I believe it did not have TVT stuff then so I should have removed your
> RB from here.
Yeah, that's probably why I didn't recognize it.
>
> >
> >>---
> >>Changes:
> >>v9:
> >>* initialize pe->table_group.tables[0] at the very end when
> >>tbl is fully initialized
> >>* moved pnv_pci_ioda2_tvt_invalidate() from earlier patch
> >>---
> >> arch/powerpc/platforms/powernv/pci-ioda.c | 67
> >> +++
> >> 1 file changed, 51 insertions(+), 16 deletions(-)
> >>
> >>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>index b9b3773..59baa15 100644
> >>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>@@ -1960,6 +1960,52 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
> >>*phb,
> >>__free_pages(tce_mem, get_order(TCE32_TABLE_SIZE * segs));
> >> }
> >>
> >>+static long pnv_pci_ioda2_set_window(struct iommu_table_group *table_group,
> >>+ struct iommu_table *tbl)
> >>+{
> >>+ struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
> >>+ table_group);
> >>+ struct pnv_phb *phb = pe->phb;
> >>+ int64_t rc;
> >>+ const __u64 start_addr = tbl->it_offset << tbl->it_page_shift;
> >>+ const __u64 win_size = tbl->it_size << tbl->it_page_shift;
> >>+
> >>+ pe_info(pe, "Setting up window at %llx..%llx "
> >>+ "pgsize=0x%x tablesize=0x%lx\n",
> >>+ start_addr, start_addr + win_size - 1,
> >>+ 1UL << tbl->it_page_shift, tbl->it_size << 3);
> >>+
> >>+ tbl->it_table_group = >table_group;
> >>+
> >>+ /*
> >>+* Map TCE table through TVT. The TVE index is the PE number
> >>+* shifted by 1 bit for 32-bits DMA space.
> >>+*/
> >>+ rc = opal_pci_map_pe_dma_window(phb->opal_id,
> >>+ pe->pe_number,
> >>+ pe->pe_number << 1,
> >>+ 1,
> >>+ __pa(tbl->it_base),
> >>+ tbl->it_size << 3,
> >>+ 1ULL << tbl->it_page_shift);
> >>+ if (rc) {
> >>+ pe_err(pe, "Failed to configure TCE table, err %ld\n", rc);
> >>+ goto fail;
> >>+ }
> >>+
> >>+ pnv_pci_ioda2_tvt_invalidate(pe);
> >>+
> >>+ /* Store fully initialized *tbl (may be external) in PE */
> >>+ pe->table_group.tables[0] = *tbl;
> >
> >Hrm, a non-atomic copy of a whole structure into the array. Is that
> >really what you want?
>
>
> set_window is called from VFIO (protected by mutex there) and the platform
> code which I believe is not racy (or hotplug takes care of it anyway). Or I
> am missing something else?
Sorry, I wasn't clear. It's not that I actually think the copy is
going to race with anything now.
It's more that copying whole structures about is a rather odd way of
doing things, and makes it much less obvious how object lifetimes
interact.
From what I've seen of the rest of the series it seems like the
following scheme would make more sense:
* struct iommu_table has identical lifetime to the actual tables
allocated under it.
* So, the "create" function both allocates the header structure,
all the actual TCE tables under it, and fills in the header
with the details of same (size, levelsize, levels etc.)
* table_group would have an array of pointers to iommu_table
structs, rather than embedding an array of iommu_table structs
* This pointers would be optionally populated
* set_window function would populate the table_group array with
a previously "create"ed iommu_table
* unset window would clear the pointer, and unref the iommu_table
* "free" and "reset" for a single table would be rolled back into a
single function
Unless there's some reason I've missed that you
Re: [PATCH kernel v9 13/32] vfio: powerpc/spapr/iommu/powernv/ioda2: Rework IOMMU ownership control
On Wed, Apr 29, 2015 at 07:19:51PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 01:02 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:37PM +1000, Alexey Kardashevskiy wrote:
> >>This adds tce_iommu_take_ownership() and tce_iommu_release_ownership
> >>which call in a loop iommu_take_ownership()/iommu_release_ownership()
> >>for every table on the group. As there is just one now, no change in
> >>behaviour is expected.
> >>
> >>At the moment the iommu_table struct has a set_bypass() which enables/
> >>disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
> >>which calls this callback when external IOMMU users such as VFIO are
> >>about to get over a PHB.
> >>
> >>The set_bypass() callback is not really an iommu_table function but
> >>IOMMU/PE function. This introduces a iommu_table_group_ops struct and
> >>adds take_ownership()/release_ownership() callbacks to it which are
> >>called when an external user takes/releases control over the IOMMU.
> >>
> >>This replaces set_bypass() with ownership callbacks as it is not
> >>necessarily just bypass enabling, it can be something else/more
> >>so let's give it more generic name.
> >>
> >>The callbacks is implemented for IODA2 only. Other platforms (P5IOC2,
> >>IODA1) will use the old iommu_take_ownership/iommu_release_ownership API.
> >>The following patches will replace iommu_take_ownership/
> >>iommu_release_ownership calls in IODA2 with full IOMMU table release/
> >>create.
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >>[aw: for the vfio related changes]
> >>Acked-by: Alex Williamson
> >>---
> >>Changes:
> >>v9:
> >>* squashed "vfio: powerpc/spapr: powerpc/iommu: Rework IOMMU ownership
> >>control"
> >>and "vfio: powerpc/spapr: powerpc/powernv/ioda2: Rework IOMMU ownership
> >>control"
> >>into a single patch
> >>* moved helpers with a loop through tables in a group
> >>to vfio_iommu_spapr_tce.c to keep the platform code free of IOMMU table
> >>groups as much as possible
> >>* added missing tce_iommu_clear() to tce_iommu_release_ownership()
> >>* replaced the set_ownership(enable) callback with take_ownership() and
> >>release_ownership()
> >>---
> >> arch/powerpc/include/asm/iommu.h | 13 +-
> >> arch/powerpc/kernel/iommu.c | 11 --
> >> arch/powerpc/platforms/powernv/pci-ioda.c | 40 +++
> >> drivers/vfio/vfio_iommu_spapr_tce.c | 66
> >> +++
> >> 4 files changed, 103 insertions(+), 27 deletions(-)
> >>
> >>diff --git a/arch/powerpc/include/asm/iommu.h
> >>b/arch/powerpc/include/asm/iommu.h
> >>index fa37519..e63419e 100644
> >>--- a/arch/powerpc/include/asm/iommu.h
> >>+++ b/arch/powerpc/include/asm/iommu.h
> >>@@ -93,7 +93,6 @@ struct iommu_table {
> >>unsigned long it_page_shift;/* table iommu page size */
> >>struct iommu_table_group *it_table_group;
> >>struct iommu_table_ops *it_ops;
> >>- void (*set_bypass)(struct iommu_table *tbl, bool enable);
> >> };
> >>
> >> /* Pure 2^n version of get_order */
> >>@@ -128,11 +127,23 @@ extern struct iommu_table *iommu_init_table(struct
> >>iommu_table * tbl,
> >>
> >> #define IOMMU_TABLE_GROUP_MAX_TABLES 1
> >>
> >>+struct iommu_table_group;
> >>+
> >>+struct iommu_table_group_ops {
> >>+ /*
> >>+* Switches ownership from the kernel itself to an external
> >>+* user. While onwership is taken, the kernel cannot use IOMMU itself.
> >
> >Typo in "onwership". I'd also like to see this be even more explicit
> >that "take" is the "core kernel -> vfio/whatever" transition and
> >release is the reverse.
>
>
> Will this work?
>
> /*
> * Switches ownership from the kernel itself to an external
> * user.
> * The ownership is taken when VFIO starts using the IOMMU group
> * and released when the platform code gets the control over the group back.
> * While ownership is taken, the platform code cannot use IOMMU itself.
> */
Hrm, verbose and still doesn't emphasise the point that always
confuses me enough. I'd prefer:
/* Switch ownership from platform code to external user (e.g. VFIO) */
above "take" then
/* Switch ownership from external user (e.g. VFIO) back to core */
above "release"..
>
>
> >>+*/
> >>+ void (*take_ownership)(struct iommu_table_group *table_group);
> >>+ void (*release_ownership)(struct iommu_table_group *table_group);
> >>+};
> >>+
> >> struct iommu_table_group {
> >> #ifdef CONFIG_IOMMU_API
> >>struct iommu_group *group;
> >> #endif
> >>struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
> >>+ struct iommu_table_group_ops *ops;
> >> };
> >>
> >> #ifdef CONFIG_IOMMU_API
> >>diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> >>index 005146b..2856d27 100644
> >>--- a/arch/powerpc/kernel/iommu.c
> >>+++ b/arch/powerpc/kernel/iommu.c
> >>@@ -1057,13 +1057,6 @@ int iommu_take_ownership(struct iommu_table *tbl)
> >>
> >>memset(tbl->it_map, 0xff, sz);
> >>
> >>- /*
> >>-* Disable
Re: [PATCH kernel v9 16/32] powerpc/powernv/ioda: Move TCE kill register address to PE
On Wed, Apr 29, 2015 at 07:00:30PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 01:25 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:40PM +1000, Alexey Kardashevskiy wrote:
> >>At the moment the DMA setup code looks for the "ibm,opal-tce-kill" property
> >>which contains the TCE kill register address. Writes to this register
> >>invalidates TCE cache on IODA/IODA2 hub.
> >>
> >>This moves the register address from iommu_table to pnv_ioda_pe as
> >>later there will be 2 tables per PE and it will be used for both tables.
> >>
> >>This moves the property reading/remapping code to a helper to reduce
> >>code duplication.
> >>
> >>This adds a new pnv_pci_ioda2_tvt_invalidate() helper which invalidates
> >>the entire table. It should be called after every call to
> >>opal_pci_map_pe_dma_window(). It was not required before because
> >>there is just a single TCE table and 64bit DMA is handled via bypass
> >>window (which has no table so no chache is used) but this is going
> >>to change with Dynamic DMA windows (DDW).
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >>---
> >>Changes:
> >>v9:
> >>* new in the series
> >>---
> >> arch/powerpc/platforms/powernv/pci-ioda.c | 69
> >> +++
> >> arch/powerpc/platforms/powernv/pci.h | 1 +
> >> 2 files changed, 44 insertions(+), 26 deletions(-)
> >>
> >>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>index f070c44..b22b3ca 100644
> >>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>@@ -1672,7 +1672,7 @@ static void pnv_pci_ioda1_tce_invalidate(struct
> >>iommu_table *tbl,
> >>struct pnv_ioda_pe, table_group);
> >>__be64 __iomem *invalidate = rm ?
> >>(__be64 __iomem *)pe->tce_inval_reg_phys :
> >>- (__be64 __iomem *)tbl->it_index;
> >>+ pe->tce_inval_reg;
> >>unsigned long start, end, inc;
> >>const unsigned shift = tbl->it_page_shift;
> >>
> >>@@ -1743,6 +1743,18 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
> >>.get = pnv_tce_get,
> >> };
> >>
> >>+static inline void pnv_pci_ioda2_tvt_invalidate(struct pnv_ioda_pe *pe)
> >>+{
> >>+ /* 01xb - invalidate TCEs that match the specified PE# */
> >>+ unsigned long addr = (0x4ull << 60) | (pe->pe_number & 0xFF);
> >
> >This doesn't really look like an address, but rather the data you're
> >writing to the register.
>
>
> This thing is made of "invalidate operation" (0x4 here), "invalidate
> address" (pci address but it is zero here as we reset everything, most bits
> are here) and "invalidate PE number". So what should I call it? :)
Ah, I see. An address from the hardware point of view, but not so
much from the kernel point of view. Probably just call it 'val' or
'data'.
>
>
>
> >>+ if (!pe->tce_inval_reg)
> >>+ return;
> >>+
> >>+mb(); /* Ensure above stores are visible */
> >>+ __raw_writeq(cpu_to_be64(addr), pe->tce_inval_reg);
> >>+}
> >>+
> >> static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
> >>unsigned long index, unsigned long npages, bool rm)
> >> {
> >>@@ -1751,7 +1763,7 @@ static void pnv_pci_ioda2_tce_invalidate(struct
> >>iommu_table *tbl,
> >>unsigned long start, end, inc;
> >>__be64 __iomem *invalidate = rm ?
> >>(__be64 __iomem *)pe->tce_inval_reg_phys :
> >>- (__be64 __iomem *)tbl->it_index;
> >>+ pe->tce_inval_reg;
> >>const unsigned shift = tbl->it_page_shift;
> >>
> >>/* We'll invalidate DMA address in PE scope */
> >>@@ -1803,13 +1815,31 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops =
> >>{
> >>.get = pnv_tce_get,
> >> };
> >>
> >>+static void pnv_pci_ioda_setup_opal_tce_kill(struct pnv_phb *phb,
> >>+ struct pnv_ioda_pe *pe)
> >>+{
> >>+ const __be64 *swinvp;
> >>+
> >>+ /* OPAL variant of PHB3 invalidated TCEs */
> >>+ swinvp = of_get_property(phb->hose->dn, "ibm,opal-tce-kill", NULL);
> >>+ if (!swinvp)
> >>+ return;
> >>+
> >>+ /* We need a couple more fields -- an address and a data
> >>+* to or. Since the bus is only printed out on table free
> >>+* errors, and on the first pass the data will be a relative
> >>+* bus number, print that out instead.
> >>+*/
> >
> >The comment above appears to have nothing to do with the surrounding code.
>
> I'll just remove it.
Ok, good.
>
>
> >
> >>+ pe->tce_inval_reg_phys = be64_to_cpup(swinvp);
> >>+ pe->tce_inval_reg = ioremap(pe->tce_inval_reg_phys, 8);
> >>+}
> >>+
> >> static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
> >> struct pnv_ioda_pe *pe, unsigned int base,
> >> unsigned int segs)
> >> {
> >>
> >>struct page *tce_mem = NULL;
> >>- const __be64 *swinvp;
> >>struct iommu_table *tbl;
> >>unsigned int i;
> >>int64_t rc;
> >>@@ -1823,6
Re: [PATCH kernel v9 18/32] powerpc/iommu/powernv: Release replaced TCE
On Wed, Apr 29, 2015 at 07:51:21PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 02:18 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:42PM +1000, Alexey Kardashevskiy wrote:
> >>At the moment writing new TCE value to the IOMMU table fails with EBUSY
> >>if there is a valid entry already. However PAPR specification allows
> >>the guest to write new TCE value without clearing it first.
> >>
> >>Another problem this patch is addressing is the use of pool locks for
> >>external IOMMU users such as VFIO. The pool locks are to protect
> >>DMA page allocator rather than entries and since the host kernel does
> >>not control what pages are in use, there is no point in pool locks and
> >>exchange()+put_page(oldtce) is sufficient to avoid possible races.
> >>
> >>This adds an exchange() callback to iommu_table_ops which does the same
> >>thing as set() plus it returns replaced TCE and DMA direction so
> >>the caller can release the pages afterwards. The exchange() receives
> >>a physical address unlike set() which receives linear mapping address;
> >>and returns a physical address as the clear() does.
> >>
> >>This implements exchange() for P5IOC2/IODA/IODA2. This adds a requirement
> >>for a platform to have exchange() implemented in order to support VFIO.
> >>
> >>This replaces iommu_tce_build() and iommu_clear_tce() with
> >>a single iommu_tce_xchg().
> >>
> >>This makes sure that TCE permission bits are not set in TCE passed to
> >>IOMMU API as those are to be calculated by platform code from DMA direction.
> >>
> >>This moves SetPageDirty() to the IOMMU code to make it work for both
> >>VFIO ioctl interface in in-kernel TCE acceleration (when it becomes
> >>available later).
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >>[aw: for the vfio related changes]
> >>Acked-by: Alex Williamson
> >
> >This looks mostly good, but there are couple of details that need fixing.
> >
>
>
> [...]
>
> >>diff --git a/arch/powerpc/platforms/powernv/pci.c
> >>b/arch/powerpc/platforms/powernv/pci.c
> >>index ba75aa5..e8802ac 100644
> >>--- a/arch/powerpc/platforms/powernv/pci.c
> >>+++ b/arch/powerpc/platforms/powernv/pci.c
> >>@@ -598,6 +598,23 @@ int pnv_tce_build(struct iommu_table *tbl, long index,
> >>long npages,
> >>return 0;
> >> }
> >>
> >>+#ifdef CONFIG_IOMMU_API
> >>+int pnv_tce_xchg(struct iommu_table *tbl, long index,
> >>+ unsigned long *tce, enum dma_data_direction *direction)
> >>+{
> >>+ u64 proto_tce = iommu_direction_to_tce_perm(*direction);
> >>+ unsigned long newtce = *tce | proto_tce;
> >>+ unsigned long idx = index - tbl->it_offset;
> >
> >Should this have a BUG_ON or WARN_ON if the supplied tce has bits set
> >below the page mask?
>
>
> Why? The caller checks these bits, do we really need to duplicate it
> here?
Because this is the crunch point where bad bits will actually cause
strange stuff to happen.
As much as anything the point of a BUG_ON would be to document that
this function expects the parameter to be aligned.
>
>
> >>+ *tce = xchg(pnv_tce(tbl, idx), cpu_to_be64(newtce));
> >>+ *tce = be64_to_cpu(*tce);
> >>+ *direction = iommu_tce_direction(*tce);
> >>+ *tce &= ~(TCE_PCI_READ | TCE_PCI_WRITE);
> >>+
> >>+ return 0;
> >>+}
> >>+#endif
>
>
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpc9KLDF6COu.pgp
Description: PGP signature
Re: [PATCH kernel v9 09/32] vfio: powerpc/spapr: Rework groups attaching
On Thu, Apr 30, 2015 at 12:29:30PM +1000, Alexey Kardashevskiy wrote: > On 04/29/2015 12:16 PM, David Gibson wrote: > >On Sat, Apr 25, 2015 at 10:14:33PM +1000, Alexey Kardashevskiy wrote: > >>This is to make extended ownership and multiple groups support patches > >>simpler for review. > >> > >>This should cause no behavioural change. > > > >Um.. this doesn't appear to be true. Previously removing a group from > >an enabled container would fail with EBUSY, now it forces a disable. > > > This is the original tce_iommu_detach_group() where I cannot find EBUSY you > are referring to; it did and does enforce disable. What do I miss > here? Sorry, my mistake. I misread the patch. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpDzPis0dnBx.pgp Description: PGP signature
Re: [PATCH kernel v9 23/32] powerpc/powernv/ioda: Define and implement DMA table/window management callbacks
On Wed, Apr 29, 2015 at 07:44:20PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 03:30 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:47PM +1000, Alexey Kardashevskiy wrote:
> >>This extends iommu_table_group_ops by a set of callbacks to support
> >>dynamic DMA windows management.
> >>
> >>create_table() creates a TCE table with specific parameters.
> >>it receives iommu_table_group to know nodeid in order to allocate
> >>TCE table memory closer to the PHB. The exact format of allocated
> >>multi-level table might be also specific to the PHB model (not
> >>the case now though).
> >>This callback calculated the DMA window offset on a PCI bus from @num
> >>and stores it in a just created table.
> >>
> >>set_window() sets the window at specified TVT index + @num on PHB.
> >>
> >>unset_window() unsets the window from specified TVT.
> >>
> >>This adds a free() callback to iommu_table_ops to free the memory
> >>(potentially a tree of tables) allocated for the TCE table.
> >
> >Doesn't the free callback belong with the previous patch introducing
> >multi-level tables?
>
>
>
> If I did that, you would say "why is it here if nothing calls it" on
> "multilevel" patch and "I see the allocation but I do not see memory
> release" ;)
Yeah, fair enough ;)
> I need some rule of thumb here. I think it is a bit cleaner if the same
> patch adds a callback for memory allocation and its counterpart, no?
On further consideration, yes, I think you're right.
> >>create_table() and free() are supposed to be called once per
> >>VFIO container and set_window()/unset_window() are supposed to be
> >>called for every group in a container.
> >>
> >>This adds IOMMU capabilities to iommu_table_group such as default
> >>32bit window parameters and others.
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >>---
> >> arch/powerpc/include/asm/iommu.h| 19
> >> arch/powerpc/platforms/powernv/pci-ioda.c | 75
> >> ++---
> >> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 12 +++--
> >> 3 files changed, 96 insertions(+), 10 deletions(-)
> >>
> >>diff --git a/arch/powerpc/include/asm/iommu.h
> >>b/arch/powerpc/include/asm/iommu.h
> >>index 0f50ee2..7694546 100644
> >>--- a/arch/powerpc/include/asm/iommu.h
> >>+++ b/arch/powerpc/include/asm/iommu.h
> >>@@ -70,6 +70,7 @@ struct iommu_table_ops {
> >>/* get() returns a physical address */
> >>unsigned long (*get)(struct iommu_table *tbl, long index);
> >>void (*flush)(struct iommu_table *tbl);
> >>+ void (*free)(struct iommu_table *tbl);
> >> };
> >>
> >> /* These are used by VIO */
> >>@@ -148,6 +149,17 @@ extern struct iommu_table *iommu_init_table(struct
> >>iommu_table * tbl,
> >> struct iommu_table_group;
> >>
> >> struct iommu_table_group_ops {
> >>+ long (*create_table)(struct iommu_table_group *table_group,
> >>+ int num,
> >>+ __u32 page_shift,
> >>+ __u64 window_size,
> >>+ __u32 levels,
> >>+ struct iommu_table *tbl);
> >>+ long (*set_window)(struct iommu_table_group *table_group,
> >>+ int num,
> >>+ struct iommu_table *tblnew);
> >>+ long (*unset_window)(struct iommu_table_group *table_group,
> >>+ int num);
> >>/*
> >> * Switches ownership from the kernel itself to an external
> >> * user. While onwership is taken, the kernel cannot use IOMMU itself.
> >>@@ -160,6 +172,13 @@ struct iommu_table_group {
> >> #ifdef CONFIG_IOMMU_API
> >>struct iommu_group *group;
> >> #endif
> >>+ /* Some key properties of IOMMU */
> >>+ __u32 tce32_start;
> >>+ __u32 tce32_size;
> >>+ __u64 pgsizes; /* Bitmap of supported page sizes */
> >>+ __u32 max_dynamic_windows_supported;
> >>+ __u32 max_levels;
> >
> >With this information, table_group seems even more like a bad name.
> >"iommu_state" maybe?
>
>
> Please, no. We will never come to agreement then :( And "iommu_state" is too
> general anyway, it won't pass.
>
>
> >>struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
> >>struct iommu_table_group_ops *ops;
> >> };
> >>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>index cc1d09c..4828837 100644
> >>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
> >>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> >>@@ -24,6 +24,7 @@
> >> #include
> >> #include
> >> #include
> >>+#include
> >>
> >> #include
> >> #include
> >>@@ -1846,6 +1847,7 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops = {
> >> #endif
> >>.clear = pnv_ioda2_tce_free,
> >>.get = pnv_tce_get,
> >>+ .free = pnv_pci_free_table,
> >> };
> >>
> >> static void pnv_pci_ioda_setup_opal_tce_kill(struct pnv_phb *phb,
> >>@@ -1936,6 +1938,8 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
> >>*phb,
> >> TCE_PCI_SWINV_PAIR);
> >>
> >>tbl->it_ops =
Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus
On Wed, Apr 29, 2015 at 10:49 PM, Shreyas B Prabhu wrote: > > > On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote: >>> I am not sure if its worth the effort now. It doesn't look like any >>> other trace point apart from the above use case will benefit from it. >>> Only smbus_write and smbus_reply seem to come close. But even they need >>> separate TP_fast_assign. >> >> It shouldn't be a problem to implement. But I'm currently cleaning up >> those files, and any changes will cause nasty conflicts. >> >> Lets do this. Push the current changes as is, and when I get around to >> adding a DEFINE_EVENT_PRINT_CONDITION(), we can modify that code to use >> it. >> > Okay, sure. Looks good then. Reviewed-by: Preeti U Murthy > > Thanks, > Shreyas > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511
Sorry for the top-posting; Josh Boyer suggested I re-mail this mail
from last month which didn't get any replies. I'm still having this
weird kernel bug affecting me and I've bisected it down to like 2-4
lines of code. (I've thought more about my theory regarding
unsigned/signed below and it's probably wrong, so ignore my
prognosticating.) Please see my rhbz link near the bottom for the full
details.
Thanks everyone!
On 2015-03-23 Trevor Cordes wrote:
> Hello everyone, this is my first attempt at bisecting a kernel to
> solve a bug. Please bear with me.
>
> I have successfully bisected and located a commit that is causing my
> problem. Look at commit 166afb64511.
>
> ktime_to_us returns s64, but the commit changes it so ktime_to_us
> just returns what ktime_divns returns, and ktime_divns returns a
> u64! If the u64 is big enough, wouldn't it wrap s64 around to a
> negative number? Or, perhaps if some caller is passing in negative
> ktime_t to begin with it will trigger without having to hit big
> numbers. With my limited knowledge of C, I am stabbing in the dark
> here.
>
> That's just my guess as to why this commit causes my problem. My bug
> symptom is my previously working MythTV lirc blaster no longer
> reliably sends IR signals. Using irsend to test I can see irsend is
> just timing out (and only sometimes blasts, usually the first
> attempt). On good kernels it returns immediately after blasting.
>
> This little patch (at bottom of email) that puts the code back in
> place and gets rid of the function call fixes the problem for me. I
> applied this patch to the very latest FC21
> kernel-PAE-3.19.1-201.fc21.i686 src.rpm and rpmbuilded and the bug is
> gone! I can once again MythTV. Hooray.
>
> I suspect no one else is seeing this because less people are running
> 32-bit now, and perhaps in most code paths the value of the u64 never
> gets above 2^63. I suspect something in drivers/media (possibly) is
> passing very high or negative values (possibly another bug) to these
> calls.
>
> Obviously my patch isn't the real solution, the real solution is to
> make the new function calls use a consistent 64-bit type, or figure
> out what in my code path is calling these functions and check it for
> value sanity.
>
> I've documented the whole process / details of this bug in RHBZ:
> https://bugzilla.redhat.com/show_bug.cgi?id=1200353
>
> Thanks!
>
> diff -uNr a/include/linux/ktime.h b/include/linux/ktime.h
> --- a/include/linux/ktime.h 2015-02-08 20:54:22.0 -0600
> +++ b/include/linux/ktime.h 2015-03-23 01:09:43.0 -0500
> @@ -173,12 +173,16 @@
>
> static inline s64 ktime_to_us(const ktime_t kt)
> {
> - return ktime_divns(kt, NSEC_PER_USEC);
> +/* return ktime_divns(kt, NSEC_PER_USEC); */
> + struct timeval tv = ktime_to_timeval(kt);
> + return (s64) tv.tv_sec * USEC_PER_SEC + tv.tv_usec;
> }
>
> static inline s64 ktime_to_ms(const ktime_t kt)
> {
> - return ktime_divns(kt, NSEC_PER_MSEC);
> +/* return ktime_divns(kt, NSEC_PER_MSEC); */
> + struct timeval tv = ktime_to_timeval(kt);
> + return (s64) tv.tv_sec * MSEC_PER_SEC + tv.tv_usec /
> USEC_PER_MSEC; }
>
> static inline s64 ktime_us_delta(const ktime_t later, const ktime_t
> earlier)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[lm-sensors][PATCH v2] hwmon: (ntc_thermistor) Add support for ncpXXwf104
This patch adds support for the ntc thermistor NCPXXWF104 serises.
Cc: Jean Delvare
Cc: Guenter Roeck
Signed-off-by: Beomho Seo
---
Changes in v2
- Fix typo.
- Update Documents and Kconfig.
- Use murata instead of ntc.
- add entry to the murata list.
---
.../devicetree/bindings/hwmon/ntc_thermistor.txt |1 +
Documentation/hwmon/ntc_thermistor |6 ++-
drivers/hwmon/Kconfig |4 +-
drivers/hwmon/ntc_thermistor.c | 44
include/linux/platform_data/ntc_thermistor.h |1 +
5 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index fcca8e7..a04a80f 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -9,6 +9,7 @@ Requires node properties:
"murata,ncp21wb473"
"murata,ncp03wb473"
"murata,ncp15wl333"
+ "murata,ncp03wf104"
/* Usage of vendor name "ntc" is deprecated */
"ntc,ncp15wb473"
diff --git a/Documentation/hwmon/ntc_thermistor
b/Documentation/hwmon/ntc_thermistor
index c5e05e2..1d4cc84 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -2,8 +2,10 @@ Kernel driver ntc_thermistor
=
Supported thermistors from Murata:
-* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
NCP15WL333
- Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
'ncp15wl333'
+* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
+ NCP15WL333, NCP03WF104
+ Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
+ 'ncp15wl333', 'ncp03wf104'
Datasheet: Publicly available at Murata
Supported thermistors from EPCOS:
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 25d9e72..4542ffc 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1106,8 +1106,8 @@ config SENSORS_NTC_THERMISTOR
send notifications about the temperature.
Currently, this driver supports
- NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333
- from Murata and B57330V2103 from EPCOS.
+ NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, NCP15WL333,
+ and NCP03WF104 from Murata and B57330V2103 from EPCOS.
This driver can also be built as a module. If so, the module
will be called ntc-thermistor.
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index 112e4d4..09ece61 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -53,6 +53,7 @@ static const struct platform_device_id ntc_thermistor_id[] = {
{ "ncp03wb473", TYPE_NCPXXWB473 },
{ "ncp15wl333", TYPE_NCPXXWL333 },
{ "b57330v2103", TYPE_B57330V2103},
+ { "ncp03wf104", TYPE_NCPXXWF104 },
{ },
};
@@ -135,6 +136,43 @@ static const struct ntc_compensation ncpXXwl333[] = {
{ .temp_c = 125, .ohm = 707 },
};
+static const struct ntc_compensation ncpXXwf104[] = {
+ { .temp_c = -40, .ohm = 4397119 },
+ { .temp_c = -35, .ohm = 3088599 },
+ { .temp_c = -30, .ohm = 2197225 },
+ { .temp_c = -25, .ohm = 1581881 },
+ { .temp_c = -20, .ohm = 1151037 },
+ { .temp_c = -15, .ohm = 846579 },
+ { .temp_c = -10, .ohm = 628988 },
+ { .temp_c = -5, .ohm = 471632 },
+ { .temp_c = 0, .ohm = 357012 },
+ { .temp_c = 5, .ohm = 272500 },
+ { .temp_c = 10, .ohm = 209710 },
+ { .temp_c = 15, .ohm = 162651 },
+ { .temp_c = 20, .ohm = 127080 },
+ { .temp_c = 25, .ohm = 10 },
+ { .temp_c = 30, .ohm = 79222 },
+ { .temp_c = 35, .ohm = 63167 },
+ { .temp_c = 40, .ohm = 50677 },
+ { .temp_c = 45, .ohm = 40904 },
+ { .temp_c = 50, .ohm = 33195 },
+ { .temp_c = 55, .ohm = 27091 },
+ { .temp_c = 60, .ohm = 4 },
+ { .temp_c = 65, .ohm = 18323 },
+ { .temp_c = 70, .ohm = 15184 },
+ { .temp_c = 75, .ohm = 12635 },
+ { .temp_c = 80, .ohm = 10566 },
+ { .temp_c = 85, .ohm = 8873 },
+ { .temp_c = 90, .ohm = 7481 },
+ { .temp_c = 95, .ohm = 6337 },
+ { .temp_c = 100, .ohm = 5384 },
+ { .temp_c = 105, .ohm = 4594 },
+ { .temp_c = 110, .ohm = 3934 },
+ { .temp_c = 115, .ohm = 3380 },
+ { .temp_c = 120, .ohm = 2916 },
+ { .temp_c = 125, .ohm = 2522 },
+};
+
/*
* The following compensation
linux-next: manual merge of the akpm-current tree with the livepatching tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/kernel/machine_kexec_64.c between commit 4545c8988013 ("x86:
introduce kaslr_offset()") from the livepatching tree and commit
22543072a261 ("kdump, vmcoreinfo: report actual value of phys_base")
from the akpm-current 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 arch/x86/kernel/machine_kexec_64.c
index e1029633f664,ab48c252e661..
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@@ -335,7 -334,8 +335,8 @@@ void arch_crash_save_vmcoreinfo(void
VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
#endif
vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
-(unsigned long)&_text - __START_KERNEL);
+kaslr_offset());
+ VMCOREINFO_PHYS_BASE(phys_base);
}
/* arch-dependent functionality related to kexec file-based syscall */
pgpLQGrnGVWqT.pgp
Description: OpenPGP digital signature
[LKP] [block] 5a19fe29ba7: +5.4% boot-slabinfo.num_objs
/vm-kbuild-1G/boot/1/debian-x86_64-2015-02-07.cgz/x86_64-rhel/01060bfb79987cf1b7b2012c5bfbc3ae6d7a7e78/0" LKP_SERVER: inn job_file: "/lkp/scheduled/vm-kbuild-1G-2/boot_boot-1-debian-x86_64.cgz-x86_64-rhel-01060bfb79987cf1b7b2012c5bfbc3ae6d7a7e78-1-20150429-10021-1gr1afy.yaml" dequeue_time: 2015-04-29 09:57:54.469064783 +08:00 initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz" bootloader_append: - root=/dev/ram0 - user=lkp - job=/lkp/scheduled/vm-kbuild-1G-2/boot_boot-1-debian-x86_64.cgz-x86_64-rhel-01060bfb79987cf1b7b2012c5bfbc3ae6d7a7e78-1-20150429-10021-1gr1afy.yaml - ARCH=x86_64 - kconfig=x86_64-rhel - branch=linux-devel/devel-hourly-2015042901 - commit=01060bfb79987cf1b7b2012c5bfbc3ae6d7a7e78 - BOOT_IMAGE=/kernel/x86_64-rhel/01060bfb79987cf1b7b2012c5bfbc3ae6d7a7e78/vmlinuz-4.1.0-rc1-01009-g01060bf - RESULT_ROOT=/result/vm-kbuild-1G/boot/1/debian-x86_64-2015-02-07.cgz/x86_64-rhel/01060bfb79987cf1b7b2012c5bfbc3ae6d7a7e78/0 - LKP_SERVER=inn - |2- earlyprintk=ttyS0,115200 rd.udev.log-priority=err systemd.log_target=journal systemd.log_level=warning debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw max_uptime: 600 lkp_initrd: "/lkp/lkp/lkp-x86_64.cgz" modules_initrd: "/kernel/x86_64-rhel/01060bfb79987cf1b7b2012c5bfbc3ae6d7a7e78/modules.cgz" bm_initrd: "/osimage/deps/debian-x86_64-2015-02-07.cgz/lkp.cgz" job_state: finished loadavg: 0.05 0.01 0.01 1/355 721 start_time: '1430272709' end_time: '1430272710' version: "/lkp/lkp/.src-20150429-092245" ___ LKP mailing list l...@linux.intel.com
Re: Tux3 Report: How fast can we fsync?
On Thu, 2015-04-30 at 07:06 +0900, OGAWA Hirofumi wrote: > Yeah, I also want to know hardware. Also, what size of partition? And > each test was done by fresh FS (i.e. after mkfs), or same FS was used > through all tests? 1TB rust bucket, with new fs each test. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Tux3 Report: How fast can we fsync?
On Wed, 2015-04-29 at 13:40 -0700, Daniel Phillips wrote: > On Wednesday, April 29, 2015 9:42:43 AM PDT, Mike Galbraith wrote: > > > > [dbench bakeoff] > > > > With dbench v4.00, tux3 seems to be king of the max_latency hill, but > > btrfs took throughput on my box. With v3.04, tux3 took 1st place at > > splashing about in pagecache, but last place at dbench -S. > > > > Hohum, curiosity satisfied. > > Hi Mike, > > Thanks for that. Please keep in mind, that was our B team, it does a > full fs sync for every fsync. Maybe a rematch when the shiny new one > lands? Also, hardware? It looks like a single 7200 RPM disk, but it > would be nice to know. And it seems, not all dbench 4.0 are equal. > Mine doesn't have a -B option. Hm, mine came from git://git.samba.org/sahlberg/dbench.git. The thing has all kinds of cool options I have no clue how to use. Yeah, the box is a modern plane jane, loads of CPU, cheap a$$ spinning rust IO. It has an SSD, but that's currently occupied by games OS. I'll eventually either buy a bigger one or steal it from winders. The only thing stopping me is my inherent mistrust of storage media that has no moving parts, but wears out anyway, and with no bearings whining to warn you :) > That order of magnitude latency difference is striking. It sounds > good, but what does it mean? I see a smaller difference here, maybe > because of running under KVM. That max_latency thing is flush. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 00/17] Re-introduce h8300 architecture
At Wed, 29 Apr 2015 10:07:45 -0700, Guenter Roeck wrote: > > On Wed, Apr 29, 2015 at 03:22:40PM +0900, Yoshinori Sato wrote: > [ ... ] > > > > OK. > > I made h8300-*-linux target patch for release version. > > Please apply and rebuild to "h8300-unknown-linux" > > http://sourceforge.jp/projects/uclinux-h8/releases/p14625 > > > > My toolchain configure options bellow > > * binutils > > ../configure --prefix=/home/ysato/h8-linux --target=h8300-unknown-linux > > > > * gcc > > ../configure --target=h8300-unknown-linux --prefix=/home/ysato/h8-linux \ > > --disable-ssp --disable-libssp --disable-mpc --disable-gmp --disable-mpfr \ > > --disable-threads --disable-shared --disable-libmudflap --disable-libgomp \ > > --disable-zlib --disable-libquadmath --without-libc --disable-libatomic \ > > --enable-languages=c > > > Compilation passes with those patches - thanks a lot! > > I get lots of warnings if I compile with C=1. Might be worthwhile looking at > those. It might also be a good idea to provide the functions found missing > when building "make allyesconfig". > > Thanks, > Guenter OK. I trying allyesconfig. Thanks. -- Yoshinori Sato -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/21] ARCNET: Defibrillation
On Mon, 2015-04-27 at 16:57 +0200, Michael Grzeschik wrote: > Hi! > > On Fri, Apr 24, 2015 at 11:58:53PM -0400, David Miller wrote: > > From: Marc Kleine-Budde > > Date: Fri, 24 Apr 2015 23:14:41 +0200 > > > > > On 04/24/2015 08:47 PM, Joe Perches wrote: > > >> On Fri, 2015-04-24 at 19:20 +0200, Michael Grzeschik wrote: > > >>> Hi! > > >> > > >> Hello. > > >> > > >>> This patch series tries to reanimate the ARCNET hardware layer to be > > >>> somehow readable and maintainable again. It includes a lot of cleanup > > >>> patches. It also adds some fixes which leads the layer to become usable > > >>> again. And as a special treatment it adds more features like correct > > >>> loading and unloading of the com20020 card. > > >> > > >> Wow. Good for you, but why? Does anyone still use these? > > > > > > Yes, there are parts of the industry where "old" machines are > > > retrofitted with new hardware...and a lot of these machines still talk > > > ARCNET :) > > > > But the real issue is, this layer is development wise in the same > > category as the IDE layer. > > > > Any non-trivial change is nothing but pure risk, especially given the > > low level of test coverage the code gets. > > Do you count coding style patches as non-trivial or trivial > patches? > > > So I really only want to see the most critical obvious bug fixes > > submitted for this layer and drivers. > > The cleanup changes I submitted should not change the actual behaviour. > Replacing the register access macros with their equivalent outb/inb > seems pretty obvious. What is your opinion on those? > > I see that the "ARCNET: whitespace, tab and codingstyle fixes" patch is > pretty mixed up and not very reliable. But Joe has sent me a nice series > for the cleanup. > > > And no I will not accept an argument stating that you have to > > restructure and clean this code up in order to fix the bugs. That's > > bogus. > > OK. > > I have the following patches in this series which fix bugs found during > my development: > > com20020-pci: add dev_port for udev handling > ARCNET: fix hard_header_len limit > ARCNET: com20020: add enable and disable device on open/close > > I would send a new series containing only those patches with more > detailed patch descriptions, if that's fine with you? I was away for a few days and while out I did another restructuring of all the inb/outb/readb/writeb code removing all the A macros. It removes all the dependencies on ioaddr and names all the offsets with new defines. I could post if you like. I think it's a lot cleaner and easier to read. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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][Fix] cpuidle: Run tick_broadcast_exit() with disabled interrupts
On 04/29/2015 07:37 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Commit 335f49196fd6 (sched/idle: Use explicit broadcast oneshot
> control function) replaced clockevents_notify() invocations in
> cpuidle_idle_call() with direct calls to tick_broadcast_enter()
> and tick_broadcast_exit(), but it overlooked the fact that
> interrupts were already enabled before calling the latter which
> led to functional breakage on systems using idle states with the
> CPUIDLE_FLAG_TIMER_STOP flag set.
>
> Fix that by moving the invocations of tick_broadcast_enter()
> and tick_broadcast_exit() down into cpuidle_enter_state() where
> interrupts are still disabled when tick_broadcast_exit() is
> called. Also ensure that interrupts will be disabled before
> running tick_broadcast_exit() even if they have been enabled by
> the idle state's ->enter callback. Trigger a WARN_ON_ONCE() in
> that case, as we generally don't want that to happen for states
> with CPUIDLE_FLAG_TIMER_STOP set.
>
> Fixes: 335f49196fd6 (sched/idle: Use explicit broadcast oneshot control
> function)
> Reported-and-tested-by: Linus Walleij
> Acked-by: Peter Zijlstra (Intel)
> Acked-by: Daniel Lezcano
> Reported-and-tested-by: Sudeep Holla
> Signed-off-by: Rafael J. Wysocki
> ---
>
> Thanks for the testing and ACKs, here it goes again with all tags and
> a changelog.
>
> If anything is missing/incorrect, please let me know ASAP as I'm going to
> push this to Linus in a couple of days.
>
> ---
> drivers/cpuidle/cpuidle.c | 16
> kernel/sched/idle.c | 16 ++--
> 2 files changed, 18 insertions(+), 14 deletions(-)
>
> Index: linux-pm/kernel/sched/idle.c
> ===
> --- linux-pm.orig/kernel/sched/idle.c
> +++ linux-pm/kernel/sched/idle.c
> @@ -81,7 +81,6 @@ static void cpuidle_idle_call(void)
> struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
> struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
> int next_state, entered_state;
> - unsigned int broadcast;
> bool reflect;
>
> /*
> @@ -150,17 +149,6 @@ static void cpuidle_idle_call(void)
> goto exit_idle;
> }
>
> - broadcast = drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP;
> -
> - /*
> - * Tell the time framework to switch to a broadcast timer
> - * because our local timer will be shutdown. If a local timer
> - * is used from another cpu as a broadcast timer, this call may
> - * fail if it is not available
> - */
> - if (broadcast && tick_broadcast_enter())
> - goto use_default;
> -
> /* Take note of the planned idle state. */
> idle_set_state(this_rq(), >states[next_state]);
>
> @@ -174,8 +162,8 @@ static void cpuidle_idle_call(void)
> /* The cpu is no longer idle or about to enter idle. */
> idle_set_state(this_rq(), NULL);
>
> - if (broadcast)
> - tick_broadcast_exit();
> + if (entered_state == -EBUSY)
> + goto use_default;
>
> /*
>* Give the governor an opportunity to reflect on the outcome
> Index: linux-pm/drivers/cpuidle/cpuidle.c
> ===
> --- linux-pm.orig/drivers/cpuidle/cpuidle.c
> +++ linux-pm/drivers/cpuidle/cpuidle.c
> @@ -158,9 +158,18 @@ int cpuidle_enter_state(struct cpuidle_d
> int entered_state;
>
> struct cpuidle_state *target_state = >states[index];
> + bool broadcast = !!(target_state->flags & CPUIDLE_FLAG_TIMER_STOP);
> ktime_t time_start, time_end;
> s64 diff;
>
> + /*
> + * Tell the time framework to switch to a broadcast timer because our
> + * local timer will be shut down. If a local timer is used from another
> + * CPU as a broadcast timer, this call may fail if it is not available.
> + */
> + if (broadcast && tick_broadcast_enter())
> + return -EBUSY;
> +
> trace_cpu_idle_rcuidle(index, dev->cpu);
> time_start = ktime_get();
>
> @@ -169,6 +178,13 @@ int cpuidle_enter_state(struct cpuidle_d
> time_end = ktime_get();
> trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
>
> + if (broadcast) {
> + if (WARN_ON_ONCE(!irqs_disabled()))
> + local_irq_disable();
> +
> + tick_broadcast_exit();
> + }
> +
> if (!cpuidle_state_is_coupled(dev, drv, entered_state))
> local_irq_enable();
>
Reviewed-by: Preeti U Murthy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCH 16/20] sched/idle: Use explicit broadcast oneshot control function
On 04/29/2015 06:34 AM, Rafael J. Wysocki wrote: > On Wednesday, April 29, 2015 02:50:22 AM Rafael J. Wysocki wrote: >> On Tuesday, April 28, 2015 02:58:37 PM Sudeep Holla wrote: >>> >>> On 28/04/15 15:14, Rafael J. Wysocki wrote: On Tuesday, April 28, 2015 03:37:44 PM Rafael J. Wysocki wrote: > On Tuesday, April 28, 2015 03:31:54 PM Rafael J. Wysocki wrote: >> On Tuesday, April 28, 2015 02:37:10 PM Linus Walleij wrote: >>> On Tue, Apr 28, 2015 at 2:19 PM, Rafael J. Wysocki >>> wrote: Sudeep: > At-least I observed issue only when I am using hardware broadcast > timer. > It doesn't hang when I am using hrtimer as broadcast timer in which > case > one of the cpu will be not enter deeper idle states that lose timer. > I will rerun on v4.1-rc1 and post the complete log. So the bug here is that cpuidle_enter() enables interrupts, so the assumption about them being not enabled made by tick_broadcast_oneshot_control() is actually not valid. It looks like we need to acquire the clockevents_lock at least in this particular case. Let me see where to put it and I'll send a patch for testing. >>> >>> Aha that looks very much like it. Put me on the patch and I'll >>> take it for a spin. >> >> OK, so something like the below for starters (the _irqsave variant is >> used to >> avoid adding one more WARN_ON(irqs_disabled()) in there). >> >> I haven't tested it, but then I can't reproduce the original issue in the >> first place. > > Of course, the whole "broadcast" thing could be done from cpuidle_enter() > in the first place, but then we could not avoid the problem with the > cpuidle > *callback* enabling interrupts possibly in there anyway (not to mention > the > "coupled" stuff). That said, if the given state is marked with CPUIDLE_FLAG_TIMER_STOP, I really wouldn't expect it to re-enable interrupts on exit and the "coupled" thing seems to be fundamentally at odds with that flag either. So it should be possible to move the "broadcast" logic into the cpuidle layer, which I'm going to try to do. >>> >>> Makes sense. >>> Please test the patch I've sent, though, as it should bring the code back to where it was before the clockevents_notify() removal and it'd be good to verify that. >>> >>> I tested your patch and it works now. Anyways I am continuing to run >>> stress tests on my board. I will report if I find any issues. >> >> Great, thanks! >> >> Below is the patch I came up with in the meantime. >> >> This moves the "switch to broadcast" timer logic into >> cpuidle_enter_state() which allows tick_broadcast_exit() to be >> called directly with interrupts disabled (as required), but >> it also adds a fallback branch reflecting the 4.0 and earlier >> behavior for idle states that enable interrupts on exit >> from their ->enter callbacks. >> >> I'm not aware of any valid cases when CPUIDLE_FLAG_TIMER_STOP can be >> set for such states, but people may try to add stuff like that in the >> future, so it's better to catch that (hence the WARN_ON_ONCE) and do >> our best to handle it gracefully anyway, IMO. >> >> The "if (entered_state == -EBUSY)" check is conservative. It may >> be better to do "if (entered_state < 0)" and fall back to the default >> on all errors, but that's not what we do today (I guess the concern >> would be "what if the state ->enter returns an error after entering >> and exiting the idle state, in which case we may miss a wakeup event >> if we fall back to the default"). > > Actually, if my understanding of things is correct (the local clock event > device cannot go away from under code executed with interrupts disabled > on the local CPU), the simplified one below should be sufficient. > > --- > drivers/cpuidle/cpuidle.c | 16 > kernel/sched/idle.c | 16 ++-- > 2 files changed, 18 insertions(+), 14 deletions(-) > > Index: linux-pm/kernel/sched/idle.c > === > --- linux-pm.orig/kernel/sched/idle.c > +++ linux-pm/kernel/sched/idle.c > @@ -81,7 +81,6 @@ static void cpuidle_idle_call(void) > struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices); > struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev); > int next_state, entered_state; > - unsigned int broadcast; > bool reflect; > > /* > @@ -150,17 +149,6 @@ static void cpuidle_idle_call(void) > goto exit_idle; > } > > - broadcast = drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP; > - > - /* > - * Tell the time framework to switch to a broadcast timer > - * because our local timer will be shutdown. If a local timer > - * is used from another cpu as a
RE: [PATCH v8] extcon-axp288: Add axp288 extcon driver support
> > This patch adds the extcon support for AXP288 PMIC which has the BC1.2 > > charger detection capability. Additionally it also adds the USB mux > > switching support b/w SOC and PMIC based on GPIO control. > > > > Signed-off-by: Ramakrishna Pallala > > When you send next versions, the convention is for you to apply Acks that > you've collected. Ok.. Do you want me to resubmit the patch? > > --- > > drivers/extcon/Kconfig |7 + > > drivers/extcon/Makefile|1 + > > drivers/extcon/extcon-axp288.c | 386 > > > include/linux/mfd/axp20x.h |5 + > > 4 files changed, 399 insertions(+) > > create mode 100644 drivers/extcon/extcon-axp288.c > > > > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index > > fdc0bf0..2305edc 100644 > > --- a/drivers/extcon/Kconfig > > +++ b/drivers/extcon/Kconfig > > @@ -28,6 +28,13 @@ config EXTCON_ARIZONA > > with Wolfson Arizona devices. These are audio CODECs with > > advanced audio accessory detection support. > > > > +config EXTCON_AXP288 > > + tristate "X-Power AXP288 EXTCON support" > > + depends on MFD_AXP20X && USB_PHY > > + help > > + Say Y here to enable support for USB peripheral detection > > + and USB MUX switching by X-Power AXP288 PMIC. > > + > > config EXTCON_GPIO > > tristate "GPIO extcon support" > > depends on GPIOLIB > > diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile index > > 9204114..ba787d0 100644 > > --- a/drivers/extcon/Makefile > > +++ b/drivers/extcon/Makefile > > @@ -5,6 +5,7 @@ > > obj-$(CONFIG_EXTCON) += extcon.o > > obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o > > obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o > > +obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o > > obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o > > obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o > > obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o > > diff --git a/drivers/extcon/extcon-axp288.c > > b/drivers/extcon/extcon-axp288.c new file mode 100644 index > > 000..ea61bf2 > > --- /dev/null > > +++ b/drivers/extcon/extcon-axp288.c > > @@ -0,0 +1,386 @@ > > +/* > > + * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection > > +driver > > + * > > + * Copyright (C) 2015 Intel Corporation > > + * Author: Ramakrishna Pallala > > + * > > + * This program is free software; you can redistribute it and/or > > +modify > > + * it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > + * > > + * 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. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* Power source status register */ > > +#define PS_STAT_VBUS_TRIGGER BIT(0) > > +#define PS_STAT_BAT_CHRG_DIR BIT(2) > > +#define PS_STAT_VBUS_ABOVE_VHOLD BIT(3) > > +#define PS_STAT_VBUS_VALID BIT(4) > > +#define PS_STAT_VBUS_PRESENT BIT(5) > > + > > +/* BC module global register */ > > +#define BC_GLOBAL_RUN BIT(0) > > +#define BC_GLOBAL_DET_STAT BIT(2) > > +#define BC_GLOBAL_DBP_TOUT BIT(3) > > +#define BC_GLOBAL_VLGC_COM_SEL BIT(4) > > +#define BC_GLOBAL_DCD_TOUT_MASK(BIT(6)|BIT(5)) > > +#define BC_GLOBAL_DCD_TOUT_300MS 0 > > +#define BC_GLOBAL_DCD_TOUT_100MS 1 > > +#define BC_GLOBAL_DCD_TOUT_500MS 2 > > +#define BC_GLOBAL_DCD_TOUT_900MS 3 > > +#define BC_GLOBAL_DCD_DET_SEL BIT(7) > > + > > +/* BC module vbus control and status register */ > > +#define VBUS_CNTL_DPDM_PD_EN BIT(4) > > +#define VBUS_CNTL_DPDM_FD_EN BIT(5) > > +#define VBUS_CNTL_FIRST_PO_STATBIT(6) > > + > > +/* BC USB status register */ > > +#define USB_STAT_BUS_STAT_MASK (BIT(3)|BIT(2)|BIT(1)|BIT(0)) > > +#define USB_STAT_BUS_STAT_SHIFT0 > > +#define USB_STAT_BUS_STAT_ATHD 0 > > +#define USB_STAT_BUS_STAT_CONN 1 > > +#define USB_STAT_BUS_STAT_SUSP 2 > > +#define USB_STAT_BUS_STAT_CONF 3 > > +#define USB_STAT_USB_SS_MODE BIT(4) > > +#define USB_STAT_DEAD_BAT_DET BIT(6) > > +#define USB_STAT_DBP_UNCFG BIT(7) > > + > > +/* BC detect status register */ > > +#define DET_STAT_MASK (BIT(7)|BIT(6)|BIT(5)) > > +#define DET_STAT_SHIFT 5 > > +#define DET_STAT_SDP 1 > > +#define DET_STAT_CDP 2 > > +#define DET_STAT_DCP
Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)
On Thu, 2015-04-30 at 10:20 +1000, Dave Chinner wrote: > IOWS, XFS just hates your disk. Spend $50 and buy a cheap SSD and > the problem goes away. :) I'd love to. Too bad sorry sack of sh*t MB manufacturer only applied _connectors_ to 4 of 6 available ports, and they're all in use :) > > > And now in more detail. Thanks for those details, made perfect sense. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MIPS: BMIPS: Delete unused Kconfig symbol
Le 04/28/15 10:52, Kevin Cernekee a écrit : > This was left over from an earlier iteration of the BMIPS irqchip changes. > It doesn't actually have an effect, so let's nuke it. > > Reported-by: Valentin Rothberg > Signed-off-by: Kevin Cernekee Acked-by: Florian Fainelli > --- > > > Ralf - could you please pull this for 4.1? > > > arch/mips/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index f5016656494f..19e5d40fdf40 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -147,7 +147,6 @@ config BMIPS_GENERIC > select BCM7120_L2_IRQ > select BRCMSTB_L2_IRQ > select IRQ_CPU > - select RAW_IRQ_ACCESSORS > select DMA_NONCOHERENT > select SYS_SUPPORTS_32BIT_KERNEL > select SYS_SUPPORTS_LITTLE_ENDIAN > -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [lm-sensors][PATCH] hwmon: (ntc_thermistor) Add support for ncpXXwf104
On 04/29/2015 07:25 PM, Beomho Seo wrote:
This patch adds support for the ntc thermistor NCPXXWF104 serise.
s/serise/series
Cc: Jean Delvare
Cc: Guenter Roeck
Signed-off-by: Beomho Seo
---
drivers/hwmon/ntc_thermistor.c | 45 ++
include/linux/platform_data/ntc_thermistor.h |1 +
Please also update
Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
Documentation/hwmon/ntc_thermistor
drivers/hwmon/Kconfig
2 files changed, 46 insertions(+)
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index 112e4d4..a320664 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -53,6 +53,7 @@ static const struct platform_device_id ntc_thermistor_id[] = {
{ "ncp03wb473", TYPE_NCPXXWB473 },
{ "ncp15wl333", TYPE_NCPXXWL333 },
{ "b57330v2103", TYPE_B57330V2103},
+ { "ncp03wf104", TYPE_NCPXXWF104 },
{ },
};
@@ -135,6 +136,43 @@ static const struct ntc_compensation ncpXXwl333[] = {
{ .temp_c = 125, .ohm = 707 },
};
+static const struct ntc_compensation ncpXXwf104[] = {
+ { .temp_c = -40, .ohm = 4397119 },
+ { .temp_c = -35, .ohm = 3088599 },
+ { .temp_c = -30, .ohm = 2197225 },
+ { .temp_c = -25, .ohm = 1581881 },
+ { .temp_c = -20, .ohm = 1151037 },
+ { .temp_c = -15, .ohm = 846579 },
+ { .temp_c = -10, .ohm = 628988 },
+ { .temp_c = -5, .ohm = 471632 },
+ { .temp_c = 0, .ohm = 357012 },
+ { .temp_c = 5, .ohm = 272500 },
+ { .temp_c = 10, .ohm = 209710 },
+ { .temp_c = 15, .ohm = 162651 },
+ { .temp_c = 20, .ohm = 127080 },
+ { .temp_c = 25, .ohm = 10 },
+ { .temp_c = 30, .ohm = 79222 },
+ { .temp_c = 35, .ohm = 63167 },
+ { .temp_c = 40, .ohm = 50677 },
+ { .temp_c = 45, .ohm = 40904 },
+ { .temp_c = 50, .ohm = 33195 },
+ { .temp_c = 55, .ohm = 27091 },
+ { .temp_c = 60, .ohm = 4 },
+ { .temp_c = 65, .ohm = 18323 },
+ { .temp_c = 70, .ohm = 15184 },
+ { .temp_c = 75, .ohm = 12635 },
+ { .temp_c = 80, .ohm = 10566 },
+ { .temp_c = 85, .ohm = 8873 },
+ { .temp_c = 90, .ohm = 7481 },
+ { .temp_c = 95, .ohm = 6337 },
+ { .temp_c = 100, .ohm = 5384 },
+ { .temp_c = 105, .ohm = 4594 },
+ { .temp_c = 110, .ohm = 3934 },
+ { .temp_c = 115, .ohm = 3380 },
+ { .temp_c = 120, .ohm = 2916 },
+ { .temp_c = 125, .ohm = 2522 },
+};
+
/*
* The following compensation table is from the specification of EPCOS NTC
* Thermistors Datasheet
@@ -231,6 +269,9 @@ static const struct of_device_id ntc_match[] = {
.data = _thermistor_id[3] },
{ .compatible = "ntc,ncp15wl333",
.data = _thermistor_id[4] },
+ { .compatible = "ntc,ncp03wf104",
Please use murata instead of ntc (see the devicetree bindings document),
and add the entry to the murata list.
+ .data = _thermistor_id[6] },
+
{ },
};
MODULE_DEVICE_TABLE(of, ntc_match);
@@ -558,6 +599,10 @@ static int ntc_thermistor_probe(struct platform_device
*pdev)
data->comp = b57330v2103;
data->n_comp = ARRAY_SIZE(b57330v2103);
break;
+ case TYPE_NCPXXWF104:
+ data->comp = ncpXXwf104;
+ data->n_comp = ARRAY_SIZE(ncpXXwf104);
+ break;
default:
dev_err(>dev, "Unknown device type: %lu(%s)\n",
pdev_id->driver_data, pdev_id->name);
diff --git a/include/linux/platform_data/ntc_thermistor.h
b/include/linux/platform_data/ntc_thermistor.h
index 0a6de4c..aed1705 100644
--- a/include/linux/platform_data/ntc_thermistor.h
+++ b/include/linux/platform_data/ntc_thermistor.h
@@ -27,6 +27,7 @@ enum ntc_thermistor_type {
TYPE_NCPXXWB473,
TYPE_NCPXXWL333,
TYPE_B57330V2103,
+ TYPE_NCPXXWF104,
};
struct ntc_thermistor_platform_data {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc/hv-24x7: Check support before registering PMU
We currently try to register the 24x7 PMU unconditionally. Not all
Power systems support 24x7 counters (eg: Power7). On these systems
we get a backtrace during boot when trying to register the 24x7 PMU.
Check if the hypervisor supports 24x7 counters before attempting to
register the 24x7 PMU.
Reported-by: Gustavo Luiz Duarte
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/perf/hv-24x7.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index ec2eb20..19a59a3 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1268,12 +1268,44 @@ static struct pmu h_24x7_pmu = {
.read= h_24x7_event_read,
};
+/*
+ * Return 1 if we can access the 24x7 counter catalog from the hypervisor.
+ * Return 0 otherwise.
+ */
+static int hv_has_24x7(void)
+{
+ int page_size = 4096;
+ unsigned long hret;
+ void *page;
+ struct hv_24x7_catalog_page_0 *page_0;
+
+ page_0 = kmalloc(page_size*2, GFP_KERNEL);
+ if (!page_0)
+ return 0;
+
+ /* buffer for catalog needs to be 4K-aligned */
+ page = (void *)((long)page_0 & (~page_size-1)) + page_size;
+ hret = h_get_24x7_catalog_page(page, 0, 0);
+ kfree(page_0);
+
+ if (hret) {
+ pr_devel("Error %ld reading catalog, disabling 24x7 PMU\n",
hret);
+ return 0;
+ }
+
+ return 1;
+}
+
+
static int hv_24x7_init(void)
{
int r;
unsigned long hret;
struct hv_perf_caps caps;
+ if (!hv_has_24x7())
+ return -ENODEV;
+
if (!firmware_has_feature(FW_FEATURE_LPAR)) {
pr_debug("not a virtualized system, not enabling\n");
return -ENODEV;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v9 15/32] powerpc/powernv/ioda/ioda2: Rework TCE invalidation in tce_build()/tce_free()
On 04/29/2015 01:18 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:39PM +1000, Alexey Kardashevskiy wrote:
The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
supposed to be called on IODA1/2 and not called on p5ioc2. It receives
start and end host addresses of TCE table.
IODA2 actually needs PCI addresses to invalidate the cache. Those
can be calculated from host addresses but since we are going
to implement multi-level TCE tables, calculating PCI address from
a host address might get either tricky or ugly as TCE table remains flat
on PCI bus but not in RAM.
This moves pnv_pci_ioda_tce_invalidate() from generic pnv_tce_build/
pnt_tce_free and defines IODA1/2-specific callbacks which call generic
ones and do PHB-model-specific TCE cache invalidation. P5IOC2 keeps
using generic callbacks as before.
This changes pnv_pci_ioda2_tce_invalidate() to receives TCE index and
number of pages which are PCI addresses shifted by IOMMU page shift.
No change in behaviour is expected.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v9:
* removed confusing comment from commit log about unintentional calling of
pnv_pci_ioda_tce_invalidate()
* moved mechanical changes away to "powerpc/iommu: Move tce_xxx callbacks from
ppc_md to iommu_table"
* fixed bug with broken invalidation in pnv_pci_ioda2_tce_invalidate -
@index includes @tbl->it_offset but old code added it anyway which later broke
DDW
---
arch/powerpc/platforms/powernv/pci-ioda.c | 86 +--
arch/powerpc/platforms/powernv/pci.c | 17 ++
2 files changed, 64 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 718d5cc..f070c44 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1665,18 +1665,20 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe
*pe,
}
}
-static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
-struct iommu_table *tbl,
-__be64 *startp, __be64 *endp, bool rm)
+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
{
+ struct pnv_ioda_pe *pe = container_of(tbl->it_table_group,
+ struct pnv_ioda_pe, table_group);
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe->tce_inval_reg_phys :
(__be64 __iomem *)tbl->it_index;
unsigned long start, end, inc;
const unsigned shift = tbl->it_page_shift;
- start = __pa(startp);
- end = __pa(endp);
+ start = __pa((__be64 *)tbl->it_base + index - tbl->it_offset);
+ end = __pa((__be64 *)tbl->it_base + index - tbl->it_offset +
+ npages - 1);
This doesn't look right. The arguments to __pa don't appear to be
addresses (since index and if_offset are in units of (TCE) pages, not
bytes).
tbl->it_base is an address and it is casted to __be64* which means:
(char*)tbl->it_base + (index - tbl->it_offset)*sizeof(__be64).
Which seems to be correct (I just removed extra braces compared to the old
code), no?
/* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
if (tbl->it_busno) {
@@ -1712,16 +1714,40 @@ static void pnv_pci_ioda1_tce_invalidate(struct
pnv_ioda_pe *pe,
*/
}
+static int pnv_ioda1_tce_build(struct iommu_table *tbl, long index,
+ long npages, unsigned long uaddr,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ long ret = pnv_tce_build(tbl, index, npages, uaddr, direction,
+ attrs);
+
+ if (!ret && (tbl->it_type & TCE_PCI_SWINV_CREATE))
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+
+ return ret;
+}
+
+static void pnv_ioda1_tce_free(struct iommu_table *tbl, long index,
+ long npages)
+{
+ pnv_tce_free(tbl, index, npages);
+
+ if (tbl->it_type & TCE_PCI_SWINV_FREE)
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+}
+
static struct iommu_table_ops pnv_ioda1_iommu_ops = {
- .set = pnv_tce_build,
- .clear = pnv_tce_free,
+ .set = pnv_ioda1_tce_build,
+ .clear = pnv_ioda1_tce_free,
.get = pnv_tce_get,
};
-static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
-struct iommu_table *tbl,
-__be64 *startp, __be64 *endp, bool rm)
+static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
{
+ struct pnv_ioda_pe *pe = container_of(tbl->it_table_group,
+ struct pnv_ioda_pe, table_group);
unsigned long start, end, inc;
__be64
Re: [PATCH 9/9] sysfs: disallow world-writable files.
Gobinda Maji writes: > Hi Rusty, Hi Gobinda, > I have a small doubt about the permission restriction (User perms >= > group perms >= other perms) in VERIFY_OCTAL_PERMISSIONS(). Please Note > that permission field of User, Group or Other consists of three bits. > LSB is EXECUTE permission, MSB is READ permission and the middle bit > is WRITE permission. Say for example, permission value is "0431". Here > User has only READ permission whereas Group has both WRITE and EXECUTE > permission and Other has EXECUTE permission. I guess, it is not good > to give Group the WRITE permission whereas User itself has no WRITE > permission. You're absolutely right, well spotted! The checks can be tightened. We don't really care about execute, but logically write is "more privileged" than read. Best to separate the tests; OTHER_WRITABLE <= GROUP_WRITABLE <= OWNER_WRITABLE and OTHER_READABLE <= GROUP_READABLE <= OWNER_READABLE. A patch would be welcome! Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v1 0/5] clk: support clocks which requires parent clock on during operation
Hi Guys, On Wed, Apr 22, 2015 at 02:12:43PM +0800, Dong Aisheng wrote: > On Wed, Apr 15, 2015 at 10:26:34PM +0800, Dong Aisheng wrote: > > This patch series adds support in clock framework for clocks which > > operations > > requires its parent clock is on. > > > > Such clock type is initially met on Freescale i.MX7D platform that all > > clocks > > operations, including enable/disable, rate change and re-parent, requires > > its > > parent clock on. No sure if any other SoC has the similar clock type. > > > > Current clock core can not support such type of clock well. > > > > This patch introduce a new flag CLK_SET_PARENT_ON to handle this special > > case > > in clock core that enable its parent clock firstly for each operation and > > disable > > it later after operation complete. > > > > The most special case is for set_parent() operation which requires both > > parent, > > old one and new one, to be enabled at the same time during the operation. > > > > Patch 1~3 are minor cleanup & fixes. > > Patch 4 add CLK_SET_PARENT_ON flags in clock core to support such type > > clocks > > Patch 5 show the need of introducing clk_core_enable_lock and > > clk_core_disable_lock to easily use and reduce duplicated code. > > It can be merged into patch 4 if required. > > > > The patch series is based on for-next branch of Michael's git: > > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > > > > Dong Aisheng (5): > > clk: change clk_core name of __clk_set_parent_after > > clk: add missing lock when call clk_core_enable in clk_set_parent > > clk: remove unneeded __clk_enable and __clk_disable > > clk: core: add CLK_SET_PARENT_ON flags to support clocks require > > parent on > > clk: introduce clk_core_enable_lock and clk_core_disable_lock > > functions > > > > Gentle Ping. > Ping again.. Any comments about this patch series? Regards Dong Aisheng > Regards > Dong Aisheng > > > drivers/clk/clk.c| 112 > > ++- > > include/linux/clk-provider.h | 5 ++ > > 2 files changed, 94 insertions(+), 23 deletions(-) > > > > -- > > 1.9.1 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 linux-next] cpufreq: pxa: replace typedef pxa_freqs_t by structure
On 30 April 2015 at 01:02, Fabian Frederick wrote: > typedef is not really useful here. Replace it by structure > to improve readability.typedef should only be used in some cases. Space after full stop. (Maybe Rafael can fix that while applying).. > (See Documentation/CodingStyle Chapter 5 for details). > > Signed-off-by: Fabian Frederick > --- > V2: verbose changelog. > > drivers/cpufreq/pxa2xx-cpufreq.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Module stacking next steps
On 04/29/2015 06:55 PM, James Morris wrote: > On Tue, 21 Apr 2015, Casey Schaufler wrote: > >> >> James, do you want to take the module stacking changes in through >> the security tree? Are there remaining objections or concerns? What >> procedure would you like to follow? > > What's the overall consensus on this -- do people generally see it as > useful and necessary, and is it ready to go in? > > Any objections or concerns? > No objections, and I know there are several people interested in seeing this land. I am happy with the code, and my only concerns lie with things that this explicitly doesn't support yet (ie. larger lsm stacking, secids, ...) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 12/32] powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group
On 04/29/2015 12:49 PM, David Gibson wrote: On Sat, Apr 25, 2015 at 10:14:36PM +1000, Alexey Kardashevskiy wrote: Modern IBM POWERPC systems support multiple (currently two) TCE tables per IOMMU group (a.k.a. PE). This adds a iommu_table_group container for TCE tables. Right now just one table is supported. For P5IOC2 and IODA, iommu_table_group is embedded into PE struct (pnv_ioda_pe and pnv_phb) and does not require iommu_free_table(), only . iommu_reset_table(). For pSeries, this replaces multiple calls of kzalloc_node() with a new iommu_pseries_group_alloc() helper and stores the table group struct pointer into the pci_dn struct. For release, a iommu_table_group_free() helper is added. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy [aw: for the vfio related changes] Acked-by: Alex Williamson I'm not particularly fond of the "table_group" name, but I can't really think of a better name for now. So, I asked Ben again. iommu_state is not much better either. I'd stick to iommu_table_group. Reviewed-by: David Gibson -- Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v9 09/32] vfio: powerpc/spapr: Rework groups attaching
On 04/29/2015 12:16 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:33PM +1000, Alexey Kardashevskiy wrote:
This is to make extended ownership and multiple groups support patches
simpler for review.
This should cause no behavioural change.
Um.. this doesn't appear to be true. Previously removing a group from
an enabled container would fail with EBUSY, now it forces a disable.
This is the original tce_iommu_detach_group() where I cannot find EBUSY you
are referring to; it did and does enforce disable. What do I miss here?
static void tce_iommu_detach_group(void *iommu_data,
struct iommu_group *iommu_group)
{
struct tce_container *container = iommu_data;
struct iommu_table *tbl = iommu_group_get_iommudata(iommu_group);
BUG_ON(!tbl);
mutex_lock(>lock);
if (tbl != container->tbl) {
pr_warn("tce_vfio: detaching group #%u, expected group is
#%u\n",
iommu_group_id(iommu_group),
iommu_group_id(tbl->it_group));
} else {
if (container->enabled) {
pr_warn("tce_vfio: detaching group #%u from
enabled container, forcing disable\n",
iommu_group_id(tbl->it_group));
tce_iommu_disable(container);
}
/* pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
iommu_group_id(iommu_group), iommu_group); */
container->tbl = NULL;
tce_iommu_clear(container, tbl, tbl->it_offset, tbl->it_size);
iommu_release_ownership(tbl);
}
mutex_unlock(>lock);
}
Signed-off-by: Alexey Kardashevskiy
[aw: for the vfio related changes]
Acked-by: Alex Williamson
Reviewed-by: David Gibson
---
drivers/vfio/vfio_iommu_spapr_tce.c | 40 ++---
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 115d5e6..0fbe03e 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -460,16 +460,21 @@ static int tce_iommu_attach_group(void *iommu_data,
iommu_group_id(container->tbl->it_group),
iommu_group_id(iommu_group));
ret = -EBUSY;
- } else if (container->enabled) {
+ goto unlock_exit;
+ }
+
+ if (container->enabled) {
pr_err("tce_vfio: attaching group #%u to enabled container\n",
iommu_group_id(iommu_group));
ret = -EBUSY;
- } else {
- ret = iommu_take_ownership(tbl);
- if (!ret)
- container->tbl = tbl;
+ goto unlock_exit;
}
+ ret = iommu_take_ownership(tbl);
+ if (!ret)
+ container->tbl = tbl;
+
+unlock_exit:
mutex_unlock(>lock);
return ret;
@@ -487,19 +492,22 @@ static void tce_iommu_detach_group(void *iommu_data,
pr_warn("tce_vfio: detaching group #%u, expected group is
#%u\n",
iommu_group_id(iommu_group),
iommu_group_id(tbl->it_group));
- } else {
- if (container->enabled) {
- pr_warn("tce_vfio: detaching group #%u from enabled
container, forcing disable\n",
- iommu_group_id(tbl->it_group));
- tce_iommu_disable(container);
- }
+ goto unlock_exit;
+ }
- /* pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
- iommu_group_id(iommu_group), iommu_group); */
- container->tbl = NULL;
- tce_iommu_clear(container, tbl, tbl->it_offset, tbl->it_size);
- iommu_release_ownership(tbl);
+ if (container->enabled) {
+ pr_warn("tce_vfio: detaching group #%u from enabled container,
forcing disable\n",
+ iommu_group_id(tbl->it_group));
+ tce_iommu_disable(container);
}
+
+ /* pr_debug("tce_vfio: detaching group #%u from iommu %p\n",
+ iommu_group_id(iommu_group), iommu_group); */
+ container->tbl = NULL;
+ tce_iommu_clear(container, tbl, tbl->it_offset, tbl->it_size);
+ iommu_release_ownership(tbl);
+
+unlock_exit:
mutex_unlock(>lock);
}
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[lm-sensors][PATCH] hwmon: (ntc_thermistor) Add support for ncpXXwf104
This patch adds support for the ntc thermistor NCPXXWF104 serise.
Cc: Jean Delvare
Cc: Guenter Roeck
Signed-off-by: Beomho Seo
---
drivers/hwmon/ntc_thermistor.c | 45 ++
include/linux/platform_data/ntc_thermistor.h |1 +
2 files changed, 46 insertions(+)
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index 112e4d4..a320664 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -53,6 +53,7 @@ static const struct platform_device_id ntc_thermistor_id[] = {
{ "ncp03wb473", TYPE_NCPXXWB473 },
{ "ncp15wl333", TYPE_NCPXXWL333 },
{ "b57330v2103", TYPE_B57330V2103},
+ { "ncp03wf104", TYPE_NCPXXWF104 },
{ },
};
@@ -135,6 +136,43 @@ static const struct ntc_compensation ncpXXwl333[] = {
{ .temp_c = 125, .ohm = 707 },
};
+static const struct ntc_compensation ncpXXwf104[] = {
+ { .temp_c = -40, .ohm = 4397119 },
+ { .temp_c = -35, .ohm = 3088599 },
+ { .temp_c = -30, .ohm = 2197225 },
+ { .temp_c = -25, .ohm = 1581881 },
+ { .temp_c = -20, .ohm = 1151037 },
+ { .temp_c = -15, .ohm = 846579 },
+ { .temp_c = -10, .ohm = 628988 },
+ { .temp_c = -5, .ohm = 471632 },
+ { .temp_c = 0, .ohm = 357012 },
+ { .temp_c = 5, .ohm = 272500 },
+ { .temp_c = 10, .ohm = 209710 },
+ { .temp_c = 15, .ohm = 162651 },
+ { .temp_c = 20, .ohm = 127080 },
+ { .temp_c = 25, .ohm = 10 },
+ { .temp_c = 30, .ohm = 79222 },
+ { .temp_c = 35, .ohm = 63167 },
+ { .temp_c = 40, .ohm = 50677 },
+ { .temp_c = 45, .ohm = 40904 },
+ { .temp_c = 50, .ohm = 33195 },
+ { .temp_c = 55, .ohm = 27091 },
+ { .temp_c = 60, .ohm = 4 },
+ { .temp_c = 65, .ohm = 18323 },
+ { .temp_c = 70, .ohm = 15184 },
+ { .temp_c = 75, .ohm = 12635 },
+ { .temp_c = 80, .ohm = 10566 },
+ { .temp_c = 85, .ohm = 8873 },
+ { .temp_c = 90, .ohm = 7481 },
+ { .temp_c = 95, .ohm = 6337 },
+ { .temp_c = 100, .ohm = 5384 },
+ { .temp_c = 105, .ohm = 4594 },
+ { .temp_c = 110, .ohm = 3934 },
+ { .temp_c = 115, .ohm = 3380 },
+ { .temp_c = 120, .ohm = 2916 },
+ { .temp_c = 125, .ohm = 2522 },
+};
+
/*
* The following compensation table is from the specification of EPCOS NTC
* Thermistors Datasheet
@@ -231,6 +269,9 @@ static const struct of_device_id ntc_match[] = {
.data = _thermistor_id[3] },
{ .compatible = "ntc,ncp15wl333",
.data = _thermistor_id[4] },
+ { .compatible = "ntc,ncp03wf104",
+ .data = _thermistor_id[6] },
+
{ },
};
MODULE_DEVICE_TABLE(of, ntc_match);
@@ -558,6 +599,10 @@ static int ntc_thermistor_probe(struct platform_device
*pdev)
data->comp = b57330v2103;
data->n_comp = ARRAY_SIZE(b57330v2103);
break;
+ case TYPE_NCPXXWF104:
+ data->comp = ncpXXwf104;
+ data->n_comp = ARRAY_SIZE(ncpXXwf104);
+ break;
default:
dev_err(>dev, "Unknown device type: %lu(%s)\n",
pdev_id->driver_data, pdev_id->name);
diff --git a/include/linux/platform_data/ntc_thermistor.h
b/include/linux/platform_data/ntc_thermistor.h
index 0a6de4c..aed1705 100644
--- a/include/linux/platform_data/ntc_thermistor.h
+++ b/include/linux/platform_data/ntc_thermistor.h
@@ -27,6 +27,7 @@ enum ntc_thermistor_type {
TYPE_NCPXXWB473,
TYPE_NCPXXWL333,
TYPE_B57330V2103,
+ TYPE_NCPXXWF104,
};
struct ntc_thermistor_platform_data {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: imx5: Add dts files for USB armory.
Hi Peter, On Tue, Apr 28, 2015 at 5:20 AM, Peter Chen wrote: > Current chipidea usb driver supports role switch function well, if you > have a gpio or id pin for it. On mx6 we are able to perform OTG role-switch funtion as they have the OTG_ID pins. We are talking about mx53 here, which does not have such OTG_ID pins, so not sure how they can perform role-switch in run-time? Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: build failure after merge of the sound-asoc tree
Dear All,
I will send a patch to fix it immediately.
Thanks.
Bard Liao
Computer Peripherals Business Unit
Realtek Semiconductor Corp.
886-3-578-0211 ext. 3334
bardl...@realtek.com
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Thursday, April 30, 2015 10:06 AM
> To: Mark Brown; Liam Girdwood
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Bard Liao
> Subject: linux-next: build failure after merge of the sound-asoc tree
>
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> sound/soc/codecs/rt5645.c: In function 'rt5645_set_jack_detect':
> sound/soc/codecs/rt5645.c:2555:2: error: implicit declaration of function
> 'rt5645_irq_detection' [-Werror=implicit-function-declaration]
> rt5645_irq_detection(rt5645);
> ^
> sound/soc/codecs/rt5645.c: At top level:
> sound/soc/codecs/rt5645.c:2591:12: error: static declaration of
> 'rt5645_irq_detection' follows non-static declaration static int
> rt5645_irq_detection(struct rt5645_priv *rt5645)
> ^
> sound/soc/codecs/rt5645.c:2555:2: note: previous implicit declaration of
> 'rt5645_irq_detection' was here
> rt5645_irq_detection(rt5645);
> ^
> sound/soc/codecs/rt5645.c:2591:12: warning: 'rt5645_irq_detection'
> defined but not used [-Wunused-function] static int
> rt5645_irq_detection(struct rt5645_priv *rt5645)
> ^
>
> Caused by commit 6e747d5311fc ("ASoC: rt5645: Adds push button
> support for rt5650").
>
> I have used the sound-asoc tree from next-20150429 for today.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> --Please consider the environment before printing this e-mail.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] extcon: Unify the dock device names on MAX8997/77693
On 27.04.2015 21:31, Chanwoo Choi wrote: This patch change the name of various dock devices as 'DOCK' because the name of various dock devices have not the standard naming rules. The name of dock devices include the differenct word but it is ambiguous and never important information on user-space aspect. This patch unifies the name of dock devices as following: - Dock-Smart -->|--> DOCK - Dock-Desk-->| - Dock-Audio -->| - Dock-Card-->| Cc: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] extcon: Alter MHL-TA cable name to TA cable name
On 27.04.2015 21:31, Chanwoo Choi wrote: This patch alters the MHL-TA cable name to TA cable name because MHL-TA is not standard name. The MHL-TA is MHL cable with charger cable (TA or USB). So, this patch use the TA cable instead of MHL-TA to inform the charger cable state. - MHL-TA -> TA Cc: Jaewon Kim Cc: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi --- drivers/extcon/extcon-max77693.c | 12 +--- drivers/extcon/extcon-max77843.c | 6 ++ 2 files changed, 7 insertions(+), 11 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Module stacking next steps
On Thu, Apr 30, 2015 at 11:55:51AM +1000, James Morris wrote: > On Tue, 21 Apr 2015, Casey Schaufler wrote: > > > > > James, do you want to take the module stacking changes in through > > the security tree? Are there remaining objections or concerns? What > > procedure would you like to follow? > > What's the overall consensus on this -- do people generally see it as > useful and necessary, and is it ready to go in? At the very worst, I see it as a very nice clean up. At best, I see it as extremely useful for the things I want to do, with various "minor" LSM working together. > Any objections or concerns? As far as I'm concerned, I'm very happy with it. Thanks! -Kees -- Kees Cook@outflux.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] extcon: Modify the name of unused external connector
On 28.04.2015 17:40, Chanwoo Choi wrote:
On Tue, Apr 28, 2015 at 12:43 PM, Krzysztof Kozlowski
wrote:
On 27.04.2015 21:31, Chanwoo Choi wrote:
This patchset alter the unused name of external connector (jig/dock/MHL)
as
following. The name of jig cable and dock device include the non-standard
H/W
information. On user-space side, this information are not necessary. The
extcon
core will support the other method to inform the specific H/W information
to
kernel device driver and framework. For example, extcon core have the plan
to add
the notifier chain for USB ID/VBUS pin state. If extcon consumer (kernel
device
driver and framework) use the notifer chain for USB ID/VBUS, they can get
the
state of both JIG and USB when JIG-USB-ON cable is attached.
And last patch removes the unused 'num_cables' filed on extcon-adc-jack.c.
1. jig cable name
- JIG-USB-ON -->|
- JIG-USB-OFF -->|
- JIG-UART-ON -->|
- JIG-UART-OFF -->|--> JIG
2. dock device name
- Dock-Smart -->|
- Dock-Desk-->|
- Dock-Audio -->|
- Dock-Card-->|--> DOCK
3. MHL-TA cable name
- MHL-TA -> TA
Hi,
That makes sense but isn't such change a break of interface with user-space?
The user-space may expect Dock-xxx for Dock.
I guess it's possible. But, the "Dock-{Smart|Desk|Audio}" device name are not
standard. Their name are only used for Samsung Galaxy S3 (releaesd 3.0
kernel) and it is not for mainline kernel.
So, I want to make the standard cable name for mainline kernel and user-space.
The extcon driver will send the event of 'dock' device with specific
external connector which is connected to 'dock' device.
For example, Dock-Smart means the Dock device with MHL cable. When
Dock-Smart is attached, extcon driver will send the two external
connector state of
both 'DOCK' and 'MHL'. So, the user-space process will detect the kind of dock
by catching both 'DOCK' and 'MHL' uevent.
Okay, one more concern - for Dock-Smart the extcon will send two
consecutive events (first DOCK, then MHL). So to distinguish this from
two separate connections of Dock and MHL (user first connects some Dock,
disconnects, connects MHL), the driver always has to call
extcon_set_cable_state(edev, "Dock", false) after disconnection.
Without the "disconnect" state this case would mean for userspace
"Dock+MHL".
This looks like an important part of API for extcon and for driver
implementations. So it should be documented somewhere?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
sound/soc/codecs/rt5645.c: In function 'rt5645_set_jack_detect':
sound/soc/codecs/rt5645.c:2555:2: error: implicit declaration of function
'rt5645_irq_detection' [-Werror=implicit-function-declaration]
rt5645_irq_detection(rt5645);
^
sound/soc/codecs/rt5645.c: At top level:
sound/soc/codecs/rt5645.c:2591:12: error: static declaration of
'rt5645_irq_detection' follows non-static declaration
static int rt5645_irq_detection(struct rt5645_priv *rt5645)
^
sound/soc/codecs/rt5645.c:2555:2: note: previous implicit declaration of
'rt5645_irq_detection' was here
rt5645_irq_detection(rt5645);
^
sound/soc/codecs/rt5645.c:2591:12: warning: 'rt5645_irq_detection' defined but
not used [-Wunused-function]
static int rt5645_irq_detection(struct rt5645_priv *rt5645)
^
Caused by commit 6e747d5311fc ("ASoC: rt5645: Adds push button support
for rt5650").
I have used the sound-asoc tree from next-20150429 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpW1G00KRmUk.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/4] extcon: Unify the jig cable names on RT8963 and MAX14577/77693/77843
On 04/30/2015 11:00 AM, Krzysztof Kozlowski wrote:
> On 27.04.2015 21:31, Chanwoo Choi wrote:
>> This patch change the name of various jig cables as 'JIG' because the name of
>> various jig cables are strange and ambiguous on user-space aspect. They
>> include
>> the different information of either USB and UART state. It is never important
>> for user-space process. This patch unifies the name of jig cables as
>> following:
>> - JIG-USB-ON -->|--> JIG
>> - JIG-USB-OFF -->|
>> - JIG-UART-ON -->|
>> - JIG-UART-OFF -->|
>>
>> Cc: Jaewon Kim
>> Cc: Krzysztof Kozlowski
>> Signed-off-by: Chanwoo Choi
>> ---
>> drivers/extcon/extcon-max14577.c | 19 +++
>> drivers/extcon/extcon-max77693.c | 23 +++
>> drivers/extcon/extcon-max77843.c | 39
>> ++-
>> drivers/extcon/extcon-rt8973a.c | 22 +-
>> 4 files changed, 25 insertions(+), 78 deletions(-)
>>
[snip]
>> struct max77843_muic_irq {
>> @@ -385,36 +379,31 @@ static int max77843_muic_jig_handler(struct
>> max77843_muic_info *info,
>> int cable_type, bool attached)
>> {
>> int ret;
>> +u8 path = CTRL1_SW_OPEN;
>>
>> dev_dbg(info->dev, "external connector is %s (adc:0x%02x)\n",
>> attached ? "attached" : "detached", cable_type);
>>
>> switch (cable_type) {
>> case MAX77843_MUIC_ADC_FACTORY_MODE_USB_OFF:
>> -ret = max77843_muic_set_path(info, CONTROL1_SW_USB, attached);
>> -if (ret < 0)
>> -return ret;
>> -extcon_set_cable_state(info->edev, "JIG-USB-OFF", attached);
>> -break;
>> case MAX77843_MUIC_ADC_FACTORY_MODE_USB_ON:
>> -ret = max77843_muic_set_path(info, CONTROL1_SW_USB, attached);
>> -if (ret < 0)
>> -return ret;
>> -extcon_set_cable_state(info->edev, "JIG-USB-ON", attached);
>> +path = CONTROL1_SW_USB;
>> break;
>> case MAX77843_MUIC_ADC_FACTORY_MODE_UART_OFF:
>> -ret = max77843_muic_set_path(info, CONTROL1_SW_UART, attached);
>> -if (ret < 0)
>> -return ret;
>> -extcon_set_cable_state(info->edev, "JIG-UART-OFF", attached);
>> +path = CONTROL1_SW_UART;
>> break;
>> default:
>> -ret = max77843_muic_set_path(info, CONTROL1_SW_OPEN, attached);
>> -if (ret < 0)
>> -return ret;
>> -break;
>> +dev_err(info->dev, "failed to detect %s jig cable\n",
>> +attached ? "attached" : "detached");
>> +return -EINVAL;
>
> The logic for this default case is changed and it is not related to the patch
> (unification of JIG). Could you split it into separate patch?
>
> Rest looks fine.
OK. I'll split out.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] extcon: Unify the jig cable names on RT8963 and MAX14577/77693/77843
On 27.04.2015 21:31, Chanwoo Choi wrote:
This patch change the name of various jig cables as 'JIG' because the name of
various jig cables are strange and ambiguous on user-space aspect. They include
the different information of either USB and UART state. It is never important
for user-space process. This patch unifies the name of jig cables as following:
- JIG-USB-ON -->|--> JIG
- JIG-USB-OFF -->|
- JIG-UART-ON -->|
- JIG-UART-OFF -->|
Cc: Jaewon Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-max14577.c | 19 +++
drivers/extcon/extcon-max77693.c | 23 +++
drivers/extcon/extcon-max77843.c | 39 ++-
drivers/extcon/extcon-rt8973a.c | 22 +-
4 files changed, 25 insertions(+), 78 deletions(-)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 3823aa4..6d5febe 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -155,10 +155,7 @@ enum {
EXTCON_CABLE_FAST_CHARGER,
EXTCON_CABLE_SLOW_CHARGER,
EXTCON_CABLE_CHARGE_DOWNSTREAM,
- EXTCON_CABLE_JIG_USB_ON,
- EXTCON_CABLE_JIG_USB_OFF,
- EXTCON_CABLE_JIG_UART_OFF,
- EXTCON_CABLE_JIG_UART_ON,
+ EXTCON_CABLE_JIG,
_EXTCON_CABLE_NUM,
};
@@ -169,10 +166,7 @@ static const char *max14577_extcon_cable[] = {
[EXTCON_CABLE_FAST_CHARGER] = "Fast-charger",
[EXTCON_CABLE_SLOW_CHARGER] = "Slow-charger",
[EXTCON_CABLE_CHARGE_DOWNSTREAM]= "Charge-downstream",
- [EXTCON_CABLE_JIG_USB_ON] = "JIG-USB-ON",
- [EXTCON_CABLE_JIG_USB_OFF] = "JIG-USB-OFF",
- [EXTCON_CABLE_JIG_UART_OFF] = "JIG-UART-OFF",
- [EXTCON_CABLE_JIG_UART_ON] = "JIG-UART-ON",
+ [EXTCON_CABLE_JIG] = "JIG",
NULL,
};
@@ -348,7 +342,6 @@ static int max14577_muic_get_cable_type(struct
max14577_muic_info *info,
static int max14577_muic_jig_handler(struct max14577_muic_info *info,
int cable_type, bool attached)
{
- char cable_name[32];
int ret = 0;
u8 path = CTRL1_SW_OPEN;
@@ -358,18 +351,12 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
switch (cable_type) {
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_OFF:/* ADC_JIG_USB_OFF */
- /* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-OFF");
- path = CTRL1_SW_USB;
- break;
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_ON: /* ADC_JIG_USB_ON */
/* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-ON");
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_UART_OFF: /* ADC_JIG_UART_OFF */
/* PATH:AP_UART */
- strcpy(cable_name, "JIG-UART-OFF");
path = CTRL1_SW_UART;
break;
default:
@@ -382,7 +369,7 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, cable_name, attached);
+ extcon_set_cable_state(info->edev, "JIG", attached);
return 0;
}
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index a66bec8..1079321 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -209,10 +209,7 @@ enum {
EXTCON_CABLE_CHARGE_DOWNSTREAM,
EXTCON_CABLE_MHL,
EXTCON_CABLE_MHL_TA,
- EXTCON_CABLE_JIG_USB_ON,
- EXTCON_CABLE_JIG_USB_OFF,
- EXTCON_CABLE_JIG_UART_OFF,
- EXTCON_CABLE_JIG_UART_ON,
+ EXTCON_CABLE_JIG,
EXTCON_CABLE_DOCK_SMART,
EXTCON_CABLE_DOCK_DESK,
EXTCON_CABLE_DOCK_AUDIO,
@@ -229,10 +226,7 @@ static const char *max77693_extcon_cable[] = {
[EXTCON_CABLE_CHARGE_DOWNSTREAM]= "Charge-downstream",
[EXTCON_CABLE_MHL] = "MHL",
[EXTCON_CABLE_MHL_TA] = "MHL-TA",
- [EXTCON_CABLE_JIG_USB_ON] = "JIG-USB-ON",
- [EXTCON_CABLE_JIG_USB_OFF] = "JIG-USB-OFF",
- [EXTCON_CABLE_JIG_UART_OFF] = "JIG-UART-OFF",
- [EXTCON_CABLE_JIG_UART_ON] = "JIG-UART-ON",
+ [EXTCON_CABLE_JIG] = "JIG",
[EXTCON_CABLE_DOCK_SMART] = "Dock-Smart",
[EXTCON_CABLE_DOCK_DESK]= "Dock-Desk",
[EXTCON_CABLE_DOCK_AUDIO] = "Dock-Audio",
@@ -642,7 +636,6 @@ static int max77693_muic_adc_ground_handler(struct
max77693_muic_info *info)
static int max77693_muic_jig_handler(struct max77693_muic_info *info,
int cable_type, bool attached)
{
- char cable_name[32];
int ret = 0;
u8 path
Re: Module stacking next steps
On Tue, 21 Apr 2015, Casey Schaufler wrote: > > James, do you want to take the module stacking changes in through > the security tree? Are there remaining objections or concerns? What > procedure would you like to follow? What's the overall consensus on this -- do people generally see it as useful and necessary, and is it ready to go in? Any objections or concerns? -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 3/3] clk: mmp: add timer clock for pxa168/mmp2/pxa910
From: Chao Xie
Timer has external fast clock, and it is a mux clock.
Add the timer clock type for timer driver.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/clk-of-mmp2.c | 6 ++
drivers/clk/mmp/clk-of-pxa168.c| 7 +++
drivers/clk/mmp/clk-of-pxa910.c| 11 +++
include/dt-bindings/clock/marvell,mmp2.h | 1 +
include/dt-bindings/clock/marvell,pxa168.h | 2 ++
include/dt-bindings/clock/marvell,pxa910.h | 3 +++
6 files changed, 30 insertions(+)
diff --git a/drivers/clk/mmp/clk-of-mmp2.c b/drivers/clk/mmp/clk-of-mmp2.c
index b7e0b89..251533d 100644
--- a/drivers/clk/mmp/clk-of-mmp2.c
+++ b/drivers/clk/mmp/clk-of-mmp2.c
@@ -30,6 +30,7 @@
#define APBC_TWSI4 0x7c
#define APBC_TWSI5 0x80
#define APBC_KPC 0x18
+#define APBC_TIMER 0x24
#define APBC_UART0 0x2c
#define APBC_UART1 0x30
#define APBC_UART2 0x34
@@ -132,6 +133,9 @@ static DEFINE_SPINLOCK(ssp2_lock);
static DEFINE_SPINLOCK(ssp3_lock);
static const char *ssp_parent_names[] = {"vctcxo_4", "vctcxo_2", "vctcxo",
"pll1_16"};
+static DEFINE_SPINLOCK(timer_lock);
+static const char *timer_parent_names[] = {"clk32", "vctcxo_2", "vctcxo_4",
"vctcxo"};
+
static DEFINE_SPINLOCK(reset_lock);
static struct mmp_param_mux_clk apbc_mux_clks[] = {
@@ -143,6 +147,7 @@ static struct mmp_param_mux_clk apbc_mux_clks[] = {
{0, "ssp1_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names),
CLK_SET_RATE_PARENT, APBC_SSP1, 4, 3, 0, _lock},
{0, "ssp2_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names),
CLK_SET_RATE_PARENT, APBC_SSP2, 4, 3, 0, _lock},
{0, "ssp3_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names),
CLK_SET_RATE_PARENT, APBC_SSP3, 4, 3, 0, _lock},
+ {0, "timer_mux", timer_parent_names, ARRAY_SIZE(timer_parent_names),
CLK_SET_RATE_PARENT, APBC_TIMER, 4, 3, 0, _lock},
};
static struct mmp_param_gate_clk apbc_gate_clks[] = {
@@ -168,6 +173,7 @@ static struct mmp_param_gate_clk apbc_gate_clks[] = {
{MMP2_CLK_SSP1, "ssp1_clk", "ssp1_mux", CLK_SET_RATE_PARENT, APBC_SSP1,
0x7, 0x3, 0x0, 0, _lock},
{MMP2_CLK_SSP2, "ssp2_clk", "ssp2_mux", CLK_SET_RATE_PARENT, APBC_SSP2,
0x7, 0x3, 0x0, 0, _lock},
{MMP2_CLK_SSP3, "ssp3_clk", "ssp3_mux", CLK_SET_RATE_PARENT, APBC_SSP3,
0x7, 0x3, 0x0, 0, _lock},
+ {MMP2_CLK_TIMER, "timer_clk", "timer_mux", CLK_SET_RATE_PARENT,
APBC_TIMER, 0x7, 0x3, 0x0, 0, _lock},
};
static void mmp2_apb_periph_clk_init(struct mmp2_clk_unit *pxa_unit)
diff --git a/drivers/clk/mmp/clk-of-pxa168.c b/drivers/clk/mmp/clk-of-pxa168.c
index 01a650e..64eaf41 100644
--- a/drivers/clk/mmp/clk-of-pxa168.c
+++ b/drivers/clk/mmp/clk-of-pxa168.c
@@ -32,6 +32,7 @@
#define APBC_PWM1 0x10
#define APBC_PWM2 0x14
#define APBC_PWM3 0x18
+#define APBC_TIMER 0x34
#define APBC_SSP0 0x81c
#define APBC_SSP1 0x820
#define APBC_SSP2 0x84c
@@ -71,6 +72,7 @@ static struct mmp_param_fixed_factor_clk fixed_factor_clks[]
= {
{PXA168_CLK_PLL1_24, "pll1_24", "pll1_12", 1, 2, 0},
{PXA168_CLK_PLL1_48, "pll1_48", "pll1_24", 1, 2, 0},
{PXA168_CLK_PLL1_96, "pll1_96", "pll1_48", 1, 2, 0},
+ {PXA168_CLK_PLL1_192, "pll1_192", "pll1_96", 1, 2, 0},
{PXA168_CLK_PLL1_13, "pll1_13", "pll1", 1, 13, 0},
{PXA168_CLK_PLL1_13_1_5, "pll1_13_1_5", "pll1_13", 2, 3, 0},
{PXA168_CLK_PLL1_2_1_5, "pll1_2_1_5", "pll1_2", 2, 3, 0},
@@ -120,6 +122,9 @@ static DEFINE_SPINLOCK(ssp3_lock);
static DEFINE_SPINLOCK(ssp4_lock);
static const char *ssp_parent_names[] = {"pll1_96", "pll1_48", "pll1_24",
"pll1_12"};
+static DEFINE_SPINLOCK(timer_lock);
+static const char *timer_parent_names[] = {"pll1_48", "clk32", "pll1_96",
"pll1_192"};
+
static DEFINE_SPINLOCK(reset_lock);
static struct mmp_param_mux_clk apbc_mux_clks[] = {
@@ -131,6 +136,7 @@ static struct mmp_param_mux_clk apbc_mux_clks[] = {
{0, "ssp2_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names),
CLK_SET_RATE_PARENT, APBC_SSP2, 4, 3, 0, _lock},
{0, "ssp3_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names),
CLK_SET_RATE_PARENT, APBC_SSP3, 4, 3, 0, _lock},
{0, "ssp4_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names),
CLK_SET_RATE_PARENT, APBC_SSP4, 4, 3, 0, _lock},
+ {0, "timer_mux", timer_parent_names, ARRAY_SIZE(timer_parent_names),
CLK_SET_RATE_PARENT, APBC_TIMER, 4, 3, 0, _lock},
};
static struct mmp_param_gate_clk apbc_gate_clks[] = {
@@ -152,6 +158,7 @@ static struct mmp_param_gate_clk apbc_gate_clks[] = {
{PXA168_CLK_SSP2, "ssp2_clk", "ssp2_mux", CLK_SET_RATE_PARENT,
APBC_SSP2, 0x3, 0x3, 0x0, 0, _lock},
{PXA168_CLK_SSP3, "ssp3_clk", "ssp3_mux", CLK_SET_RATE_PARENT,
APBC_SSP3, 0x3, 0x3, 0x0, 0, _lock},
{PXA168_CLK_SSP4, "ssp4_clk", "ssp4_mux", CLK_SET_RATE_PARENT,
APBC_SSP4, 0x3, 0x3, 0x0, 0, _lock},
+ {PXA168_CLK_TIMER, "timer_clk", "timer_mux", CLK_SET_RATE_PARENT,
APBC_TIMER, 0x3, 0x3, 0x0, 0, _lock},
};
Re: [PATCH RFC] x86: enforce inlining for atomics
On Wed, 22 Apr 2015, Hagen Paul Pfeifer wrote: > On 22 April 2015 at 11:28, Ingo Molnar wrote: > > So I think the original patch makes sense (and I already applied it), > > we want known-simple and performance critical methods (such as atomic > > ops) always inlined. > > Right. As I wrote I will post a follow up patch for the remaining > cases where inline is a must. To guarantee that performance critical > functions are always inlined - no matter what configuration is used. It would be nice to see those patches in -stable eventually, please... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 1/3] clk: mmp: add fixed clock UBS_PLL for pxa910/pxa168
From: Chao Xie
USB will drive clock from USB_PLL.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/clk-of-pxa168.c| 1 +
drivers/clk/mmp/clk-of-pxa910.c| 1 +
include/dt-bindings/clock/marvell,pxa168.h | 1 +
include/dt-bindings/clock/marvell,pxa910.h | 1 +
4 files changed, 4 insertions(+)
diff --git a/drivers/clk/mmp/clk-of-pxa168.c b/drivers/clk/mmp/clk-of-pxa168.c
index 5b1810d..01a650e 100644
--- a/drivers/clk/mmp/clk-of-pxa168.c
+++ b/drivers/clk/mmp/clk-of-pxa168.c
@@ -58,6 +58,7 @@ static struct mmp_param_fixed_rate_clk fixed_rate_clks[] = {
{PXA168_CLK_CLK32, "clk32", NULL, CLK_IS_ROOT, 32768},
{PXA168_CLK_VCTCXO, "vctcxo", NULL, CLK_IS_ROOT, 2600},
{PXA168_CLK_PLL1, "pll1", NULL, CLK_IS_ROOT, 62400},
+ {PXA168_CLK_USB_PLL, "usb_pll", NULL, CLK_IS_ROOT, 48000},
};
static struct mmp_param_fixed_factor_clk fixed_factor_clks[] = {
diff --git a/drivers/clk/mmp/clk-of-pxa910.c b/drivers/clk/mmp/clk-of-pxa910.c
index 5e3c80d..cca98ef 100644
--- a/drivers/clk/mmp/clk-of-pxa910.c
+++ b/drivers/clk/mmp/clk-of-pxa910.c
@@ -57,6 +57,7 @@ static struct mmp_param_fixed_rate_clk fixed_rate_clks[] = {
{PXA910_CLK_CLK32, "clk32", NULL, CLK_IS_ROOT, 32768},
{PXA910_CLK_VCTCXO, "vctcxo", NULL, CLK_IS_ROOT, 2600},
{PXA910_CLK_PLL1, "pll1", NULL, CLK_IS_ROOT, 62400},
+ {PXA910_CLK_USB_PLL, "usb_pll", NULL, CLK_IS_ROOT, 48000},
};
static struct mmp_param_fixed_factor_clk fixed_factor_clks[] = {
diff --git a/include/dt-bindings/clock/marvell,pxa168.h
b/include/dt-bindings/clock/marvell,pxa168.h
index 79630b9..84ce5de 100644
--- a/include/dt-bindings/clock/marvell,pxa168.h
+++ b/include/dt-bindings/clock/marvell,pxa168.h
@@ -19,6 +19,7 @@
#define PXA168_CLK_PLL1_2_1_5 19
#define PXA168_CLK_PLL1_3_16 20
#define PXA168_CLK_UART_PLL27
+#define PXA168_CLK_USB_PLL 28
/* apb periphrals */
#define PXA168_CLK_TWSI0 60
diff --git a/include/dt-bindings/clock/marvell,pxa910.h
b/include/dt-bindings/clock/marvell,pxa910.h
index 719cffb..bea08b6 100644
--- a/include/dt-bindings/clock/marvell,pxa910.h
+++ b/include/dt-bindings/clock/marvell,pxa910.h
@@ -19,6 +19,7 @@
#define PXA910_CLK_PLL1_2_1_5 19
#define PXA910_CLK_PLL1_3_16 20
#define PXA910_CLK_UART_PLL27
+#define PXA910_CLK_USB_PLL 28
/* apb periphrals */
#define PXA910_CLK_TWSI0 60
--
1.8.3.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 RESEND 2/3] clk: mmp: Fix the wrong factor table for uart PLL
From: Chao Xie
The suggested value in the mmp2 manual is wrong.
There are only 13 bits for numerator, but some suggested
value has 14 bits.
Fix the factor tabled and remove the unused items.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/clk-mmp2.c| 4 +---
drivers/clk/mmp/clk-of-mmp2.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index 5c90a42..09d2832 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -63,10 +63,8 @@ static struct mmp_clk_factor_masks uart_factor_masks = {
};
static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
- {.num = 14634, .den = 2165},/*14.745MHZ */
+ {.num = 8125, .den = 1536}, /*14.745MHZ */
{.num = 3521, .den = 689}, /*19.23MHZ */
- {.num = 9679, .den = 5728}, /*58.9824MHZ */
- {.num = 15850, .den = 9451},/*59.429MHZ */
};
static const char *uart_parent[] = {"uart_pll", "vctcxo"};
diff --git a/drivers/clk/mmp/clk-of-mmp2.c b/drivers/clk/mmp/clk-of-mmp2.c
index 2cbc2b4..b7e0b89 100644
--- a/drivers/clk/mmp/clk-of-mmp2.c
+++ b/drivers/clk/mmp/clk-of-mmp2.c
@@ -98,10 +98,8 @@ static struct mmp_clk_factor_masks uart_factor_masks = {
};
static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
- {.num = 14634, .den = 2165},/*14.745MHZ */
+ {.num = 8125, .den = 1536}, /*14.745MHZ */
{.num = 3521, .den = 689}, /*19.23MHZ */
- {.num = 9679, .den = 5728}, /*58.9824MHZ */
- {.num = 15850, .den = 9451},/*59.429MHZ */
};
static void mmp2_pll_init(struct mmp2_clk_unit *pxa_unit)
--
1.8.3.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 RESEND 0/3] clk: mmp: fix and add new clock
From: Chao Xie There are three patches First two are fix patches. The last one will add the timer clock for pxa168/mmp2/pxa910. The timer driver will make use of the timer clock. Chao Xie (3): clk: mmp: add fixed clock UBS_PLL for pxa910/pxa168 clk: mmp: Fix the wrong factor table for uart PLL clk: mmp: add timer clock for pxa168/mmp2/pxa910 drivers/clk/mmp/clk-mmp2.c | 4 +--- drivers/clk/mmp/clk-of-mmp2.c | 10 +++--- drivers/clk/mmp/clk-of-pxa168.c| 8 drivers/clk/mmp/clk-of-pxa910.c| 12 include/dt-bindings/clock/marvell,mmp2.h | 1 + include/dt-bindings/clock/marvell,pxa168.h | 3 +++ include/dt-bindings/clock/marvell,pxa910.h | 4 7 files changed, 36 insertions(+), 6 deletions(-) -- 1.8.3.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] arm64: perf: Fix callchain parse error with kernel tracepoint events
On 2015/4/29 18:12, Will Deacon wrote:
Hello,
On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:
For ARM64, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.
./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
./perf report -f
Samples: 194 of event 'sched:sched_switch', Event count (approx.): 194
Children SelfCommand Shared Object Symbol
100.00% 100.00% ls [unknown] [.]
The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .
With this patch, callchain can be parsed correctly as follows:
..
+2.63% 0.00% ls [kernel.kallsyms] [k] vfs_symlink
+2.63% 0.00% ls [kernel.kallsyms] [k] follow_down
+2.63% 0.00% ls [kernel.kallsyms] [k] pfkey_get
+2.63% 0.00% ls [kernel.kallsyms] [k] do_execveat_common.isra.33
-2.63% 0.00% ls [kernel.kallsyms] [k] pfkey_send_policy_notify
pfkey_send_policy_notify
pfkey_get
v9fs_vfs_rename
page_follow_link_light
link_path_walk
el0_svc_naked
...
For tracepoint event, stack parsing also doesn't work well for ARM. Jean Pihet
comed up a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280
Any chance you could revive that series too, please? I'd like to update both
arm and arm64 together, since we're currently working at merging the two
perf backends and introducing discrepencies is going to delay that even
longer.
Signed-off-by: Hou Pengyang
---
arch/arm64/include/asm/perf_event.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/include/asm/perf_event.h
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..16a074f 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
#define perf_misc_flags(regs) perf_misc_flags(regs)
#endif
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+ unsigned long sp; \
+ __asm__ ("mov %[sp], sp\n" : [sp] "=r" (sp)); \
+ (regs)->pc = (__ip);\
+ __asm__ ( \
+ "str %[sp], %[_arm64_sp] \n\t"\
+ "str x29, %[_arm64_fp] \n\t"\
+ "mrs %[_arm64_cpsr], spsr_el1 \n\t" \
+ : [_arm64_sp] "=m" (regs->sp), \
+ [_arm64_fp] "=m" (regs->regs[29]), \
+ [_arm64_cpsr] "=r" (regs->pstate) \
Does this really all need to be in assembly code? Ideally we'd use something
like __builtin_stack_pointer and __builtin_frame_pointer. That just leaves
the CPSR, but given that it's (a) only used for user_mode_regs tests and (b)
this macro is only used by ftrace, then we just set it to a static value
indicating that we're at EL1.
So I *think* we should be able to write this as three lines of C.
Hi, will, as you said, we can get fp by __builtin_frame_address() and
pstate by setting it to a static value. However, for sp, there isn't a
gcc builtin fuction like __builtin_stack_pointer, so assembly code is
needed. What's more, if CONFIG_FRAME_POINTER is close, can fp be got by
__builtin_frame_address()?
Will
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tux3 Report: How fast can we fsync?
On Tue, Apr 28, 2015 at 04:13:18PM -0700, Daniel Phillips wrote: > Greetings, > > This post is dedicated to Ted, who raised doubts a while back about > whether Tux3 can ever have a fast fsync: > > https://lkml.org/lkml/2013/5/11/128 > "Re: Tux3 Report: Faster than tmpfs, what?" [snip] > I measured fsync performance using a 7200 RPM disk as a virtual > drive under KVM, configured with cache=none so that asynchronous > writes are cached and synchronous writes translate into direct > writes to the block device. Yup, a slow single spindle, so fsync performance is determined by seek latency of the filesystem. Hence the filesystem that "wins" will be the filesystem that minimises fsync seek latency above all other considerations. http://www.spinics.net/lists/kernel/msg1978216.html So, to demonstrate, I'll run the same tests but using a 256GB samsung 840 EVO SSD and show how much the picture changes. I didn't test tux3, you don't make it easy to get or build. > To focus purely on fsync, I wrote a > small utility (at the end of this post) that forks a number of > tasks, each of which continuously appends to and fsyncs its own > file. For a single task doing 1,000 fsyncs of 1K each, we have: > >Ext4: 34.34s >XFS: 23.63s >Btrfs: 34.84s >Tux3: 17.24s Ext4: 1.94s XFS:2.06s Btrfs: 2.06s All equally fast, so I can't see how tux3 would be much faster here. > Things get more interesting with parallel fsyncs. In this test, each > task does ten fsyncs and task count scales from ten to ten thousand. > We see that all tested filesystems are able to combine fsyncs into > group commits, with varying degrees of success: > >Tasks: 10 1001,00010,000 >Ext4: 0.79s 0.98s4.62s61.45s >XFS:0.75s 1.68s 20.97s 238.23s >Btrfs 0.53s 0.78s3.80s84.34s >Tux3: 0.27s 0.34s1.00s 6.86s Tasks: 10 1001,00010,000 Ext4: 0.05s 0.12s0.48s 3.99s XFS:0.25s 0.41s0.96s 4.07s Btrfs 0.22s 0.50s2.86s 161.04s (lower is better) Ext4 and XFS are fast and show similar performance. Tux3 *can't* be very much faster as most of the elapsed time in the test is from forking the processes that do the IO and fsyncs. FWIW, btrfs shows it's horrible fsync implementation here, burning huge amounts of CPU to do bugger all IO. i.e. it burnt all 16p for 2 and a half minutes in that 1 fork test so wasn't IO bound at all. > Is there any practical use for fast parallel fsync of tens of thousands > of tasks? This could be useful for a scalable transaction server > that sits directly on the filesystem instead of a database, as is > the fashion for big data these days. It certainly can't hurt to know > that if you need that kind of scaling, Tux3 will do it. Ext4 and XFS already do that just fine, too, when you use storage suited to such a workload and you have a sane interface for submitting tens of thousands of concurrent fsync operations. e.g http://oss.sgi.com/archives/xfs/2014-06/msg00214.html > Of course, a pure fsync load could be viewed as somewhat unnatural. We > also need to know what happens under a realistic load with buffered > operations mixed with fsyncs. We turn to an old friend, dbench: > > Dbench -t10 > >Tasks: 8 16 32 >Ext4:35.32 MB/s 34.08 MB/s 39.71 MB/s >XFS: 32.12 MB/s 25.08 MB/s 30.12 MB/s >Btrfs: 54.40 MB/s 75.09 MB/s 102.81 MB/s >Tux3:85.82 MB/s 133.69 MB/s 159.78 MB/s > (higher is better) On a SSD (256GB samsung 840 EVO), running 4.0.0: Tasks: 8 16 32 Ext4:598.27 MB/s981.13 MB/s 1233.77 MB/s XFS: 884.62 MB/s 1328.21 MB/s 1373.66 MB/s Btrfs: 201.64 MB/s137.55 MB/s 108.56 MB/s dbench looks *very different* when there is no seek latency, doesn't it? > Dbench -t10 -s (all file operations synchronous) > >Tasks: 8 16 32 >Ext4: 4.51 MB/s6.25 MB/s7.72 MB/s >XFS: 4.24 MB/s4.77 MB/s5.15 MB/s >Btrfs:7.98 MB/s 13.87 MB/s 22.87 MB/s >Tux3:15.41 MB/s 25.56 MB/s 39.15 MB/s > (higher is better) Ext4: 173.54 MB/s 294.41 MB/s 424.11 MB/s XFS:172.98 MB/s 342.78 MB/s 458.87 MB/s Btrfs: 36.92 MB/s 34.52 MB/s 55.19 MB/s Again, the numbers are completely the other way around on a SSD, with the conventional filesystems being 5-10x faster than the WA/COW style filesystem. > In the full disclosure department, Tux3 is still not properly > optimized in some areas. One of them is fragmentation: it is not > very hard to make Tux3 slow down by running long tests. Our current Oh, that still hasn't been fixed? Until you sort of how you are going to scale allocation to tens of TB and not fragment free space over time, fsync performance of the filesystem is pretty much
Re: [GIT PULL] kdbus for 4.1-rc1
> "David" == David Herrmann writes: David> Hi David> On Wed, Apr 29, 2015 at 10:43 PM, David Lang wrote: >> If the justification for why this needs to be in the kernel is that you >> can't reliably prevent apps from exiting if there are pending messages, [...] David> It's not. >> the answer of "preventing apps from exiting if there are pending messages >> isn't a sane thing to try and do" is a direct counter to that justification >> for including it in the kernel. David> It's optionally used for reliable exit-on-idle. Then why is there a critical race that must be solved in the kernel if it's optional? And can you please describe in more detail what this 'exit-on-idle' thing is and how it works and why you would use it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] f2fs: support FALLOC_FL_COLLAPSE_RANGE
Hi Jaegeuk, > -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Thursday, April 30, 2015 5:31 AM > To: Chao Yu > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/2] f2fs: support FALLOC_FL_COLLAPSE_RANGE > > Hi Chao, > > On Sat, Apr 18, 2015 at 06:00:36PM +0800, Chao Yu wrote: > > Now, FALLOC_FL_COLLAPSE_RANGE flag in ->fallocate is supported in ext4/xfs. > > > > In commit, the semantics of this flag is descripted as following: > > "1) It collapses the range lying between offset and length by removing any > > data > >blocks which are present in this range and than updates all the logical > >offsets of extents beyond "offset + len" to nullify the hole created by > >removing blocks. In short, it does not leave a hole. > > 2) It should be used exclusively. No other fallocate flag in combination. > > 3) Offset and length supplied to fallocate should be fs block size aligned > >in case of xfs and ext4. > > 4) Collaspe range does not work beyond i_size." > > > > This patch implements fallocate's FALLOC_FL_COLLAPSE_RANGE for f2fs. > > [snip] > > +void replace_block(struct f2fs_sb_info *sbi, struct f2fs_summary *sum, > > + block_t old_blkaddr, block_t new_blkaddr) > > Seems like we can reuse the code in recover_data_page. > How about adding a generic replace_block(..., bool recover_curseg) for both of > them? Agree, I will do it. Thanks for your review! :) > > For other flow, looks good to me. > > Nice work. > 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/
[alsa-devel] [PATCH v4 2/2] mfd: arizona: Update DT binding to support hpdet channel
This patch add device tree bindings for the pdata needed to configure the Accessory Detect Mode select when Headphone detection. Signed-off-by: Inha Song --- Documentation/devicetree/bindings/mfd/arizona.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 7bd1273..7ddeda8 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -49,6 +49,12 @@ Optional properties: input singals. If values less than the number of input signals, elements that has not been specifed are set to 0 by default. + - wlf,hpdet-channel : Headphone detection channel. +ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL +ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR +If this node is not mentioned or if the value is unknown, then +headphone detection mode is set to HPDETL. + - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if they are being externally supplied. As covered in Documentation/devicetree/bindings/regulator/regulator.txt -- 2.0.0.390.gcb682f8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel] [PATCH v4 0/2] Add support for select accessory detect mode to HPDETL or HPDETR
This set of patches adds support for select accessory detect mode to HPDETL or HPDETR. Changes in v4: - Set the hpdet_channel default value to HPDETL in variable declaration. - Fix the indentation in binding documentation. Changes in v3: - Set the hpdet_channel default value to HPDETL If the value is unknown or invalid. Changes in v2: - Use the value in pdata instead of hpdet_channel in extcon_info. - Wrap arizona_extcon_of_get in IS_ENABLED(CONFIG_OF). - Change hpdet_channel type to unsigned from signed in pdata. - Move ARIZONA_ACCDET_MODE_* define to dt-binding header and directly set it to pdata. Inha Song (2): extcon: arizona: Add support for select accessory detect mode when headphone detection mfd: arizona: Update DT binding to support hpdet channel Documentation/devicetree/bindings/mfd/arizona.txt | 6 drivers/extcon/extcon-arizona.c | 38 ++- include/dt-bindings/mfd/arizona.h | 8 + include/linux/mfd/arizona/pdata.h | 3 ++ 4 files changed, 47 insertions(+), 8 deletions(-) create mode 100644 include/dt-bindings/mfd/arizona.h -- 2.0.0.390.gcb682f8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel] [PATCH v4 1/2] extcon: arizona: Add support for select accessory detect mode when headphone detection
This patch add support for select accessory detect mode to HPDETL or HPDETR.
Arizona provides a headphone detection circuit on the HPDETL and HPDETR pins
to measure the impedance of an external load connected to the headphone.
Depending on board design, headphone detect pins can change to HPDETR or HPDETL.
Signed-off-by: Inha Song
---
drivers/extcon/extcon-arizona.c | 38 ++
include/dt-bindings/mfd/arizona.h | 8
include/linux/mfd/arizona/pdata.h | 3 +++
3 files changed, 41 insertions(+), 8 deletions(-)
create mode 100644 include/dt-bindings/mfd/arizona.h
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 63f01c4..d251e92 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -32,13 +32,10 @@
#include
#include
#include
+#include
#define ARIZONA_MAX_MICD_RANGE 8
-#define ARIZONA_ACCDET_MODE_MIC 0
-#define ARIZONA_ACCDET_MODE_HPL 1
-#define ARIZONA_ACCDET_MODE_HPR 2
-
#define ARIZONA_MICD_CLAMP_MODE_JDL 0x4
#define ARIZONA_MICD_CLAMP_MODE_JDH 0x5
#define ARIZONA_MICD_CLAMP_MODE_JDL_GP5H 0x9
@@ -653,9 +650,9 @@ static void arizona_identify_headphone(struct
arizona_extcon_info *info)
ret = regmap_update_bits(arizona->regmap,
ARIZONA_ACCESSORY_DETECT_MODE_1,
ARIZONA_ACCDET_MODE_MASK,
-ARIZONA_ACCDET_MODE_HPL);
+arizona->pdata.hpdet_channel);
if (ret != 0) {
- dev_err(arizona->dev, "Failed to set HPDETL mode: %d\n", ret);
+ dev_err(arizona->dev, "Failed to set HPDET mode: %d\n", ret);
goto err;
}
@@ -705,9 +702,9 @@ static void arizona_start_hpdet_acc_id(struct
arizona_extcon_info *info)
ARIZONA_ACCESSORY_DETECT_MODE_1,
ARIZONA_ACCDET_SRC | ARIZONA_ACCDET_MODE_MASK,
info->micd_modes[0].src |
-ARIZONA_ACCDET_MODE_HPL);
+arizona->pdata.hpdet_channel);
if (ret != 0) {
- dev_err(arizona->dev, "Failed to set HPDETL mode: %d\n", ret);
+ dev_err(arizona->dev, "Failed to set HPDET mode: %d\n", ret);
goto err;
}
@@ -1103,6 +1100,26 @@ static void arizona_micd_set_level(struct arizona
*arizona, int index,
regmap_update_bits(arizona->regmap, reg, mask, level);
}
+static int arizona_extcon_of_get_pdata(struct arizona *arizona)
+{
+ struct arizona_pdata *pdata = >pdata;
+ unsigned int val = ARIZONA_ACCDET_MODE_HPL;
+
+ of_property_read_u32(arizona->dev->of_node, "wlf,hpdet-channel", );
+ switch (val) {
+ case ARIZONA_ACCDET_MODE_HPL:
+ case ARIZONA_ACCDET_MODE_HPR:
+ pdata->hpdet_channel = val;
+ break;
+ default:
+ dev_err(arizona->dev,
+ "Wrong wlf,hpdet-channel DT value %d\n", val);
+ pdata->hpdet_channel = ARIZONA_ACCDET_MODE_HPL;
+ }
+
+ return 0;
+}
+
static int arizona_extcon_probe(struct platform_device *pdev)
{
struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
@@ -1120,6 +1137,11 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
if (!info)
return -ENOMEM;
+ if (IS_ENABLED(CONFIG_OF)) {
+ if (!dev_get_platdata(arizona->dev))
+ arizona_extcon_of_get_pdata(arizona);
+ }
+
info->micvdd = devm_regulator_get(>dev, "MICVDD");
if (IS_ERR(info->micvdd)) {
ret = PTR_ERR(info->micvdd);
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
new file mode 100644
index 000..9ecff78
--- /dev/null
+++ b/include/dt-bindings/mfd/arizona.h
@@ -0,0 +1,8 @@
+#ifndef __DT_BINDINGS_ARIZONA_H__
+#define __DT_BINDINGS_ARIZONA_H__
+
+#define ARIZONA_ACCDET_MODE_MIC 0
+#define ARIZONA_ACCDET_MODE_HPL 1
+#define ARIZONA_ACCDET_MODE_HPR 2
+
+#endif /* __DT_BINDINGS_ARIZONA_H__ */
diff --git a/include/linux/mfd/arizona/pdata.h
b/include/linux/mfd/arizona/pdata.h
index 4578c72..2473a67 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -139,6 +139,9 @@ struct arizona_pdata {
/** GPIO used for mic isolation with HPDET */
int hpdet_id_gpio;
+ /** Channel to use for headphone detection */
+ unsigned int hpdet_channel;
+
/** Extra debounce timeout used during initial mic detection (ms) */
int micd_detect_debounce;
--
2.0.0.390.gcb682f8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] kdbus for 4.1-rc1
>>> >>> I've had Enterprise systems where I could hit power on two boxes, and >>> finish >>> the OS install on one before the other has even finished POST and look >>> for >>> the boot media. I did this 5 years ago, before the "let's speed up boot" >>> push started. >>> >>> Admittedly, this wasn't a stock distro boot/install, it was my own >>> optimized >>> one, but it also wasn't as optimized and automated as it could have been >>> (several points where the installer needed to pick items from a menu and >>> enter values) >>> >> >> You guys might have missed this new industry trend, I think they call >> it virtualisation, >> >> I hear it's going to be big, you might want to look into it. > > > So what do you run your virtual machines on? you still have to put an OS on > the hardware to support your VMs. Virtualization doesn't eliminate servers > (as much as some cloud advocates like to claim it does) > > And virtualization has overhead, sometimes very significant overhead, so > it's not always the right answer. > Thanks for proving my point, RHEL as a distro runs in both scenarios, optimising one is important at the moment, that fact that it might speed up boot on server which take 15 mins to POST is a side effect. For some reason people seem to think their one use case is all that matters, 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: [RFC] x86, perf: Add an aperfmperf driver
On Wed, Apr 29, 2015 at 11:50 AM, Andy Lutomirski wrote:
> On Apr 29, 2015 2:09 AM, "Peter Zijlstra" wrote:
>>
>> On Tue, Apr 28, 2015 at 02:25:37PM -0700, Andy Lutomirski wrote:
>> > diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
>> > index 80091ae54c2b..fadc822efc90 100644
>> > --- a/arch/x86/kernel/cpu/Makefile
>> > +++ b/arch/x86/kernel/cpu/Makefile
>> > @@ -45,6 +45,8 @@ obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE) +=
>> > perf_event_intel_uncore.o \
>> > perf_event_intel_uncore_snb.o \
>> > perf_event_intel_uncore_snbep.o \
>> > perf_event_intel_uncore_nhmex.o
>> > +obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_aperf_mperf.o
>> > +obj-$(CONFIG_CPU_SUP_AMD)+= perf_event_aperf_mperf.o
>>
>> Does this actually work? I would expect it to go complain about having
>> to build it twice if you have both set.
>
> No, but only because I spelled the filename wrong while regenerating
> the patch. Oops!
>
>>
>> > diff --git a/arch/x86/kernel/cpu/perf_event_aperfmperf.c
>> > b/arch/x86/kernel/cpu/perf_event_aperfmperf.c
>> > new file mode 100644
>> > index ..6e6d113bd9ce
>> > --- /dev/null
>> > +++ b/arch/x86/kernel/cpu/perf_event_aperfmperf.c
>> > @@ -0,0 +1,119 @@
>> > +#include
>> > +
>> > +#define APERFMPERF_EVENT_APERF 0
>> > +#define APERFMPERF_EVENT_MPERF 1
>> > +
>>
>> > +static int aperfmperf_event_init(struct perf_event *event)
>> > +{
>> > + if (event->attr.type != event->pmu->type)
>> > + return -ENOENT;
>> > +
>> > + if (event->attr.config != APERFMPERF_EVENT_APERF &&
>> > + event->attr.config != APERFMPERF_EVENT_MPERF)
>> > + return -ENOENT;
>>
>> Once we pass the type test we know its 'our' event, and we can go return
>> fatal errors. No other PMU will pick this up.
>>
>> This could therefore turn into an -EINVAL.
>>
>> > +
>> > + if (event->attr.config1 != 0)
>> > + return -ENOENT;
>>
>> Idem.
>>
>> > + /* no sampling */
>> > + if (event->hw.sample_period)
>> > + return -EINVAL;
>>
>> You could have set pmu::capabilities =
>> PERF_PMU_CAP_NO_INTERRUPT which would also have killed that dead.
>
>
> That checks attr.sample_period. I'm a bit confused about the
> relationship between event->hw and event->attr. Do I not need to
> check hw.sample_period?
>
>>
>> > + /* unsupported modes and filters */
>> > + if (event->attr.exclude_user ||
>> > + event->attr.exclude_kernel ||
>> > + event->attr.exclude_hv ||
>> > + event->attr.exclude_idle ||
>> > + event->attr.exclude_host ||
>> > + event->attr.exclude_guest ||
>> > + event->attr.freq ||
>> > + event->attr.sample_period) /* no sampling */
>> > + return -EINVAL;
>> > +
>> > + event->hw.idx = -1;
>> > + event->hw.event_base = (event->attr.config == APERFMPERF_EVENT_APERF
>> > ?
>> > + MSR_IA32_APERF : MSR_IA32_MPERF);
>> > +
>> > + return 0;
>> > +}
>>
>> The rest looks about right. Very simple thing indeed ;-)
>
> Before I submit v2, do you think this is actually worth doing? I can
> see it being useful for answering questions like "did this workload
> end up running at full speed".
>
To clarify, this is partially redundant with "cpu-cycles" and
"ref-cycles". That being said, these are simpler, actually documented
as being appropriate for measuring cpu performance states, and don't
have any scheduling constraints.
Also, is perf stat able to count while idle? perf stat -a -e
cpu-cycles sleep 1 reports very small numbers.
> --Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: location of the jdelvare-hwmon quilt series
Hi all,
I noticed commit a95d7600d9c4 ("hwmon: Update the location of my quilt
tree") in the hwmon-staging tree. It says that the quilt series is at
http://jdelvare.nerim.net/devel/linux/jdelvare-hwmon/ but inlinux-next
I am using http://jdelvare.nerim.net/devel/linux-3/jdelvare-hwmon/ . I
hope that they are really the same place, but should I update where I
fetch from?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpO9dPEJkP8g.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/1] ARM: dts: Add keep-power-in-suspend to WiFi SDIO node for Peach Boards
Hello Kukjin, On 04/15/2015 10:07 AM, Javier Martinez Canillas wrote: > > On 04/07/2015 05:09 PM, Doug Anderson wrote: >> Javier, >> >> On Tue, Apr 7, 2015 at 6:03 AM, Javier Martinez Canillas >> wrote: >>> The Marvell mwifiex driver prevents the system to enter into a suspend >>> state if the card power is not preserved during a suspend/resume cycle. >>> >>> So Suspend-to-RAM and Suspend-to-idle is failing on Exynos5800 Peach Pi >>> and Exynos5420 Peach Pit Chromebooks. >>> >>> Add the keep-power-in-suspend Power Management property to the SDIO/MMC >>> node so the mwifiex suspend handler doesn't fail and the system is able >>> to enter into a suspend state. >>> >>> Signed-off-by: Javier Martinez Canillas >>> --- >>> arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + >>> 2 files changed, 2 insertions(+) >> >> Reviewed-by: Doug Anderson >> > > Any comments on this patch? > > Best regards, > Javier > Gentle reminder about this patch. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 17/32] powerpc/powernv: Implement accessor to TCE entry
On Wed, Apr 29, 2015 at 07:02:17PM +1000, Alexey Kardashevskiy wrote:
> On 04/29/2015 02:04 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:14:41PM +1000, Alexey Kardashevskiy wrote:
> >>This replaces direct accesses to TCE table with a helper which
> >>returns an TCE entry address. This does not make difference now but will
> >>when multi-level TCE tables get introduces.
> >>
> >>No change in behavior is expected.
> >>
> >>Signed-off-by: Alexey Kardashevskiy
> >
> >Reviewed-by: David Gibson
> >
> >
> >>---
> >>Changes:
> >>v9:
> >>* new patch in the series to separate this mechanical change from
> >>functional changes; this is not right before
> >>"powerpc/powernv: Implement multilevel TCE tables" but here in order
> >>to let the next patch - "powerpc/iommu/powernv: Release replaced TCE" -
> >>use pnv_tce() and avoid changing the same code twice
> >>---
> >> arch/powerpc/platforms/powernv/pci.c | 34
> >> +-
> >> 1 file changed, 21 insertions(+), 13 deletions(-)
> >>
> >>diff --git a/arch/powerpc/platforms/powernv/pci.c
> >>b/arch/powerpc/platforms/powernv/pci.c
> >>index 84b4ea4..ba75aa5 100644
> >>--- a/arch/powerpc/platforms/powernv/pci.c
> >>+++ b/arch/powerpc/platforms/powernv/pci.c
> >>@@ -572,38 +572,46 @@ struct pci_ops pnv_pci_ops = {
> >>.write = pnv_pci_write_config,
> >> };
> >>
> >>+static __be64 *pnv_tce(struct iommu_table *tbl, long idx)
> >>+{
> >>+ __be64 *tmp = ((__be64 *)tbl->it_base);
> >>+
> >>+ return tmp + idx;
> >>+}
> >>+
> >> int pnv_tce_build(struct iommu_table *tbl, long index, long npages,
> >>unsigned long uaddr, enum dma_data_direction direction,
> >>struct dma_attrs *attrs)
> >> {
> >>u64 proto_tce = iommu_direction_to_tce_perm(direction);
> >>- __be64 *tcep;
> >>- u64 rpn;
> >>+ u64 rpn = __pa(uaddr) >> tbl->it_page_shift;
> >
> >I guess this was a problem in the existing code, not this patch. But
> >"uaddr" is a really bad name (and unsigned long is a bad type) for
> >what must actually be a kernel linear mapping address.
>
>
> Yes and may be one day I'll clean this up. s/uaddr/linear/ and s/hwaddr/hpa/
> are the first things to do globally but not in this patchset.
Ok.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpbU5WJWSBDO.pgp
Description: PGP signature
Re: [PATCH 1/1] Revert "ARM: dts: add display power domain for exynos5250"
Hello, On 04/29/2015 09:45 PM, Sjoerd Simons wrote: > On Wed, 2015-04-29 at 10:40 -0700, Kevin Hilman wrote: >> Javier Martinez Canillas writes: > >> Tested-by: Kevin Hilman >> >> FWIW, this patch fixes the boot panics when using MMC rootfs on >> exynos5800-peach-pi with current linux-next that have been happening >> for awhile. > > That seems unlikely as this patch changes things in the exynos5250.dtsi, > which isn't used by exynos5800-peach-pi.? > Indeed, it will be surprising if $subject changes any behavior on Exynos5420/5422/5800 machines. FWIW, this patch is not needed anymore since the right fix is Krzysztof's "drm/exynos: Enable DP clock to fix display on Exynos5250 and other" patch which is already in linux-next. The regression on Exynos5420/5422/5800 that has been for a while is fixed by "ARM: dts: Make DP a consumer of DISP1 power domain on Exynos5420" [0] which has been posted many weeks ago. >> For several months now, DRM/display related stuff is very routinely >> breaking basic booting on exynos5, which gives the rather strong >> impression that the DRM stuff is not tested well enough to be merged. > > Unfortunately it seems to have been that way for ages, but only has > started being visible since Javier turned on the various exynos DRM > drivers on in exynos_defconfig.. So now we're actually seeing bugs > rather then just having broken code sit around :/ > Agreed. Best regards, Javier [0]: https://lkml.org/lkml/2015/4/12/153 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: dts: Make DP a consumer of DISP1 power domain on Exynos5420
Javier Martinez Canillas wrote:
>
> Hello Kukjin,
>
Hi,
> On 04/16/2015 09:40 AM, Javier Martinez Canillas wrote:
> >
> > On 04/12/2015 10:30 PM, Javier Martinez Canillas wrote:
> >> Commit ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")
> >> added a device node for the Exynos5420 DISP1 power domain but dit not
> >> make the DP controller a consumer of that power domain.
> >>
> >> This causes an "Unhandled fault: imprecise external abort" error if the
> >> exynos-dp driver tries to access the DP controller registers and the PD
> >> was turned off. This lead to a kernel panic and a complete system hang.
> >>
> >> Make the DP controller device node a consumer of the DISP1 power domain
> >> to ensure that the PD is turned on when the exynos-dp driver is probed.
> >>
> >> Fixes: ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")
> >> Signed-off-by: Javier Martinez Canillas
> >
> > Any comments about this patch?
> >
> > It's very trivial but fixes a very important regression on Exynos5420 boards
> > with display panel and Peach Pit and Pi have been broken since
> > next-20150401.
> >
> > This [0] is the Peach Pit boot log with yesteday's linux-next for example.
> >
> > Best regards,
> > Javier
> >
> > [0]:
> > http://arm-soc.lixom.net/bootlogs/next/next-20150415/pit-arm-exynos_defconfig.html
> >
>
> It has been many weeks since this patch has been posted and linux-next
> is still broken:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20150429/pi-arm-exynos_defconfig.html
>
> Could you please apply $subject to fix the imprecise external abort issue.
>
Sure I'll in this weekend.
Thanks for your gentle reminder ;-)
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 stable] block: discard bdi_unregister() in favour of bdi_destroy()
bdi_unregister() now contains very little functionality.
It contains a "WARN_ON" if bdi->dev is NULL. This warning is of no
real consequence as bdi->dev isn't needed by anything else in the function,
and it triggers if
blk_cleanup_queue() -> bdi_destroy()
is called before bdi_unregister, which a subsequent patch will make happen.
So this isn't wanted.
It also calls bdi_set_min_ratio(). This needs to be called after
writes through the bdi have all been flushed, and before the bdi is destroyed.
Calling it early is better than calling it late as it frees up a global
resource.
Calling it immediately after bdi_wb_shutdown() in bdi_destroy()
perfectly fits these requirements.
So bdi_unregister can be discarded with the important content moved to
bdi_destroy, as can the
writeback_bdi_unregister
event which is already not used.
This is tagged for 'stable' as it is a pre-requisite for a subsequent
patch which moves calls to blk_cleanup_queue() before calls to
del_gendisk(). The commit identified as 'Fixes' removed a lot of
other functionality from bdi_unregister(), and made a change which
necessitated moving the blk_cleanup_queue() calls.
Reported-by: Mike Snitzer
Cc: Christoph Hellwig
Cc: Peter Zijlstra
Cc: sta...@vger.kernel.org (v4.0)
Fixes: c4db59d31e39ea067c32163ac961e9c80198fd37
Signed-off-by: NeilBrown
---
Hi again Jens,
would you be able to queue this patch *before* the other one:
block: destroy bdi before blockdev is unregistered.
If it has to come after I'll need to re-write the text a bit.
If you could give me the commit hash to reference I'll do that.
diff --git a/block/genhd.c b/block/genhd.c
index e351fc521053..1d4435478e8a 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -657,7 +657,6 @@ void del_gendisk(struct gendisk *disk)
disk->flags &= ~GENHD_FL_UP;
sysfs_remove_link(_to_dev(disk)->kobj, "bdi");
- bdi_unregister(>queue->backing_dev_info);
blk_unregister_queue(disk);
blk_unregister_region(disk_devt(disk), disk->minors);
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index aff923ae8c4b..d87d8eced064 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -116,7 +116,6 @@ __printf(3, 4)
int bdi_register(struct backing_dev_info *bdi, struct device *parent,
const char *fmt, ...);
int bdi_register_dev(struct backing_dev_info *bdi, dev_t dev);
-void bdi_unregister(struct backing_dev_info *bdi);
int __must_check bdi_setup_and_register(struct backing_dev_info *, char *);
void bdi_start_writeback(struct backing_dev_info *bdi, long nr_pages,
enum wb_reason reason);
diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h
index 880dd7437172..c178d13d6f4c 100644
--- a/include/trace/events/writeback.h
+++ b/include/trace/events/writeback.h
@@ -250,7 +250,6 @@ DEFINE_EVENT(writeback_class, name, \
DEFINE_WRITEBACK_EVENT(writeback_nowork);
DEFINE_WRITEBACK_EVENT(writeback_wake_background);
DEFINE_WRITEBACK_EVENT(writeback_bdi_register);
-DEFINE_WRITEBACK_EVENT(writeback_bdi_unregister);
DECLARE_EVENT_CLASS(wbc_class,
TP_PROTO(struct writeback_control *wbc, struct backing_dev_info *bdi),
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index 6dc4580df2af..000e7b3b9896 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -359,23 +359,6 @@ static void bdi_wb_shutdown(struct backing_dev_info *bdi)
flush_delayed_work(>wb.dwork);
}
-/*
- * Called when the device behind @bdi has been removed or ejected.
- *
- * We can't really do much here except for reducing the dirty ratio at
- * the moment. In the future we should be able to set a flag so that
- * the filesystem can handle errors at mark_inode_dirty time instead
- * of only at writeback time.
- */
-void bdi_unregister(struct backing_dev_info *bdi)
-{
- if (WARN_ON_ONCE(!bdi->dev))
- return;
-
- bdi_set_min_ratio(bdi, 0);
-}
-EXPORT_SYMBOL(bdi_unregister);
-
static void bdi_wb_init(struct bdi_writeback *wb, struct backing_dev_info *bdi)
{
memset(wb, 0, sizeof(*wb));
@@ -443,6 +426,7 @@ void bdi_destroy(struct backing_dev_info *bdi)
int i;
bdi_wb_shutdown(bdi);
+ bdi_set_min_ratio(bdi, 0);
WARN_ON(!list_empty(>work_list));
WARN_ON(delayed_work_pending(>wb.dwork));
pgpzpL2i0ekDE.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/1] ARM: dts: Make DP a consumer of DISP1 power domain on Exynos5420
Hello Kukjin,
On 04/16/2015 09:40 AM, Javier Martinez Canillas wrote:
>
> On 04/12/2015 10:30 PM, Javier Martinez Canillas wrote:
>> Commit ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")
>> added a device node for the Exynos5420 DISP1 power domain but dit not
>> make the DP controller a consumer of that power domain.
>>
>> This causes an "Unhandled fault: imprecise external abort" error if the
>> exynos-dp driver tries to access the DP controller registers and the PD
>> was turned off. This lead to a kernel panic and a complete system hang.
>>
>> Make the DP controller device node a consumer of the DISP1 power domain
>> to ensure that the PD is turned on when the exynos-dp driver is probed.
>>
>> Fixes: ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")
>> Signed-off-by: Javier Martinez Canillas
>
> Any comments about this patch?
>
> It's very trivial but fixes a very important regression on Exynos5420 boards
> with display panel and Peach Pit and Pi have been broken since next-20150401.
>
> This [0] is the Peach Pit boot log with yesteday's linux-next for example.
>
> Best regards,
> Javier
>
> [0]:
> http://arm-soc.lixom.net/bootlogs/next/next-20150415/pit-arm-exynos_defconfig.html
>
It has been many weeks since this patch has been posted and linux-next
is still broken:
http://arm-soc.lixom.net/bootlogs/next/next-20150429/pi-arm-exynos_defconfig.html
Could you please apply $subject to fix the imprecise external abort issue.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] mmap.2: clarify MAP_LOCKED semantic (was: Re: Should mmap MAP_LOCKED fail if mm_poppulate fails?)
On Wed, 29 Apr 2015, Michal Hocko wrote: > MAP_LOCKED had a subtly different semantic from mmap(2)+mlock(2) since > it has been introduced. > mlock(2) fails if the memory range cannot get populated to guarantee > that no future major faults will happen on the range. mmap(MAP_LOCKED) on > the other hand silently succeeds even if the range was populated only > partially. > > Fixing this subtle difference in the kernel is rather awkward because > the memory population happens after mm locks have been dropped and so > the cleanup before returning failure (munlock) could operate on something > else than the originally mapped area. > > E.g. speculative userspace page fault handler catching SEGV and doing > mmap(fault_addr, MAP_FIXED|MAP_LOCKED) might discard portion of a racing > mmap and lead to lost data. Although it is not clear whether such a > usage would be valid, mmap page doesn't explicitly describe requirements > for threaded applications so we cannot exclude this possibility. > > This patch makes the semantic of MAP_LOCKED explicit and suggest using > mmap + mlock as the only way to guarantee no later major page faults. > > Signed-off-by: Michal Hocko > --- > man2/mmap.2 | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/man2/mmap.2 b/man2/mmap.2 > index 54d68cf87e9e..1486be2e96b3 100644 > --- a/man2/mmap.2 > +++ b/man2/mmap.2 > @@ -235,8 +235,19 @@ See the Linux kernel source file > for further information. > .TP > .BR MAP_LOCKED " (since Linux 2.5.37)" > -Lock the pages of the mapped region into memory in the manner of > +Mark the mmaped region to be locked in the same way as > .BR mlock (2). > +This implementation will try to populate (prefault) the whole range but > +the mmap call doesn't fail with > +.B ENOMEM > +if this fails. Therefore major faults might happen later on. So the semantic > +is not as strong as > +.BR mlock (2). > +.BR mmap (2) > ++ > +.BR mlock (2) > +should be used when major faults are not acceptable after the initialization > +of the mapping. > This flag is ignored in older kernels. > .\" If set, the mapped pages will not be swapped out. > .TP The wording of this begs the question on the behavior of MAP_LOCKED | MAP_POPULATE since this same man page specifies that accesses to memory mapped with MAP_POPULATE will not block on page faults later. I think Documentation/vm/unevictable-lru.txt would benefit from an update under the mmap(MAP_LOCKED) section where all this can be laid out and perhaps reference it from the man page? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Using pmem from a driver exposing a memory mapping (mmap) to userspace
- Original Message - > On 04/28/2015 06:35 PM, Mathieu Desnoyers wrote: > > Hi! > > > > I'm currently adaping lttng-modules to use DAX and pmem. > > It will allow LTTng buffers to be recovered after a kernel > > crash. I've moved pretty much all struct page pointers to > > page frame numbers, as I remember being told that pmem does > > not have struct page. > > > > Now I'm looking into adapting my mmap and page fault handler > > implementation (based on struct page) to a page-frame number > > based implementation when the ring buffer is backed by > > persistent memory, which will probably not require any page > > fault handler at all when based by pmem+dax memory. > > There will be page-faults at lease once for every combination > of application+page. Sure there may only be one per a+p > until the application does a close on the file. > > Your job can be simple if you use the pmem's inode. You know > how each block-device is a mini file system with a single file. > Use bdev->bd_inode to get to the one inode associated with > your pmem bdev. Well this inode is IS_DAX(), so if you supply > your own get_block() function to the DAX handlers you need > not duplicate any mmap code at all. > > (You can also use the same DAX infrastructure for the read/write_iter > implementation) > > > > > My current work is in this branch: > > https://github.com/compudj/lttng-modules-dev/tree/persistent-memory-buffers > > (see last commits) > > > > LTTng-modules supports both mmap() and splice(), but I plan > > to only provide mmap() support for persistent memory, since > > splice() really requires struct page. > > > > No splice just works fine. In-fact a NULL .splice_XXX vector > will use the default_file_splice_read/write which does a > copy and uses your regular read/write_iter vectors. So > leave the .splice NULL and it will be supported by your > read/write_iter interface. > > > Are there existing driver mmap implementations doing similar > > things, or do you have recommendations on how to implement > > this ? > > > > DAX.c lib does all that you need. You only need your own > translation from your device files to a chunk of pmem. > > Its how I'd do it, good luck. CC me on the patches I'll > review them. Now that I think about it a bit more, the simplest solution would probably be to open() a file within a DAX-enabled filesystem from our userspace daemon (lttng-consumerd) for each buffer. Then, I could pass each file descriptor to the kernel through a lttng-specific ioctl(), and let the kernel use that file as a ring buffer. lttng-consumerd could then simply mmap() that file and use it if it wants to consume the data while it's being produced (optional). And this file stays there after crash/reboot, so we can extract the buffers with a separate tool. Thoughts ? Thanks! Mathieu > > Cheers > Boaz > > > Thanks, > > Mathieu > > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)
On Wed, Apr 29, 2015 at 09:05:26PM +0200, Mike Galbraith wrote: > Here's something that _might_ interest xfs folks. > > cd git (source repository of git itself) > make clean > echo 3 > /proc/sys/vm/drop_caches > time make -j8 test > > ext42m20.721s > xfs 6m41.887s <-- ick > btrfs 1m32.038s > tux31m30.262s > > Testing by Aunt Tilly: mkfs, no fancy switches, mount the thing, test. TL;DR: Results are *very different* on a 256GB Samsung 840 EVO SSD with slightly slower CPUs (E5-4620 @ 2.20GHz)i, all filesystems using defaults: realusersys xfs 3m16.138s 7m8.341s14m32.462s ext43m18.045s 7m7.840s14m32.994s btrfs 3m45.149s 7m10.184s 16m30.498s What you are seeing is physical seek distances impacting read performance. XFS does not optimise for minimal physical seek distance, and hence is slower than filesytsems that do optimise for minimal seek distance. This shows up especially well on slow single spindles. XFS is *adequate* for the use on slow single drives, but it is really designed for best performance on storage hardware that is not seek distance sensitive. IOWS, XFS just hates your disk. Spend $50 and buy a cheap SSD and the problem goes away. :) And now in more detail. It's easy to be fast on empty filesystems. XFS does not aim to be fast in such situations - it aims to have consistent performance across the life of the filesystem. In this case, ext4, btrfs and tux3 have optimal allocation filling from the outside of the disk, while XFS is spreading the files across (at least) 4 separate regions of the whole disk. Hence XFS is seeing seek times on read are much larger than the other filesystems when the filesystem is empty as it is doing full disk seeks rather than being confined to the outer edges of spindle. Thing is, once you've abused those filesytsems for a couple of months, the files in ext4, btrfs and tux3 are not going to be laid out perfectly on the outer edge of the disk. They'll be spread all over the place and so all the filesystems will be seeing large seeks on read. The thing is, XFS will have roughly the same performance as when the filesystem is empty because the spreading of the allocation allows it to maintain better locality and separation and hence doesn't fragment free space nearly as badly as the oher filesystems. Free space fragmentation is what leads to performance degradation in filesystems, and all the other filesystem will have degraded to be *much worse* than XFS. Put simply: empty filesystem benchmarking does not show the real performance of the filesystem under sustained production workloads. Hence benchmarks like this - while interesting from a theoretical point of view and are widely used for bragging about whose got the fastest - are mostly irrelevant to determining how the filesystem will perform in production environments. We can also look at this algorithm in a different way: take a large filesystem (say a few hundred TB) across a few tens of disks in a linear concat. ext4, btrfs and tux3 will only hit the first disk in the concat, and so go no faster because they are still bound by physical seek times. XFS, however, will spread the load across many (if not all) of the disks, and so effectively reduce the average seek time by the number of disks doing concurrent IO. Then you'll see that application level IO concurrency becomes the performance limitation, not the physical seek time of the hardware. IOWs, what you don't see here is that the XFS algorithms that make your test slow will keep *lots* of disks busy. i.e. testing empty filesystem performance a single, slow disk demonstrates that an algorithm designed for scalability isn't designed to acheive physical seek distance minimisation. Hence your storage makes XFS look particularly poor in comparison to filesystems that are being designed and optimised for the limitations of single slow spindles... To further demonstrate that it is physical seek distance that is the issue here, lets take the seek time out of the equation (e.g. use a SSD). Doing that will result in basically no difference in performance between all 4 filesystems as performance will now be determined by application level concurrency and that is the same for all tests. e.g. on a 16p, 16GB RAM VM with storage on a SSDs a "make -j 8" compile test on a kernel source tree (using my normal test machine .config) gives: realusersys xfs:4m6.723s26m21.087s 2m49.426s ext4: 4m11.415s 26m21.122s 2m49.786s btrfs: 4m8.118s26m26.440s 2m50.357s i.e. take seek times out of the picture, and XFS is just as fast as any of the other filesystems. Just about everyone I know uses SSDs in their laptops and machines that build kernels these days, and spinning disks are rapidly disappearing from enterprise and HPC environments which also happens to be the target markets for XFS.
Re: [GIT PULL] kdbus for 4.1-rc1
On Thu, 30 Apr 2015, Dave Airlie wrote: On 30 April 2015 at 10:05, David Lang wrote: On Wed, 29 Apr 2015, Theodore Ts'o wrote: On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote: If your customers wnat this feature, you're more than welcome to fork the kernel and support it yourself. Oh wait... Redhat does that already. So what's the problem? Just put it into RHEL (which I use I admit, along with Debian/Mint) and be done with it. Harald, If you make the RHEL initramfs harder to debug in the field, I will await the time when some Red Hat field engineers will need to do the same sort of thing I have had to do in the field, and be amused when they want to shake you very warmly by the throat. :-) Seriously, keep things as simple as possible in the initramfs; don't use complicated bus protocols; that way lies madness. Enterprise systems aren't constantly booting (or they shouldn't be, if your kernels are sufficiently reliable :-), so trying to optimize for an extra 2 or 3 seconds worth of boot time really, REALLY isn't worth it. I've had Enterprise systems where I could hit power on two boxes, and finish the OS install on one before the other has even finished POST and look for the boot media. I did this 5 years ago, before the "let's speed up boot" push started. Admittedly, this wasn't a stock distro boot/install, it was my own optimized one, but it also wasn't as optimized and automated as it could have been (several points where the installer needed to pick items from a menu and enter values) You guys might have missed this new industry trend, I think they call it virtualisation, I hear it's going to be big, you might want to look into it. So what do you run your virtual machines on? you still have to put an OS on the hardware to support your VMs. Virtualization doesn't eliminate servers (as much as some cloud advocates like to claim it does) And virtualization has overhead, sometimes very significant overhead, so it's not always the right answer. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] kdbus for 4.1-rc1
On 30 April 2015 at 10:05, David Lang wrote: > On Wed, 29 Apr 2015, Theodore Ts'o wrote: > >> On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote: >>> >>> If your customers wnat this feature, you're more than welcome to fork >>> the kernel and support it yourself. Oh wait... Redhat does that >>> already. So what's the problem? Just put it into RHEL (which I use >>> I admit, along with Debian/Mint) and be done with it. >> >> >> Harald, >> >> If you make the RHEL initramfs harder to debug in the field, I will >> await the time when some Red Hat field engineers will need to do the >> same sort of thing I have had to do in the field, and be amused when >> they want to shake you very warmly by the throat. :-) >> >> Seriously, keep things as simple as possible in the initramfs; don't >> use complicated bus protocols; that way lies madness. Enterprise >> systems aren't constantly booting (or they shouldn't be, if your >> kernels are sufficiently reliable :-), so trying to optimize for an >> extra 2 or 3 seconds worth of boot time really, REALLY isn't worth it. > > > I've had Enterprise systems where I could hit power on two boxes, and finish > the OS install on one before the other has even finished POST and look for > the boot media. I did this 5 years ago, before the "let's speed up boot" > push started. > > Admittedly, this wasn't a stock distro boot/install, it was my own optimized > one, but it also wasn't as optimized and automated as it could have been > (several points where the installer needed to pick items from a menu and > enter values) > You guys might have missed this new industry trend, I think they call it virtualisation, I hear it's going to be big, you might want to look into it. 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: [PATCH RFC] net/mlx4: Remove improper usage of dma_alloc_coherent().
First of all, let me apologize for top posting, but it is currently my only option. I have been away from my office for the last couple of weeks, I was going to re-send on Monday, May 4. If you would like to do it before then, please go ahead and do that. Thanks, David Daney -Original Message- From: Ido Shamay [mailto:i...@dev.mellanox.co.il] Sent: Wednesday, April 29, 2015 7:14 AM To: David Daney; linux-kernel@vger.kernel.org; net...@vger.kernel.org; linux-r...@vger.kernel.org; David S. Miller Cc: Roland Dreier; Sean Hefty; Hal Rosenstock; Amir Vadai; Or Gerlitz; Yishai Hadas; Matan Barak; Majd Dibbiny; Jack Morgenstein; Moni Shoua; Eugenia Emantayev; Saeed Mahameed; Yuval Atias; Maor Gottlieb; David Daney Subject: Re: [PATCH RFC] net/mlx4: Remove improper usage of dma_alloc_coherent(). On 4/13/2015 12:33 AM, Ido Shamay wrote: > On 4/7/2015 10:43 PM, Ido Shamay wrote: >> On 4/7/2015 2:00 AM, David Daney wrote: >>> From: David Daney >>> >>> The dma_alloc_coherent() function returns a virtual address which >>> can be used for coherent access to the underlying memory. On some >>> architectures, like arm64, undefined behavior results if this memory >>> is also accessed via virtual mappings that are not coherent. Because >>> of their undefined nature, operations like virt_to_page() return >>> garbage when passed virtual addresses obtained from >>> dma_alloc_coherent(). Any subsequent mappings via vmap() of the >>> garbage page values are unusable and result in bad things like bus >>> errors (synchronous aborts in ARM64 speak). >>> >>> The MLX4 driver contains code that does the equivalent of: >>> >>>vmap(virt_to_page(dma_alloc_coherent)) >>> >>> This results in an OOPs when the device is opened. >>> >>> To fix this... >>> >>> Always use result of dma_alloc_coherent() directly. > Acked-by: Ido Shamay Thanks David, this is good > for us Hi David, Are you resending this patch or you want us to do that? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -stable] block: destroy bdi before blockdev is unregistered.
On Wed, 29 Apr 2015 18:02:58 +0200 Peter Zijlstra
wrote:
> On Wed, Apr 29, 2015 at 03:35:12PM +0200, Christoph Hellwig wrote:
> > On Wed, Apr 29, 2015 at 07:25:30AM +1000, NeilBrown wrote:
> > > As bdi_set_min_ratio doesn't touch bdi->dev, there seems to be no need for
> > > the test, or the warning.
> > >
> > > I wonder if it would make sense to move the bdi_set_min_ratio() call to
> > > bdi_destroy, and discard bdi_unregister??
> > > There is a comment which suggests bdi_unregister might be of use later,
> > > but
> > > it might be best to have a clean slate in which to add whatever might be
> > > needed??
> >
> > This seems fine to me from the block dev point of view. I don't really
> > understand the bdi_min_ratio logic, but Peter might have a better idea.
>
> Ah, that was a bit of digging, I've not looked at that in ages :-)
>
> So if you look at bdi_dirty_limit()'s comment:
>
> * The bdi's share of dirty limit will be adapting to its throughput and
> * bounded by the bdi->min_ratio and/or bdi->max_ratio parameters, if set.
>
> So the min_ratio is a minimum guaranteed fraction of the total
> throughput.
>
> Now the problem before commit ccb6108f5b0b ("mm/backing-dev.c: reset bdi
> min_ratio in bdi_unregister()") was that since bdi_set_min_ratio()
> keeps a global sum of bdi->min_ratio, you need to subtract from said
> global sum when taking the BDI away. Otherwise we loose/leak a fraction
> of the total throughput available (to the other BDIs).
>
> Which is what that bdi_set_min_ratio(bdi, 0) in unregister does. It
> resets the min_ratio for the bdi being taken out and frees up the min
> allocated bandwidth for the others.
>
> So I think moving that do destroy would be fine; assuming the delay
> between unregister and destroy is typically 'short'. Because without
> that you can 'leak' this min ratio for extended periods which means the
> bandwidth is unavailable for other BDIs.
>
> Does that make sense?
Your assessment is almost exactly what I had come up with, so it definitely
makes sense :-)
'destroy' does come very shortly after 'unregister' (and immediately before
'blk_put_queue' which actually frees the struct). However the driving force
for this patch was a desire to move blk_cleanup_queue(), which calls
'destroy', earlier. So the net result is that bdi_set_min_ratio will be
called slightly sooner.
Thanks,
NeilBrown
pgpFxqZ_agjmJ.pgp
Description: OpenPGP digital signature
Re: [GIT PULL] kdbus for 4.1-rc1
On Wed, 29 Apr 2015, Theodore Ts'o wrote: On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote: If your customers wnat this feature, you're more than welcome to fork the kernel and support it yourself. Oh wait... Redhat does that already. So what's the problem? Just put it into RHEL (which I use I admit, along with Debian/Mint) and be done with it. Harald, If you make the RHEL initramfs harder to debug in the field, I will await the time when some Red Hat field engineers will need to do the same sort of thing I have had to do in the field, and be amused when they want to shake you very warmly by the throat. :-) Seriously, keep things as simple as possible in the initramfs; don't use complicated bus protocols; that way lies madness. Enterprise systems aren't constantly booting (or they shouldn't be, if your kernels are sufficiently reliable :-), so trying to optimize for an extra 2 or 3 seconds worth of boot time really, REALLY isn't worth it. I've had Enterprise systems where I could hit power on two boxes, and finish the OS install on one before the other has even finished POST and look for the boot media. I did this 5 years ago, before the "let's speed up boot" push started. Admittedly, this wasn't a stock distro boot/install, it was my own optimized one, but it also wasn't as optimized and automated as it could have been (several points where the installer needed to pick items from a menu and enter values) David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net] net/bonding: Fix code style issues in a previous commit
This fixes a few coding style issues in my previous patch:
commit e913fb279c56
("net: Fix Kernel Panic in bonding driver debugfs file: rlb_hash_table")
Signed-off-by: Vishwanath Pai
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d5fe5d5..ab3eeb1 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4543,8 +4543,8 @@ unsigned int bond_get_num_tx_queues(void)
*/
int bond_create(struct net *net, const char *name)
{
- struct net_device *bond_dev;
struct bonding *bond;
+ struct net_device *bond_dev;
struct alb_bond_info *bond_info;
int res;
@@ -4559,8 +4559,7 @@ int bond_create(struct net *net, const char *name)
return -ENOMEM;
}
- /*
-* Initialize rx_hashtbl_used_head to RLB_NULL_INDEX.
+ /* Initialize rx_hashtbl_used_head to RLB_NULL_INDEX.
* It is set to 0 by default which is wrong.
*/
bond = netdev_priv(bond_dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MIPS: OCTEON: Stop .bss memory being allocated to the kernel
During development work on a 3.16 based kernel it was found that a
number of builds would panic during the kernel init process, more
specifically in 'delayed_fput()'. The panic showed the kernel trying
to access a memory address of '0xb7fdc00' while traversing the
'delayed_fput_list' structure. Comparing this memory address to the
value of the pointer used on builds that did not panic confirmed
that the pointer on crashing builds must have been corrupted at some
stage earlier in the init process.
By traversing the list earlier and earlier in the code it was found
that 'plat_mem_setup()' was responsible for corrupting the list.
Specifically the line:
memory = cvmx_bootmem_phy_alloc(mem_alloc_size,
__pa_symbol(&__init_end), -1,
0x10,
CVMX_BOOTMEM_FLAG_NO_LOCKING);
Which would eventually call:
cvmx_bootmem_phy_set_size(new_ent_addr,
cvmx_bootmem_phy_get_size
(ent_addr) -
(desired_min_addr -
ent_addr));
Where 'new_ent_addr'=0x480 (the address of 'delayed_fput_list')
and the second argument (size)=0xb7fdc00 (the address causing the
kernel panic). The job of this part of 'plat_mem_setup()' is to
allocate chunks of memory for the kernel to use. At the start of
each chunk of memory the size of the chunk is written, hence the
value 0xb7fdc00 is written onto memory at 0x480, therefore the
kernel panics when it goes back to access 'delayed_fput_list' later
on in the initialisation process.
On builds that were not crashing it was found that the compiler had
placed 'delayed_fput_list' at 0x488, meaning it wasn't corrupted
(but something else in memory was overwritten).
As can be seen in the first function call above the code begins to
allocate chunks of memory beginning from the symbol '__init_end'.
The MIPS linker script (vmlinux.lds.S) however defines the .bss
section to begin after '__init_end'. Therefore memory within the
.bss section is allocated to the kernel to use (System.map shows
'delayed_fput_list' and other kernel structures to be in .bss).
To stop the kernel panic (and the .bss section being corrupted)
memory should begin being allocated from the symbol '_end'.
Signed-off-by: Matt Bennett
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
arch/mips/cavium-octeon/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index 7e4367b..f632f14 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -1008,7 +1008,7 @@ void __init plat_mem_setup(void)
while ((boot_mem_map.nr_map < BOOT_MEM_MAP_MAX)
&& (total < MAX_MEMORY)) {
memory = cvmx_bootmem_phy_alloc(mem_alloc_size,
- __pa_symbol(&__init_end), -1,
+ __pa_symbol(&_end), -1,
0x10,
CVMX_BOOTMEM_FLAG_NO_LOCKING);
if (memory >= 0) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
2015-04-30 2:31 GMT+09:00 Kevin Hilman :
> Krzysztof Kozlowski writes:
>
>> After adding display power domain for Exynos5250 in commit
>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>> display on Chromebook Snow and others stopped working after boot.
>>
>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>> This clock is required by Display Port and is enabled by bootloader.
>> However when FIMD driver probing was deferred, the display power domain
>> was turned off. This effectively reset the value of DP clock enable
>> register.
>>
>> When exynos-dp is later probed, the clock is not enabled and display is
>> not properly configured:
>>
>> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
>> exynos-dp 145b.dp-controller: unable to config video
>>
>> Signed-off-by: Krzysztof Kozlowski
>> Reported-by: Javier Martinez Canillas
>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>> Cc:
>>
>> ---
>>
>> This should fix issue reported by Javier [1][2].
>>
>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>> especially on other Exynos 5xxx products.
>
> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
> to linux-next or to Linus' master branch.
>
> Are there some other dependencies here?
It is already applied:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] efi: add capsule update capability via sysfs
On Wed, Apr 29, 2015 at 4:36 PM, James Bottomley wrote: > On Wed, 2015-04-29 at 16:25 -0700, Andy Lutomirski wrote: >> On Wed, Apr 29, 2015 at 4:12 PM, James Bottomley >> wrote: >> > From: James Bottomley >> > >> > The firmware update should be applied simply by doing >> > >> > cat fw_file > /sys/firmware/capsule/update >> > >> > With a properly formatted fw_file. Any error will be returned on close of >> > stdout. util-linux returns errors correctly from closing stdout, but >> > firmware >> > shippers should check whatever utilities package they use correctly >> > captures >> > the error return on close. >> >> s/util-linux/coreutils/ >> >> This still makes my API sense itch. It's kind of an abuse of >> open/write/close. > > It works ... and according to Alan, NFS is already doing it. I suppose > we can have a do over of the whole debate again ... I think that NFS is at least writing to actual files as opposed to trying to implement some kind of transactions. Blech, whatever. This approach certainly works, as long as no one trips over the busybox thing. Maybe there should also be /sys/something_that_errors_on_close that people can use as a test. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] efi: add capsule update capability via sysfs
On Wed, 2015-04-29 at 16:25 -0700, Andy Lutomirski wrote:
> On Wed, Apr 29, 2015 at 4:12 PM, James Bottomley
> wrote:
> > From: James Bottomley
> >
> > The firmware update should be applied simply by doing
> >
> > cat fw_file > /sys/firmware/capsule/update
> >
> > With a properly formatted fw_file. Any error will be returned on close of
> > stdout. util-linux returns errors correctly from closing stdout, but
> > firmware
> > shippers should check whatever utilities package they use correctly captures
> > the error return on close.
>
> s/util-linux/coreutils/
>
> This still makes my API sense itch. It's kind of an abuse of
> open/write/close.
It works ... and according to Alan, NFS is already doing it. I suppose
we can have a do over of the whole debate again ...
> >
> > Signed-off-by: James Bottomley
> > ---
> > drivers/firmware/efi/Makefile | 2 +-
> > drivers/firmware/efi/capsule.c | 78
> > ++
> > drivers/firmware/efi/capsule.h | 2 ++
> > drivers/firmware/efi/efi.c | 8 +
> > 4 files changed, 89 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/firmware/efi/capsule.c
> > create mode 100644 drivers/firmware/efi/capsule.h
> >
> > diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> > index d8be608..698846e 100644
> > --- a/drivers/firmware/efi/Makefile
> > +++ b/drivers/firmware/efi/Makefile
> > @@ -1,7 +1,7 @@
> > #
> > # Makefile for linux kernel
> > #
> > -obj-$(CONFIG_EFI) += efi.o vars.o reboot.o
> > +obj-$(CONFIG_EFI) += efi.o vars.o reboot.o capsule.o
> > obj-$(CONFIG_EFI_VARS) += efivars.o
> > obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
> > obj-$(CONFIG_UEFI_CPER)+= cper.o
> > diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c
> > new file mode 100644
> > index 000..1fd78e7
> > --- /dev/null
> > +++ b/drivers/firmware/efi/capsule.c
> > @@ -0,0 +1,78 @@
> > +#include
> > +#include
> > +#include
> > +
> > +#include "capsule.h"
> > +
> > +static struct kset *capsule_kset;
> > +static struct transaction_buf *capsule_buf;
> > +
> > +static int capsule_data_write(struct file *file, struct kobject *kobj,
> > + struct bin_attribute *attr,
> > + char *buffer, loff_t offset, size_t count)
> > +{
> > + if (!capsule_buf) {
> > + capsule_buf = kmalloc(sizeof(*capsule_buf), GFP_KERNEL);
> > + if (!capsule_buf)
> > + return -ENOMEM;
> > + transaction_init(capsule_buf);
> > + }
> > +
> > + return transaction_write(capsule_buf, buffer, offset, count);
> > +}
>
> This seems unlikely to have good effects if two struct files are
> active at once.
I thought of threading ->open and using that to make it exclusive. But
then I thought caveat emptor.
I think for multiple files, I need a mutex in the transaction code just
to ensure orderly access.
> Also, I think you crash if you open and close without calling write,
yes there should be an if (!capsule_buf) return -EINVAL in flush
> and I don't know what whether there can be spurious flushes (fsync?).
It turns out that the bdi flusher and the fop->flush() operation are
totally different things. ->flush() is used mostly just to do stuff on
close (NFS uses it to tidy up for instance).
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/8] extcon: arizona: Add support for WM8998 and WM1814
Hi Richard,
This patch didn't include any description?
I think that you better to add the patch description.
Thanks,
Chanwoo Choi
On 04/29/2015 11:37 PM, Richard Fitzgerald wrote:
> Signed-off-by: Richard Fitzgerald
> Acked-by: Chanwoo Choi
> ---
> drivers/extcon/extcon-arizona.c | 33 ++---
> 1 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 830c5f9..586ec53 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1,7 +1,7 @@
> /*
> * extcon-arizona.c - Extcon driver Wolfson Arizona devices
> *
> - * Copyright (C) 2012 Wolfson Microelectronics plc
> + * Copyright (C) 2012-2014 Wolfson Microelectronics plc
> *
> * 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
> @@ -140,10 +140,14 @@ static void arizona_extcon_hp_clamp(struct
> arizona_extcon_info *info,
> bool clamp)
> {
> struct arizona *arizona = info->arizona;
> - unsigned int mask = 0, val = 0;
> + unsigned int mask, val = 0;
> int ret;
>
> switch (arizona->type) {
> + case WM8998:
> + case WM1814:
> + mask = 0;
> + break;
> case WM5110:
> mask = ARIZONA_HP1L_SHRTO | ARIZONA_HP1L_FLWR |
> ARIZONA_HP1L_SHRTI;
> @@ -175,17 +179,19 @@ static void arizona_extcon_hp_clamp(struct
> arizona_extcon_info *info,
>ret);
> }
>
> - ret = regmap_update_bits(arizona->regmap, ARIZONA_HP_CTRL_1L,
> - mask, val);
> - if (ret != 0)
> - dev_warn(arizona->dev, "Failed to do clamp: %d\n",
> + if (mask) {
> + ret = regmap_update_bits(arizona->regmap, ARIZONA_HP_CTRL_1L,
> + mask, val);
> + if (ret != 0)
> + dev_warn(arizona->dev, "Failed to do clamp: %d\n",
>ret);
>
> - ret = regmap_update_bits(arizona->regmap, ARIZONA_HP_CTRL_1R,
> - mask, val);
> - if (ret != 0)
> - dev_warn(arizona->dev, "Failed to do clamp: %d\n",
> - ret);
> + ret = regmap_update_bits(arizona->regmap, ARIZONA_HP_CTRL_1R,
> + mask, val);
> + if (ret != 0)
> + dev_warn(arizona->dev, "Failed to do clamp: %d\n",
> + ret);
> + }
>
> /* Restore the desired state while not doing the clamp */
> if (!clamp) {
> @@ -1176,6 +1182,11 @@ static int arizona_extcon_probe(struct platform_device
> *pdev)
> break;
> }
> break;
> + case WM8998:
> + case WM1814:
> + info->micd_clamp = true;
> + info->hpdet_ip_version = 2;
> + break;
> default:
> break;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
