| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The original commit appears to have the logic reversed in
amd_fch_gpio_get_direction. Also confirmed by observing the value of
"direction" in the sys tree.
Signed-off-by: Ed Wildgoose <[email protected]>
Fixes: e09d168f13f0 ("gpio: AMD G-Series PCH gpio driver")
Cc: [email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
It's hard for occasional GPIO code reader/writer to know if values 0/1
equal to IN or OUT. Use defined GPIO_LINE_DIRECTION_IN and
GPIO_LINE_DIRECTION_OUT to help them out.
NOTE - for gpio-amd-fch and gpio-bd9571mwv:
This commit also changes the return value for direction get to equal 1
for direction INPUT. Prior this commit these drivers might have
returned some other positive value but 1 for INPUT.
Signed-off-by: Matti Vaittinen <[email protected]>
Acked-by: Scott Branden <[email protected]>
Reviewed-by: Grygorii Strashko <[email protected]>
Reviewed-by: Michal Simek <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Acked-by: William Breathitt Gray <[email protected]>
Acked-by: Kuppuswamy Sathyanarayanan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The struct resource field is statically initialized
and may never change. Therefore make it const.
Signed-off-by: Enrico Weigelt <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
The pointer to the struct platform_device in the driver's private
data struct is never used and therefore can be dropped.
Signed-off-by: Enrico Weigelt <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Current amd_fch_gpio_direction_output implementation ignores the value
argument, fix it so direction_output will set proper output level.
Signed-off-by: Axel Lin <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Sparse complains:
gpio-amd-fch.c:45:27: sparse: expected void *
gpio-amd-fch.c:45:27: sparse: got void [noderef] <asn:2> *
gpio-amd-fch.c:45:27: sparse: warning: incorrect type in return
expression (different address spaces)
gpio-amd-fch.c:56:9: sparse: expected void const volatile [noderef]
<asn:2> *addr
gpio-amd-fch.c:56:9: sparse: expected void volatile [noderef] <asn:2> *addr
gpio-amd-fch.c:56:9: sparse: got void *ptr
gpio-amd-fch.c:56:9: sparse: warning: incorrect type in argument 1 (different address spaces)
I think it is because void * is returned rather than void __iomem *,
so fix it up.
Cc: Enrico Weigelt <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The build servers and linux-next are complaining like this:
drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe':
drivers/gpio/gpio-amd-fch.c:164:49: warning: passing argument 2 of
'devm_ioremap_resource' discards 'const' qualifier from pointer
target type [-Wdiscarded-qualifiers]
priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores);
^~~~~~~~~~~~~~~~~~~
In file included from include/linux/platform_device.h:14, from
drivers/gpio/gpio-amd-fch.c:15:
include/linux/device.h:709:15: note: expected 'struct resource *'
but argument is of type 'const struct resource *'
void __iomem *devm_ioremap_resource(struct device *dev,struct resource *res);
^~~~~~~~~~~~~~~~~~~~~
Let's just remove "const" for now.
It is possible that devm_ioremap_resource() should rather
be constified so we can pass const resources as arguments.
But right now I just want to get rid of this build warning.
Fixes: e09d168f13f0 ("gpio: AMD G-Series PCH gpio driver")
Reported-by: Stephen Rothwell <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Reported-by: Anders Roxell <[email protected]>
Cc: Enrico Weigelt <[email protected]>
Tested-by: Anders Roxell <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
GPIO platform driver for the AMD G-series PCH (eg. on GX-412TC)
This driver doesn't registers itself automatically, as it needs to
be provided with platform specific configuration, provided by some
board driver setup code.
Didn't implement oftree probing yet, as it's rarely found on x86.
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|