Re: [PATCH 2/4] drm/exynos: fix comparison to bitshift when dealing with a mask

2018년 02월 06일 05:09에 Wolfram Sang 이(가) 쓴 글: > Due to a typo, the mask was destroyed by a comparison instead of a bit > shift. > > Signed-off-by: Wolfram Sang > --- > Only build tested. To be applied individually per subsystem. > >

Re: [PATCH 4/4] net: amd-xgbe: fix comparison to bitshift when dealing with a mask

On 2/5/2018 2:10 PM, Wolfram Sang wrote: > Due to a typo, the mask was destroyed by a comparison instead of a bit > shift. > > Signed-off-by: Wolfram Sang Excellent find. Acked-by: Tom Lendacky David, this should also be applied to

[PATCH 3/4] v4l: dvb-frontends: stb0899: fix comparison to bitshift when dealing with a mask

Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Signed-off-by: Wolfram Sang --- Only build tested. To be applied individually per subsystem. drivers/media/dvb-frontends/stb0899_reg.h | 8 1 file changed, 4 insertions(+),

[PATCH 4/4] net: amd-xgbe: fix comparison to bitshift when dealing with a mask

Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Signed-off-by: Wolfram Sang --- Only build tested. To be applied individually per subsystem. drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/4] drm/exynos: fix comparison to bitshift when dealing with a mask

Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Signed-off-by: Wolfram Sang --- Only build tested. To be applied individually per subsystem. drivers/gpu/drm/exynos/regs-fimc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

In one Renesas driver, I found a typo which turned an intended bit shift ('<<') into a comparison ('<'). Because this is a subtle issue, I looked tree wide for similar patterns. This small patch series is the outcome. Buildbot and checkpatch are happy. Only compile-tested. To be applied

[PATCH 1/4] v4l: vsp1: fix mask creation for MULT_ALPHA_RATIO

Due to a typo, the mask was destroyed by a comparison instead of a bit shift. No regression since the mask has not been used yet. Signed-off-by: Wolfram Sang --- Only build tested. To be applied individually per subsystem.

Re: [PATCH 2/2] clk: renesas: cpg-mssr: add R8A77980 support

Hi Sergei, On Wed, Jan 31, 2018 at 9:31 PM, Sergei Shtylyov wrote: > Add R-Car V3H (R8A77980) Clock Pulse Generator / Module Standby and > Software Reset support, using the CPG/MSSR driver core and the common > R-Car Gen3 code. > > Based on the original (and

Re: [PATCH 1/2] dt-bindings: clock: add R8A77980 CPG core clock definitions

On Wed, Jan 31, 2018 at 9:27 PM, Sergei Shtylyov wrote: > Add macros usable by the device tree sources to reference the R8A77980 > CPG core clocks by index. The data come from the table 8.2e of the R-Car > Series, 3rd Generation User's Manual: Hardware (Rev.

Re: [PATCH 05/11] arm64: dts: renesas: initial R8A77980 SoC device tree

Hi Sergei, On Mon, Feb 5, 2018 at 2:48 PM, Sergei Shtylyov wrote: > On 2/5/2018 4:32 PM, Geert Uytterhoeven wrote: >>> The initial R8A77980 SoC device tree including Cortex-A53 CPU, GIC, >>> timer, >>> CPG, RST, and SYSC. >>> >>> Based on the original (and

Re: [PATCH 05/11] arm64: dts: renesas: initial R8A77980 SoC device tree

On 2/5/2018 4:32 PM, Geert Uytterhoeven wrote: The initial R8A77980 SoC device tree including Cortex-A53 CPU, GIC, timer, CPG, RST, and SYSC. Based on the original (and large) patch by Vladimir Barinov. Signed-off-by: Vladimir Barinov Signed-off-by:

Re: [PATCH 05/11] arm64: dts: renesas: initial R8A77980 SoC device tree

Hi Sergei, On Fri, Feb 2, 2018 at 7:33 PM, Sergei Shtylyov wrote: > The initial R8A77980 SoC device tree including Cortex-A53 CPU, GIC, timer, > CPG, RST, and SYSC. > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir

[PATCH] mmc: sh_mmcif: remove some cruft

The TODO section from 2010 is obsolete. We have DMA and PM meanwhile and we always want to handle errors better, if possible. Also DRIVER_VERSION is not used anymore these days. Signed-off-by: Wolfram Sang --- drivers/mmc/host/sh_mmcif.c | 8 1 file

Re: [PATCH 03/11] dt-bindings: power: add R8A77980 SYSC power domain definitions

On Fri, Feb 2, 2018 at 7:29 PM, Sergei Shtylyov wrote: > Add macros usable by the device tree sources to reference R8A77980 SYSC > power domains by index. > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov

Re: [PATCH/RFT v3] sata_rcar: Reset SATA PHY when Salvator-X board resumes

Hi Sergei, 2018-02-05 17:33 GMT+09:00 Sergei Shtylyov : > Hello! > > On 2/4/2018 10:18 PM, Yoshihiro Kaneko wrote: > >> From: Khiem Nguyen >> >> Because power of Salvator-X board is cut off in suspend, >> it needs to reset SATA

Re: [PATCH 02/11] soc: renesas: rcar-rst: add R8A77980 support

On Fri, Feb 2, 2018 at 7:27 PM, Sergei Shtylyov wrote: > Add support for R-Car V3H (R8A77980) to the R-Car RST driver -- this driver > is needed for the clock driver to work. Please drop the extra spaces in between words that are part of the same sentence.

Re: [PATCH 01/11] soc: renesas: identify R-Car V3H

On Fri, Feb 2, 2018 at 7:22 PM, Sergei Shtylyov wrote: > Add support for identifying the R-Car V3H (R8A77980) SoC. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Geert Uytterhoeven

RE: [RFC v4 12/26] watchdog: renesas_wdt: Add R-Car Gen2 support

Hello Guenter, thank you for your feedback. > -Original Message- > From: devicetree-ow...@vger.kernel.org > [mailto:devicetree-ow...@vger.kernel.org] On Behalf Of Guenter Roeck > Sent: 02 February 2018 02:56 > To: Fabrizio Castro ; Philipp Zabel >

Re: [PATCH 03/11] dt-bindings: power: add R8A77980 SYSC power domain definitions

On Fri, Feb 02, 2018 at 09:29:16PM +0300, Sergei Shtylyov wrote: > Add macros usable by the device tree sources to reference R8A77980 SYSC > power domains by index. > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov

Re: [PATCH 02/11] soc: renesas: rcar-rst: add R8A77980 support

On Fri, Feb 02, 2018 at 09:27:01PM +0300, Sergei Shtylyov wrote: > Add support for R-Car V3H (R8A77980) to the R-Car RST driver -- this driver > is needed for the clock driver to work. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Simon Horman

Re: [PATCH 01/11] soc: renesas: identify R-Car V3H

On Fri, Feb 02, 2018 at 09:22:14PM +0300, Sergei Shtylyov wrote: > Add support for identifying the R-Car V3H (R8A77980) SoC. > > Signed-off-by: Sergei Shtylyov For the record, this matches my reading of the documentation: Reviewed-by: Simon Horman

Re: [PATCH 1/2] dt-bindings: clock: add R8A77980 CPG core clock definitions

On Wed, Jan 31, 2018 at 11:27:47PM +0300, Sergei Shtylyov wrote: > Add macros usable by the device tree sources to reference the R8A77980 > CPG core clocks by index. The data come from the table 8.2e of the R-Car > Series, 3rd Generation User's Manual: Hardware (Rev. 0.80, Oct, 2017), > however I

Re: [PATCH 2/2] clk: renesas: cpg-mssr: add R8A77980 support

On Wed, Jan 31, 2018 at 11:31:05PM +0300, Sergei Shtylyov wrote: > Add R-Car V3H (R8A77980) Clock Pulse Generator / Module Standby and > Software Reset support, using the CPG/MSSR driver core and the common > R-Car Gen3 code. > > Based on the original (and large) patch by Vladimir Barinov. > >

Re: [PATCH/RFT v3] sata_rcar: Reset SATA PHY when Salvator-X board resumes

Hello! On 2/4/2018 10:18 PM, Yoshihiro Kaneko wrote: From: Khiem Nguyen Because power of Salvator-X board is cut off in suspend, it needs to reset SATA PHY state in resume. Otherwise, SATA partition could not be accessed anymore. Signed-off-by: Khiem Nguyen

Re: [PATCH 1/2] DT: arm: shmobile: document R8A77980 SoC bindings

On Mon, Feb 05, 2018 at 12:08:41AM -0600, Rob Herring wrote: > On Fri, Feb 02, 2018 at 09:51:01AM +0100, Simon Horman wrote: > > On Thu, Feb 01, 2018 at 09:01:54PM +0100, Geert Uytterhoeven wrote: > > > On Wed, Jan 31, 2018 at 8:56 PM, Sergei Shtylyov > > >

[PATCH] usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path

This fixes an issue that a gadget driver (usb_f_fs) is possible to stop rx transactions after the usb-dmac is used because the following functions missed to set/check the "running" flag. - usbhsf_dma_prepare_pop_with_usb_dmac() - usbhsf_dma_pop_done_with_usb_dmac() So, if next transaction uses