Re: [PATCH] mtd: increase max page/OOB size to support 16K pagesize NAND
On Fri, Dec 13, 2013 at 05:03:49AM +, Caizhiyong wrote:
> From: Cai Zhiyong
> Date: Fri, 13 Dec 2013 12:52:46 +0800
> Subject: [PATCH] mtd: increase max page/OOB size to support 16K pagesize NAND.
>
> The Toshiba's TC58TEG5DCJTA pagesize is 16K, oob size is 1280 bytes.
> So increase the NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE.
It would help if we had nand_base/nand_ids support for TC58TEG5DCJTA
before we try to increase NAND_MAX_PAGESIZE and NAND_MAX_OOBSIZE yet
again. AFAICT, nand_base will not detect new, large Toshiba flash
properly anyway.
> Signed-off-by: Cai Zhiyong
> ---
> include/linux/mtd/nand.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index f3ea8da..2f0a7f2 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -56,8 +56,8 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs,
> uint64_t len);
> * is supported now. If you add a chip with bigger oobsize/page
> * adjust this accordingly.
> */
> -#define NAND_MAX_OOBSIZE 744
> -#define NAND_MAX_PAGESIZE8192
> +#define NAND_MAX_OOBSIZE 1280
> +#define NAND_MAX_PAGESIZE16384
It might be time to draw a line in the sand: next person who needs to
increase MAX_{PAGE,OOB}SIZE gets the job of killing the macro? We are
long overdue for dynamic buffer allocation.
There are two drivers that use the macros, plus nand_chip.buffers.*. The
drivers can be weaned off by allocating a small, fixed-size temporary
buffer for the few tasks that need it. With nand_base.c, I think we can
get by with waiting to allocate nand_chip.buffers until after we detect
the writesize/oobsize.
So Cai, are you up for this?
>
> /*
> * Constants for hardware specific CLE/ALE/NCE function
>
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] hfs: Known exploit detection for CVE-2011-4330
On Thu, Dec 12, 2013 at 05:52:26PM +0100, vegard.nos...@oracle.com wrote: > From: Vegard Nossum No need for this because we can get that from the email. > > See bc5b8a9003132ae44559edd63a1623b7b99dfb68. Put some human readable text in your changelog like the patch title or something. regards dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/8] Documentation: dt: kona-sdhci: Add clocks property
On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger wrote:
> The Kona SDHCI block requires a clock that must be specified in the
> device tree. Update the documentation to reflect this requirement.
>
> Signed-off-by: Tim Kryger
> Reviewed-by: Matt Porter
> ---
> Documentation/devicetree/bindings/mmc/kona-sdhci.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/kona-sdhci.txt
> b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt
> index 789fb07..aaba248 100644
> --- a/Documentation/devicetree/bindings/mmc/kona-sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt
> @@ -6,12 +6,16 @@ and the properties present in the bcm281xx SDHCI
> Required properties:
> - compatible : Should be "brcm,kona-sdhci"
> - DEPRECATED: compatible : Should be "bcm,kona-sdhci"
> +- clocks: phandle + clock specifier pair of the external clock
> +
> +Refer to clocks/clock-bindings.txt for generic clock consumer properties.
>
> Example:
>
> sdio2: sdio@0x3f1a {
> compatible = "brcm,kona-sdhci";
> reg = <0x3f1a 0x1>;
> + clocks = <&sdio3_clk>;
> interrupts = <0x0 74 0x4>;
> };
>
> --
> 1.8.0.1
>
Reviewed-by: Christian Daudt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: increase max page/OOB size to support 16K pagesize NAND
On Fri, Dec 13, 2013 at 03:27:12PM +0800, Huang Shijie wrote: > On Fri, Dec 13, 2013 at 05:03:49AM +, Caizhiyong wrote: > > --- a/include/linux/mtd/nand.h > > +++ b/include/linux/mtd/nand.h > > @@ -56,8 +56,8 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs, > > uint64_t len); > > * is supported now. If you add a chip with bigger oobsize/page > > * adjust this accordingly. > > */ > > -#define NAND_MAX_OOBSIZE 744 > > -#define NAND_MAX_PAGESIZE 8192 > > +#define NAND_MAX_OOBSIZE 1280 > > +#define NAND_MAX_PAGESIZE 16384 > maybe it is time to remove these two macros. It's like you read my mind :) Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hamradio/yam: fix info leak in ioctl
The yam_ioctl() code fails to initialise the cmd field of the struct yamdrv_ioctl_cfg. Add an explicit memset(0) before filling the structure to avoid the 4-byte info leak. Signed-off-by: Salva Peiró CC: --- drivers/net/hamradio/yam.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c index 1971411..bb02c8a 100644 --- a/drivers/net/hamradio/yam.c +++ b/drivers/net/hamradio/yam.c @@ -953,6 +953,7 @@ static int yam_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) struct yamdrv_ioctl_mcs *ym; int ioctl_cmd; + memset(&yi, 0, sizeof(yi)); if (copy_from_user(&ioctl_cmd, ifr->ifr_data, sizeof(int))) return -EFAULT; -- 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 v4 8/8] ARM: dts: Specify clocks for timer on bcm11351
On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger wrote:
> Specify the external clock label in the timer node.
>
> Signed-off-by: Tim Kryger
> Reviewed-by: Markus Mayer
> Reviewed-by: Matt Porter
> ---
> arch/arm/boot/dts/bcm11351.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 25ca128..1246885 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -95,7 +95,7 @@
> compatible = "brcm,kona-timer";
> reg = <0x35006000 0x1000>;
> interrupts = ;
> - clock-frequency = <32768>;
> + clocks = <&hub_timer_clk>;
> };
>
> gpio: gpio@35003000 {
> --
> 1.8.0.1
>
Reviewed-by: Christian Daudt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
CPU_FA526 lacks thumb state support and doesn't get along with some of the options enabled by ARCH_MULTI_V4T. More specifically it doesn't get along with CPU_ARM920T: CPU_ABRT_EV4T CPU_CACHE_V4WT CPU_COPY_V4WB CPU_TLB_V4WBI One or a combination of the above cause trouble for userspace, the following happens when kernel tries to exec init: [ 11.79] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004 [ 11.79] [ 11.79] CPU: 0 PID: 1 Comm: init Not tainted 3.13.0-rc3-next-20131212+ #1332 [ 11.79] [] (unwind_backtrace) from [] (show_stack+0x18/0x1c) [ 11.79] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 11.79] [] (dump_stack) from [] (panic+0x98/0x1ec) [ 11.79] [] (panic) from [] (do_exit+0x80c/0x8e8) [ 11.79] [] (do_exit) from [] (do_group_exit+0x44/0xb8) [ 11.79] [] (do_group_exit) from [] (get_signal_to_deliver+0x2fc/0x5a4) [ 11.79] [] (get_signal_to_deliver) from [] (do_signal+0xac/0x3e0) [ 11.79] [] (do_signal) from [] (do_work_pending+0xcc/0xe8) [ 11.79] [] (do_work_pending) from [] (work_pending+0xc/0x20) Reinsert ARCH_MULTI_V4 so it can be used on platforms with CPU_FA526. Signed-off-by: Jonas Jensen --- Notes: I don't know how to handle this so I'm making it standalone for your feedback (it was broken out from MOXA ART SoC series). This is important for MOXA ART (and other FA526 platforms), please have a look. Applies to next-20131213 arch/arm/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b64a8ef..4f88ff3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -863,6 +863,11 @@ menu "Multiple platform selection" comment "CPU Core family selection" +config ARCH_MULTI_V4 + bool "ARMv4 based platforms (FA526, StrongARM)" + depends on !ARCH_MULTI_V6_V7 + select ARCH_MULTI_V4_V5 + config ARCH_MULTI_V4T bool "ARMv4T based platforms (ARM720T, ARM920T, ...)" depends on !ARCH_MULTI_V6_V7 -- 1.8.2.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] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
On Fri, Dec 13, 2013 at 2:55 AM, José Miguel Gonçalves wrote: > On 27-09-2013 15:17, Linus Walleij wrote: >> On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves >> wrote: >> >>> Some GPIO line limits are incorrectly set which, for instance, >>> does not allow nRTS1 (GPH11) configuration on a S3C2416 chip. >>> >>> Signed-off-by: José Miguel Gonçalves >>> --- >>> arch/arm/mach-s3c24xx/include/mach/gpio.h | 10 +- (...) > > Was this patch forgotten? Not by me, I just never got an ACK from the Samsung maintainers, so I can't apply it to the GPIO tree. Ben, Kukjin: can one of you ACK this so I can take it through the GPIO tree? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: documentation: remove hopelessly out-of-date locking doc
On 12/10/2013 08:18 PM, Dave Hansen wrote: From: Dave Hansen Documentation/vm/locking is a blast from the past. In the entire git history, it has had precisely Three modifications. Two of those look to be pure renames, and the third was from 2005. The doc contains such gems as: The page_table_lock is grabbed while holding the kernel_lock spinning monitor. Page stealers hold kernel_lock to protect against a bunch of races. Or this which talks about mmap_sem: 4. The exception to this rule is expand_stack, which just takes the read lock and the page_table_lock, this is ok because it doesn't really modify fields anybody relies on. expand_stack() doesn't take any locks any more directly, and the mmap_sem acquisition was long ago moved up in to the page fault code itself. It could be argued that we need to rewrite this, but it is dangerous to leave it as-is. It will confuse more people than it helps. Heh yeah, when I started few months ago and stumbled upon this doc, people in the office suggested that I could send a patch that just deletes it. I wasn't that brave, but I agree nevertheless. Signed-off-by: Dave Hansen Acked-by: Vlastimil Babka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: uhci_hcd: Possible corruption of DMA pool uhci->td_pool
On 12/11/2013 08:41 PM, Alan Stern wrote: On Wed, 11 Dec 2013, Eugene Shatokhin wrote: Hi, On ROSA Linux with kernel 3.10.21 with DMA debug options enabled, the kernel sometimes issues a warning about DMA pool corruption (see the log below). That happens sometimes, when the system boots or resumes from hibernation with Samson C01U USB microphone attached. The affected DMA pool is 'uhci->td_pool', uhci_alloc_td() from drivers/usb/host/uhci-hcd.c makes the relevant dma_pool_alloc() calls. Any ideas about how to find what causes this and how to fix it? This is not an easy sort of thing to track down... Here is the relevant part of the system log: [ 22.264332] usb 2-1: new full-speed USB device number 2 using uhci_hcd [ 22.450609] usb 2-1: New USB device found, idVendor=17a0, idProduct=0001 [ 22.450626] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 22.450639] usb 2-1: Product: Samson C01U [ 22.450649] usb 2-1: Manufacturer: Samson Technologies <...> [ 280.703483] retire_capture_urb: 4494 callbacks suppressed [ 284.961087] uhci_hcd :00:1d.1: dma_pool_alloc uhci_td, efb7b060 (corruped) [ 284.961087] : 00 06 00 00 af 00 00 03 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0020: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] retire_capture_urb: 4343 callbacks suppressed [ 284.961087] uhci_hcd :00:1d.1: dma_pool_alloc uhci_td, efb7b5d0 (corruped) [ 284.961087] : 00 06 00 00 af 00 00 03 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0020: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) 0xa7 is POOL_POISON_FREED. The memory pages to be allocated from the pool should be filled with such bytes. Each time I observed this problem, the first 8 bytes of the listed memory area were overwritten, with different data each time. It kind of looks like a hardware bug. Still, it's hard to say. Can you test the current 3.13-rc kernel? There have been a few recent changes in this area that might have an effect. I tested 3.13-rc3 - the problem has not shown up so far. Regards, Eugene -- Eugene Shatokhin, ROSA Laboratory. www.rosalab.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: [RFC/PATCH 3/3] usb/xhci-plat: remove unnecessary #ifdef checks for CONFIG_PM_SLEEP
On 13 December 2013 06:18, David Cohen wrote:
> From: Santosh Shilimkar
>
> Drivers using SET_*_PM_OPS() no longer need to #ifdef for CONFIG_PM_*
> So, let's remove the unnecessary #ifdef's.
>
> Signed-off-by: Santosh Shilimkar
> Signed-off-by: David Cohen
> ---
> drivers/usb/host/xhci-plat.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index d9c169f470d3..b1d93c344e04 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -197,7 +197,6 @@ static int xhci_plat_remove(struct platform_device *dev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
I think you can solve this in another way.
As a start, I would suggest to change above to CONFIG_PM_SLEEP
> static int xhci_plat_suspend(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> @@ -217,10 +216,6 @@ static int xhci_plat_resume(struct device *dev)
> static const struct dev_pm_ops xhci_plat_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
> };
> -#define DEV_PM_OPS (&xhci_plat_pm_ops)
> -#else
> -#define DEV_PM_OPS NULL
> -#endif /* CONFIG_PM */
Remove the use of DEV_PM_OPS define. Instead use below macro and
outside #ifdef CONFIG_PM_SLEEP.
"static SIMPLE_DEV_PM_OPS(xhci_plat_pm_ops, xhci_plat_suspend,
xhci_plat_resume)"
That should do the trick I believe, without the need for changing the
existing SET_SYSTEM_SLEEP_PM_OPS macro in patch1.
Kind regards
Ulf Hansson
>
> #ifdef CONFIG_OF
> static const struct of_device_id usb_xhci_of_match[] = {
> @@ -235,7 +230,7 @@ static struct platform_driver usb_xhci_driver = {
> .remove = xhci_plat_remove,
> .driver = {
> .name = "xhci-hcd",
> - .pm = DEV_PM_OPS,
> + .pm = &xhci_plat_pm_ops,
> .of_match_table = of_match_ptr(usb_xhci_of_match),
> },
> };
> --
> 1.8.4.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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 09/10] power8, perf: Change BHRB branch filter configuration
On 12/09/2013 11:51 AM, Michael Ellerman wrote:
>
> As I said in my comments on version 3 which you ignored:
>
> I think it would be clearer if we actually checked for the possibilities
> we
> allow and let everything else fall through, eg:
>
> Â Â Â Â Â Â Â Â /* Ignore user/kernel/hv bits */
> Â Â Â Â Â Â Â Â branch_sample_type &= ~PERF_SAMPLE_BRANCH_PLM_ALL;
>
> Â Â Â Â Â Â Â Â if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY)
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â return 0;
>
> Â Â Â Â Â Â Â Â if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY_CALL)
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â return POWER8_MMCRA_IFM1;
> Â
> Â Â Â Â Â Â Â Â if (branch_sample_type == PERF_SAMPLE_BRANCH_COND)
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â return POWER8_MMCRA_IFM3;
> Â Â Â Â Â Â Â Â
> Â Â Â Â Â Â Â Â return -1;
>
Hey Michael,
This patch only adds support for the PERF_SAMPLE_BRANCH_COND filter, if the
over all code flow does not clearly suggest that all combinations of any of
these HW filters are invalid, then we can go with one more patch to clean
that up before or after this patch but not here in this patch. Finally the
code section here will look something like this. Does it sound good ?
static u64 power8_bhrb_filter_map(u64 branch_sample_type)
{
u64 pmu_bhrb_filter = 0;
/* BHRB and regular PMU events share the same privilege state
* filter configuration. BHRB is always recorded along with a
* regular PMU event. As the privilege state filter is handled
* in the basic PMC configuration of the accompanying regular
* PMU event, we ignore any separate BHRB specific request.
*/
/* Ignore user, kernel, hv bits */
branch_sample_type &= ~PERF_SAMPLE_BRANCH_PLM_ALL;
if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY)
return pmu_bhrb_filter;
if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY_CALL) {
pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
return pmu_bhrb_filter;
}
if (branch_sample_type == PERF_SAMPLE_BRANCH_COND) {
pmu_bhrb_filter |= POWER8_MMCRA_IFM3;
return pmu_bhrb_filter;
}
/* Every thing else is unsupported */
return -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 1/9] Known exploit detection
On 12/12/2013 08:06 PM, Theodore Ts'o wrote: On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote: The idea is simple -- since different kernel versions are vulnerable to different root exploits, hackers most likely try multiple exploits before they actually succeed. Suppose we put put this into the mainstream kernel. Wouldn't writers of root kit adapt by checking for the kernel version to avoid checking for exploits that are known not work? So the question is whether the additional complexity in the kernel is going to be worth it, since once the attackers adapt, the benefits of trying to detect attacks for mitigated exploits will be minimal. Yeah, you could probably avoid detection by being more careful. But I think it would be worth making it harder; I'd argue that the "additional complexity" in this case is minimal, since we are mostly talking about ~1 line added to an error path for each critical vulnerability. Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/8] ARM: dts: Specify clocks for SDHCIs on bcm11351
On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger wrote: > Specify the external clock label in each SDHCI node. > > Signed-off-by: Tim Kryger > Reviewed-by: Markus Mayer > Reviewed-by: Matt Porter > --- > arch/arm/boot/dts/bcm11351.dtsi | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi > index 9b99c52..25ca128 100644 > --- a/arch/arm/boot/dts/bcm11351.dtsi > +++ b/arch/arm/boot/dts/bcm11351.dtsi > @@ -118,6 +118,7 @@ > compatible = "brcm,kona-sdhci"; > reg = <0x3f18 0x1>; > interrupts = ; > + clocks = <&sdio1_clk>; > status = "disabled"; > }; > > @@ -125,6 +126,7 @@ > compatible = "brcm,kona-sdhci"; > reg = <0x3f19 0x1>; > interrupts = ; > + clocks = <&sdio2_clk>; > status = "disabled"; > }; > > @@ -132,6 +134,7 @@ > compatible = "brcm,kona-sdhci"; > reg = <0x3f1a 0x1>; > interrupts = ; > + clocks = <&sdio3_clk>; > status = "disabled"; > }; > > @@ -139,6 +142,7 @@ > compatible = "brcm,kona-sdhci"; > reg = <0x3f1b 0x1>; > interrupts = ; > + clocks = <&sdio4_clk>; > status = "disabled"; > }; > > -- > 1.8.0.1 > Reviewed-by: Christian Daudt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] drivers: misc: Mark functions as static in ad525x_dpot.c
On 12/13/2013 07:57 AM, Rashika Kheria wrote:
This patch marks the function ad_dpot_add_files() and
ad_dpot_remove_files() as static in ad525x_dpot.c because they are not
used outside this file.
Thus, it also eliminates the following warnings in ad525x_dpot.c:
drivers/misc/ad525x_dpot.c:644:5: warning: no previous prototype for
‘ad_dpot_add_files’ [-Wmissing-prototypes]
drivers/misc/ad525x_dpot.c:669:13: warning: no previous prototype for
‘ad_dpot_remove_files’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Acked-by: Michael Hennerich
---
drivers/misc/ad525x_dpot.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/ad525x_dpot.c b/drivers/misc/ad525x_dpot.c
index 0daadcf..d3eee11 100644
--- a/drivers/misc/ad525x_dpot.c
+++ b/drivers/misc/ad525x_dpot.c
@@ -641,7 +641,7 @@ static const struct attribute_group ad525x_group_commands =
{
.attrs = ad525x_attributes_commands,
};
-int ad_dpot_add_files(struct device *dev,
+static int ad_dpot_add_files(struct device *dev,
unsigned features, unsigned rdac)
{
int err = sysfs_create_file(&dev->kobj,
@@ -666,7 +666,7 @@ int ad_dpot_add_files(struct device *dev,
return err;
}
-inline void ad_dpot_remove_files(struct device *dev,
+static inline void ad_dpot_remove_files(struct device *dev,
unsigned features, unsigned rdac)
{
sysfs_remove_file(&dev->kobj,
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PULL REQUEST] i2c for 3.13
Linus, here are two simple but wanted fixes for the i2c subsystem. Please pull. Thanks, Wolfram The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e: Linux 3.13-rc3 (2013-12-06 09:34:04 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to e5bf216a945e7292f8718276372d2b41486bed26: i2c: imx: Check the return value from clk_prepare_enable() (2013-12-12 22:48:22 +0100) Elie De Brauwer (1): i2c: mux: Inherit retry count and timeout from parent for muxed bus Fabio Estevam (1): i2c: imx: Check the return value from clk_prepare_enable() drivers/i2c/busses/i2c-imx.c | 4 +++- drivers/i2c/i2c-mux.c| 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-) signature.asc Description: Digital signature
Re: [PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
Am Freitag, 13. Dezember 2013, 09:12:52 schrieb Linus Walleij: > On Fri, Dec 13, 2013 at 2:55 AM, José Miguel Gonçalves > > wrote: > > On 27-09-2013 15:17, Linus Walleij wrote: > >> On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves > >> > >> wrote: > >>> Some GPIO line limits are incorrectly set which, for instance, > >>> does not allow nRTS1 (GPH11) configuration on a S3C2416 chip. > >>> > >>> Signed-off-by: José Miguel Gonçalves > >>> --- > >>> > >>> arch/arm/mach-s3c24xx/include/mach/gpio.h | 10 +- > > (...) > > > Was this patch forgotten? > > Not by me, I just never got an ACK from the Samsung maintainers, > so I can't apply it to the GPIO tree. > > Ben, Kukjin: can one of you ACK this so I can take it through the > GPIO tree? again not the maintainer :-), but I've looked through the manuals of s3c24xx socs and the new values look correct [I had looked up the patch content in the list archive], so Acked-by: Heiko Stuebner But Jose, you should really really look into moving to devicetree with your platform, if you're not already doing so. Pinctrl support is already present, and I'm hopefull the move to the common clock framework I posted a few days ago might make it too. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sched: update runqueue clock before migrations away
On 12 December 2013 19:24, Peter Zijlstra wrote: > On Tue, Dec 10, 2013 at 03:55:43PM +, Chris Redpath wrote: >> >That's guestimating the last_runnable_update based on decay_count, and >> >per the previous the decay count can get slightly out of sync. >> >> The guesstimation works fine, the issue is only that we can't tell at >> this point how much time that entity was asleep when the CPU it ran on >> has no tick and since it is too expensive to synchronize the clocks, >> there isn't (currently) a way to find out without updating the rq we >> came from. >> >> I can't see anything handy lying around in struct rq, but is there a >> copy of the jiffies held anywhere per-cpu presuming it would stop being >> updated when the tick stops? If not, I could store one somewhere as part >> of turning the tick off and then we could use the difference between >> that and the current jiffies count to estimate the amount of time in >> limbo. That would almost certainly be accurate enough for me - a few ms >> won't hurt but when we lose seconds it does. > > Would pre_schedule_idle() -> rq_last_tick_reset() -> rq->last_sched_tick > be useful? > > I suppose we could easily lift that to NO_HZ_COMMON. > > Which raises another point; I dislike this idle pre/post business. Why > can't the post_schedule_idle() calls be done from pick_next_task_idle() > and pre_schedule_idle() done from put_prev_task_idle() ? The update of runnable_avg for a cpu that becomes idle, must be done before the call to idle_balance which will use it; So idle_enter_fair is called in pre_schedule_idle. idle_exit_fair has been put in the post_schedule function in order to be symmetric and coherent but nothing prevent from moving it in pick_next_task_idle. Vincent > > That would avoid the post_schedule() rq->lock dance. > > Vince? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl: at91: implement at91_pinconf_dbg_show
On 07/12/2013 14:08, Alexandre Belloni :
This allows to get the pin configuration by using debugfs. On my system:
# cat /sys/kernel/debug/pinctrl/pinctrl.3/pinconf-pins
Signed-off-by: Alexandre Belloni
I am fine with these helpers:
Acked-by: Nicolas Ferre
But still a little disappointed that Laurent announced that he wouldn't
review the whole kernel ;-)
Bye guys and thanks a lot!
---
drivers/pinctrl/pinctrl-at91.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index b0b78f3468ae..bcfc8a2eebca 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -784,10 +784,35 @@ static int at91_pinconf_set(struct pinctrl_dev *pctldev,
return 0;
}
+#define DBG_SHOW_FLAG(flag) do { \
+ if (config & flag) {\
+ if (num_conf) \
+ seq_puts(s, "|"); \
+ seq_puts(s, #flag); \
+ num_conf++; \
+ } \
+} while (0)
+
static void at91_pinconf_dbg_show(struct pinctrl_dev *pctldev,
struct seq_file *s, unsigned pin_id)
{
+ unsigned long config;
+ int ret, val, num_conf = 0;
+
+ ret = at91_pinconf_get(pctldev, pin_id, &config);
+
+ DBG_SHOW_FLAG(MULTI_DRIVE);
+ DBG_SHOW_FLAG(PULL_UP);
+ DBG_SHOW_FLAG(PULL_DOWN);
+ DBG_SHOW_FLAG(DIS_SCHMIT);
+ DBG_SHOW_FLAG(DEGLITCH);
+ DBG_SHOW_FLAG(DEBOUNCE);
+ if (config & DEBOUNCE) {
+ val = config >> DEBOUNCE_VAL_SHIFT;
+ seq_printf(s, "(%d)", val);
+ }
+ return;
}
static void at91_pinconf_group_dbg_show(struct pinctrl_dev *pctldev,
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] perf tools: Fix next_pow2_l()
Hi My implementation of next_pow2_l() was incorrect. Here is a fix, after which next_pow2() is unused so I remove it and rename next_pow2_l() -> next_pow2() Adrian Hunter (2): perf tools: Fix next_pow2_l() perf tools: Remove unused next_pow2() and rename next_pow2_l() tools/perf/util/evlist.c | 2 +- tools/perf/util/util.h | 22 -- 2 files changed, 9 insertions(+), 15 deletions(-) Regards Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf tools: Fix next_pow2_l()
My implementation of next_pow2_l() was incorrect.
e.g.
perf record -m4296015872 uname
rounding mmap pages size to 17592186044416 bytes (4294967296 pages)
Invalid argument for --mmap_pages/-m
Notice that the next power-of-2 value 4294967296 is
less than the option value 4296015872.
Change to using __builtin_clzl() and prevent the
shift being equal to the width of the operand.
Also __builtin_clzl(x) is undefined if x is 0,
so adjust the condition to preclude that
possibility. Now:
perf record -m4296015872 uname
rounding mmap pages size to 35184372088832 bytes (8589934592 pages)
Invalid argument for --mmap_pages/-m
Signed-off-by: Adrian Hunter
---
tools/perf/util/util.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index a1eea3e..ae609fe 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -284,13 +284,14 @@ static inline unsigned next_pow2(unsigned x)
static inline unsigned long next_pow2_l(unsigned long x)
{
-#if BITS_PER_LONG == 64
- if (x <= (1UL << 31))
- return next_pow2(x);
- return (unsigned long)next_pow2(x >> 32) << 32;
-#else
- return next_pow2(x);
-#endif
+ int leading_zeros;
+
+ if (x < 2)
+ return 1;
+ leading_zeros = __builtin_clzl(x - 1);
+ if (!leading_zeros)
+ return 0;
+ return 1UL << (BITS_PER_LONG - leading_zeros);
}
size_t hex_width(u64 v);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG in munlock_vma_pages_range
On 12/13/2013 05:05 AM, Sasha Levin wrote:
> On 12/12/2013 07:41 AM, Vlastimil Babka wrote:
>> On 12/12/2013 06:03 AM, Bob Liu wrote:
>>>
>>> On 12/12/2013 11:16 AM, Sasha Levin wrote:
On 12/11/2013 05:59 PM, Vlastimil Babka wrote:
> On 12/09/2013 09:26 PM, Sasha Levin wrote:
>> On 12/09/2013 12:12 PM, Vlastimil Babka wrote:
>>> On 12/09/2013 06:05 PM, Sasha Levin wrote:
On 12/09/2013 04:34 AM, Vlastimil Babka wrote:
> Hello, I will look at it, thanks.
> Do you have specific reproduction instructions?
Not really, the fuzzer hit it once and I've been unable to trigger
it again. Looking at
the piece of code involved it might have had something to do with
hugetlbfs, so I'll crank
up testing on that part.
>>>
>>> Thanks. Do you have trinity log and the .config file? I'm currently
>>> unable to even boot linux-next
>>> with my config/setup due to a GPF.
>>> Looking at code I wouldn't expect that it could encounter a tail
>>> page, without first encountering a
>>> head page and skipping the whole huge page. At least in THP case, as
>>> TLB pages should be split when
>>> a vma is split. As for hugetlbfs, it should be skipped for
>>> mlock/munlock operations completely. One
>>> of these assumptions is probably failing here...
>>
>> If it helps, I've added a dump_page() in case we hit a tail page
>> there and got:
>>
>> [ 980.172299] page:ea003e5e8040 count:0 mapcount:1
>> mapping: (null) index:0
>> x0
>> [ 980.173412] page flags: 0x2f80008000(tail)
>>
>> I can also add anything else in there to get other debug output if
>> you think of something else useful.
>
> Please try the following. Thanks in advance.
[ 428.499889] page:ea003e5c0040 count:0 mapcount:4
mapping: (null) index:0x0
[ 428.499889] page flags: 0x2f80008000(tail)
[ 428.499889] start=140117131923456 pfn=16347137
orig_start=140117130543104 page_increm
=1 vm_start=140117130543104 vm_end=140117134688256 vm_flags=135266419
[ 428.499889] first_page pfn=16347136
[ 428.499889] page:ea003e5c count:204 mapcount:44
mapping:880fb5c466c1 inde
x:0x7f6f8fe00
[ 428.499889] page flags:
0x2f80084068(uptodate|lru|active|head|swapbacked)
>>>
>>> From this print, it looks like the page is still a huge page.
>>> One situation I guess is a huge page which isn't PageMlocked and passed
>>> to munlock_vma_page(). I'm not sure whether this will happen.
>>
>> Yes that's quite likely the case. It's not illegal to happen I would say.
>>
>>> Please take a try this patch.
>>
>> I've made a simpler version that does away with the ugly page_mask
>> thing completely.
>> Please try that as well. Thanks.
>>
>> Also when working on this I think I found another potential but much
>> rare problem
>> when munlock_vma_page races with a THP split. That would however
>> manifest such that
>> part of the former tail pages would stay PageMlocked. But that still
>> needs more thought.
>> The bug at hand should however be fixed by this patch.
>
> Yup, this patch seems to fix the issue previously reported.
>
> However, I'll piggyback another thing that popped up now that the vm
> could run for a while which
> also seems to be caused by the original patch. It looks like a pretty
> straightforward deadlock, but
Looks like put_page() in __munlock_pagevec() need to get the
zone->lru_lock which is already held when entering __munlock_pagevec().
How about fix like this?
Thanks,
-Bob
diff --git a/mm/mlock.c b/mm/mlock.c
index d480cd6..5880d63 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -291,7 +291,6 @@ static void __munlock_pagevec(struct pagevec *pvec,
struct zone *zone)
int pgrescued = 0;
/* Phase 1: page isolation */
- spin_lock_irq(&zone->lru_lock);
for (i = 0; i < nr; i++) {
struct page *page = pvec->pages[i];
@@ -300,6 +299,7 @@ static void __munlock_pagevec(struct pagevec *pvec,
struct zone *zone)
int lru;
if (PageLRU(page)) {
+ spin_lock_irq(&zone->lru_lock);
lruvec = mem_cgroup_page_lruvec(page, zone);
lru = page_lru(page);
/*
@@ -308,6 +308,7 @@ static void __munlock_pagevec(struct pagevec *pvec,
struct zone *zone)
*/
ClearPageLRU(page);
del_page_from_lru_list(page, lruvec, lru);
+ spin_unlock_irq(&zone->lru_lock);
} else {
__munlock_isolation_failed(page);
goto skip_munlock;
@@ -325,8 +326,7 @@ skip_munlock:
delta_munlocked++
[PATCH 2/2] perf tools: Remove unused next_pow2() and rename next_pow2_l()
The fixed version of 'next_pow2_l()' does not call
'next_pow2()' anymore, so it is unused, so remove
it and rename 'next_pow2_l()' to 'next_pow2()'.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 2 +-
tools/perf/util/util.h | 9 +
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 0b31cee..327a1a4 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -736,7 +736,7 @@ static long parse_pages_arg(const char *str, unsigned long
min,
/* leave number of pages at 0 */
} else if (!is_power_of_2(pages)) {
/* round pages up to next power of 2 */
- pages = next_pow2_l(pages);
+ pages = next_pow2(pages);
if (!pages)
return -EINVAL;
pr_info("rounding mmap pages size to %lu bytes (%lu pages)\n",
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index ae609fe..3860d76 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -275,14 +275,7 @@ bool is_power_of_2(unsigned long n)
return (n != 0 && ((n & (n - 1)) == 0));
}
-static inline unsigned next_pow2(unsigned x)
-{
- if (!x)
- return 1;
- return 1ULL << (32 - __builtin_clz(x - 1));
-}
-
-static inline unsigned long next_pow2_l(unsigned long x)
+static inline unsigned long next_pow2(unsigned long x)
{
int leading_zeros;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] drivers: misc: Mark functions as static in grukservices.c
On Fri, Dec 13, 2013 at 12:12:34PM +0530, Rashika Kheria wrote:
> This patch marks the function gru_get_cb_exception_detail_str() and
> gru_abort() as static in sgi-gru/grukservices.c because they are not
> used outside this file.
>
> Thus, it also eliminates the following warnings in
> sgi-gru/grukservices.c:
> drivers/misc/sgi-gru/grukservices.c:432:7: warning: no previous prototype for
> ‘gru_get_cb_exception_detail_str’ [-Wmissing-prototypes]
> drivers/misc/sgi-gru/grukservices.c:508:6: warning: no previous prototype for
> ‘gru_abort’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/misc/sgi-gru/grukservices.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/sgi-gru/grukservices.c
> b/drivers/misc/sgi-gru/grukservices.c
> index 913de07..29d1582 100644
> --- a/drivers/misc/sgi-gru/grukservices.c
> +++ b/drivers/misc/sgi-gru/grukservices.c
> @@ -429,7 +429,7 @@ int gru_get_cb_exception_detail(void *cb,
> return 0;
> }
>
> -char *gru_get_cb_exception_detail_str(int ret, void *cb,
> +static char *gru_get_cb_exception_detail_str(int ret, void *cb,
> char *buf, int size)
> {
> struct gru_control_block_status *gen = (void *)cb;
> @@ -505,7 +505,7 @@ int gru_wait_proc(void *cb)
> return ret;
> }
>
> -void gru_abort(int ret, void *cb, char *str)
> +static void gru_abort(int ret, void *cb, char *str)
> {
> char buf[GRU_EXC_STR_SIZE];
>
> --
> 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 2/5] drivers: misc: Mark functions as static in xp_main.c
On Fri, Dec 13, 2013 at 12:21:20PM +0530, Rashika Kheria wrote:
> This patch marks the function xp_init() and xp_exit() as static in
> sgi-xp/xp_main.c because they are not used outside this file.
>
> Thus, it also eliminates the following warnings in sgi-xp/xp_main.c:
> drivers/misc/sgi-xp/xp_main.c:249:1: warning: no previous prototype for
> ‘xp_init’ [-Wmissing-prototypes]
> drivers/misc/sgi-xp/xp_main.c:274:1: warning: no previous prototype for
> ‘xp_exit’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/misc/sgi-xp/xp_main.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/sgi-xp/xp_main.c b/drivers/misc/sgi-xp/xp_main.c
> index 01be66d..df14c70 100644
> --- a/drivers/misc/sgi-xp/xp_main.c
> +++ b/drivers/misc/sgi-xp/xp_main.c
> @@ -245,7 +245,7 @@ xpc_disconnect(int ch_number)
> }
> EXPORT_SYMBOL_GPL(xpc_disconnect);
>
> -int __init
> +static int __init
> xp_init(void)
> {
> enum xp_retval ret;
> @@ -270,7 +270,7 @@ xp_init(void)
>
> module_init(xp_init);
>
> -void __exit
> +static void __exit
> xp_exit(void)
> {
> if (is_shub())
> --
> 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 3/5] drivers: misc: Mark functions as static in xpc_main.c
On Fri, Dec 13, 2013 at 12:24:05PM +0530, Rashika Kheria wrote:
> This patch marks the function xpc_init() and xpc_exit() as static in
> sgi-xp/xpc_main.c because they are not used outside this file.
>
> Thus, it also eliminates the following warnings in sgi-xp/xpc_main.c:
> drivers/misc/sgi-xp/xpc_main.c:1231:1: warning: no previous prototype for
> ‘xpc_init’ [-Wmissing-prototypes]
> drivers/misc/sgi-xp/xpc_main.c:1349:1: warning: no previous prototype for
> ‘xpc_exit’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/misc/sgi-xp/xpc_main.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
> index 82dc574..5b1b10d 100644
> --- a/drivers/misc/sgi-xp/xpc_main.c
> +++ b/drivers/misc/sgi-xp/xpc_main.c
> @@ -1227,7 +1227,7 @@ xpc_system_die(struct notifier_block *nb, unsigned long
> event, void *_die_args)
> return NOTIFY_DONE;
> }
>
> -int __init
> +static int __init
> xpc_init(void)
> {
> int ret;
> @@ -1345,7 +1345,7 @@ out_1:
>
> module_init(xpc_init);
>
> -void __exit
> +static void __exit
> xpc_exit(void)
> {
> xpc_do_exit(xpUnloading);
> --
> 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 5/5] drivers: misc: Mark function jp_generic_ide_ioctl() as static in lkdtm.c
On Fri, Dec 13, 2013 at 12:29:42PM +0530, Rashika Kheria wrote:
> This patch marks the function jp_generic_ide_ioctl() as static in
> lkdtm.c because it is not used outside this file.
>
> Thus, it also eliminates the following warnings in lkdtm.c:
> drivers/misc/lkdtm.c:227:5: warning: no previous prototype for
> ‘jp_generic_ide_ioctl’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/misc/lkdtm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
> index a2edb2e..79b677e 100644
> --- a/drivers/misc/lkdtm.c
> +++ b/drivers/misc/lkdtm.c
> @@ -224,7 +224,7 @@ static int jp_scsi_dispatch_cmd(struct scsi_cmnd *cmd)
> }
>
> #ifdef CONFIG_IDE
> -int jp_generic_ide_ioctl(ide_drive_t *drive, struct file *file,
> +static int jp_generic_ide_ioctl(ide_drive_t *drive, struct file *file,
> struct block_device *bdev, unsigned int cmd,
> unsigned long arg)
> {
> --
> 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 4/5] drivers: misc: Mark functions as static in ad525x_dpot.c
On Fri, Dec 13, 2013 at 12:27:10PM +0530, Rashika Kheria wrote:
> This patch marks the function ad_dpot_add_files() and
> ad_dpot_remove_files() as static in ad525x_dpot.c because they are not
> used outside this file.
>
> Thus, it also eliminates the following warnings in ad525x_dpot.c:
> drivers/misc/ad525x_dpot.c:644:5: warning: no previous prototype for
> ‘ad_dpot_add_files’ [-Wmissing-prototypes]
> drivers/misc/ad525x_dpot.c:669:13: warning: no previous prototype for
> ‘ad_dpot_remove_files’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/misc/ad525x_dpot.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/ad525x_dpot.c b/drivers/misc/ad525x_dpot.c
> index 0daadcf..d3eee11 100644
> --- a/drivers/misc/ad525x_dpot.c
> +++ b/drivers/misc/ad525x_dpot.c
> @@ -641,7 +641,7 @@ static const struct attribute_group ad525x_group_commands
> = {
> .attrs = ad525x_attributes_commands,
> };
>
> -int ad_dpot_add_files(struct device *dev,
> +static int ad_dpot_add_files(struct device *dev,
> unsigned features, unsigned rdac)
> {
> int err = sysfs_create_file(&dev->kobj,
> @@ -666,7 +666,7 @@ int ad_dpot_add_files(struct device *dev,
> return err;
> }
>
> -inline void ad_dpot_remove_files(struct device *dev,
> +static inline void ad_dpot_remove_files(struct device *dev,
> unsigned features, unsigned rdac)
> {
> sysfs_remove_file(&dev->kobj,
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers: platform: Mark functions as static in hp_accel.c
On Fri, Dec 13, 2013 at 12:56:34PM +0530, Rashika Kheria wrote:
> This patch marks the functions lis3lv02d_acpi_init(),
> lis3lv02d_acpi_read() and lis3lv02d_acpi_write() as static in
> x86/hp_accel.c because they are not used outside this file.
>
> Thus, it also eliminates the following warnings in x86/hp_accel.c:
> drivers/platform/x86/hp_accel.c:91:5: warning: no previous prototype for
> ‘lis3lv02d_acpi_init’ [-Wmissing-prototypes]
> drivers/platform/x86/hp_accel.c:109:5: warning: no previous prototype for
> ‘lis3lv02d_acpi_read’ [-Wmissing-prototypes]
> drivers/platform/x86/hp_accel.c:132:5: warning: no previous prototype for
> ‘lis3lv02d_acpi_write’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/platform/x86/hp_accel.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/x86/hp_accel.c b/drivers/platform/x86/hp_accel.c
> index a8e43cf..01b619e 100644
> --- a/drivers/platform/x86/hp_accel.c
> +++ b/drivers/platform/x86/hp_accel.c
> @@ -88,7 +88,7 @@ MODULE_DEVICE_TABLE(acpi, lis3lv02d_device_ids);
> *
> * Returns 0 on success.
> */
> -int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
> +static int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
> {
> struct acpi_device *dev = lis3->bus_priv;
> if (acpi_evaluate_object(dev->handle, METHOD_NAME__INI,
> @@ -106,7 +106,7 @@ int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
> *
> * Returns 0 on success.
> */
> -int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8 *ret)
> +static int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8 *ret)
> {
> struct acpi_device *dev = lis3->bus_priv;
> union acpi_object arg0 = { ACPI_TYPE_INTEGER };
> @@ -129,7 +129,7 @@ int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg,
> u8 *ret)
> *
> * Returns 0 on success.
> */
> -int lis3lv02d_acpi_write(struct lis3lv02d *lis3, int reg, u8 val)
> +static int lis3lv02d_acpi_write(struct lis3lv02d *lis3, int reg, u8 val)
> {
> struct acpi_device *dev = lis3->bus_priv;
> unsigned long long ret; /* Not used when writting */
> --
> 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 2/2] drivers: platform: Include appropriate header file in mxm-wmi.c
On Fri, Dec 13, 2013 at 12:59:52PM +0530, Rashika Kheria wrote: > This patch includes appropriate header file linux/mxm-wmi.h in > x86/mxm-wmi.c because functions mxm_wmi_call_mxds(), mxm_wmi_call_mxmx() > and mxm_wmi_supported() have their prototype declaration in > linux/mxm-wmi.h. > > Thus, it also eliminates the following warnings in x86/mxm-wmi.c: > drivers/platform/x86/mxm-wmi.c:43:5: warning: no previous prototype for > ‘mxm_wmi_call_mxds’ [-Wmissing-prototypes] > drivers/platform/x86/mxm-wmi.c:68:5: warning: no previous prototype for > ‘mxm_wmi_call_mxmx’ [-Wmissing-prototypes] > drivers/platform/x86/mxm-wmi.c:93:6: warning: no previous prototype for > ‘mxm_wmi_supported’ [-Wmissing-prototypes] > > Signed-off-by: Rashika Kheria Reviewed-by: Josh Triplett > drivers/platform/x86/mxm-wmi.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/platform/x86/mxm-wmi.c b/drivers/platform/x86/mxm-wmi.c > index 0aea63b..7503d2b 100644 > --- a/drivers/platform/x86/mxm-wmi.c > +++ b/drivers/platform/x86/mxm-wmi.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] drivers: message: Mark function mpt_SoftResetHandler() as static in mptbase.c
On Fri, Dec 13, 2013 at 11:33:11AM +0530, Rashika Kheria wrote:
> This patch marks the function mpt_SoftResetHandler() as static in mptbase.c
> because it is not used outside this file.
>
> Thus, it also eliminates the following warning in fusion/mptbase.c:
> drivers/message/fusion/mptbase.c:7011:1: warning: no previous prototype for
> ‘mpt_SoftResetHandler’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/message/fusion/mptbase.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/message/fusion/mptbase.c
> b/drivers/message/fusion/mptbase.c
> index 767ff4d..c783a42 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -7007,7 +7007,7 @@ EXPORT_SYMBOL(mpt_halt_firmware);
> * IOC doesn't reply to any outstanding request. This will transfer IOC
> * to READY state.
> **/
> -int
> +static int
> mpt_SoftResetHandler(MPT_ADAPTER *ioc, int sleepFlag)
> {
> int rc;
> --
> 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 3/3] drivers: message: Mark functions as static in mptsas.c
On Fri, Dec 13, 2013 at 11:40:35AM +0530, Rashika Kheria wrote:
> This patch marks the function mptsas_refreshing_device_handles(),
> mptsas_expander_add() and mptsas_shutdown() as static in fusion/mptsas.c
> because they are not used outside this file.
>
> Thus, it also eliminates the following warnings in fusion/mptsas.c:
> drivers/message/fusion/mptsas.c:1579:1: warning: no previous prototype for
> ‘mptsas_refreshing_device_handles’ [-Wmissing-prototypes]
> drivers/message/fusion/mptsas.c:3654:1: warning: no previous prototype for
> ‘mptsas_expander_add’ [-Wmissing-prototypes]
> drivers/message/fusion/mptsas.c:5327:1: warning: no previous prototype for
> ‘mptsas_shutdown’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/message/fusion/mptsas.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
> index dd239bd..906f448 100644
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -1575,7 +1575,7 @@ mptsas_del_end_device(MPT_ADAPTER *ioc, struct
> mptsas_phyinfo *phy_info)
> mptsas_port_delete(ioc, phy_info->port_details);
> }
>
> -struct mptsas_phyinfo *
> +static struct mptsas_phyinfo *
> mptsas_refreshing_device_handles(MPT_ADAPTER *ioc,
> struct mptsas_devinfo *sas_device)
> {
> @@ -3650,7 +3650,7 @@ mptsas_send_expander_event(struct fw_event_work
> *fw_event)
> * @handle:
> *
> */
> -struct mptsas_portinfo *
> +static struct mptsas_portinfo *
> mptsas_expander_add(MPT_ADAPTER *ioc, u16 handle)
> {
> struct mptsas_portinfo buffer, *port_info;
> @@ -5323,7 +5323,7 @@ mptsas_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
> return error;
> }
>
> -void
> +static void
> mptsas_shutdown(struct pci_dev *pdev)
> {
> MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
> --
> 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 2/3] drivers: message: Mark function mptscsih_quiesce_raid() as static in mptspi.c
On Fri, Dec 13, 2013 at 11:36:54AM +0530, Rashika Kheria wrote:
> This patch marks the function mptscsih_quiesce_raid() as static in
> fusion/mptspi.c because it is not used outside this function.
>
> Thus, it also eliminates the following warning in fusion/mptspi.c:
> drivers/message/fusion/mptspi.c:624:1: warning: no previous prototype for
> ‘mptscsih_quiesce_raid’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/message/fusion/mptspi.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
> index 5653e50..ed8de0a 100644
> --- a/drivers/message/fusion/mptspi.c
> +++ b/drivers/message/fusion/mptspi.c
> @@ -620,7 +620,7 @@ static void mptspi_read_parameters(struct scsi_target
> *starget)
> spi_width(starget) = (nego & MPI_SCSIDEVPAGE0_NP_WIDE) ? 1 : 0;
> }
>
> -int
> +static int
> mptscsih_quiesce_raid(MPT_SCSI_HOST *hd, int quiesce, u8 channel, u8 id)
> {
> MPT_ADAPTER *ioc = hd->ioc;
> --
> 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: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)
On Thu, 12 Dec 2013 22:16:55 +0100 John Stultz wrote > On 12/12/2013 11:39 AM, John Stultz wrote: > > On 12/05/2013 03:51 AM, Brecht Machiels wrote: > >> On Mon, 02 Dec 2013 22:19:58 +0100, Borislav Petkov wrote: > >> > >>> On Mon, Dec 02, 2013 at 12:47:17PM -0800, John Stultz wrote: > Ok, sorry about this. I've been hoping we'd get some better insight > into what's actually happening on these strange BIOSes where disabling > the irq seems to cause it to scream (powering the system back on when > its shutdown), in the hopes of having a proper workaround. But despite > Borislav's efforts, he didn't seem to be able to root cause the issue. > >>> Right, this bug is too nasty - you could generate good random numbers > >>> just from how the hardware behaves. :) And I've been trying to make > >>> sense of what happens but I failed, as you know. :( > >>> > >>> I consider it a huge waste of time and efforts having to deal with such > >>> b0rked hardware instead of throwing it out of the window into the poring > >>> rain while it is still powered. > >>> > Borislav, could you double check this patch still works on your > hardware as well? > >>> Well, we have the patch in SLES11: > >>> > >>> http://kernel.opensuse.org/cgit/kernel/commit/?h=SLE11- > >> SP3&id=835398eb94dca7d55acd1a2628372e602ae3252a > >>> and it passed testing. > >>> > >>> From what I see below, your version is equivalent to the one above with > >>> the logic reversed so it should work. I'll still try to get that > >>> affected box and run your version on it but it'll take a while. > >> Hello John and Boris, > >> > >> Thank you for your quick response. And no need for an apology, I can > >> understand your frustration with the way some hardware behaves. > >> > >> I ran with John's patch for a couple of days, and it seems to work. > >> Curiously, the laptop did spontaneously boot the first time that I shut > >> it down with the patched kernel. I have no conclusive explanation for > >> this, but I have noticed that a manual power down is necessary after > >> booting with an unpatched kernel. Simply rebooting with a patched kernel > >> is not enough to stop the spontaneous boots. As far as I can remember, I > >> went directly from my custom kernel (with the v2 patch reverted) to a > >> kernel with your patch applied, so I'm not 100% convinced everything is > >> all right. I should say that I did experience some spontaneous boots when > >> > >> running only Windows XP in the past, so there may be occasions where > >> drivers might not be able to help at all. > > Yea. It seems almost like the RTC_AIE bit is inverted in the hardware or > > something. > > > >> Thankfully, after other shutdowns/hibernates (about 6 in total) the > >> laptop never booted spontaneously. > >> > >> As for killing alarm functionality on the affected systems, I did some > >> quick tests. With the patched kernel, I can set the RTC alarm by echoing > >> to /sys/class/rtc/rtc0/wakealarm, and the machine will boot at the > >> specified time. I have also tried setting the RTC alarm, and then > >> disabling it again by echoing '0' to /sys/class/rtc/rtc0/wakealarm. While > >> > >> this sets the alrm_time to five minutes in the future, alarm_IRQ is set > >> to 'no' and the machine does *not* boot spontaneously 5 minutes after > >> shutting down. So, all seems well, as far as I can see. Unfortunately, I > >> don't know enough about the RTC driver to draw any conclusions from this. > > Ok. Sounds like the patch works fairly well then. I'll go ahead and > > queue it for 3.14 and -stable. > Brecht: Is it OK if I add to the patch: > Tested-by: Brecht Machiels Sure. Thanks, Brecht -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] at91: drivers for 3.14 #1
Arnd, Olof, Kevin, This is a "drivers" series that adds Device Tree support to Atmel crypto drivers (AES/[T]DES/SHA). As the DT part of this addition is in at91-3.14-dt I thought it would be simpler to take this series through arm-soc. I asked and got Herbert's blessing. The Device Tree entries documented in these patches are very simple and only declare the reg/irq values and the link to DMA. Thanks, best regards, The following changes since commit b46e837d8ef1f3c777bbf9513e2cdb5d87d6c374: ARM: at91/dt: remove old clk material (2013-12-02 15:31:29 +0100) are available in the git repository at: git://github.com/at91linux/linux-at91.git tags/at91-drivers for you to fetch changes up to 1ca5b7d95315c42cf0b78d33cd316e404a9f137c: crypto: atmel-sha - add sha information to the log (2013-12-12 18:39:36 +0100) AT91 crypto drivers DT support: - add DT to sha/des/aes existing drivers - add DMA DT - all documentation added to crypto/atmel-crypto.txt file Nicolas Ferre (4): crypto: atmel-aes - add support for Device Tree crypto: atmel-tdes - add support for Device Tree crypto: atmel-sha - add support for Device Tree crypto: atmel-sha - add sha information to the log .../devicetree/bindings/crypto/atmel-crypto.txt| 68 ++ drivers/crypto/atmel-aes.c | 143 ++--- drivers/crypto/atmel-sha.c | 103 +++ drivers/crypto/atmel-tdes.c| 143 ++--- 4 files changed, 334 insertions(+), 123 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/atmel-crypto.txt -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-3.10.y] ip6tnl: fix use after free of fb_tnl_dev
The upstream commit bb8140947a24 ("ip6tnl: allow to use rtnl ops on fb tunnel")
(backported into linux-3.10.y) left a bug which was fixed upstream by commit
1e9f3d6f1c40 ("ip6tnl: fix use after free of fb_tnl_dev").
The problem is a bit different in linux-3.10.y, because there is no x-netns
support (upstream commit 0bd8762824e7 ("ip6tnl: add x-netns support")).
When ip6_tunnel.ko is unloaded, FB device is deleted by rtnl_link_unregister()
and then we try to delete it again in ip6_tnl_destroy_tunnels().
This patch removes the second deletion.
Reported-by: Steven Rostedt
Suggested-by: Steven Rostedt
Signed-off-by: Nicolas Dichtel
---
net/ipv6/ip6_tunnel.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0516ebbea80b..209bb4d6e188 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1711,8 +1711,6 @@ static void __net_exit ip6_tnl_destroy_tunnels(struct
ip6_tnl_net *ip6n)
}
}
- t = rtnl_dereference(ip6n->tnls_wc[0]);
- unregister_netdevice_queue(t->dev, &list);
unregister_netdevice_many(&list);
}
--
1.8.4.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: kernel BUG in munlock_vma_pages_range
On 12/13/2013 09:49 AM, Bob Liu wrote:
> On 12/13/2013 05:05 AM, Sasha Levin wrote:
>> On 12/12/2013 07:41 AM, Vlastimil Babka wrote:
>>> On 12/12/2013 06:03 AM, Bob Liu wrote:
On 12/12/2013 11:16 AM, Sasha Levin wrote:
> On 12/11/2013 05:59 PM, Vlastimil Babka wrote:
>> On 12/09/2013 09:26 PM, Sasha Levin wrote:
>>> On 12/09/2013 12:12 PM, Vlastimil Babka wrote:
On 12/09/2013 06:05 PM, Sasha Levin wrote:
> On 12/09/2013 04:34 AM, Vlastimil Babka wrote:
>> Hello, I will look at it, thanks.
>> Do you have specific reproduction instructions?
>
> Not really, the fuzzer hit it once and I've been unable to trigger
> it again. Looking at
> the piece of code involved it might have had something to do with
> hugetlbfs, so I'll crank
> up testing on that part.
Thanks. Do you have trinity log and the .config file? I'm currently
unable to even boot linux-next
with my config/setup due to a GPF.
Looking at code I wouldn't expect that it could encounter a tail
page, without first encountering a
head page and skipping the whole huge page. At least in THP case, as
TLB pages should be split when
a vma is split. As for hugetlbfs, it should be skipped for
mlock/munlock operations completely. One
of these assumptions is probably failing here...
>>>
>>> If it helps, I've added a dump_page() in case we hit a tail page
>>> there and got:
>>>
>>> [ 980.172299] page:ea003e5e8040 count:0 mapcount:1
>>> mapping: (null) index:0
>>> x0
>>> [ 980.173412] page flags: 0x2f80008000(tail)
>>>
>>> I can also add anything else in there to get other debug output if
>>> you think of something else useful.
>>
>> Please try the following. Thanks in advance.
>
> [ 428.499889] page:ea003e5c0040 count:0 mapcount:4
> mapping: (null) index:0x0
> [ 428.499889] page flags: 0x2f80008000(tail)
> [ 428.499889] start=140117131923456 pfn=16347137
> orig_start=140117130543104 page_increm
> =1 vm_start=140117130543104 vm_end=140117134688256 vm_flags=135266419
> [ 428.499889] first_page pfn=16347136
> [ 428.499889] page:ea003e5c count:204 mapcount:44
> mapping:880fb5c466c1 inde
> x:0x7f6f8fe00
> [ 428.499889] page flags:
> 0x2f80084068(uptodate|lru|active|head|swapbacked)
From this print, it looks like the page is still a huge page.
One situation I guess is a huge page which isn't PageMlocked and passed
to munlock_vma_page(). I'm not sure whether this will happen.
>>>
>>> Yes that's quite likely the case. It's not illegal to happen I would say.
>>>
Please take a try this patch.
>>>
>>> I've made a simpler version that does away with the ugly page_mask
>>> thing completely.
>>> Please try that as well. Thanks.
>>>
>>> Also when working on this I think I found another potential but much
>>> rare problem
>>> when munlock_vma_page races with a THP split. That would however
>>> manifest such that
>>> part of the former tail pages would stay PageMlocked. But that still
>>> needs more thought.
>>> The bug at hand should however be fixed by this patch.
>>
>> Yup, this patch seems to fix the issue previously reported.
>>
>> However, I'll piggyback another thing that popped up now that the vm
>> could run for a while which
>> also seems to be caused by the original patch. It looks like a pretty
>> straightforward deadlock, but
Sigh, put one down, patch it around... :)
> Looks like put_page() in __munlock_pagevec() need to get the
> zone->lru_lock which is already held when entering __munlock_pagevec().
I've come to the same conclusion, however:
> How about fix like this?
That unfortunately removes most of the purpose of this function which was to
avoid repeated locking.
Please try this patch.
---8<---
From: Vlastimil Babka
Date: Fri, 13 Dec 2013 10:03:25 +0100
Subject: [PATCH] Deadlock in __munlock_pagevec candidate fix
---
mm/mlock.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index a34dfdc..c97273e 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -281,10 +281,12 @@ static void __munlock_pagevec(struct pagevec *pvec,
struct zone *zone)
{
int i;
int nr = pagevec_count(pvec);
- int delta_munlocked = -nr;
+ int delta_munlocked;
struct pagevec pvec_putback;
int pgrescued = 0;
+ pagevec_init(&pvec_putback, 0);
+
/* Phase 1: page isolation */
spin_lock_irq(&zone->lru_lock);
for (i = 0; i < nr; i++) {
@@ -313,16 +315,22 @@ skip_munlock:
/*
* We won't be munlocking this page in the next phase
* but we still need to release the follow_page_mask()
-
Re: [PATCH 1/9] Known exploit detection
On 12/12/2013 10:13 PM, Kees Cook wrote: On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote: On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote: The idea is simple -- since different kernel versions are vulnerable to different root exploits, hackers most likely try multiple exploits before they actually succeed. I like it. I like how lightweight it is, and I like that it can be trivially compiled out. My concerns would be: - how do we avoid bikeshedding about which exploits are "serious enough" to trigger a report? Well, I've already suggested that only bugs that potentially lead to privilege escalation/intrusion (local and remote) would be candidates. This probably includes any kind of buffer overflow or "wild write" bug. Clearly, a bug should also be present over a complete release cycle before it's worth annotating. A bug introduced in -rc1 and fixed in -rc5 is NOT a candidate. - who will keep adding these triggers going forward? I'm more than happy to assist with adding future triggers, but I don't want to be the only person doing it. :) Thanks! Without making any promises, I am fairly sure that my team has an interest in adding and maintaining triggers. Based on some of the later comments in this thread, I think it might be a good idea to keep a separate git tree for the triggers for a while. You are of course welcome to contribute in any case. Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] net: phy: Ethernet PHY powerdown optimization
This is v2 of the ethernet PHY power optimization patches to reduce power consumption of network PHYs with link that are either unused or the corresponding netdev is down. Compared to the last version, this patch set drops a patch to disable unused PHYs after late initcall, as it is not compatible with a modular mdio bus [1]. I'll investigate different ways to have a modular mdio bus driver get notified when driver loading is done. Again, a branch with v2 applied to v3.13-rc2 can also be found at https://github.com/shesselba/linux-dove.git topic/ethphy-power-v2 [1] http://www.spinics.net/lists/arm-kernel/msg293028.html Sebastian Hesselbarth (5): net: mv643xx_eth: properly start/stop phy device net: phy: marvell: provide genphy suspend/resume net: phy: provide phy_resume/phy_suspend helpers net: phy: resume/suspend PHYs on attach/detach net: phy: suspend phydev when going to HALTED drivers/net/ethernet/marvell/mv643xx_eth.c |4 +++- drivers/net/phy/marvell.c | 22 ++ drivers/net/phy/phy.c |6 +- drivers/net/phy/phy_device.c | 27 +++ include/linux/phy.h|2 ++ 5 files changed, 59 insertions(+), 2 deletions(-) --- Cc: David Miller Cc: Florian Fainelli Cc: Mugunthan V N Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] net: mv643xx_eth: properly start/stop phy device
When using phydev, it should be phy_start/phy_stop'ed properly. This driver doesn't do that, so add the corresponding calls to port_start/ stop respectively. Signed-off-by: Sebastian Hesselbarth Acked-by: Mugunthan V N Reviewed-by: Florian Fainelli --- Cc: David Miller Cc: Florian Fainelli Cc: Mugunthan V N Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethernet/marvell/mv643xx_eth.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index 61088a6..3aa706f 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c @@ -2098,6 +2098,7 @@ static void port_start(struct mv643xx_eth_private *mp) mv643xx_eth_get_settings(mp->dev, &cmd); phy_reset(mp); mv643xx_eth_set_settings(mp->dev, &cmd); + phy_start(mp->phy); } /* @@ -2293,7 +2294,8 @@ static int mv643xx_eth_stop(struct net_device *dev) del_timer_sync(&mp->rx_oom); netif_carrier_off(dev); - + if (mp->phy) + phy_stop(mp->phy); free_irq(dev->irq, dev); port_reset(mp); -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] net: phy: suspend phydev when going to HALTED
When phydev is going to HALTED state, we can try to suspend it to safe more power. phy_suspend helper will check if PHY can be suspended, so just call it when entering HALTED state. Signed-off-by: Sebastian Hesselbarth Acked-by: Mugunthan V N Reviewed-by: Florian Fainelli --- Cc: David Miller Cc: Florian Fainelli Cc: Mugunthan V N Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/net/phy/phy.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 36c6994..6429942 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -740,7 +740,7 @@ void phy_state_machine(struct work_struct *work) struct delayed_work *dwork = to_delayed_work(work); struct phy_device *phydev = container_of(dwork, struct phy_device, state_queue); - int needs_aneg = 0; + int needs_aneg = 0, do_suspend = 0; int err = 0; mutex_lock(&phydev->lock); @@ -855,6 +855,7 @@ void phy_state_machine(struct work_struct *work) phydev->link = 0; netif_carrier_off(phydev->attached_dev); phydev->adjust_link(phydev->attached_dev); + do_suspend = 1; } break; case PHY_RESUMING: @@ -913,6 +914,9 @@ void phy_state_machine(struct work_struct *work) if (needs_aneg) err = phy_start_aneg(phydev); + if (do_suspend) + phy_suspend(phydev); + if (err < 0) phy_error(phydev); -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] net: phy: provide phy_resume/phy_suspend helpers
This adds helper functions to resume and suspend a given phy_device
by calling the corresponding driver callbacks if available.
Signed-off-by: Sebastian Hesselbarth
Acked-by: Mugunthan V N
Reviewed-by: Florian Fainelli
---
Cc: David Miller
Cc: Florian Fainelli
Cc: Mugunthan V N
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/phy/phy_device.c | 24
include/linux/phy.h |2 ++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d6447b3..6f0e9e4 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -625,6 +625,30 @@ void phy_detach(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_detach);
+int phy_suspend(struct phy_device *phydev)
+{
+ struct phy_driver *phydrv = to_phy_driver(phydev->dev.driver);
+ struct ethtool_wolinfo wol;
+
+ /* If the device has WOL enabled, we cannot suspend the PHY */
+ wol.cmd = ETHTOOL_GWOL;
+ phy_ethtool_get_wol(phydev, &wol);
+ if (wol.wolopts)
+ return -EBUSY;
+
+ if (phydrv->suspend)
+ return phydrv->suspend(phydev);
+ return 0;
+}
+
+int phy_resume(struct phy_device *phydev)
+{
+ struct phy_driver *phydrv = to_phy_driver(phydev->dev.driver);
+
+ if (phydrv->resume)
+ return phydrv->resume(phydev);
+ return 0;
+}
/* Generic PHY support and helper functions */
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..1070ee3 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -538,6 +538,8 @@ struct phy_device *phy_device_create(struct mii_bus *bus,
int addr, int phy_id,
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
int phy_device_register(struct phy_device *phy);
int phy_init_hw(struct phy_device *phydev);
+int phy_suspend(struct phy_device *phydev);
+int phy_resume(struct phy_device *phydev);
struct phy_device * phy_attach(struct net_device *dev,
const char *bus_id, phy_interface_t interface);
struct phy_device *phy_find_first(struct mii_bus *bus);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] Known exploit detection
On 12/13/2013 12:50 AM, Ryan Mallon wrote: On 13/12/13 08:13, Kees Cook wrote: On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote: On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote: The idea is simple -- since different kernel versions are vulnerable to different root exploits, hackers most likely try multiple exploits before they actually succeed. The _exploit() notifications could also be used to spam the syslogs. Although they are individually ratelimited, if there are enough _exploit() markers in the kernel then an annoying person can cycle through them all to generate large amounts of useless syslog. They are rate limited collectively, not individually, so this should not be an issue. Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] net: phy: marvell: provide genphy suspend/resume
Marvell PHYs support generic PHY suspend/resume, so provide those
callbacks to all marvell specific drivers.
Signed-off-by: Sebastian Hesselbarth
Acked-by: Mugunthan V N
Reviewed-by: Florian Fainelli
---
Cc: David Miller
Cc: Florian Fainelli
Cc: Mugunthan V N
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/phy/marvell.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 2e3c778e..bd37e45 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -894,6 +894,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -907,6 +909,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -920,6 +924,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -933,6 +939,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = {.owner = THIS_MODULE,},
},
{
@@ -946,6 +954,8 @@ static struct phy_driver marvell_drivers[] = {
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.did_interrupt = &m88e1121_did_interrupt,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -961,6 +971,8 @@ static struct phy_driver marvell_drivers[] = {
.did_interrupt = &m88e1121_did_interrupt,
.get_wol = &m88e1318_get_wol,
.set_wol = &m88e1318_set_wol,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -974,6 +986,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -987,6 +1001,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -1000,6 +1016,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -1013,6 +1031,8 @@ static struct phy_driver marvell_drivers[] = {
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
{
@@ -1026,6 +1046,8 @@ static struct phy_driver marvell_drivers[] = {
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.did_interrupt = &m88e1121_did_interrupt,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
.driver = { .owner = THIS_MODULE },
},
};
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
[PATCH v2 4/5] net: phy: resume/suspend PHYs on attach/detach
This ensures PHYs are resumed on attach and suspended on detach.
Signed-off-by: Sebastian Hesselbarth
Acked-by: Mugunthan V N
Reviewed-by: Florian Fainelli
---
Cc: David Miller
Cc: Florian Fainelli
Cc: Mugunthan V N
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/phy/phy_device.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 6f0e9e4..3903f44 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -570,6 +570,8 @@ static int phy_attach_direct(struct net_device *dev, struct
phy_device *phydev,
if (err)
phy_detach(phydev);
+ phy_resume(phydev);
+
return err;
}
@@ -615,6 +617,7 @@ void phy_detach(struct phy_device *phydev)
{
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
+ phy_suspend(phydev);
/* If the device had no specific driver before (i.e. - it
* was using the generic driver), we unbind the device
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
José Miguel Gonçalves wrote: > > On 27-09-2013 15:17, Linus Walleij wrote: > > On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves > > wrote: > > > >> Some GPIO line limits are incorrectly set which, for instance, > >> does not allow nRTS1 (GPH11) configuration on a S3C2416 chip. > >> > >> Signed-off-by: José Miguel Gonçalves > >> --- > >> arch/arm/mach-s3c24xx/include/mach/gpio.h | 10 +- > > OK but g! > > > > What needs to happen to the s3c24xx is to get rid of this file. > > > > - Define ARCH_NR_GPIOS in arch/arm/Kconfig entry > >ARCH_NR_GPIO like everyone else > > > > - Get rid of the config symbol NEED_MACH_GPIO_H > > > > - Move this file down into arch/arm/mach-s3c24xx/s3c24xx-gpio.h > >or whatever and make it local... > > > > I will try to do this myself if noone else helps out, so I'd like to > > carry this patch in the GPIO tree provided I can get an ACK from > > the S3C24xx maintainer. Tomasz, is that you or Kukjin? > > > > (BTW the above maybe goes for S3c64xx as well .. and S5P > > oh well I will get to it.) > > > > Was this patch forgotten? > Hi Jose, Sorry about missing your patch. It's my fault :( and as you know, at this moment the file will be removed by Linus' patch... Anyway, let me look at the Samsung patches closely ;) Thanks, 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/
Re: [PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
Am Freitag, 13. Dezember 2013, 10:24:59 schrieb kg...@kernel.org: > José Miguel Gonçalves wrote: > > On 27-09-2013 15:17, Linus Walleij wrote: > > > On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves > > > > > > wrote: > > >> Some GPIO line limits are incorrectly set which, for instance, > > >> does not allow nRTS1 (GPH11) configuration on a S3C2416 chip. > > >> > > >> Signed-off-by: José Miguel Gonçalves > > >> --- > > >> > > >> arch/arm/mach-s3c24xx/include/mach/gpio.h | 10 +- > > > > > > OK but g! > > > > > > What needs to happen to the s3c24xx is to get rid of this file. > > > > > > - Define ARCH_NR_GPIOS in arch/arm/Kconfig entry > > > > > >ARCH_NR_GPIO like everyone else > > > > > > - Get rid of the config symbol NEED_MACH_GPIO_H > > > > > > - Move this file down into arch/arm/mach-s3c24xx/s3c24xx-gpio.h > > > > > >or whatever and make it local... > > > > > > I will try to do this myself if noone else helps out, so I'd like to > > > carry this patch in the GPIO tree provided I can get an ACK from > > > the S3C24xx maintainer. Tomasz, is that you or Kukjin? > > > > > > (BTW the above maybe goes for S3c64xx as well .. and S5P > > > oh well I will get to it.) > > > > Was this patch forgotten? > > Hi Jose, > > Sorry about missing your patch. It's my fault :( and as you know, at this > moment the file will be removed by Linus' patch... > > Anyway, let me look at the Samsung patches closely ;) The comment that is changed in the header is removed by Linus' patch, but the change to the gpio driver is still relevant for the time being I'd think. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv6 1/4] pwm: Add Freescale FTM PWM driver support
> > + struct fsl_pwm_chip *fpc;
> > +
> > + fpc = to_fsl_chip(chip);
> > +
> > + period_cycles = fsl_rate_to_cycles(fpc, period_ns);
> > + if (period_cycles > 0x) {
> > + dev_err(chip->dev, "required PWM period cycles(%lu) overflow "
> > + "16-bits counter!\n", period_cycles);
> > + return -EINVAL;
> > + }
> > +
> > + duty_cycles = fsl_rate_to_cycles(fpc, duty_ns);
> > + if (duty_cycles >= 0x) {
> > + dev_err(chip->dev, "required PWM duty cycles(%lu) overflow "
> > + "16-bits counter!\n", duty_cycles);
> > + return -EINVAL;
> > + }
>
> I'm not sure the error messages are all that useful. A -EINVAL error code
> should make it pretty clear what the problem is.
>
Yes, it is.
But for the pwm leds, there hasn't any check about the return values, if
there is something wrong, we cannot get any information about this.
So I think this error messages are useful for this case.
--
Xiubo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] Known exploit detection
On Fri, 13 Dec 2013, Theodore Ts'o wrote: > I am at least partially sympathetic to the concerns which Greg has > raised, though. At the very least the exploit() tags should also have > a date stamp, so it we can automatically scan for exploit tags whose > time has come and gone. At least this is a non-issue, if you supply the CVE string (as Vegard's patchset proposed), as it implicitly contains a year it has been issued (which seems like sufficient granularity for this kind of tracking). > I'm also worried about false positives getting triggered due to > userspace bugs, corrupted file systems, or other random hardare > failures. This could be a support headache for distributions, and > possibly for other kernel support organizations as well. Given that > attack authors will probably adapt their explots to only try them on > known RHEL/SLES kernels that have the bug, it wouldn't surprise me if > enterprise distro's such as Red Hat and SuSE will very likely simply > not turn on the config option. I of course can't really now talk officially about what we would do, as no internal discussion about this has happened, but my gut feeling is that we will be turning it off, exactly due to the reasons outlined above. We want to maintain sanity of our support engineers and not let them be drowned in figuring out these being false positives and then going through the pain of explaining this to the customer. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl: at91: implement at91_pinconf_dbg_show
On Sat, Dec 7, 2013 at 2:08 PM, Alexandre Belloni wrote: > This allows to get the pin configuration by using debugfs. On my system: > # cat /sys/kernel/debug/pinctrl/pinctrl.3/pinconf-pins > > Signed-off-by: Alexandre Belloni Patch applied with Nicolas' ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
On Fri, Dec 13, 2013 at 10:24 AM, wrote: > José Miguel Gonçalves wrote: (..) >> Was this patch forgotten? >> > Hi Jose, > > Sorry about missing your patch. It's my fault :( and as you know, at this > moment the file will be removed by Linus' patch... Oh I can certainly rebase the patch onto my tree if I just get an ACK for it... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
Hi Heiko, On 13-12-2013 08:42, Heiko Stübner wrote: But Jose, you should really really look into moving to devicetree with your platform, if you're not already doing so. Pinctrl support is already present, and I'm hopefull the move to the common clock framework I posted a few days ago might make it too. I'm currently maintaining a deployed equipment whose development started some time ago, so I still need to use a 3.9 kernel with the traditional hardware initialization. But, of course, for any new developments based on the same S3C24XX platform, I will look in migrating to the device tree. Best regards, José Gonçalves -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] HID: hid-multitouch: add support for SiS panel in LG 23ET83V
On Thu, 12 Dec 2013, Greg KH wrote: > > 3.12.5-stable patch > > > > > > From: Emanuel Krenz > > > > Add support for SiS multitouch panel in the touch monitor LG 23ET83V. > > > > Signed-off-by: Emanuel Krenz > > Signed-off-by: Forest Bond > > Signed-off-by: Jiri Kosina > > Signed-off-by: Greg Kroah-Hartman > > I signed off on this? What is the git commit id of the patch in Linus's > tree? I haven't either, and I don't think I have ever seen this patch (it's definitely neither in Linus' nor my tree). Emanuel, what is going on here, please? Is it that you authored this patch yourself, and would like to have it included in Linus' tree (only then it can go to -stable)? If so, please remove all Signoffs of people who haven't provided it to you, and resubmit it to maintainer (./scripts/get_maintainer.pl will tell you who are proper recepients of this patch). Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv7 0/4] Add Freescale FTM PWM driver.
This patch series is the Freescale FTM PWM implementation. And there are 8 channels most supported by the FTM PWM. This implementation is only compatible with device tree definition. This patch series is based on linux-next and has been tested on Vybrid VF610 Tower board using device tree. Changes in v7: - Add big-endian mode support. - Add FTM mutex lock. - Add period time check with the current running pwm(s). - Recode the counter clock source selecting. - Sort some header files alphabetically, etc. Changes in v6: - Remove "fsl,pwm-counter-clk". Changes in v5: - Remove active/idle pinctrl stuff. Changes in v4: - Check for the result and return an error for devm_kzalloc(). - Move pinmux setting from the SoC file to the board specific file. - Revise the written mistake of 'ret |= FTMSC_CLKEXT;' --> 'reg |= FTMSC_CLKEXT;'. Changes in v3: - Remove "availabe" field. - Remove "fsl,pwm-avaliable-chs" property. - ... Changes in v2: - Remove PWM CPWM/EPWM feature and sysfs. - Remove some redundant code. - Revise some code for more readable. - Remove "fsl,pwm-clk-ps", "fsl,pwm-number", "fsl,pwm-channels",etc. - Add "fsl,pwm-avaliable-chs", "fsl,pwm-counter-clk", etc. - Support 8 channels default in dtsi file. - Add counter clock source selection. - Rename some function name, macro name, etc. - Use PWM's and OF's existing function interfaces. - Split clk_unprepare_enable to clk_unprepare and clk_enable,etc. - ... Added in v1: - Add Freescale FTM PWM driver support. - Add Freescale FTM PWM node for VF610. - Enable Enables FTM PWM device for Vybrid VF610 TOWER. - Add device tree bindings for Freescale. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv7 4/4] Documentation: Add device tree bindings for Freescale FTM PWM.
This adds the binding documentation for Freescale FlexTimer Module
(FTM) PWM driver under Documentation/devicetree/bindings/pwm/.
Signed-off-by: Xiubo Li
Reviewed-by: Sascha Hauer
Acked-by: Kumar Gala
---
.../devicetree/bindings/pwm/pwm-fsl-ftm.txt| 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
new file mode 100644
index 000..6ae6377
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
@@ -0,0 +1,38 @@
+Freescale FlexTimer Module (FTM) PWM controller
+
+Required properties:
+- compatible: Should be "fsl,vf610-ftm-pwm".
+- reg: Physical base address and length of the controller's registers
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+ the cells format.
+- clock-names : Should include the following module clock source entries:
+"ftm_sys" (module clock, also can be used as counter clock),
+"ftm_ext" (external counter clock),
+"ftm_fix" (fixed counter clock),
+"ftm_cnt_clk_en" (external and fixed counter clock enable/disable).
+- clocks : Must contain a clock specifier for each entry in clock-names,
+ See clock/clock-bindings.txt for details of the property values.
+- pinctrl-names: Must contain a "default" entry.
+- pinctrl-NNN: One property must exist for each entry in pinctrl-names.
+ See pinctrl/pinctrl-bindings.txt for details of the property values.
+- big-endian: If this property is absent, the little endian mode will be in
+ use as default, or the big endian mode will be in use for all the device
+ registers.
+
+
+Example:
+
+pwm0: pwm@40038000 {
+ compatible = "fsl,vf610-ftm-pwm";
+ reg = <0x40038000 0x1000>;
+ #pwm-cells = <3>;
+ clock-names = "ftm_sys", "ftm_ext",
+ "ftm_fix", "ftm_cnt_clk_en";
+ clocks = <&clks VF610_CLK_FTM0>,
+ <&clks VF610_CLK_FTM0_EXT_SEL>,
+ <&clks VF610_CLK_FTM0_FIX_SEL>,
+ <&clks VF610_CLK_FTM0_EXT_FIX_EN>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_1>;
+ big-endian;
+};
--
1.8.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/
[PATCHv7 2/4] ARM: dts: Add Freescale FTM PWM node for VF610.
This adds devicetree node for VF610, and there are 8 channels
supported.
Signed-off-by: Xiubo Li
Reviewed-by: Sascha Hauer
---
arch/arm/boot/dts/vf610.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 67d929c..9bea0b2 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -140,6 +140,19 @@
clock-names = "pit";
};
+ pwm0: pwm@40038000 {
+ compatible = "fsl,vf610-ftm-pwm";
+ #pwm-cells = <3>;
+ reg = <0x40038000 0x1000>;
+ clock-names = "ftm_sys", "ftm_ext",
+ "ftm_fix", "ftm_cnt_clk_en";
+ clocks = <&clks VF610_CLK_FTM0>,
+ <&clks VF610_CLK_FTM0_EXT_SEL>,
+ <&clks VF610_CLK_FTM0_FIX_SEL>,
+ <&clks VF610_CLK_FTM0_EXT_FIX_EN>;
+ status = "disabled";
+ };
+
wdog@4003e000 {
compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
reg = <0x4003e000 0x1000>;
--
1.8.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/
[PATCHv7 1/4] pwm: Add Freescale FTM PWM driver support
The FTM PWM device can be found on Vybrid VF610 Tower and
Layerscape LS-1 SoCs.
Signed-off-by: Xiubo Li
Signed-off-by: Alison Wang
Signed-off-by: Jingchang Lu
Reviewed-by: Sascha Hauer
---
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-fsl-ftm.c | 508 ++
3 files changed, 519 insertions(+)
create mode 100644 drivers/pwm/pwm-fsl-ftm.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index eece329..c77c571 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -71,6 +71,16 @@ config PWM_EP93XX
To compile this driver as a module, choose M here: the module
will be called pwm-ep93xx.
+config PWM_FSL_FTM
+ tristate "Freescale FlexTimer Module (FTM) PWM support"
+ depends on OF
+ help
+ Generic FTM PWM framework driver for Freescale VF610 and
+ Layerscape LS-1 SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-fsl-ftm.
+
config PWM_IMX
tristate "i.MX PWM support"
depends on ARCH_MXC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 8b754e4..9029a12 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
+obj-$(CONFIG_PWM_FSL_FTM) += pwm-fsl-ftm.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
new file mode 100644
index 000..22715e7
--- /dev/null
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -0,0 +1,508 @@
+/*
+ * Freescale FlexTimer Module (FTM) PWM Driver
+ *
+ * Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FTM_SC 0x00
+#define FTM_SC_CLK_MASK0x3
+#define FTM_SC_CLK_SHIFT 3
+#define FTM_SC_CLK(c) (((c) + 1) << FTM_SC_CLK_SHIFT)
+#define FTM_SC_PS_MASK 0x7
+#define FTM_SC_PS_SHIFT0
+
+#define FTM_CNT0x04
+#define FTM_MOD0x08
+
+#define FTM_CSC_BASE 0x0C
+#define FTM_CSC_MSBBIT(5)
+#define FTM_CSC_MSABIT(4)
+#define FTM_CSC_ELSB BIT(3)
+#define FTM_CSC_ELSA BIT(2)
+#define FTM_CSC(_channel) (FTM_CSC_BASE + ((_channel) * 8))
+
+#define FTM_CV_BASE0x10
+#define FTM_CV(_channel) (FTM_CV_BASE + ((_channel) * 8))
+
+#define FTM_CNTIN 0x4C
+#define FTM_STATUS 0x50
+
+#define FTM_MODE 0x54
+#define FTM_MODE_FTMEN BIT(0)
+#define FTM_MODE_INIT BIT(2)
+#define FTM_MODE_PWMSYNC BIT(3)
+
+#define FTM_SYNC 0x58
+#define FTM_OUTINIT0x5C
+#define FTM_OUTMASK0x60
+#define FTM_COMBINE0x64
+#define FTM_DEADTIME 0x68
+#define FTM_EXTTRIG0x6C
+#define FTM_POL0x70
+#define FTM_FMS0x74
+#define FTM_FILTER 0x78
+#define FTM_FLTCTRL0x7C
+#define FTM_QDCTRL 0x80
+#define FTM_CONF 0x84
+#define FTM_FLTPOL 0x88
+#define FTM_SYNCONF0x8C
+#define FTM_INVCTRL0x90
+#define FTM_SWOCTRL0x94
+#define FTM_PWMLOAD0x98
+
+enum {
+ FSL_PWM_CLK_SYS,
+ FSL_PWM_CLK_FIX,
+ FSL_PWM_CLK_EXT,
+ FSL_PWM_CLK_MAX,
+};
+
+struct fsl_pwm_chip {
+ struct pwm_chip chip;
+
+ struct mutex lock;
+
+ struct clk *sys_clk;
+ struct clk *counter_clk;
+ struct clk *counter_clk_en;
+ unsigned int counter_clk_select;
+ unsigned int counter_clk_enable;
+ unsigned int clk_ps;
+
+ void __iomem *base;
+
+ int period_ns;
+ int big_endian;
+};
+
+static inline u32 fsl_pwm_readl(struct fsl_pwm_chip *fpc,
+ const void __iomem *addr)
+{
+ u32 val;
+
+ val = __raw_readl(addr);
+
+ if (likely(fpc->big_endian))
+ val = be32_to_cpu(val);
+ else
+ val = le32_to_cpu(val);
+ rmb();
+
+ return val;
+}
+
+static inline void fsl_pwm_writel(struct fsl_pwm_chip *fpc,
+ u32 val, void __iomem *addr)
+{
+ wmb();
+ if (likely(fpc->big_endian))
+ val = cpu_to_be32(val);
+ else
+ val = cpu_to_le32(val);
+
+ __raw_writel(val, addr);
+}
+
+static inline struct fsl_pwm_chip *to_fsl_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct fsl_pwm_chip, chip);
+}
+
+static int fsl_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct fsl_pwm_chip *
[PATCHv7 3/4] ARM: dts: Enables FTM PWM device for Vybrid VF610 TOWER board.
Signed-off-by: Xiubo Li
Reviewed-by: Sascha Hauer
---
arch/arm/boot/dts/vf610-twr.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 82d352f..3130f85 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -83,6 +83,12 @@
status = "okay";
};
+&pwm0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_1>;
+ status = "okay";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1_1>;
--
1.8.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: why does index in truncate_inode_pages_range() grows so much ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/11/2013 09:26 PM, Jan Kara wrote: > Thanks! So this works more or less as expected - trinity issued a > read at absurdly high offset so we created pagecache page a that > offset and tried to read data into it. That failed. We left the > page in the pagecache where it was for reclaim to reclaim it when > free pages are needed. Everything works as designed except we could > possibly argue that it's not the most efficient way to use > pages... > > Patch 'vfs: fix a bug when we do some dio reads with append dio > writes' (http://www.spinics.net/lists/linux-fsdevel/msg70899.html) > should actually change the situation and we won't unnecessarily > cache these pages. > confirmed - applied to latest git tree of Linus I helps. - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKq2NQACgkQxOrN3gB26U5LJgD/f0jU9NXrgVw7UthV613FrCMX zUTRpvoNy8oKgpyiejwA/R2oVVwYXhKTcs0XHstQ9w3mjBcjp9t2ub2GAWa8hDnb =KAh4 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] AX88179_178A: Add FLAG_HW_IPALIGN to determine whether reserving NET_IP_ALIGN bytes for an SKB.
From: Freddy Xin
The AX88179_178A has a hardware feature that it can insert a
2-bytes pseudo header in front of each received frame by setting
the AX_RX_CTL_IPE bit. This feature is used to let the IP header
be aligned on a doubleword-aligned address, so the rx_submit() of
usbnet.c needn't reserve NET_IP_ALIGN bytes for an SKB in the case.
This patch adds a flag of driver_info "FLAG_HW_IPALIGN" which is
used in rx_submit() of usbnet.c to determine whether reserving
NET_IP_ALIGN bytes for an SKB.
Signed-off-by: Freddy Xin
---
drivers/net/usb/ax88179_178a.c | 8
drivers/net/usb/usbnet.c | 5 -
include/linux/usb/usbnet.h | 3 +++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 8e8d0fc..04a2cc9 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1374,7 +1374,7 @@ static const struct driver_info ax88179_info = {
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_HW_IPALIGN,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1387,7 +1387,7 @@ static const struct driver_info ax88178a_info = {
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_HW_IPALIGN,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1400,7 +1400,7 @@ static const struct driver_info sitecom_info = {
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_HW_IPALIGN,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
@@ -1413,7 +1413,7 @@ static const struct driver_info samsung_info = {
.link_reset = ax88179_link_reset,
.reset = ax88179_reset,
.stop = ax88179_stop,
- .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_HW_IPALIGN,
.rx_fixup = ax88179_rx_fixup,
.tx_fixup = ax88179_tx_fixup,
};
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 8494bb5..8a618b8 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -473,7 +473,10 @@ static int rx_submit (struct usbnet *dev, struct urb *urb,
gfp_t flags)
return -ENOLINK;
}
- skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
+ if (dev->driver_info->flags & FLAG_HW_IPALIGN)
+ skb = __netdev_alloc_skb(dev->net, size, flags);
+ else
+ skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
if (!skb) {
netif_dbg(dev, rx_err, dev->net, "no rx skb\n");
usbnet_defer_kevent (dev, EVENT_RX_MEMORY);
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index e303eef..e4855cf 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -116,6 +116,9 @@ struct driver_info {
#define FLAG_MULTI_PACKET 0x2000
#define FLAG_RX_ASSEMBLE 0x4000 /* rx packets may span >1 frames */
#define FLAG_NOARP 0x8000 /* device can't do ARP */
+#define FLAG_HW_IPALIGN0x1 /* hardware adds headers to let
the
+* IP header align on a dword-aligned
+* address */
/* init device ... can sleep, or cause probe() failure */
int (*bind)(struct usbnet *, struct usb_interface *);
--
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 v5 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
On Thursday 12 December 2013 11:48 PM, Felipe Balbi wrote: > Hi, > > On Thu, Dec 12, 2013 at 08:26:02AM -0500, Matt Porter wrote: >> This adds a pair of APIs that allows the generic PHY subsystem to >> provide information on the PHY bus width. The PHY provider driver may >> use phy_set_bus_width() to set the bus width that the PHY supports. >> The controller driver may then use phy_get_bus_width() to fetch the >> PHY bus width in order to properly configure the controller. >> >> Signed-off-by: Matt Porter > > Kishon, I need your Acked-by here, if you're ok with the change. here it goes.. Acked-by: Kishon Vijay Abraham I > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: reinsert ARCH_MULTI_V4 Kconfig option
On Fri, Dec 13, 2013 at 09:09:09AM +0100, Jonas Jensen wrote: > CPU_FA526 lacks thumb state support and doesn't get along with some > of the options enabled by ARCH_MULTI_V4T. > > More specifically it doesn't get along with CPU_ARM920T: > > CPU_ABRT_EV4T > CPU_CACHE_V4WT > CPU_COPY_V4WB > CPU_TLB_V4WBI Having these selected doesn't change how the kernel is compiled or how the kernel uses the code which these provide. These mainly control which files are built. They also control indirectly how the code is called - but the ultimate decision is made by the CPU which is detected and the block in __fa526_proc_info. So, having these symbols enabled (provided the right ones for FA526 are also enabled) makes no difference. So I don't buy your explanation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI
Hi Olof, On Thu, Dec 12, 2013 at 10:05 AM, Olof Johansson wrote: > Hi, > > A couple of small comments below. Thanks for your feedback! > On Thu, Dec 12, 2013 at 08:56:26AM +0900, Magnus Damm wrote: >> From: Magnus Damm >> >> Add Kconfig entries for CMT, MTU2, TMU and STI to >> drivers/clocksource/Kconfig. This will allow us to >> get rid of duplicated entires in architecture code >> such as arch/sh and arch/arm/mach-shmobile. >> >> Signed-off-by: Magnus Damm >> --- >> >> drivers/clocksource/Kconfig | 44 >> +++ >> 1 file changed, 44 insertions(+) >> >> --- 0001/drivers/clocksource/Kconfig >> +++ work/drivers/clocksource/Kconfig 2013-12-12 08:41:55.0 +0900 >> @@ -134,3 +134,47 @@ config VF_PIT_TIMER >> bool >> help >> Support for Period Interrupt Timer on Freescale Vybrid Family SoCs. >> + >> +config SYS_SUPPORTS_CMT >> +bool >> + >> +config SYS_SUPPORTS_TMU >> +bool >> + >> +config SYS_SUPPORTS_MTU2 >> +bool >> + >> +config SYS_SUPPORTS_STI >> +bool > > Maybe a prefix to avoid namespace collissions here? Sure, that is fine with me. I based the ones above on already existing ones used by SH but I don't mind reworking those. How about SYS_SUPPORTS_CLKSRC_xxx? >> +config SH_TIMER_CMT >> + bool "Renesas CMT timer driver" if COMPILE_TEST >> + default SYS_SUPPORTS_CMT > > It might be useful to have an explicit depends on ARCH_SH || ARCH_SHMOBILE > || COMPILE_TEST on these, just to make it easier for someone reading > the code later on. I have any strong feelings one way or the other about that myself, but I got the impression that John Stultz preferred to not allow manual selection at all, and my compromise here is to allow it only when COMPILE_TEST is selected. Would you be ok to keep it as-is for now? If needed then we can add an incremental patch later to enable more flexible selection. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] perf script: Improve srcline display for BTS
Change the order of the output to put the srcline last.
e.g.
perf record -e branches:u -c 1 -d ls
perf script -fip,sym,symoff,dso,addr,srcline
old format:
4028fc main+0x2c (/bin/ls)
/build/buildd/coreutils-8.20/src/ls.c:1269 => 40d8a0
set_program_name+0x0 (/bin/ls)
new format:
4028fc main+0x2c (/bin/ls) => 40d8a0 set_program_name+0x0
(/bin/ls)
/build/buildd/coreutils-8.20/src/ls.c:1269
Signed-off-by: Adrian Hunter
---
tools/perf/builtin-script.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 7a571fb..8997b69 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -428,15 +428,22 @@ static void print_sample_bts(union perf_event *event,
struct addr_location *al)
{
struct perf_event_attr *attr = &evsel->attr;
+ bool print_srcline_last = false;
/* print branch_from information */
if (PRINT_FIELD(IP)) {
- if (!symbol_conf.use_callchain)
- printf(" ");
- else
+ unsigned int print_opts = output[attr->type].print_ip_opts;
+
+ if (symbol_conf.use_callchain && sample->callchain) {
printf("\n");
- perf_evsel__print_ip(evsel, sample, machine, al,
-output[attr->type].print_ip_opts,
+ } else {
+ printf(" ");
+ if (print_opts & PRINT_IP_OPT_SRCLINE) {
+ print_srcline_last = true;
+ print_opts &= ~PRINT_IP_OPT_SRCLINE;
+ }
+ }
+ perf_evsel__print_ip(evsel, sample, machine, al, print_opts,
PERF_MAX_STACK_DEPTH);
}
@@ -448,6 +455,9 @@ static void print_sample_bts(union perf_event *event,
!output[attr->type].user_set))
print_sample_addr(event, sample, machine, thread, attr);
+ if (print_srcline_last)
+ map__fprintf_srcline(al->map, al->addr, "\n ", stdout);
+
printf("\n");
}
-- 1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] ARM: dts: sun7i: cubietruck: Enable the GMAC
On 12/7/2013 2:57 AM, Florian Fainelli wrote:
2013/12/6 Chen-Yu Tsai :
On Sat, Dec 7, 2013 at 5:09 AM, Florian Fainelli wrote:
2013/12/6 Chen-Yu Tsai :
The CubieTruck uses the GMAC with an RGMII phy.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 8a1009d..af212a2 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -33,6 +33,14 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii>;
+ snps,phy-addr = <1>;
What is this snps,phy-addr property? Why is not a standard device tree
node for an Ethernet PHY node used?
This property is implemented by stmmac and documented in the DT
bindings. stmmac has not been updated to use Ethernet PHY nodes.
This driver property should be removed and deprecated since there is
an ePAPR standardized Ethernet PHY node. What I am worried here is the
loss of information, the standard Ethernet DT node allows to specify
much more information (clause, maximum speed, compatible string
etc...).
yes Florian you are right and I have already started updating the
driver. I do not sure that I'll be able to send all the patches soon
but for sure I can re-base them.
Removing this property will not affect the function of the driver.
The driver probes its MDIO bus and selects the lowest available
address if not specified.
So if this is just giving the driver a hint on where to probe for a
PHY on the MDIO bus, then let's drop it and use the standard DT node
no?
+ phy-mode = "rgmii";
Especially since you use the relatively standard "phy-mode" property here?
Used as specified in stmmac DT bindings.
That one is kind of okay because of_get_phy_mode() knows about it,
even though ePAPR states this should be "phy-connection-type", so I am
okay with keeping that one because current practice and helpers are
here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/6] ARM: pinctrl: Add Broadcom Capri pinctrl driver
On Thu, Dec 12, 2013 at 09:54:50PM +0100, Linus Walleij wrote: > This is a reimplementation of regmap for MMIO. > See drivers/base/regmap/regmap-mmio.c > Notice how regmap_update_bits() is used throughout the > kernel. > If you want to do this, use regmap. Or if this is very performance sensitive (which I'd not expect for pinctrl) there's a helper in review at the minute which just uses a spinlock. signature.asc Description: Digital signature
Re: [PATCH 1/9] Known exploit detection
On 12/13/2013 06:09 AM, James Morris wrote: On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote: On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote: On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote: > - who will keep adding these triggers going forward? I think we'd need to have someone commit to maintaining this long term before seriously considering it as part of mainline. Over time it will become increasingly useless if new triggers aren't added. Based on your input, we (the Ksplice team) will probably set up a public git repository where we maintain these patches on top of the latest released kernel. What happens when code is refactored, who refactors the triggers? also.. - Who will test the existing triggers are doing the right thing when related code changes. I don't think refactoring or maintenance is a huge issue. The triggers are mostly one-liners in the error path of a specific input validation check. I haven't maintained these patches for a very long time, but at least nothing came up in the six months of development that I've had these patches sitting for. I'd say the person doing the refactoring should also take care to maintain the trigger, but if it just doesn't make sense anymore, it can also just be taken out. In any case, maintaining a public git repository alongside mainline will give us some experience with overcoming refactoring/code changes. And: - how do you determine an "expoit attempt" from "userspace program doing something stupid" / "corrupted filesytem mounted"? Right, and if there are enough false positives, it'll end up being quite useless. I suspect this kind of thing is better done in userspace anti-malware scanning. I really don't like this, it means that our normal error handling for userspace data will suddenly all have CVE entries on them over time. How is that helpful to anyone? Think ahead in 10-20 years, what is the code paths going to look like then? Horrible... Agree. This could make an interesting research project outside of the kernel. It doesn't belong in mainline without at least first being proven in the field and also properly maintained long term, if at all. I already suggested a 5-year expiry date for any triggers we add. It's easy to retire them based on the CVE (or other) identifier that includes the year (possibly combined with git blame and friends). I also think the set of triggers should be limited to serious bugs that could lead to privilege escalation. There are not THAT many of them. There are probably fewer than 20 every year, which would cap the total number of triggers at 100 in the whole kernel at any given time. The point is NOT to add triggers in every error path in the kernel, of course not. Triggers should only be added where there's a real possibility of the bug actually being exploited. I thought about requiring a proof-of-concept exploit code to be provided with each trigger as well, but that could be too hard to be useful in practice, since actually exploiting any given potential privilege escalation bug could require a lot of ingenuity. Thanks, Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/9] Known exploit detection
Am 13.12.2013 02:42, schrieb Greg Kroah-Hartman: On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote: On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote: > - who will keep adding these triggers going forward? also.. - Who will test the existing triggers are doing the right thing when related code changes. And: - how do you determine an "expoit attempt" from "userspace program doing something stupid" / "corrupted filesytem mounted"? And what makes a bug marked as exploit more serious than the all the other bugs? I assume there exists many, many more serious (fixed or not) bugs than just those which found there way into the CVE database. And I think most bugs are getting fixed without such a number and often even those for which CVEs do exist, the CVE is unknown to the dev(s). So people might be think they are safe if they call some tool which tests for existing CVEs which are marked as such inside the kernel, which just isn't the reality. And, as already mentioned, those CVE marks might block refactoring, as devs might become careful to remove such a CVE marker when code changed. I've never seen a comment inside the kernel sources which does point to a CVE, so I assume there already does exists some agreement about not doing so. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: hid-multitouch: add support for SiS panel in LG 23ET83V
Am 13.12.2013 10:39, schrieb Jiri Kosina: On Thu, 12 Dec 2013, Greg KH wrote: 3.12.5-stable patch From: Emanuel Krenz Add support for SiS multitouch panel in the touch monitor LG 23ET83V. Signed-off-by: Emanuel Krenz Signed-off-by: Forest Bond Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman I signed off on this? What is the git commit id of the patch in Linus's tree? I haven't either, and I don't think I have ever seen this patch (it's definitely neither in Linus' nor my tree). Emanuel, what is going on here, please? Is it that you authored this patch yourself, and would like to have it included in Linus' tree (only then it can go to -stable)? If so, please remove all Signoffs of people who haven't provided it to you, and resubmit it to maintainer (./scripts/get_maintainer.pl will tell you who are proper recepients of this patch). Thanks, Hello, I'm sorry, guys. I thought I have to add those "Signed-off-by" lines to mention, where I got the ideas for this patch from. It was actually this patch: https://lkml.org/lkml/2013/12/2/647 That was obviously a mistake, please forgive me. As I mentioned, this was my first submitted patch, I was just so excited that I might help developing. Thank you, Jiri, for telling me, to remove this "Signed-off-by" lines and resubmit the patch after using get_maintainer.pl. Now I actually got your name as the maintainer of HID CORE LAYER. So i'll send it to you again without those lines, i hope it's correct now. Thanks, guys, for all your work and help! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] AX88179_178A: Add FLAG_HW_IPALIGN to determine whether reserving NET_IP_ALIGN bytes for an SKB.
> From: fre...@asix.com.tw
...
> - skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
> + if (dev->driver_info->flags & FLAG_HW_IPALIGN)
> + skb = __netdev_alloc_skb(dev->net, size, flags);
> + else
> + skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
Given the definition:
static inline struct sk_buff *__netdev_alloc_skb_ip_align(struct net_device
*dev,
unsigned int length, gfp_t gfp)
{
struct sk_buff *skb = __netdev_alloc_skb(dev, length + NET_IP_ALIGN,
gfp);
if (NET_IP_ALIGN && skb)
skb_reserve(skb, NET_IP_ALIGN);
return skb;
}
It really ought to be possible to code that without an extra conditional.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/10] net: stmmac: sunxi platfrom extensions for GMAC in Allwinner A20 SoC's
On Thu, Dec 12, 2013 at 06:31:43PM +0800, Chen-Yu Tsai wrote: > Hi, > > On Thu, Dec 12, 2013 at 5:04 PM, Maxime Ripard > wrote: > > Hi, > > > > On Wed, Dec 11, 2013 at 02:45:08PM +, srinivas kandagatla wrote: > >> >>> 1. .tx_coe > >> >>>This is not exported in the DT bindings. > >> >>>Looking at stmmac code, not setting this seems to disable all > >> >>>checksum offloading. > >> >> > >> >> Why cant this go via DT as well? > >> > > >> > If you and Giuseppe are OK with this, why not? > >> Am Ok with it. > > > > Please note that I'm opposed to this until someone explain why putting > > it in the DT is relevant (and not just convenient). > > Checksum offloading is an optional feature[1], implemented starting > from version 3.20a. It is not tied to a specific IP version. As such, > using a "snps,dwmac-" compatible isn't a good fit here. No, but we're not in such case. Since we have a compatible of our own, we can derive it from that. Putting a property in the DT would only be redundant. > stmmac does auto-detection for optional features on MAC version > 3.50a. > This is what Srinivas was referring to. > > Unfortunately, our MAC is < 3.50a. No auto-detection. We could add a > "snps,dwmac-tx-coe" compatible for this, or the seperate DT property. > > The other way would be to pass the flags in the initial .data with the > SoC specific compatible. Other SoCs with the same feature won't be > able to reuse the same compatible though. Which is already pretty much the case, since we have to deal with Allwinner specific code and features. A new compatible is cheap to maintain, a new property is not. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 3/8] regmap: Add support for using regmap over ssbi
On Thu, Dec 12, 2013 at 03:13:01PM -0800, Stephen Boyd wrote: > > bulk_read() should decay to individual reads if there isn't a block > > operaton and it's not like the hardware actually supports bulk reads > > anyway. > So regmap_bulk_read() should work if I don't have a map->bus? To make it > work with reg_read/write I had to do this. I'm not sure how to make > bulk_write work. Yes, I'd expect the operation to work. Your changes below are mostly fine (we should add an additional check for values that aren't integer numbers of bytes, I can add that) - can you send as a signed off patch please and I'll apply? signature.asc Description: Digital signature
Re: [PATCH V10 01/14] xen/pvh: Support ParaVirtualized Hardware extensions.
On 13/12/13 02:10, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor
>
> PVH allows PV linux guest to utilize hardware extended capabilities, such
> as running MMU updates in a HVM container.
>
> This patch allows it to be configured and enabled. Also, basic header file
> changes to add new subcalls to physmap hypercall.
>
> Lastly, mfn_to_local_pfn must return mfn for paging mode translate
> (since we let the hypervisor - or CPU - do them for us).
[...]
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -168,6 +168,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
> static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
> {
> unsigned long pfn = mfn_to_pfn(mfn);
> +
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return mfn;
This does the mfn_to_pfn() call first and then ignores the result.
> if (get_phys_to_machine(pfn) != mfn)
> return -1; /* force !pfn_valid() */
> return pfn;
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 1a3c765..4d890c3 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -51,3 +51,13 @@ config XEN_DEBUG_FS
> Enable statistics output and various tuning options in debugfs.
> Enabling this option may incur a significant performance overhead.
>
> +config XEN_X86_PVH
> + bool "Support for running as a PVH guest (EXPERIMENTAL)"
> + depends on X86_64 && XEN && EXPERIMENTAL
Drop EXPERIMENTAL here (not in the follow up patch).
> + default n
default y or don't provide this as a user selectable choice.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..1a6bca1 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
> #include
> #include
>
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "|writable_descriptor_tables" \
> + "|auto_translated_physmap" \
> + "|supervisor_mode_kernel" \
> + "|hvm_callback_vector"
> +#else
> +#define FEATURES_PVH /* Not supported */
> +#endif
> +
> __INIT
> ENTRY(startup_xen)
> cld
> @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
> #endif
> ELFNOTE(Xen, XEN_ELFNOTE_ENTRY, _ASM_PTR startup_xen)
> ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> - ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz
> "!writable_page_tables|pae_pgdir_above_4gb")
> + ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz
> "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
> ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "yes")
> ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
> ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
Not clear how this can be part of the first patch. A guest with only
this patch cannot actually work in PVH mode, right?
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 2ecfe4f..a122164 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -175,7 +175,10 @@ struct xen_add_to_physmap {
> uint16_tsize;
>
> /* Source mapping space. */
> -unsigned int space;
> +uint16_t space;
> +domid_t foreign_domid; /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x8000
What's this change? It doesn't match the hypervisor.
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -291,6 +291,16 @@ struct physdev_dbgp_op {
> } u;
> };
>
> +#define PHYSDEVOP_map_iomem30
> +struct physdev_map_iomem {
> +/* IN */
> +uint64_t first_gfn;
> +uint64_t first_mfn;
> +uint32_t nr_mfns;
> +uint32_t add_mapping; /* 1 == add mapping; 0 == unmap */
> +
> +};
> +
Not provided by the hypervisor.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: hid-multitouch: add support for SiS panel in LG 23ET83V
From: Emanuel Krenz
Add support for SiS multitouch panel in the touch monitor LG 23ET83V.
---
I bought an LG 23ET83V multitouch monitor, whose idProduct=1030 wasn't
yet included in the hid-multitouch driver.
So I wrote following patch to include the ID number 1030 and patched the
latest stable 3.12.5 kernel. The SiS touchpanel in my monitor works for
me now.
This is my first submitted patch by now, hope it's okay.
--
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1823,6 +1823,7 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_SAMSUNG,
USB_DEVICE_ID_SAMSUNG_WIRELESS_KBD_MOUSE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SIS2_TOUCH,
USB_DEVICE_ID_SIS9200_TOUCH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SIS2_TOUCH,
USB_DEVICE_ID_SIS817_TOUCH) },
+{ HID_USB_DEVICE(USB_VENDOR_ID_SIS2_TOUCH,
USB_DEVICE_ID_SIS1030_TOUCH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SKYCABLE,
USB_DEVICE_ID_SKYCABLE_WIRELESS_PRESENTER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_BUZZ_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_WIRELESS_BUZZ_CONTROLLER) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -755,6 +755,7 @@
#define USB_VENDOR_ID_SIS2_TOUCH0x0457
#define USB_DEVICE_ID_SIS9200_TOUCH0x9200
#define USB_DEVICE_ID_SIS817_TOUCH0x0817
+#define USB_DEVICE_ID_SIS1030_TOUCH0x1030
#define USB_VENDOR_ID_SKYCABLE0x1223
#defineUSB_DEVICE_ID_SKYCABLE_WIRELESS_PRESENTER0x3F07
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1306,6 +1306,9 @@ static const struct hid_device_id mt_dev
{ .driver_data = MT_CLS_DEFAULT,
HID_USB_DEVICE(USB_VENDOR_ID_SIS2_TOUCH,
USB_DEVICE_ID_SIS817_TOUCH) },
+{ .driver_data = MT_CLS_DEFAULT,
+HID_USB_DEVICE(USB_VENDOR_ID_SIS2_TOUCH,
+USB_DEVICE_ID_SIS1030_TOUCH) },
/* Stantum panels */
{ .driver_data = MT_CLS_CONFIDENCE,
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -86,6 +86,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SIGMATEL, USB_DEVICE_ID_SIGMATEL_STMP3780,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_SIS2_TOUCH, USB_DEVICE_ID_SIS9200_TOUCH,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_SIS2_TOUCH, USB_DEVICE_ID_SIS817_TOUCH,
HID_QUIRK_NOGET },
+{ USB_VENDOR_ID_SIS2_TOUCH, USB_DEVICE_ID_SIS1030_TOUCH,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_SUN, USB_DEVICE_ID_RARITAN_KVM_DONGLE,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_SYMBOL, USB_DEVICE_ID_SYMBOL_SCANNER_1,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_SYMBOL, USB_DEVICE_ID_SYMBOL_SCANNER_2,
HID_QUIRK_NOGET },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] regulator: act8865: add PMIC(Power Management IC) driver
On Fri, Dec 13, 2013 at 07:10:36AM +, Yang, Wenyou wrote: > > Please keep this and the Makefile sorted. > Only this one confuses me, > How can I sort it? By i2c interface, by regulator type: voltage or current? > Where is act8865 should be? By name - look at the existing entries. signature.asc Description: Digital signature
[PATCH 1/1] usb: musb: ux500_dma: fix potential NULL dereference error
static checker warning: "drivers/usb/musb/ux500_dma.c:335
ux500_dma_controller_start()
error: potential NULL dereference 'param_array'."
Reported-by: Dan Carpenter
Signed-off-by: Lee Jones
---
drivers/usb/musb/ux500_dma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 3700e97..9aad00f 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -336,7 +336,9 @@ static int ux500_dma_controller_start(struct
ux500_dma_controller *controller)
data ?
data->dma_filter :
NULL,
-
param_array[ch_num]);
+ param_array ?
+ param_array[ch_num]
:
+ NULL);
if (!ux500_channel->dma_chan) {
ERR("Dma pipe allocation error dir=%d ch=%d\n",
--
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 00/15] cleanups and optimizations
On 12/12/2013 16:08, Peter Zijlstra wrote: > This series contains the preempt_enable_no_resched() cleanups that include > spin_lock_bh() optimizations and local_clock() optimizations. I'm trying to test this on tip/master. Patch 3 fails to apply on kenrel/softirq.c Thanks, Eliezer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 / writeback invoking soft lockup.
On Fri, Dec 13, 2013 at 02:14:07AM -0500, Dave Jones wrote:
> I can hit this pretty reliably on one of my slower test machines.
> (8gb ram, 1 slow sata disk)
>
> the machine is pretty responsive, and recovers after a while.
> anything we can do to shut it up ?
Actually, I think this indicates a problem.
> BUG: soft lockup - CPU#2 stuck for 22s! [kworker/u8:2:8479]
...
> Call Trace:
> [] lru_add_drain+0x1c/0x39
> [] __pagevec_release+0x10/0x26
> [] write_cache_pages+0x2f9/0x486
That code in write_cache_pages():
1907 while (!done && (index <= end)) {
1908 int i;
1909
1910 nr_pages = pagevec_lookup_tag(&pvec, mapping, &index, tag,
1911 min(end - index, (pgoff_t)PAGEVEC_SIZE-1) +
1)
1912 if (nr_pages == 0)
1913 break;
1914
1915 for (i = 0; i < nr_pages; i++) {
1916 struct page *page = pvec.pages[i];
2001 }
2002 pagevec_release(&pvec);
2003 cond_resched();
2004 }
So after all the pages in a pagevec are processed, we release the
CPU before we grab the next pagevec. This softlockup implies we
have been processing this pagevec for 22s. That tells me the code
is actually stuck spinning on something, not that this is a false
positive. i.e. it should not take 22s to process 14 pages.
[ Yes, I know XFS can process more than that ->writepage, but it's
still only a millisecond of work if it doesn't block on anything.
And it can't be blocking, otherwise we wouldn't be firing the
softlockup warning. ]
The page cache LRU code is a maze of twisty per-cpu passages that go
deep into the mm subsystem and memcg code - I'm not really sure what
all that code is doing, so you'll probably have to ask someone who
knows about that code.
All I can say is that there doesn't look to be any obvious signs
that this is a XFS or writeback problem fom the stack trace, and
without more information or a reproducable test case I'm not going
to be able to understand the cause.
Is the problem reproducable, or is it just a one-off?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.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: [PATCH] ARM: reinsert ARCH_MULTI_V4 Kconfig option
On 13 December 2013 10:56, Russell King - ARM Linux wrote: > So, having these symbols enabled (provided the right ones for FA526 are > also enabled) makes no difference. So I don't buy your explanation. The explanation is indeed false, CPU_FA526 and CPU_ARM920T get along just fine. That's not where the problem is. Panic goes away after removing CONFIG_ARM_THUMB=y. I assume this is what should happen on processors without thumb? Thanks, Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [uml-devel] why does index in truncate_inode_pages_range() grows so much ?
On Fri, Dec 13, 2013 at 10:52 AM, Toralf Förster wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 12/11/2013 09:26 PM, Jan Kara wrote: >> Thanks! So this works more or less as expected - trinity issued a >> read at absurdly high offset so we created pagecache page a that >> offset and tried to read data into it. That failed. We left the >> page in the pagecache where it was for reclaim to reclaim it when >> free pages are needed. Everything works as designed except we could >> possibly argue that it's not the most efficient way to use >> pages... >> >> Patch 'vfs: fix a bug when we do some dio reads with append dio >> writes' (http://www.spinics.net/lists/linux-fsdevel/msg70899.html) >> should actually change the situation and we won't unnecessarily >> cache these pages. >> > confirmed - applied to latest git tree of Linus I helps. Good to know! :-) -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V10 02/14] xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
On 13/12/13 02:10, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor
>
> Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> as PVH only needs to send down gdtaddr and gdtsz in the
> vcpu_guest_context structure..
>
> For interrupts, PVH uses native_irq_ops so we can skip most of the
> PV ones. In the future we can support the pirq_eoi_map..
> Also VCPU hotplug is currently not available for PVH.
>
> For events (and IRQs) we follow what PVHVM does - so use callback
> vector. Lastly, for XenBus we use the same logic that is used in
> the PVHVM case.
[...]
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -145,7 +145,16 @@ struct vcpu_guest_context {
> struct cpu_user_regs user_regs; /* User-level CPU registers
> */
> struct trap_info trap_ctxt[256];/* Virtual IDT
> */
> unsigned long ldt_base, ldt_ents; /* LDT (linear address, # ents)
> */
> -unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents)
> */
> +union {
> + struct {
> + /* PV: GDT (machine frames, # ents).*/
> + unsigned long gdt_frames[16], gdt_ents;
> + } pv;
> + struct {
> + /* PVH: GDTR addr and size */
> + unsigned long gdtaddr, gdtsz;
> + } pvh;
> +} u;
Doesn't match the hypervisor.
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -800,8 +800,10 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned
> long mfn)
> unsigned topidx, mididx, idx;
>
> /* don't track P2M changes in autotranslate guests */
> - if (unlikely(xen_feature(XENFEAT_auto_translated_physmap)))
> + if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> + BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
> return true;
> + }
Isn't this undoing a recent change that removed this BUG_ON()?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [HANG 3.13-rc3] blk-mq/virtio: mkfs.ext4 hangs in blk_mq_wait_for_tags
On Fri, Dec 13, 2013 at 09:57:48AM +0800, Ming Lei wrote: > On Tue, Dec 10, 2013 at 6:39 AM, Dave Chinner wrote: > > Hi Jens, > > > > Another day, another blkmq/virtio problem. Running mkfs.ext4 on a > > sparse 100TB VM file image, it hangs hard while writing superblock > > information: > > > > $ tests/fsmark-50-test-ext4.sh > > mke2fs 1.43-WIP (20-Jun-2013) > > Filesystem label= > > OS type: Linux > > Block size=4096 (log=2) > > Fragment size=4096 (log=2) > > Stride=0 blocks, Stripe width=0 blocks > > 1677721600 inodes, 26843545600 blocks > > 1342177280 blocks (5.00%) reserved for the super user > > First data block=0 > > 819200 block groups > > 32768 blocks per group, 32768 fragments per group > > 2048 inodes per group > > Superblock backups stored on blocks: > > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, > > 2654208, > > 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, > > 10240, 214990848, 51200, 550731776, 644972544, 1934917632, > > 256000, 3855122432, 5804752896, 128, 17414258688 > > > > Allocating group tables: done > > Writing inode tables: done > > Creating journal (32768 blocks): done > > Writing superblocks and filesystem accounting information: > > > > It writes a few superblocks, then hangs. Immediately after it stops > > updating that last line, I see this: > > > > root@test4:~# echo w > /proc/sysrq-trigger > > It might be helpful to do below and post the result before the sysrq-trigger: > > cat/sys/class/block/vda/mq/0/tags I would, but for some reason I can't reproduce it now. I'm running a slightly more recent kernel than a few days ago, and it isn't hanging now Cheers, Dave. -- Dave Chinner da...@fromorbit.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: [PATCH v5 5/9] usb: gadget: s3c-hsotg: use generic phy_init()/phy_exit() support
On Thursday 12 December 2013 06:56 PM, Matt Porter wrote: > If a generic phy is present, call phy_init()/phy_exit(). This supports > generic phys that must be soft reset before power on. > > Signed-off-by: Matt Porter Acked-by: Kishon Vijay Abraham I > --- > drivers/usb/gadget/s3c-hsotg.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c > index 7c5d8bd..e9683c2 100644 > --- a/drivers/usb/gadget/s3c-hsotg.c > +++ b/drivers/usb/gadget/s3c-hsotg.c > @@ -3621,6 +3621,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev) > goto err_supplies; > } > > + if (hsotg->phy) > + phy_init(hsotg->phy); > + > /* usb phy enable */ > s3c_hsotg_phy_enable(hsotg); > > @@ -3714,6 +3717,8 @@ static int s3c_hsotg_remove(struct platform_device > *pdev) > } > > s3c_hsotg_phy_disable(hsotg); > + if (hsotg->phy) > + phy_exit(hsotg->phy); > clk_disable_unprepare(hsotg->clk); > > return 0; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V10 05/14] xen/pvh: balloon and grant changes.
On 13/12/13 02:10, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor
>
> For balloon changes we skip setting of local P2M as it's updated
> in Xen. For grant, the shared grant frame is the PFN and not MFN,
> hence its mapped via the same code path as HVM.
It's difficult to see how these are related. Please split.
I also think Stefano recently submitted an equivalent fix for the
balloon driver.
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1056,14 +1056,20 @@ static void gnttab_unmap_frames_v2(void)
> static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> {
> struct gnttab_setup_table setup;
> + unsigned long start_gpfn;
> xen_pfn_t *frames;
> unsigned int nr_gframes = end_idx + 1;
> int rc;
>
> - if (xen_hvm_domain()) {
> + if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
> struct xen_add_to_physmap xatp;
> unsigned int i = end_idx;
> rc = 0;
> +
> + if (xen_hvm_domain())
> + start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> + else
> + start_gpfn = virt_to_pfn(gnttab_shared.addr);
Not really clear why PVH diverges from HVM here.
> @@ -1135,7 +1141,7 @@ static void gnttab_request_version(void)
> int rc;
> struct gnttab_set_version gsv;
>
> - if (xen_hvm_domain())
> + if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
> gsv.version = 1;
> else
> gsv.version = 2;
Why is PVH limited to version 1?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 6/9] usb: gadget: s3c-hsotg: get phy bus width from phy subsystem
On Thursday 12 December 2013 06:56 PM, Matt Porter wrote:
> Adds support for querying the phy bus width from the generic phy
> subsystem. Configure UTMI bus width in GUSBCFG based on this value.
>
> Signed-off-by: Matt Porter
Acked-by: Kishon Vijay Abraham I
> ---
> drivers/usb/gadget/s3c-hsotg.c | 14 +-
> drivers/usb/gadget/s3c-hsotg.h | 1 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
> index e9683c2..168aaa9 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -144,6 +144,7 @@ struct s3c_hsotg_ep {
> * @regs: The memory area mapped for accessing registers.
> * @irq: The IRQ number we are using
> * @supplies: Definition of USB power supplies
> + * @phyif: PHY interface width
> * @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
> * @num_of_eps: Number of available EPs (excluding EP0)
> * @debug_root: root directrory for debugfs.
> @@ -171,6 +172,7 @@ struct s3c_hsotg {
>
> struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
>
> + u32 phyif;
> unsigned intdedicated_fifos:1;
> unsigned char num_of_eps;
>
> @@ -2276,7 +2278,7 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
>*/
>
> /* set the PLL on, remove the HNP/SRP and set the PHY */
> - writel(GUSBCFG_PHYIf16 | GUSBCFG_TOutCal(7) |
> + writel(hsotg->phyif | GUSBCFG_TOutCal(7) |
> (0x5 << 10), hsotg->regs + GUSBCFG);
>
> s3c_hsotg_init_fifo(hsotg);
> @@ -3621,6 +3623,16 @@ static int s3c_hsotg_probe(struct platform_device
> *pdev)
> goto err_supplies;
> }
>
> + /* Set default UTMI width */
> + hsotg->phyif = GUSBCFG_PHYIf16;
> +
> + /*
> + * If using the generic PHY framework, check if the PHY bus
> + * width is 8-bit and set the phyif appropriately.
> + */
> + if (hsotg->phy && (phy_get_bus_width(phy) == 8))
> + hsotg->phyif = GUSBCFG_PHYIf8;
> +
> if (hsotg->phy)
> phy_init(hsotg->phy);
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.h b/drivers/usb/gadget/s3c-hsotg.h
> index d650b12..85f549f 100644
> --- a/drivers/usb/gadget/s3c-hsotg.h
> +++ b/drivers/usb/gadget/s3c-hsotg.h
> @@ -55,6 +55,7 @@
> #define GUSBCFG_HNPCap (1 << 9)
> #define GUSBCFG_SRPCap (1 << 8)
> #define GUSBCFG_PHYIf16 (1 << 3)
> +#define GUSBCFG_PHYIf8 (0 << 3)
> #define GUSBCFG_TOutCal_MASK (0x7 << 0)
> #define GUSBCFG_TOutCal_SHIFT(0)
> #define GUSBCFG_TOutCal_LIMIT(0x7)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V10 08/14] x86/xen: Use __pa_symbol instead of __pa on C visible symbols
On 13/12/13 02:10, Konrad Rzeszutek Wilk wrote: > From: Alexander Duyck > > This change updates a few of the functions to use __pa_symbol when > translating C visible symbols instead of __pa. By using __pa_symbol we are > able to drop a few extra lines of code as don't have to test to see if the > virtual pointer is a part of the kernel text or just standard virtual memory. Why is this part of the PVH series? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] misc: Reserve minor for VFIO
> VFIO currently allocates it's own dynamic chardev range, reserving the > first minor for the control part of the interface (/dev/vfio/vfio) and > the remainder for VFIO groups (/dev/vfio/$GROUP). This works, but it > doesn't support auto loading. For instance when libvirt checks for > VFIO support it looks for /dev/vfio/vfio, which currently doesn't > exist unless the vfio module is loaded. By converting the control > device to a misc driver and reserving a static minor, we can enable > auto loading. Looks sensible to me. I'm not sure if Lanana even really goes anywhere any more however. Linus kept complaining about static device numbering despite the fact it's still essential for a few odd cases like this. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/9] Known exploit detection
> Totally true, but there's a million way to DoS a local machine. At > least this way shows who's doing it. It's the DoSes that don't include > attribution that I worry about. :) So long as they compile out to nothingness for all the systems where this stuff is useless (ie most of them because they are embedded or phones etc) I don't see a big problem. Note however if you trip one of those in any code with the console lock held and your log goes to the consoles due to printk level or similar you'll probably hang the box. There are some other lock sequences that are going to do that too, so it can't be placed arbitarily but will need the locking assumptions for each non-obvious one documented clearly. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: increase max page/OOB size to support 16K pagesize NAND
> On Fri, Dec 13, 2013 at 05:03:49AM +, Caizhiyong wrote:
> > From: Cai Zhiyong
> > Date: Fri, 13 Dec 2013 12:52:46 +0800
> > Subject: [PATCH] mtd: increase max page/OOB size to support 16K pagesize
> > NAND.
> >
> > The Toshiba's TC58TEG5DCJTA pagesize is 16K, oob size is 1280 bytes.
> > So increase the NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE.
>
> It would help if we had nand_base/nand_ids support for TC58TEG5DCJTA
> before we try to increase NAND_MAX_PAGESIZE and NAND_MAX_OOBSIZE yet
> again. AFAICT, nand_base will not detect new, large Toshiba flash
> properly anyway.
There are a lot of 16K page size NAND, they are used in android system.
Many NAND need read retry and data randomization, kernel does not support this
feature.
Kernel also does not support synchronous NAND.
As you know, is someone doing some work to support those feature now?
If Kernel support TC58TEG5DCJTA, the read retry and data randomization also
need be supported, it will be a big project.
>
> > Signed-off-by: Cai Zhiyong
> > ---
> > include/linux/mtd/nand.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index f3ea8da..2f0a7f2 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -56,8 +56,8 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs,
> uint64_t len);
> > * is supported now. If you add a chip with bigger oobsize/page
> > * adjust this accordingly.
> > */
> > -#define NAND_MAX_OOBSIZE 744
> > -#define NAND_MAX_PAGESIZE 8192
> > +#define NAND_MAX_OOBSIZE 1280
> > +#define NAND_MAX_PAGESIZE 16384
>
> It might be time to draw a line in the sand: next person who needs to
> increase MAX_{PAGE,OOB}SIZE gets the job of killing the macro? We are
> long overdue for dynamic buffer allocation.
>
> There are two drivers that use the macros, plus nand_chip.buffers.*. The
> drivers can be weaned off by allocating a small, fixed-size temporary
> buffer for the few tasks that need it. With nand_base.c, I think we can
> get by with waiting to allocate nand_chip.buffers until after we detect
> the writesize/oobsize.
>
> So Cai, are you up for this?
Ok, I will try update it.
>
> >
> > /*
> > * Constants for hardware specific CLE/ALE/NCE function
> >
>
> Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] netvsc: don't flush peers notifying work during setting mtu
There's a possible deadlock if we flush the peers notifying work during setting
mtu:
[ 22.991149] ==
[ 22.991173] [ INFO: possible circular locking dependency detected ]
[ 22.991198] 3.10.0-54.0.1.el7.x86_64.debug #1 Not tainted
[ 22.991219] ---
[ 22.991243] ip/974 is trying to acquire lock:
[ 22.991261] ((&(&net_device_ctx->dwork)->work)){+.+.+.}, at:
[] flush_work+0x5/0x2e0
[ 22.991307]
but task is already holding lock:
[ 22.991330] (rtnl_mutex){+.+.+.}, at: []
rtnetlink_rcv+0x1b/0x40
[ 22.991367]
which lock already depends on the new lock.
[ 22.991398]
the existing dependency chain (in reverse order) is:
[ 22.991426]
-> #1 (rtnl_mutex){+.+.+.}:
[ 22.991449][] __lock_acquire+0xb19/0x1260
[ 22.991477][] lock_acquire+0xa2/0x1f0
[ 22.991501][] mutex_lock_nested+0x89/0x4f0
[ 22.991529][] rtnl_lock+0x17/0x20
[ 22.991552][] netdev_notify_peers+0x12/0x30
[ 22.991579][] netvsc_send_garp+0x22/0x30
[hv_netvsc]
[ 22.991610][] process_one_work+0x211/0x6e0
[ 22.991637][] worker_thread+0x11b/0x3a0
[ 22.991663][] kthread+0xed/0x100
[ 22.991686][] ret_from_fork+0x7c/0xb0
[ 22.991715]
-> #0 ((&(&net_device_ctx->dwork)->work)){+.+.+.}:
[ 22.991715][] check_prevs_add+0x967/0x970
[ 22.991715][] __lock_acquire+0xb19/0x1260
[ 22.991715][] lock_acquire+0xa2/0x1f0
[ 22.991715][] flush_work+0x4e/0x2e0
[ 22.991715][] __cancel_work_timer+0x95/0x130
[ 22.991715][] cancel_delayed_work_sync+0x13/0x20
[ 22.991715][] netvsc_change_mtu+0x84/0x200
[hv_netvsc]
[ 22.991715][] dev_set_mtu+0x34/0x80
[ 22.991715][] do_setlink+0x23a/0xa00
[ 22.991715][] rtnl_newlink+0x394/0x5e0
[ 22.991715][] rtnetlink_rcv_msg+0x9c/0x260
[ 22.991715][] netlink_rcv_skb+0xa9/0xc0
[ 22.991715][] rtnetlink_rcv+0x2a/0x40
[ 22.991715][] netlink_unicast+0xdd/0x190
[ 22.991715][] netlink_sendmsg+0x337/0x750
[ 22.991715][] sock_sendmsg+0x99/0xd0
[ 22.991715][] ___sys_sendmsg+0x39e/0x3b0
[ 22.991715][] __sys_sendmsg+0x42/0x80
[ 22.991715][] SyS_sendmsg+0x12/0x20
[ 22.991715][] system_call_fastpath+0x16/0x1b
This is because we hold the rtnl_lock() before ndo_change_mtu() and try to flush
the work in netvsc_change_mtu(), in the mean time, netdev_notify_peers() may be
called from worker and also trying to hold the rtnl_lock. This will lead the
flush won't succeed forever. Solve this by not canceling and flushing the work,
this is safe because the transmission done by NETDEV_NOTIFY_PEERS was
synchronized with the netif_tx_disable() called by netvsc_change_mtu().
Reported-by: Yaju Cao
Tested-by: Yaju Cao
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Signed-off-by: Jason Wang
---
The patch is needed for stable.
---
drivers/net/hyperv/netvsc_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 524f713..f813572 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -327,7 +327,6 @@ static int netvsc_change_mtu(struct net_device *ndev, int
mtu)
return -EINVAL;
nvdev->start_remove = true;
- cancel_delayed_work_sync(&ndevctx->dwork);
cancel_work_sync(&ndevctx->work);
netif_tx_disable(ndev);
rndis_filter_device_remove(hdev);
--
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 5/9] hfsplus: Known exploit detection for CVE-2012-2319
On Thu, 12 Dec 2013 17:52:28 +0100
vegard.nos...@oracle.com wrote:
> From: Vegard Nossum
>
> See 6f24f892871acc47b40dd594c63606a17c714f77.
>
> Cc: Greg Kroah-Hartman
> Signed-off-by: Vegard Nossum
> ---
> fs/hfsplus/catalog.c |2 ++
> fs/hfsplus/dir.c |3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
> index 968ce41..5f47a1a 100644
> --- a/fs/hfsplus/catalog.c
> +++ b/fs/hfsplus/catalog.c
> @@ -8,6 +8,7 @@
> * Handling of catalog records
> */
>
> +#include
>
> #include "hfsplus_fs.h"
> #include "hfsplus_raw.h"
> @@ -374,6 +375,7 @@ int hfsplus_rename_cat(u32 cnid,
> if (err)
> goto out;
> if (src_fd.entrylength > sizeof(entry) || src_fd.entrylength < 0) {
> + exploit("CVE-2012-2319");
Whooppee but if I drive the box totally out of memory with several of
these file systems I can cause all sorts of problems due to missing null
checks, and I can feed some others such as reiserfs (why do we still ship
that ?) corrupt disk images and patch the kernel that way.
So surely we ought to be fixing the actual bugs first ?
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: pinconf: remove warning: unused variable 'ops'
Signed-off-by: Alexandre Belloni
---
drivers/pinctrl/pinconf.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 4187fe58794d..8bfa0643e5dc 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -296,7 +296,6 @@ static void pinconf_dump_pin(struct pinctrl_dev *pctldev,
static int pinconf_pins_show(struct seq_file *s, void *what)
{
struct pinctrl_dev *pctldev = s->private;
- const struct pinconf_ops *ops = pctldev->desc->confops;
unsigned i, pin;
seq_puts(s, "Pin config settings per pin\n");
@@ -343,7 +342,6 @@ static int pinconf_groups_show(struct seq_file *s, void
*what)
{
struct pinctrl_dev *pctldev = s->private;
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
- const struct pinconf_ops *ops = pctldev->desc->confops;
unsigned ngroups = pctlops->get_groups_count(pctldev);
unsigned selector = 0;
--
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: XFS / writeback invoking soft lockup.
On Fri, Dec 13, 2013 at 09:48:53PM +1100, Dave Chinner wrote: > All I can say is that there doesn't look to be any obvious signs > that this is a XFS or writeback problem fom the stack trace, and > without more information or a reproducable test case I'm not going > to be able to understand the cause. > > Is the problem reproducable, or is it just a one-off? If it's reproducable it would be good to enable the xfs_writepage tracepoint and get a trace-cmd log of 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 v5 08/14] efi: export efi runtime memory mapping to sysfs
On 12/12/13 at 09:36pm, Borislav Petkov wrote: > On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote: > > BTW, I will restructure the whole code when I move them to > > efi_kexec.c, so no worry about it? If you have strong opinion I can > > move them though. > > Well, if it were me, I'd do it now so that it'll see more testing. > Later, it will be only a mechanical move of those functions which belong > to efi_kexec.c and won't need a second testing. Will do, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
On 12/12/13 at 10:04pm, Borislav Petkov wrote: > On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote: > > Rethink about this issue, moving them to efi_$(BITS).c I need move the > > efi_setup from a static variable to an extern, It looks not worth. > > Dave, would you please do what is suggested to you? A big part of > the efi code is split into 32-bit and 64-bit functionality. If you > have a serious argument why it shouldn't be done so then sure, by all > means, but stop coming up with silly arguments like having an extern > declaration is a bad thing. Please. Ok, will do. -- Thanks 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] phy: Add exynos-phy driver
Hi, On Wednesday 11 December 2013 03:46 PM, Sylwester Nawrocki wrote: > On 11/12/13 10:54, Kishon Vijay Abraham I wrote: >> On Wednesday 27 November 2013 06:56 PM, Tomasz Stanislawski wrote: Hello everyone, The Samsung SoCs from Exynos family are enhanced with a bunch of switches dedicated for IP blocks. Those switches are called PHYs in Exynos specification. They are usually controlled by a single bit in a single one-word-long register. >> >> So only enabling this switch is enough for the controller or some other >> actual >> PHY IP is needed along with this switch? >> >> However I'm not sure if the switch should be modelled as PHY as it is not a >> PHY >> in the real sense. > > These are ordinary PHY devices embedded in an SoC. I wouldn't really call > them "switches", as they indeed provide the physical layer functionality > for various interfaces, like USB, HDMI, MIPI CSI/DSI, etc. Their control Are they used along with the phy IPs for which Kamil and others have sent patches or this is used in different SoCs from what Kamil uses? Thanks Kishon > interface is often very simple - usually only an enable and a reset > control bit. But that can't change the fact they are real PHY devices, > so let's not call them switches, that's just untrue. > > Regards, > Sylwester > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] omap: twl-common: Fix musb-hdrc device name.
On Mon, Dec 9, 2013 at 6:50 PM, Tony Lindgren wrote: > * Belisko Marek [131208 23:36]: >> Hi Tony, >> >> On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren wrote: >> > * Belisko Marek [131203 01:21]: >> >> On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek >> >> wrote: >> >> > Hi, >> >> > >> >> > On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I >> >> > wrote: >> >> >> Hi, >> >> >> >> >> >> On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: >> >> >>> Without this change when booting omap3 device (gta04) with board file >> >> >>> leads to follwing errors: >> >> >>> >> >> >>> [1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy >> >> >>> [1.209075] HS USB OTG: no transceiver configured >> >> >>> [1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller >> >> >>> failed with status -517 >> >> >>> >> >> >>> and usb isn't working. >> >> >>> >> >> >>> This is probably regression caused by commit: 6c27f939 >> >> >> >> >> >> I think a better fix would be to have this merged.. >> >> >> https://lkml.org/lkml/2013/7/26/91 >> >> > Yes I see but how this could help with current situation? Ho you then >> >> > specify device number? >> >> I was too fast with reply sorry. I can see whole series and it is of >> >> course correct solution. But as I said >> >> can we except to be merged to 3.13. If not Tony can you pick my patch. >> > >> > If it's a regression, then let's get it merged for the -rc cycle. >> Yes it is regression and without that usb on most omap3 based boards >> without DT will not work. >> > >> > So please try to follow up on getting the proper fix merged, meanwhile >> > I'll mark this thread as read. If you need this one merged for some >> > reason, then please report to get it back to my radar. > > I'm still clueless which USB regression fix to apply for the -rc cycle > though.. Hoping to see a single patch which clearly states the issue > and has acks. Kishon can you please comment on that? Would be possible to get your patch to 3.13 (I seen some comments from Felipe). Otherwise I think only possible option to avoid non-working usb in 3.13 for omap is took my patch. Thanks. > > Regards, > > Tony BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH CFT] ARM:S3C24XX: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
Configs ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR are enabled as default to platform S3C24XX. Introduction of PHYS_VIRT config as default would enable phy-to-virt and virt-to-phy translation function at boot and module loading time and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would enable calculation of kernel load address at run time. PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in systems with NOR flash devices, and ZRELADDR config is mutually exclusive to ZBOOT_ROM. CFT::Call For Testing Requesting maintainers of S3C24XX platforms to evaluate the changes on the board and comment, as I dont have the board for testing and also requesting an ACK the changes. Signed-off-by: panchaxari Cc: Heiko Stuebner Cc: Ben Dooks Cc: Kukjin Kim Cc: Russell King Cc: Linus Walleij Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- S3C24XX is basically a Samsung SOC with ARM920T instruction set, and has an operating frquency of 203MHz, it also has enhanced MMU architecture to support WinCE, EPOC 32 and Linux. This SOC is an Integrated system for hand-held devices and general embedded systems. Supports various types of ROM for booting (NOR/NAND Flash, EEPROM, and others). Supports 8 memory banks, 128M for each bank, with a total of 1GB. --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 32acacb..ec1faea 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -708,6 +708,8 @@ config ARCH_S3C24XX bool "Samsung S3C24XX SoCs" select ARCH_HAS_CPUFREQ select ARCH_REQUIRE_GPIOLIB + select ARM_PATCH_PHYS_VIRT + select AUTO_ZRELADDR select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWM select GENERIC_CLOCKEVENTS -- 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 v3 04/11] PCI/MSI/pSeries: Make quota traversing and requesting race-safe
On Tue, Dec 10, 2013 at 03:30:20PM -0700, Bjorn Helgaas wrote: > Can you outline the race and the scenario that leads to incorrect results > or a crash? I looked through rtas_setup_msi_irqs() (briefly) and I didn't > see the way that concurrent calls for different devices could interfere > with each other. > > I was looking for some place that modifies state, where concurrent calls > might trample on each other, but it looks like msi_quota_for_device() is > pretty safe: it traverses a tree, but everything it computes is on the > stack and it doesn't seem to save results anywhere. Maybe I'm barking up > the wrong tree? Hmm. I've assumed the number of MSIs for a device is cached, and therefore concurrent calls to msi_quota_for_device() and rtas_change_msi() could race. But it seems msi_quota_for_device() indeed computes a quota while reading only device's properties and gains constant result (well, assuming the device tree is not updated, but this is a different story). Which makes me confused about this note from a earlier thread: [quote] On Sat, 2013-10-05 at 16:20 +0200, Alexander Gordeev wrote: > So my point is - drivers should first obtain a number of MSIs they *can* > get, then *derive* a number of MSIs the device is fine with and only then > request that number. Not terribly different from memory or any other type > of resource allocation ;) What if the limit is for a group of devices ? Your interface is racy in that case, another driver could have eaten into the limit in between the calls. Ben. [/quote] Some comment from Ben would be nice, but I think the patch could be dropped for now. Thanks, Bjorn! > Bjorn -- Regards, Alexander Gordeev agord...@redhat.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: [PATCH V10 14/14] xen/pvh: vcpu info placement, load CS selector, and remove debug printk.
On 13/12/13 02:10, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor
>
> This patch addresses 3 things:
>- Resolve vcpu info placement fixme.
>- Load CS selector for PVH after switching to new gdt.
>- Remove printk in case of failure to map pnfs in p2m. This because qemu
> has lot of expected failures when mapping HVM pages.
[...]
> @@ -1423,7 +1425,20 @@ static void __init xen_setup_stackprotector(void)
> {
> /* PVH TBD/FIXME: investigate setup_stack_canary_segment */
> if (xen_feature(XENFEAT_auto_translated_physmap)) {
> + unsigned long dummy;
> +
> switch_to_new_gdt(0);
> +#ifdef CONFIG_X86_64
> + asm volatile ("pushq %0\n"
> + "leaq 1f(%%rip),%0\n"
> + "pushq %0\n"
> + "lretq\n"
> + "1:\n"
> + : "=&r" (dummy) : "0" (__KERNEL_CS));
Why does CS need to be reloaded here?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
