l.
I don't know when this happened in 2.4.0-testxx, but 2.2.x does not
show this behavior.
stewart
On Thu, 4 Jan 2001, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, Dec 29, 2000 at 04:25:43PM -0800, Linus Torvalds wrote:
> >
> > Stephen: mind trying your fsync/etc tests
{standard input}: Assembler messages:
{standard input}:8: Warning: Ignoring changed section attributes for
.modinfo
gcc -D__KERNEL__ -I/local/build/2.4.0/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVE
this looks like a typo and fixes a compile error in
2.4.0-ac3.
--- drivers/video/vesafb.c.old Sun Jan 7 12:18:13 2001
+++ drivers/video/vesafb.c Sun Jan 7 12:18:23 2001
@@ -637,7 +637,7 @@
int temp_size = video_size;
/* Find the largest power-of-two */
button until the machine cycles. I have no data
for earlier 2.4.0 kernels.
What else can I do to debug this and what other info will help in
identifying the problem?
Thanks,
Stewart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
in consuming hi percentages.
I've consistently re-produced this on my Dell Latitude CS laptop. I'm
wondering if this will reduce battery life since the CPU is constantly
being loaded instead of properly idled.
Stewart
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
very helpful.
Technical merits and voter intent aside, this behavior is misleading and
inconsistent with previous kernels. Tools like top or a CPU dock applet show
a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled'
seems like the wrong answer.
stewart
On M
I am also having problems with this driver, but with different adapters
and symptoms. depmod is reporting a lot of unresolved symbols for generic
scsi and scsi cdrom. Compiling it into the kernel instead of as a module
seems to bypass the problems.
stewart
On Sun, 17 Dec 2000, Mathias
ditto.
On Sun, 17 Dec 2000, Mathias Wiklander wrote:
> Sorry I've forgot that. It is 2.4.0-test12
>
> /Eastbay
> "Mohammad A. Haque" wrote:
> >
> > Helps if we could get a kernel version.
> >
> > Mathias Wiklander wrote:
> > >
> > > Hi!
> > >
> > > I have problem using my scsi card. It is a
I have a sync()/fdatasync() intensive application that is designed to work
on both raw files and raw partitions. Today I upgraded my kernel to the
new pre-release and found that my benchmark program would no longer finish
when handed a raw partition. I've written a small Java program (my app
Thanks, Andi. In which case sync() for direct buffered block
device access would seem to be broken in 2.4.0-prerelease.
stewart
On Tue, 2 Jan 2001, Andi Kleen wrote:
> On Mon, Jan 01, 2001 at 07:50:31PM -0500, [EMAIL PROTECTED] wrote:
> >
> > I have a sync()/fdatas
Thanks for the correction. I am using a buffered block device
then, not a real synchronous raw device.
stewart
On Tue, 2 Jan 2001, Andi Kleen wrote:
> On Mon, Jan 01, 2001 at 07:50:31PM -0500, [EMAIL PROTECTED] wrote:
> >
> > I have a sync()/fdatasync() intensive appl
The original reason to request this change was simple: to figure out
what type of interface we are looking at, since now some wireless
drivers can simultaneously create managed, p2p and ap interfaces.
Knowing that, from a simple front-end (let's even say a shell script)
we can decide what arguments
On Mon, Apr 22, 2013 at 6:29 AM, Johannes Berg
wrote:
>
> On Wed, 2013-04-17 at 15:14 -0700, Paul Stewart wrote:
> > I believe the documents for "iw" state explicitly that we shouldn't
> > screen-scrape it?
>
> Well, you specifically control your system. I
2.4.3.
Below is the output from a custom board (but the problem also shows up
with a standard PCI card with RTL-8139B) with three RealTek RTL8139
chipsets on it.
[root@stewart-nw34 /root]# ps uax|grep eth
root14 0.0 0.0 00 ? Z13:39 0:00 [eth0 ]
root15 0.0 0.0
On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > Hello,
> >
> > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > thread for each device we have; if the driver is built into the kernel.
> > If the driver i
On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Rod Stewart wrote:
> > > >
> > > > Hello,
> > > >
> > > > Using the 8139too driver, 0.9.15c, we have noti
On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Is there something unusual about your setup?
> >
> > One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400
> >
On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Rod Stewart wrote:
> > > >
> > > > Hello,
> > > >
> > > > Using the 8139too driver, 0.9.15c, we have noti
On Sat, 14 Apr 2001, Manfred Spraul wrote:
> >> Ah. Of course. All (or most) kernel initialisation is
> >> done by PID 1. Search for "kernel_thread" in init/main.c
> >>
> >> So it seems that in your setup, process 1 is not reaping
> >> children, which is why this hasn't been reported before.
> >
t. The thing I find funny is that it only appears
when IP_PNP is compiled in. It is as if the driver ends up in some weird
state when IP_PNP is used. According to ps, from my limited
understanding, the thread is stuck in do_exit
[root@stewart-nw34 /root]# ps elaxww|grep eth
F UID PID PPID
On Sun, 15 Apr 2001, Manfred Spraul wrote:
> Alan, which fix would you prefer:
> * init could use wait3 and set __WALL.
> * all kernel thread users could set SIGCHLD. Some already do that
> (__call_usermodehelper).
> * the kernel_thread implementations could force the exit signal to
> SIGCHLD.
>
On Wed, 29 Nov 2000, Keith Owens wrote:
> On Tue, 28 Nov 2000 20:22:59 +0100,
> Kurt Garloff <[EMAIL PROTECTED]> wrote:
> >Find attached the modules.dep that caused this: There is a circular
> >dependency of pppoe on pppox on pppoe on
>
> The kernel code is broken. Circular dependencies m
Attached is a patch which fixes the boot problems on I-Opener hardware.
The problem is not the IDE chipset, as some had assumed, but rather the
SanDisk flash disk. Since flashdisks typically don't have slaves, there
is code in the kernel to avoid checking for a slave disk if a flashdisk
is detec
Andre Hedrick wrote:
>
> On Sat, 30 Sep 2000, Alex Stewart wrote:
>
> > The attached patch (against 2.4.0-test8) adjusts the code to only mark
> > the slave not present if a flashdisk is master, not vice-versa.
>
> So are you saying that the master is flash and sl
thout proper info, it's a stab in the dark, but has anyone seen
something like this before?
TIA...
-- Alison
-==*==-
Alison Stewart (aka Luna Torquill)
http://www.strappe.com/arcturus/
Foogod Enterprises (www.foogod.com)
---
7;re trying RH7 tomorrow; I expect that will work. If it doesn't, I'll
probably be back -- unless someone can provide a more suitable list to
post to. :)
Thanks.
--A
-----==*==-
Alison Stewart (aka Luna Torquill)
http://www.strappe.com/arcturus/
&quo
Problem fixed (installed RH7). Thanks for the help (with OT stuff, no
less).
--A
-==*==-
Alison Stewart (aka Luna Torquill)
http://www.strappe.com/arcturus/
"I may regret what I have lost, but
I will not regret what I have b
hi,
I have a D-Link DFE-530TX Rev A, PCI ethernet card, but it refuses
to work.
I have looked at http://www.scyld.com/network/index.html#pci
which sugests using the via-rhine driver.
I did this and compiled it into the kernel. It detects it at boot (via-
rhine v1.08-LK1.1.6 8/9/2000 Donald Bec
On 2 Feb 2001, at 20:17, Urban Widmark wrote:
>
> > >I did this and compiled it into the kernel. It detects it at boot
> > >(via- rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the
> > >hardware address (mac address?) is 00-00-00-00-00-00.
>
> This is a good example of what is missed by no
On 3 Feb 2001, at 14:02, Urban Widmark wrote:
> This is intresting. Your card reports that it is stopped while the
> other report show normal values on most things. Does this change if
> you try and send something (like a ping)? Common to both reports is
> that the transceivers don't respond.
>
00 00
0x110: 00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73
MII PHY found at address 8, status 0x782d.
MII PHY #8 transceiver registers:
3000 782d 0016 f880 01e1 4461
ffff
0022 ff40 0050 ffc0 00a0
as working and
when it was not working.
regards
tom
-
This message is ROT-13 encoded twice for extra security
Thomas Stewart - [EMAIL PROTECTED]
This should contain no attachments
-
-
To unsubscribe from this list: send the line "un
On 5 Feb 2001, at 11:58, Manfred Spraul wrote:
> Thomas Stewart wrote:
> Several regs are just the wakeup frames, but some look suspicious.
>
> Could you try Urban's patch, but add
>
> <<<<<<<<
> writeb(0x00, ioaddr + 0x83);
> writel(0x0
worked" although we do seem to get issues
on ext3).
I have a (casually stupid) simulation program... although I've observed
little to no problems on all my XFS tests using it.
--
Stewart Smith, Senior Software Engineer (MySQL Cluster)
MySQL AB, www.mysql.com
Office: +1408213
:
Tyan S2882 dual opteron 240
4 gig ram
2 Highpoint 1820a
12 seagate 7200.7 baracudas
Thank you
Billy Stewart
- exerpt below
I've upgraded from 2.6.9 to 2.6.11-rc1 and the problem has been gone! On
Sun, 2005-01-16 at 23:14 +0100, Pallai Roland wrote: > I've read a
Originator: Stewart Andreason <[EMAIL PROTECTED]>
Synopsis: upgrade from 2.2.16 to 2.2.19 results in 2 failures:
Unable to find Adaptec or SCSI CDrom drive
Unable to load PPP compression module
__clip from successful 2.2.16 boot
detected 1 controller(s)
aha152x0: vita
es Inc Radeon
RV200 QW [Radeon 7500]
Thanks in advance for your help.
Andy
--
Andy Stewart, Founder
Worcester Linux Users' Group
Worcester, MA, USA
http://www.wlug.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
HI again,
Does anybody have any suggestions as to what I could do to help debug
this situation?
Perhaps someone who has this working with this kernel version might
share what worked for them.
Thanks again,
Andy
--
Andy Stewart, Founder
Worcester Linux Users' Group
Worcester, MA, USA
UIRY failed with code 0x2
I don't yet know why the DVD burner is failing on the scsi INQUIRY
command. Does anybody have any ideas?
I plan to keep looking.
Thanks,
Andy
--
Andy Stewart, Founder
Worcester Linux Users' Group
Worcester, MA, USA
http://www.wlug.org
-
To unsubscribe from thi
ing happening.
yes. Keep in mind that the binlog grows in file size too... so this has
to sync all the metadata as well (ick, i know).
--
Stewart Smith, Senior Software Engineer
MySQL AB, www.mysql.com
Office: +14082136540 Ext: 6616
VoIP: [EMAIL PROTECTED]
Mobile: +61 4 3 8844 332
Jum
Shilpasri G Bhat writes:
> Modify the OCC reset/load/active event message to make it clearer for
> the user to understand the event and effect of the event.
>
> Suggested-by: Stewart Smith
> Signed-off-by: Shilpasri G Bhat
Acked-by: Stewart Smith
--
To unsubscribe from this
ame(rm_node, "ibm,homer-image"); dn;
> + dn = of_find_node_by_name(dn, "ibm,homer-image")) {
> +
> + /* Get the chip id to which the above homer region belongs to */
> + if (of_property_read_u32(dn, "ibm,chip-id", &chip_id))
> + goto err;
So, I was thinking on this (and should probably comment on the firmware
side as well).
I'd prefer an OPAL interface where instead of looking up where
ibm,homer-image is, we provide the kernel with a base address and then
have offsets into it.
That way, we don't tie the kernel code to counters that are only in the
HOMER region.
--
Stewart Smith
OPAL Architect, IBM.
n OPAL_IMC_COUNTERS_INIT should return
OPAL_SUCCESS and just do nothing. This future proofs everything, and the
API is that one *must* call _INIT before start.
--
Stewart Smith
OPAL Architect, IBM.
Compliments of the day ;
I have a business proposition for you which I sent you previously,I do not
know if you received it?
Please do find it proper to write me if your email is still active.
Yours Faithfully,Barr. Alexander Stewart.
that you can answer "where did all my CPUs go?"
by looking at the device tree rather than having to know the platform
specific way of how guards are stored.
--
Stewart Smith
OPAL Architect, IBM.
Colin King writes:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in hmi_error_types text
>
> Signed-off-by: Colin Ian King
Reviewed-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
Pranith Kumar writes:
> On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman
> wrote:
>> On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote:
>>> When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
>>> return 0. Check for these return values and skip registering the dump
nseText
>>
>> Signed-off-by: Thomas Gleixner
>
> Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kate Stewart
Apache-2.0.html#licenseText
>>
>> Signed-off-by: Thomas Gleixner
>
> Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kate Stewart
ontinuing on is okay, as we have to keep compatibility with that firmware.
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -17,7 +17,7 @@
>
> #define CPUIDLE_STATE_MAX10
> #define CPUIDLE_NAME_LEN 16
> -#define CPUIDLE_DESC_LEN 32
> +#define CPUIDLE_DESC_LEN 60
Do we really get that long?
--
Stewart Smith
OPAL Architect, IBM.
d
workloads, if you guard out a CPU core you'll not get WoF, which means
that performance goes down when you wouldn't expect it to. Right?
--
Stewart Smith
OPAL Architect, IBM.
; OpenIB.org license is a true match to BSD-2-Clause.
>
> The license text was copied from:
>
> https://spdx.org/licenses/Linux-OpenIB.html#licenseText
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Kate Stewart
-BY-SA-4.0.html#licenseText
>>
>> Signed-off-by: Thomas Gleixner
>
> Reviewed-by: Greg Kroah-Hartman
>
Reviewed-by: Kate Stewart
Greg KH writes:
> On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
>>
>> > There were only 3 (or 4), users of this api, and no new ones had been
>> > added in _years_, it's a very obscure thing, and odds are, it wouldn't
Tejun Heo writes:
> On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
>> I think this is being blown out of proportion. It was a rarely used
>> API and converting to the new one is mostly trivial which can be
>
> So, looked at the failed code. The only necessary change seems to be
> cal
Previously, many years ago, this was done in series which was fine,
but things moved to be done in parallel and with many disks in a system
it can be hard to see which disk spun up and which one didn't as the
printk messages were all mixed together.
Signed-off-by: Stewart Smith
---
drivers
n Fontenot
> Signed-off-by: Greg Kurz
Acked-by: Stewart Smith
--
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/
Vasant Hegde writes:
> PowerNV platform is capable of capturing host memory region when system
> crashes (because of host/firmware). We have new OPAL API to register
> memory region to be capture when system crashes.
>
> This patch adds support for new API and also registers kernel log
> buffer.
Greg Kurz writes:
> struct rtas_error_log {
> +#ifdef __BIG_ENDIAN__
> + /* Byte 0 */
> unsigned long version:8;/* Architectural version */
> + /* Byte 1 */
I think it would be great if we got rid of the usage of bitfields. As
soon as the mood of the compiler change
Greg Kurz writes:
> On Mon, 31 Mar 2014 09:27:16 +1100
> Stewart Smith wrote:
>> Greg Kurz writes:
>> > struct rtas_error_log {
>> > +#ifdef __BIG_ENDIAN__
>> > + /* Byte 0 */
>> >unsigned long version:8;/* Architectural v
Benjamin Herrenschmidt writes:
> On Mon, 2014-03-31 at 09:27 +1100, Stewart Smith wrote:
>> Greg Kurz writes:
>> > struct rtas_error_log {
>> > +#ifdef __BIG_ENDIAN__
>> > + /* Byte 0 */
>> >unsigned long version:8;/* Architect
Signed-off-by: Brandon Stewart
---
drivers/macintosh/adb.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
index 04a5049..53611de 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -38,7
I corrected several coding errors.
Signed-off-by: Brandon Stewart
---
drivers/macintosh/adb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
index 53611de..dd3f49a 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers
Shilpasri G Bhat writes:
> Add OPAL_MSG_OCC message definition to opal_message_type to receive
> OCC events like reset, load and throttled. Host performance can be
> affected when OCC is reset or OCC throttles the max Pstate.
> We can register to opal_message_notifier to receive OPAL_MSG_OCC type
Shilpasri G Bhat writes:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index d0c18c9..a634199 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include /* Require
Shilpasri G Bhat writes:
>> Also, do we export this information via sysfs somewhere? It would seem
>> to want to go along with other cpufreq/cpu info there.
>
> No we don't export the throttling status of the cpu via sysfs. Since the
> throttling state is common across the chip, the per_cpu export
PAL.
With a slight change to the commit message,
Acked-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
Daniel Axtens writes:
> I just realised I sent my reply to Denis not the list - apologies. This
> info goes for v2 as well.
>
> > Could you explain why it's useful, and what it's useful for. Moreover,
> > it's POWER8 feature, right?
>
> I'm not sure whether you're asking about the script or
linux.conf.au 2016 in Geelong will have a kernel miniconf. The format is
part talks, part unconference.
The miniconf will be all day Monday.
Like previous years, a mixture of organised talks and impromptu
discussion and sessions can provide a good mix.
CFP open until Jan 20th. Unconference topic
a
work-in-progress getting all this documentation in order.
The questions of if it's a sensible hypervisor to partition interface
and if it's a sensible userspace API are open for debate :)
Would we implement this way of communicating between a KVM guest and the
host linux system? If not, then it's probably not a generally good
idea. That being said, it seems to be what already exists in PowerVM
--
Stewart Smith
OPAL Architect, IBM.
Michael Ellerman writes:
> Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
> output confirms
6f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
> Signed-off-by: Michael Ellerman
> Signed-off-by: Anton Blanchard
By building a gcov enabled skiboot, which makes OPAL_START_CPU a whole
bunch slower (because gcov), I could really *really* reliably reproduce
this. With th
Madhavan Srinivasan writes:
> Nest Counters can be configured via PORE Engine and OPAL
> provides an interface call to it. PORE Engine also does the
> work of moving the counter data to memory.
Do you have the associated skiboot patch that implements this firmware
call? I haven't seen it on th
This just leaves us with CXL vs CAPI as differences in the list of OPAL
calls between opal.h in firmware and opal.h in Linux.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 2aaa861..b60a25a 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc
OPAL/IBM calls it CAPI and Linux calls it CXL because CAPI was taken.
In order to have opal.h match between firmware and Linux, we're going
to just deal with one call used in a place be CAPI rather than CXL to
match what's in firmware.
Signed-off-by: Stewart Smith
---
arch/powerpc/i
For whatever strange reason, these two structures were in different
locations in opal.h in firmware and opal.h in Linux. Move them around
to match firmware so that the diff is less.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 32
1 file
this adds CAPI and EPOW parts to opal.h that previously were only
in firmware opal.h
Currently unused, but gets us really close to being able to share
opal.h between firmware and linux.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 52
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 4373010..240ee1c 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index c09cf66..2aaa861 100644
--- a/arch/powerpc/include/asm/opal.h
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 2441f36..68ce7ef 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc
For whatever reason these structures were in different places.
Now they are not.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 48 +++
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b
e.
In the process of doing this, I fixed a few things in firmware too,
so this matches skiboot at 4681ed9, which is a little after the most
recent skiboot release (4.1.1).
The biggest change is moving the function prototypes for API calls
out to opal-api.h.
Stewart Smith (18):
powerpc/powernv:
Adds OPAL_MSG_DPO and docs for OPAL_MSG_SHUTDOWN
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 3786c6b..2deaadf 100644
--- a/arch
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal-api.h |4
arch/powerpc/include/asm/opal.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index c4009dd..172d08e
This patch just matches whitespace and comments between
the opal.h from firmware and that in linux.
No addition/removal.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9ca5167..7075f57 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch
reduces the diff between linux and firmware header files significantly.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 51 +++
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc
Some enums in firmware opal.h were missing from linux opal.h, add them.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
This finally syncs the content of opal.h between linux and firmware
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 68ce7ef
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 7075f57..31b9656 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc
To further the cause of syncing opal.h between firmware and linux,
move the function prototypes that were in opal.h out to opal-api.h
and fix the associated includes.
There are still a few places where opal.h is adequate.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal-api.h
Michael Ellerman writes:
> I'm going to be a total pain, and suggest that this is the wrong approach :)
>
> I was on board until patch 15, where you have to add an #ifdef SKIBOOT to
> guard
> an include, and you have to remove an include on the Linux side.
(the Linux include was actually not use
rthy
Same acked-by as before, from perspective of "I merged the firmware side
of things" and things look godo in relation to firmware PoV.
Acked-by: Stewart Smith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
Correct use of REGISTER/UNREGISTER is to check if the token exists
before calling. If we don't we get a "OPAL: Called with bad token 101 !"
error, which is harmless but may be alarming to some.
Signed-off-by: Stewart Smith
---
arch/powerpc/platforms/powernv/opal.c |6 +-
Not all OPAL platforms support resending system dumps, so check
that current firmware supports it first. Otherwise we get firmware
complaining:
"OPAL: Called with bad token 91 !"
Signed-off-by: Stewart Smith
---
arch/powerpc/platforms/powernv/opal-dump.c |3 ++-
1 file changed, 2
.
Stewart Smith (3):
powerpc/powernv: only register log if OPAL supports doing so
powerpc/powernv: only call OPAL_ELOG_RESEND if firmware supports it
powerpc/powernv: only call OPAL_RESEND_DUMP if firmware supports it
arch/powerpc/platforms/powernv/opal-dump.c |3 ++-
arch/powerpc
Otherwise firmware complains: "OPAL: Called with bad token 74 !"
as not all OPAL systems have the ability to resend error logs.
Signed-off-by: Stewart Smith
---
arch/powerpc/platforms/powernv/opal-elog.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ar
Preeti U Murthy writes:
> On 01/28/2015 02:45 PM, Stewart Smith wrote:
>> Preeti U Murthy writes:
>>> The device tree now exposes the residency values for different idle states.
>>> Read
>>> these values instead of calculating residency from the latency va
nd falling back looks good.
(I find the hardcoding of snooze in the driver a bit odd, as is the
hardcoding of max power states to 8 - which could bite us in the future
if a future processor has more states... but these aren't problems with
this patch)
Acked-by: Stewart Smith
--
To unsubscri
1 - 100 of 167 matches
Mail list logo
