Re: [PATCH 127/141] staging: qlge: Fix fall-through warnings for Clang

[Benjamin Poirier]

On 2020-11-20 12:39 -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/staging/qlge/qlge_main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/qlge/qlge_main.c 
> b/drivers/staging/qlge/qlge_main.c
> index 27da386f9d87..c41b1373dcf8 100644
> --- a/drivers/staging/qlge/qlge_main.c
> +++ b/drivers/staging/qlge/qlge_main.c
> @@ -1385,6 +1385,7 @@ static void ql_categorize_rx_err(struct ql_adapter 
> *qdev, u8 rx_err,
>   break;
>   case IB_MAC_IOCB_RSP_ERR_CRC:
>   stats->rx_crc_err++;
> + break;
>   default:
>   break;
>   }

In this instance, it think it would be more appropriate to remove the
"default" case.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

[Miguel Ojeda]

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
 wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
irqwait->request.sequence +=
atomic_read(_irq->irq_received);
irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+   break;
case VIA_IRQ_ABSOLUTE:
break;
default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC 3/3] media: atomisp: do not select COMMON_CLK to fix builds

[Stephen Boyd]

Quoting Krzysztof Kozlowski (2020-11-15 09:09:50)
> COMMON_CLK is a user-selectable option with its own dependencies.  The
> most important dependency is !HAVE_LEGACY_CLK.  User-selectable drivers
> should not select COMMON_CLK because they will create a dependency cycle
> and build failures.
> 
> Signed-off-by: Krzysztof Kozlowski 

This is fallout from making the COMMON_CLK symbol selectable in commit
bbd7ffdbef68 ("clk: Allow the common clk framework to be selectable").
Before then we needed drivers to select the COMMON_CLK config so that
the framework was enabled. Now that isn't necessary and any
user-selectable options should be moved to depends syntax.

Reviewed-by: Stephen Boyd 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] clk: fix redefinition of clk_prepare on MIPS with HAVE_LEGACY_CLK

[Stephen Boyd]

Quoting Krzysztof Kozlowski (2020-11-17 23:48:12)
> On Tue, Nov 17, 2020 at 11:41:57PM -0800, Stephen Boyd wrote:
> > Quoting Krzysztof Kozlowski (2020-11-15 09:09:48)
> > > COMMON_CLK even though is a user-selectable symbol, is still selected by
> > > multiple other config options.  COMMON_CLK should not be used when
> > > legacy clocks are provided by architecture, so it correctly depends on
> > > !HAVE_LEGACY_CLK.
> > > 
> > > However it is possible to create a config which selects both COMMON_CLK
> > > (by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to
> > 
> > Why is SND_SUN8I_CODEC selecting COMMON_CLK? Or really, why is
> > SOC_RT305X selecting HAVE_LEGACY_CLK?
> 
> The SND_SUN8I_CODEC I fixed in following patch (I sent separately v2 of
> it).
> 
> The SOC_RT305X select HAVE_LEGACY_CLK? because it is an old, Ralink
> platform, not converted to Common clock frm. Few clock operations are
> defined in: arch/mips/ralink/clk.c
> 

Ok so this patch isn't necessary then? It seems OK to select
HAVE_LEGACY_CLK but not to select COMMON_CLK unless it's architecture
code that can't be enabled when the other architecture code is selecting
HAVE_LEGACY_CLK.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

[Kees Cook]

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook  wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
> ++x;
>   default:
> break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[staging:staging-testing] BUILD SUCCESS 749c1e1481e1d242ded9dd1bf210ddb7c0d22a4f

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
 staging-testing
branch HEAD: 749c1e1481e1d242ded9dd1bf210ddb7c0d22a4f  Merge tag 
'iio-for-5.11a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-next

elapsed time: 722m

configs tested: 112
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
sh  defconfig
c6xevmc6457_defconfig
arm  exynos_defconfig
mipsgpr_defconfig
arm nhk8815_defconfig
mips bigsur_defconfig
mips   jazz_defconfig
powerpc  pmac32_defconfig
mips   lemote2f_defconfig
mips  maltasmvp_defconfig
powerpc  ppc44x_defconfig
powerpc  mpc866_ads_defconfig
mips   ip32_defconfig
armmulti_v5_defconfig
powerpc mpc837x_mds_defconfig
sh   se7619_defconfig
mips allyesconfig
powerpc mpc832x_mds_defconfig
arm  badge4_defconfig
powerpc stx_gp3_defconfig
arm  integrator_defconfig
sh ecovec24_defconfig
mips  cavium_octeon_defconfig
sh  landisk_defconfig
arm bcm2835_defconfig
powerpc mpc8272_ads_defconfig
shedosk7760_defconfig
arm at91_dt_defconfig
powerpc mpc8315_rdb_defconfig
mips rt305x_defconfig
arc  axs103_smp_defconfig
mips loongson1b_defconfig
powerpc  arches_defconfig
powerpc  ppc64e_defconfig
arm  collie_defconfig
xtensaxip_kc705_defconfig
mipsar7_defconfig
arm am200epdkit_defconfig
arm orion5x_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20201124
x86_64   randconfig-a003-20201124
x86_64   randconfig-a004-20201124
x86_64   randconfig-a005-20201124
x86_64   randconfig-a001-20201124
x86_64   randconfig-a002-20201124
i386 randconfig-a004-20201124
i386 randconfig-a003-20201124
i386 randconfig-a002-20201124
i386 randconfig-a005-20201124
i386 randconfig-a001-20201124
i386 randconfig-a006-20201124
i386 randconfig-a012-20201124
i386 randconfig-a013-20201124
i386 randconfig-a011-20201124
i386 randconfig-a016-20201124
i386 randconfig-a014-20201124
i386 randconfig-a015-20201124
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
riscvnommu_k210_defconfig
riscvnommu_virt_defconfig

Re: [PATCH 000/141] Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

On Mon, Nov 23, 2020 at 08:38:46PM +, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>   commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: trivial: hikey9xx: fix be32<->u32 casting warnings

[Arnd Bergmann]

On Thu, Nov 19, 2020 at 1:31 PM Juan Antonio Aldea-Armenteros
 wrote:
>
> This patch fixes the following warnings reported by sparse, by adding
> missing __force annotations.
>
> drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
> restricted __be32
> drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
> restricted __be32
> drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
> restricted __be32
> drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
> restricted __be32
> drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
> restricted __be32
> drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to 
> restricted __be32
>
> drivers/staging/hikey9xx/hisi-spmi-controller.c:239:25: warning: cast from 
> restricted __be32
>
> Rationale for #164:
> data is declared as u32, and it is read and then converted by means of
> be32_to_cpu(). Said function expects a __be32 but data is u32, therefore
> there's a type missmatch here.
>
> Rationale for #239:
> Is the dual of #164. This time data going to be  written so it
> needs to be converted from cpu to __be32, but writel() expects u32 and the
> output of cpu_to_be32 returns a __be32.

Both of the casts look very suspicious, I'd leave these in unless
someone can confirm what the actual desired behavior is.

>  SPMI_SLAVE_OFFSET * slave_id +
>  SPMI_APB_SPMI_RDATA0_BASE_ADDR +
>  i * SPMI_PER_DATAREG_BYTE);
> -   data = be32_to_cpu((__be32)data);
> +   data = be32_to_cpu((__be32 __force)data);
> if ((bc - i * SPMI_PER_DATAREG_BYTE) >> 2) {
> memcpy(buf, , sizeof(data));
> buf += sizeof(data);

The data comes from a readl(), which contains an endian conversion
on architectures that need it, such as when running the board
in big-endian arm64 mode. Having a second endian-conversion
on little-endian architectures means that the data is always swapped
when it gets written to the register.

In the original code before Mauro's commit 8788a30c12c7 ("staging:
spmi: hisi-spmi-controller: use le32 macros where needed"), the data
was byteswapped, and then written into the fifo register, which
produced no warning but would do a double-swap on a big-endian
kernel, and change the behavior from what it was before.

My guess is that Mauro inadvertently fixed this driver for big-endian
mode, without noticing that it was broken to start with, and that
he did not actually try it with CONFIG_CPU_BIG_ENDIAN.

I think the best way would be to go back to to using swab32p()
(not the open-coded version) and then use writesl() or
iowrite32_rep() with count=1 to write the byteswapped FIFO
register without swapping it again.

  Arnd
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Formación Bonificable 2020

[FOESCO]

Buenos días



Desde FOESCO os informamos que se encuentra abierto el plazo de inscripción para
la presente y ÚLTIMA CONVOCATORIA 2020 de Cursos Bonificables.

Recordamos que los cursos van dirigidos a empleados en activo y en situación
de ERTE y son totalmente bonificables con cargo al Crédito de Formación
2020.

Si vuestra empresa todavía dispone de Crédito de Formación 2020 esta es la
última oportunidad para poder consumirlo.


Deseáis que os mandemos la información?


Quedamos a la espera de vuestra respuesta.


Saludos cordiales.


Alex Pons
Director FOESCO.

FOESCO Formación Estatal Continua.
Entidad Organizadora: B200592AA
www.foesco.com
e-mail: cur...@foesco.net
Tel: 910 323 794
(Horario de 9h a 15h y de 17h a 20h de Lunes a Viernes)

FOESCO ofrece formación a empresas y trabajadores en activo a través de
cursos bonificados por la Fundación Estatal para la Formación en el Empleo
(antiguo FORCEM) que gestiona las acciones formativas de FORMACIÓN CONTINUA
para trabajadores y se rige por la ley 30/2015 de 9 de Septiembre.

Antes de imprimir este e-mail piense bien si es necesario hacerlo. Before
printing this e-mail please think twice if you really need it. FOESCO Tfno:
910 382 880 Email: cur...@foesco.com. La información transmitida en este
mensaje está dirigida solamente a las personas o entidades que figuran en el
encabezamiento y contiene información confidencial, por lo que, si usted lo
recibiera por error, por favor destrúyalo sin copiarlo, usarlo ni
distribuirlo, comunicándolo inmediatamente al emisor del mensaje. De
conformidad con lo dispuesto en el Reglamento Europeo del 2016/679, del 27
de Abril de 2016, FOESCO le informa que los datos por usted suministrados
serán tratados con las medidas de seguridad conformes a la normativa vigente
que se requiere. Dichos datos serán empleados con fines de gestión. Para el
ejercicio de sus derechos de transparencia, información, acceso,
rectificación, supresión o derecho al olvido, limitación del tratamiento ,
portabilidad de datos y oposición de sus datos de carácter personal deberá
dirigirse a la dirección del Responsable del tratamiento a C/ LAGUNA DEL
MARQUESADO Nº10, 28021, MADRID, "PULSANDO AQUI"
 y "ENVIAR" o a traves de la
dirección de correo electrónico: ba...@foesco.com

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel