When do we get the message:
IRQ79 no longer affine to CPU1
Is this a hard error? As i understand this comes during CPU hotplug.
Can anyone explain when this happens. I am not interrester in IRQ79,
But more interested in why this occurs?
Thanks,
Ryan
--
To unsubscribe from this list: send the
t: %s\n"
- "features\t:",
+ "flags\t:",
c->fdiv_bug ? "yes" : "no",
c->hlt_works_ok ? "no" : "yes",
ssing something?
My software resembes Debian woody,
gcc --version:
2.95.2
Hope this helps.
-ryan
(PS: my raid array is from a 2.2.16 patched with the latest raid patches
for that kernel... debian raidtools2 uses this patch, so its the "latest
one". I'm not sure how releva
der
2.4.0test10 would be good? Either way I dont think a hardcrash is a
reasonable response ;-)
-ryan
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU: 1
EIP: 0010:[]
EFLAGS: 0086
eax: c01b2824 ebx: c7ff8e80 ecx: 0020 edx: 0001
esi: c1234e60 edi: 0282 ebp: 000e esp: c7f
, how do I generate a report for the 2nd Promise card in the system?)
I've tried many different combinations of the settings in the "Block Devices"
portion of the kernel, but nothing seems to help the situation.
Thanks for the help!
Ryan Allgaier
I'm using Linux-2.2.19 wit
Is there a way to trace suspend-resume without using ftrace and printk.
Thanks.
ryan
--
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
Pleas
CONFIG_CACHE_PL310_STANDBY_MODE=y
CONFIG_CACHE_PL310_DYNAMIC_CLOCK_GATING=y
However, If i disable them it detects only One Core.
Any Idea why is this required?
Regards,
Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Am I suppose to add a 'Sign by' line for myself or
is that for the core kernel team?
Thank you for time and feedback,
Ryan
On 03/28/2014 03:13 PM, Ryan Desfosses wrote:
>change made to resolve following checkpatch message:
>drivers/pci/pci.c:109: ERROR: "foo* bar&qu
of debugging kernel freeze.
Thanks and Regards,
Ryan.
--
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/
Hello all,
I wanted to find out if udev is involved in loading of the firmware
during the booting up of the kernel.
Usually firmware download is done during the bootup of the kernel. In
that case, the udev monitors are not running. How do the firmware get
downloaded?
Thanks,
ryan
affic, but oddly enough
even though tcpdump shows that traffic is transmitting and the link
lights blink, the other side does not see any traffic. I've tested
this with different computers and different link speeds to no avail.
The fact that the link lights blink when transmitting makes
claration of function
> 'devm_ioremap'
> drivers/video/ep93xx-fb.c:533: warning: assignment makes pointer from integer
> without a cast
>
> Include to pickup the declaration of 'devm_ioremap'.
>
> Signed-off-by: H Hartley Sweeten
> Cc:
> Cc: Flor
On 16/03/13 12:03, H Hartley Sweeten wrote:
> Remove the __init tag from ep93xxbl_probe() to fix the section
> mismatch warning.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Richard Purdie
> Cc: Florian Tobias Schandinat
There is a patch for this alr
remove the init/exit boilerplate.
>>
>> Signed-off-by: H Hartley Sweeten
>> Cc: Ryan Mallon
>> Cc: Arnd Bergmann
>> Cc: Greg Kroah-Hartman
>
> Acked-by: Arnd Bergmann
For the whole series:
Acked-by: Ryan Mallon
Not sure if I should take these
c_subdir_lock);
> - error = -EINVAL;
> + error = -ENOMEM;
This seems incorrect. This function doesn't allocate anything, it looks
up an inode. From my reading it looks like -EINVAL is returned here if
the dentry name matches, but the inode cannot be found.
~
ur change only sizeof(struct proc_dir_entry) is zero'ed by memset, and
then the name is filled in (the len + 1 part). After your change the
structure and the name field are both zeroed, so the name field is being
written to twice. The cost is probably negligible though.
~Ryan
--
To unsub
er happened. I'm not
sure what the reasons were. You can read through the discussion yourself
if you are so inclined. There is an email from Linus explaining some of
the historical reasons why the sound code is in sound/ and not
drivers/sound:
http://lkml.indiana.edu/hypermail/linux/kernel/08
)
This is a functional change since pr_debug compiles away to nothing
unless DEBUG is defined, so now you need to define both DEBUG and
DEBUG_GPIO for this to print.
A better fix would be to just replace calls to gpio_dbg with pr_debug.
~Ryan
--
To unsubscribe from this list: send the line "u
on:
int err;
err = gpiolib_sysfs_init();
if (err)
return err;
return gpiolib_debugfs_init();
?
> +}
> +module_init(gpiolib_init);
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
,
>>>gc->label);
>>
>> I would rather see dev_* conversion instead.
>>
>> my 2 cents
>
> Hi Felipe Balbi,
>
> OK, I will replace printk(KERN_ERR...) with dev_err.
> Thank you.
I was going to suggest that also, but I
Arnd Bergmann
Acked-by: Ryan Mallon
> Cc: Grant Likely
> Cc: Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Jeff Garzik (supporter:SERIAL ATA
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Dmitry Torokhov (maintainer:INPUT
> Cc: Florian Tobias Schandinat
> Cc: Liam Girdwoo
))
> - path = ptr + 1;
The original version here returns the string after the last '/' or '\',
the new kbasename function only looks for '/'. Does that matter here, or
wa
On 03/10/12 10:30, Ryan Mallon wrote:
> On 03/10/12 01:00, Andy Shevchenko wrote:
>> The custom filename function mostly repeats the kernel's kbasename. This
>> patch
>> simplifies it. The updated filename() will not check for the '\' in the
>> filenames.
s pointless.
> +}
> +
> +
> +module_init(logger_init);
> +module_exit(logger_exit);
Nitpick - Blank line here.
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Brian Swetland, ");
Should be Robert Love according to the header comment.
> +MODULE_DESCRIPTION(&q
make sure that it works
correctly (e.g. doesn't miss some early logs) in order to make this
change. It should be done as a separate patch anyway to make it easier
to identify any issues with it later.
~Ryan
--
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/
333..75cc8da 100644
> --- a/arch/ia64/mm/discontig.c
> +++ b/arch/ia64/mm/discontig.c
> @@ -185,7 +185,7 @@ static void *per_cpu_node_setup(void *cpu_data, int node)
> void __init setup_per_cpu_areas(void)
> {
> struct pcpu_alloc_info *ai;
> - struct pcpu_group_i
my time to maintain this tree. I cannot see how
it could be any harder than sending to Linus directly. Also, the arm-soc
maintainers, Arnd and Olof, have been very helpful in getting me started
with my maintainer tree, and in learning the development flow.
I would also rather get flamed by the arm-
es indeed complain about uses of seq_printf() in
drivers/staging/android/binder.c which are passing formatted strings. At
a quick glance it looks like checkpatch.pl is only checking for the
format string on the same line as seq_printf(), so this files ugly
coding style confuses the check. Joe?
Anyway, pl
that once
privileges are re-elevated only the in-memory copy is used.
I still think in-kernel fixing is a good idea too though, since it
hardens against user-space setuid apps that don't do this. This was just
the simplest approach to fixing the problem that I could think of. I'm
If input_event_from_user() fails in evdev write() and at least one
event has been written successfully then return the number of bytes
written. If no events have been written, then the EFAULT error is
returned.
Signed-off-by: Ryan Mallon
---
drivers/input/evdev.c |3 ++-
1 file changed, 2
Rework the code in uinput_inject_event so that it matches the code in
evdev_write and allows injecting more than one event, or zero events.
Signed-off-by: Ryan Mallon
---
drivers/input/misc/uinput.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a
On 19/09/13 05:48, Dmitry Torokhov wrote:
> Hi Ryan,
>
> On Wed, Sep 18, 2013 at 08:55:44AM +1000, Ryan Mallon wrote:
>> Rework the code in uinput_inject_event so that it matches the code in
>> evdev_write and allows injecting more than one event, or zero events.
>
>
ection. The point is to have the same
> inteface for these drivers.
>
> Signed-off-by: Michal Simek
Hi Michal,
Some comments below.
~Ryan
>
> ---
> MAINTAINERS | 7 +
> drivers/Kconfig | 2 +
> drivers/Makefile| 1 +
> drivers/fp
Several video drivers open code the fb_write write function with code
which is very similar to fb_sys_write. Replace the open code versions
with calls to fb_sys_write. An fb_sync callback is added to each of
the drivers.
Signed-off-by: Ryan Mallon
---
diff --git a/drivers/video/auo_k190x.c
Call input_inject_event rather than input_event in uinput_inject_event. This
mirrors the behaviour of evdev_write. input_inject_event will ignore the
injected event if the uinput input device has been grabbed for exclusive
access by a handler other than uinput.
Signed-off-by: Ryan Mallon
Rework the code in uinput_inject_event so that it matches the code in
evdev_write and allows injecting more than one event, or zero events.
Signed-off-by: Ryan Mallon
---
drivers/input/misc/uinput.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers
On 11/09/13 10:12, Dmitry Torokhov wrote:
> Hi Ryan,
>
> On Wed, Sep 11, 2013 at 09:32:53AM +1000, Ryan Mallon wrote:
>> Call input_inject_event rather than input_event in uinput_inject_event. This
>> mirrors the behaviour of evdev_write. input_inject_event will ignore the
On 11/09/13 10:14, Dmitry Torokhov wrote:
> Hi Ryan,
>
> On Wed, Sep 11, 2013 at 09:32:52AM +1000, Ryan Mallon wrote:
>> Rework the code in uinput_inject_event so that it matches the code in
>> evdev_write and allows injecting more than one event, or zero events.
>>
&g
mm_segment_t fs = get_fs();
It looks like you missed the removal of the old:
mm_segment_t fs = get_fs();
above? Just below if (FILTER(ELF_HEADERS)).
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
up ids are equal to the
real ids. If a setuid binary reads the contents of a file which uses
%pK then the pointer values will be printed as NULL if the real user
is unprivileged.
Signed-off-by: Ryan Mallon
---
Changes since v1:
* Fix the description to say 'vsprintf' instead of
On 09/10/13 12:30, Joe Perches wrote:
> On Tue, 2013-10-08 at 17:49 -0700, Joe Perches wrote:
>> On Wed, 2013-10-09 at 11:15 +1100, Ryan Mallon wrote:
>>> Some setuid binaries will allow reading of files which have read
>>> permission by the real user id. This is p
On 09/10/13 13:00, Joe Perches wrote:
> On Wed, 2013-10-09 at 12:55 +1100, Ryan Mallon wrote:
>> On 09/10/13 12:30, Joe Perches wrote:
>>> On Tue, 2013-10-08 at 17:49 -0700, Joe Perches wrote:
>>>> On Wed, 2013-10-09 at 11:15 +1100, Ryan Mallon wrote:
>>>>
ned-off-by: Ryan Mallon
---
Changes since v2:
* Fixed typo in comment: 'proccess' -> 'process'
* Use a switch statement for the kptr_restrict values
* Updated the sysctl documentation
Changes since v1:
* Fix the description to say 'vsprintf' instead of
On 10/10/13 09:00, Joe Perches wrote:
> On Thu, 2013-10-10 at 08:52 +1100, Ryan Mallon wrote:
>> Some setuid binaries will allow reading of files which have read
>> permission by the real user id. This is problematic with files which
>> use %pK because the file access permissi
On 10/10/13 09:14, Joe Perches wrote:
> On Thu, 2013-10-10 at 09:04 +1100, Ryan Mallon wrote:
>> On 10/10/13 09:00, Joe Perches wrote:
> []
>>> Move the interrupt tests and pK-error printk
>>> into case 1:
>>>
>>> It's the only case where CAP_S
On 10/10/13 09:33, Joe Perches wrote:
> On Thu, 2013-10-10 at 09:25 +1100, Ryan Mallon wrote:
>
>> if (kptr_restrict && (in_irq() || in_serving_softirq() ||
>>in_nmi())) {
>>
>> Is making sure that you don't
laining why the uid/gid check is
necessary :-/.
~Ryan
> Documentation/sysctl/kernel.txt | 17
> lib/vsprintf.c | 43
> -
> 2 files changed, 39 insertions(+), 21 deletions(-)
>
> diff --git a/
sda_falling_time = dev->sda_falling_time ? dev->sda_falling_time : 300;
You can also use the gcc-ism, which is a bit more concise:
sda_falling_time = dev->sda_falling_time ?: 300;
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
t=0 is the default.
>
> Sigh. This is all wrong. The only correct thing to test is
> file->f_cred. Aka the capabilities of the program that opened the
> file.
>
> Which means that the interface to %pK in the case of kptr_restrict is
> broken as it has no way to be passed
ULL if the real user is unprivileged.
Signed-off-by: Ryan Mallon
---
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..b1cd14d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1312,10 +1312,24 @@ char *pointer(const char *fmt, char *buf, char *end,
the seq_file to
> lib/vsprintf.c:pointer() would be tricky.
:-).
>
> But it also seems like the Right Thing to do; other fixes seem like
> ineffective kludges.
Will wait and see what others have to say.
(also apologies for the badly formatted initial post. The mail client on
my other
> these mythical setuid applications are probably broken in some
> situations anyway, because what happens if /proc/kallsyms is set to "2"
> (unconditionally replace addresses with 0's)? I also can't think of a
> better solution.
Okay, this was just the simplest soluti
to be removed, but that is still a huge
number to change, and doesn't include extern usage in C files or local
headers. You are probably never going to remove all the instances, so
what is the point of just randomly doing a handful?
~Ryan
> ---
> include/net/ping.h | 4 ++--
>
On 23/09/13 12:16, Joe Perches wrote:
> On Mon, 2013-09-23 at 11:59 +1000, Ryan Mallon wrote:
>> This seems like a lot of code churn for very little benefit. At a quick
>> glance:
>>
>> git grep extern include/ | wc -l
>> 11427
>>
>> Not all of tho
s are also
using the SZ_ defines, but are indirectly including linux/sizes.h via
asm/memory.h, which in turn is indirectly included via asm/io.h. That
seems a bit flaky, so I wonder if we should just explicitly include
in all the board files which use the SZ_ macros as per
the patch below. Thoughts?
Add IOMEM defines for the TS72xx VIRT_BASE defines to fix type
conversion warnings.
Signed-off-by: Ryan Mallon
---
diff --git a/arch/arm/mach-ep93xx/include/mach/ts72xx.h
b/arch/arm/mach-ep93xx/include/mach/ts72xx.h
index f1397a1..b30deb6 100644
--- a/arch/arm/mach-ep93xx/include/mach/ts72xx.h
; But if we do these changes, this patch is more than a build fix.
Fair enough,
I've applied your patch as-is to my ep93xx-fixes branch.
Thanks,
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
macros are like the macros PCI_DEVICE and PCI_DEVICE_CLASS.
>
> I understand that.
>
>> Are READ and WRITE the action names? They are really the important
>> information in this case.
>
> Yes, most (all?) uses of _READ and _WRITE macros actually
> perform some I/O.
W
addr, buf, sizeof(buf))
>>> };
>>>
>>
>> Any reason why struct i2c_msg is an array ?
>
> I assumed that it looked more harmonious with the other uses of
> i2c_transfer, which takes as arguments an array and the number of elements.
>
> But the
iv->cfg->i2c_address,
> - .flags = 0, .buf = ®, .len = 1 },
> - { .addr = priv->cfg->i2c_address,
> - .flags = I2C_M_RD, .buf = val, .len = 1 },
> + I2C_MSG_WRITE(priv->cfg->i2c_address, ®, sizeof(reg)),
> +
if (i2c_transfer(priv->i2c_props.adap, &msg, 1) != 1) {
> if (priv->ignore_i2c_write_errors == 0) {
> printk(KERN_ERR "xc4000: I2C write failed (len=%i)\n",
> @@ -550,10 +549,8 @@ static int xc4000_readreg(struct xc4000_priv *priv, u16
> r
ne here or as a separate
patch. Some of the other patches also have cases where single index
arrays (both buffers and messages) could be converted. Should either
convert all or none of them. I think its probably best to do as a
separate series on top of this though.
~Ryan
>
> ret =
st of the cases where 2 messages are used, the first message
> has length equal
> to one, and it uses a fixed u8 constant with the I2C sub-address. So, maybe
> it would be nice
> to have a variant for this case.
That ends up with a whole bunch of variants of the macro for somethi
On 08/10/12 16:05, Julia Lawall wrote:
> On Mon, 8 Oct 2012, Ryan Mallon wrote:
>
>> On 08/10/12 02:38, Julia Lawall wrote:
>>> From: Julia Lawall
>>>
>>> Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
>>>
>>> A length expresse
On 19/10/12 21:07, Linus Walleij wrote:
> On Wed, Oct 17, 2012 at 1:41 AM, Ryan Mallon wrote:
>
>> The gpio_export function uses nested if statements and the status
>> variable to handle the failure cases. This makes the function logic
>> difficult to follow. Re
number of split lines and makes the code easier
to read.
Signed-off-by: Ryan Mallon
---
Changes since v1:
- Return immediately if no unwinding needed
- Added pr_debug to immediate returns
- Changed unavailable (!requested || exported) to -EPERM
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio
On 23/10/12 09:13, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 2:39 AM, Ryan Mallon wrote:
>
>> The gpio_export function uses nested if statements and the status
>> variable to handle the failure cases. This makes the function logic
>> difficult to follow. Re
since those tools are often recommended to (new) kernel developers.
Some more comments below.
~Ryan
> ---
> samples/Kconfig | 14 +
> samples/Makefile|5 +-
> samples/ltd/Makefile|1 +
> samples/ltd/ldt.c | 764
> +
Boot than in Linux.
This is probably okay for some hardware, but doesn't work in the general
case. Not all hardware is detectable, for example a cape which just adds
a set of LEDs for GPIO pins. Also, some hardware might not easily be
detectable without adding additional complexity to the b
lts
> by 1000, since the removed arm_gettimeoffset() did this. Also,
> s/unsigned long/u32/ just to make the function prototypes exactly
> match that of arch_gettimeoffset.
>
> Cc: Russell King
> Cc: Andrew Victor
> Cc: Nicolas Ferre
> Cc: Jean-Christophe Plagniol-Villa
On 10/11/12 08:07, Stephen Warren wrote:
> On 11/08/2012 04:06 PM, Ryan Mallon wrote:
>> On 09/11/12 08:01, Stephen Warren wrote:
>>> remove ARM's struct sys_timer .offset function pointer, and instead
>>> directly set the arch_gettimeoffset function poin
make the system unstable if you don't bug.
Can't they just be replaced with (for example):
if (WARN_ON(blah))
return;
Or even just:
netdev_err(adapter->netdev, "bad irq type %d for free\n",
intr->type);
~Ryan
--
omplish little [in the way of enforcing write ordering].
Accept it. And start thinking instead about talking directly to a
storage controller that offers proper write barriers."
I hope I misread what you said, because that's a depressing thing to
hear from your OS.
Ryan
--
To unsu
anned to work on the kernel side of this and I have
a GLIBC patch in process.
Comments?
Ryan S. Arnold
IBM Linux Technology Center
glibc PowerPC maintainer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
s you add documentation
for the new sysfs interface to Documentation/ABI/stable/.
~Ryan
>
> drivers/pwm/Kconfig | 6 +
> drivers/pwm/Makefile| 1 +
> drivers/pwm/core.c | 25 +++-
> drivers/pwm/pwm-sysfs.c | 357
>
> Cc: Grant Likely
> Cc: Linus Walleij
> ---
> Since v1:
> - address Linus' comments: self-descriptive error codes, removal of __init in
>header, better title in c-file.
Hi Andy,
Some trivial coding style comment below.
~Ryan
>
> drivers/gpio/Kc
table overhead.
Why not just make CONFIG_PWM_SYSFS default y, so that if CONFIG_SYSFS is
enabled (which should be true for the vast majority of test configs) that
pwm sysfs is also enabled?
The IS_ENABLED method just seems very messy for a very small gain.
~Ryan
--
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/
scan->node);
> kfree(scan);
It looks like an mport_id can only be assigned to one scan entry (see
rio_register_scan), so you can use list_for_each_entry and break; after
the kfree(scan); instead.
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
= mport_id) {
> list_del(&scan->node);
> kfree(scan);
> + break;
> }
> + }
>
> mutex_unlock(&rio_mport_list_lock);
>
Reviewed-by: Ryan Mallon
--
To unsubscribe from this list: send the li
gt;
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Mika Westerberg
> Cc: Mark Brown
> Cc: Grant Likely
> ---
> drivers/spi/spi-ep93xx.c | 64
> +++-
> 1 file changed, 20 insertions(+), 44 deletions(-)
>
always call ep93xx_spi_chip_setup()
> to configure the hardware for each transfer in the message.
>
> Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer()
> which just initializes the hardware to the "default" based on the SPI
> device.
>
> S
On 29/06/13 04:44, H Hartley Sweeten wrote:
> This inline helper function is only used to determine the bus width
> of the current transfer (8 or 16 bit). Add a bool flag to the private
> structure and set it appropriately for each transfer.
>
> Signed-off-by: H Hartley Swee
r to do
>
> struct device_node *bl;
>
> bl = of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
>
> and avoid the 80-col trickery.
The other reason being that it now becomes much more apparent that *fb
is not an argument to of_find_n
obably mention that this will change the
interrupt name (which appears in /proc/interrupts for example) from "wd"
to "eth%d".
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
On 01/03/13 21:50, Michail Kurachkin wrote:
> From: Michail Kurochkin
>
> Signed-off-by: Michail Kurochkin
Hi Michail,
Quick review below. I'll try to find some time to look through
the other patches later.
~Ryan
> ---
> drivers/staging/Kconfig|4
On 01/03/13 21:52, Michail Kurachkin wrote:
> From: Michail Kurochkin
>
> Signed-off-by: Michail Kurochkin
> ---
> drivers/staging/tdm/kirkwood_tdm.c | 932
>
> drivers/staging/tdm/kirkwood_tdm.h | 110 +
> 2 files changed, 1042 insertions(+), 0 dele
On 01/03/13 21:57, Michail Kurachkin wrote:
> From: Michail Kurochkin
>
> Signed-off-by: Michail Kurochkin
> ---
> drivers/staging/tdm/kirkwood_tdm.c | 162
> +---
> drivers/staging/tdm/kirkwood_tdm.h | 10 ++-
> drivers/staging/tdm/tdm.h |5 +-
/* I: worker attributes */
If attrs always exists, why not just embed the struct and avoid the
need to alloc/free it?
~Ryan
--
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 06/03/13 09:34, Tejun Heo wrote:
> On Tue, Mar 05, 2013 at 02:33:27PM -0800, Tejun Heo wrote:
>> Hello, Ryan.
>>
>> On Wed, Mar 06, 2013 at 09:29:35AM +1100, Ryan Mallon wrote:
>>>> @@ -148,6 +148,8 @@ struct worker_pool {
>>>>struc
On 04/03/13 20:02, Jingoo Han wrote:
> When platform_driver_probe() is not used, bind/unbind via sysfs is
> enabled. Thus, __init/__exit annotations should be removed from
> probe()/remove().
>
> Signed-off-by: Jingoo Han
Acked-by: Ryan Mallon
> ---
> Changes since v1
On 06/03/13 09:44, Tejun Heo wrote:
> Hello,
>
> On Wed, Mar 06, 2013 at 09:40:48AM +1100, Ryan Mallon wrote:
>>> Ooh, right, and that cpumask_t is going away and you can't statically
>>> allocate cpumask_var_t, so it needs an allocation and error check from
>&g
le. Would this be useful for lockdep or
> anything like that?
lockdep has lockdep_assert_held(), which might be what you want. Though
it looks like it possibly also has the false positive issues on SMP?
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
+++-
> 1 file changed, 50 insertions(+), 137 deletions(-)
>
Series looks fine to me.
Reviewed-by: Ryan Mallon
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
> }
A couple of other improvements could be done here. The function should
really return bool, inline is unnecessary (the compiler is smart enough
to do that for us), and we can simplify the logic a bit too:
static bool is_between(size_t a, size_t b, size_t c)
{
if (a < b)
ues with the arguments:
#define hash_min ({ \
sizeof(val) <= 4 ? \
hash_32(val, bits) :\
hash_long(val, bits)); \
})
~Ryan
--
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 15/09/12 07:34, Arnd Bergmann wrote:
> ARM is moving to stricter checks on readl/write functions,
> so we need to use the correct types everywhere.
>
> Cc: Hartley Sweeten
> Cc: Ryan Mallon
> Signed-off-by: Arnd Bergmann
Hi Arnd,
Do you want me to queue both this an
nice to tabify the fields, and put the comments on their own
lines while you are here. With the C99 format you can also omit fields
which are initialised to zero. Like this:
{
/* Setup read pointer */
.addr = client->addr,
zeof(reg_addr),
> .buf = reg_addr}
> ,
Putting the whole initialiser on one line is a bit ugly. Any reason not
to expand it over multiple lines as the previous patch (and majority of
other drivers) does?
~Ryan
--
To unsubscribe from this list: send the line "unsubsc
struct i2c_msg msgs[2] = {
I2C_WRITE(client->addr, reg_addr, sizeof(reg_addr)),
I2C_READ(client->addr, buf, len),
};
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
On 18/09/12 15:40, Shubhrajyoti wrote:
> On Tuesday 18 September 2012 07:21 AM, Ryan Mallon wrote:
>> Actually, I wonder if it is useful to have something like:.
> Read and write differ only in the flag also it will be a deviation from
> what $SUBJECT
> would warrant. So could b
1 - 100 of 547 matches
Mail list logo
