From: Linus Walleij <linus.walleij@linaro.org> To: Sven Van Asbroeck <thesven73@gmail.com>, Arnd Bergmann <arnd@arndb.de> Cc: svendev@arcx.com, "Lee Jones" <lee.jones@linaro.org>, "Rob Herring" <robh+dt@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Andreas Färber" <afaerber@suse.de>, "Thierry Reding" <treding@nvidia.com>, "David Lechner" <david@lechnology.com>, "Noralf Trønnes" <noralf@tronnes.org>, "Johan Hovold" <johan@kernel.org>, "Michal Simek" <monstr@monstr.eu>, michal.vokac@ysoft.com, "Greg KH" <gregkh@linuxfoundation.org>, john.garry@huawei.com, "Geert Uytterhoeven" <geert+renesas@glider.be>, "Robin Murphy" <robin.murphy@arm.com>, "Paul Gortmaker" <paul.gortmaker@windriver.com>, "Sebastien Bourdelin" <sebastien.bourdelin@savoirfairelinux.com>, "Icenowy Zheng" <icenowy@aosc.io>, "Stuart Yoder" <stuyoder@gmail.com>, "Maxime Ripard" <maxime.ripard@bootlin.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org> Subject: Re: [PATCH anybus v2 1/5] misc: support the Arcx anybus bridge. Date: Thu, 1 Nov 2018 00:15:25 +0100 [thread overview] Message-ID: <CACRpkdai-6iNbz4EGuHNHkQYyR+yhTEJdRXP4G6fUKpA+XApjQ@mail.gmail.com> (raw) In-Reply-To: <20181031194425.32132-2-TheSven73@googlemail.com> Hi Sven, On Wed, Oct 31, 2018 at 8:44 PM <thesven73@gmail.com> wrote: > From: Sven Van Asbroeck <svendev@arcx.com> > > Add a driver for the Arcx anybus bridge. > > This chip embeds up to two Anybus-S application connectors > (slots), and connects to the SoC via a parallel memory bus. > There is also a CAN power readout, unrelated to the Anybus. > > Signed-off-by: Sven Van Asbroeck <svendev@arcx.com> This is fun :) > drivers/misc/Kconfig | 9 ++ > drivers/misc/Makefile | 1 + > drivers/misc/anybus-bridge.c | 301 +++++++++++++++++++++++++++++++++++ I would put this also in drivers/bus, why not. Just two files there. It's a bus bridge for sure, we keep them there. drivers/reset if it is mostly about resetting stuff. > +config ARCX_ANYBUS_BRIDGE > + tristate "Arcx Anybus-S Bridge" > + depends on OF depends on GPIOLIB > + help > + Select this to get support for the Arcx Anybus bridge. > + It connects to the SoC via a parallel memory bus, and > + embeds up to two Anybus-S application connectors (slots). > + There is also a CAN power readout, unrelated to the Anybus. (...) > +#include <linux/gpio.h> > +#include <linux/of_gpio.h> Don't use these please. Juse use #include <linux/gpio/consumer.h> > +struct bridge_priv { > + struct device *class_dev; > + struct reset_controller_dev rcdev; > + bool common_reset; > + int reset_gpio; struct gpio_desc *reset_gpiod; > + void __iomem *cpld_base; > + spinlock_t regs_lock; > + u8 control_reg; > + char version[3]; > + u16 design_no; (...) > +static ssize_t version_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct bridge_priv *cd = dev_get_drvdata(dev); > + > + return sprintf(buf, "%s\n", cd->version); > +} > +static DEVICE_ATTR_RO(version); Do you need this in userspace really? > +static ssize_t design_number_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct bridge_priv *cd = dev_get_drvdata(dev); > + > + return sprintf(buf, "%d\n", cd->design_no); > +} > +static DEVICE_ATTR_RO(design_number); And this? > +static ssize_t can_power_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct bridge_priv *cd = dev_get_drvdata(dev); > + > + return sprintf(buf, "%d\n", > + !(readb(cd->cpld_base + CPLD_STATUS1) & > + CPLD_STATUS1_CAN_POWER)); > +} > +static DEVICE_ATTR_RO(can_power); This should certainly be reflected as a fixed-voltage regulator and not a random integer in sysfs. > +static int bridge_probe(struct platform_device *pdev) > +{ > + struct bridge_priv *cd; > + struct device *dev = &pdev->dev; > + struct device_node *np = dev->of_node; > + int err, id; > + struct resource *res; > + u8 status1, cap; > + > + cd = devm_kzalloc(dev, sizeof(*cd), GFP_KERNEL); > + if (!cd) > + return -ENOMEM; > + dev_set_drvdata(dev, cd); > + spin_lock_init(&cd->regs_lock); This: > + cd->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0); > + if (!gpio_is_valid(cd->reset_gpio)) { > + dev_err(dev, "reset-gpios not found\n"); > + return -EINVAL; > + } > + devm_gpio_request(dev, cd->reset_gpio, NULL); > + gpio_direction_output(cd->reset_gpio, 0); Should be: cd->reset_gpiod = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW); if (IS_ERR(cd->reset_gpiod)) return PTR_ERR(cd->reset_gpiod); You can turn it to input as you do in the .remove() function to let a pull-up resistor pull it high, but isn't it better to actively just drive it high? Yours, Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org> To: Sven Van Asbroeck <thesven73@gmail.com>, Arnd Bergmann <arnd@arndb.de> Cc: svendev@arcx.com, "Lee Jones" <lee.jones@linaro.org>, "Rob Herring" <robh+dt@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Andreas Färber" <afaerber@suse.de>, "Thierry Reding" <treding@nvidia.com>, "David Lechner" <david@lechnology.com>, "Noralf Trønnes" <noralf@tronnes.org>, "Johan Hovold" <johan@kernel.org>, "Michal Simek" <monstr@monstr.eu>, michal.vokac@ysoft.com, "Greg KH" <gregkh@linuxfoundation.org>, john.garry@huawei.com, "Geert Uytterhoeven" <geert+renesas@glider.be>, "Robin Murphy" <robin.murphy@arm.com>, "Paul Gortmaker" <paul.gortmaker@windriver.com>, "Sebastien Bourdelin" <sebastien.bourdelin@savoirfairelinux.com>, "Icenowy Zheng" <icenowy@aosc.io>, "Stuart Yoder" <stuyoder@gmail.com>, "Maxime Ripard" <maxime.ripard@bootlin.com> Subject: Re: [PATCH anybus v2 1/5] misc: support the Arcx anybus bridge. Date: Thu, 1 Nov 2018 00:15:25 +0100 [thread overview] Message-ID: <CACRpkdai-6iNbz4EGuHNHkQYyR+yhTEJdRXP4G6fUKpA+XApjQ@mail.gmail.com> (raw) In-Reply-To: <20181031194425.32132-2-TheSven73@googlemail.com> Hi Sven, On Wed, Oct 31, 2018 at 8:44 PM <thesven73@gmail.com> wrote: > From: Sven Van Asbroeck <svendev@arcx.com> > > Add a driver for the Arcx anybus bridge. > > This chip embeds up to two Anybus-S application connectors > (slots), and connects to the SoC via a parallel memory bus. > There is also a CAN power readout, unrelated to the Anybus. > > Signed-off-by: Sven Van Asbroeck <svendev@arcx.com> This is fun :) > drivers/misc/Kconfig | 9 ++ > drivers/misc/Makefile | 1 + > drivers/misc/anybus-bridge.c | 301 +++++++++++++++++++++++++++++++++++ I would put this also in drivers/bus, why not. Just two files there. It's a bus bridge for sure, we keep them there. drivers/reset if it is mostly about resetting stuff. > +config ARCX_ANYBUS_BRIDGE > + tristate "Arcx Anybus-S Bridge" > + depends on OF depends on GPIOLIB > + help > + Select this to get support for the Arcx Anybus bridge. > + It connects to the SoC via a parallel memory bus, and > + embeds up to two Anybus-S application connectors (slots). > + There is also a CAN power readout, unrelated to the Anybus. (...) > +#include <linux/gpio.h> > +#include <linux/of_gpio.h> Don't use these please. Juse use #include <linux/gpio/consumer.h> > +struct bridge_priv { > + struct device *class_dev; > + struct reset_controller_dev rcdev; > + bool common_reset; > + int reset_gpio; struct gpio_desc *reset_gpiod; > + void __iomem *cpld_base; > + spinlock_t regs_lock; > + u8 control_reg; > + char version[3]; > + u16 design_no; (...) > +static ssize_t version_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct bridge_priv *cd = dev_get_drvdata(dev); > + > + return sprintf(buf, "%s\n", cd->version); > +} > +static DEVICE_ATTR_RO(version); Do you need this in userspace really? > +static ssize_t design_number_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct bridge_priv *cd = dev_get_drvdata(dev); > + > + return sprintf(buf, "%d\n", cd->design_no); > +} > +static DEVICE_ATTR_RO(design_number); And this? > +static ssize_t can_power_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct bridge_priv *cd = dev_get_drvdata(dev); > + > + return sprintf(buf, "%d\n", > + !(readb(cd->cpld_base + CPLD_STATUS1) & > + CPLD_STATUS1_CAN_POWER)); > +} > +static DEVICE_ATTR_RO(can_power); This should certainly be reflected as a fixed-voltage regulator and not a random integer in sysfs. > +static int bridge_probe(struct platform_device *pdev) > +{ > + struct bridge_priv *cd; > + struct device *dev = &pdev->dev; > + struct device_node *np = dev->of_node; > + int err, id; > + struct resource *res; > + u8 status1, cap; > + > + cd = devm_kzalloc(dev, sizeof(*cd), GFP_KERNEL); > + if (!cd) > + return -ENOMEM; > + dev_set_drvdata(dev, cd); > + spin_lock_init(&cd->regs_lock); This: > + cd->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0); > + if (!gpio_is_valid(cd->reset_gpio)) { > + dev_err(dev, "reset-gpios not found\n"); > + return -EINVAL; > + } > + devm_gpio_request(dev, cd->reset_gpio, NULL); > + gpio_direction_output(cd->reset_gpio, 0); Should be: cd->reset_gpiod = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW); if (IS_ERR(cd->reset_gpiod)) return PTR_ERR(cd->reset_gpiod); You can turn it to input as you do in the .remove() function to let a pull-up resistor pull it high, but isn't it better to actively just drive it high? Yours, Linus Walleij
next prev parent reply other threads:[~2018-10-31 23:15 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-31 19:44 [PATCH anybus v2 0/5] Support HMS Profinet Card over Anybus thesven73 2018-10-31 19:44 ` [PATCH anybus v2 1/5] misc: support the Arcx anybus bridge thesven73 2018-10-31 23:15 ` Linus Walleij [this message] 2018-10-31 23:15 ` Linus Walleij 2018-11-01 17:17 ` Sven Van Asbroeck 2018-11-01 21:53 ` Linus Walleij 2018-11-01 21:53 ` Linus Walleij 2018-11-02 14:16 ` Sven Van Asbroeck 2018-10-31 19:44 ` [PATCH anybus v2 2/5] dt-bindings: anybus-bridge: document devicetree binding thesven73 2018-10-31 23:29 ` Andreas Färber 2018-10-31 19:44 ` [PATCH anybus v2 3/5] bus: support HMS Anybus-S bus thesven73 2018-11-15 0:19 ` kbuild test robot 2018-10-31 19:44 ` [PATCH anybus v2 4/5] dt-bindings: anybuss-host: document devicetree binding thesven73 2018-10-31 19:44 ` [PATCH anybus v2 5/5] misc: support HMS Profinet IRT industrial controller thesven73 2018-11-01 16:03 ` kbuild test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACRpkdai-6iNbz4EGuHNHkQYyR+yhTEJdRXP4G6fUKpA+XApjQ@mail.gmail.com \ --to=linus.walleij@linaro.org \ --cc=afaerber@suse.de \ --cc=arnd@arndb.de \ --cc=david@lechnology.com \ --cc=devicetree@vger.kernel.org \ --cc=geert+renesas@glider.be \ --cc=gregkh@linuxfoundation.org \ --cc=icenowy@aosc.io \ --cc=johan@kernel.org \ --cc=john.garry@huawei.com \ --cc=lee.jones@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@bootlin.com \ --cc=michal.vokac@ysoft.com \ --cc=monstr@monstr.eu \ --cc=noralf@tronnes.org \ --cc=paul.gortmaker@windriver.com \ --cc=robh+dt@kernel.org \ --cc=robin.murphy@arm.com \ --cc=sebastien.bourdelin@savoirfairelinux.com \ --cc=stuyoder@gmail.com \ --cc=svendev@arcx.com \ --cc=thesven73@gmail.com \ --cc=treding@nvidia.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.