On Tue, 01 Jun 2021, Robert Marko wrote: > On Tue, Jun 1, 2021 at 10:19 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote: > > > > On Mon, 31 May 2021, Robert Marko wrote: > > > > > On Wed, May 26, 2021 at 9:52 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote: > > > > > > > > On Tue, 25 May 2021, Robert Marko wrote: > > > > > > > > > On Tue, May 25, 2021 at 9:46 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Mon, 24 May 2021, Rob Herring wrote: > > > > > > > > > > > > > On Mon, May 24, 2021 at 02:05:38PM +0200, Robert Marko wrote: > > > > > > > > Add binding documents for the Delta TN48M CPLD drivers. > > > > > > > > > > > > > > > > Signed-off-by: Robert Marko <robert.marko@xxxxxxxxxx> > > > > > > > > --- > > > > > > > > Changes in v2: > > > > > > > > * Implement MFD as a simple I2C MFD > > > > > > > > * Add GPIO bindings as separate > > > > > > > > > > > > > > I don't understand why this changed. This doesn't look like an MFD to > > > > > > > me. Make your binding complete if there are missing functions. > > > > > > > Otherwise, stick with what I already ok'ed. > > > > > > > > > > > > Right. What else, besides GPIO, does this do? > > > > > > > > > > It currently does not do anything else as hwmon driver was essentially > > > > > NACK-ed for not exposing standard attributes. > > > > > > > > Once this provides more than GPIO capabilities i.e. becomes a proper > > > > Multi-Function Device, then it can use the MFD framework. Until then, > > > > it's a GPIO device I'm afraid. > > > > > > > > Are you going to re-author the HWMON driver to conform? > > > hwmon cannot be reathored as it has no standard hwmon attributes. > > > > > > > > > > > > The CPLD itself has PSU status-related information, bootstrap related > > > > > information, > > > > > various resets for the CPU-s, OOB ethernet PHY, information on the exact board > > > > > model it's running etc. > > > > > > > > > > PSU and model-related info stuff is gonna be exposed via a misc driver > > > > > in debugfs as > > > > > we have user-space SW depending on that. > > > > > I thought we agreed on that as v1 MFD driver was exposing those directly and > > > > > not doing anything else. > > > > > > > > Yes, we agreed that creating an MFD driver just to expose chip > > > > attributes was not an acceptable solution. > > > > > > > > > So I moved to use the simple I2C MFD driver, this is all modeled on the sl28cpld > > > > > which currently uses the same driver and then GPIO regmap as I do. > > > > > > > > > > Other stuff like the resets is probably gonna get exposed later when > > > > > it's required > > > > > to control it directly. > > > > > > > > In order for this driver to tick the MFD box, it's going to need more > > > > than one function. > > > > > > Understood, would a debug driver count or I can expose the resets via > > > a reset driver > > > as we have a future use for them? > > > > CPLDs and FPGAs are funny ones and are often difficult to support in > > Linux. Especially if they can change their behaviour. > > > > It's hard to make a solid suggestion as to how your device is handled > > without knowing the intricacies of the device. > > Yeah, I understand. > This one is a generic CPLD used in multiple switch models, however in this > switch model, it has the smallest set of features. > Things that are usable for the kernel and userspace it provides are SFP pins, > resets and debug information. > Debug information is quite detailed actually. > > I have added the reset driver in v3 as that is something that was gonna get > added later as well as it exposes resets for the ethernet PHY-s and U-boot > messes with the OOB PHY configuration. > > > > > Why do you require one single Regmap anyway? Are they register banks > > not neatly separated on a per-function basis? > > For GPIO and reset drivers, I could get away with each of them > registering a regmap > but the debug driver will require accessing certain registers from their space. > Also, I see using a single regmap that is provided by a generic driver > much simpler and cleaner than doing that in each of the child drivers. Obviously not. :) -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
