[<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