Re: RT2880F based iNIC mini-PCI network card
On Sun, Jul 15, 2018 at 1:37 AM Linus Walleij wrote: > I'm curious to hear if you have hints of this beast: > > lspci: > 00:0c.0 Class 0200: 1814:0801 (...) > Has someone seen a vendor tree where this leaked out by > mistake or so? The Internet is so big. impossible to keep secrets there. So I found it: https://github.com/kovz/ralink_inic Now I just need to churn through this. The firmware is ~500K. I guess an entire operating system. Oh well, I guess we can replace it with RT2880F Linux since it is just a vanilla SoC. Yours, Linus Walleij
Re: [PATCH 4/4] staging: wilc1000: use descriptor-based interface for GPIO
On Fri, Jul 20, 2018 at 2:02 PM Ajay Singh wrote: > Now making use of descriptor-based interface instead of integer-based > interface for IRQ GPIO. > Added device tree binding reference for WILC SDIO and SPI interface > module. Also moved the code to free gpio descriptor in module 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
RT2880F based iNIC mini-PCI network card
I'm curious to hear if you have hints of this beast: lspci: 00:0c.0 Class 0200: 1814:0801 AFAICT this is a ralink Mini PCI using the RT2880F dubbed "iNIC" (intelligent NIC). It is found sometimes soldered (!) onto the mini PCI sockets in a few select routers. I am trying to us it with D-Link DIR-685, the same mini PCI is found in Asus DSL-N13, Asus WL-127n, Alcatel Lucent Cellpipe 7130, Pegatron WL227N-5G Wireless Card, and the Billion BiPAC 7800N. I would try to hack on rt2xxx but I simply have no source code for this, there are GPL drops for some of the above routers but they just contain binaries, often in a path like this: ralink_RT2880_iNIC/v1.1.8.3/build/module-v1.1.8.3 A DD-WRT source tree contained this: #obj-$(CONFIG_RT2880v2_INIC_MII) += iNIC/mii/ #obj-$(CONFIG_RT2880v2_INIC_PCI) += iNIC/pci/ So there is apparently even a v2 version. The board photos shows a RT2880F and a RT2850L antenna driver on the board (the latter in a shield box). Has someone seen a vendor tree where this leaked out by mistake or so? Any other hints to get it going? I tried just adding the PCI IDs of course. The card reports back as type "" making me suspect it does not behave like all the others :( Yours, Linus Walleij
Re: [PATCH 01/12] gpio: Only descend into gpio directory when CONFIG_GPIOLIB is set
On Mon, Jun 13, 2016 at 10:02 PM, Andrew F. Davis <a...@ti.com> wrote: > When CONFIG_GPIOLIB is not set make will still descend into the gpio > directory but nothing will be built. This produces unneeded build > artifacts and messages in addition to slowing the build. Fix this here. > > Signed-off-by: Andrew F. Davis <a...@ti.com> Patch applied. Strange that this went unnoticed for years. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mediatek wifi
On Mon, Dec 21, 2015 at 1:09 PM, Anca Emanuel <anca.eman...@gmail.com> wrote: > https://github.com/neurobin/MT7630E is reported to work for wifi. Yes this works because it contains a forked and bitrotting copy of the entire Mediatek code drop including a fork of rt2x00 from the v3.10 kernel. It's not going to last, and I can't get it to compile properly with the most recent Fedora kernel relase (v4.3.x-based). Ubuntu will also run into the problem sooner or later. :( Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP
On Fri, Dec 18, 2015 at 7:01 PM, Hauke Mehrtens <ha...@hauke-m.de> wrote: > On 12/18/2015 07:27 AM, Rafał Miłecki wrote: >> I'm afraid it wasn't tested on BCM47XX (MIPS) :( > > Yes, you are probably right. > >> On 14 August 2015 at 00:21, Hauke Mehrtens <ha...@hauke-m.de> wrote: >>> @@ -218,9 +187,8 @@ int bcma_gpio_init(struct bcma_drv_cc *cc) >>> chip->set = bcma_gpio_set_value; >>> chip->direction_input = bcma_gpio_direction_input; >>> chip->direction_output = bcma_gpio_direction_output; >>> -#if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X) >>> - chip->to_irq= bcma_gpio_to_irq; >>> -#endif >>> + chip->owner = THIS_MODULE; >>> + chip->dev = bcma_bus_get_host_dev(bus); >> >> This assigns >host_pdev->dev which is NULL. > > hmm, how do we fix this, as long as bcma does not have a device on mips > this is a problem. Should we create a new device for mips? Yes I think MIPS should just create a host device. That makes things simple and nice. Is it complex to do so? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP
On Tue, Dec 22, 2015 at 1:09 PM, Hauke Mehrtens <ha...@hauke-m.de> wrote: > On 12/22/2015 10:01 AM, Linus Walleij wrote: >> On Fri, Dec 18, 2015 at 7:01 PM, Hauke Mehrtens <ha...@hauke-m.de> wrote: >>> On 12/18/2015 07:27 AM, Rafał Miłecki wrote: >>>> I'm afraid it wasn't tested on BCM47XX (MIPS) :( >>> >>> Yes, you are probably right. >>> >>>> On 14 August 2015 at 00:21, Hauke Mehrtens <ha...@hauke-m.de> wrote: >>>>> @@ -218,9 +187,8 @@ int bcma_gpio_init(struct bcma_drv_cc *cc) >>>>> chip->set = bcma_gpio_set_value; >>>>> chip->direction_input = bcma_gpio_direction_input; >>>>> chip->direction_output = bcma_gpio_direction_output; >>>>> -#if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X) >>>>> - chip->to_irq= bcma_gpio_to_irq; >>>>> -#endif >>>>> + chip->owner = THIS_MODULE; >>>>> + chip->dev = bcma_bus_get_host_dev(bus); >>>> >>>> This assigns >host_pdev->dev which is NULL. >>> >>> hmm, how do we fix this, as long as bcma does not have a device on mips >>> this is a problem. Should we create a new device for mips? >> >> Yes I think MIPS should just create a host device. That >> makes things simple and nice. Is it complex to do so? >> >> Yours, >> Linus Walleij >> > Currently the documentation says this for the parent member on struct > gpio_chip: > > * @parent: optional parent device providing the GPIOs > > I assume the optional is wrong here. For just gpiochip it is optional. But if you read on: GPIO drivers providing IRQs --- (...) To use the helpers please keep the following in mind: - Make sure to assign all relevant members of the struct gpio_chip so that the irqchip can initialize. E.g. .dev and .can_sleep shall be set up properly. (...) Well it's complex. But when adding the gpio character device I am working with, I will introduce a struct device to the gpio_chip (or similar sibling gpio_device) which we can then refer, so that this actually will no longer be a requirement. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 000/182] Rid struct gpio_chip from container_of() usage
On Mon, Dec 14, 2015 at 1:46 PM, Johan Hovold <jo...@kernel.org> wrote:
> Ok, but let's take a step back. So you have all this in place and a
> consumer calls gpiod_get_value() that returns an errno because the device
> is gone. Note that this wasn't even possible before e20538b82f1f ("gpio:
> Propagate errors from chip->get()") that went into *v4.3*, and I assume
> most drivers would need to be updated to even handle that that gpio
> call, and all future calls, are now suddenly failing.
I actually have a revert of that in my fixes queue. So another step back
and two forward for v4.5 (hopefully): audit all drivers to respect this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 000/182] Rid struct gpio_chip from container_of() usage
On Tue, Dec 15, 2015 at 8:25 AM, Dmitry Torokhov <dmitry.torok...@gmail.com> wrote: > On Mon, Dec 14, 2015 at 1:18 AM, Linus Walleij <linus.wall...@linaro.org> > wrote: >> At this point we have to cross-reference the pointer to my chip to >> find the chip to remove. This goes for anything that takes the struct >> gpio_chip * >> as parameter, like gpiochip_add_pin_range(), gpiochip_request_own_desc() >> etc etc. So something inside gpiolib must take a gpio_chip * pointer and >> turn that into the actual state container, e.g, a struct gpio_device. >> Since struct gpio_chip needs to be static and stateless, it cannot contain >> a pointer back to its struct gpio_device. > > Why does gpio_chip have to be stateless? I am not saying that it > should or should not, I just want to better understand what you are > trying to achieve. Because the allocation of gpio_chip is currently inside each driver (often as part of their own state struct) and will go away with the driver. I want to make that const parameter that the drivers supply to the core gpiolib, and the gpiolib handled all states using something like that struct gpio_device you suggested or a more elaborate solution. >> If I compare to how struct input_dev is done, you appear to also use the >> pattern Russell suggested with input_dev_allocate() akin to >> netdev_alloc(), and the allocated struct holds all the vtable and states etc, >> and I think it is a good pattern, and that GPIO should conform. > > The main difference between gpio_chip (at least as it stands > currently) and input devices and corresponding private driver data is > that input device and driver data has different lifetimes; input > devices may stick around even though driver is unbound from > corresponding device and driver's private data freed. I would like to achieve something similar for GPIO devices. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 000/182] Rid struct gpio_chip from container_of() usage
This removes the use of container_of() constructions from *all*
GPIO drivers in the kernel. It is done by instead adding an
optional void *data pointer to the struct gpio_chip and an
accessor function, gpiochip_get_data() to get it from a driver.
WHY?
Because we want to have a proper userspace ABI for GPIO chips,
which involves using a character device that the user opens
and closes. While the character device is open, the underlying
kernel objects must not go away.
Currently the GPIO drivers keep their state in the struct
gpio_chip, and that is often allocated by the drivers, very
often as a part of a containing per-instance state container
struct for the driver:
struct foo_state {
struct gpio_chip chip; <- OMG my state is there
};
Drivers cannot allocate and manage this state: if a user has the
character device open, the objects allocated must stay around
even if the driver goes away. Instead drivers need to pass a
descriptor to the GPIO core, and then the core should allocate
and manage the lifecycle of things related to the device, such
as the chardev itself or the struct device related to the GPIO
device.
Thus what is today gpiochip_add() (and after this patch set
gpiochip_add_data()) must return a pointer/cookie to an object
maintained elsewhere. The object passed back to the functions
in the vtable of a gpio_chip like .request(), .get_value(),
.set_value() etc must also be changed.
Thus container_of() constructions will not work, because
container_of(), clever as it is, does not work with a member
that is a pointer: it needs a full struct inside the
containing struct.
This patch set takes the first step by eliminating container_of()
and replacing it with a data pointer mechanism.
The patch set is just a step in the larger refactoring needed
but stands on its own as it happens to remove 500+ lines
of code and (IMO) makes the code in all drivers easier
to read and understand.
I need ACKs to merge this through the GPIO tree.
I do not think we will see collissions in the merge window
but if you're adding new gpio_chips or deleting drivers,
write me so we can work something out. (Immutable branches
that I can pull and make fixes on top of would be the
best.)
And as mentioned this kind of series will continue.
If you think it looks invasive, think of the changes done
for irq_chip over the year. GPIO is in a similar situation.
Linus Walleij (182):
gpio: forward-declare enum gpiod_flags
gpio: add a data pointer to gpio_chip
gpio: of: provide optional of_mm_gpiochip_add_data() function
gpio: generic: factor into gpio_chip struct
gpio: 104-idi-48: use gpiochip data pointer
gpio: 104-idio-16: use gpiochip data pointer
gpio: 74x164: use gpiochip data pointer
gpio: adnp: use gpiochip data pointer
gpio: adp5520: use gpiochip data pointer
gpio: adp5588: use gpiochip data pointer
gpio: altera: use gpiochip data pointer
gpio: amd8111: use gpiochip data pointer
gpio: amdpt: use gpiochip data pointer
gpio: arizona: use gpiochip data pointer
gpio: ath79: use gpiochip data pointer
gpio: bcm-kona: use gpiochip data pointer
gpio: bt8xx: use gpiochip data pointer
gpio: crystalcove: use gpiochip data pointer
gpio: cs5535: use gpiochip data pointer
gpio: da9052: use gpiochip data pointer
gpio: da9055: use gpiochip data pointer
gpio: davinci: use gpiochip data pointer
gpio: dln2: use gpiochip data pointer
gpio: em: use gpiochip data pointer
gpio: f7188: use gpiochip data pointer
gpio: intel-mid: use gpiochip data pointer
gpio: it87: use gpiochip data pointer
gpio: kempld: use gpiochip data pointer
gpio: lp3943: use gpiochip data pointer
gpio: lpc18xx: use gpiochip data pointer
gpio: lpc32xx: use gpiochip data pointer
gpio: lynxpoint: use gpiochip data pointer
gpio: max730x: use gpiochip data pointer
gpio: max732x: use gpiochip data pointer
gpio: mb86s7x: use gpiochip data pointer
gpio: mc33880: use gpiochip data pointer
gpio: mc9s08dz60: use gpiochip data pointer
gpio: mcp: use gpiochip data pointer
gpio: ml-ioh: use gpiochip data pointer
gpio: mm-lantiq: use gpiochip data pointer
gpio: mpc5200: use gpiochip data pointer
gpio: mpc8xxx: use gpiochip data pointer
gpio: msic: use gpiochip data pointer
gpio: mvebu: use gpiochip data pointer
gpio: octeon: use gpiochip data pointer
gpio: omap: use gpiochip data pointer
gpio: palmas: use gpiochip data pointer
gpio: pca953x: use gpiochip data pointer
gpio: pcf857x: use gpiochip data pointer
gpio: pch: use gpiochip data pointer
gpio: pl061: use gpiochip data pointer
gpio: pxa: use gpiochip data pointer
gpio: rc5t583: use gpiochip data pointer
gpio: rcar: use gpiochip data pointer
gpio: rdc321x: use gpiochip data pointer
gpio: samsung: use gpiochip data pointer
gpio: sch: use gpiochip data pointer
gpio: sch311x: use gpiochip data pointer
gpio: spear-spics: use gpiochip data pointer
gpio: sta2x11: use gpiochip data pointer
gpio: stmpe: use gpioc
[PATCH 153/182] bcma: gpio: use gpiochip data pointer
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: Rafał Miłecki <zaj...@gmail.com>
Cc: Hauke Mehrtens <ha...@hauke-m.de>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
BCMA maintainers: please ACK this so I can take it through the
GPIO tree.
---
drivers/bcma/driver_gpio.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 949754427ce2..98067f757fb0 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -17,14 +17,9 @@
#define BCMA_GPIO_MAX_PINS 32
-static inline struct bcma_drv_cc *bcma_gpio_get_cc(struct gpio_chip *chip)
-{
- return container_of(chip, struct bcma_drv_cc, gpio);
-}
-
static int bcma_gpio_get_value(struct gpio_chip *chip, unsigned gpio)
{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
+ struct bcma_drv_cc *cc = gpiochip_get_data(chip);
return !!bcma_chipco_gpio_in(cc, 1 << gpio);
}
@@ -32,14 +27,14 @@ static int bcma_gpio_get_value(struct gpio_chip *chip,
unsigned gpio)
static void bcma_gpio_set_value(struct gpio_chip *chip, unsigned gpio,
int value)
{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
+ struct bcma_drv_cc *cc = gpiochip_get_data(chip);
bcma_chipco_gpio_out(cc, 1 << gpio, value ? 1 << gpio : 0);
}
static int bcma_gpio_direction_input(struct gpio_chip *chip, unsigned gpio)
{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
+ struct bcma_drv_cc *cc = gpiochip_get_data(chip);
bcma_chipco_gpio_outen(cc, 1 << gpio, 0);
return 0;
@@ -48,7 +43,7 @@ static int bcma_gpio_direction_input(struct gpio_chip *chip,
unsigned gpio)
static int bcma_gpio_direction_output(struct gpio_chip *chip, unsigned gpio,
int value)
{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
+ struct bcma_drv_cc *cc = gpiochip_get_data(chip);
bcma_chipco_gpio_outen(cc, 1 << gpio, 1 << gpio);
bcma_chipco_gpio_out(cc, 1 << gpio, value ? 1 << gpio : 0);
@@ -57,7 +52,7 @@ static int bcma_gpio_direction_output(struct gpio_chip *chip,
unsigned gpio,
static int bcma_gpio_request(struct gpio_chip *chip, unsigned gpio)
{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
+ struct bcma_drv_cc *cc = gpiochip_get_data(chip);
bcma_chipco_gpio_control(cc, 1 << gpio, 0);
/* clear pulldown */
@@ -70,7 +65,7 @@ static int bcma_gpio_request(struct gpio_chip *chip, unsigned
gpio)
static void bcma_gpio_free(struct gpio_chip *chip, unsigned gpio)
{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
+ struct bcma_drv_cc *cc = gpiochip_get_data(chip);
/* clear pullup */
bcma_chipco_gpio_pullup(cc, 1 << gpio, 0);
@@ -81,7 +76,7 @@ static void bcma_gpio_free(struct gpio_chip *chip, unsigned
gpio)
static void bcma_gpio_irq_unmask(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
+ struct bcma_drv_cc *cc = gpiochip_get_data(gc);
int gpio = irqd_to_hwirq(d);
u32 val = bcma_chipco_gpio_in(cc, BIT(gpio));
@@ -92,7 +87,7 @@ static void bcma_gpio_irq_unmask(struct irq_data *d)
static void bcma_gpio_irq_mask(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
+ struct bcma_drv_cc *cc = gpiochip_get_data(gc);
int gpio = irqd_to_hwirq(d);
bcma_chipco_gpio_intmask(cc, BIT(gpio), 0);
@@ -216,7 +211,7 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
else
chip->base = -1;
- err = gpiochip_add(chip);
+ err = gpiochip_add_data(chip, cc);
if (err)
return err;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 000/182] Rid struct gpio_chip from container_of() usage
On Wed, Dec 9, 2015 at 2:44 PM, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:
Thanks Russell, I think you speed up the design and shorten the
development time by providing these ideas, so it is much, much
appreciated.
> On Wed, Dec 09, 2015 at 02:08:35PM +0100, Linus Walleij wrote:
>> Because we want to have a proper userspace ABI for GPIO chips,
>> which involves using a character device that the user opens
>> and closes. While the character device is open, the underlying
>> kernel objects must not go away.
>
> Okay, so you stop the gpio_chip struct from going away.
Actually I was going to create a new struct gpio_device, but yes.
> What
> about the code which is called via gpio_chip - say, if userspace
> keeps the chardev open, and someone rmmod's the driver providing
> the GPIO driver.
The idea was that when what is today gpiochip_remove() is called by the
gpiochip driver, the static data pointer to the vtable with all
callbacks is set to NULL (in some safe way), and the code avoids
calling these, so the device goes numb.
I think you give me the right solution to this "safe way" below,
thanks!
> I'm not sure that splitting up objects in this way really solves
> anything at all. Yes, it divorses the driver's private data from
> the subsystem data, but is that really an advantage?
I like the design pattern you describe below, and
I have no strong opinion on it. If there is a precedent in the kernel
to do it with a separate alloc_foo() function I can do that.
(Would like Greg's and/or Johan's opinion on this though.)
> Network drivers have a similar issue, and the way this problem is
> solved there is that alloc_netdev() is always used to allocate the
> subsystem data structure and any driver private data structure as
> one allocation, and the lifetime of both objects remains under the
> control of the subsystem.
>
> The allocated memory is only freed when the last user goes away,
> and net has protection to prevent an unregistered driver from
> being called (via locks on every path into the layer.)
That's a viable way to solve this.
The refactoring would be bigger in size and different. The current
patch set would still be needed though, as the drivers will
still not be able to use the container_of() design pattern with this
design either, as the gpiolib core handles allocation of its
own struct and then some more.
With what I had in mind it would be something like:
struct foo_gpio {
struct gpio_device *gd;
};
const struct gpio_ops foo_ops = {
.set = ...
.get = ...
};
foo = devm_kzalloc(dev, ...);
foo->gd = gpio_add_device(_ops, ...);
...
gpio_remove_device(foo->gd);
But with the alloc_gpiodev() pattern we get this:
struct foo_gpio {
};
static void setup(struct gpio_device *gd)
{
gd->set = ...;
gd->get = ...;
}
foo = gpio_alloc_device(sizeof(foo), name, setup);
struct gpio_device *gd = gpio_add_device(foo);
...
gpio_remove_device(gd);
The setup call is clever to use also with GPIO because we
can use that to setup mmio-gpio drivers and easier refactor
those drivers that assign members to gpio_chip dynamically.
Also I think this case would involve getting rid of all static
vtables and only use that setup call to assign function
pointers akin to what we have for gpio_chip. Lots of work,
but I like it.
We can do allocation in early boot these days even if
the gpiochip is added with an early initcall right?
> Things get a little more complex with gpio, because there's the
> issue that some methods are spinlocked while others can take
> semaphores, but it should be possible to come up with a solution
> to that - maybe an atomic_t which is incremented whenever we're
> in some operation provided it's >= 0 (otherwise it fails), and
> decremented when the operation completes. We can then control
> in the unregistration path further GPIO accesses, and also
> prevent new accesses occuring by setting the atomic_t to -1.
> This shouldn't require any additional locking in any path. It
> does mean that the unregistration path needs careful thought to
> ensure that when we set it to -1, we wait for it to be dropped
> by the appropriate amount.
Yeah we will both in spinlocks/hotpath and
semaphores/mutexes/slowpath in these ops for sure :/
The atomic hack should work: I understand that you mean
we read it and set it to -1 and if it was 2 wait for it to
become -3, then conclude unregistration with callbacks
numbed.
Then there is a particular case that occurs with USB or similar
pluggable buses, where there is a glitch or powercycle on the
bus, and the same device goes away and comes back in
a few milliseconds, and that means it should reattach to the
character device that is already open.
Making that work is however non-trivial :(
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP
On Sun, Aug 2, 2015 at 8:00 PM, Hauke Mehrtens ha...@hauke-m.de wrote: From: Linus Walleij linus.wall...@linaro.org This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to handle its interrupts instead of rolling its own copy of the irqdomain handling etc. Signed-off-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Hauke Mehrtens ha...@hauke-m.de --- I fixed some bugs in the original patch, some of them are compile errors and others caused some runtime problems. This patch worked on my BCM4708 based device, I was able to receive an IRQ for a GPIO change (button press). Thanks a *LOT* for spending the effort of fixing up my uglyhack. I think this should go through the wireless tree. @Linus could you please check if the changes I did are correct? LooksGoodToMe(TM) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for Mediatek MT7630E
On Wed, Jul 29, 2015 at 12:23 AM, Linus Walleij linus.wall...@linaro.org wrote: My daughter has this device in her laptop it seems, sigh. I might start fiddling with it unless someone else is already doing it. I managed to rebase the patch to mainline HEAD and have it compiling and booting without crashing. It also lists the APs nicely. However connect fails with some random encryption complaints so I will work on this whenever I have time. If there is general interest to hack on this I can publish my kernel tree @kernel.org. Xose Vazquez Perez xose.vazq...@gmail.com wrote: The driver for MediaTek MT7601U was recently added to upstream at: drivers/net/wireless/mediatek/mt7601u/ Awesome, I can see I have some duplicated defines etc from this in my patch, so will see if they can integrate cleanly if I even get this working properly. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for Mediatek MT7630E
On Wed, Jul 29, 2015 at 1:24 AM, Xose Vazquez Perez xose.vazq...@gmail.com wrote: Linus Walleij wrote: Did anything ever happen to this? My daughter has this device in her laptop it seems, sigh. I might start fiddling with it unless someone else is already doing it. Jakub Kicinski was working on it at: https://github.com/kuba-moo/mt7630e Ah yeah that is what I have running. It's a fork of rt2x00 so it's missing all fixes since 3.11 or so, just a question of when this becomes unsupportable. This code is a complete mashup of Linux and duct-taped Windows NDIS-based driver code, my eyes are bleeding from looking at it. The defines etc patched in have obvious gaps due to other unsupported chips such as MT7601u I suspect. I guess it's necessary to also look at this in order to not screw things up for 7601. https://github.com/porjo/mt7601 Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for Mediatek MT7630E
On 2014-06-11 Larry wrote: I found such a device at a reasonable price on E-bay, and ordered it. It should arrive next week. I also was able to find the firmware in an RPM for SUSE SLE11, and a license allowing redistribution. Before I start modifying rt2800pci for this new device, I want to be assured that this modification is not currently being done by anyone in the rt2x00 project. There is too much to be done to duplicate effort. Did anything ever happen to this? My daughter has this device in her laptop it seems, sigh. I might start fiddling with it unless someone else is already doing it. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP
This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
handle its interrupts instead of rolling its own copy of the
irqdomain handling etc.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
Hi BCMA people,
if we can figure this out it would be great if you can test this
and merge it through whatever GIT tree handles BCMA patches.
Alternatively I can merge it into the GPIO tree with your ACK.
This is not even compiled, I don't have the right cross compilers
but the conversion is done like all other GPIOLIB_IRQCHIP conversions
I've done, so it shouldn't be very far off. Maybe you can get it
in shape in accordance with my idea if I screwed up? Thanks.
---
drivers/bcma/Kconfig| 2 +-
drivers/bcma/driver_gpio.c | 88 +
include/linux/bcma/bcma_driver_chipcommon.h | 1 -
3 files changed, 28 insertions(+), 63 deletions(-)
diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index be5fffb6da24..023d448ed3fa 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -92,7 +92,7 @@ config BCMA_DRIVER_GMAC_CMN
config BCMA_DRIVER_GPIO
bool BCMA GPIO driver
depends on BCMA GPIOLIB
- select IRQ_DOMAIN if BCMA_HOST_SOC
+ select GPIOLIB_IRQCHIP if BCMA_HOST_SOC
help
Driver to provide access to the GPIO pins of the bcma bus.
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 5f6018e7cd4c..f436fb5b429c 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -8,10 +8,8 @@
* Licensed under the GNU/GPL. See COPYING for details.
*/
-#include linux/gpio.h
-#include linux/irq.h
+#include linux/gpio/driver.h
#include linux/interrupt.h
-#include linux/irqdomain.h
#include linux/export.h
#include linux/bcma/bcma.h
@@ -79,19 +77,11 @@ static void bcma_gpio_free(struct gpio_chip *chip, unsigned
gpio)
}
#if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X)
-static int bcma_gpio_to_irq(struct gpio_chip *chip, unsigned gpio)
-{
- struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
-
- if (cc-core-bus-hosttype == BCMA_HOSTTYPE_SOC)
- return irq_find_mapping(cc-irq_domain, gpio);
- else
- return -EINVAL;
-}
static void bcma_gpio_irq_unmask(struct irq_data *d)
{
- struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
u32 val = bcma_chipco_gpio_in(cc, BIT(gpio));
@@ -101,7 +91,8 @@ static void bcma_gpio_irq_unmask(struct irq_data *d)
static void bcma_gpio_irq_mask(struct irq_data *d)
{
- struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
bcma_chipco_gpio_intmask(cc, BIT(gpio), 0);
@@ -116,6 +107,7 @@ static struct irq_chip bcma_gpio_irq_chip = {
static irqreturn_t bcma_gpio_irq_handler(int irq, void *dev_id)
{
struct bcma_drv_cc *cc = dev_id;
+ struct gpio_chip *gc = cc-gpio;
u32 val = bcma_cc_read32(cc, BCMA_CC_GPIOIN);
u32 mask = bcma_cc_read32(cc, BCMA_CC_GPIOIRQ);
u32 pol = bcma_cc_read32(cc, BCMA_CC_GPIOPOL);
@@ -125,14 +117,14 @@ static irqreturn_t bcma_gpio_irq_handler(int irq, void
*dev_id)
if (!irqs)
return IRQ_NONE;
- for_each_set_bit(gpio, irqs, cc-gpio.ngpio)
- generic_handle_irq(bcma_gpio_to_irq(cc-gpio, gpio));
+ for_each_set_bit(gpio, irqs, gc-ngpio)
+ generic_handle_irq(irq_find_mapping(gc-irq_domain, gpio));
bcma_chipco_gpio_polarity(cc, irqs, val irqs);
return IRQ_HANDLED;
}
-static int bcma_gpio_irq_domain_init(struct bcma_drv_cc *cc)
+static int bcma_gpio_irq_init(struct bcma_drv_cc *cc)
{
struct gpio_chip *chip = cc-gpio;
int gpio, hwirq, err;
@@ -140,66 +132,43 @@ static int bcma_gpio_irq_domain_init(struct bcma_drv_cc
*cc)
if (cc-core-bus-hosttype != BCMA_HOSTTYPE_SOC)
return 0;
- cc-irq_domain = irq_domain_add_linear(NULL, chip-ngpio,
- irq_domain_simple_ops, cc);
- if (!cc-irq_domain) {
- err = -ENODEV;
- goto err_irq_domain;
- }
- for (gpio = 0; gpio chip-ngpio; gpio++) {
- int irq = irq_create_mapping(cc-irq_domain, gpio);
-
- irq_set_chip_data(irq, cc);
- irq_set_chip_and_handler(irq, bcma_gpio_irq_chip,
-handle_simple_irq);
- }
-
hwirq = bcma_core_irq(cc-core, 0);
err = request_irq(hwirq, bcma_gpio_irq_handler, IRQF_SHARED, gpio,
cc);
if (err)
- goto err_req_irq;
+ return err
Re: [PATCH] net: rfkill: gpio: Add default GPIO driver mappings for ACPI
On Mon, Oct 27, 2014 at 11:15 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
The driver uses devm_gpiod_get_index(..., index) so that the index refers
directly to the GpioIo resource under the ACPI device. The problem with
this is that if the ordering changes we get wrong GPIOs.
With ACPI 5.1 _DSD we can now use names instead to reference GPIOs
analogous to Device Tree. However, we still have systems out there that do
not provide _DSD at all. These systems must be supported as well.
Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide
mappings for systems where _DSD is not provided and still take advantage of
_DSD if it exists.
This patch changes the driver to create default GPIO mappings if we are
running on ACPI system.
While there we can drop the indices completely and use devm_gpiod_get()
with name instead.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
---
Hi,
This patch is based on top of linux-pm/device-properties [1] and following
patch from Rafael [2].
Johannes, John,
If you are happy with the patch, can you ACK it so that we can merge it
with the rest of the device-properties patches. Thanks.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
[2] https://lkml.org/lkml/2014/10/24/690
(...)
+static const struct acpi_gpio_params reset_gpios = { 0, 0, false };
+static const struct acpi_gpio_params shutdown_gpios = { 1, 0, false };
+
+static const struct acpi_gpio_mapping acpi_rfkill_default_gpios[] = {
+ { reset-gpios, reset_gpios, 1 },
+ { shutdown-gpios, shutdown_gpios, 1 },
+ { },
+};
Jaysis, it could use a comment above the map telling the poor code
reader what is actually going on.
Other than that, this is what we have to live with I guess so:
Acked-by: Linus Walleij linus.wall...@linaro.org
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
