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
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 m
dopt 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-k
eg"
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 fi
d. I'd be surprised 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
t; worked?
>
> 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 r
/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 messa
P 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
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/majord
or add
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
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 lis
de from being reviewed 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,
P
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
states 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/
quot;dw-hdmi-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/
ch
appears 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/
23861.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/
uot;);
> +MODULE_LICENSE("GPL v2");
(There's a mismatch between the license used in the comment at the top
of this file and the ident used 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
h was the result of a manual 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 t
On Tue, 2015-06-23 at 15:17 -0400, Benjamin Tissoires wrote:
> drivers/input/rmi4/Kconfig | 5 +
> drivers/input/rmi4/Makefile | 2 +-
> drivers/input/rmi4/rmi_bus.c| 11 ++-
> drivers/input/rmi4/rmi_driver.h | 8
> drivers/input/rmi4/rmi_f11.c| 10
> +module_exit(kinetis_pinctrl_exit);
> +
> +MODULE_DESCRIPTION("Freescale Kinetis pinctrl driver");
> +MODULE_LICENSE("GPL v2");
pinctrl-kinetis.o can only be built-in, right? But the code uses a few
module specific constructs. Did you mean to make PINCTRL_KINETIS
trista
hat will fire of a "MODALIAS=platform:xilinx
-mailbox" when it's created.
I couldn't spot such a platform_device. Provided git grep didn't let me
down here: what breaks if this line is dropped?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "un
r_driver(&asusrb_driver);
> +
> + if (asuspl_dev) {
If asusrb_exit() will be run asusrb_init() must have completed
successfully before, right? And is there a way for asuspl_dev to be
NULL after asusrb_init() succeeded?
> + platform_device_unregister(asuspl_dev);
> +
)
> + c8sectpfe-y += c8sectpfe-debugfs.o
> +endif
Isn't the above equivalent to
c8sectpfe-y += c8sectpfe-core.o c8sectpfe-common.o c8sectpfe-dvb.o
c8sectpfe-debugfs.o
obj-$(CONFIG_DVB_C8SECTPFE) += c8sectpfe.o
Or am I missing something subtle here?
Paul Bolle
--
To unsu
On Thu, 2015-06-25 at 08:55 +0200, Michal Simek wrote:
> On 06/24/2015 10:36 PM, Paul Bolle wrote:
> > On Tue, 2015-06-23 at 11:00 -0700, Moritz Fischer wrote:
> > > +MODULE_ALIAS("platform:xilinx-mailbox");
> >
> > So I think this MODULE_ALIAS() is
the point of this line. As I
asked in my first message: what breaks if this line is dropped?
> Also it is quite common that users create own BSP for their custom
> boards but they don't push it to mainline.
I can't recall what BSP means. Anyhow, why should we care about boards
not pu
WARNING: "rsa_pkcs1_v1_5_verify_signature"
[[...]/crypto/asymmetric_keys/public_key.ko] undefined!
Also no MODULE_LICENSE() macro, so loading rsa_pkcs1_v1_5.ko should
trigger a warning and taint the kernel.
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/
; +{
> + return platform_driver_register(&gpio_wdt_driver);
> +}
> +arch_initcall(gpio_wdt_init);
> +#else
> module_platform_driver(gpio_wdt_driver);
> +#endif
The entire patch is basically an elaborate NOP. How did this pass your
testing?
Paul Bolle
--
To unsubscribe from thi
c_dev))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +static int vf610_soc_remove(struct platform_device *pdev)
> +{
> + struct vf610_soc *info = platform_get_drvdata(pdev);
> +
> + if (info->soc_dev)
> + soc_device_unr
are not rhetorical questions. I actually wonder whether there a
reasons not to mark module_init() and module_exit() functions with
__init and __exit.)
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/
m_calxedaxgmac_exit(void)
> +{
> +}
> +
> +module_init(vfio_platform_calxedaxgmac_init);
> +module_exit(vfio_platform_calxedaxgmac_exit);
Just a nit: I think it's OK to leave out these functions if they both do
nothing. See delete_module in kernel/module.c.
Paul Bolle
--
To unsubscrib
On Sat, 2015-06-06 at 14:56 +0200, Valentin Rothberg wrote:
> On Sat, Jun 06, 2015 at 12:03:06PM +0200, Paul Bolle wrote:
> > On Sat, 2015-06-06 at 00:46 -0700, Jean-Baptiste Theou wrote:
> > > +#ifdef GPIO_WATCHDOG_ARCH_INITCALL
> >
> > You meant
> > #ifde
On Tue, 2015-06-02 at 16:16 -0400, Paul Gortmaker wrote:
> +static void __init serial_exit(void)
s/__init/__exit/
> +{
> + platform_device_unregister(&uart8250_device);
> +}
> +module_exit(serial_exit);
Paul Bolle
--
To unsubscribe from this list: send the line "
; +static IIO_DEVICE_ATTR(threshold_socval, S_IRUGO | S_IWUSR,
> + hi843x_threshold_socval_show, hi843x_threshold_socval_store, 0);
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/
is not needed.)
> + }
If I scanned this correctly, the dev_set_drvdata() and dev_get_drvdata()
pair adds an actual user of ufs_hba_qcom_vops. So that ends the obvious
issue I think the code currently has. And I gladly defer to the scsi
people to determine whether that is done the right way.
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-04 at 16:07 +0200, Paul Bolle wrote:
> On Wed, 2015-06-03 at 12:37 +0300, Yaniv Gardi wrote:
> > +static int ufs_qcom_probe(struct platform_device *pdev)
> > +{
> > + dev_set_drvdata(&pdev->dev, (void *)&ufs_hba_qcom_vops);
>
> (Cast to
the MODULE_LICENSE() macro needs to
change.
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/
ult "rtc0"
> + help
> + The RTC device used for NTP synchronization. The main difference
> + between RTC_HCTOSYS_DEVICE and RTC_SYSTOHC_DEVICE is that this
> + one can sleep when setting time, because it runs in the workqueue
> + context.
Paul Boll
any, or maybe even most, of
the changes are really not interesting enough to keep in the commit
explanation.)
> --- /dev/null
> +++ b/drivers/firmware/raspberrypi.c
> +EXPORT_SYMBOL_GPL(rpi_firmware_property_list);
> +EXPORT_SYMBOL_GPL(rpi_firmware_property);
A patch that uses these expor
re should be a From line at the top.
Even if you're the author of this patch a From: line is needed.
Otherwise "majun (F) " would become the author,
instead of "Ma Jun ", and "majun (F)" is probably
not your name.
Thanks,
Paul Bolle
--
To unsub
On Sat, 2015-05-30 at 14:59 -0400, Dan Williams wrote:
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> +config ARCH_HAS_PMEM_API
> + def_bool n
'n' is the default anyway, so I think
config ARCH_HAS_PMEM_API
bool
should work just as well.
Paul Bolle
--
To unsu
\n", __func__,
reg_size, val_size, reg_data[0], *((u8 *)val));
return 0;
} else if (ret < 0)
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/
of sane. By that time I usually give up.)
Downside is, of course, that you can build things outside of the
supported configurations. So it's best to state clearly that one built
something using this hack. I sinned against that rule, but apparently
got lucky, because this driver is not
On Tue, 2015-06-09 at 08:03 +0200, Michal Simek wrote:
> Have you sent any patch to add GPL v2+ to license.h?
"GPL" already means GPL v2 or later (see include/linux/module.h).
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
or twice a week.
Did I miss anything in that list?
I'm afraid that most of the above can only be caught reliably by
attention to detail by submitters and reviewers. That's a pity, because
checking for that stuff is about as boring as it gets. (What does that
say about me?)
T
ring checks this
currently requires. And, of course, that new way, whatever that might
be, can probably not just replace the many thousands instances of the
MODULE_LICENSE() macro that there currently are. People being not to
keen on seeing their code being, well, relicensed.
Paul Bolle
--
To
device_initcall(mt8173_cpufreq_driver_init);
Why don't you just use that directly?
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
On Tue, 2015-06-09 at 12:41 +0200, Michal Simek wrote:
> On 06/09/2015 10:15 AM, Paul Bolle wrote:
> > Mistakes I've seen made since I started checking this stuff (a few
> > months ago):
> > - typos in the license ident, say "GPLv2", "GPL V2", or
= 88pm88x-core.o 88pm88x-i2c.o 88pm88x-irq.o
> 88pm886-table.o 88pm880-table.o
> +obj-$(CONFIG_MFD_88PM88X)+= 88pm88x.o
MFD_88PM88X is bool, but the patch adds module specific code too (ie,
code that serves no purpose when built-in). Did you perhaps intend for
MFD_88PM88X 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/
side I note that very few new mismatches get added (at
least, I tricked myself into believing that).
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
PL v2.
> +MODULE_LICENSE("GPL");
And, according to include/linux/module.h, this states 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.
Paul Bolle
--
To unsubscribe from
ND)+= nand_benand.o
So there's another patch that adds drivers/mtd/nand/nand_benand.c?
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.kerne
ly.
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,
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 majo
_drv)
static.
> +{
> + platform_driver_unregister(&fm_driver);
> + mutex_destroy(&fm_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)
>
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 v
correct, 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 li
unclear. Ask 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 vers
t right? Because 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
d it 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 o
t;Paul 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-ker
pending that would allow 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
--
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
> >
> >&
vent 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, somewher
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 xmldocs&qu
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. Wo
ThinkPad hitting 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/
ight 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/
of this 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/
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 "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
e of the non-obvious issues caused by built-in 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
>
a local branch for over five years, but
never dared to push it upstream.
Does it still apply?
Thanks,
Paul Bolle
-- >8 ---
>From 0f73c8ee776c197e3029c4eed21af0f121a8f9d3 Mon Sep 17 00:00:00 2001
From: Paul Bolle
Date: Tue, 4 Feb 2014 22:22:48 +0100
Subject: [PATCH] headers_check: enab
Paul Bolle schreef op di 09-04-2019 om 21:11 [+0200]:
> Does it still apply?
It does, cleanly. Output is (for v5.1-rc4):
./usr/include/asm-generic/fcntl.h:119: leaks CONFIG_64BIT to userspace where it
is not valid
./usr/include/asm-generic/mman-common.h:22: le
ed and evaluates to n.
> The default values are probably only for convenience, so 88EU_AP_MODE and
> 88EU_P2P are activated together with 8188EU. They still can be turned off.
> Anyway, it should probably say "default y" in both cases.
Ditto.
Paul Bolle
--
To unsubscribe from this lis
On Sat, 2013-11-02 at 17:40 -0200, Mauro Carvalho Chehab wrote:
> Em Sat, 02 Nov 2013 20:20:54 +0100
> Paul Bolle escreveu:
> > Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like
> > to send the trivial patch to fix this?
>
> Yes, it is a typo
core.c:pcie_port_device_register(). Is that
correct? But what should then be done if pci_enable_device() fails?
And Bjorn's question - what's the point of this warning if
pci_set_master() will be called anyway - also came up when I looked at
that code segment for the first time. But I&#x
ve finally managed to bisect these messages to commit 202317a573b2
("ACPI / scan: Add acpi_device objects for all device nodes in the
namespace"). That's a rather big commit, so I've not even bothered to
try to revert it on top on v3.14-rc6.
2) What should I do to make that erro
Rafael J. Wysocki schreef op ma 17-03-2014 om 01:02 [+0100]:
> On Sunday, March 16, 2014 10:41:35 PM Paul Bolle wrote:
> > 2) What should I do to make that error go away?
>
> This is not an error, but a message whose log level is too high. It basically
> means "I found
On Tue, 2014-02-25 at 10:05 +0200, Jani Nikula wrote:
> On Thu, 20 Feb 2014, Paul Bolle wrote:
> > On an (rather old) ThinkPad X41, which also uses i915, brightness
> > adjustments stopped working altogether in v3.14-rc1 (I haven't used its
> > docking station in th
^
Silence this warning by using min_t(). Since cur_size will never be
negative and its upper bound is PAGE_SIZE, we can change its type to
size_t and use min_t(size_t, [...]) here.
Signed-off-by: Paul Bolle
---
v2: use min_t() as Ilia suggested, and convert cur_size to size_t, as
Thier
reorganize the code to help GCC
understand the flow of this code. So take the easy way out and
initialize bvprv to { NULL }.
And, since we're touching this code, make first a bool.
Signed-off-by: Paul Bolle
---
v2: redone, as required by Keith's review. Note that initializing bvprv
t
ings popped up in v3.14-rc1. (In v3.13 bvprv was a pointer
initialized to NULL.) This patch is not urgent, but it would still be
nice if the warnings were silenced in v3.14, since they are so noisy. Is
there any tree that queues NVMe fixes to be applied during this release
cycle?
> On Tue, 4 Mar 20
et this flag, if I'm
not misunderstanding Joe.) For what it's worth, I've added the list of
these (for v3.14-rc5) below.
Paul Bolle
v3.14-rc5:arch/powerpc/platforms/pseries/Makefile:ccflags-$(CONFIG_PPC_PSERIES_DEBUG)
+= -DDEBUG
v3.14-rc5:drivers/base/Makefile:ccflags-$(CO
look at.
I hope to do a bisect in the next few days. If that bisect pinpoints an
interesting commit that might just be in time for v3.14.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
On Mon, 2014-02-24 at 20:38 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 24.02.2014 19:39, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 18, 2014 at 11:14:27AM +0100, Paul Bolle wrote:
> >> And that commit was reverted
Steven,
On Wed, 2014-02-26 at 18:35 +0800, Steven Miao wrote:
> On Thu, Feb 13, 2014 at 5:40 PM, Paul Bolle wrote:
> >> 1) There are many lines that might be converted to IS_ENABLED() in this
> >> file. I'm not sure if and how that should be done.
> Sorry for t
On Wed, 2014-02-12 at 16:04 +, Mark Brown wrote:
> On Mon, Feb 10, 2014 at 11:09:19PM +0100, Paul Bolle wrote:
> > See, if you scan v3.10:arch/arm/mach-exynos/mach-smdkv310.c you'll
> > notice the string "smdk-audio". If you grep that string you get a few
> &g
Signed-off-by: Paul Bolle
---
Untested.
Another option would be to drop this comment, but perhaps someone finds
it useful, somehow.
include/uapi/linux/capi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/capi.h b/include/uapi/linux/capi.h
index 65100d6
W: http://www.monstr.eu/fdt/
> T: git git://git.monstr.eu/linux-2.6-microblaze.git
> S: Supported
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/
Signed-off-by: Paul Bolle
---
0) This typo was introduced in commit 0d47acc4ffaa ("ASoC: smdk_wm8994:
Make driver name more unique").
1) So currently there's a difference between platform_drive.driver.name
and the (sub)string used in MODULE_ALIAS(). If I'd understand
On Mon, 2014-02-10 at 16:36 +, Mark Brown wrote:
> On Mon, Feb 10, 2014 at 04:30:42PM +0100, Paul Bolle wrote:
> > So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were
> > removed in commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for
> >
entry is used to set the DEBUG
compiler flag, which enables calls of dev_dbg().
So add a Makefile line to do that for omap4iss too.
Signed-off-by: Paul Bolle
---
0) v1 was called "[media] v4l: omap4iss: Remove VIDEO_OMAP4_DEBUG". This
versions implements Laurent's alternativ
re of a reason why these driver should be set by
default, let's just drop these lines (that basically do nothing).
Signed-off-by: Paul Bolle
---
This patch deserves a
Reported-by: Martin Walch
line, but that apparently requires Martin's permission.
drivers/usb/host/Kconfig |
Two Kconfig entries for this driver default to (uppercase) "Y". But in
Kconfig (lowercase) "y" is a magic symbol. "Y" is an ordinary symbol.
As "Y" is never set these Kconfig symbols will also not be set by
default.
So use "default y" here, a
A number of Kconfig entries default to (uppercase) "N". It was clearly
intended to use "default n". But since (lowercase) "n" is the default
anyway, these lines might as well be removed.
Signed-off-by: Paul Bolle
---
Tested on a Fedora 20-based .config, where it w
Mauro,
On Sat, 2013-11-02 at 17:40 -0200, Mauro Carvalho Chehab wrote:
> Em Sat, 02 Nov 2013 20:20:54 +0100
> Paul Bolle escreveu:
> > On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote:
> > > drivers/media/common/siano/Kconfig:21-26
> > > > config SMS_S
es first. It contains:
Please note that this tag should not be added without the reporter's
permission, especially if the problem was not reported in a public
forum.
Perhaps that should read:
[...], unless the problem was reported in a public forum.
Paul Bolle
--
To unsubscribe fro
;t they? So it
seems these lines should be wrapped with a preprocessor check for
CONFIG_MSM_OCMEM too.
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/
Dan's reply to that message.
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 Tue, 2014-02-11 at 12:29 -0500, Rob Clark wrote:
> On Tue, Feb 11, 2014 at 10:39 AM, Paul Bolle wrote:
> > Commit 55459968176f ("drm/msm: add a330/apq8x74") added preprocessor
> > checks for CONFIG_MSM_OCMEM. But I couldn't find a Kconfig symbol
> > MSM_OC
701 - 800 of 2086 matches
Mail list logo
