hides in
MODULE_DEVICE_TABLE(of, rockchip_max98090_of_match);
Which, I think, implies that any MODULE_ALIAS(platform:[...]) is
pointless for systems booting with device tree support.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
, in short, the difference between this driver and other platform
drivers is that, as far as I'm aware, this platform driver lacks a
corresponding platform device. Probably because OF support suffices to
get this module autoloaded.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line
_MODE_3,
> + .platform_data = &(struct fbtft_platform_data) {
> + .display = {
> + .buswidth = 9,
> + },
> + .gpios = (const struct fbtft_gpio []) {
> + {},
> +
_driver *const serial_drivers[] = {
> + _device, NULL
> +};
> +
If you drop this empty line ...
> +module_usb_serial_driver(serial_drivers, id_table);
and add an empty line here, things look neater.
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_AUTHOR("Peter Hong &quo
line here, things look neater.
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_AUTHOR(Peter Hong peter_h...@fintek.com.tw);
+MODULE_AUTHOR(Tom Tsai tom_t...@fintek.com.tw);
+MODULE_LICENSE(GPL);
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
,
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/
icate more data can be sent.
If "appropriate value" could be changed into something less vague
(either in this patch or in a future follow up patch) that would be
really nice.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
hat it might be in time for
v4.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/
a
few weeks so that it might finally be fixed in v4.3.
Applied.
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/
be sent.
If appropriate value could be changed into something less vague
(either in this patch or in a future follow up patch) that would be
really nice.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
in v4.3.
Applied.
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 it might be in time for
v4.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/
-lpc32xx", which will fire off a "MODALIAS=platform:spi-lpc32xx" uevent
when it's created.
I couldn't find that platform_device. Did I miss something? Or is there
another way this alias is useful?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscri
platform_device with a .name of spi
-lpc32xx, which will fire off a MODALIAS=platform:spi-lpc32xx uevent
when it's created.
I couldn't find that platform_device. Did I miss something? Or is there
another way this alias is useful?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line
+ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> +#define DRIVER_NAME "fsl-dcu-drm"
Nit: I don't think DRIVER_NAME is actually used anywhere.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
the !CONFIG_ACPI case include/linux/acpi.h contains
#define ACPI_PTR(_ptr) (NULL)
So I think the above CONFIG_ACPI guard is superfluous and can be dropped.
> +[...]
> + },
> +};
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
river = {
> + .driver = {
> + .name = DRV_NAME,
> + .of_match_table = of_fsl_qman_ids,
> + },
> + .probe = of_fsl_qman_probe,
> + .remove = of_fsl_qman_remove,
> +};
> +
> +module_platform_driver(of_fsl_qman_driver);
As of v4.2-rc1 you can use built
builtin_platform_driver() for built-in only
code.
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/
/linux/acpi.h contains
#define ACPI_PTR(_ptr) (NULL)
So I think the above CONFIG_ACPI guard is superfluous and can be dropped.
+[...]
+ },
+};
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
DRIVER_NAME fsl-dcu-drm
Nit: I don't think DRIVER_NAME is actually used anywhere.
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
to upstream
> these drivers.
At the end of the day, what matters is what the people that need to sign
off on these drivers (ppc? netdev?) are comfortable with. I know that
some maintainers won't even bother looking at code that has no callers.
In the mean time I'll skip the exports for the re
drivers/soc/fsl/qbman/dpaa_sys.h
>
> +#define CONFIG_TRY_BETTER_MEMCPY
Please replace the CONFIG_ prefix with something else.
> +#ifdef CONFIG_TRY_BETTER_MEMCPY
This will always be true, right?
> [...]
> +#else
> +#define copy_words memcpy
> +#define copy_shorts memcpy
> +#defi
t("ASSERT: (%s:%d) %s\n", __FILE__, __LINE__, \
> + __stringify_1(x)); \
> + dump_stack(); \
> + panic("assertion failure"); \
Not my call, but why panic() here?
> + } \
> + } while (0)
On vr, 2015-07-10 at 08:53 +0530, Vaishali Thakkar wrote:
> I thought about this solution before sending this patch. But I was not
> sure about it. Thanks for the explanation. I will send v3 with this
> change.
>
> Can I add Suggested By: Paul Bolle
That should be "Sug
e warnings being treated as errors
scripts/Makefile.build:264: recipe for target
'[...]/drivers/soc/fsl/qbman/bman.o' failed
make[1]: *** [[...]/drivers/soc/fsl/qbman/bman.o] Error 1
Makefile:1568: recipe for target 'bman.ko' failed
make: *** [bman.ko] Error 2
make: Leaving directory '[...]'
Thanks,
Paul
/bman.o' failed
make[1]: *** [[...]/drivers/soc/fsl/qbman/bman.o] Error 1
Makefile:1568: recipe for target 'bman.ko' failed
make: *** [bman.ko] Error 2
make: Leaving directory '[...]'
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On vr, 2015-07-10 at 08:53 +0530, Vaishali Thakkar wrote:
I thought about this solution before sending this patch. But I was not
sure about it. Thanks for the explanation. I will send v3 with this
change.
Can I add Suggested By: Paul Bolle pebo...@tiscali.nl
That should be Suggested
(0)
+#else
+#define DPA_ASSERT(x)
+#endif
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
+#define copy_shorts memcpy
+#define copy_bytes memcpy
+#endif
--- /dev/null
+++ b/include/soc/fsl/bman.h
+static inline int bman_reserve_bpid(u32 bpid)
+{
+ return bman_reserve_bpid_range(bpid, 1);
+}
Unused.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe
matters is what the people that need to sign
off on these drivers (ppc? netdev?) are comfortable with. I know that
some maintainers won't even bother looking at code that has no callers.
In the mean time I'll skip the exports for the remainder of this series.
Thanks,
Paul Bolle
--
To unsubscribe
ONFIG_CORESIGHT_LINKS_AND_SINKS is
defined. CORESIGHT_LINKS_AND_SINKS is a bool symbol. It depends on
CORESIGHT, which is also a bool symbol. CORESIGHT is a top level symbol,
available on arm and arm64.
I think coresight-replicator.o can only be built-in. So I suggest to use
builtin_platform_driver() instead.
Thanks,
P
I
couldn't find the struct platform_device's that would, in short, fire
off the corresponding "MODALIAS=platform:mv88e6[...]" uevent when
they're created. Where should I look for those struct platform_device's?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "
and the maintainer
(Linus?). I just prefer if you'd be consistent with that choice (ie, you
should not use module specific code in a built-in only driver).
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
.of_match_table = st_fdma_xbar_match,
> + },
> + .probe = st_fdma_xbar_probe,
> + .remove = st_fdma_xbar_remove,
> +};
> +module_platform_driver(st_fdma_xbar_driver);
See my remark on 3/7: builtin_platform_driver().
> +MODULE_LICENSE("GPL v2");
> +M
*chan, void *param)
> +{
> + [...]
> +}
> +EXPORT_SYMBOL(st_fdma_filter_fn);
This series adds no users of this export. I suppose they will be added
in another series. Is that correct?
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("STMicroelect
engine driver);
+MODULE_AUTHOR(Ludovic.barre ludovic.ba...@st.com);
These macros will, basically, be preprocessed away for built-in only
code.
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
(st_fdma_xbar_driver);
See my remark on 3/7: builtin_platform_driver().
+MODULE_LICENSE(GPL v2);
+MODULE_DESCRIPTION(STMicroelectronics FDMA cross bar);
+MODULE_AUTHOR(Ludovic.barre ludovic.ba...@st.com);
See my remark on 3/7: will be preprocessed away.
Thanks,
Paul Bolle
--
To unsubscribe
[...] uevent when
they're created. Where should I look for those struct platform_device's?
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
just prefer if you'd be consistent with that choice (ie, you
should not use module specific code in a built-in only driver).
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
. CORESIGHT_LINKS_AND_SINKS is a bool symbol. It depends on
CORESIGHT, which is also a bool symbol. CORESIGHT is a top level symbol,
available on arm and arm64.
I think coresight-replicator.o can only be built-in. So I suggest to use
builtin_platform_driver() instead.
Thanks,
Paul Bolle
--
To unsubscribe from
it's an anti-pattern
nevertheless. See the discussion that Shobhit Kumar, Paul Gortmaker, and
I had starting in https://lkml.org/lkml/2015/6/20/63 .
Please let me know if you're unconvinced by the arguments brought
forward by both Pauls in that discussion.
Thanks,
Paul Bolle
--
To unsubscribe fr
On wo, 2015-07-08 at 20:47 +0200, Espen Carlsen wrote:
> I assume your wild guess was that if I had /lib/modules/4.1.0/build &
> source as that was the kernel I was building?
Yes.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
B)/build ; \
ln -s $(CURDIR) $(MODLIB)/build ; \
fi
@cp -f $(objtree)/modules.order $(MODLIB)/
@cp -f $(objtree)/modules.builtin $(MODLIB)/
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
I wonder why you don't see similar links when building on CentOS
ld guess: do the Ubuntu systems already have
/lib/modules/4.1.0/build
/lib/modules/4.1.0/source
as symlinks to /usr/src/kernels/4.1.0 when you're building the rpms?
(That is, not in rpm's buildroot, but in the actual filesystem.)
Paul Bolle
--
To unsubscribe from this list: send the line "
35 Jul 4 18:31
/lib/modules/4.1.0/build -> /usr/src/kernels/4.1.0
lrwxrwxrwx1 rootroot 35 Jul 6 12:15
/lib/modules/4.1.0/source -> /usr/src/kernels/4.1.0
drwxr-xr-x2 rootroot0 Jul 6 12:15
/usr/src/kernels/4.1.0
or something e
/kernels/4.1.0
lrwxrwxrwx1 rootroot 35 Jul 6 12:15
/lib/modules/4.1.0/source - /usr/src/kernels/4.1.0
drwxr-xr-x2 rootroot0 Jul 6 12:15
/usr/src/kernels/4.1.0
or something equivalent, right?
Paul Bolle
--
To unsubscribe from this list
systems already have
/lib/modules/4.1.0/build
/lib/modules/4.1.0/source
as symlinks to /usr/src/kernels/4.1.0 when you're building the rpms?
(That is, not in rpm's buildroot, but in the actual filesystem.)
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux
$(MODLIB)/
@cp -f $(objtree)/modules.builtin $(MODLIB)/
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
I wonder why you don't see similar links when building on CentOS. I saw
similar links in rpm's BUILDROOT when building on Fedora 22.
Thanks,
Paul Bolle
--
To unsubscribe from
-pattern
nevertheless. See the discussion that Shobhit Kumar, Paul Gortmaker, and
I had starting in https://lkml.org/lkml/2015/6/20/63 .
Please let me know if you're unconvinced by the arguments brought
forward by both Pauls in that discussion.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send
On wo, 2015-07-08 at 20:47 +0200, Espen Carlsen wrote:
I assume your wild guess was that if I had /lib/modules/4.1.0/build
source as that was the kernel I was building?
Yes.
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
G_FOO is not set
will be printed if FOO's dependencies are met and FOO either has a
"prompt" or a default of 'n'.
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 major
> +module_exit(hvsock_exit);
Any specific reason not to mark these functions __init and __exit?
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/
oesn't
config MMU
bool
(ie, drop the 'n' default) work just as well?
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.ht
ls. So, as far as I can
see, the code it adds can only be built-in.
This series also uses a number of module specific constructs (ie,
THIS_MODULE, MODULE_DEVICE_TABLE, module_exit, MODULE_AUTHOR,
MODULE_DESCRIPTION, and MODULE_LICENSE). So I wonder whether it was
intended to make these new Kconfig symbols
op of this file states, succinctly, that the license
is GPL v2. And, according to include/linux/module.h, the
MODULE_LICENSE() macro here states that the license is GPL v2 or later.
So I think that either that comment or the ident used in that macro
needs to change.
Ditto for 2/2.
Thanks,
Paul Bolle
, that the license
is GPL v2. And, according to include/linux/module.h, the
MODULE_LICENSE() macro here states that the license is GPL v2 or later.
So I think that either that comment or the ident used in that macro
needs to change.
Ditto for 2/2.
Thanks,
Paul Bolle
--
To unsubscribe from
-in.
This series also uses a number of module specific constructs (ie,
THIS_MODULE, MODULE_DEVICE_TABLE, module_exit, MODULE_AUTHOR,
MODULE_DESCRIPTION, and MODULE_LICENSE). So I wonder whether it was
intended to make these new Kconfig symbols tristate instead?
Thanks,
Paul Bolle
--
To unsubscribe from
.
--- /dev/null
+++ b/net/hv_sock/af_hvsock.c
+static int hvsock_init(void)
+{
+ [...]
+}
+
+static void hvsock_exit(void)
+{
+ [...]
+}
+
+module_init(hvsock_init);
+module_exit(hvsock_exit);
Any specific reason not to mark these functions __init and __exit?
Thanks,
Paul Bolle
will be printed if FOO's dependencies are met and FOO either has a
prompt or a default of 'n'.
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
(ie, drop the 'n' default) work just as well?
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/
e->lineno++;
> @@ -132,7 +140,6 @@ n [A-Za-z0-9_]
> BEGIN(STRING);
> }
> \n BEGIN(INITIAL); current_file->lineno++; return T_EOL;
> - --- /* ignore */
> ({n}|[-/.])+{
> const struct kconf_id *id = kconf_id_lookup(yytext, y
ly) GPL v2. So I think that either the comment at the top of this
file or the ident used in MODULE_LICENSE() 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 majordo
ln -sf /usr/src/kernels/$KERNELRELEASE build"
> -echo "ln -sf /usr/src/kernels/$KERNELRELEASE source"
> +echo "ln -sfT /usr/src/kernels/$KERNELRELEASE build"
> +echo "ln -sfT /usr/src/kernels/$KERNELRELEASE source"
Thanks,
Paul Bolle
--
To unsubscribe f
source
+echo ln -sfT /usr/src/kernels/$KERNELRELEASE build
+echo ln -sfT /usr/src/kernels/$KERNELRELEASE source
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
}|[-/.])+{
const struct kconf_id *id = kconf_id_lookup(yytext, yyleng);
if (id id-flags TF_PARAM) {
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
the comment at the top of this
file or the ident used in MODULE_LICENSE() 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
ped files like
these should mention the command line that was used. Because now
everyone is expected to figure that out themselves. Bonus points for
mentioning the version of the tool that was used.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
ccessful
> exit code.
>
> Signed-off-by: Sam Bobroff
Could you please resend and include linux-kbu...@vger.kernel.org?
scripts/get_maintainer.pl would have told you that. (Please don't bother
including Yann Morin, as Yann has not been heard of for a long time
now.)
Thanks,
Paul Boll
-l
2590
Doable. Might not make you friends.
> Tightening things up should be safe after that.
Did you already try adding ---help--- (and something similar to Andreas'
check for the mistake we're discussing here)?
Paul Bolle
--
To unsubscribe from this list: send the line "un
lean way. (Perhaps that will start with renaming COMMAND
and PARAM and/or documenting these states.) I think I already
demonstrated that I'm too unfamiliar with lex for it to make sense to
volunteer.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
Because, obviously, the review of those patches could also be
used to demonstrate their downsides. Actually, since
DEBUG_UART_8250_WORD already uses ">=", and that's now become legal,
perhaps the downsides can already be demonstrated.
Thanks,
Paul Bolle
--
To unsubscribe from this list:
hink you implied, it doesn't help that the empty rule we're hitting
here is not commented.)
So the naive solution seems to be to also add the warning to COMMAND's
rule for '.'. A quick test suggest that would work. Am I missing some
obvious downside with that solution?
Thanks,
Paul Bolle
--
To
that the empty rule we're hitting
here is not commented.)
So the naive solution seems to be to also add the warning to COMMAND's
rule for '.'. A quick test suggest that would work. Am I missing some
obvious downside with that solution?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line
also be
used to demonstrate their downsides. Actually, since
DEBUG_UART_8250_WORD already uses =, and that's now become legal,
perhaps the downsides can already be demonstrated.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
with renaming COMMAND
and PARAM and/or documenting these states.) I think I already
demonstrated that I'm too unfamiliar with lex for it to make sense to
volunteer.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
that.
Did you already try adding ---help--- (and something similar to Andreas'
check for the mistake we're discussing here)?
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
.
Signed-off-by: Sam Bobroff sam.bobr...@au1.ibm.com
Could you please resend and include linux-kbu...@vger.kernel.org?
scripts/get_maintainer.pl would have told you that. (Please don't bother
including Yann Morin, as Yann has not been heard of for a long time
now.)
Thanks,
Paul Bolle
the command line that was used. Because now
everyone is expected to figure that out themselves. Bonus points for
mentioning the version of the tool that was used.
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
[Spoiler: please start at the end of my reply.]
On do, 2015-07-02 at 13:57 +0200, Andreas Ruprecht wrote:
> On 07/02/2015 11:01, Paul Bolle wrote:
> > On Thu, 2015-07-02 at 10:08 +0200, Valentin Rothberg wrote:
> > Welcome to the wonders of lex and yacc!
> >
> > I
On do, 2015-07-02 at 11:01 +0200, Paul Bolle wrote:
> I'm just guessing here. Anyhow, you might start by looking at this
> snippet in zconf.l:
> . {
> unput(yytext[0]);
> BEGIN(COMMAND);
> }
>
>
ing if we encounter some text ({n} = [A-Za-z0-9_]);
- go in INITIAL state if we encounter newlines or unknown stuff.
At the end of which we're back where we started before encountering
the'+'. But there are more references to '.' in the lex rules so it's
probably more complicated.
Hope this help
stuff.
At the end of which we're back where we started before encountering
the'+'. But there are more references to '.' in the lex rules so it's
probably more complicated.
Hope this helps,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On do, 2015-07-02 at 11:01 +0200, Paul Bolle wrote:
I'm just guessing here. Anyhow, you might start by looking at this
snippet in zconf.l:
. {
unput(yytext[0]);
BEGIN(COMMAND);
}
COMMAND{
{n
[Spoiler: please start at the end of my reply.]
On do, 2015-07-02 at 13:57 +0200, Andreas Ruprecht wrote:
On 07/02/2015 11:01, Paul Bolle wrote:
On Thu, 2015-07-02 at 10:08 +0200, Valentin Rothberg wrote:
Welcome to the wonders of lex and yacc!
I try to spend as little time as possible
his 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 pushed into mainline?
Pau
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_ALIA
)
> + 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 unsub
_driver(_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);
> + plat
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 only useful if, in short, there's
a corresponding
() succeeded?
+ platform_device_unregister(asuspl_dev);
+ platform_driver_unregister(asuspl_driver);
+ }
+}
+
+module_init(asusrb_init);
+module_exit(asusrb_exit);
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
+= 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 unsubscribe from this list: send the line
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 pushed into mainline?
Paul Bolle
--
To unsubscribe from this list: send the line
ill 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 "unsubscribe linux-kern
e_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
tristate instea
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_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
tristate instead?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
module specific code or
macros there still might be left in this file.
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
=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 unsubscribe linux-kernel in
the body of a message to majord
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 the line "unsubs
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 o
501 - 600 of 4150 matches
Mail list logo
