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] [day] [month] [year] [list]
Message-ID: <20220319001355.GB929848@euler>
Date:   Fri, 18 Mar 2022 17:13:55 -0700
From:   Colin Foster <colin.foster@...advantage.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC v1 0/2] Add more detailed regmap formatting capabilities

On Fri, Mar 18, 2022 at 08:57:54PM +0000, Mark Brown wrote:
> On Sun, 13 Mar 2022 15:45:22 -0700, Colin Foster wrote:
> > The Ocelot chips (specifically the VSC7512 I'm using) have a method of
> > accessing their registers internally via MMIO, or externally via SPI.
> > When accessing these registers externally, a 24-bit address is used and
> > downshifted by two. The manual references it as:
> > 
> > SI_ADDR = (REG_ADDR & 0x00FFFFFF) >> 2;
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
> 
> Thanks!
> 
> [1/2] regmap: add configurable downshift for addresses
>       commit: 86fc59ef818beb0e1945d17f8e734898baba7e4e
> [2/2] regmap: allow a defined reg_base to be added to every address
>       commit: 0074f3f2b1e43d3cedd97e47fb6980db6d2ba79e
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.

Thanks Mark! Based on your initial feedback I wasn't expecting patch 1
to be applied and was expecting to have to work around it (which could
be done) but I don't think patch 2 could have been reasonably worked
around. Hopefully these are patches that nobody notices... unless they
need them too :-D

> 
> Thanks,
> Mark

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ