All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.