Re: general protection fault in skb_segment

> Good point. Packet sockets require CAP_NET_RAW, but this is also > taken for virtio, so we probably want more stringent entry tests here. That would be something like #include +#include #include +#include static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,

Re: general protection fault in skb_segment

> Good point. Packet sockets require CAP_NET_RAW, but this is also > taken for virtio, so we probably want more stringent entry tests here. That would be something like #include +#include #include +#include static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,

Re: [PATCH 1/3] dt-bindings: mfd: axp20x: Document backup battery charging property

On Sat, 30 Dec 2017, Paul Kocialkowski wrote: > This adds documentation for the "backup" property of the axp20x driver, > that controls the charging mechanism for the backup battery on axp20x. > > Signed-off-by: Paul Kocialkowski > > diff --git

Re: [PATCH 1/3] dt-bindings: mfd: axp20x: Document backup battery charging property

On Sat, 30 Dec 2017, Paul Kocialkowski wrote: > This adds documentation for the "backup" property of the axp20x driver, > that controls the charging mechanism for the backup battery on axp20x. > > Signed-off-by: Paul Kocialkowski > > diff --git

Re: [PATCH V2 3/7] PCI: make pci_flr_wait() generic and rename to pci_dev_wait()

On 12/13/2017 5:43 PM, Bjorn Helgaas wrote: >> + >> +/* >> + * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within > I think this should reference the "Advanced Capabilities for > Conventional PCI" ECN, shouldn't it? The one I see is dated 13 April > 2006, updated 27 July 2006,

Re: [PATCH V2 3/7] PCI: make pci_flr_wait() generic and rename to pci_dev_wait()

On 12/13/2017 5:43 PM, Bjorn Helgaas wrote: >> + >> +/* >> + * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within > I think this should reference the "Advanced Capabilities for > Conventional PCI" ECN, shouldn't it? The one I see is dated 13 April > 2006, updated 27 July 2006,

Re: [PATCH v2 2/2] PCI: dra7xx: Iterate over INTx status bits

On Fri, Dec 29, 2017 at 05:11:31PM +0530, Vignesh R wrote: > It is possible that more than one legacy IRQ may be set at the same > time, therefore iterate and handle all the pending INTx interrupts > before clearing the status and exiting the IRQ handler. Otherwise, some > interrupts would be

Re: [PATCH 2/3] mfd: axp20x: Add support for backup battery charging

On Sat, 30 Dec 2017, Paul Kocialkowski wrote: > This adds support for backup battery charging for axp20x PMICs, that is > configured through a dedicated device-tree property. > > It supports 4 different charging voltages and as many charging currents. > This is especially useful to allow the

Re: [PATCH v2 2/2] PCI: dra7xx: Iterate over INTx status bits

On Fri, Dec 29, 2017 at 05:11:31PM +0530, Vignesh R wrote: > It is possible that more than one legacy IRQ may be set at the same > time, therefore iterate and handle all the pending INTx interrupts > before clearing the status and exiting the IRQ handler. Otherwise, some > interrupts would be

Re: [PATCH 2/3] mfd: axp20x: Add support for backup battery charging

On Sat, 30 Dec 2017, Paul Kocialkowski wrote: > This adds support for backup battery charging for axp20x PMICs, that is > configured through a dedicated device-tree property. > > It supports 4 different charging voltages and as many charging currents. > This is especially useful to allow the

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On Fri, Dec 22, 2017 at 09:42:47PM +0100, Peter Zijlstra wrote: > On Fri, Dec 22, 2017 at 07:56:29PM +0100, Peter Zijlstra wrote: > > Right; but I figured we'd try and do it 'right' and see how horrible it > > is before we try and do funny things. > > So now it should have a 32ms tick for up to

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On Fri, Dec 22, 2017 at 09:42:47PM +0100, Peter Zijlstra wrote: > On Fri, Dec 22, 2017 at 07:56:29PM +0100, Peter Zijlstra wrote: > > Right; but I figured we'd try and do it 'right' and see how horrible it > > is before we try and do funny things. > > So now it should have a 32ms tick for up to

Re: [PATCH v2 7/9] media: i2c: ov772x: Remove soc_camera dependencies

Hi Jacopo, Thank you for the patch. On Thursday, 28 December 2017 16:01:19 EET Jacopo Mondi wrote: > Remove soc_camera framework dependencies from ov772x sensor driver. > - Handle clock and gpios > - Register async subdevice > - Remove soc_camera specific g/s_mbus_config operations > - Change

Re: [PATCH v2 7/9] media: i2c: ov772x: Remove soc_camera dependencies

Hi Jacopo, Thank you for the patch. On Thursday, 28 December 2017 16:01:19 EET Jacopo Mondi wrote: > Remove soc_camera framework dependencies from ov772x sensor driver. > - Handle clock and gpios > - Register async subdevice > - Remove soc_camera specific g/s_mbus_config operations > - Change

[PATCH] crypto: tcrypt - free xoutbuf instead of axbuf

From: Colin Ian King There seems to be a cut-n-paste bug with the name of the buffer being free'd, xoutbuf should be used instead of axbuf. Detected by CoverityScan, CID#1463420 ("Copy-paste error") Fixes: 427988d981c4 ("crypto: tcrypt - add multibuf aead speed test")

[PATCH] crypto: tcrypt - free xoutbuf instead of axbuf

From: Colin Ian King There seems to be a cut-n-paste bug with the name of the buffer being free'd, xoutbuf should be used instead of axbuf. Detected by CoverityScan, CID#1463420 ("Copy-paste error") Fixes: 427988d981c4 ("crypto: tcrypt - add multibuf aead speed test") Signed-off-by: Colin Ian

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

On 2 January 2018 at 14:53, Geert Uytterhoeven wrote: > On Tue, Jan 2, 2018 at 1:53 PM, Ulf Hansson wrote: >> On 2 January 2018 at 11:48, Rafael J. Wysocki wrote: >>> On Tue, Jan 2, 2018 at 11:44 AM, Geert Uytterhoeven >>>

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

On 2 January 2018 at 14:53, Geert Uytterhoeven wrote: > On Tue, Jan 2, 2018 at 1:53 PM, Ulf Hansson wrote: >> On 2 January 2018 at 11:48, Rafael J. Wysocki wrote: >>> On Tue, Jan 2, 2018 at 11:44 AM, Geert Uytterhoeven >>> wrote: On Tue, Jan 2, 2018 at 11:32 AM, Rafael J. Wysocki

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v2

Quoting Christian König (2018-01-02 12:13:58) > TTM tries to allocate coherent memory in chunks of 2MB first to improve > TLB efficiency and falls back to allocating 4K pages if that fails. > > Suppress the warning when the 2MB allocations fails since there is a > valid fall back path. > > v2:

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v2

Quoting Christian König (2018-01-02 12:13:58) > TTM tries to allocate coherent memory in chunks of 2MB first to improve > TLB efficiency and falls back to allocating 4K pages if that fails. > > Suppress the warning when the 2MB allocations fails since there is a > valid fall back path. > > v2:

[PATCH v2] MIPS: Loongson64: Drop 32-bit support for Loongson 2E/2F devices

The 32-bit support was broken at runtime, it doesn't boot anymore, witch is hard to debug because even early printk isn't working, also there are some build warnings. Some newer bootloader may not support 32-bit ELF. So we decide to drop 32-bit support. Make loongson64 a pure 64-bit arch.

[PATCH v2] MIPS: Loongson64: Drop 32-bit support for Loongson 2E/2F devices

The 32-bit support was broken at runtime, it doesn't boot anymore, witch is hard to debug because even early printk isn't working, also there are some build warnings. Some newer bootloader may not support 32-bit ELF. So we decide to drop 32-bit support. Make loongson64 a pure 64-bit arch.

Re: [PATCH v3] backlight: tdo24m: fix the spi cs between transfers

On Thu, 28 Dec 2017, Robert Jarzmik wrote: > Currently the LCD display (TD035S) on the cm-x300 platform is broken and > remains blank. > > The TD0245S specification requires that the chipselect is toggled > between commands sent to the panel. This was also the purpose of the > former patch of

Re: [PATCH v3 1/2] dt-bindings: Document mti,mips-cpc binding

On Wed, Dec 27, 2017 at 03:37:51PM +0100, Aleksandar Markovic wrote: > From: Paul Burton > > Document a binding for the MIPS Cluster Power Controller (CPC) that > allows the device tree to specify where the CPC registers are located. > > Signed-off-by: Paul Burton

Re: [PATCH v3] backlight: tdo24m: fix the spi cs between transfers

On Thu, 28 Dec 2017, Robert Jarzmik wrote: > Currently the LCD display (TD035S) on the cm-x300 platform is broken and > remains blank. > > The TD0245S specification requires that the chipselect is toggled > between commands sent to the panel. This was also the purpose of the > former patch of

Re: [PATCH v3 1/2] dt-bindings: Document mti,mips-cpc binding

On Wed, Dec 27, 2017 at 03:37:51PM +0100, Aleksandar Markovic wrote: > From: Paul Burton > > Document a binding for the MIPS Cluster Power Controller (CPC) that > allows the device tree to specify where the CPC registers are located. > > Signed-off-by: Paul Burton > Signed-off-by: Aleksandar

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

On 2018-01-02 23:13, Arnd Bergmann wrote: On 2017-12-31 07:10, Arnd Bergmann wrote: On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang wrote: When PCH works under eSPI mode, the PMC (Power Management Controller) in PCH is waiting for SUS_ACK from BMC after it alerts

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

On 2018-01-02 23:13, Arnd Bergmann wrote: On 2017-12-31 07:10, Arnd Bergmann wrote: On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang wrote: When PCH works under eSPI mode, the PMC (Power Management Controller) in PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in dead loop

Re: [PATCH] PCI: exynos: remove the deprecated phy codes

On Wed, Dec 27, 2017 at 06:43:27PM +0900, Jaehoon Chung wrote: > pci-exynos had updated to use the PHY framework. > (drivers/phy/samsung/phy-exynos-pcie.c) > Removed the depreccated codes relevant to phy in pci-exynos.c. > Instead, use the phy-exynos-pcie.c file. > > Modified the binding

Re: [PATCH] PCI: exynos: remove the deprecated phy codes

On Wed, Dec 27, 2017 at 06:43:27PM +0900, Jaehoon Chung wrote: > pci-exynos had updated to use the PHY framework. > (drivers/phy/samsung/phy-exynos-pcie.c) > Removed the depreccated codes relevant to phy in pci-exynos.c. > Instead, use the phy-exynos-pcie.c file. > > Modified the binding

Re: [PATCH] tpm: remove unused variables

On Tue, Jan 02, 2018 at 11:38:54AM +0100, Arnd Bergmann wrote: > The CLKRUN fix caused a few harmless compile-time warnings: > > drivers/char/tpm/tpm_tis.c: In function 'tpm_tis_pnp_remove': > drivers/char/tpm/tpm_tis.c:274:23: error: unused variable 'priv' > [-Werror=unused-variable] >

Re: [PATCH] tpm: remove unused variables

On Tue, Jan 02, 2018 at 11:38:54AM +0100, Arnd Bergmann wrote: > The CLKRUN fix caused a few harmless compile-time warnings: > > drivers/char/tpm/tpm_tis.c: In function 'tpm_tis_pnp_remove': > drivers/char/tpm/tpm_tis.c:274:23: error: unused variable 'priv' > [-Werror=unused-variable] >

Re: [PATCH] mfd: axp20x: Mark axp288 CHRG_BAK_CTRL register volatile

On Fri, 22 Dec 2017, Hans de Goede wrote: > The input current limit bits get updated by the charger detection logic, > so we should not cache the contents of this register. > > Signed-off-by: Hans de Goede > --- > drivers/mfd/axp20x.c | 1 + > 1 file changed, 1

Re: [PATCH 2/3] x86/tsc: Fix erroneous TSC rate on Skylake Xeon

On 12/22/2017 12:27 AM, Len Brown wrote: > From: Len Brown > > Linux-4.9 added INTEL_FAM6_SKYLAKE_X to native_calibrate_tsc(): > > commit 6baf3d61821f > ("x86/tsc: Add additional Intel CPU models to the crystal quirk list") > > There are several problems with doing this.

Re: [PATCH] mfd: axp20x: Mark axp288 CHRG_BAK_CTRL register volatile

On Fri, 22 Dec 2017, Hans de Goede wrote: > The input current limit bits get updated by the charger detection logic, > so we should not cache the contents of this register. > > Signed-off-by: Hans de Goede > --- > drivers/mfd/axp20x.c | 1 + > 1 file changed, 1 insertion(+) Applied, thanks.

Re: [PATCH 2/3] x86/tsc: Fix erroneous TSC rate on Skylake Xeon

On 12/22/2017 12:27 AM, Len Brown wrote: > From: Len Brown > > Linux-4.9 added INTEL_FAM6_SKYLAKE_X to native_calibrate_tsc(): > > commit 6baf3d61821f > ("x86/tsc: Add additional Intel CPU models to the crystal quirk list") > > There are several problems with doing this. > > The first is

Re: [PATCH v7 2/2] mfd: syscon: Add hardware spinlock support

Arnd, > Some system control registers need hardware spinlock to synchronize > between the multiple subsystems, so we should add hardware spinlock > support for syscon. > > Signed-off-by: Baolin Wang > Acked-by: Rob Herring ... did you sign off on this

Re: [PATCH v7 2/2] mfd: syscon: Add hardware spinlock support

Arnd, > Some system control registers need hardware spinlock to synchronize > between the multiple subsystems, so we should add hardware spinlock > support for syscon. > > Signed-off-by: Baolin Wang > Acked-by: Rob Herring ... did you sign off on this in the end? > --- > Changes since v6: >

Re: [PATCH 05/12] pinctrl: armada-37xx: account for const type of of_device_id.data

Hi Julia, On mar., janv. 02 2018, Julia Lawall wrote: > The data field of an of_device_id structure has type const void *, so > there is no need for a const-discarding cast when putting const values > into such a structure. > > Done using Coccinelle. > > Signed-off-by:

Re: [PATCH 05/12] pinctrl: armada-37xx: account for const type of of_device_id.data

Hi Julia, On mar., janv. 02 2018, Julia Lawall wrote: > The data field of an of_device_id structure has type const void *, so > there is no need for a const-discarding cast when putting const values > into such a structure. > > Done using Coccinelle. > > Signed-off-by: Julia Lawall

Re: [PATCH v5 2/3] input: evdev: Replace timeval with timespec64

On Tue, Jan 2, 2018 at 7:46 AM, Dmitry Torokhov wrote: > On Sun, Dec 17, 2017 at 09:18:43PM -0800, Deepa Dinamani wrote: >> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle, >> { >> struct evdev *evdev = handle->private; >> struct

Re: [PATCH v5 2/3] input: evdev: Replace timeval with timespec64

On Tue, Jan 2, 2018 at 7:46 AM, Dmitry Torokhov wrote: > On Sun, Dec 17, 2017 at 09:18:43PM -0800, Deepa Dinamani wrote: >> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle, >> { >> struct evdev *evdev = handle->private; >> struct evdev_client *client; >> -

Re: [PATCH] scripts: Add device_attr_<rw|ro|wr>.pl scripts to convert DEVICE_ATTR uses

On Sat, 2017-12-23 at 15:19 +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 22, 2017 at 12:02:47PM -0800, Joe Perches wrote: > > There are many uses of the DEVICE_ATTR(var, perms, show, store) > > declaration macro that could use one of the convenience macros > > DEVICE_ATTR_RW, DEVICE_ATTR_RO, or

Re: [PATCH] scripts: Add device_attr_.pl scripts to convert DEVICE_ATTR uses

On Sat, 2017-12-23 at 15:19 +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 22, 2017 at 12:02:47PM -0800, Joe Perches wrote: > > There are many uses of the DEVICE_ATTR(var, perms, show, store) > > declaration macro that could use one of the convenience macros > > DEVICE_ATTR_RW, DEVICE_ATTR_RO, or

Re: [PATCH] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II

Hi, On 02-01-18 14:42, Paul Cercueil wrote: Add touchscreen platform data for the Teclast X98 Plus II tablet. Signed-off-by: Paul Cercueil Looks good to me: Acked-by: Hans de Goede You should probably send a v2 rebased on top of:

Re: [PATCH] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II

Hi, On 02-01-18 14:42, Paul Cercueil wrote: Add touchscreen platform data for the Teclast X98 Plus II tablet. Signed-off-by: Paul Cercueil Looks good to me: Acked-by: Hans de Goede You should probably send a v2 rebased on top of:

Re: linux-next: Signed-off-by missing for commit in the tpmdd tree

On Sat, Dec 30, 2017 at 10:32:13AM +1100, Stephen Rothwell wrote: > Hi Jarkko, > > Commit > > c01386d6129f ("tpm: Update MAINTAINERS for Jason Gunthorpe") > > is missing a Signed-off-by from its committer. > > -- > Cheers, > Stephen Rothwell Oops, sorry. It's now fixed. /Jarkko

Re: linux-next: Signed-off-by missing for commit in the tpmdd tree

On Sat, Dec 30, 2017 at 10:32:13AM +1100, Stephen Rothwell wrote: > Hi Jarkko, > > Commit > > c01386d6129f ("tpm: Update MAINTAINERS for Jason Gunthorpe") > > is missing a Signed-off-by from its committer. > > -- > Cheers, > Stephen Rothwell Oops, sorry. It's now fixed. /Jarkko

Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

On Tue, Jan 2, 2018 at 1:17 PM, Anson Huang wrote: > This change is only valid for mx6ul and mx6ull, other SoCs like 6q/dl/qp are > NOT impacted. Thanks for the clarification: Reviewed-by: Fabio Estevam

Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

On Tue, Jan 2, 2018 at 1:17 PM, Anson Huang wrote: > This change is only valid for mx6ul and mx6ull, other SoCs like 6q/dl/qp are > NOT impacted. Thanks for the clarification: Reviewed-by: Fabio Estevam

Re: [PATCH 1/2] ARM: dts: imx6ul: add 696MHz operating point

On Tue, Jan 2, 2018 at 1:12 PM, Anson Huang wrote: > There is a comment in VDD_ARM, VDD_SOC must NOT lower than VDD_ARM. > > Output voltage must be set to the following rules: > • VDD_ARM_CAP <= VDD_SOC_CAP > • VDD_SOC_CAP - VDD_ARM_CAP < 330 mV Thanks for the clarifcation.

Re: [PATCH 1/2] ARM: dts: imx6ul: add 696MHz operating point

On Tue, Jan 2, 2018 at 1:12 PM, Anson Huang wrote: > There is a comment in VDD_ARM, VDD_SOC must NOT lower than VDD_ARM. > > Output voltage must be set to the following rules: > • VDD_ARM_CAP <= VDD_SOC_CAP > • VDD_SOC_CAP - VDD_ARM_CAP < 330 mV Thanks for the clarifcation. Reviewed-by: Fabio

[PATCH] thermal/x86 pkg temp: Remove debugfs_create_u32() casts

When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. Signed-off-by: Geert Uytterhoeven

[PATCH] thermal/x86 pkg temp: Remove debugfs_create_u32() casts

When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. Signed-off-by: Geert Uytterhoeven ---

Re: linux-next: build warning after merge of the netfilter-next tree

Hi Stephen, On Tue, Jan 02, 2018 at 12:14:51PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the netfilter-next tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > In file included from net/ipv6/af_inet6.c:45:0: >

Re: linux-next: build warning after merge of the netfilter-next tree

Hi Stephen, On Tue, Jan 02, 2018 at 12:14:51PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the netfilter-next tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > In file included from net/ipv6/af_inet6.c:45:0: >

[PATCH] iommu/omap: Fix debugfs_create_*() usage

When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. omap_iommu.nr_tlb_entries is "int", hence

[PATCH] iommu/omap: Fix debugfs_create_*() usage

When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. omap_iommu.nr_tlb_entries is "int", hence

[PATCH] clk: Fix debugfs_create_*() usage

When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. clk_core.rate, .accuracy, and .flags are

[PATCH] clk: Fix debugfs_create_*() usage

When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type. Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs. clk_core.rate, .accuracy, and .flags are

Re: [PATCH v2 5/9] arch: sh: migor: Use new renesas-ceu camera driver

Hi Jacopo, Thank you for the patch. As pointed out by the 0day bot, you should move this patch to the end of the series to avoid breaking compilation. On Thursday, 28 December 2017 16:01:17 EET Jacopo Mondi wrote: > Migo-R platform uses sh_mobile_ceu camera driver, which is now being >

Re: [PATCH v2 5/9] arch: sh: migor: Use new renesas-ceu camera driver

Hi Jacopo, Thank you for the patch. As pointed out by the 0day bot, you should move this patch to the end of the series to avoid breaking compilation. On Thursday, 28 December 2017 16:01:17 EET Jacopo Mondi wrote: > Migo-R platform uses sh_mobile_ceu camera driver, which is now being >

[PATCH] ACPI: Fix debugfs_create_*() usage

acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose the wrong half on big-endian 64-bit systems. Fix this by changing its type to "u32" and removing the cast, as all other code already uses u32 or sometimes even only u8. Fixes: 1195a098168fcacf ("ACPI: Provide

[PATCH] ACPI: Fix debugfs_create_*() usage

acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose the wrong half on big-endian 64-bit systems. Fix this by changing its type to "u32" and removing the cast, as all other code already uses u32 or sometimes even only u8. Fixes: 1195a098168fcacf ("ACPI: Provide

Re: [PATCH v17 0/5] ZII RAVE platform driver

On Wed, 20 Dec 2017, Andrey Smirnov wrote: > Everyone: > > This patch series is v17 of the driver for supervisory processor found > on RAVE series of devices from ZII. Supervisory processor is a PIC > microcontroller connected to various electrical subsystems on RAVE > devices whose firmware

Re: [PATCH v17 0/5] ZII RAVE platform driver

On Wed, 20 Dec 2017, Andrey Smirnov wrote: > Everyone: > > This patch series is v17 of the driver for supervisory processor found > on RAVE series of devices from ZII. Supervisory processor is a PIC > microcontroller connected to various electrical subsystems on RAVE > devices whose firmware

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

On Tue, 2 Jan 2018, Bart Van Assche wrote: > On Tue, 2018-01-02 at 15:00 +0100, Julia Lawall wrote: > > On Tue, 2 Jan 2018, Bob Peterson wrote: > > > - Original Message - > > > > - Original Message - > > > > > > > Still, the GFS2 and DLM code has a plethora of broken-up printk

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

On Tue, 2 Jan 2018, Bart Van Assche wrote: > On Tue, 2018-01-02 at 15:00 +0100, Julia Lawall wrote: > > On Tue, 2 Jan 2018, Bob Peterson wrote: > > > - Original Message - > > > > - Original Message - > > > > > > > Still, the GFS2 and DLM code has a plethora of broken-up printk

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

> On 2017-12-31 07:10, Arnd Bergmann wrote: > > On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang > > wrote: > >> When PCH works under eSPI mode, the PMC (Power Management Controller) in > >> PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in > >> dead

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

> On 2017-12-31 07:10, Arnd Bergmann wrote: > > On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang > > wrote: > >> When PCH works under eSPI mode, the PMC (Power Management Controller) in > >> PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in > >> dead loop if no SUS_ACK assert.

Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

Hi Anson, On Tue, Jan 2, 2018 at 1:05 PM, Anson Huang wrote: > This change is to support 696MHz operating point, both the speed grading > check and pll rate change are necessary for 696MHz support, do you think > they should be in different patch? I thought this could

Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

Hi Anson, On Tue, Jan 2, 2018 at 1:05 PM, Anson Huang wrote: > This change is to support 696MHz operating point, both the speed grading > check and pll rate change are necessary for 696MHz support, do you think > they should be in different patch? I thought this could also change the

[PATCH v5 03/15] clk: ingenic: support PLLs with no bypass bit

The second PLL of the JZ4770 does not have a bypass bit. This commit makes it possible to support it with the current common CGU code. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 3 ++-

[PATCH v5 03/15] clk: ingenic: support PLLs with no bypass bit

The second PLL of the JZ4770 does not have a bypass bit. This commit makes it possible to support it with the current common CGU code. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 3 ++- drivers/clk/ingenic/cgu.h | 2 ++ 2 files changed, 4 insertions(+),

[PATCH v5 02/15] clk: ingenic: Fix recalc_rate for clocks with fixed divider

Previously, the clocks with a fixed divider would report their rate as being the same as the one of their parent, independently of the divider in use. This commit fixes this behaviour. This went unnoticed as neither the jz4740 nor the jz4780 CGU code have clocks with fixed dividers yet.

[PATCH v5 02/15] clk: ingenic: Fix recalc_rate for clocks with fixed divider

Previously, the clocks with a fixed divider would report their rate as being the same as the one of their parent, independently of the divider in use. This commit fixes this behaviour. This went unnoticed as neither the jz4740 nor the jz4780 CGU code have clocks with fixed dividers yet.

[PATCH v5 05/15] dt-bindings: clock: Add jz4770-cgu.h header

This will be used from the devicetree bindings to specify the clocks that should be obtained from the jz4770-cgu driver. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- include/dt-bindings/clock/jz4770-cgu.h | 58

[PATCH v5 01/15] clk: ingenic: Use const pointer to clk_ops in struct

The CGU common code does not modify the pointed clk_ops structure, so it should be marked as const. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.h| 2 +- drivers/clk/ingenic/jz4780-cgu.c | 2 +- 2 files

[PATCH v5 01/15] clk: ingenic: Use const pointer to clk_ops in struct

The CGU common code does not modify the pointed clk_ops structure, so it should be marked as const. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.h| 2 +- drivers/clk/ingenic/jz4780-cgu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) v2:

[PATCH v5 05/15] dt-bindings: clock: Add jz4770-cgu.h header

This will be used from the devicetree bindings to specify the clocks that should be obtained from the jz4770-cgu driver. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- include/dt-bindings/clock/jz4770-cgu.h | 58 ++ 1 file changed, 58 insertions(+)

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

On Tue, 2018-01-02 at 15:00 +0100, Julia Lawall wrote: > On Tue, 2 Jan 2018, Bob Peterson wrote: > > - Original Message - > > > - Original Message - > > > > > Still, the GFS2 and DLM code has a plethora of broken-up printk messages, > > and I don't like the thought of re-combining

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

On Tue, 2018-01-02 at 15:00 +0100, Julia Lawall wrote: > On Tue, 2 Jan 2018, Bob Peterson wrote: > > - Original Message - > > > - Original Message - > > > > > Still, the GFS2 and DLM code has a plethora of broken-up printk messages, > > and I don't like the thought of re-combining

[PATCH v5 08/15] MIPS: ingenic: Use common cmdline handling code

From: Paul Burton jz4740_init_cmdline appends all arguments from argv (in fw_arg1) to arcs_cmdline, up to argc (in fw_arg0). The common code in fw_init_cmdline will do the exact same thing when run on a system where fw_arg0 isn't a pointer to kseg0 (it'll also set

[PATCH v5 08/15] MIPS: ingenic: Use common cmdline handling code

From: Paul Burton jz4740_init_cmdline appends all arguments from argv (in fw_arg1) to arcs_cmdline, up to argc (in fw_arg0). The common code in fw_init_cmdline will do the exact same thing when run on a system where fw_arg0 isn't a pointer to kseg0 (it'll also set _fw_envp but we don't use it).

[PATCH v5 06/15] clk: Add Ingenic jz4770 CGU driver

Add support for the clocks provided by the CGU in the Ingenic JZ4770 SoC. Signed-off-by: Paul Cercueil Signed-off-by: Maarten ter Huurne Acked-by: Stephen Boyd --- drivers/clk/ingenic/Makefile | 1 +

[PATCH v5 04/15] clk: ingenic: Add code to enable/disable PLLs

This commit permits the PLLs to be dynamically enabled and disabled when their children clocks are enabled and disabled. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 89

[PATCH v5 06/15] clk: Add Ingenic jz4770 CGU driver

Add support for the clocks provided by the CGU in the Ingenic JZ4770 SoC. Signed-off-by: Paul Cercueil Signed-off-by: Maarten ter Huurne Acked-by: Stephen Boyd --- drivers/clk/ingenic/Makefile | 1 + drivers/clk/ingenic/jz4770-cgu.c | 483 +++ 2 files

[PATCH v5 04/15] clk: ingenic: Add code to enable/disable PLLs

This commit permits the PLLs to be dynamically enabled and disabled when their children clocks are enabled and disabled. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 89 +++ 1 file changed, 74 insertions(+), 15

[PATCH v5 09/15] MIPS: platform: add machtype IDs for more Ingenic SoCs

Add a machtype ID for the JZ4780 SoC, which was missing, and one for the newly supported JZ4770 SoC. Signed-off-by: Paul Cercueil --- arch/mips/include/asm/bootinfo.h | 2 ++ 1 file changed, 2 insertions(+) v2: No change v3: No change v5: No change diff --git

[PATCH v5 09/15] MIPS: platform: add machtype IDs for more Ingenic SoCs

Add a machtype ID for the JZ4780 SoC, which was missing, and one for the newly supported JZ4770 SoC. Signed-off-by: Paul Cercueil --- arch/mips/include/asm/bootinfo.h | 2 ++ 1 file changed, 2 insertions(+) v2: No change v3: No change v5: No change diff --git

Re: [PATCH v4 0/7] ARM: davinci: convert to common clock framework​

On Sun, Dec 31, 2017 at 5:39 PM, David Lechner wrote: > This series converts mach-davinci to use the common clock framework. > > Basically, this series does some cleanup and rearranging to get things > ready for the conversion. Then there is a patch to add new driver in >

Re: [PATCH v4 0/7] ARM: davinci: convert to common clock framework​

On Sun, Dec 31, 2017 at 5:39 PM, David Lechner wrote: > This series converts mach-davinci to use the common clock framework. > > Basically, this series does some cleanup and rearranging to get things > ready for the conversion. Then there is a patch to add new driver in > drivers/clk and finally

[PATCH v5 07/15] MIPS: Setup boot_command_line before plat_mem_setup

From: Paul Burton Platforms using DT will typically call __dt_setup_arch from plat_mem_setup. This in turn calls early_init_dt_scan. When CONFIG_CMDLINE is set, this leads to its value being copied into boot_command_line by early_init_dt_scan_chosen. If this happens

[PATCH v5 07/15] MIPS: Setup boot_command_line before plat_mem_setup

From: Paul Burton Platforms using DT will typically call __dt_setup_arch from plat_mem_setup. This in turn calls early_init_dt_scan. When CONFIG_CMDLINE is set, this leads to its value being copied into boot_command_line by early_init_dt_scan_chosen. If this happens before the code setting up

[PATCH v5 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

From: Maarten ter Huurne We have seen MMC DMA transfers read corrupted data from SDRAM when a burst interval ends at physical address 0x1000. To avoid this problem, we remove the final page of low memory from the memory map. Signed-off-by: Maarten ter Huurne

[PATCH v5 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

From: Maarten ter Huurne We have seen MMC DMA transfers read corrupted data from SDRAM when a burst interval ends at physical address 0x1000. To avoid this problem, we remove the final page of low memory from the memory map. Signed-off-by: Maarten ter Huurne --- arch/mips/jz4740/setup.c |

[PATCH v5 11/15] MIPS: ingenic: Initial JZ4770 support

Provide just enough bits (clocks, clocksource, uart) to allow a kernel to boot on the JZ4770 SoC to a initramfs userspace. Signed-off-by: Paul Cercueil --- arch/mips/boot/dts/ingenic/jz4770.dtsi | 212 + arch/mips/jz4740/Kconfig

[PATCH v5 12/15] MIPS: JZ4770: Work around config2 misreporting associativity

From: Maarten ter Huurne According to config2, the associativity would be 5-ways, but the documentation states 4-ways, which also matches the documented L2 cache size of 256 kB. Signed-off-by: Maarten ter Huurne --- arch/mips/mm/sc-mips.c | 9

[PATCH v5 12/15] MIPS: JZ4770: Work around config2 misreporting associativity

From: Maarten ter Huurne According to config2, the associativity would be 5-ways, but the documentation states 4-ways, which also matches the documented L2 cache size of 256 kB. Signed-off-by: Maarten ter Huurne --- arch/mips/mm/sc-mips.c | 9 + 1 file changed, 9 insertions(+) v2:

[PATCH v5 11/15] MIPS: ingenic: Initial JZ4770 support

Provide just enough bits (clocks, clocksource, uart) to allow a kernel to boot on the JZ4770 SoC to a initramfs userspace. Signed-off-by: Paul Cercueil --- arch/mips/boot/dts/ingenic/jz4770.dtsi | 212 + arch/mips/jz4740/Kconfig | 6 +

<    5   6   7   8   9   10   11   12   13   14   >