| Message ID | 20240318193410.178163-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next,v1,1/1] can: mcp251x: Fix up includes | expand |
Mon, Mar 18, 2024 at 08:34:10PM CET, andriy.shevchenko@linux.intel.com wrote: >This driver is including the legacy GPIO header <linux/gpio.h> >but the only thing it is using from that header is the wrong >define for GPIOF_DIR_OUT. > >Fix it up by using GPIO_LINE_DIRECTION_* macros respectively. > >Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> net-next is closed, send again next week.
On 18.03.2024 21:34:10, Andy Shevchenko wrote: > This driver is including the legacy GPIO header <linux/gpio.h> > but the only thing it is using from that header is the wrong > define for GPIOF_DIR_OUT. > > Fix it up by using GPIO_LINE_DIRECTION_* macros respectively. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> No need to resend, added to linux-can-next. Thanks, Marc
On Tue, Mar 19, 2024 at 11:25:19AM +0100, Jiri Pirko wrote: > Mon, Mar 18, 2024 at 08:34:10PM CET, andriy.shevchenko@linux.intel.com wrote: > >This driver is including the legacy GPIO header <linux/gpio.h> > >but the only thing it is using from that header is the wrong > >define for GPIOF_DIR_OUT. > > > >Fix it up by using GPIO_LINE_DIRECTION_* macros respectively. > > net-next is closed, send again next week. Thank you for the reminder. I have a question though. Can net adapt to the existence of lore.kernel.org please? I mean it's not big deal to me to resend, but: 1) it adds too much noise in already noisy mailing lists; 2) it brings no value since we have lore.kernel.org archive; 3) last but not least, it saves a lot of resources and becomes environment friendly when we send _less_ emails.
On Tue, Mar 19, 2024 at 03:25:24PM +0100, Marc Kleine-Budde wrote: > On 18.03.2024 21:34:10, Andy Shevchenko wrote: > > This driver is including the legacy GPIO header <linux/gpio.h> > > but the only thing it is using from that header is the wrong > > define for GPIOF_DIR_OUT. > > > > Fix it up by using GPIO_LINE_DIRECTION_* macros respectively. > No need to resend, added to linux-can-next. Thank you for taking care, although it doesn't cancel my question to the net subsystem flow in general.
diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c index 79c4bab5f724..643974b3f329 100644 --- a/drivers/net/can/spi/mcp251x.c +++ b/drivers/net/can/spi/mcp251x.c @@ -28,7 +28,6 @@ #include <linux/device.h> #include <linux/ethtool.h> #include <linux/freezer.h> -#include <linux/gpio.h> #include <linux/gpio/driver.h> #include <linux/interrupt.h> #include <linux/io.h> @@ -482,9 +481,9 @@ static int mcp251x_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) { if (mcp251x_gpio_is_input(offset)) - return GPIOF_DIR_IN; + return GPIO_LINE_DIRECTION_IN; - return GPIOF_DIR_OUT; + return GPIO_LINE_DIRECTION_OUT; } static int mcp251x_gpio_get(struct gpio_chip *chip, unsigned int offset)
This driver is including the legacy GPIO header <linux/gpio.h> but the only thing it is using from that header is the wrong define for GPIOF_DIR_OUT. Fix it up by using GPIO_LINE_DIRECTION_* macros respectively. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/net/can/spi/mcp251x.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)