[PATCH linux dev-5.4 2/2] fsi: aspeed: Support cabled FSI
Andrew Jeffery
andrew at aj.id.au
Fri Mar 27 12:05:01 AEDT 2020
On Tue, 24 Mar 2020, at 21:55, Joel Stanley wrote:
> Some FSI development systems have internally routed FSI signals, and
> some have external cabled FSI. Software can detect which machine this is
> by reading a jumper GPIO, and also control which pins the signals are
> routed to through a mux GPIO.
>
> This attempts to find the GPIOs at probe time. If they are not present
> in the device tree the driver will not error and continue as before.
>
> The mux GPIO is owned by the FSI driver to ensure it is not modified at
> runtime. The jumper is freed to allow other software to inspect it's
> state.
>
> Signed-off-by: Joel Stanley <joel at jms.id.au>
> ---
> drivers/fsi/fsi-master-aspeed.c | 45 +++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/drivers/fsi/fsi-master-aspeed.c b/drivers/fsi/fsi-master-aspeed.c
> index f49742b310c2..3436805d590a 100644
> --- a/drivers/fsi/fsi-master-aspeed.c
> +++ b/drivers/fsi/fsi-master-aspeed.c
> @@ -13,6 +13,7 @@
> #include <linux/regmap.h>
> #include <linux/slab.h>
> #include <linux/iopoll.h>
> +#include <linux/gpio/consumer.h>
>
> #include "fsi-master.h"
>
> @@ -419,6 +420,44 @@ static int aspeed_master_init(struct
> fsi_master_aspeed *aspeed)
> return 0;
> }
>
> +static int tacoma_cabled_fsi_fixup(struct device *dev)
> +{
> + struct gpio_desc *routing_gpio, *mux_gpio;
> + int gpio;
> +
> + /*
> + * The routing GPIO is a jumper indicating we should mux for the
> + * externally routed FSI cable.
> + */
> + routing_gpio = devm_gpiod_get_optional(dev, "fsi-routing", GPIOD_IN);
> + if (IS_ERR(routing_gpio))
> + return PTR_ERR(routing_gpio);
> + if (!routing_gpio)
> + return 0;
> +
> + mux_gpio = devm_gpiod_get_optional(dev, "fsi-mux", GPIOD_IN);
> + if (IS_ERR(mux_gpio))
> + return PTR_ERR(mux_gpio);
> + if (!mux_gpio)
> + return 0;
This leaks routing_gpio.
> +
> + gpio = gpiod_get_value(routing_gpio);
> + if (gpio < 0)
> + return 0;
> +
> + /* If the routing GPIO is low we should set the mux to low. */
> + if (gpio == 0) {
> + gpiod_set_value(mux_gpio, 0);
> + dev_info(dev, "FSI configured for external cable\n");
> + }
Is mux_gpio pulled up? Also you're acquiring mux_gpio using the GPIOD_IN
flag - the dt patch only specifies GPIO_ACTIVE_HIGH which means its
implicitly push-pull, but we're not changing the direction before setting the
value.
I feel like we should explicitly set the value either way, or at least document
the pull-up state in a comment if the gpio is indeed pulled up.
> +
> + /* Free the cabled mux GPIO for other users to sample */
> + devm_gpiod_put(dev, routing_gpio);
The comment mentions "mux GPIO" but then does the put for routing_gpio.
I think you can improve the clarity of the comment to make it more obvious
that it's meant to apply to routing_gpio and it isn't a mistake in the code.
Can you also add to the comment why you're not putting mux_gpio?
> +
> + return 0;
> +}
> +
> +
> static int fsi_master_aspeed_probe(struct platform_device *pdev)
> {
> struct fsi_master_aspeed *aspeed;
> @@ -426,6 +465,12 @@ static int fsi_master_aspeed_probe(struct
> platform_device *pdev)
> int rc, links, reg;
> __be32 raw;
>
> + rc = tacoma_cabled_fsi_fixup(&pdev->dev);
> + if (rc) {
> + dev_err(&pdev->dev, "Tacoma FSI cable fixup failed\n");
> + return rc;
> + }
> +
> aspeed = devm_kzalloc(&pdev->dev, sizeof(*aspeed), GFP_KERNEL);
> if (!aspeed)
> return -ENOMEM;
> --
> 2.25.1
>
>
More information about the openbmc
mailing list