my Linux is booted.
Best regards,
Daniel Santos
jan 14 19:05:03 torre kernel: usb 1-5: device descriptor read/all, error -110
jan 14 19:05:03 torre kernel: usb 1-5: new high-speed USB device number 4 using
ehci-pci
(...)
jan 14 19:05:14 torre kernel: usb 1-5: device descriptor read/all, error -
Ping 2!
On 11/05/2018 03:38 PM, Daniel Santos wrote:
> Ping.
>
> Daniel
>
> On 10/21/2018 07:32 PM, Hou Tao wrote:
>> On 2018/10/19 16:30, Daniel Santos wrote:
>>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>>> is defined then a
Ping 2!
On 11/05/2018 03:38 PM, Daniel Santos wrote:
> Ping.
>
> Daniel
>
> On 10/21/2018 07:32 PM, Hou Tao wrote:
>> On 2018/10/19 16:30, Daniel Santos wrote:
>>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>>> is defined then a
Ping.
Daniel
On 10/21/2018 07:32 PM, Hou Tao wrote:
>
> On 2018/10/19 16:30, Daniel Santos wrote:
>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>> is defined then a write buffer is available and has been initialized.
>> However, this does is n
Ping.
Daniel
On 10/21/2018 07:32 PM, Hou Tao wrote:
>
> On 2018/10/19 16:30, Daniel Santos wrote:
>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>> is defined then a write buffer is available and has been initialized.
>> However, this does is n
Hello,
I'm trying to use a GPIO as an interrupt on an mt7620 (using OpenWRT
drivers) and I can't seem to figure out how to glue my two-celled
interrupt description (including the trigger) to the device tree code.
This is the gpio driver I'm using:
Hello,
I'm trying to use a GPIO as an interrupt on an mt7620 (using OpenWRT
drivers) and I can't seem to figure out how to glue my two-celled
interrupt description (including the trigger) to the device tree code.
This is the gpio driver I'm using:
On 10/21/2018 07:32 PM, Hou Tao wrote:
>
> On 2018/10/19 16:30, Daniel Santos wrote:
>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>> is defined then a write buffer is available and has been initialized.
>> However, this does is not the case
On 10/21/2018 07:32 PM, Hou Tao wrote:
>
> On 2018/10/19 16:30, Daniel Santos wrote:
>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>> is defined then a write buffer is available and has been initialized.
>> However, this does is not the case
supers+0xf4/0x120
[ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
[ 90.875067] [<80014424>] syscall_common+0x34/0x58
Signed-off-by: Daniel Santos
---
fs/jffs2/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 793ad
supers+0xf4/0x120
[ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
[ 90.875067] [<80014424>] syscall_common+0x34/0x58
Signed-off-by: Daniel Santos
---
fs/jffs2/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 793ad
I have not rebooted my system since recovering my data off of an old
raid5 array with an external journal which broke after a crash in
write-back mode (https://www.spinics.net/lists/raid/msg61331.html) and I
noticed this in my kernel log. I had the array assembled in read-only
mode without a
I have not rebooted my system since recovering my data off of an old
raid5 array with an external journal which broke after a crash in
write-back mode (https://www.spinics.net/lists/raid/msg61331.html) and I
noticed this in my kernel log. I had the array assembled in read-only
mode without a
Hello Nick,
On 08/27/2018 03:09 PM, Nick Desaulniers wrote:
>> Now we're back to the question of "what do you mean by 'constant'"? If
>> you mean a C constant expression (as defined in the C standard) than
>> almost none of this code fits that criteria. For these compile-time
>> assertions to
Hello Nick,
On 08/27/2018 03:09 PM, Nick Desaulniers wrote:
>> Now we're back to the question of "what do you mean by 'constant'"? If
>> you mean a C constant expression (as defined in the C standard) than
>> almost none of this code fits that criteria. For these compile-time
>> assertions to
Hello Masahiro,
On 08/25/2018 01:16 PM, Masahiro Yamada wrote:
> __compiletime_assert_fallback() is supposed to stop building earlier
> by using the negative-array-size method in case the compiler does not
> support "error" attribute, but has never worked like that.
>
> You can simply try:
>
>
Hello Masahiro,
On 08/25/2018 01:16 PM, Masahiro Yamada wrote:
> __compiletime_assert_fallback() is supposed to stop building earlier
> by using the negative-array-size method in case the compiler does not
> support "error" attribute, but has never worked like that.
>
> You can simply try:
>
>
On 08/19/2018 03:25 PM, Nick Desaulniers wrote:
> + gbiv who wrote this cool paste (showing alternatives to
> _Static_assert, which is supported by both compilers in -std=gnu89,
> but not until gcc 4.6): https://godbolt.org/g/DuLsxu
>
> I can't help but think that BUILD_BUG_ON_MSG should use
>
On 08/19/2018 03:25 PM, Nick Desaulniers wrote:
> + gbiv who wrote this cool paste (showing alternatives to
> _Static_assert, which is supported by both compilers in -std=gnu89,
> but not until gcc 4.6): https://godbolt.org/g/DuLsxu
>
> I can't help but think that BUILD_BUG_ON_MSG should use
>
Hello Julia,
I'm CCing LKML on this so that others can be involved.
On 04/15/2018 12:43 AM, Julia Lawall wrote:
> Hello,
>
> I saw that you introduced BUILD_BUG_ON_MSG in the Linux kernel a few years
> ago.
>
> BUILD_BUG_ON_MSG is not safe when used in header files. Via
> compiletime_assert,
Hello Julia,
I'm CCing LKML on this so that others can be involved.
On 04/15/2018 12:43 AM, Julia Lawall wrote:
> Hello,
>
> I saw that you introduced BUILD_BUG_ON_MSG in the Linux kernel a few years
> ago.
>
> BUILD_BUG_ON_MSG is not safe when used in header files. Via
> compiletime_assert,
On 02/07/2014 05:22 AM, Luis Henriques wrote:
3.5.7.30 -stable review patch. If anyone has any objections, please let me
know.
--
From: Daniel Santos
commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d upstream.
This corrects a problem in spi_pump_messages() that leads
On 02/07/2014 05:22 AM, Luis Henriques wrote:
3.5.7.30 -stable review patch. If anyone has any objections, please let me
know.
--
From: Daniel Santos daniel.san...@pobox.com
commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d upstream.
This corrects a problem
or become broken ( which I'm managing via a #if
LINUX_VERSION_CODE >= KERNEL_VERSION(4,99,99) check:
https://github.com/daniel-santos/mcp2210-linux/blob/master/mcp2210-spi.c#L143).
No, don't do that - it's not sensible. If there's something you need
work upstream to get it implemented or underst
or become broken ( which I'm managing via a #if
LINUX_VERSION_CODE = KERNEL_VERSION(4,99,99) check:
https://github.com/daniel-santos/mcp2210-linux/blob/master/mcp2210-spi.c#L143).
No, don't do that - it's not sensible. If there's something you need
work upstream to get it implemented or understand
,99) check:
https://github.com/daniel-santos/mcp2210-linux/blob/master/mcp2210-spi.c#L143).
The reason is for this is that the mcp2210 driver has an internal
command queue that manages (per its requirements) spi messages as well
as other types of commands to the remote (via USB) device (which is b
) check:
https://github.com/daniel-santos/mcp2210-linux/blob/master/mcp2210-spi.c#L143).
The reason is for this is that the mcp2210 driver has an internal
command queue that manages (per its requirements) spi messages as well
as other types of commands to the remote (via USB) device (which is both
Sorry, the "[PATCH]" prefix didn't get in the subject.
--
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
Sorry, the [PATCH] prefix didn't get in the subject.
--
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 09/20/2013 08:07 AM, David Howells wrote:
I suspect he doesn't really need to implement a "strerror()" function but
should rather build it straight into printk()/vsprintf().
David
Indeed we don't necessarily *need* a strerror() function per-se, but it
is an addition to the libc support in
On 09/20/2013 06:45 AM, Joe Perches wrote:
On Fri, 2013-09-20 at 00:21 -0500, Daniel Santos wrote:
[nice example about bloat]
Yeah, I do agree, I just don't see how to do it without introducing
unnecessary bloat.
I think the code size cost of %pE is pretty trivial
compared to the log size
On 09/20/2013 06:45 AM, Joe Perches wrote:
On Fri, 2013-09-20 at 00:21 -0500, Daniel Santos wrote:
[nice example about bloat]
Yeah, I do agree, I just don't see how to do it without introducing
unnecessary bloat.
I think the code size cost of %pE is pretty trivial
compared to the log size
On 09/20/2013 08:07 AM, David Howells wrote:
I suspect he doesn't really need to implement a strerror() function but
should rather build it straight into printk()/vsprintf().
David
Indeed we don't necessarily *need* a strerror() function per-se, but it
is an addition to the libc support in
On 09/19/2013 08:07 PM, Joe Perches wrote:
On Wed, 2013-09-18 at 20:27 -0500, Daniel Santos wrote:
if I use ERR_PTR() on a signed int on a x86_64 where pointer
is 64 bits and int is 32, wouldn't that mean a signed conversion
instruction where the sign bit has to be moved from bit 31 to 63
On 09/19/2013 05:35 PM, Daniel Santos wrote:
Hmm, I cannot reproduce the error. :( I'm using next-20130919
currently (x86_64), and if I try to just "make O=lib" it fails w/o my
patches. The only file that should depend upon error_strings.h is
lib/string.c.
Ahh! I've never seen
On 09/18/2013 06:38 AM, David Howells wrote:
danielfsan...@att.net wrote:
This is a simple bash script that parses our errno*.h files and formats
them into the error_strings.h header that our strerror and strerror_name
functions will use later.
I presume you haven't tried building with a
On 09/18/2013 06:38 AM, David Howells wrote:
danielfsan...@att.net wrote:
This is a simple bash script that parses our errno*.h files and formats
them into the error_strings.h header that our strerror and strerror_name
functions will use later.
I presume you haven't tried building with a make
On 09/19/2013 05:35 PM, Daniel Santos wrote:
Hmm, I cannot reproduce the error. :( I'm using next-20130919
currently (x86_64), and if I try to just make O=lib it fails w/o my
patches. The only file that should depend upon error_strings.h is
lib/string.c.
Ahh! I've never seen the make O
On 09/19/2013 08:07 PM, Joe Perches wrote:
On Wed, 2013-09-18 at 20:27 -0500, Daniel Santos wrote:
if I use ERR_PTR() on a signed int on a x86_64 where pointer
is 64 bits and int is 32, wouldn't that mean a signed conversion
instruction where the sign bit has to be moved from bit 31 to 63
On 09/18/2013 06:04 AM, David Howells wrote:
Joe Perches wrote:
On Tue, 2013-09-17 at 18:08 -0500, danielfsan...@att.net wrote:
This adds an extension for the integral format specifier suffix of 'e',
so that the format %[duxXo]e will result in printing an number (as
before) in addition to a
On 09/18/2013 06:08 AM, David Howells wrote:
danielfsan...@att.net wrote:
Typically, we don't care about error messages or names in the kernel because
userspace will manage that. But sometimes we need to output an error number
to printks and that creates a situation where a user, system
On 09/18/2013 06:38 AM, David Howells wrote:
danielfsan...@att.net wrote:
This is a simple bash script that parses our errno*.h files and formats
them into the error_strings.h header that our strerror and strerror_name
functions will use later.
I presume you haven't tried building with a
On 09/18/2013 06:55 AM, David Howells wrote:
David Howells wrote:
(1) Why are you double-NUL'ing all your strings? (see the \0 in the strings)
Ah... I see what you're doing. I missed the fact that you don't have a comma
after each string.
Yeah, I was trying to format the code so that
On 09/18/2013 06:55 AM, David Howells wrote:
David Howells dhowe...@redhat.com wrote:
(1) Why are you double-NUL'ing all your strings? (see the \0 in the strings)
Ah... I see what you're doing. I missed the fact that you don't have a comma
after each string.
Yeah, I was trying to
On 09/18/2013 06:38 AM, David Howells wrote:
danielfsan...@att.net wrote:
This is a simple bash script that parses our errno*.h files and formats
them into the error_strings.h header that our strerror and strerror_name
functions will use later.
I presume you haven't tried building with a make
On 09/18/2013 06:08 AM, David Howells wrote:
danielfsan...@att.net wrote:
Typically, we don't care about error messages or names in the kernel because
userspace will manage that. But sometimes we need to output an error number
to printks and that creates a situation where a user, system
On 09/18/2013 06:04 AM, David Howells wrote:
Joe Perches j...@perches.com wrote:
On Tue, 2013-09-17 at 18:08 -0500, danielfsan...@att.net wrote:
This adds an extension for the integral format specifier suffix of 'e',
so that the format %[duxXo]e will result in printing an number (as
before)
On 09/17/2013 06:08 PM, danielfsan...@att.net wrote:
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -58,6 +58,7 @@ config DYNAMIC_DEBUG
implicitly compiles in all pr_debug() and dev_dbg() calls, which
enlarges the kernel text size by about 2%.
+
If a source
On 09/17/2013 06:08 PM, danielfsan...@att.net wrote:
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -58,6 +58,7 @@ config DYNAMIC_DEBUG
implicitly compiles in all pr_debug() and dev_dbg() calls, which
enlarges the kernel text size by about 2%.
+
If a source
On 09/10/2013 01:01 PM, Mark Brown wrote:
On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
One of my original requirements for this driver is that it is
reusable for different devices that use the MCP2210, not just my own
hardware. There are a number of ways to accomplish
On 09/10/2013 01:01 PM, Mark Brown wrote:
On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
One of my original requirements for this driver is that it is
reusable for different devices that use the MCP2210, not just my own
hardware. There are a number of ways to accomplish
On 09/09/2013 06:06 AM, Mark Brown wrote:
On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:
So do i create an IRQ domain and then call generic_handle_irq() from
my URB complete() function? If so, which type of IRQ Domain is
appropriate for this? Unlike typical platform devices
On 09/09/2013 06:06 AM, Mark Brown wrote:
On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:
So do i create an IRQ domain and then call generic_handle_irq() from
my URB complete() function? If so, which type of IRQ Domain is
appropriate for this? Unlike typical platform devices
On 09/07/2013 07:52 PM, Guenter Roeck wrote:
On 09/07/2013 05:19 PM, Daniel Santos wrote:
I've posted a number of requests for aid on this and have gotten very
little responses and none that were helpful. I have spent at least 24
hours of research time on this and just a little direction from
On 09/07/2013 07:52 PM, Guenter Roeck wrote:
On 09/07/2013 05:19 PM, Daniel Santos wrote:
I've posted a number of requests for aid on this and have gotten very
little responses and none that were helpful. I have spent at least 24
hours of research time on this and just a little direction from
), but that can wait.
Any help *greatly* appreciated and thank you in advance!
Daniel
PS: If interested, my current driver here:
https://github.com/daniel-santos/mcp2210-linux. I haven't sought review
yet because I want to finish it first.
--
To unsubscribe from this list: send the line
), but that can wait.
Any help *greatly* appreciated and thank you in advance!
Daniel
PS: If interested, my current driver here:
https://github.com/daniel-santos/mcp2210-linux. I haven't sought review
yet because I want to finish it first.
--
To unsubscribe from this list: send the line
On 09/02/2013 06:07 PM, Greg KH wrote:
On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
Hello guys. I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.
I need to be able to generate interrupts from a USB device driver while
servicing
ivers.
https://github.com/daniel-santos/mcp2210-linux/
Anyway, look at the spi core, I think you want to tie into the
spi_new_device() call in your usb driver, and start sending/receiving
data through the SPI interfaces the spi core provides.
I'm actually using the alternative to th
://github.com/daniel-santos/mcp2210-linux/
Anyway, look at the spi core, I think you want to tie into the
spi_new_device() call in your usb driver, and start sending/receiving
data through the SPI interfaces the spi core provides.
I'm actually using the alternative to that call, which
On 09/02/2013 06:07 PM, Greg KH wrote:
On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
Hello guys. I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.
I need to be able to generate interrupts from a USB device driver while
servicing
On 09/02/2013 06:07 PM, Greg KH wrote:
On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
Hello guys. I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.
I need to be able to generate interrupts from a USB device driver while
servicing
Hello guys. I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.
I need to be able to generate interrupts from a USB device driver while
servicing the complete() function of an interrupt URB. While I realize
that this may seem strange, the purpose is for a
Hello guys. I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.
I need to be able to generate interrupts from a USB device driver while
servicing the complete() function of an interrupt URB. While I realize
that this may seem strange, the purpose is for a
On 09/02/2013 06:07 PM, Greg KH wrote:
On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
Hello guys. I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.
I need to be able to generate interrupts from a USB device driver while
servicing
also
very nice for prototyping.
My current driver is on github:
https://github.com/daniel-santos/mcp2210-linux/
Daniel
--
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.
for prototyping.
My current driver is on github:
https://github.com/daniel-santos/mcp2210-linux/
Daniel
--
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
hmm, git send-email didn't change my subject on the above message to
"[PATCH v2]", not sure what I did wrong. Sorry about that.
Daniel
--
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
On 08/24/2013 02:57 PM, Guenter Roeck wrote:
Looking into calling code, desc_to_gpio() is clearly not supposed to
return an error,
and it will result in odd behavior if it returns -1. For example, the
resulting debug
message of "gpio--1 (...) status ..." is not very useful.
It would make
On 08/24/2013 02:57 PM, Guenter Roeck wrote:
Looking into calling code, desc_to_gpio() is clearly not supposed to
return an error,
and it will result in odd behavior if it returns -1. For example, the
resulting debug
message of gpio--1 (...) status ... is not very useful.
It would make
hmm, git send-email didn't change my subject on the above message to
[PATCH v2], not sure what I did wrong. Sorry about that.
Daniel
--
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
On 01/01/2013 03:09 PM, danielfsan...@att.net wrote:
#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
-#if __GNUC_MINOR__>= 4
+#if GCC_VERSION>= 40400
#define __HAVE_BUILTIN_BSWAP32__
#define __HAVE_BUILTIN_BSWAP64__
#endif
-#if __GNUC_MINOR__>= 8 || (defined(__powerpc__)&& __GNUC_MINOR__>= 6)
On 01/01/2013 03:09 PM, danielfsan...@att.net wrote:
#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
-#if __GNUC_MINOR__= 4
+#if GCC_VERSION= 40400
#define __HAVE_BUILTIN_BSWAP32__
#define __HAVE_BUILTIN_BSWAP64__
#endif
-#if __GNUC_MINOR__= 8 || (defined(__powerpc__) __GNUC_MINOR__= 6)
+#if
On 12/13/2012 03:43 AM, Jan Beulich wrote:
On 13.12.12 at 01:29, Daniel Santos wrote:
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
On 12/13/2012 03:43 AM, Jan Beulich wrote:
On 13.12.12 at 01:29, Daniel Santosdanielfsan...@att.net wrote:
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few
On 11/06/2012 03:23 AM, Jan Beulich wrote:
This sort of logic is normally performed via the
include/linux/compiler*.h system. And
grep __GNUC include/linux/*.h
indicates that we've been pretty successful. Can we do that here too?
(eg: suppose the Intel compiler supports
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
(https://lkml.org/lkml/2012/9/28/1136). I've finally gotten ACKs from
maintainers
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
(https://lkml.org/lkml/2012/9/28/1136). I've finally gotten ACKs from
maintainers
On 11/06/2012 03:23 AM, Jan Beulich wrote:
This sort of logic is normally performed via the
include/linux/compiler*.h system. And
grep __GNUC include/linux/*.h
indicates that we've been pretty successful. Can we do that here too?
(eg: suppose the Intel compiler supports
On 11/17/2012 08:38 AM, Borislav Petkov wrote:
> On Thu, Nov 15, 2012 at 01:11:15PM -0600, Daniel Santos wrote:
>> Ah yes. I did notice that at one point, but I think it slipped
>> my mind. Also, the kernel has introduced me to the usage of the
>> !! construct, of which I
On 11/17/2012 08:38 AM, Borislav Petkov wrote:
On Thu, Nov 15, 2012 at 01:11:15PM -0600, Daniel Santos wrote:
Ah yes. I did notice that at one point, but I think it slipped
my mind. Also, the kernel has introduced me to the usage of the
!! construct, of which I'm well versed in its affects
On 11/13/2012 04:13 PM, danielfsan...@att.net wrote:
> +#define __compiletime_assert(condition, msg, __func) \
> + do {\
> + bool __cond = !(condition); \
> + extern
On 11/13/2012 04:13 PM, danielfsan...@att.net wrote:
+#define __compiletime_assert(condition, msg, __func) \
+ do {\
+ bool __cond = !(condition); \
+ extern void
> code if it were optimized. However, using a negative-sized array with a
>> similar value will not result in an false-positive (error). The only
>> caveat being that it will also fail to catch valid conditions, which we
>> should be expecting in an unoptimized build anyway.
>&g
This patch eliminates that error.
>>
>> Signed-off-by: Daniel Santos
>> ---
>> include/linux/bug.h |5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/bug.h b/include/linux/bug.h
>> index 1b2465d..ccd
.
Signed-off-by: Daniel Santos daniel.san...@pobox.com
---
include/linux/bug.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 1b2465d..ccd44ce 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -58,8
conditions, which we
should be expecting in an unoptimized build anyway.
Signed-off-by: Daniel Santos daniel.san...@pobox.com
---
include/linux/bug.h |2 +-
include/linux/compiler.h |5 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/bug.h b
.h will eventually be included to define __linktime_error
> (used in BUILD_BUG_ON). This patch includes it directly for clarity and
> to avoid the possibility of changes in /*/include/asm/bug.h being
> changed or not including linux/compiler.h for some reason.
>
> Signed-off-b
__linktime_error
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
to avoid the possibility of changes in arch/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason.
Signed-off-by: Daniel Santos daniel.san...@pobox.com
Acked-by: Borislav Petkov
On 10/31/2012 06:06 AM, Borislav Petkov wrote:
>> Realistically, a single macro could be defined in compiler*.h that
>> encapsulates the entirety of this mechanism and only exposes a "black
>> box" macro, that will simply expand to something that breaks the build
>> in the most appropriate fashion
On 10/31/2012 06:06 AM, Borislav Petkov wrote:
Realistically, a single macro could be defined in compiler*.h that
encapsulates the entirety of this mechanism and only exposes a black
box macro, that will simply expand to something that breaks the build
in the most appropriate fashion based
On 10/31/2012 06:06 AM, Borislav Petkov wrote:
> On Wed, Oct 31, 2012 at 12:34:45AM -0500, Daniel Santos wrote:
>> Yes, the __build_bug_on_failed message is much more informative. This
>> will only increase with these patches. For example, the line
>>
>> B
On 10/31/2012 06:06 AM, Borislav Petkov wrote:
On Wed, Oct 31, 2012 at 12:34:45AM -0500, Daniel Santos wrote:
Yes, the __build_bug_on_failed message is much more informative. This
will only increase with these patches. For example, the line
BUILD_BUG_ON(sizeof(*c) != 4);
emits this error
;> call BUILD_BUG_ON_MSG. This not only reduces source code bloat, but
>>> also prevents the possibility of code being changed for one macro and
>>> not for the other (which was previously the case for BUILD_BUG and
>>> BUILD_BUG_ON).
>>>
>>&g
ch case it expands to
>> do{}while(0), resulting in exactly one compile-time error on all
>> versions of gcc.
>>
>> Signed-off-by: Daniel Santos
>> ---
>> include/linux/bug.h |4 ++--
>> include/linux/compiler.h |7 +++
>> 2 fil
-by: Daniel Santos daniel.san...@pobox.com
---
include/linux/bug.h |4 ++--
include/linux/compiler.h |7 +++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 03259d7..da03dc1 100644
--- a/include/linux/bug.h
reduces source code bloat, but
also prevents the possibility of code being changed for one macro and
not for the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).
Signed-off-by: Daniel Santos daniel.san...@pobox.com
---
include/linux/bug.h | 17 +++--
1 files
(used in BUILD_BUG_ON). This patch includes it directly for clarity and
>> to avoid the possibility of changes in /*/include/asm/bug.h being
>> changed or not including linux/compiler.h for some reason. (Later
>> patches will in this set use more macros defined in compiler*
includes it directly for clarity and
to avoid the possibility of changes in arch/*/include/asm/bug.h being
changed or not including linux/compiler.h for some reason. (Later
patches will in this set use more macros defined in compiler*.h.)
Signed-off-by: Daniel Santos daniel.san...@pobox.com
On 10/07/2012 02:42 PM, Borislav Petkov wrote:
> On Sun, Oct 07, 2012 at 01:27:58PM -0500, Daniel Santos wrote:
>>> Did I miss something again? This "error" preprocessor function is
>>> commented out here? Why?
>> We'll have to ask Andrew. Maybe so
1 - 100 of 285 matches
Mail list logo
