linux-kernel - Re: [PATCH 4/6] spi: altera: use regmap instead of direct mmio register access

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: <20200612123115.GA8653@yilunxu-OptiPlex-7050>
Date:   Fri, 12 Jun 2020 20:31:15 +0800
From:   Xu Yilun <yilun.xu@...el.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
        trix@...hat.com, hao.wu@...el.com, matthew.gerlach@...ux.intel.com,
        russell.h.weight@...el.com
Subject: Re: [PATCH 4/6] spi: altera: use regmap instead of direct mmio
  register access

On Fri, Jun 12, 2020 at 12:52:02PM +0100, Mark Brown wrote:
> On Fri, Jun 12, 2020 at 12:43:46PM +0800, Xu Yilun wrote:
> 
> > So we think of creating regmap to abstract the actually register accessing
> > detail. The parent device driver creates the regmap of indirect access,
> > and it creates the spi-altera platform device as child. Spi-altera
> > driver could just get the regmap from parent, don't have to care about
> > the indirect access detail.
> 
> To be clear there's absolutely no problem with the end result, my
> concern is the way that we're getting there.
> 
> > It seems your concern is how to gracefully let spi-altera driver get the
> > regmap. or not using it. Since our platform doesn't enable device tree
> > support, seems the only way to talk to platform device is the
> > platform_data.
> 
> No, the problem is with how that platform data is structured.  Based on
> what you're saying I'd suggest adding another device ID for this - you
> can use the id_table field in struct platform_driver to have more than
> one ID like you can have more than one ACPI ID or OF compatible.  That
> would mirror how this would be handled if things were enumerated through
> firmware.

Thanks for your quick response. It's very clear and makes sense. I'll
change it.

> 
> > I think the driver may need to figure out the role of the device in
> > system, whether it is a subdev of other device (like MFD? Many mfd subdev
> > driver will get parent regmap by default), or it is an independent mmio
> > device. But I'm not sure how to do it in right way.
> 
> Yes, it sounds like this card is a MFD.