-"openbmc" wrote:
-
>To: Rob Herring
>From: Steven Lee
>Sent by: "openbmc"
>Date: 04/12/2021 08:31PM
>Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
>, Ulf Hansson ,
>Ryan Chen , "moderated list:ASPEED SD/MMC
>DRIVER" , Andrew Jeffery
>, "open list:ASPEED SD/MMC
On : 06/19/2020 abiout 12:46PM in some timezone, Manikandan Elumalai wrote:
>The adm1278 temp attribute need it for openbmc platform .
>This feature not enabled by default, so PMON_CONFIG needs to enable
>it.
>
>Signed-off-by: Manikandan Elumalai
>---
>---v4 -Reported-by: kernel test robot
About 03/07/2018 04:12PM in some time zone, Pavel Machek wrote:
>Subject: Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings:
>Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs
>
>Hi!
>
>> >Are these SoCs x86-based?
>>
>> Yes, these are ARM SoCs. Please see Andrew's
About 03/07/2018 04:12PM in some time zone, Pavel Machek wrote:
>Subject: Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings:
>Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs
>
>Hi!
>
>> >Are these SoCs x86-based?
>>
>> Yes, these are ARM SoCs. Please see Andrew's
On Tue, 11 Oct 2016 07:09:16 -0300, Mauro wrote:
> struct af9005_device_state {
>
> u8 sequence;
>
> int led_state;
>
> + unsigned char data[256];
>
> + struct mutex data_mutex;
>
> };
This will not work on DMA incoherent architectures. When the data
cache is
On Tue, 11 Oct 2016 07:09:16 -0300, Mauro wrote:
> struct af9005_device_state {
>
> u8 sequence;
>
> int led_state;
>
> + unsigned char data[256];
>
> + struct mutex data_mutex;
>
> };
This will not work on DMA incoherent architectures. When the data
cache is
[adding Rob as Doc maintanier]
On Sat, 28 Jul 2012 about 11:08:16 -, Dirk Gouders wrote:
> Borislav Petkov writes:
>
> > On Fri, Jul 27, 2012 at 11:24:53AM +0200, Dirk Gouders wrote:
> >> Cong Wang writes:
> >>
> >> > On Fri, Jul 27, 2012 at 2:35 PM, Dirk Gouders
> >> > wrote:
> >> >> Hi
[adding Rob as Doc maintanier]
On Sat, 28 Jul 2012 about 11:08:16 -, Dirk Gouders wrote:
Borislav Petkov b...@alien8.de writes:
On Fri, Jul 27, 2012 at 11:24:53AM +0200, Dirk Gouders wrote:
Cong Wang xiyou.wangc...@gmail.com writes:
On Fri, Jul 27, 2012 at 2:35 PM, Dirk Gouders
On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote:
Hi.
I'm finding that recently kexec'ed kernels on PS3 will
panic on startup. It seems the trouble was introduced
with the ppc64 SPARSEMEM_VMEMMAP support. The problem
is the same when starting either new or old kernels:
2.6.24 -> 2.6.23 ok
On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote:
Hi.
I'm finding that recently kexec'ed kernels on PS3 will
panic on startup. It seems the trouble was introduced
with the ppc64 SPARSEMEM_VMEMMAP support. The problem
is the same when starting either new or old kernels:
2.6.24 - 2.6.23 ok
nd leaking the memory of the
tables.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
[resend with From set]
against e8b8c977734193adedf2b0f607d6252c78e86394
Before this patch on a 2-core 4-thread box compiled for SMT and NUMA,
the domains appear empty (there are actually
to KBUILD_CFLAGS instead.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
The commit also changed xtensia to export EXTRA_CFLAGS from its boot
directory, that needs to be fixed too.
from ARCH=ppc prep_defconfig:
/data/home/miltonm/work.git/arch/ppc/boot/of1275/write.c:11:20: error:
of
to KBUILD_CFLAGS instead.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
The commit also changed xtensia to export EXTRA_CFLAGS from its boot
directory, that needs to be fixed too.
from ARCH=ppc prep_defconfig:
/data/home/miltonm/work.git/arch/ppc/boot/of1275/write.c:11:20: error:
of1275.h
the memory of the
tables.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
[resend with From set]
against e8b8c977734193adedf2b0f607d6252c78e86394
Before this patch on a 2-core 4-thread box compiled for SMT and NUMA,
the domains appear empty (there are actually 3 levels per cpu
ing table entries, but any child tables and names
will be reclaimed upon free.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Hi Ingo.
It occurred to me this morning that the procname field was dynamically
allocated and needed to be freed. I started to put in break statements
when a
entries, but any child tables and names
will be reclaimed upon free.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
Hi Ingo.
It occurred to me this morning that the procname field was dynamically
allocated and needed to be freed. I started to put in break statements
when allocation failed
I forgot to put the seqence numbers in the patch subjects (I did
in the message ids).
Here is the order I diffed them:
sched domain sysctl: register online cpus
sched domain sysctl: free and rebuild when changing domains
sched.c: use kcalloc
sched domain sysctl: don't bug on alloc failure
sched
Now that we are calling this at runtime, a more relaxed error path is
suggested. If an allocation fails, we just register the partial table,
which will show empty directories.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: kernel/kernel/s
The register_sysctl_table stops on the first entry without a
procname and ctl_name, so we need to fill in consecutive entries.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: kernel/kernel/sched.c
===
--- kernel.orig/
init_sched_domain_sysctl was walking cpus 0-n and referencing per_cpu
variables. If the cpus_possible mask is not contigious this will result
in a crash referencing unallocated data. If the online mask is not
contigious then we would show offline cpus and miss online ones.
Signed-off-by: Milton
kcalloc checks for n * sizeof(element) overflows and it zeros.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: kernel/kernel/sched.c
===
--- kernel.orig/kernel/sched.c 2007-10-12 03:58:35.0 -0500
+++ kernel/
Unregister and free the sysctl table before destroying domains, then
rebuild and register after creating the new domains. This prevents the
sysctl table from pointing to freed memory for root to write.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: kernel/kernel/s
The following 5 patches provide fixes for the sysctl code added under
CONFIG_DEBUG_SCHED. After debugging a boot failure dereferencing
not per-cpu data for an impossible cpu, I found the other issues by
inspection.
Following these fixes, /proc/sysctl/kernel/sched_debug/ should work with
The register_sysctl_table stops on the first entry without a
procname and ctl_name, so we need to fill in consecutive entries.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
Index: kernel/kernel/sched.c
===
--- kernel.orig/kernel
init_sched_domain_sysctl was walking cpus 0-n and referencing per_cpu
variables. If the cpus_possible mask is not contigious this will result
in a crash referencing unallocated data. If the online mask is not
contigious then we would show offline cpus and miss online ones.
Signed-off-by: Milton
kcalloc checks for n * sizeof(element) overflows and it zeros.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
Index: kernel/kernel/sched.c
===
--- kernel.orig/kernel/sched.c 2007-10-12 03:58:35.0 -0500
+++ kernel/kernel
Unregister and free the sysctl table before destroying domains, then
rebuild and register after creating the new domains. This prevents the
sysctl table from pointing to freed memory for root to write.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
Index: kernel/kernel/sched.c
The following 5 patches provide fixes for the sysctl code added under
CONFIG_DEBUG_SCHED. After debugging a boot failure dereferencing
not per-cpu data for an impossible cpu, I found the other issues by
inspection.
Following these fixes, /proc/sysctl/kernel/sched_debug/ should work with
Now that we are calling this at runtime, a more relaxed error path is
suggested. If an allocation fails, we just register the partial table,
which will show empty directories.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
Index: kernel/kernel/sched.c
I forgot to put the seqence numbers in the patch subjects (I did
in the message ids).
Here is the order I diffed them:
sched domain sysctl: register online cpus
sched domain sysctl: free and rebuild when changing domains
sched.c: use kcalloc
sched domain sysctl: don't bug on alloc failure
sched
Don't allow cpu hotplug on pSeries systems lacking XICS interrupt controller,
since current code is hardcoded to call xics routines.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--
Olof's patch searched the device-tree again, looking for an mpic. This
code instead checks that we
On Tue, Oct 9 2007 Thomas Gleixner wrote:
>On Tue, 9 Oct 2007, Linus Torvalds wrote:
>>On Wed, 10 Oct 2007, Thomas Gleixner wrote:
>>>
>>> Wrapping it into a #ifdef CONFIG_X86 would be sufficient.
>>
>> Well, the ppc oops seems to be a ppc bug regardless.
>>
>> If CPU_HOTPLUG isn't defined, the
On Tue, Oct 9 2007 Thomas Gleixner wrote:
On Tue, 9 Oct 2007, Linus Torvalds wrote:
On Wed, 10 Oct 2007, Thomas Gleixner wrote:
Wrapping it into a #ifdef CONFIG_X86 would be sufficient.
Well, the ppc oops seems to be a ppc bug regardless.
If CPU_HOTPLUG isn't defined, the thing does
Don't allow cpu hotplug on pSeries systems lacking XICS interrupt controller,
since current code is hardcoded to call xics routines.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
--
Olof's patch searched the device-tree again, looking for an mpic. This
code instead checks that we found
mple check for MAKEFLAGS having -j and refusing to run would
be approprate.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
I chose @: as the phony command after the sub-make target does all the
work; is there a better alternative? It looks like :; is used for
Makefile.
Index:
having -j and refusing to run would
be approprate.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
I chose @: as the phony command after the sub-make target does all the
work; is there a better alternative? It looks like :; is used for
Makefile.
Index: kernel/Makefile
On Jul 20, 2007, at 1:17 PM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation
On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation.
What can't we do? We've already worked with the drivers to quesce
the
hardware and put
On Jul 20, 2007, at 6:17 AM, Rafael J. Wysocki wrote:
On Friday, 20 July 2007 01:07, [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
The currently identified problems under discussion include:
(1) how to interact
On Jul 19, 2007, at 3:28 PM, Rafael J. Wysocki wrote:
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
The currently identified problems under discussion include:
(1) how to interact with acpi to enter into S4.
(2) how to identify which memory needs to be saved
(3) how to communicate where
On Jul 19, 2007, at 12:31 PM, [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Milton Miller wrote:
(2) Upon start-up (by which I mean what happens after the user has
pressed
the power button or something like that):
* check if the image is present (and valid) _without_ enabling
ACPI
On Jul 19, 2007, at 12:31 PM, [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Milton Miller wrote:
(2) Upon start-up (by which I mean what happens after the user has
pressed
the power button or something like that):
* check if the image is present (and valid) _without_ enabling
ACPI
On Jul 19, 2007, at 3:28 PM, Rafael J. Wysocki wrote:
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
The currently identified problems under discussion include:
(1) how to interact with acpi to enter into S4.
(2) how to identify which memory needs to be saved
(3) how to communicate where
On Jul 20, 2007, at 6:17 AM, Rafael J. Wysocki wrote:
On Friday, 20 July 2007 01:07, [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
The currently identified problems under discussion include:
(1) how to interact
On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation.
What can't we do? We've already worked with the drivers to quesce
the
hardware and put
On Jul 20, 2007, at 1:17 PM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation
end of list and s bits would not be set
in the template nor cleared when linking in recieve skbs, so
as long as the kernel can keep up with the 100Mb card we
wouldn't see the adapter go off the linked list, possibly
explaining any successful use of this patch written against
2.6.14).
Signed-off-by: Mi
of list and s bits would not be set
in the template nor cleared when linking in recieve skbs, so
as long as the kernel can keep up with the 100Mb card we
wouldn't see the adapter go off the linked list, possibly
explaining any successful use of this patch written against
2.6.14).
Signed-off-by: Milton
Anton Blanchard wrote:
Hi Ingo,
this is the v5 release of the syslet/threadlet subsystem:
http://redhat.com/~mingo/syslet-patches/
Nice!
I too went and downloaded patches-v5 for review.
First off, one problem I noticed in sys_async_wait:
+ ah->events_left = min_wait_events -
Anton Blanchard wrote:
Hi Ingo,
this is the v5 release of the syslet/threadlet subsystem:
http://redhat.com/~mingo/syslet-patches/
Nice!
I too went and downloaded patches-v5 for review.
First off, one problem I noticed in sys_async_wait:
+ ah-events_left = min_wait_events -
On Feb 27, 2007, at 2:24 AM, David Woodhouse wrote:
On Sun, 2007-02-25 at 20:13 -0800, Linus Torvalds wrote:
On Sun, 25 Feb 2007, David Woodhouse wrote:
Can you try adding something like
memset(start, 0xf0, end - start);
Yeah, I did that before giving up on it for the day and going
On Feb 27, 2007, at 2:24 AM, David Woodhouse wrote:
On Sun, 2007-02-25 at 20:13 -0800, Linus Torvalds wrote:
On Sun, 25 Feb 2007, David Woodhouse wrote:
Can you try adding something like
memset(start, 0xf0, end - start);
Yeah, I did that before giving up on it for the day and going
On Mon, 12 Feb 2007 12:38:15 -0500 (EST), Andrey Borzenkov wrote:
> Is not it too much fore a trivial two lines patch to a single file?
>
> {pts/1}% stg import
> ~/patch/Re_2_6_20_rc6_libata_PATA_ATAPI_CDROM_is_not_working.patch
> Importing
> patch
On Mon, 12 Feb 2007 12:38:15 -0500 (EST), Andrey Borzenkov wrote:
Is not it too much fore a trivial two lines patch to a single file?
{pts/1}% stg import
~/patch/Re_2_6_20_rc6_libata_PATA_ATAPI_CDROM_is_not_working.patch
Importing
patch
On Feb 9, 2007, at 10:17 AM, Carl Love wrote:
On Thu, 2007-02-08 at 20:46 -0600, Milton Miller wrote:
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
On Feb 9, 2007, at 10:17 AM, Carl Love wrote:
On Thu, 2007-02-08 at 20:46 -0600, Milton Miller wrote:
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
On Feb 9, 2007, at 1:10 PM, Arnd Bergmann wrote:
On Friday 09 February 2007 19:47, Milton Miller wrote:
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
Doing the translation in two stages in user space, as you
suggest here, definitely makes sense to me. I think it
can be done a little
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
The current patch specifically identifies that only single
elf objects are handled. There is no code to handle dynamic
linked libraries or overlays. Nor is there any method
On Feb 8, 2007, at 5:59 PM, Maynard Johnson wrote:
Milton,
Thank you for your comments. Carl will reply to certain parts of your
posting where he's more knowledgeable than I. See my replies below.
Thanks for the pleasant tone and dialog.
Milton Miller wrote:
On Feb 6, 2007, at 5:02
On Feb 8, 2007, at 5:59 PM, Maynard Johnson wrote:
Milton,
Thank you for your comments. Carl will reply to certain parts of your
posting where he's more knowledgeable than I. See my replies below.
Thanks for the pleasant tone and dialog.
Milton Miller wrote:
On Feb 6, 2007, at 5:02
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
The current patch specifically identifies that only single
elf objects are handled. There is no code to handle dynamic
linked libraries or overlays. Nor is there any method
On Feb 9, 2007, at 1:10 PM, Arnd Bergmann wrote:
On Friday 09 February 2007 19:47, Milton Miller wrote:
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
Doing the translation in two stages in user space, as you
suggest here, definitely makes sense to me. I think it
can be done a little
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
In the current patch, the user specifies a sample rate as a time
interval.
The kernel is (a) calling
crementer in the SPU), this is obviously a future
item. But it is facilitated by having user space resolve the
SPU to source file translation.
milton
--
[EMAIL PROTECTED] Milton Miller
Speaking for myself only.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
), this is obviously a future
item. But it is facilitated by having user space resolve the
SPU to source file translation.
milton
--
[EMAIL PROTECTED] Milton Miller
Speaking for myself only.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
In the current patch, the user specifies a sample rate as a time
interval.
The kernel is (a) calling
Does anything actually break without this patch?
My reading of unregister_console says we will acquire
the console semaphore, walk the list, fail to find the
console, relase the semaphore, and return.
Hmm... unless there is a problem with the console preference
code? I don't see anything that
Does anything actually break without this patch?
My reading of unregister_console says we will acquire
the console semaphore, walk the list, fail to find the
console, relase the semaphore, and return.
Hmm... unless there is a problem with the console preference
code? I don't see anything that
68 matches
Mail list logo
