[RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

Remove old, dead Kconfig options (in order appearing in this commit): - EXPERIMENTAL is gone since v3.9; - INET_LRO: commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"); - USB_DEVICE_CLASS: commit 007bab91324e ("USB: remove CONFIG_USB_DEVICE_CLASS"); - HID_SUPPORT: commit 1f41a6a99476

[RESEND PATCH] c6x: defconfig: Cleanup from old Kconfig options

Remove old, dead Kconfig options (in order appearing in this commit): - EXPERIMENTAL is gone since v3.9; - MISC_DEVICES: commit 7c5763b8453a ("drivers: misc: Remove MISC_DEVICES config option"); Signed-off-by: Krzysztof Kozlowski --- arch/c6x/configs/dsk6455_defconfig | 2

[RESEND PATCH] c6x: defconfig: Cleanup from old Kconfig options

Remove old, dead Kconfig options (in order appearing in this commit): - EXPERIMENTAL is gone since v3.9; - MISC_DEVICES: commit 7c5763b8453a ("drivers: misc: Remove MISC_DEVICES config option"); Signed-off-by: Krzysztof Kozlowski --- arch/c6x/configs/dsk6455_defconfig | 2 --

[RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

Remove old, dead Kconfig options (in order appearing in this commit): - EXPERIMENTAL is gone since v3.9; - INET_LRO: commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"); - USB_DEVICE_CLASS: commit 007bab91324e ("USB: remove CONFIG_USB_DEVICE_CLASS"); - HID_SUPPORT: commit 1f41a6a99476

[RESEND PATCH] alpha: defconfig: Cleanup from old Kconfig options

Remove old, dead Kconfig options (in order appearing in this commit): - IP_NF_QUEUE: commit 3dd6664fac7e ("netfilter: remove unused "config IP_NF_QUEUE""); - AUTOFS_FS: commit 561c5cf9236a ("staging: Remove autofs3"); Signed-off-by: Krzysztof Kozlowski ---

[RESEND PATCH] alpha: defconfig: Cleanup from old Kconfig options

Remove old, dead Kconfig options (in order appearing in this commit): - IP_NF_QUEUE: commit 3dd6664fac7e ("netfilter: remove unused "config IP_NF_QUEUE""); - AUTOFS_FS: commit 561c5cf9236a ("staging: Remove autofs3"); Signed-off-by: Krzysztof Kozlowski --- arch/alpha/defconfig | 2 -- 1

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 9:43 PM, Joe Perches wrote: > > As a concept I think individual files would be better. > But maybe grouping by subsystem instead of by letter. Yes. Grouped by subsystem would be nice. And maybe we could start with just a few bigger groups, and split them

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 9:43 PM, Joe Perches wrote: > > As a concept I think individual files would be better. > But maybe grouping by subsystem instead of by letter. Yes. Grouped by subsystem would be nice. And maybe we could start with just a few bigger groups, and split them as people step on

Re: [PATCH v3 06/15] commoncap: Refactor to remove bprm_secureexec hook

On Tue, Jul 18, 2017 at 6:10 PM, Andy Lutomirski wrote: > On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook wrote: >> The commoncap implementation of the bprm_secureexec hook is the only LSM >> that depends on the final call to its bprm_set_creds hook (since it

Re: [PATCH v3 06/15] commoncap: Refactor to remove bprm_secureexec hook

On Tue, Jul 18, 2017 at 6:10 PM, Andy Lutomirski wrote: > On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook wrote: >> The commoncap implementation of the bprm_secureexec hook is the only LSM >> that depends on the final call to its bprm_set_creds hook (since it may >> be called for multiple files, it

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 9:36 PM, Theodore Ts'o wrote: >> >> Maybe we can just do the prefix thing and just do 26 files A-Z >> instead? Or maybe go by first word (so all the ARM things would go in >> one place?) > > Is that really going to help with merge conflicts? It might help

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 9:36 PM, Theodore Ts'o wrote: >> >> Maybe we can just do the prefix thing and just do 26 files A-Z >> instead? Or maybe go by first word (so all the ARM things would go in >> one place?) > > Is that really going to help with merge conflicts? It might help keep > things

Re: [PATCH 0/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

On Wed, Jul 19, 2017 at 04:05:21PM -0400, Mark Salter wrote: > Yes, I should have included Boris. The last time this came up, Boris > said it was up to you. :) > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401772.html /me goes back and reads the old emails. So I had

Re: [PATCH 0/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

On Wed, Jul 19, 2017 at 04:05:21PM -0400, Mark Salter wrote: > Yes, I should have included Boris. The last time this came up, Boris > said it was up to you. :) > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401772.html /me goes back and reads the old emails. So I had

linux-next: Tree for Jul 20

Hi all, Changes since 20170719: The kbuild tree still produces a large number of build warnings so I reverted a commit from it. The drm-misc tree gained conflict a conflict against the drm-intel tree. The userns tree gained a build failure so I used the version from next-20170719. Non-merge

linux-next: Tree for Jul 20

Hi all, Changes since 20170719: The kbuild tree still produces a large number of build warnings so I reverted a commit from it. The drm-misc tree gained conflict a conflict against the drm-intel tree. The userns tree gained a build failure so I used the version from next-20170719. Non-merge

Re:'Funds AED35,623,785 (US$9.7 Milliön) for you, Write to e-mail: sarah.shuh...@activist.com for dètails.

Re:'Funds AED35,623,785 (US$9.7 Milliön) for you, Write to e-mail: sarah.shuh...@activist.com for dètails.

Re: [PATCH] efifb: allow user to disable write combined mapping.

On Wed, Jul 19, 2017 at 9:28 PM, Andy Lutomirski wrote: > > It shouldn't be that hard to hack up efifb to allocate some actual RAM > as "framebuffer", unmap it from the direct map, and ioremap_wc() it as > usual. Then you could see if PCIe is important for it. The thing is, the

Re: [PATCH] efifb: allow user to disable write combined mapping.

On Wed, Jul 19, 2017 at 9:28 PM, Andy Lutomirski wrote: > > It shouldn't be that hard to hack up efifb to allocate some actual RAM > as "framebuffer", unmap it from the direct map, and ioremap_wc() it as > usual. Then you could see if PCIe is important for it. The thing is, the "actual RAM"

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, 2017-07-19 at 21:24 -0700, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: > > > > Just for ease of manipulation and not breaking the script much, > > I'd suggest just having a MAINTAINERS directory and stuffing > > each of the sections into

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, 2017-07-19 at 21:24 -0700, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: > > > > Just for ease of manipulation and not breaking the script much, > > I'd suggest just having a MAINTAINERS directory and stuffing > > each of the sections into separate files. >

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> So the fortify_string code has decided that only a single-byte (or > empty) memcpy is ok. > > And that, in turn, seems to be because we're copying from > optprobe_template_entry, which is declared as > > extern __visible kprobe_opcode_t optprobe_template_entry; > > so the fortify code

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> So the fortify_string code has decided that only a single-byte (or > empty) memcpy is ok. > > And that, in turn, seems to be because we're copying from > optprobe_template_entry, which is declared as > > extern __visible kprobe_opcode_t optprobe_template_entry; > > so the fortify code

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 09:24:13PM -0700, Linus Torvalds wrote: > So I don't mind the idea of just making MAINTAINERS a directory, but I > don't think we want to so far as to make one file per entry. That's > what, 1500+ files tiny files or so? Seems a bit excessive. > > Maybe we can just do the

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 09:24:13PM -0700, Linus Torvalds wrote: > So I don't mind the idea of just making MAINTAINERS a directory, but I > don't think we want to so far as to make one file per entry. That's > what, 1500+ files tiny files or so? Seems a bit excessive. > > Maybe we can just do the

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 04:40:25PM +, Kani, Toshimitsu wrote: > ghes_edac allows to report errors to OS management tools like > rasdaemon in addition to platform- specific managements. So ghes_edac *is* a poor man's driver in the sense that it doesn't do anything fancy but repeat like a

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 04:40:25PM +, Kani, Toshimitsu wrote: > ghes_edac allows to report errors to OS management tools like > rasdaemon in addition to platform- specific managements. So ghes_edac *is* a poor man's driver in the sense that it doesn't do anything fancy but repeat like a

[PATCH v2 2/2] vfio: platform: reset: Add Broadcom FlexRM reset module

This patch adds Broadcom FlexRM low-level reset for VFIO platform. It will do the following: 1. Disable/Deactivate each FlexRM ring 2. Flush each FlexRM ring The cleanup sequence for FlexRM rings is adapted from Broadcom FlexRM mailbox driver. Signed-off-by: Anup Patel

[PATCH v2 2/2] vfio: platform: reset: Add Broadcom FlexRM reset module

This patch adds Broadcom FlexRM low-level reset for VFIO platform. It will do the following: 1. Disable/Deactivate each FlexRM ring 2. Flush each FlexRM ring The cleanup sequence for FlexRM rings is adapted from Broadcom FlexRM mailbox driver. Signed-off-by: Anup Patel Reviewed-by: Oza Oza

[PATCH v2 1/2] vfio: Allow No-IOMMU mode without checking iommu_present()

Not allowing No-IOMMU mode for devices already having iommu_ops on their bus is very conservative. We now have IOMMU (such as ARM SMMU) which can bypass transcations when IOMMU is not configured for a given device. In addition, it is not necessary to have all devices on bus to be upstream to an

[PATCH v2 1/2] vfio: Allow No-IOMMU mode without checking iommu_present()

Not allowing No-IOMMU mode for devices already having iommu_ops on their bus is very conservative. We now have IOMMU (such as ARM SMMU) which can bypass transcations when IOMMU is not configured for a given device. In addition, it is not necessary to have all devices on bus to be upstream to an

[PATCH v2 0/2] FlexRM support in VFIO platform

This patchset primarily adds Broadcom FlexRM reset module for VFIO platform driver. We also have minor improvments in IOMMU and VFIO driver to allow VFIO no-IOMMU mode access to FlexRM. The patches are based on Linux-4.13-rc1 and can also be found at flexrm-vfio-v2 branch of

[PATCH v2 0/2] FlexRM support in VFIO platform

This patchset primarily adds Broadcom FlexRM reset module for VFIO platform driver. We also have minor improvments in IOMMU and VFIO driver to allow VFIO no-IOMMU mode access to FlexRM. The patches are based on Linux-4.13-rc1 and can also be found at flexrm-vfio-v2 branch of

Re: [PATCH] livepatch: add (un)patch hooks

On Wed, Jul 19, 2017 at 11:17:23PM -0500, Josh Poimboeuf wrote: > This one was interesting: > > 6f442be2fb22 ("x86_64, traps: Stop using IST for #SS") > > A livepatch patch for it is below. We had something similar for kpatch. > The below patch is completely untested because we don't have >

Re: [PATCH] livepatch: add (un)patch hooks

On Wed, Jul 19, 2017 at 11:17:23PM -0500, Josh Poimboeuf wrote: > This one was interesting: > > 6f442be2fb22 ("x86_64, traps: Stop using IST for #SS") > > A livepatch patch for it is below. We had something similar for kpatch. > The below patch is completely untested because we don't have >

Re: [PATCH] efifb: allow user to disable write combined mapping.

On Wed, Jul 19, 2017 at 9:07 PM, Dave Airlie wrote: > > Yes hoping someone can give some insight. > > Scrap the multi-socket it's been seen on a single-socket, but not as > drastic, 2x rather than 10x slowdowns. > > It's starting to seem like the commonality might be the Matrox

Re: [PATCH] efifb: allow user to disable write combined mapping.

On Wed, Jul 19, 2017 at 9:07 PM, Dave Airlie wrote: > > Yes hoping someone can give some insight. > > Scrap the multi-socket it's been seen on a single-socket, but not as > drastic, 2x rather than 10x slowdowns. > > It's starting to seem like the commonality might be the Matrox G200EH > which is

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: > > Just for ease of manipulation and not breaking the script much, > I'd suggest just having a MAINTAINERS directory and stuffing > each of the sections into separate files. > > The script would only need to add $ cat

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: > > Just for ease of manipulation and not breaking the script much, > I'd suggest just having a MAINTAINERS directory and stuffing > each of the sections into separate files. > > The script would only need to add $ cat MAINTAINERS/* as input.

Re: [PATCH] livepatch: add (un)patch hooks

On Wed, Jul 19, 2017 at 11:17:23PM -0500, Josh Poimboeuf wrote: > +static void swapgs_unload_hook(void) > +{ > + if (paravirt_enabled() && strcmp(pv_info.name, "KVM")) > + return; > + > + write_cr0(read_cr0() & ~X86_CR0_WP); > + barrier(); > + > +

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 02:55:08PM -0400, Aristeu Rozanski wrote: > That would also need to keep an eye on versions. A newer version of BIOS > on a whitelisted platform might be broken. Yeah, that would be a nasty, back-stabbing SNAFU. So I'm thinking of adding a bunch of FW_ERR sanity checks to

Re: [PATCH] livepatch: add (un)patch hooks

On Wed, Jul 19, 2017 at 11:17:23PM -0500, Josh Poimboeuf wrote: > +static void swapgs_unload_hook(void) > +{ > + if (paravirt_enabled() && strcmp(pv_info.name, "KVM")) > + return; > + > + write_cr0(read_cr0() & ~X86_CR0_WP); > + barrier(); > + > +

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 02:55:08PM -0400, Aristeu Rozanski wrote: > That would also need to keep an eye on versions. A newer version of BIOS > on a whitelisted platform might be broken. Yeah, that would be a nasty, back-stabbing SNAFU. So I'm thinking of adding a bunch of FW_ERR sanity checks to

Re: [PATCH] livepatch: add (un)patch hooks

On Wed, Jul 19, 2017 at 03:49:52PM -0500, Josh Poimboeuf wrote: > > I am sorry for the long mail. But I have really troubles to > > understand and describe what can be done with these hooks > > a safe way. > > > > It might help if you share some real-life examples. > > Agreed, we should share

Re: [PATCH] livepatch: add (un)patch hooks

On Wed, Jul 19, 2017 at 03:49:52PM -0500, Josh Poimboeuf wrote: > > I am sorry for the long mail. But I have really troubles to > > understand and describe what can be done with these hooks > > a safe way. > > > > It might help if you share some real-life examples. > > Agreed, we should share

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 04:56:17PM +, Kani, Toshimitsu wrote: > Since ghes_edac has not been used for a long time, I have a feeling > that not so many vendors want to use it. In the case of HPE, we do not > need to update with each platform since "HPE" "Server" will cover all > platforms we

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Wed, Jul 19, 2017 at 04:56:17PM +, Kani, Toshimitsu wrote: > Since ghes_edac has not been used for a long time, I have a feeling > that not so many vendors want to use it. In the case of HPE, we do not > need to update with each platform since "HPE" "Server" will cover all > platforms we

linux-next: build warning after merge of the char-misc tree

Hi all, After merging the char-misc tree, yesterday's linux-next build (i386 defconfig) produced this warning: In file included from /home/sfr/next/next/arch/x86/entry/vdso/vma.c:25:0: /home/sfr/next/next/arch/x86/include/asm/mshyperv.h:181:15: warning: return type defaults to 'int'

linux-next: build warning after merge of the char-misc tree

Hi all, After merging the char-misc tree, yesterday's linux-next build (i386 defconfig) produced this warning: In file included from /home/sfr/next/next/arch/x86/entry/vdso/vma.c:25:0: /home/sfr/next/next/arch/x86/include/asm/mshyperv.h:181:15: warning: return type defaults to 'int'

Re: [PATCH] efifb: allow user to disable write combined mapping.

On 19 July 2017 at 11:15, Linus Torvalds wrote: > On Tue, Jul 18, 2017 at 5:00 PM, Dave Airlie wrote: >> >> More digging: >> Single CPU system: >> Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz >> 01:00.1 VGA compatible controller: Matrox Electronics

Re: [PATCH] efifb: allow user to disable write combined mapping.

On 19 July 2017 at 11:15, Linus Torvalds wrote: > On Tue, Jul 18, 2017 at 5:00 PM, Dave Airlie wrote: >> >> More digging: >> Single CPU system: >> Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz >> 01:00.1 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200EH >> >> Now I can't get

RE: [PATCH 3/3] platform/x86: Add Audio domain PG status events

> -Original Message- > From: Bhardwaj, Rajneesh > Sent: Wednesday, July 19, 2017 7:08 PM > To: Chakravarty, Souvik K > Cc: platform-driver-...@vger.kernel.org; dvh...@infradead.org; > a...@infradead.org; linux-kernel@vger.kernel.org; Murthy, Shanth >

RE: [PATCH 3/3] platform/x86: Add Audio domain PG status events

> -Original Message- > From: Bhardwaj, Rajneesh > Sent: Wednesday, July 19, 2017 7:08 PM > To: Chakravarty, Souvik K > Cc: platform-driver-...@vger.kernel.org; dvh...@infradead.org; > a...@infradead.org; linux-kernel@vger.kernel.org; Murthy, Shanth > > Subject: Re: [PATCH 3/3]

Re: [PATCH 5/5] vfio: platform: reset: Add Broadcom FlexRM reset module

On Wed, Jul 19, 2017 at 10:20 PM, Scott Branden wrote: > Hi Anup, > > NAK - as indicated in internal review please use unmodified Broadcom legal > header in its own comment block. I had addressed your internal review comments and used standard GLPv2 header (also

Re: [PATCH 5/5] vfio: platform: reset: Add Broadcom FlexRM reset module

On Wed, Jul 19, 2017 at 10:20 PM, Scott Branden wrote: > Hi Anup, > > NAK - as indicated in internal review please use unmodified Broadcom legal > header in its own comment block. I had addressed your internal review comments and used standard GLPv2 header (also present in other drivers). The

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hmm. I wonder why the kernel test robot ends up having that annoying line doubling for the dmesg. On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 6974f0c4555e285ab217cee58b6e874f776ff409

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

Hmm. I wonder why the kernel test robot ends up having that annoying line doubling for the dmesg. On Wed, Jul 19, 2017 at 6:42 PM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 6974f0c4555e285ab217cee58b6e874f776ff409 ("include/linux/string.h: > add the option

Re: [PATCH 3/5] iommu/arm-smmu-v3: add IOMMU_CAP_BYPASS to the ARM SMMUv3 driver

On Wed, Jul 19, 2017 at 5:23 PM, Will Deacon wrote: > On Wed, Jul 19, 2017 at 05:09:05PM +0530, Anup Patel wrote: >> On Wed, Jul 19, 2017 at 5:03 PM, Will Deacon wrote: >> > On Wed, Jul 19, 2017 at 05:01:11PM +0530, Anup Patel wrote: >> >> On Wed, Jul

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 > [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 Probably this: /* Copy arch-dep-instance from template */ memcpy(buf, _template_entry, TMPL_END_IDX); Not a real bug, just technically undefined because these

Re: [PATCH 3/5] iommu/arm-smmu-v3: add IOMMU_CAP_BYPASS to the ARM SMMUv3 driver

On Wed, Jul 19, 2017 at 5:23 PM, Will Deacon wrote: > On Wed, Jul 19, 2017 at 05:09:05PM +0530, Anup Patel wrote: >> On Wed, Jul 19, 2017 at 5:03 PM, Will Deacon wrote: >> > On Wed, Jul 19, 2017 at 05:01:11PM +0530, Anup Patel wrote: >> >> On Wed, Jul 19, 2017 at 4:55 PM, Will Deacon wrote: >>

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 > [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 Probably this: /* Copy arch-dep-instance from template */ memcpy(buf, _template_entry, TMPL_END_IDX); Not a real bug, just technically undefined because these

[PATCH v2 00/10] ARM: sun8i: a83t: Add support for MMC controllers

Hi everyone, This is v2 of my MMC controller support series. Changes since v1: - Fix patches already applied have been dropped - V2 now exports sunxi-ng mmc timing mode API functions (in case mmc driver is built as a module) - Added stub functions for the timing mode API functions,

[PATCH v2 07/10] ARM: dts: sun8i: a83t: Add MMC controller device nodes

The A83T has 3 MMC controllers. The third one is a bit special, as it supports a wider 8-bit bus, and a "new timing mode". Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 59 +++ 1 file changed, 59 insertions(+) diff --git

[PATCH v2 00/10] ARM: sun8i: a83t: Add support for MMC controllers

Hi everyone, This is v2 of my MMC controller support series. Changes since v1: - Fix patches already applied have been dropped - V2 now exports sunxi-ng mmc timing mode API functions (in case mmc driver is built as a module) - Added stub functions for the timing mode API functions,

[PATCH v2 07/10] ARM: dts: sun8i: a83t: Add MMC controller device nodes

The A83T has 3 MMC controllers. The third one is a bit special, as it supports a wider 8-bit bus, and a "new timing mode". Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 59 +++ 1 file changed, 59 insertions(+) diff --git

[PATCH v2 08/10] ARM: dts: sun8i: a83t: Add pingroup for 8-bit eMMC on mmc2

mmc2 can support 8-bit eMMC chips, with a dedicated reset line. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi index

[PATCH v2 08/10] ARM: dts: sun8i: a83t: Add pingroup for 8-bit eMMC on mmc2

mmc2 can support 8-bit eMMC chips, with a dedicated reset line. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi index 21ab668abfac..d9b4372dbdf3

[PATCH v2 04/10] mmc: sunxi: Support controllers that can use both old and new timings

On the SoCs that introduced the new timing mode for MMC controllers, both the old (where the clock delays are set in the CCU) and new (where the clock delays are set in the MMC controller) timing modes are available, and we have to support them both. However there are two bits that control which

[PATCH v2 04/10] mmc: sunxi: Support controllers that can use both old and new timings

On the SoCs that introduced the new timing mode for MMC controllers, both the old (where the clock delays are set in the CCU) and new (where the clock delays are set in the MMC controller) timing modes are available, and we have to support them both. However there are two bits that control which

[PATCH v2 06/10] mmc: sunxi: Add support for A83T eMMC (MMC2)

The third MMC controller (MMC2) on the Allwinner A83T SoC is slightly different. It supports a wider 8-bit bus, has a dedicated controllable reset pin for eMMC, and a "new timing mode" which is supposed to deliver better signals and thus better performance. Add a compatible for this one to use

[PATCH v2 09/10] ARM: dts: sun8i: a83t: cubietruck-plus: Enable micro-SD card and eMMC

Now that we support the MMC controllers on the A83T SoC, we can enable them on some boards. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 27 1 file changed, 27 insertions(+) diff --git

[PATCH v2 06/10] mmc: sunxi: Add support for A83T eMMC (MMC2)

The third MMC controller (MMC2) on the Allwinner A83T SoC is slightly different. It supports a wider 8-bit bus, has a dedicated controllable reset pin for eMMC, and a "new timing mode" which is supposed to deliver better signals and thus better performance. Add a compatible for this one to use

[PATCH v2 09/10] ARM: dts: sun8i: a83t: cubietruck-plus: Enable micro-SD card and eMMC

Now that we support the MMC controllers on the A83T SoC, we can enable them on some boards. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 27 1 file changed, 27 insertions(+) diff --git

[PATCH v2 10/10] ARM: dts: sun8i: a83t: h8homlet: Enable micro-SD card and onboard eMMC

The H8 homlet has a micro-SD card slot connected to mmc0, and onboard eMMC from FORESEE, connected to mmc2. Signed-off-by: Chen-Yu Tsai --- .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 21 + 1 file changed, 21 insertions(+) diff --git

[PATCH v2 05/10] mmc: sunxi: Support MMC DDR52 transfer mode with new timing mode

The MMC controller can support DDR52 transfers under the new timing mode. According to the BSP kernel, the module clock has to be double the card clock, regardless of the bus width. The default timings in the hardware can be used. This also reworks the code setting the internal divider, getting

[PATCH v2 10/10] ARM: dts: sun8i: a83t: h8homlet: Enable micro-SD card and onboard eMMC

The H8 homlet has a micro-SD card slot connected to mmc0, and onboard eMMC from FORESEE, connected to mmc2. Signed-off-by: Chen-Yu Tsai --- .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 21 + 1 file changed, 21 insertions(+) diff --git

[PATCH v2 05/10] mmc: sunxi: Support MMC DDR52 transfer mode with new timing mode

The MMC controller can support DDR52 transfers under the new timing mode. According to the BSP kernel, the module clock has to be double the card clock, regardless of the bus width. The default timings in the hardware can be used. This also reworks the code setting the internal divider, getting

[PATCH v2 03/10] clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock

The MMC2 clock supports a new timing mode. When the new mode is active, the output clock rate is halved. This patch sets the feature flag for the new timing mode, and adds a pre-divider based on the mode bit. Signed-off-by: Chen-Yu Tsai --- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c

[PATCH v2 03/10] clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock

The MMC2 clock supports a new timing mode. When the new mode is active, the output clock rate is halved. This patch sets the feature flag for the new timing mode, and adds a pre-divider based on the mode bit. Signed-off-by: Chen-Yu Tsai --- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 15

[PATCH v2 02/10] clk: sunxi-ng: Add MP_MMC clocks that support MMC timing modes switching

All of our MMC clocks are of the MP clock type. A few MMC clocks on some SoCs, such as MMC2 on the A83T, support new/old timing mode switching. >From a clock rate point of view, when the new timing mode is active. the output clock rate is halved. This patch adds a special wrapper class of

[PATCH v2 02/10] clk: sunxi-ng: Add MP_MMC clocks that support MMC timing modes switching

All of our MMC clocks are of the MP clock type. A few MMC clocks on some SoCs, such as MMC2 on the A83T, support new/old timing mode switching. >From a clock rate point of view, when the new timing mode is active. the output clock rate is halved. This patch adds a special wrapper class of

[PATCH v2 01/10] clk: sunxi-ng: Add interface to query or configure MMC timing modes.

Starting with the A83T SoC, Allwinner introduced a new timing mode for its MMC clocks. The new mode changes how the MMC controller sample and output clocks are delayed to match chip and board specifics. There are two controls for this, one on the CCU side controlling how the clocks behave, and one

[PATCH v2 01/10] clk: sunxi-ng: Add interface to query or configure MMC timing modes.

Starting with the A83T SoC, Allwinner introduced a new timing mode for its MMC clocks. The new mode changes how the MMC controller sample and output clocks are delayed to match chip and board specifics. There are two controls for this, one on the CCU side controlling how the clocks behave, and one

Re: [PATCH RFC v5] cpufreq: schedutil: Make iowait boost more energy efficient

On 19-07-17, 19:38, Joel Fernandes wrote: > On Tue, Jul 18, 2017 at 11:19 PM, Viresh Kumar > wrote: > > On 18-07-17, 21:39, Joel Fernandes wrote: > >> Not really, to me B will still work because in the case the flag is > >> set, we are correctly double boosting in the

Re: [PATCH RFC v5] cpufreq: schedutil: Make iowait boost more energy efficient

On 19-07-17, 19:38, Joel Fernandes wrote: > On Tue, Jul 18, 2017 at 11:19 PM, Viresh Kumar > wrote: > > On 18-07-17, 21:39, Joel Fernandes wrote: > >> Not really, to me B will still work because in the case the flag is > >> set, we are correctly double boosting in the next cycle. > >> > >>

Re: [PATCH] powerpc: Convert to using %pOF instead of full_name

Rob Herring writes: > On Wed, Jul 19, 2017 at 7:03 AM, Michael Ellerman wrote: >> Rob Herring writes: >> >>> Now that we have a custom printf format specifier, convert users of >>> full_name to use %pOF instead. This is preparation to

Re: [PATCH] powerpc: Convert to using %pOF instead of full_name

Rob Herring writes: > On Wed, Jul 19, 2017 at 7:03 AM, Michael Ellerman wrote: >> Rob Herring writes: >> >>> Now that we have a custom printf format specifier, convert users of >>> full_name to use %pOF instead. This is preparation to remove storing >>> of the full path string for each node.

Re: perf: bisected sampling bug in Linux 4.11-rc1

On Tue, 18 Jul 2017, Ingo Molnar wrote: > > Ok, great - if this works then I'll pick up this fix instead of the revert > that > I've queued up earlier today. sorry for the delay, I was out of town for a few days. I've tried the patch and it looks like it fixes the test in question and

Re: perf: bisected sampling bug in Linux 4.11-rc1

On Tue, 18 Jul 2017, Ingo Molnar wrote: > > Ok, great - if this works then I'll pick up this fix instead of the revert > that > I've queued up earlier today. sorry for the delay, I was out of town for a few days. I've tried the patch and it looks like it fixes the test in question and

linux-next: build failure after merge of the userns tree

new pid namespaces") I have used the userns tree from next-20170719 for today. -- Cheers, Stephen Rothwell

linux-next: build failure after merge of the userns tree

new pid namespaces") I have used the userns tree from next-20170719 for today. -- Cheers, Stephen Rothwell

Re: [PATCH] watchdog: imx2_wdt: use new_timeout value to override the old

On 2017年07月20日 11:18, Guenter Roeck wrote: On 07/19/2017 07:45 PM, yanjiang@windriver.com wrote: From: Yanjiang Jin Without this patch we couldn't change the timeout value of imx2_wdt. Signed-off-by: Yanjiang Jin ---

Re: [PATCH] watchdog: imx2_wdt: use new_timeout value to override the old

On 2017年07月20日 11:18, Guenter Roeck wrote: On 07/19/2017 07:45 PM, yanjiang@windriver.com wrote: From: Yanjiang Jin Without this patch we couldn't change the timeout value of imx2_wdt. Signed-off-by: Yanjiang Jin --- drivers/watchdog/imx2_wdt.c | 3 +++ 1 file changed, 3

Re: [PATCH v2 5/7] Input: gpio_keys - use devm_device_add_group() for attributes

On 07/19/2017 05:24 PM, Dmitry Torokhov wrote: Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov Reviewed-by: Guenter Roeck ---

Re: [PATCH v2 5/7] Input: gpio_keys - use devm_device_add_group() for attributes

On 07/19/2017 05:24 PM, Dmitry Torokhov wrote: Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov Reviewed-by: Guenter Roeck --- drivers/input/keyboard/gpio_keys.c | 16 ++--

Re: [PATCH v2 6/7] Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01

On 07/19/2017 05:24 PM, Dmitry Torokhov wrote: Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov Reviewed-by: Guenter Roeck ---

Re: [PATCH v2 6/7] Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01

On 07/19/2017 05:24 PM, Dmitry Torokhov wrote: Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov Reviewed-by: Guenter Roeck --- drivers/input/rmi4/rmi_f01.c | 11 +++ 1 file

Re: [PATCH v2 7/7] Input: axp20x-pek - switch to using devm_device_add_group()

On 07/19/2017 05:24 PM, Dmitry Torokhov wrote: Now that we have proper managed API to create device attributes, let's use it instead of installing a custom devm action. Signed-off-by: Dmitry Torokhov Reviewed-by: Guenter Roeck ---

Re: [PATCH v2 7/7] Input: axp20x-pek - switch to using devm_device_add_group()

On 07/19/2017 05:24 PM, Dmitry Torokhov wrote: Now that we have proper managed API to create device attributes, let's use it instead of installing a custom devm action. Signed-off-by: Dmitry Torokhov Reviewed-by: Guenter Roeck --- drivers/input/misc/axp20x-pek.c | 18 +-

<    1   2   3   4   5   6   7   8   9   10   >