[linux-sunxi] Re: [PATCH v6 18/18] crypto: sun8i-ce: fix some style issue
On Fri, 2020-09-04 at 11:10 +, Corentin Labbe wrote: > This patch fix a double empty line issue reported by checkpatch. > While at it, since now the maximum line length is now 100, reorder some > wrapped line. [] > diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c > b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c [] > @@ -164,12 +164,10 @@ static int sun8i_ce_cipher_prepare(struct crypto_engine > *engine, void *async_req > goto theend_key; > } > offset = areq->cryptlen - ivsize; > - scatterwalk_map_and_copy(rctx->backup_iv, areq->src, > - offset, ivsize, 0); > + scatterwalk_map_and_copy(rctx->backup_iv, areq->src, > offset, ivsize, 0); > } > memcpy(rctx->bounce_iv, areq->iv, ivsize); > - addr_iv = dma_map_single(ce->dev, rctx->bounce_iv, rctx->ivlen, > - DMA_TO_DEVICE); > + addr_iv = dma_map_single(ce->dev, rctx->bounce_iv, rctx->ivlen, > DMA_TO_DEVICE); coding-style.rst: Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Do these longer lines make the code significantly more readable? I don't think they do. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/906c2ffb0ef6b2d87d6aecdf60b61833ea79e4fb.camel%40perches.com.
[linux-sunxi] Re: [PATCH] phy: allwinner: Fix GENMASK misuse
On Thu, 2019-11-07 at 23:39 +, Russell King - ARM Linux admin wrote: > On Thu, Nov 07, 2019 at 09:46:45PM +0100, Rikard Falkeborn wrote: > > Arguments are supposed to be ordered high then low. > > > > Signed-off-by: Rikard Falkeborn > > --- > > Spotted while trying to add compile time checks of GENMASK arguments. > > Patch has only been compile tested. > > My feeling, personally, is that GENMASK() really isn't worth the pain > it causes. Can we instead get rid of this thing and just use easier > to understand and less error-prone hex masks please? > > I don't care what anyone else says, personally I'm going to stick with > using hex masks as I find them way easier to get right first time than > a problematical opaque macro - and I really don't want the effort of > finding out that I've got the arguments wrong when I build it. It's > just _way_ easier and less error prone to use a hex mask straight off. I agree, but there are already more than 8000 uses of this rather silly (and perhaps backwards argument order) macro in the kernel. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/2367894118ccee058ed451927412d7c1a33864bd.camel%40perches.com.
Re: [linux-sunxi] [PATCH 01/11] MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
On Wed, 2016-02-03 at 11:19 +1100, Julian Calaby wrote: > On Tue, Feb 2, 2016 at 9:27 PM, Chen-Yu Tsai wrote: > > Add an entry for X-Powers AXP family PMIC drivers and list myself > > as maintainer. [] > > diff --git a/MAINTAINERS b/MAINTAINERS [] > > @@ -11941,6 +11941,12 @@ F: include/linux/workqueue.h > > F: kernel/workqueue.c > > F: Documentation/workqueue.txt > > > > +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS > > +M: Chen-Yu Tsai > > +L: linux-ker...@vger.kernel.org > > +S: Maintained > > +N: axp[128] > > Should you list the files maintained and this list also? This "N:" pattern is kind of a wildcard. The difference between F: and N: is that git history is also used by default for files that match. There are no files in -next today that match "*axp8*" Dunno if this patchset added any. This matches: $ git ls-files | grep "axp[128]" Documentation/devicetree/bindings/mfd/axp20x.txt Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt arch/arm/boot/dts/axp152.dtsi arch/arm/boot/dts/axp209.dtsi arch/arm/boot/dts/axp22x.dtsi drivers/extcon/extcon-axp288.c drivers/iio/adc/axp288_adc.c drivers/input/misc/axp20x-pek.c drivers/mfd/axp20x.c drivers/power/axp20x_usb_power.c drivers/power/axp288_charger.c drivers/power/axp288_fuel_gauge.c drivers/regulator/axp20x-regulator.c include/linux/mfd/axp20x.h Are all these files appropriate? -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v6 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System
On Mon, 2015-03-16 at 20:01 +0100, LABBE Corentin wrote: [] > diff --git a/MAINTAINERS b/MAINTAINERS [] > @@ -10923,6 +10923,12 @@ L: linux...@kvack.org > S: Maintained > F: mm/zswap.c > > +ALLWINNER SECURITY SYSTEM > +M: Corentin Labbe > +L: linux-cry...@vger.kernel.org > +S: Maintained > +F: drivers/crypto/sunxi-ss/ Use alphabetic ordering for new sections please. Please place this section between: ALI1563 I2C DRIVER and ALPHA PORT -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator
On Tue, 2014-10-21 at 02:28 +0300, Vladimir Zapolskiy wrote:
> On 19.10.2014 17:16, LABBE Corentin wrote:
> > Add support for the Security System included in Allwinner SoC A20.
> > The Security System is a hardware cryptographic accelerator that support
> > AES/MD5/SHA1/DES/3DES/PRNG algorithms.
[]
> > diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-core.c
> > b/drivers/crypto/sunxi-ss/sunxi-ss-core.c
[]
> > + cr = clk_get_rate(ss->busclk);
> > + if (cr >= cr_ahb)
> > + dev_dbg(&pdev->dev, "Clock bus %lu (%lu MHz) (must be >=
> > %lu)\n",
> > + cr, cr / 100, cr_ahb);
> > + else
> > + dev_warn(&pdev->dev, "Clock bus %lu (%lu MHz) (must be >=
> > %lu)\n",
> > + cr, cr / 100, cr_ahb);
>
> See next comment.
>
> > + cr = clk_get_rate(ss->ssclk);
> > + if (cr <= cr_mod)
> > + if (cr < cr_mod)
> > + dev_info(&pdev->dev, "Clock ss %lu (%lu MHz) (must be
> > <= %lu)\n",
> > + cr, cr / 100, cr_mod);
> > + else
> > + dev_dbg(&pdev->dev, "Clock ss %lu (%lu MHz) (must be <=
> > %lu)\n",
> > + cr, cr / 100, cr_mod);
> > + else
> > + dev_warn(&pdev->dev, "Clock ss is at %lu (%lu MHz) (must be <=
> > %lu)\n",
> > + cr, cr / 100, cr_mod);
>
> The management of kernel log levels looks pretty strange. As far as I
> understand there is no error on any clock rate, I'd recommend to keep
> only one information message.
And if not, please add some braces.
> hash_init: initialize request context */
> > +int sunxi_hash_init(struct ahash_request *areq)
> > +{
> > + const char *hash_type;
> > + struct sunxi_req_ctx *op = ahash_request_ctx(areq);
> > +
> > + memset(op, 0, sizeof(struct sunxi_req_ctx));
> > +
> > + hash_type = crypto_tfm_alg_name(areq->base.tfm);
> > +
> > + if (strcmp(hash_type, "sha1") == 0)
> > + op->mode = SS_OP_SHA1;
> > + if (strcmp(hash_type, "md5") == 0)
> > + op->mode = SS_OP_MD5;
else if ?
> > + if (op->mode == 0)
> > + return -EINVAL;
maybe this?
if (!strcmp(hash_type, "sha1"))
op->mode = SS_OP_SHA1;
else if (!strcmp(hash_type, "md5"))
op->mode = SH_OP_MD5;
else
return -EINVAL;
> > +
> > + return 0;
> > +}
[]
> > +int sunxi_hash_update(struct ahash_request *areq)
> > +{
[]
> > + dev_dbg(ss->dev, "%s %s bc=%llu len=%u mode=%x bw=%u ww=%u",
> > + __func__, crypto_tfm_alg_name(areq->base.tfm),
> > + op->byte_count, areq->nbytes, op->mode,
> > + op->nbw, op->nwait);
dev_dbg statements generally don't need __func__ as
dynamic_debug can add it.
If you want to keep it, the most common output form for
__func__ is '"%s: ...", __func__'
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
