Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18

Hi Simon, On Fri, May 18, 2018 at 01:16:00PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM64 based SoC DT updates for v4.18. > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15

Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.18

On Fri, May 18, 2018 at 01:16:25PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC defconfig updates for v4.18. > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15 18:24:20

Re: [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.18

On Fri, May 18, 2018 at 01:16:44PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC DT bindings updates for v4.18. > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15

Re: [PATCH 3/6] ravb: remove custom .set_link_ksettings from ethtool ops

On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change replaces a custom implementation of .set_link_ksettings > callback with a shared phy_ethtool_set_link_ksettings(), this fixes > sleep in atomic context bug, which is encountered every time when link > settings are changed by ethtool.

Re: [PATCH 4/6] sh_eth: remove custom .nway_reset from ethtool ops

On 05/26/2018 09:46 PM, Sergei Shtylyov wrote: >> The change fixes a sleep in atomic context issue, which can be >> always triggered by running 'ethtool -r' command, because >> phy_start_aneg() protects phydev fields by a mutex. > >Again, I'm unable to reproduce this BUG()... Now I can!

Re: [PATCH 4/6] sh_eth: remove custom .nway_reset from ethtool ops

On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change fixes a sleep in atomic context issue, which can be > always triggered by running 'ethtool -r' command, because > phy_start_aneg() protects phydev fields by a mutex. Again, I'm unable to reproduce this BUG()... > Another note is

Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops

On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change fixes a sleep in atomic context issue, which can be > always triggered by running 'ethtool -r' command, because > phy_start_aneg() protects phydev fields by a mutex. BTW, I was unable to trigger the BUG() with 'ethtool -r eth0'

Re: [PATCH 0/6] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers

On 05/25/2018 09:25 AM, Vladimir Zapolskiy wrote: For ages trivial changes to RAVB and SuperH ethernet links by means of standard 'ethtool' trigger a 'sleeping function called from invalid context' bug, to visualize it on r8a7795 ULCB: % ethtool -r eth0 BUG:

Re: [PATCH 2/6] ravb: remove custom .get_link_ksettings from ethtool ops

On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change replaces a custom implementation of .get_link_ksettings > callback with a shared phy_ethtool_get_link_ksettings(), note that > >lock wrapping is not needed, because the lock does not > serialize access to phydev fields. No BUG()

Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops

Hello. A formal patch review this time... On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change fixes a sleep in atomic context issue, which can be > always triggered by running 'ethtool -r' command, because > phy_start_aneg() protects phydev fields by a mutex. OK so far... >

Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops

Hello. A formal patch review this time... On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change fixes a sleep in atomic context issue, which can be > always triggered by running 'ethtool -r' command, because > phy_start_aneg() protects phydev fields by a mutex. OK so far... >

Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties

On 26.05.2018 19:18, Laurent Pinchart wrote: > On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote: >> Hi Dimitri, > > And sorry for the spelling mistake :-/ That's also a kinda correct spelling. No worries ;)

Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties

On 26.05.2018 19:16, Laurent Pinchart wrote: > Hi Dimitri, > > Thank you for the patch. > > I'll review this in details, but as this patch is based on the "[PATCH/RFC > 1/4] drm: Add colorkey properties" patch I've submitted, please retain the > authorship, both in the Signed-off-by line, and

Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties

On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote: > Hi Dimitri, And sorry for the spelling mistake :-/ > Thank you for the patch. > > I'll review this in details, but as this patch is based on the "[PATCH/RFC > 1/4] drm: Add colorkey properties" patch I've submitted, please retain

Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties

Hi Dimitri, Thank you for the patch. I'll review this in details, but as this patch is based on the "[PATCH/RFC 1/4] drm: Add colorkey properties" patch I've submitted, please retain the authorship, both in the Signed-off-by line, and in the patch author in git. On Saturday, 26 May 2018

[RFC PATCH v2 1/2] drm: Add generic colorkey properties

Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component

[RFC PATCH v2 2/2] drm/tegra: plane: Implement generic colorkey property for older Tegra's

Color keying allows to draw on top of overlapping planes, like for example on top of a video plane. Older Tegra's have a limited color keying capability, such that blending features are reduced when color keying is enabled. In particular dependent weighting isn't possible, meaning that cursors

[RFC PATCH v2 0/2] Implement standard color keying properties for DRM planes

Hello, DRM maintainers! Laurent Pinchart kindly agreed to allow me to pick up his work on the generic colorkey DRM plane property [0]. I've reworked the original patch a tad, hopefully making it flexible enough to cover various HW capabilities. Changes I've made: - Some code clean up

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCH v7 5/5] clk: renesas: Renesas R9A06G032 clock driver

] url: https://github.com/0day-ci/linux/commits/Michel-Pollet/dt-bindings-Add-the-r9a06g032-sysctrl-h-file/20180526-154235 base: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git clk-renesas reproduce: # apt-get install sparse make ARCH=x86_64

Re: [PATCH 2/6] mfd: da9063: Replace model with type

/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next config: x86_64-randconfig-x011-201820 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached

Re: [PATCH] PCI: rcar: Clean up PHY init on failure

On 5/25/2018 9:33 PM, Marek Vasut wrote: If the Gen3 PHY fails to power up, the code does not undo the initialization caused by phy_init(). Add the missing failure handling to the rcar_pcie_phy_init_gen3() function. Signed-off-by: Marek Vasut Reported-by: Geert

Re: [PATCH 2/6] mfd: da9063: Replace model with type

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613 > base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > for-mfd-next > confi

Re: [PATCH 2/6] mfd: da9063: Replace model with type

/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next config: x86_64-randconfig-x002-201820 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save