linux-kernel - Re: [PATCH 1/2 v5] regmap: Support accelerated noinc operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yw46t9Y1PYoMLSKq@smile.fi.intel.com>
Date:   Tue, 30 Aug 2022 19:28:39 +0300
From:   Andy Shevchenko <andriy.shevchenko@...el.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2 v5] regmap: Support accelerated noinc operations

On Tue, Aug 16, 2022 at 10:48:31PM +0200, Linus Walleij wrote:
> Several architectures have accelerated operations for MMIO
> operations writing to a single register, such as writesb, writesw,
> writesl, writesq, readsb, readsw, readsl and readsq but regmap
> currently cannot use them because we have no hooks for providing
> an accelerated noinc back-end for MMIO.
> 
> Solve this by providing reg_[read/write]_noinc callbacks for
> the bus abstraction, so that the regmap-mmio bus can use this.
> 
> Currently I do not see a need to support this for custom regmaps
> so it is only added to the bus.
> 
> Callbacks are passed a void * with the array of values and a
> count which is the number of items of the byte chunk size for
> the specific register width.

I see these applied, but consider below for the possible followups.

...

> +			ret = regcache_write(map, reg, lastval);
> +			if (ret != 0)

if (ret) ?

> +				return ret;

...

> +		dev_info(map->dev, "%x %s [", reg, write ? "<=" : "=>");
> +		for (i = 0; i < val_len; i++) {
> +			switch (val_bytes) {
> +			case 1:
> +				pr_cont("%x", u8p[i]);
> +				break;
> +			case 2:
> +				pr_cont("%x", u16p[i]);
> +				break;
> +			case 4:
> +				pr_cont("%x", u32p[i]);
> +				break;
> +#ifdef CONFIG_64BIT
> +			case 8:
> +				pr_cont("%llx", u64p[i]);
> +				break;
> +#endif
> +			default:
> +				break;
> +			}
> +			if (i == (val_len - 1))
> +				pr_cont("]\n");
> +			else
> +				pr_cont(",");
> +		}

I'm wondering why we can't use hex_dump_to_buffer() approach? Or even better,
introduce eventually dev_hex_dump() (as it's done for seq_file and printk)
and use it.

-- 
With Best Regards,
Andy Shevchenko