t?
This is one of those cases where I would suggest collect ACKs
from affected subsystem maintainers and send a pull request
to the SoC tree for this hairy bundle.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverde
and shall be removed from here.
>
> Signed-off-by: Sergio Paracuellos
Acked-by: Linus Walleij
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
merge window.
Applied patches 1-7 to the pinctrl tree, patch 8 needs to be sent
to Greg.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
merge window.
Reviewed-by: Linus Walleij
If Greg wants he can queue them last minute. Else I'll apply these
after the merge window, no big deal.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverpr
h 1 (which I will eventually apply directly anyway).
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi Serigio,
I dug around some to try to understand the patch I think I get
it now :)
Squash this with the third patch so it becomes a
"move" of this file, preserving history. With that:
Acked-by: Linus Walleij
I have ideas, but it is better to move the driver out
of staging and imp
description: function...
enum: [gpio, i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2,
mdio, nand1, nand2, sdhci]
Note: the function names are fine but the group names are a bit
confusion since often a group can be used for more than one
function, and e.g.
function = "i2c&q
x27;s move it to my subsystem before the merge window
if there is time. I'll provide ACK.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Mon, Dec 7, 2020 at 2:57 PM Sergio Paracuellos
wrote:
> On Mon, Dec 7, 2020 at 2:05 PM Linus Walleij wrote:
> > After this I think the driver looks good and can graduate from staging.
> > Can you send a patch to move this to drivers/pinctrl next
> >
> > I think dri
ry pin between
> gpio node and pinctrl node and we can stop using the deprecated
> pinctrl_add_gpio_range() function.
>
> Signed-off-by: Sergio Paracuellos
Reviewed-by: Linus Walleij
After this I think the driver looks good and can graduate from staging.
Can you send a patch to m
-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebased on v5.9-rc1
---
.../media/atomisp/i2c/atomisp-lm3554.c| 68 ---
.../media/atomisp/include/media/lm3554.h | 7 +-
2 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atom
This makes the driver use the irqchip template to assign
properties to the gpio_irq_chip instead of using the
explicit calls to gpiochip_irqchip_add(). The irqchip is
instead added while adding the gpiochip.
Cc: Nishad Kamdar
Cc: Johan Hovold
Signed-off-by: Linus Walleij
---
drivers/staging
gt;;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v4->v5:
- Make the wakeup GPIO optional.
ChangeLog v3->v4:
- Finally figured out how to compile this by selecting SPI
host and deselecting MMC host.
- Initialize the reset GPIO as OUT_LOW
- Initialize the wakeup GPIO as
gt;;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- Finally figured out how to compile this by selecting SPI
host and deselecting MMC host.
- Initialize the reset GPIO as OUT_LOW
- Initialize the wakeup GPIO as OUT_LOW
- Drop one more desc_to_gpio()
- Update
On Sun, Jun 28, 2020 at 12:43 PM Greg KH wrote:
> On Sun, Jun 28, 2020 at 10:52:36AM +0200, Linus Walleij wrote:
> > ChangeLog v2->v3:
> > - ERR_CAST not PTR_CAST
> > ChangeLog v1->v2:
> > - Fixed a cast and a variable name.
> > - I still don't
gt;;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- ERR_CAST not PTR_CAST
ChangeLog v1->v2:
- Fixed a cast and a variable name.
- I still don't know how to compile this but hey the zeroday
robot does.
---
drivers/staging/wfx/bus_spi.c | 11
gt;;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Fixed a cast and a variable name.
- I still don't know how to compile this but hey the zeroday
robot does.
---
drivers/staging/wfx/bus_spi.c | 11 +
drivers/staging/wfx/main.c| 42 --
-by: Linus Walleij
---
.../media/atomisp/i2c/atomisp-lm3554.c| 68 ---
.../media/atomisp/include/media/lm3554.h | 7 +-
2 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp
gt;;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
drivers/staging/wfx/bus_spi.c | 11 +
drivers/staging/wfx/main.c| 42 ---
drivers/staging/wfx/main.h| 2 --
3 files changed, 9 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/w
On Tue, Jan 7, 2020 at 10:31 AM Bartosz Golaszewski
wrote:
> wt., 7 sty 2020 o 10:29 Linus Walleij napisał(a):
> > > Ugh, I now noticed I responded to Thierry only after applying this to my
> > > tree.
> > >
> > > Anyway, it shouldn't be a proble
On Tue, Jan 7, 2020 at 9:25 AM Bartosz Golaszewski
wrote:
> pon., 6 sty 2020 o 23:59 Linus Walleij napisał(a):
> > On Sun, Dec 15, 2019 at 7:31 PM Dmitry Osipenko wrote:
> >
> > > I was investigating why CPU hangs during of GPIO driver suspend and in
> > > t
ritel_relaxed accessors
> gpio: tegra: Properly handle irq_set_irq_wake() error
> gpio: tegra: Use NOIRQ phase for suspend/resume
All three patches applied with Thierry's review/test tag.
Yours,
Linus Walleij
___
devel mai
clarifying why ^= SPI_CS_HIGH is the right
choice here.
Reported-by: Mark Brown
Signed-off-by: Linus Walleij
---
drivers/staging/fbtft/fb_uc1611.c| 12 +---
drivers/staging/fbtft/fb_watterott.c | 13 ++---
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers
y: Janusz Krzysztofik
Patch applied with Marek's Tested-by.
Thanks to both of you for digging in and fixing this up!
Now we are in good shape for the v4.20 cycle :)
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
l speed up processing of applications
> using whole GPIO banks as I/O ports, while not breaking simultaneous
> manipulation of consecutive pins of the same chip which don't follow
> the equal numbering rule.
>
> Cc: Jonathan Corbet
> Signed-off-by: Janusz Krzysztofik
Patch
already processed via fast bitmap path, possibly resulting in an
> infinite loop. Fix it.
>
> Signed-off-by: Janusz Krzysztofik
Patch applied!
Thanks for working on getting this into shape!
Yours,
Linus Walleij
___
devel mailing list
de
for testing on this platform!
> Booting hangs after detecting MMC cards. Reverting this patch fixes the
> boot. I will try later to add some debugs and investigate it further what
> really happens when booting hangs.
How typical. I hope we can fix it, because this should mean speedups
for
On Thu, Sep 13, 2018 at 2:22 AM Linus Walleij wrote:
> On Wed, Sep 5, 2018 at 11:49 PM Janusz Krzysztofik
> wrote:
>
> > The goal is to boost performance of get/set array functions while
> > processing GPIO arrays which represent pins of a signle chip in
> > ha
really excited to merge this!
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
e I should move forward
with my plan to send a sed script to Torvalds just renaming all
of those to something sane in the next merge window.
Like __assign_bit() -> assign_bit_nonatomic()
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverpr
lon
> who suggested using GPIO API modified to accept bitmaps, and by Linus
> Walleij who suggested still more great ideas for further immprovement
> of the proposed API changes - thanks!
>
> The goal is to boost performans of get/set array functions while
> processing GPIO arrays whi
remove
> as the reference was fetched in probe function.
> Updated the TODO file
>
> Signed-off-by: Ajay Singh
Reviewed-by: Linus Walleij
Thanks Ajay!
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverde
uot;wide".
I changed it while applying the patch.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Thu, Jul 5, 2018 at 3:43 PM Sergio Paracuellos
wrote:
> Add a devicetree binding documentation for the mt7621 gpio.
>
> Signed-off-by: Sergio Paracuellos
> Reviewed-by: NeilBrown
Patch applied with Rob's review tag.
You
On Thu, Jun 14, 2018 at 4:33 PM, Rob Herring wrote:
> On Thu, Jun 14, 2018 at 8:14 AM, Linus Walleij
> wrote:
>> On Wed, Jun 13, 2018 at 9:28 PM, Rob Herring wrote:
>>
>>>> "Some system-on-chips (SoCs) use the concept of GPIO banks. ...
>>>> Usual
"aha, it is mediatek,mt7321-gpio, so it has 3x32 GPIOs
indexed from 0..95".
No need of overspecifying stuff.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
h as it is already.
Better in that case to concatenate the offsets and instead of
having an extra cell 0, 1 and offsets 0-31, 0-31
have two cells and offsets 0-63.
My reasoning is that since it is represented by a single device
we are indexing into that one device from 0-n.
Yours,
Linus Walle
A second thought:
On Fri, Jun 8, 2018 at 1:59 PM, Linus Walleij wrote:
>> + select GPIOLIB_IRQCHIP
>
> You are not using this so I guess remove that line.
(...)
>> +static int
>> +mediatek_gpio_to_irq(struct gpio_chip *chip, unsigned int pin)
>> +{
>>
not? Can't be that hard
now that you fixed everything else!
> +static struct irq_chip mediatek_gpio_irq_chip = {
> + .name = "GPIO",
> + .irq_unmask = mediatek_gpio_irq_unmask,
> + .irq_mask = mediatek_gpio_irq_mask,
> +
On Thu, Apr 19, 2018 at 1:01 PM, Marc Dietrich wrote:
> Use GPIO descriptors instead of relying on the old method.
>
> Cc: Linus Walleij
> Signed-off-by: Marc Dietrich
> ---
> This obsolets the ToDo reminder sent by Linus a few hours ago.
Awesome :)
Reviewed-by: Linus Wall
To make sure that these drivers do not leave staging before they
are properly converted to use the new GPIO descriptor API, and the
GPIOLIB_IRQCHIP helper library, create the TODO file with these work
items.
Cc: Johan Hovold
Signed-off-by: Linus Walleij
---
I started some work in this area
GPIO drivers should include only, the
header is deprecated.
Cc: John Crispin
Cc: Zhiyong Tao
Cc: Sean Wang
Signed-off-by: Linus Walleij
---
I was philosophizing whether pinctrl/mediatek/pinctrl-mt7622 is
similar to this and can drive also the mt7621 but what do I know.
Sean can you have a
To make sure that this driver does not leave staging before it
is properly converted to use the new GPIO descriptor API,
augment the TODO file with this work item.
Cc: Andres Salomon
Cc: Jens Frederich
Signed-off-by: Linus Walleij
---
drivers/staging/olpc_dcon/TODO | 4
1 file changed, 4
To make sure that this driver does not leave staging before it
is properly converted to use the new GPIO descriptor API,
augment the TODO file with this work item.
Cc: Johnny Kim
Cc: Nicolas Ferre
Signed-off-by: Linus Walleij
---
drivers/staging/wilc1000/TODO | 4
1 file changed, 4
To make sure that this driver does not leave staging before it
is properly converted to use the new GPIO descriptor API,
augment the TODO file with this work item.
Cc: Marc Dietrich
Signed-off-by: Linus Walleij
---
drivers/staging/nvec/TODO | 5 +
1 file changed, 5 insertions(+)
diff
To make sure that these drivers do not leave staging before they
are properly converted to use the new GPIO descriptor API, create
the TODO file with this work item.
Cc: Thomas Petazzoni
Cc: Noralf Tronnes
Signed-off-by: Linus Walleij
---
drivers/staging/fbtft/TODO | 4
1 file changed, 4
To make sure this driver does not leave staging without a proper
conversion to the GPIO descriptor API, leave a note in the TODO.
Cc: Magnus Damm
Cc: Simon Horman
Cc: Geert Uytterhoeven
Signed-off-by: Linus Walleij
---
drivers/staging/emxx_udc/TODO | 2 ++
1 file changed, 2 insertions
Trying to be helpful for people who want to clean up the
staging drivers: point out the drivers that need to be
converted to use GPIO descriptors and a little bit on
how to do it.
Linus Walleij (9):
staging: emxx_udc: Add GPIO descriptor work to TODO
staging: fbtft: Add TODO file with GPIO
To make sure that these drivers do not leave staging before they
are properly converted to use the new GPIO descriptor API,
augment the TODO file with this work item.
Cc: Alan Cox
Cc: Andy Shevchenko
Signed-off-by: Linus Walleij
---
I'm happy to help to move this forward, however Andy i
To make sure that these drivers do not leave staging before they
are properly converted to use the new GPIO descriptor API,
augment the TODO file with this work item.
Cc: Jonathan Cameron
Signed-off-by: Linus Walleij
---
drivers/staging/iio/TODO | 9 -
1 file changed, 8 insertions
sed
SMI-driver and convert it to DSA.
I bet I can do that :D
Well, I will try. Because it's blocking me to work on the Gemini
ethernet driver.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproje
Top posting and resending since net...@vger.kernel.org
is the right mail address for this. Mea culpa.
Linus Walleij
On Sat, Oct 14, 2017 at 11:35 AM, Linus Walleij
wrote:
> On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu
> wrote:
>
>> This patchset introduces the Ethernet Sw
subsystem so we can house these
drivers in a proper way?
What we need AFAICT:
- Consensus on userspace ABI
- Consensus on ethtool extenstions
- Consensus on where in drivers/net this goes
You can kick me for not knowing what I'm talking about and how
On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam
> Cc: Linus Walleij
> Cc: Alexandre Cour
us *what* it is detecting the presence of.
Apart from this it has some of the same issues pointed out in the
other drivers, correct these as well.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Should be <2>. The first cell is the pin number (within the controller's
> +pin space), and the second is used for the following flags:
> + bit[0]: direction (0 = out, 1 = in)
> + bit[1]: init high
> + bit[2]: active low
Can't you just
basic
GPIO and a separate add-on patch for the IRQ functionality.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Greybus GPIO seems to reimplement the already existing generic
gpiolib irqchip. Also use gpiochip_get_data(). Also use
devm_gpiochip_add_data().
Cc: Viresh Kumar
Cc: Axel Haslam
Cc: Johan Hovold
Cc: Sandeep Patil
Cc: Rui Miguel Silva
Cc: Greg Kroah-Hartman
Signed-off-by: Linus Walleij
Greybus GPIO seems to reimplement the already existing generic
gpiolib irqchip. Also use gpiochip_get_data(). Also use
devm_gpiochip_add_data().
Cc: Viresh Kumar
Cc: Axel Haslam
Cc: Johan Hovold
Cc: Sandeep Patil
Cc: Rui Miguel Silva
Cc: Greg Kroah-Hartman
Signed-off-by: Linus Walleij
On Fri, Dec 11, 2015 at 7:58 AM, Martyn Welch wrote:
> On 09/12/15 13:50, Linus Walleij wrote:
>>
>> This makes the driver use the data pointer added to the gpio_chip
>> to store a pointer to the state container instead of relying on
>> container_of().
>>
>>
This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().
Cc: Greg Kroah-Hartman
Cc: Martyn Welch
Cc: Manohar Vanga
Cc: de...@driverdev.osuosl.org
Signed-off-by: Linus Walleij
---
Greg, please ACK this so
ad mark
> the functions as __maybe_unused, which is a nicer anyway, as it
> provides build testing for all the code in all configurations
> and is harder to get wrong.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Linus Walleij
Yours,
Linus Walleij
and
> test it)?
I can do that once the touchscreen portions are in place.
I'm just not quite familiar with the structure of the new RMI4
framework so I will need some time on it.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproj
63 matches
Mail list logo
