Re: [PATCH v3 02/17] media: v4l2-fwnode: Pass notifier to v4l2_async_register_fwnode_subdev()
On Tue, Feb 04, 2020 at 03:49:03PM -0800, Steve Longerbeam wrote: > Instead of allocating a notifier in v4l2_async_register_fwnode_subdev(), > have the caller provide one. This allows the caller to implement > notifier ops (bind, unbind). > > The caller is now responsible for first initializing its notifier with a > call to v4l2_async_notifier_init(). Hint: When creating a list of maintainers use this (or similar) command: scripts/get_maintainer.pl --git --git-min-percent=67 ... P.S. Please, do not add me in Cc list for v4l2 matters. -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: octeon: delete driver
On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck wrote:
> On 2/4/20 7:34 PM, Dan Carpenter wrote:
> > On Tue, Feb 04, 2020 at 12:31:16PM -0800, Matthew Wilcox wrote:
> >> On Tue, Feb 04, 2020 at 08:06:14PM +, Chris Packham wrote:
> >>> On Tue, 2020-02-04 at 07:09 +, gre...@linuxfoundation.org wrote:
> On Tue, Feb 04, 2020 at 04:02:15AM +, Chris Packham wrote:
> >>> On Tue, 2020-02-04 at 10:21 +0300, Dan Carpenter wrote:
> My advice is to delete all the COMPILE_TEST code. That stuff was a
> constant source of confusion and headaches.
> >>>
> >>> I was also going to suggest this. Since the COMPILE_TEST has been a
> >>> source of trouble I was going to propose dropping the || COMPILE_TEST
> >>> from the Kconfig for the octeon drivers.
> >>
> >> Not having it also causes problems. I didn't originally add it for
> >> shits and giggles.
> >
> > I wonder if the kbuild bot does enough cross compile build testing these
> > days to detect compile problems. It might have improved to the point
> > where COMPILE_TEST isn't required.
It depends...
> Not really. Looking at the build failures in the mainline kernel right now:
>
> Failed builds:
> alpha:allmodconfig
> arm:allmodconfig
> i386:allyesconfig
> i386:allmodconfig
> m68k:allmodconfig
> microblaze:mmu_defconfig
> mips:allmodconfig
> parisc:allmodconfig
> powerpc:allmodconfig
> s390:allmodconfig
> sparc64:allmodconfig
I did receive a report from nore...@ellerman.id.au for the m68k build
failure. But that was sent to me only, not to the offender, and I do my
own builds anyway.
More interesting, that report happened after the offending commit landed
upstream, while it had been in next for 4 weeks.
> Many of those don't even _have_ specific configurations causing the build
> failures.
Exactly. These are the "easy" ones, as the all*config builds enable as
much infrastructure as possible. It's much harder if some common
dependency is not fulfilled in some specific config.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Mon, 2020-02-03 at 12:03 +, Jonathan Cameron wrote:
>
> On Mon, 3 Feb 2020 10:31:30 +0100
> Nuno Sá wrote:
>
> > Hi Jonathan,
> >
> >
> > On Sat, 2020-02-01 at 17:08 +, Jonathan Cameron wrote:
> > > On Mon, 20 Jan 2020 16:20:49 +0200
> > > Alexandru Ardelean wrote:
> > >
> > > > From: Nuno Sá
> > > >
> > > > All the ADIS devices perform, at the beginning, a self test to
> > > > make
> > > > sure
> > > > the device is in a sane state. Furthermore, some drivers also
> > > > do a
> > > > call
> > > > to `adis_reset()` before the test which is also a good
> > > > practice.
> > > > This
> > > > patch unifies all those operation so that, there's no need for
> > > > code
> > > > duplication. Furthermore, the rst pin is also checked to make
> > > > sure
> > > > the
> > > > device is not in HW reset. On top of this, some drivers also
> > > > read
> > > > the
> > > > device product id and compare it with the device being probed
> > > > to
> > > > make
> > > > sure the correct device is being handled. This can also be
> > > > passed
> > > > to the
> > > > library by introducing a variable holding the PROD_ID register
> > > > of
> > > > the
> > > > device.
> > > >
> > > > Signed-off-by: Nuno Sá
> > > > Signed-off-by: Alexandru Ardelean <
> > > > alexandru.ardel...@analog.com>
> > > > ---
> > > > drivers/iio/imu/Kconfig | 1 +
> > > > drivers/iio/imu/adis.c | 63 ++
> > > >
> > > > --
> > > > include/linux/iio/imu/adis.h | 15 -
> > > > 3 files changed, 61 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> > > > index 60bb1029e759..63036cf473c7 100644
> > > > --- a/drivers/iio/imu/Kconfig
> > > > +++ b/drivers/iio/imu/Kconfig
> > > > @@ -85,6 +85,7 @@ endmenu
> > > >
> > > > config IIO_ADIS_LIB
> > > > tristate
> > > > + depends on GPIOLIB
> > > > help
> > > > A set of IO helper functions for the Analog Devices
> > > > ADIS*
> > > > device family.
> > > >
> > > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> > > > index d02b1911b0f2..1eca5271380e 100644
> > > > --- a/drivers/iio/imu/adis.c
> > > > +++ b/drivers/iio/imu/adis.c
> > > > @@ -7,6 +7,7 @@
> > > > */
> > > >
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -365,36 +366,64 @@ static int adis_self_test(struct adis
> > > > *adis)
> > > > }
> > > >
> > > > /**
> > > > - * adis_inital_startup() - Performs device self-test
> > > > + * __adis_initial_startup() - Device initial setup
> > > > * @adis: The adis device
> > > > *
> > > > + * This functions makes sure the device is not in reset, via
> > > > rst
> > > > pin.
> > > > + * Furthermore it performs a SW reset (only in the case we are
> > > > not
> > > > coming from
> > > > + * reset already) and a self test. It also compares the
> > > > product id
> > > > with the
> > > > + * device id if the prod_id_reg variable is set.
> > > > + *
> > > > * Returns 0 if the device is operational, a negative error
> > > > code
> > > > otherwise.
> > > > *
> > > > * This function should be called early on in the device
> > > > initialization sequence
> > > > * to ensure that the device is in a sane and known state and
> > > > that
> > > > it is usable.
> > > > */
> > > > -int adis_initial_startup(struct adis *adis)
> > > > +int __adis_initial_startup(struct adis *adis)
> > > > {
> > > > int ret;
> > > > -
> > > > - mutex_lock(&adis->state_lock);
> > > > + struct gpio_desc *gpio;
> > > > + const struct adis_timeout *timeouts = adis->data-
> > > > >timeouts;
> > > > + const char *iio_name = spi_get_device_id(adis->spi)-
> > > > >name;
> > > > + u16 prod_id, dev_id;
> > > > +
> > > > + /* check if the device has rst pin low */
> > > > + gpio = devm_gpiod_get_optional(&adis->spi->dev,
> > > > "reset",
> > > > GPIOD_ASIS);
> > > > + if (IS_ERR(gpio)) {
> > > > + return PTR_ERR(gpio);
> > >
> > > Given you are returning here, no need for else to follow
> > >
> > > if (gpio...
> > >
> >
> > Definitely...
> >
> > > > + } else if (gpio && gpiod_get_value_cansleep(gpio)) {
> > > > + /* bring device out of reset */
> > > > + gpiod_set_value_cansleep(gpio, 0);
> > >
> > > Hmm. So is a software reset the best option if we have a hardware
> > > reset
> > > line but it's not currently in the reset mode?
> > >
> >
> > Hmm, that's a fair question. Now that I think about it, if we do
> > have a
> > gpio we should just assume it's in reset and call
> > `gpiod_set_value_cansleep`. So, I guess we could just ditch the
> > `gpiod_get_value_cansleep(gpio)` part.
>
> Not sure I agree. For example the driver may well have been unbound
> and rebound for some reason.
Yes, that is true..
> I would argue you should just do a set / reset cycle with appropriate
> slee
[PATCH] staging: greybus: use after free in gb_audio_manager_remove_all()
When we call kobject_put() and it's the last reference to the kobject
then it calls gb_audio_module_release() and frees module. We dereference
"module" on the next line which is a use after free.
Fixes: c77f85bbc91a ("greybus: audio: Fix incorrect counting of 'ida'")
Signed-off-by: Dan Carpenter
---
drivers/staging/greybus/audio_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager.c
b/drivers/staging/greybus/audio_manager.c
index 9b19ea9d3fa1..9a3f7c034ab4 100644
--- a/drivers/staging/greybus/audio_manager.c
+++ b/drivers/staging/greybus/audio_manager.c
@@ -92,8 +92,8 @@ void gb_audio_manager_remove_all(void)
list_for_each_entry_safe(module, next, &modules_list, list) {
list_del(&module->list);
- kobject_put(&module->kobj);
ida_simple_remove(&module_id, module->id);
+ kobject_put(&module->kobj);
}
is_empty = list_empty(&modules_list);
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: octeon: delete driver
On 2/5/20 1:03 AM, Geert Uytterhoeven wrote: On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck wrote: On 2/4/20 7:34 PM, Dan Carpenter wrote: On Tue, Feb 04, 2020 at 12:31:16PM -0800, Matthew Wilcox wrote: On Tue, Feb 04, 2020 at 08:06:14PM +, Chris Packham wrote: On Tue, 2020-02-04 at 07:09 +, gre...@linuxfoundation.org wrote: On Tue, Feb 04, 2020 at 04:02:15AM +, Chris Packham wrote: On Tue, 2020-02-04 at 10:21 +0300, Dan Carpenter wrote: My advice is to delete all the COMPILE_TEST code. That stuff was a constant source of confusion and headaches. I was also going to suggest this. Since the COMPILE_TEST has been a source of trouble I was going to propose dropping the || COMPILE_TEST from the Kconfig for the octeon drivers. Not having it also causes problems. I didn't originally add it for shits and giggles. I wonder if the kbuild bot does enough cross compile build testing these days to detect compile problems. It might have improved to the point where COMPILE_TEST isn't required. It depends... Not really. Looking at the build failures in the mainline kernel right now: Failed builds: alpha:allmodconfig arm:allmodconfig i386:allyesconfig i386:allmodconfig m68k:allmodconfig microblaze:mmu_defconfig mips:allmodconfig parisc:allmodconfig powerpc:allmodconfig s390:allmodconfig sparc64:allmodconfig I did receive a report from nore...@ellerman.id.au for the m68k build failure. But that was sent to me only, not to the offender, and I do my own builds anyway. More interesting, that report happened after the offending commit landed upstream, while it had been in next for 4 weeks. m68k in -next builds fine for me, and did for a while. I have not seen a build failure there. There must be a context commit causing this failure, or what is (or was) in -next differs from what is in mainline. Many of those don't even _have_ specific configurations causing the build failures. Exactly. These are the "easy" ones, as the all*config builds enable as much infrastructure as possible. It's much harder if some common dependency is not fulfilled in some specific config. Yes, that is correct. But that doesn't mean that it would be a good idea to retire COMPILE_TEST. Guenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Wed, 5 Feb 2020 12:25:40 +
"Sa, Nuno" wrote:
> On Mon, 2020-02-03 at 12:03 +, Jonathan Cameron wrote:
> >
> > On Mon, 3 Feb 2020 10:31:30 +0100
> > Nuno Sá wrote:
> >
> > > Hi Jonathan,
> > >
> > >
> > > On Sat, 2020-02-01 at 17:08 +, Jonathan Cameron wrote:
> > > > On Mon, 20 Jan 2020 16:20:49 +0200
> > > > Alexandru Ardelean wrote:
> > > >
> > > > > From: Nuno Sá
> > > > >
> > > > > All the ADIS devices perform, at the beginning, a self test to
> > > > > make
> > > > > sure
> > > > > the device is in a sane state. Furthermore, some drivers also
> > > > > do a
> > > > > call
> > > > > to `adis_reset()` before the test which is also a good
> > > > > practice.
> > > > > This
> > > > > patch unifies all those operation so that, there's no need for
> > > > > code
> > > > > duplication. Furthermore, the rst pin is also checked to make
> > > > > sure
> > > > > the
> > > > > device is not in HW reset. On top of this, some drivers also
> > > > > read
> > > > > the
> > > > > device product id and compare it with the device being probed
> > > > > to
> > > > > make
> > > > > sure the correct device is being handled. This can also be
> > > > > passed
> > > > > to the
> > > > > library by introducing a variable holding the PROD_ID register
> > > > > of
> > > > > the
> > > > > device.
> > > > >
> > > > > Signed-off-by: Nuno Sá
> > > > > Signed-off-by: Alexandru Ardelean <
> > > > > alexandru.ardel...@analog.com>
> > > > > ---
> > > > > drivers/iio/imu/Kconfig | 1 +
> > > > > drivers/iio/imu/adis.c | 63 ++
> > > > >
> > > > > --
> > > > > include/linux/iio/imu/adis.h | 15 -
> > > > > 3 files changed, 61 insertions(+), 18 deletions(-)
> > > > >
> > > > > diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> > > > > index 60bb1029e759..63036cf473c7 100644
> > > > > --- a/drivers/iio/imu/Kconfig
> > > > > +++ b/drivers/iio/imu/Kconfig
> > > > > @@ -85,6 +85,7 @@ endmenu
> > > > >
> > > > > config IIO_ADIS_LIB
> > > > > tristate
> > > > > + depends on GPIOLIB
> > > > > help
> > > > > A set of IO helper functions for the Analog Devices
> > > > > ADIS*
> > > > > device family.
> > > > >
> > > > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> > > > > index d02b1911b0f2..1eca5271380e 100644
> > > > > --- a/drivers/iio/imu/adis.c
> > > > > +++ b/drivers/iio/imu/adis.c
> > > > > @@ -7,6 +7,7 @@
> > > > > */
> > > > >
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -365,36 +366,64 @@ static int adis_self_test(struct adis
> > > > > *adis)
> > > > > }
> > > > >
> > > > > /**
> > > > > - * adis_inital_startup() - Performs device self-test
> > > > > + * __adis_initial_startup() - Device initial setup
> > > > > * @adis: The adis device
> > > > > *
> > > > > + * This functions makes sure the device is not in reset, via
> > > > > rst
> > > > > pin.
> > > > > + * Furthermore it performs a SW reset (only in the case we are
> > > > > not
> > > > > coming from
> > > > > + * reset already) and a self test. It also compares the
> > > > > product id
> > > > > with the
> > > > > + * device id if the prod_id_reg variable is set.
> > > > > + *
> > > > > * Returns 0 if the device is operational, a negative error
> > > > > code
> > > > > otherwise.
> > > > > *
> > > > > * This function should be called early on in the device
> > > > > initialization sequence
> > > > > * to ensure that the device is in a sane and known state and
> > > > > that
> > > > > it is usable.
> > > > > */
> > > > > -int adis_initial_startup(struct adis *adis)
> > > > > +int __adis_initial_startup(struct adis *adis)
> > > > > {
> > > > > int ret;
> > > > > -
> > > > > - mutex_lock(&adis->state_lock);
> > > > > + struct gpio_desc *gpio;
> > > > > + const struct adis_timeout *timeouts = adis->data-
> > > > > >timeouts;
> > > > > + const char *iio_name = spi_get_device_id(adis->spi)-
> > > > > >name;
> > > > > + u16 prod_id, dev_id;
> > > > > +
> > > > > + /* check if the device has rst pin low */
> > > > > + gpio = devm_gpiod_get_optional(&adis->spi->dev,
> > > > > "reset",
> > > > > GPIOD_ASIS);
> > > > > + if (IS_ERR(gpio)) {
> > > > > + return PTR_ERR(gpio);
> > > >
> > > > Given you are returning here, no need for else to follow
> > > >
> > > > if (gpio...
> > > >
> > >
> > > Definitely...
> > >
> > > > > + } else if (gpio && gpiod_get_value_cansleep(gpio)) {
> > > > > + /* bring device out of reset */
> > > > > + gpiod_set_value_cansleep(gpio, 0);
> > > >
> > > > Hmm. So is a software reset the best option if we have a hardware
> > > > reset
> > > > line but it's not currently in the reset mode?
> > > >
> > >
> > > Hmm, that's a fair question. Now that I think about it, if we do
> > > have a
> > > gpio we should just ass
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Wed, 2020-02-05 at 14:59 +, Jonathan Cameron wrote:
> On Wed, 5 Feb 2020 12:25:40 +
> "Sa, Nuno" wrote:
>
> > On Mon, 2020-02-03 at 12:03 +, Jonathan Cameron wrote:
> > > On Mon, 3 Feb 2020 10:31:30 +0100
> > > Nuno Sá wrote:
> > >
> > > > Hi Jonathan,
> > > >
> > > >
> > > > On Sat, 2020-02-01 at 17:08 +, Jonathan Cameron wrote:
> > > > > On Mon, 20 Jan 2020 16:20:49 +0200
> > > > > Alexandru Ardelean wrote:
> > > > >
> > > > > > From: Nuno Sá
> > > > > >
> > > > > > All the ADIS devices perform, at the beginning, a self test
> > > > > > to
> > > > > > make
> > > > > > sure
> > > > > > the device is in a sane state. Furthermore, some drivers
> > > > > > also
> > > > > > do a
> > > > > > call
> > > > > > to `adis_reset()` before the test which is also a good
> > > > > > practice.
> > > > > > This
> > > > > > patch unifies all those operation so that, there's no need
> > > > > > for
> > > > > > code
> > > > > > duplication. Furthermore, the rst pin is also checked to
> > > > > > make
> > > > > > sure
> > > > > > the
> > > > > > device is not in HW reset. On top of this, some drivers
> > > > > > also
> > > > > > read
> > > > > > the
> > > > > > device product id and compare it with the device being
> > > > > > probed
> > > > > > to
> > > > > > make
> > > > > > sure the correct device is being handled. This can also be
> > > > > > passed
> > > > > > to the
> > > > > > library by introducing a variable holding the PROD_ID
> > > > > > register
> > > > > > of
> > > > > > the
> > > > > > device.
> > > > > >
> > > > > > Signed-off-by: Nuno Sá
> > > > > > Signed-off-by: Alexandru Ardelean <
> > > > > > alexandru.ardel...@analog.com>
> > > > > > ---
> > > > > > drivers/iio/imu/Kconfig | 1 +
> > > > > > drivers/iio/imu/adis.c | 63
> > > > > > ++
> > > > > >
> > > > > > --
> > > > > > include/linux/iio/imu/adis.h | 15 -
> > > > > > 3 files changed, 61 insertions(+), 18 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/iio/imu/Kconfig
> > > > > > b/drivers/iio/imu/Kconfig
> > > > > > index 60bb1029e759..63036cf473c7 100644
> > > > > > --- a/drivers/iio/imu/Kconfig
> > > > > > +++ b/drivers/iio/imu/Kconfig
> > > > > > @@ -85,6 +85,7 @@ endmenu
> > > > > >
> > > > > > config IIO_ADIS_LIB
> > > > > > tristate
> > > > > > + depends on GPIOLIB
> > > > > > help
> > > > > > A set of IO helper functions for the Analog Devices
> > > > > > ADIS*
> > > > > > device family.
> > > > > >
> > > > > > diff --git a/drivers/iio/imu/adis.c
> > > > > > b/drivers/iio/imu/adis.c
> > > > > > index d02b1911b0f2..1eca5271380e 100644
> > > > > > --- a/drivers/iio/imu/adis.c
> > > > > > +++ b/drivers/iio/imu/adis.c
> > > > > > @@ -7,6 +7,7 @@
> > > > > > */
> > > > > >
> > > > > > #include
> > > > > > +#include
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > @@ -365,36 +366,64 @@ static int adis_self_test(struct adis
> > > > > > *adis)
> > > > > > }
> > > > > >
> > > > > > /**
> > > > > > - * adis_inital_startup() - Performs device self-test
> > > > > > + * __adis_initial_startup() - Device initial setup
> > > > > > * @adis: The adis device
> > > > > > *
> > > > > > + * This functions makes sure the device is not in reset,
> > > > > > via
> > > > > > rst
> > > > > > pin.
> > > > > > + * Furthermore it performs a SW reset (only in the case we
> > > > > > are
> > > > > > not
> > > > > > coming from
> > > > > > + * reset already) and a self test. It also compares the
> > > > > > product id
> > > > > > with the
> > > > > > + * device id if the prod_id_reg variable is set.
> > > > > > + *
> > > > > > * Returns 0 if the device is operational, a negative
> > > > > > error
> > > > > > code
> > > > > > otherwise.
> > > > > > *
> > > > > > * This function should be called early on in the device
> > > > > > initialization sequence
> > > > > > * to ensure that the device is in a sane and known state
> > > > > > and
> > > > > > that
> > > > > > it is usable.
> > > > > > */
> > > > > > -int adis_initial_startup(struct adis *adis)
> > > > > > +int __adis_initial_startup(struct adis *adis)
> > > > > > {
> > > > > > int ret;
> > > > > > -
> > > > > > - mutex_lock(&adis->state_lock);
> > > > > > + struct gpio_desc *gpio;
> > > > > > + const struct adis_timeout *timeouts = adis->data-
> > > > > > > timeouts;
> > > > > > + const char *iio_name = spi_get_device_id(adis->spi)-
> > > > > > > name;
> > > > > > + u16 prod_id, dev_id;
> > > > > > +
> > > > > > + /* check if the device has rst pin low */
> > > > > > + gpio = devm_gpiod_get_optional(&adis->spi->dev,
> > > > > > "reset",
> > > > > > GPIOD_ASIS);
> > > > > > + if (IS_ERR(gpio)) {
> > > > > > + return PTR_ERR(gpio);
> > > > >
> > > > > Given you are returning here, no need for else to follow
> > > > >
> > > > > if (gpio...
> > > > >
> > > >
> > > > Definitely...
> > > >
>
Are people from linux-mediatek also interested in Mediatek MIPS SoCs? [Was: [PATCH] staging: mt7621-dts: add dt node for 2nd/3rd uart on mt7621]
On Tue, Feb 4, 2020 at 6:37 PM Dan Carpenter wrote: > > On Tue, Feb 04, 2020 at 05:59:21PM +0800, Chuanhong Guo wrote: > > Hi! > > > > On Tue, Feb 4, 2020 at 5:47 PM Dan Carpenter > > wrote: > > > > > > Please use ./scripts/get_maintainer.pl to pick the CC list and resend. > > > > > > The MAINTAINERS file says Matthias Brugger is supposed to be CC'd and > > > a couple other email lists. > > > > According to get_maintainer.pl, Matthias Brugger is the maintainer of > > Mediatek ARM SoC: > > > > Matthias Brugger (maintainer:ARM/Mediatek SoC > > support) > > linux-arm-ker...@lists.infradead.org (moderated list:ARM/Mediatek SoC > > support) > > linux-media...@lists.infradead.org (moderated list:ARM/Mediatek SoC support) > > > > I specifically removed the above 3 addresses because they are all for > > Mediatek ARM chips > > while mt7621 is a mips chip and belongs to ralink target under > > /arch/mips/mach-ralink. > > Code contribution for mt7621 goes through linux-mips instead of > > linux-arm or linux-mediatek, > > I would have thought that we would still CC linux-mediatek? > > > > > I thinks this is an incorrect setup of get_maintainer.pl and should be > > corrected. > > We could ask him... > > It's always easiest to fix MAINTAINERS instead of remembering all the > exceptions and rules. Hi Matthias and other folks on linux-mediatek: I noticed that get_maintainers.pl reports "ARM/Mediatek SoC support" e-mail addreses for MTK MIPS SoCs (mt7620/mt7621/mt76x8) because of "mt[678]" name match in MAINTAINERS file. This is confusing because these MIPS SoCs clearly don't fall into "ARM" category. Is this an incorrect match or is it intentional? If it's intentional I think we should remove the confusing ARM prefix, and if it's incorrect we may need to figure out how to exclude mt7620/mt7621/mt76x8 from "ARM/Mediatek SoC support". Regards, Chuanhong Guo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
