- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "ARM: dts: imx53-qsb-common: fix FEC pinmux config" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: imx53-qsb-common: fix FEC pinmux config to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 18:22:51 CET 2017 From: Patrick Bruenn <p.bruenn(a)beckhoff.com> Date: Wed, 25 Jan 2017 06:25:48 +0100 Subject: ARM: dts: imx53-qsb-common: fix FEC pinmux config From: Patrick Bruenn <p.bruenn(a)beckhoff.com> [ Upstream commit 8b649e426336d7d4800ff9c82858328f4215ba01 ] The pinmux configuration in device tree was different from manual muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us. But recently u-boot is migrating to reuse device tree files from the kernel tree, so it seems to be better to have the correct pinmuxing in our files, too. Signed-off-by: Patrick Bruenn <p.bruenn(a)beckhoff.com> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) --- a/arch/arm/boot/dts/imx53-qsb-common.dtsi +++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi @@ -215,16 +215,16 @@ pinctrl_fec: fecgrp { fsl,pins = < - MX53_PAD_FEC_MDC__FEC_MDC 0x80000000 - MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000 - MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000 - MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000 - MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000 - MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000 - MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000 - MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000 - MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000 - MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000 + MX53_PAD_FEC_MDC__FEC_MDC 0x4 + MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc + MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180 + MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180 + MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180 + MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180 + MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180 + MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4 + MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4 + MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4 >; }; Patches currently in stable-queue which might be from p.bruenn(a)beckhoff.com are queue-4.4/arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch

6 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] adv7604: Initialize drive strength to default when using DT" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] adv7604: Initialize drive strength to default when using DT to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: adv7604-initialize-drive-strength-to-default-when-using-dt.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 18:22:51 CET 2017 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Tue, 29 Nov 2016 09:23:48 -0200 Subject: [media] adv7604: Initialize drive strength to default when using DT From: Lars-Peter Clausen <lars(a)metafoo.de> [ Upstream commit da8892d410db224d9a24104529794e6e37e0c100 ] The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/i2c/adv7604.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2856,6 +2856,9 @@ static int adv76xx_parse_dt(struct adv76 state->pdata.alt_data_sat = 1; state->pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0; state->pdata.bus_order = ADV7604_BUS_ORDER_RGB; + state->pdata.dr_str_data = ADV76XX_DR_STR_MEDIUM_HIGH; + state->pdata.dr_str_clk = ADV76XX_DR_STR_MEDIUM_HIGH; + state->pdata.dr_str_sync = ADV76XX_DR_STR_MEDIUM_HIGH; return 0; } Patches currently in stable-queue which might be from lars(a)metafoo.de are queue-4.4/adv7604-initialize-drive-strength-to-default-when-using-dt.patch

6 years, 7 months

1
0
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 3.18

by Levin, Alexander (Sasha Levin)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 943dc0b3ef9f0168494d6dca305cd0cf53a0b3d4: Linux 3.18.80 (2017-11-08 10:03:50 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg-3.18-2 for you to fetch changes up to dc9288cdd7a681a1eeaa03054be6a098925f06db: IB/ipoib: Change list_del to list_del_init in the tx object (2017-11-08 15:41:33 -0500) - ---------------------------------------------------------------- Akinobu Mita (2): Input: mpr121 - handle multiple bits change of status register Input: mpr121 - set missing event capability Alison Schofield (1): iio: trigger: free trigger resource correctly David Lechner (2): dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification dt-bindings: Add vendor prefix for LEGO Feras Daoud (1): IB/ipoib: Change list_del to list_del_init in the tx object Gilad Ben-Yossef (1): IPsec: do not ignore crypto err in ah4 input Juergen Gross (1): xen/netback: set default upper limit of tx/rx queues to 8 Laurent Pinchart (1): serial: sh-sci: Fix register offsets for the IRDA serial port Maciej W. Rozycki (1): video: fbdev: pmag-ba-fb: Remove bad `__init' annotation Noralf TrÃ¸nnes (1): drm: drm_minor_register(): Clean up debugfs on failure Patrick Bruenn (1): ARM: dts: imx53-qsb-common: fix FEC pinmux config Tony Lindgren (1): ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6 Volodymyr Bendiuga (1): phy: increase size of MII_BUS_ID_SIZE and bus_id William wu (1): usb: hcd: initialize hcd->flags to 0 when rm hcd Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 +++++++++--------- arch/arm/configs/omap2plus_defconfig | 1 + arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 - drivers/gpu/drm/drm_drv.c | 2 +- drivers/iio/trigger/iio-trig-interrupt.c | 8 ++++---- drivers/iio/trigger/iio-trig-sysfs.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +- drivers/input/keyboard/mpr121_touchkey.c | 24 ++++++++++++++-------- drivers/net/xen-netback/netback.c | 6 ++++-- drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 ++-- drivers/tty/serial/sh-sci.c | 17 ++++++++------- drivers/usb/core/hcd.c | 1 + drivers/video/fbdev/pmag-ba-fb.c | 2 +- include/linux/phy.h | 8 ++------ net/ipv4/ah4.c | 3 +++ 17 files changed, 59 insertions(+), 47 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaA2z7AAoJEN6mb/eXdyzcY/8QAJupw2qifHueOo1aV55oBhVU bdaPFKjx/qDW9h+K3lbAIESv9LO2tnrWGyWwEr+WnALF8v34h4z5SyvlH1IbiANz FFS66JijtewDecrGd1jSDFsA31Fb/Fy42vHQIYMxiZFETByr3U4NlDS1zkzvp/IH tF1hVu9pMZXWhRLi1h1YxZe97ZU9Ryj+euMGAQW/PZsn3ZNu3YzOi8GqfHgXeCZE YmsKGU9brevJPJFbm2hBrxCfiRmtUgzb4eb914Mf0zm1B0HOmr3vKtsW/6QvDAYE rGrVXpUMyfoP80WJH9Mxw5qLeKnpSi6o5jdzXf3arzt5JJIyj8XL5X/C6IuoxTNx LbCFfJpW4Qyf+yIW01eM7f3zSlimTyLtih7cwMTGNge0LcAnFcrL+MC+s36tOpvG UH+HxDwzG+7dqnfTb/5ypbsZI6srgyb5PbxEuFzG/YM2/Es1QfWS9zPOzdaPE+Xn WzjU+CbIrSoiJc5qi/61nlhBVK+aNSIIyuNCGjY3FQV4OTYAAKWpezZa0uMFZS5r L3GCaYqZr551Z8uTOm0a4tiZ+1jZPlZ1Tv8YUGr0MqrcR2B0DIIxAeNgOnd8M2op acJkngJiYGrNGp3ZznZvv9ZMPPktRysVwN8u5s/SQvjDlYzCZhAPvnEsRezWLzuk 2/NLxsxp8qRMMK6d8LVh =kzGq -----END PGP SIGNATURE-----

6 years, 7 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH] HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection

by Jason Gerecke

On Thu, Oct 19, 2017 at 1:22 AM, Jiri Kosina <jikos(a)kernel.org> wrote: > On Wed, 18 Oct 2017, Jason Gerecke wrote: > >> The WACOM_PEN_FIELD macro is used to determine if a given HID field should be >> associated with pen input. This field includes several known collection types >> that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application >> collection type is notably missing. This can result in fields within this >> kind of collection being completely ignored by the `wacom_usage_mapping` >> function, preventing the later '*_event' functions from being notified about >> changes to their value. >> >> Fixes: c9c095874a ("HID: wacom: generic: Support and use 'Custom HID' mode and usages") >> Fixes: ac2423c975 ("HID: wacom: generic: add vendor defined touch") >> Cc: stable(a)vger.kernel.org >> Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com> > > Applied to for-4.14/upstream-fixes > > -- > Jiri Kosina > SUSE Labs > Was this branch ever sent to Linus? I don't see any mention of it (or this patch) in the 4.14-rc8 history... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours....

6 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for-4.4 01/39] extcon: palmas: Check the parent instance to prevent the NULL

by Levin, Alexander (Sasha Levin)

From: Roger Quadros <rogerq(a)ti.com> [ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ] extcon-palmas must be child of palmas and expects parent's drvdata to be valid. Check for non NULL parent drvdata and fail if it is NULL. Not doing so will result in a NULL pointer dereference later in the probe() parent drvdata is NULL (e.g. misplaced extcon-palmas node in device tree). Signed-off-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- drivers/extcon/extcon-palmas.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c index 93c30a885740..aa2f6bb82b32 100644 --- a/drivers/extcon/extcon-palmas.c +++ b/drivers/extcon/extcon-palmas.c @@ -190,6 +190,11 @@ static int palmas_usb_probe(struct platform_device *pdev) struct palmas_usb *palmas_usb; int status; + if (!palmas) { + dev_err(&pdev->dev, "failed to get valid parent\n"); + return -EINVAL; + } + palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL); if (!palmas_usb) return -ENOMEM; -- 2.11.0

6 years, 7 months

2
40
0 0

[Linux-stable-mirror] [PATCH] usb: f_fs: Drop check on Reserved1 field on OS_DESC_EXT_COMPAT

by John Keeping

This check has gone through several incompatible variations in commits 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), 354bc45bf329 ("usb: gadget: f_fs: Fix ExtCompat descriptor validation") and 3ba534df815f ("Revert "usb: gadget: f_fs: Fix ExtCompat descriptor validation"") after initially being introduced in commit f0175ab51993 ("usb: gadget: f_fs: OS descriptors support"). The various changes make it impossible for a single userspace implementation to work with different kernel versions, so let's just drop the condition to avoid breaking userspace. Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Cc: stable(a)vger.kernel.org # v4.7+ Signed-off-by: John Keeping <john(a)metanate.com> --- drivers/usb/gadget/function/f_fs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 652397eda6d6..0d9962834345 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -2282,8 +2282,7 @@ static int __ffs_data_do_os_desc(enum ffs_os_desc_type type, int i; if (len < sizeof(*d) || - d->bFirstInterfaceNumber >= ffs->interfaces_count || - !d->Reserved1) + d->bFirstInterfaceNumber >= ffs->interfaces_count) return -EINVAL; for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i) if (d->Reserved2[i]) -- 2.15.0

6 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2 1/6] drm/i915: Update watermark state correctly in sanitize_watermarks

by Maarten Lankhorst

We no longer use intel_crtc->wm.active for watermarks any more, which was incorrect. But this uncovered a bug in sanitize_watermarks(), which meant that we wrote the correct watermarks, but the next update would still use the wrong hw watermarks for calculating. This caused all further updates to fail with -EINVAL and the log would reveal an error like the one below: [ 10.043902] [drm:ilk_validate_wm_level.part.8 [i915]] Sprite WM0 too large 56 (max 0) [ 10.043960] [drm:ilk_validate_pipe_wm [i915]] LP0 watermark invalid [ 10.044030] [drm:intel_crtc_atomic_check [i915]] No valid intermediate pipe watermarks are possible Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.") Cc: stable(a)vger.kernel.org #v4.8+ --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 84817ccc5305..17665ee06c9a 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14442,6 +14442,8 @@ static void sanitize_watermarks(struct drm_device *dev) cs->wm.need_postvbl_update = true; dev_priv->display.optimize_watermarks(intel_state, cs); + + to_intel_crtc_state(crtc->state)->wm = cs->wm; } put_state: -- 2.15.0

6 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] Patch "ASoC: sunxi: Add bindings for sun8i to SPDIF" has been added to the 4.9-stable tree

by Levin, Alexander (Sasha Levin)

On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote: >On Thu, Nov 09, 2017 at 10:09:10AM +0100, gregkh(a)linuxfoundation.org wrote: > >> This is a note to let you know that I've just added the patch titled >> >> ASoC: sunxi: Add bindings for sun8i to SPDIF > >> The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the >> transmit fifo is at a different address. > >This doesn't seem like a good idea - note how the changelog says that >the transmit FIFO is at a different address, I'd expect this means that >people won't be able to use the new compatible without a corresponding >code change. Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something... I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue. -- Thanks, Sasha

6 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 3.16 000/294] 3.16.50-rc1 review

by Guenter Roeck

On Thu, Nov 09, 2017 at 12:40:36PM +0000, Ben Hutchings wrote: > On Thu, 2017-11-09 at 13:21 +0100, Arnd Bergmann wrote: > > On Thu, Nov 9, 2017 at 1:08 PM, Greg KH <greg(a)kroah.com> wrote: > > > On Thu, Nov 09, 2017 at 12:55:30PM +0100, Arnd Bergmann wrote: > [...] > > > > I think if you upload the branch to the stable-rc git, that should produce > > > > the automated build and boot results via email or via the > > > > https://kernelci.org/job/ interface. Once there are some results > > > > there, I'll go through the list once more to see what warnings > > > > and failures remain. > > > > > > I don't know of a way to have others push to that tree/branch at the > > > moment :( > > > > > > I'll go update that branch now... > > > > Thanks! > > > > With the arm-soc tree, we simply have a shared group-id on > > gitolite.kernel.org and everyone in that group can push to it. > > > > If that is the only thing you need, it should be trivial to let Ben > > and Sasha push to /pub/scm/linux/kernel/git/stable/*.git as well, > > I'm sure helpdesk(a)kernel.org can arrange that. Of course if you are > > worried about having multiple accounts with write access to all the > > branches, then that wouldn't be enough. > > I think I'd rather send a pull request to Greg at the start of the > review period. > If you change the trees I am supposed to pull from for my builders, please let me know. Guenter

6 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drm/fsl-dcu: set DPMS off before initializing connector

by Stefan Agner

Since commit 4a97a3da420b ("drm: Don't update property values for atomic drivers") atomic drivers must not update property values as properties are read from the state instead. To catch remaining users, the drm_object_property_set_value() function now throws a warning when called by atomic drivers on non-immutable properties, and we hit that warning when creating connectors. The easy fix is to just remove the drm_object_property_set_value() as it is used here to set the initial value of the connector's DPMS property to OFF. The DPMS property applies on top of the connector's state crtc pointer (initialized to NULL) that is the main connector on/off control, and should thus default to ON. Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers") Cc: stable(a)vger.kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Signed-off-by: Stefan Agner <stefan(a)agner.ch> --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c index edd7d8127d19..c54806d08dd7 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c @@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev, { struct drm_encoder *encoder = &fsl_dev->encoder; struct drm_connector *connector = &fsl_dev->connector.base; - struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config; int ret; fsl_dev->connector.encoder = encoder; @@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev, if (ret < 0) goto err_sysfs; - drm_object_property_set_value(&connector->base, - mode_config->dpms_property, - DRM_MODE_DPMS_OFF); - ret = drm_panel_attach(panel, connector); if (ret) { dev_err(fsl_dev->dev, "failed to attach panel\n"); -- 2.14.2

6 years, 7 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror