scan for a
small set of common (and mostly trivial) mistakes in patches that I try
to do regularly. All pretty basic stuff, otherwise I wouldn't been able
to spot these mistakes.
Does this answer your question?
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
in the MODULE_LICENSE() macro. See
include/linux/module.h.)
st-cpufreq.o can only be built-in. But the code contains of few lines
that are only useful if the code can be modular. Was ARM_ST_CPUFREQ
perhaps meant to be tristate?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line
.2385.152.camel@x220 . So that's
already being worked on.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
pears to do) also enable module auto-loading? That would mean there's
another, even less obvious, mechanism at work here.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
mi-i2s-audio" name.
So I wonder whether this MODULE_ALIAS() is actually needed. What breaks
if you leave it out?
(Likewise for 5/6, but there the platform_device should have a
"rockchip-hdmi-audio" name.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
s the license is GPL
v2 or later. So I think that either the comment at the top of this file
or the ident used in the MODULE_LICENSE() macro needs to change.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
. So that's
already being worked on.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
. What breaks
if you leave it out?
(Likewise for 5/6, but there the platform_device should have a
rockchip-hdmi-audio name.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
that either the comment at the top of this file
or the ident used in the MODULE_LICENSE() macro needs to change.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
? That would mean there's
another, even less obvious, mechanism at work here.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
n only code
using module specific constructs.
> I can anyway shove out these macros to end the discussion.
I'd rather convince you than annoy you into doing as I suggested.
> BTW whether you buy the argument or not, please do treat yourself
> with ice cream for being able to make such
.
I can anyway shove out these macros to end the discussion.
I'd rather convince you than annoy you into doing as I suggested.
BTW whether you buy the argument or not, please do treat yourself
with ice cream for being able to make such a comment.
Will do.
Thanks,
Paul Bolle
o isn't needed
here, as I couldn't find a platform_device using that name. (But perhaps
a patch that adds it is pending, somewhere.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
is export. Actually, it doesn't even
add a local caller of this function. Is a patch that adds a user of this
function queued somewhere?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
k might be moved to 3/4, if you like to entertain pedantry like
that, that is. (But see my remark on 3/4 too.)
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
itting this, but with
PCI_SUBVENDOR_ID_IBM involved.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
The MODULE_SUPPORTED_DEVICE macro is documented as
Not Yet Implemented
for over a decade now. It will clearly never be implemented. Remove it
from the places where it's currently used.
Not-yet-signed-off-by: Paul Bolle
---
Jiri,
I'm thinking about doing this cleanup. Would you
The MODULE_SUPPORTED_DEVICE macro is documented as
Not Yet Implemented
for over a decade now. It will clearly never be implemented. Remove a
reference to it from a DocBook template.
Signed-off-by: Paul Bolle
---
Module "classes"? I removed that too.
Running "make xmldo
when it's created. That would be a platform_device using a
"atmel_flexcom" name.
If that's correct, then I think this MODULE_ALIAS macro isn't needed
here, as I couldn't find a platform_device using that name. (But perhaps
a patch that adds it is pending, somewhere.)
Thanks,
Paul Bolle
be a platform_device using a
atmel_flexcom name.
If that's correct, then I think this MODULE_ALIAS macro isn't needed
here, as I couldn't find a platform_device using that name. (But perhaps
a patch that adds it is pending, somewhere.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line
The MODULE_SUPPORTED_DEVICE macro is documented as
Not Yet Implemented
for over a decade now. It will clearly never be implemented. Remove a
reference to it from a DocBook template.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Module classes? I removed that too.
Running make xmldocs
The MODULE_SUPPORTED_DEVICE macro is documented as
Not Yet Implemented
for over a decade now. It will clearly never be implemented. Remove it
from the places where it's currently used.
Not-yet-signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Jiri,
I'm thinking about doing this cleanup
pedantry like
that, that is. (But see my remark on 3/4 too.)
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
pci_set_power_state(drm_dev-pdev, PCI_D3hot);
return 0;
Just two days ago we discussed this bug too, see
https://lkml.org/lkml/2015/6/17/327 . That message contains a link to a
patch I cobbled together for yet another ThinkPad hitting this, but with
PCI_SUBVENDOR_ID_IBM involved.
Paul
that name. (But perhaps
a patch that adds it is pending, somewhere.)
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
of this function. Is a patch that adds a user of this
function queued somewhere?
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Hi Shobhit,
On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote:
> On Fri, May 1, 2015 at 2:42 AM, Paul Bolle wrote:
> > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
> >> --- a/drivers/pwm/Kconfig
> >> +++ b/drivers/pwm/Kconfig
> >
> >&
this driver to build.
Discussing those two disabilities doesn't require a (much broader)
discussion on how Atmel goes about their Linux business. At least, I
hope it doesn't, because I don't actually have an opinion in that
matter.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send
l can't read! Na na na na
na! Paul can't read!"
> Ok, so I post sama5d2 early support today so that we can agree it's not
> necessary to add superfluous steps.
I see.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
out correctly.) Perhaps reviewers skip over
the boilerplate stuff.
> Until now no animal was hurt with it.
Sure, no overhead and all that. No value too.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
ecause it follows from the above that this line
serves no purpose. Worse, it makes the code actually confusing. Because
it suggests the availability of functionality that in reality doesn't
exist.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscr
for clarification if so. Perhaps I was wrong.
Then you're free to correct me. But, please, rate limit your patch
versions. You've sent a version on Monday, Tuesday, and Wednesday. That
mainly will make people to filter out your patches. I won't be looking
at a new version for another week now, sorr
Hi Alexander,
On Thu, 2015-06-18 at 09:40 +0200, Alexander Sverdlin wrote:
> On 17/06/15 18:03, ext Paul Bolle wrote:
> >> You do not see the platform_device, because there are no users yet, put
> >> > this MODULE_ALIAS() is perfectly fine, it will allow automati
eviewed or even better merged in order to ease this new
> SoC landing...
The other side of that is that the sama5d2 might never make it, or take
very long to make it, into mainline. And this would then end up being
yet another chunk of code adding no value to mainline.
Thanks,
Paul Bolle
--
T
On Thu, 2015-06-18 at 09:33 +0200, Boris Brezillon wrote:
> I guess it will be selected by platforms embedding such clks. We just
> have to wait for those platform to reach mainline ;-).
So what's the point of this patch at this moment?
Paul Bolle
--
To unsubscribe from this list
select HAVE_AT91_GENERATED
somewhere (possibly even in a second patch). But as it stands the patch
looks like an elaborate NOP.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
post sama5d2 early support today so that we can agree it's not
necessary to add superfluous steps.
I see.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
this driver to build.
Discussing those two disabilities doesn't require a (much broader)
discussion on how Atmel goes about their Linux business. At least, I
hope it doesn't, because I don't actually have an opinion in that
matter.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send
Hi Shobhit,
On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote:
On Fri, May 1, 2015 at 2:42 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
+config PWM_CRC
+ bool Intel
(possibly even in a second patch). But as it stands the patch
looks like an elaborate NOP.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
correctly.) Perhaps reviewers skip over
the boilerplate stuff.
Until now no animal was hurt with it.
Sure, no overhead and all that. No value too.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
Hi Alexander,
On Thu, 2015-06-18 at 09:40 +0200, Alexander Sverdlin wrote:
On 17/06/15 18:03, ext Paul Bolle wrote:
You do not see the platform_device, because there are no users yet, put
this MODULE_ALIAS() is perfectly fine, it will allow automatic module
loading
in non-DT case
On Thu, 2015-06-18 at 09:33 +0200, Boris Brezillon wrote:
I guess it will be selected by platforms embedding such clks. We just
have to wait for those platform to reach mainline ;-).
So what's the point of this patch at this moment?
Paul Bolle
--
To unsubscribe from this list: send the line
merged in order to ease this new
SoC landing...
The other side of that is that the sama5d2 might never make it, or take
very long to make it, into mainline. And this would then end up being
yet another chunk of code adding no value to mainline.
Thanks,
Paul Bolle
--
To unsubscribe from
. Perhaps I was wrong.
Then you're free to correct me. But, please, rate limit your patch
versions. You've sent a version on Monday, Tuesday, and Wednesday. That
mainly will make people to filter out your patches. I won't be looking
at a new version for another week now, sorry.
Thanks,
Paul Bolle
no purpose. Worse, it makes the code actually confusing. Because
it suggests the availability of functionality that in reality doesn't
exist.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
ding once the patch
that adds a struct platform_device with a "i2c-mux-reg" name lands?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
AGP thingy, and/or broken RV250 (or the interaction of
these things or whatever). Maddening stuff, impossible to debug.
Good luck,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
lkml/2015/3/18/133 . So I
think that's another system not covered by commit ab3be73fa7b4
("drm/i915: gen4: work around hang during hibernation").
Hope this helps,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
>
> Unfortunately, not as far as I know.
>
> > If yes it might be a good idea to bisect to narrow down the problem.
>
> No such luck. I may try something like "3.0" if we are really
> desperate (2.6.X kernels probably won't won't boot with recent
> userland)
if that doesn't break stuff
left and right without additional changes (which this patch lacks).
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger
ot;
uevent when it's created. (I don't know exactly how all that works, so
I'm handwaving quite a bit here.) That would be platform_device with a
"i2c-mux-reg" name.
Did I get this right? Because then I think this MODULE_ALIAS() isn't
needed, as I couldn't find such a corresponding p
(which this patch lacks).
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
that works, so
I'm handwaving quite a bit here.) That would be platform_device with a
i2c-mux-reg name.
Did I get this right? Because then I think this MODULE_ALIAS() isn't
needed, as I couldn't find such a corresponding platform_device.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send
://bugzilla.redhat.com/show_bug.cgi?id=531825 for a lot of
background.
Does booting with radeon.agpmode=1 survive a suspend and resume cycle?
Hope this helps,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
ab3be73fa7b4
(drm/i915: gen4: work around hang during hibernation).
Hope this helps,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
or whatever). Maddening stuff, impossible to debug.
Good luck,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
the patch
that adds a struct platform_device with a i2c-mux-reg name lands?
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
opt the .config to the
toolchain at hand. As long as we don't do anything funny once we've
generated the .config file that might just work.
Yes, I know, the devil hides in the details.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
t would
not be possible tries to build a kernel with that symbol set? That
person's .config would end up containing
# CONFIG_AS_AVX2 is not set
or similar, right?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
borate, because now you've left me and, perhaps, the
other people reading this wondering what "toolchain dependencies"
actually means and what those "bunch of reasons" are.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> +++ b/include/dt-bindings/clock/clk-si5338.h
> +#ifndef _DT_BINDINGS_CLK_DSI5338_H
> +#define _DT_BINDINGS_CLK_DSI5338_H
(I spotted a D that looks odd here.)
And git am whines:
new blank line at EOF.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I think that either the comment at the top of this file or
the ident used in the MODULE_LICENSE() macro needs to change.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
t (easily and cleanly) unload this module. Which is
uncommon enough for me to inquire whether that was by design.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at htt
now you've left me and, perhaps, the
other people reading this wondering what toolchain dependencies
actually means and what those bunch of reasons are.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
a kernel with that symbol set? That
person's .config would end up containing
# CONFIG_AS_AVX2 is not set
or similar, right?
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
the .config to the
toolchain at hand. As long as we don't do anything funny once we've
generated the .config file that might just work.
Yes, I know, the devil hides in the details.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
and cleanly) unload this module. Which is
uncommon enough for me to inquire whether that was by design.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
at the top of this file or
the ident used in the MODULE_LICENSE() macro needs to change.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
spotted a D that looks odd here.)
And git am whines:
new blank line at EOF.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t; power
> + management unit is designed or saving power when RK3288 in low
> power
> + mode. The RK3288 PMU is dedicated for managing the power ot the
> whole chip.
s/ot/of/
> + If unsure, say N.
Thanks,
Paul Bolle
--
To unsubscribe from this list:
s of "#if IS_ENABLED(CONFIG_USB)" and "#if IS_ENABLED(CONFIG_PCI)"
in the code. The above function is a rather ugly example.
Is there a point to all this if neither PCI nor USB is enabled?
USB can be 'm'. Does this build and work in that case?
There's no MODULE_LICENSE() macro. I
that's, well, called by module_exit() that undoes
the above. So one can build this as a module, load that module, but not
unload it. That's by design?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
by module_exit() that undoes
the above. So one can build this as a module, load that module, but not
unload it. That's by design?
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
or saving power when RK3288 in low
power
+ mode. The RK3288 PMU is dedicated for managing the power ot the
whole chip.
s/ot/of/
+ If unsure, say N.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
DEV_OVERLAYMGR to be bool instead?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CENSE("GPL");
The comment at the top of this file states the license is GPL v2. The
MODULE_LICENSE() macro states, according to include/linux/module.h, that
the license is GPL v2 or later. So I think one of these two needs to
change.
I spotted the same license mismatch in 2/4, 3/4 and 4/4
) in
arch/powerpc/. That approach tells me this function could be static and
marked as __init. Would that work here too?
> +{
> + [...]
> +}
> +
> +/* need to call this before SMP init */
> +early_initcall(fsl_rcpm_init);
Thanks,
Paul Bolle
--
To unsubscribe from this list:
invalidate);
I couldn't spot any users of these exports. Actually, I couldn't even
spot any users of these three functions. Why were they added?
> +MODULE_LICENSE("GPL");
This states, according to include/linux/module.h, that the license is
GPL v2 or later. So I think either the comment
utomatically
> + generates ECC inside NAND chip.
> +
> --- /dev/null
> +++ b/drivers/mtd/nand/nand_benand.c
> +EXPORT_SYMBOL(nand_benand_status_chk);
I didn't spot any users of nand_benand_status_chk() outside of this
file. Why is this export needed?
Thanks,
Paul Bol
On Fri, 2015-06-12 at 09:55 +0800, Koro Chen wrote:
> On Thu, 2015-06-11 at 09:03 +0200, Paul Bolle wrote:
> > (What does negating a bool twice do?)
> >
> Because bool actually can be unsigned char, although actually in this
> driver, the caller always passes "true&qu
were they added?
+MODULE_LICENSE(GPL);
This states, according to include/linux/module.h, that the license is
GPL v2 or later. So I think either the comment at the top of this file
or the ident used in the MODULE_LICENSE() macro needs to change.
Thanks,
Paul Bolle
--
To unsubscribe from
, that
the license is GPL v2 or later. So I think one of these two needs to
change.
I spotted the same license mismatch in 2/4, 3/4 and 4/4.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
/powerpc/. That approach tells me this function could be static and
marked as __init. Would that work here too?
+{
+ [...]
+}
+
+/* need to call this before SMP init */
+early_initcall(fsl_rcpm_init);
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux
On Fri, 2015-06-12 at 09:55 +0800, Koro Chen wrote:
On Thu, 2015-06-11 at 09:03 +0200, Paul Bolle wrote:
(What does negating a bool twice do?)
Because bool actually can be unsigned char, although actually in this
driver, the caller always passes true or false to this function.
bool
.
+
--- /dev/null
+++ b/drivers/mtd/nand/nand_benand.c
+EXPORT_SYMBOL(nand_benand_status_chk);
I didn't spot any users of nand_benand_status_chk() outside of this
file. Why is this export needed?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Thu, 2015-06-11 at 18:05 +0800, Yi Zhang wrote:
> On Tue, Jun 09, 2015 at 02:14:11PM +0200, Paul Bolle wrote:
> > On Mon, 2015-06-08 at 20:55 +0800, Yi Zhang wrote:
> > > --- /dev/null
> > > +++ b/drivers/mfd/88pm880-table.c
> >
> > > +#include
, and the other I4L drivers, should be (finally) tossed
out? That was discussed last year too, but nothing really was decided.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo in
orrect, this is not an urgent request, but
a chronic issue. So in that case anyone who cares about OpenRISC should
consider taking over. Because this looks like an orphaned architecture
to me.
Am I being too strict?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
So I couldn't help having yet another look at the code, just to drive
home my point.
On Thu, 2015-06-11 at 10:55 +0200, Paul Bolle wrote:
> > +void *fm_drv_init(void)
>
> static.
>
> > +{
> > + memset(_drvs, 0, sizeof(fm_drvs));
fm_drvs is an external variable.
iver);
> + mutex_destroy(_drv_mutex);
> +
> + return 0;
> +}
And p_fm_drv is unused in the function (and see below).
> +static void *p_fm_drv;
> +static int __init __cold fm_load(void)
> +{
> + p_fm_drv = fm_drv_init();
> + if (!p_fm_drv) {
>
On Thu, 2015-06-11 at 09:03 +0200, Paul Bolle wrote:
> Is SND_SOC_MEDIATEK perhaps meant to be bool?
s/bool/tristate/, of course.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
But the code uses a few module specific constructs. I spotted
THIS_MODULE, MODULE_DESCRIPTION, MODULE_AUTHOR, MODULE_LICENSE, and
MODULE_DEVICE_TABLE.
Is SND_SOC_MEDIATEK perhaps meant to be bool?
Likewise for SND_SOC_MT8173_MAX98090 (in 2/3) and
SND_SOC_MT8173_RT5650_RT5676 (in 3/3).
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
, should be (finally) tossed
out? That was discussed last year too, but nothing really was decided.
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
So I couldn't help having yet another look at the code, just to drive
home my point.
On Thu, 2015-06-11 at 10:55 +0200, Paul Bolle wrote:
+void *fm_drv_init(void)
static.
+{
+ memset(fm_drvs, 0, sizeof(fm_drvs));
fm_drvs is an external variable. It is guaranteed to be zero, isn't
perhaps meant to be tristate?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
, this is not an urgent request, but
a chronic issue. So in that case anyone who cares about OpenRISC should
consider taking over. Because this looks like an orphaned architecture
to me.
Am I being too strict?
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, 2015-06-11 at 18:05 +0800, Yi Zhang wrote:
On Tue, Jun 09, 2015 at 02:14:11PM +0200, Paul Bolle wrote:
On Mon, 2015-06-08 at 20:55 +0800, Yi Zhang wrote:
--- /dev/null
+++ b/drivers/mfd/88pm880-table.c
+#include linux/module.h
I'm _guessing_ this could as well be linux
).
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2015-06-11 at 09:03 +0200, Paul Bolle wrote:
Is SND_SOC_MEDIATEK perhaps meant to be bool?
s/bool/tristate/, of course.
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
601 - 700 of 4150 matches
Mail list logo
