* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-30 1:26 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <AANLkTikSH8_QXV2qsBR+vxsjvQwNdx2st3vfbRpfsMff@mail.gmail.com>
On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
> Hi Greg:
>
> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
> >> Hi Greg:
> >>
> >> We will change to a BSD 3 clause license header. Our legal counsel is
> >> talking to Synopsis to make this change.
> >
> > Why BSD? You do realize what that means when combined within the body
> > of the kernel, right?
> >
>
> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
> Hil driver.
What specific driver is this?
And are you sure that all of the contributors to the code agree with
this licensing change? Are you going to require contributors to
dual-license their changes?
If so, why keep it BSD, what does that get you?
> > Are you going to be expecting others to contribute back to the code
> > under this license, or will you accept the fact that future
> > contributions from the community will cause the license to change?
You didn't answer this question, which is a very important one before I
can accept this driver.
> >> We will resubmit once this is in place. Please let me know if you have
> >> any additional concerns.
> >
> > My main concern is that you, and everyone else involved in the driver,
> > never considered the license of the code in the first place and expected
> > the kernel community to accept it as-is, placing the problem on us.
>
> FKAN: Please don't think this is the case, we gone through this exercise
> with Denx.
What is "Denx"?
> We had legal looking into the header before submission
> to them and the kernel.
Then what happened here? Just curious as to how the driver was public
for so long before someone realized this.
> > What will be done in the future to prevent this from happening again?
>
> FKAN: agreed, once bitten .... :)
That didn't answer the question :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: David Gibson @ 2010-07-30 1:38 UTC (permalink / raw)
To: Grant Likely
Cc: Mitch Bradley, Matthew McClintock, Kumar Gala, linuxppc-dev,
Timur Tabi
In-Reply-To: <AANLkTilDcYYbsH-6f0_HlX9WwaOwG24w1CfhRLplZKS7@mail.gmail.com>
On Thu, Jul 15, 2010 at 01:18:21PM -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm@freescale.com> wrote:
> > On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
> >> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm@freescale.com> wrote:
> >> > Yes. Where would we get a list of memreserve sections?
> >>
> >> I would say the list of reserves that are not under the control of
> >> Linux should be explicitly described in the device tree proper. For
> >> instance, if you have a region that firmware depends on, then have a
> >> node for describing the firmware and a property stating the memory
> >> regions that it depends on. The memreserve regions can be generated
> >> from that.
> >
> > Ok, so we could traverse the tree node-by-bode for a
> > persistent-memreserve property and add them to the /memreserve/ list in
> > the kexec user space tools?
Well.. I don't think it should be this way as a matter of spec. But
you could use a property as an interim stash for memreserve
information.
I agree that the precise defined semantics of the memreserve regions
is kind of fuzzy and non-obvious. Here's how I believe they need to
work:
memory in a reserved region must *never* be touched by the OS
(or subsequent kexec-invoked OSes) unless something else in the device
tree explicitly instructs it how
There already exist several mechanisms for instructing the OS to use
particular reserved regions for particular purposes: e.g. the initrd
properties, and the spin-table properties. More such mechanisms might
be added in future ePAPR (or whatever) revisions. But if the OS
version doesn't understand such a future mechanism, it must fall back
to assuming that the memory is reserved in perpetuity.
Now, some of these mechanisms (implicitly) permit the OS to re-use the
reserved memory after it's done using them as instructed (initrd is
the most obvious one). In that case the OS can re-add the reserved
space to it's general pools, and excise it from the reserved space for
subsequent kexec()-style boots. However that's (potentially) a more
complex process than just removing an entry - the initial firmware is
free to combine adjacent reserved regions into one reserve entry, or
even to cover a single reserved region with multiple entries. So in
order to do this manipulation you will need an allocator of sorts that
does the region reservation/dereservation correctly handling the
semantics on a byte-by-byte basis.
You should also be careful that the regions you're handling do
actually lie in memory space. Linux doesn't support this right now,
but I do have an experimental patch that allows the initrd properties
to point to (e.g.) flash instead of RAM. In that case the initrd
wouldn't have to lie in an explicitly reserved region, and obviously
could not be returned to the general pool after use.
> I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch,
> David Gibson, and other device tree experts on whether or not that
> exact property naming is a good one.
>
> Write up a proposed binding (you can use devicetree.org). Post it for
> review (make sure you cc: both devicetree-discuss and linuxppc-dev, as
> well as cc'ing the people listed above.)
>
> >> > Should we export
> >> > the reserve sections instead of the device tree location?
> >>
> >> It shouldn't really be something that the kernel is explicitly
> >> exporting because it is a characteristic of the board design. It is
> >> something that belongs in the tree-proper. ie. when you extract the
> >> tree you have data telling what the region is, and why it is reserved.
> >
> > Agreed.
> >
> >>
> >> > We just need a
> >> > way to preserve what was there at boot to pass to the new kernel.
> >>
> >> Yet there is no differentiation between the board-dictated memory
> >> reserves and the things that U-Boot/Linux made an arbitrary decision
> >> on. The solution should focus not on "can I throw this one away?" but
> >> rather "Is this one I should keep?" :-) A subtle difference, I know,
> >> but it changes the way you approach the solution.
> >
> > Fair enough. I think the above solution will work nicely, and I can
> > start implementing something if you agree - if I interpreted your idea
> > correctly. Although it should not require any changes to the kernel
> > proper.
>
> Correct.
>
> g.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-30 2:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730012650.GB24931@suse.de>
On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
>> Hi Greg:
>>
>> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
>> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> >> Hi Greg:
>> >>
>> >> We will change to a BSD 3 clause license header. Our legal counsel is
>> >> talking to Synopsis to make this change.
>> >
>> > Why BSD? =C2=A0You do realize what that means when combined within the=
body
>> > of the kernel, right?
>> >
>>
>> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hil driver.
>
> What specific driver is this?
FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
>
> And are you sure that all of the contributors to the code agree with
> this licensing change? =C2=A0Are you going to require contributors to
> dual-license their changes?
>
> If so, why keep it BSD, what does that get you?
FKAN: for one thing, to make it future proof on other submissions.
>
>> > Are you going to be expecting others to contribute back to the code
>> > under this license, or will you accept the fact that future
>> > contributions from the community will cause the license to change?
>
>
> You didn't answer this question, which is a very important one before I
> can accept this driver.
FKAN: Yes, all of the above. Our legal is working on that. I thought by def=
ault
GPL defines the above statement.
>
>> >> We will resubmit once this is in place. Please let me know if you hav=
e
>> >> any additional concerns.
>> >
>> > My main concern is that you, and everyone else involved in the driver,
>> > never considered the license of the code in the first place and expect=
ed
>> > the kernel community to accept it as-is, placing the problem on us.
>>
>> FKAN: Please don't think this is the case, we gone through this exercise
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with Denx.
>
> What is "Denx"?
FKAN: U-Boot Denx.de
>
>> We had legal looking into the header before submission
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to them and the kernel.
>
> Then what happened here? =C2=A0Just curious as to how the driver was publ=
ic
> for so long before someone realized this.
>
FKAN: this was few years back. At the time we had the header changed
so it was BSD like to be accepted by Denx.
>> > What will be done in the future to prevent this from happening again?
>>
>> FKAN: agreed, once bitten .... :)
>
> That didn't answer the question :)
FKAN: we have a system of checks for every patch that goes out. I will send
out a guideline to all reviewer to make sure the header
follow kernel precedence.
Legal is quite aware of the issue now too.
>
> thanks,
>
> greg k-h
>
--=20
Feng Kan
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Michael Neuling @ 2010-07-30 3:15 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, kexec, Milton Miller
In-Reply-To: <4C521FD2.4050301@ozlabs.org>
(adding kexec list to CC)
In message <4C521FD2.4050301@ozlabs.org> you wrote:
> Michael Neuling wrote:
> > In message <4C511216.30109@ozlabs.org> you wrote:
> >> When CPU hotplug is used, some CPUs may be offline at the time a kexec is
> >> performed. The subsequent kernel may expect these CPUs to be already runn
ing
> > ,
> >> and will declare them stuck. On pseries, there's also a soft-offline (ced
e)
> >> state that CPUs may be in; this can also cause problems as the kexeced ker
nel
> >> may ask RTAS if they're online -- and RTAS would say they are. Again, stu
ck.
> >>
> >> This patch kicks each present offline CPU awake before the kexec, so that
> >> none are lost to these assumptions in the subsequent kernel.
> >
> > There are a lot of cleanups in this patch. The change you are making
> > would be a lot clearer without all the additional cleanups in there. I
> > think I'd like to see this as two patches. One for cleanups and one for
> > the addition of wake_offline_cpus().
>
> Okay, I can split this. Typofixy-add-debug in one, wake_offline_cpus
> in another.
Thanks.
>
> > Other than that, I'm not completely convinced this is the functionality
> > we want. Do we really want to online these cpus? Why where they
> > offlined in the first place? I understand the stuck problem, but is the
> > solution to online them, or to change the device tree so that the second
> > kernel doesn't detect them as stuck?
>
> Well... There are two cases. If a CPU is soft-offlined on pseries, it
> must b e woken from that cede loop (in
> platforms/pseries/hotplug-cpu.c) as we're repla cing code under its
> feet. We could either special-case the wakeup from this ce de loop to
> get that CPU to RTAS "stop-self" itself properly. (Kind of like a "
> wake to die".)
Makes sense.
> So that leaves hard-offline CPUs (perhaps including the above): I
> don't know why they might have been offlined. If it's something
> serious, like fire, they'd be removed from the present set too (and
> thus not be considered in this restarting case). We could add a mask
> to the CPU node to show which of the threads (if any) are running, and
> alter the startup code to start everything if this mask doesn't exist
> (non-kexec) or only online currently-running threads if the mask is
> present. That feels a little weird.
>
> My reasoning for restarting everything was: The first time you boot,
> all of your present CPUs are started up. When you reboot, any CPUs
> you offlined for fun are restarted. Kexec is (in this non-crash
> sense) a user-initiated 'quick reboot', so I reasoned that it should
> look the same as a 'hard reboot' and your new invocation would have
> all available CPUs running as is usual.
OK, I like this justification. Would be good to include it in the
checkin comment since we're changing functionality somewhat.
Mikey
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-30 3:36 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <AANLkTimiox6UbUnhSRLgC06S2kfcDOANA08gm3m++TXd@mail.gmail.com>
On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote:
> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
> > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
> >> Hi Greg:
> >>
> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
> >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
> >> >> Hi Greg:
> >> >>
> >> >> We will change to a BSD 3 clause license header. Our legal counsel is
> >> >> talking to Synopsis to make this change.
> >> >
> >> > Why BSD? ??You do realize what that means when combined within the body
> >> > of the kernel, right?
> >> >
> >>
> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
> >> ?? ?? ?? ?? ?? ??Hil driver.
> >
> > What specific driver is this?
>
> FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
Ok, thanks.
Are you _sure_ that you didn't take any existing GPL code and put it
into this driver when making it? Did all contributors to the code
release their contributions under both licenses?
> > And are you sure that all of the contributors to the code agree with
> > this licensing change? ??Are you going to require contributors to
> > dual-license their changes?
> >
> > If so, why keep it BSD, what does that get you?
>
> FKAN: for one thing, to make it future proof on other submissions.
What do you mean by this? What can you do with this code other than use
it on a Linux system? You can't put it into any other operating system
with a different license, can you?
> >> > Are you going to be expecting others to contribute back to the code
> >> > under this license, or will you accept the fact that future
> >> > contributions from the community will cause the license to change?
> >
> >
> > You didn't answer this question, which is a very important one before I
> > can accept this driver.
>
> FKAN: Yes, all of the above. Our legal is working on that. I thought by default
> GPL defines the above statement.
The GPL does, but as you are trying to dual-license the code, you have
to be careful about how you accept changes, and under what license.
It's a lot more work than I think you realize. What process do you have
in place to handle this?
> >> >> We will resubmit once this is in place. Please let me know if you have
> >> >> any additional concerns.
> >> >
> >> > My main concern is that you, and everyone else involved in the driver,
> >> > never considered the license of the code in the first place and expected
> >> > the kernel community to accept it as-is, placing the problem on us.
> >>
> >> FKAN: Please don't think this is the case, we gone through this exercise
> >> ?? ?? ?? ?? ?? with Denx.
> >
> > What is "Denx"?
>
> FKAN: U-Boot Denx.de
Ah, thanks.
> >> We had legal looking into the header before submission
> >> ?? ?? ?? ?? ?? to them and the kernel.
> >
> > Then what happened here? ??Just curious as to how the driver was public
> > for so long before someone realized this.
> >
>
> FKAN: this was few years back. At the time we had the header changed
> so it was BSD like to be accepted by Denx.
>
> >> > What will be done in the future to prevent this from happening again?
> >>
> >> FKAN: agreed, once bitten .... :)
> >
> > That didn't answer the question :)
>
> FKAN: we have a system of checks for every patch that goes out. I will send
> out a guideline to all reviewer to make sure the header
> follow kernel precedence.
But you took this code from a different vendor, are you able to properly
identify the code contributions to this base and what license it is
under and where they got it from?
> Legal is quite aware of the issue now too.
As they should be :)
Please reconsider the dual licensing unless you really are ready to
handle the implications of it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Simon Horman @ 2010-07-30 3:25 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, kexec, Milton Miller, Matt Evans
In-Reply-To: <20694.1280459714@neuling.org>
On Fri, Jul 30, 2010 at 01:15:14PM +1000, Michael Neuling wrote:
> (adding kexec list to CC)
>
> In message <4C521FD2.4050301@ozlabs.org> you wrote:
> > Michael Neuling wrote:
> > > In message <4C511216.30109@ozlabs.org> you wrote:
> > >> When CPU hotplug is used, some CPUs may be offline at the time a kexec is
> > >> performed. The subsequent kernel may expect these CPUs to be already runn
> ing
> > > ,
> > >> and will declare them stuck. On pseries, there's also a soft-offline (ced
> e)
> > >> state that CPUs may be in; this can also cause problems as the kexeced ker
> nel
> > >> may ask RTAS if they're online -- and RTAS would say they are. Again, stu
> ck.
> > >>
> > >> This patch kicks each present offline CPU awake before the kexec, so that
> > >> none are lost to these assumptions in the subsequent kernel.
> > >
> > > There are a lot of cleanups in this patch. The change you are making
> > > would be a lot clearer without all the additional cleanups in there. I
> > > think I'd like to see this as two patches. One for cleanups and one for
> > > the addition of wake_offline_cpus().
> >
> > Okay, I can split this. Typofixy-add-debug in one, wake_offline_cpus
> > in another.
>
> Thanks.
>
> >
> > > Other than that, I'm not completely convinced this is the functionality
> > > we want. Do we really want to online these cpus? Why where they
> > > offlined in the first place? I understand the stuck problem, but is the
> > > solution to online them, or to change the device tree so that the second
> > > kernel doesn't detect them as stuck?
> >
> > Well... There are two cases. If a CPU is soft-offlined on pseries, it
> > must b e woken from that cede loop (in
> > platforms/pseries/hotplug-cpu.c) as we're repla cing code under its
> > feet. We could either special-case the wakeup from this ce de loop to
> > get that CPU to RTAS "stop-self" itself properly. (Kind of like a "
> > wake to die".)
>
> Makes sense.
>
> > So that leaves hard-offline CPUs (perhaps including the above): I
> > don't know why they might have been offlined. If it's something
> > serious, like fire, they'd be removed from the present set too (and
> > thus not be considered in this restarting case). We could add a mask
> > to the CPU node to show which of the threads (if any) are running, and
> > alter the startup code to start everything if this mask doesn't exist
> > (non-kexec) or only online currently-running threads if the mask is
> > present. That feels a little weird.
> >
> > My reasoning for restarting everything was: The first time you boot,
> > all of your present CPUs are started up. When you reboot, any CPUs
> > you offlined for fun are restarted. Kexec is (in this non-crash
> > sense) a user-initiated 'quick reboot', so I reasoned that it should
> > look the same as a 'hard reboot' and your new invocation would have
> > all available CPUs running as is usual.
>
> OK, I like this justification. Would be good to include it in the
> checkin comment since we're changing functionality somewhat.
FWIW, I do too. Personally I like to think of kexec as soft-reboot.
Where soft means, in software, not soft-touch.
^ permalink raw reply
* [PATCH 3/3 v2] mmc: Add ESDHC weird voltage bits workaround
From: Roy Zang @ 2010-07-30 3:52 UTC (permalink / raw)
To: linux-mmc; +Cc: linuxppc-dev, akpm
P4080 ESDHC controller does not support 1.8V and 3.0V voltage. but the
host controller capabilities register wrongly set the bits.
This patch adds the workaround to correct the weird voltage setting bits.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
This is the second version of patch
http://patchwork.ozlabs.org/patch/60106/
According to the comment, remove some un-necessary setting.
Together with patch
http://patchwork.ozlabs.org/patch/60111/
http://patchwork.ozlabs.org/patch/60116/
This serial patches add mmc support for p4080 silicon
drivers/mmc/host/sdhci-of-core.c | 4 ++++
drivers/mmc/host/sdhci.c | 8 ++++++++
drivers/mmc/host/sdhci.h | 4 ++++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index 0c30242..1f3913d 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -164,6 +164,10 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
if (sdhci_of_wp_inverted(np))
host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
+ if (of_device_is_compatible(np, "fsl,p4080-esdhc"))
+ host->quirks |= (SDHCI_QUIRK_QORIQ_NO_VDD_180
+ |SDHCI_QUIRK_QORIQ_NO_VDD_300);
+
clk = of_get_property(np, "clock-frequency", &size);
if (clk && size == sizeof(*clk) && *clk)
of_host->clock = *clk;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1424d08..a667790 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1699,6 +1699,14 @@ int sdhci_add_host(struct sdhci_host *host)
caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+ /* Workaround for P4080 host controller capabilities
+ * 1.8V and 3.0V do not supported*/
+ if (host->quirks & SDHCI_QUIRK_QORIQ_NO_VDD_180)
+ caps &= ~SDHCI_CAN_VDD_180;
+
+ if (host->quirks & SDHCI_QUIRK_QORIQ_NO_VDD_300)
+ caps &= ~SDHCI_CAN_VDD_300;
+
if (host->quirks & SDHCI_QUIRK_FORCE_DMA)
host->flags |= SDHCI_USE_SDMA;
else if (!(caps & SDHCI_CAN_DO_SDMA))
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index aa112aa..389b58c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -243,6 +243,10 @@ struct sdhci_host {
#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
/* Controller uses Auto CMD12 command to stop the transfer */
#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
+/* Controller cannot support 1.8V */
+#define SDHCI_QUIRK_QORIQ_NO_VDD_180 (1<<28)
+/* Controller cannot support 3.0V */
+#define SDHCI_QUIRK_QORIQ_NO_VDD_300 (1<<29)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2] powerpc/kexec: Fix orphaned offline CPUs, add comments/debug
From: Matt Evans @ 2010-07-30 4:44 UTC (permalink / raw)
To: linuxppc-dev, kexec; +Cc: Michael Neuling, Milton Miller
Separated tidyup comments & debug away from the fix of restarting offline
available CPUs before waiting for them on kexec.
Matt Evans (2):
powerpc/kexec: Add to and tidy debug/comments in machine_kexec64.c
powerpc/kexec: Fix orphaned offline CPUs across kexec
arch/powerpc/kernel/machine_kexec_64.c | 55 ++++++++++++++++++++++++++++---
1 files changed, 49 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 1/2] powerpc/kexec: Add to and tidy debug/comments in machine_kexec64.c
From: Matt Evans @ 2010-07-30 4:47 UTC (permalink / raw)
To: linuxppc-dev, kexec; +Cc: Michael Neuling, Milton Miller
In-Reply-To: <4C5258C8.1030305@ozlabs.org>
Tidies some typos, KERN_INFO-ise an info msg, and add a debug msg showing
when the final sequence starts.
Also adds a comment to kexec_prepare_cpus_wait() to make note of a possible
problem; the need for kexec to deal with CPUs that failed to originally start
up.
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/kernel/machine_kexec_64.c | 29 ++++++++++++++++++++++++-----
1 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 4fbb3be..aa3d5cd 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -15,6 +15,7 @@
#include <linux/thread_info.h>
#include <linux/init_task.h>
#include <linux/errno.h>
+#include <linux/kernel.h>
#include <asm/page.h>
#include <asm/current.h>
@@ -181,7 +182,20 @@ static void kexec_prepare_cpus_wait(int wait_state)
int my_cpu, i, notified=-1;
my_cpu = get_cpu();
- /* Make sure each CPU has atleast made it to the state we need */
+ /* Make sure each CPU has at least made it to the state we need.
+ *
+ * FIXME: There is a (slim) chance of a problem if not all of the CPUs
+ * are correctly onlined. If somehow we start a CPU on boot with RTAS
+ * start-cpu, but somehow that CPU doesn't write callin_cpu_map[] in
+ * time, the boot CPU will timeout. If it does eventually execute
+ * stuff, the secondary will start up (paca[].cpu_start was written) and
+ * get into a peculiar state. If the platform supports
+ * smp_ops->take_timebase(), the secondary CPU will probably be spinning
+ * in there. If not (i.e. pseries), the secondary will continue on and
+ * try to online itself/idle/etc. If it survives that, we need to find
+ * these possible-but-not-online-but-should-be CPUs and chaperone them
+ * into kexec_smp_wait().
+ */
for_each_online_cpu(i) {
if (i == my_cpu)
continue;
@@ -189,9 +203,9 @@ static void kexec_prepare_cpus_wait(int wait_state)
while (paca[i].kexec_state < wait_state) {
barrier();
if (i != notified) {
- printk( "kexec: waiting for cpu %d (physical"
- " %d) to enter %i state\n",
- i, paca[i].hw_cpu_id, wait_state);
+ printk(KERN_INFO "kexec: waiting for cpu %d "
+ "(physical %d) to enter %i state\n",
+ i, paca[i].hw_cpu_id, wait_state);
notified = i;
}
}
@@ -215,7 +229,10 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
- /* Before removing MMU mapings make sure all CPUs have entered real mode */
+ /*
+ * Before removing MMU mappings make sure all CPUs have entered real
+ * mode:
+ */
kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
put_cpu();
@@ -284,6 +301,8 @@ void default_machine_kexec(struct kimage *image)
if (crashing_cpu == -1)
kexec_prepare_cpus();
+ pr_debug("kexec: Starting switchover sequence.\n");
+
/* switch to a staticly allocated stack. Based on irq stack code.
* XXX: the task struct will likely be invalid once we do the copy!
*/
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Matt Evans @ 2010-07-30 4:49 UTC (permalink / raw)
To: linuxppc-dev, kexec; +Cc: Michael Neuling, Milton Miller
In-Reply-To: <4C5258C8.1030305@ozlabs.org>
When CPU hotplug is used, some CPUs may be offline at the time a kexec is
performed. The subsequent kernel may expect these CPUs to be already running,
and will declare them stuck. On pseries, there's also a soft-offline (cede)
state that CPUs may be in; this can also cause problems as the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are. The CPU will
either appear stuck, or will cause a crash as we replace its cede loop beneath
it.
This patch kicks each present offline CPU awake before the kexec, so that
none are forever lost to these assumptions in the subsequent kernel.
Now, the behaviour is that all available CPUs that were offlined are now
online & usable after the kexec. This mimics the behaviour of a full reboot
(on which all CPUs will be restarted).
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/kernel/machine_kexec_64.c | 26 +++++++++++++++++++++++++-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index aa3d5cd..37f805e 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -16,6 +16,7 @@
#include <linux/init_task.h>
#include <linux/errno.h>
#include <linux/kernel.h>
+#include <linux/cpu.h>
#include <asm/page.h>
#include <asm/current.h>
@@ -213,9 +214,32 @@ static void kexec_prepare_cpus_wait(int wait_state)
mb();
}
-static void kexec_prepare_cpus(void)
+/*
+ * We need to make sure each present CPU is online. The next kernel will scan
+ * the device tree and assume primary threads are online and query secondary
+ * threads via RTAS to online them if required. If we don't online primary
+ * threads, they will be stuck. However, we also online secondary threads as we
+ * may be using 'cede offline'. In this case RTAS doesn't see the secondary
+ * threads as offline -- and again, these CPUs will be stuck.
+ *
+ * So, we online all CPUs that should be running, including secondary threads.
+ */
+static void wake_offline_cpus(void)
{
+ int cpu = 0;
+
+ for_each_present_cpu(cpu) {
+ if (!cpu_online(cpu)) {
+ printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
+ cpu);
+ cpu_up(cpu);
+ }
+ }
+}
+static void kexec_prepare_cpus(void)
+{
+ wake_offline_cpus();
smp_call_function(kexec_smp_down, NULL, /* wait */0);
local_irq_disable();
mb(); /* make sure IRQs are disabled before we say they are */
--
1.6.3.3
^ permalink raw reply related
* Which microcode patch for MPC870?
From: Shawn Jin @ 2010-07-30 6:40 UTC (permalink / raw)
To: ppcdev
Hi,
Which microcode patch should be selected for MPC870? In the old 2.4
kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding
config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or
CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I
believe USB microcode is irrelevant here. So it comes down the other
two choices. Of course do I really need the patch? My board has I2C
and SMC1, but no SPI.
I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the
following compilation error:
CC arch/powerpc/sysdev/micropatch.o
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:629: error: expected '=', ',', ';',
'asm' or '__attribute__' before '*' token
arch/powerpc/sysdev/micropatch.c:629: error: 'spp' undeclared (first
use in this function)
arch/powerpc/sysdev/micropatch.c:629: error: (Each undeclared
identifier is reported only once
arch/powerpc/sysdev/micropatch.c:629: error: for each function it appears in.)
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c:630: warning: ISO C90 forbids mixed
declarations and code
arch/powerpc/sysdev/micropatch.c:671: error: 'spi_t' undeclared (first
use in this function)
arch/powerpc/sysdev/micropatch.c:671: error: expected expression
before ')' token
arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
Obviously there is no spi_t declaration in 2.6.33.5. So where is this
spi_t declared?
Thanks a lot,
-Shawn.
^ permalink raw reply
* Re: Which microcode patch for MPC870?
From: Anton Vorontsov @ 2010-07-30 6:45 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTimBP98EwRuvU_dj-RM2kaXZ-FSZ=GQxdod9VQeU@mail.gmail.com>
Hello,
On Thu, Jul 29, 2010 at 11:40:21PM -0700, Shawn Jin wrote:
> Hi,
>
> Which microcode patch should be selected for MPC870? In the old 2.4
> kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding
> config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or
> CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I
> believe USB microcode is irrelevant here. So it comes down the other
> two choices. Of course do I really need the patch? My board has I2C
> and SMC1, but no SPI.
>
> I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the
> following compilation error:
These errors were fixed by
http://patchwork.ozlabs.org/patch/58262/
and
http://patchwork.ozlabs.org/patch/58263/
Thanks,
> CC arch/powerpc/sysdev/micropatch.o
> arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
> arch/powerpc/sysdev/micropatch.c:629: error: expected '=', ',', ';',
> 'asm' or '__attribute__' before '*' token
> arch/powerpc/sysdev/micropatch.c:629: error: 'spp' undeclared (first
> use in this function)
> arch/powerpc/sysdev/micropatch.c:629: error: (Each undeclared
> identifier is reported only once
> arch/powerpc/sysdev/micropatch.c:629: error: for each function it appears in.)
> cc1: warnings being treated as errors
> arch/powerpc/sysdev/micropatch.c:630: warning: ISO C90 forbids mixed
> declarations and code
> arch/powerpc/sysdev/micropatch.c:671: error: 'spi_t' undeclared (first
> use in this function)
> arch/powerpc/sysdev/micropatch.c:671: error: expected expression
> before ')' token
> arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
> make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
>
> Obviously there is no spi_t declaration in 2.6.33.5. So where is this
> spi_t declared?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* ramdisk size is larger than 4MB
From: Shawn Jin @ 2010-07-30 7:00 UTC (permalink / raw)
To: ppcdev
Hi,
I have a ramdisk as RFS much larger than 4MB in a 2.4 kernel. In
recent 2.6 kernels ramdisk is no longer supported so I decided to go
with initramfs. However I found the initial RFS for initramfs is
limited to 4MB since the bootwrapper locates at 0x400000.
One way to lift this limitation is to relocate the bootwrapper to
somewhere else, say for example, 0x1000000 so that a 16MB initramfs
can be loaded. If the bootwrapper is relocated, what else would be
affected by this relocation?
Another (better?) way may be to find a right file system for RFS such
as JFFS2. My board has limited NOR flash (32MB) but larger RAM
(128MB). There is not much space left in flash for RFS.
Would you like to share some thoughts?
Thanks a lot,
-Shawn.
^ permalink raw reply
* Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
From: Benjamin Herrenschmidt @ 2010-07-30 7:04 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1278569285.28659.76.camel@pasglop>
On Thu, 2010-07-08 at 16:08 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-06-25 at 11:56 +0200, Jakub Jelinek wrote:
>
> > static inline void sync(void)
> > diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
> > index b8f152e..288d8b2 100644
> > --- a/arch/powerpc/include/asm/atomic.h
> > +++ b/arch/powerpc/include/asm/atomic.h
> > @@ -19,14 +19,14 @@ static __inline__ int atomic_read(const atomic_t *v)
> > {
> > int t;
> >
> > - __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
> > + __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m<>"(v->counter));
> >
> > return t;
> > }
> >
>
> This gives me:
>
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/time.c: In function ‘timer_interrupt’:
> /home/benh/linux-powerpc-test/arch/powerpc/include/asm/atomic.h:22: error: ‘asm’ operand has impossible constraints
> make[2]: *** [arch/powerpc/kernel/time.o] Error 1
>
> $ gcc --version
> gcc (Debian 4.4.4-1) 4.4.4
Ping :-)
Do that mean that 4.4.4 doesn't understand your new constraints or are
we doing something incorrect ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3 v2] mmc: Add ESDHC weird voltage bits workaround
From: Anton Vorontsov @ 2010-07-30 7:06 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <1280461977-2023-1-git-send-email-tie-fei.zang@freescale.com>
On Fri, Jul 30, 2010 at 11:52:57AM +0800, Roy Zang wrote:
> P4080 ESDHC controller does not support 1.8V and 3.0V voltage. but the
> host controller capabilities register wrongly set the bits.
> This patch adds the workaround to correct the weird voltage setting bits.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
[...]
> diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
> index 0c30242..1f3913d 100644
> --- a/drivers/mmc/host/sdhci-of-core.c
> +++ b/drivers/mmc/host/sdhci-of-core.c
> @@ -164,6 +164,10 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
> if (sdhci_of_wp_inverted(np))
> host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
>
> + if (of_device_is_compatible(np, "fsl,p4080-esdhc"))
> + host->quirks |= (SDHCI_QUIRK_QORIQ_NO_VDD_180
> + |SDHCI_QUIRK_QORIQ_NO_VDD_300);
> +
It should be two properties, something like sdhci,no-vdd-180
and sdhci,no-vdd-300. But it might be even better: we have
voltage-ranges for mmc-spi case, see
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt.
If voltage-ranges specified, then we use it, not capabilities
register.
For p4080 it will be 'voltage-ranges = <3200 3400>;'. So, with
voltage-ranges we can do fine grained VDD control without
introducing anything new.
As for implementation, you might just factor out voltage-ranges
parsing from drivers/mmc/host/of_mmc_spi.c, and then in sdhci
driver you could do.
if (host->ocr_avail)
mmc->ocr_avail = host->ocr_avail.
> clk = of_get_property(np, "clock-frequency", &size);
> if (clk && size == sizeof(*clk) && *clk)
> of_host->clock = *clk;
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 1424d08..a667790 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1699,6 +1699,14 @@ int sdhci_add_host(struct sdhci_host *host)
>
> caps = sdhci_readl(host, SDHCI_CAPABILITIES);
>
> + /* Workaround for P4080 host controller capabilities
> + * 1.8V and 3.0V do not supported*/
> + if (host->quirks & SDHCI_QUIRK_QORIQ_NO_VDD_180)
The point of making NO_VDD stuff is to make these quirks
"chip-agnostic". Ideally, sdhci.c should never know about
particular chips.
So, you shouldn't name quirks with QORIQ.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
From: Jakub Jelinek @ 2010-07-30 7:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1280473486.2169.2.camel@pasglop>
On Fri, Jul 30, 2010 at 05:04:46PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-08 at 16:08 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2010-06-25 at 11:56 +0200, Jakub Jelinek wrote:
> >
> > > static inline void sync(void)
> > > diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
> > > index b8f152e..288d8b2 100644
> > > --- a/arch/powerpc/include/asm/atomic.h
> > > +++ b/arch/powerpc/include/asm/atomic.h
> > > @@ -19,14 +19,14 @@ static __inline__ int atomic_read(const atomic_t *v)
> > > {
> > > int t;
> > >
> > > - __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
> > > + __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m<>"(v->counter));
> > >
> > > return t;
> > > }
> > >
> >
> > This gives me:
> >
> > /home/benh/linux-powerpc-test/arch/powerpc/kernel/time.c: In function ‘timer_interrupt’:
> > /home/benh/linux-powerpc-test/arch/powerpc/include/asm/atomic.h:22: error: ‘asm’ operand has impossible constraints
> > make[2]: *** [arch/powerpc/kernel/time.o] Error 1
> >
> > $ gcc --version
> > gcc (Debian 4.4.4-1) 4.4.4
>
> Ping :-)
>
> Do that mean that 4.4.4 doesn't understand your new constraints or are
> we doing something incorrect ?
The constraints weren't new, so in theory everything would work fine.
Except because < and > were so rarely used on many targets before,
there were backend bugs on PowerPC and SPARC at least related to that.
See
http://gcc.gnu.org/PR44707
http://gcc.gnu.org/PR44701
http://gcc.gnu.org/PR44492
So, in short, I'm afraid "m<>" needs to be used only for GCC 4.6+
(and, vendors which backported the inline-asm handling changes
to their older gcc would need to adjust for their gccs too).
When "m<>" isn't used, it just leads to potential code pessimization
in inline-asms that are prepared for handling side-effects.
Jakub
^ permalink raw reply
* Re: [PATCH 1/3] mmc: Auto CMD12 support for eSDHC driver
From: Anton Vorontsov @ 2010-07-30 7:26 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, linux-mmc-approval, Chang-Ming.Huang
In-Reply-To: <1280295753-12331-1-git-send-email-tie-fei.zang@freescale.com>
On Wed, Jul 28, 2010 at 01:42:33PM +0800, Roy Zang wrote:
[...]
> + if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> + if (mrq->stop) {
> + mrq->data->stop = NULL;
> + mrq->stop = NULL;
> + }
Please put additional curly braces for the first 'if' statement.
> host->mrq = mrq;
>
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index c846813..aa112aa 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -2,6 +2,7 @@
> * linux/drivers/mmc/host/sdhci.h - Secure Digital Host Controller Interface driver
> *
> * Copyright (C) 2005-2008 Pierre Ossman, All Rights Reserved.
> + * Copyright 2010 Freescale Semiconductor, Inc.
Wrong count of spaces after '*'.
Also, according to git shortlog it's Freescale's first
patch to sdhci core, and the patch is quite trivial.
IANAL, but please refrain from adding authorship or copyright
notices unless you have done some major contribution(s).
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> @@ -240,6 +241,8 @@ struct sdhci_host {
> #define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN (1<<25)
> /* Controller cannot support End Attribute in NOP ADMA descriptor */
> #define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
> +/* Controller uses Auto CMD12 command to stop the transfer */
> +#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/3] dts: Add sdhci-auto-cmd12 field for p4080 device tree
From: Anton Vorontsov @ 2010-07-30 7:30 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, linux-mmc-approval
In-Reply-To: <1280295887-14251-1-git-send-email-tie-fei.zang@freescale.com>
On Wed, Jul 28, 2010 at 01:44:47PM +0800, Roy Zang wrote:
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> arch/powerpc/boot/dts/p4080ds.dts | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/p4080ds.dts b/arch/powerpc/boot/dts/p4080ds.dts
> index 6b29eab..11c8884 100644
> --- a/arch/powerpc/boot/dts/p4080ds.dts
> +++ b/arch/powerpc/boot/dts/p4080ds.dts
> @@ -280,6 +280,7 @@
> reg = <0x114000 0x1000>;
> interrupts = <48 2>;
> interrupt-parent = <&mpic>;
> + fsl,sdhci-auto-cmd12;
This should be sdhci,auto-cmd12 or something like that,
not fsl-specific.
Also please document this property in
Documentation/powerpc/dts-bindings/fsl/esdhc.txt.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] mmc: Add ESDHC weird register workaround
From: Anton Vorontsov @ 2010-07-30 7:37 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: linuxppc-dev, linux-mmc
In-Reply-To: <83024545B35D6445A690EFD603E7869A0512E0@zch01exm23.fsl.freescale.net>
On Wed, Jul 28, 2010 at 05:43:00PM +0800, Zang Roy-R61911 wrote:
[...]
> > > + /* The default value of DMAS bits of Protocol Control
> > Register is not
> > > + * correct. clear these two bits to use simple DMA */
> > > +#define ESDHCI_CTRL_DMAS_MASK 0xFFFFFCFF
> > > + if (host->quirks & SDHCI_QUIRK_QORIQ_REG_WEIRD) {
> > > + ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
> > > + ctrl = ctrl & ESDHCI_CTRL_DMAS_MASK;
> > > + sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
> > > + }
> >
> > You should implement register quirks via SDHCI IO accessors.
> What does you mean "SDHCI IO accessors?
See drivers/mmc/host/sdhci-of-esdhc.c
struct sdhci_of_data sdhci_esdhc = {
...
.ops = {
...
.write_l = sdhci_be32bs_writel,
...
},
};
You can implement your own write_l and put the quirk in
there, as we do for esdhc_readw, esdhc_writew, etc.
OTOH, as you say it has wrong default value, not behaviour,
so I think you can just initialize the HOST_CONTROL register
just once somewhere in sdhci-of-esdhc, e.g. ->enable_dma
callback?
> It makes more sense to define something like:
> SDHCI_QUIRK_QORIQ_PROCTL_WEIRD.
I don't think so.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
From: Benjamin Herrenschmidt @ 2010-07-30 7:52 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20100730071922.GQ18378@tyan-ft48-01.lab.bos.redhat.com>
On Fri, 2010-07-30 at 09:19 +0200, Jakub Jelinek wrote:
> So, in short, I'm afraid "m<>" needs to be used only for GCC 4.6+
> (and, vendors which backported the inline-asm handling changes
> to their older gcc would need to adjust for their gccs too).
> When "m<>" isn't used, it just leads to potential code pessimization
> in inline-asms that are prepared for handling side-effects.
Ok, so we'll need some kind of macro to "fixup" those constraints ...
Just to make sure I understand things properly, if we don't change them,
the code will still be correct with 4.6 but sub-optimal, right ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] Use is_32bit_task() helper to test 32 bit binary
From: Denis Kirjanov @ 2010-07-30 8:04 UTC (permalink / raw)
To: benh; +Cc: shaggy, paulus, linuxppc-dev
Use is_32bit_task() helper to test 32 bit binary.
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
arch/powerpc/kernel/process.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 43855c9..e7dffbf 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -692,7 +692,7 @@ int copy_thread(unsigned long clone_flags, unsigned long usp,
p->thread.regs = childregs;
if (clone_flags & CLONE_SETTLS) {
#ifdef CONFIG_PPC64
- if (!test_thread_flag(TIF_32BIT))
+ if (!is_32bit_task())
childregs->gpr[13] = childregs->gpr[6];
else
#endif
@@ -787,7 +787,7 @@ void start_thread(struct pt_regs *regs, unsigned long start, unsigned long sp)
regs->nip = start;
regs->msr = MSR_USER;
#else
- if (!test_thread_flag(TIF_32BIT)) {
+ if (!is_32bit_task()) {
unsigned long entry, toc;
/* start is a relocated pointer to the function descriptor for
@@ -959,7 +959,7 @@ int sys_clone(unsigned long clone_flags, unsigned long usp,
if (usp == 0)
usp = regs->gpr[1]; /* stack pointer for child */
#ifdef CONFIG_PPC64
- if (test_thread_flag(TIF_32BIT)) {
+ if (is_32bit_task()) {
parent_tidp = TRUNC_PTR(parent_tidp);
child_tidp = TRUNC_PTR(child_tidp);
}
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Tejun Heo @ 2010-07-30 8:45 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mark Brown, Jani Nikula, Linus Walleij, James Smart,
Eric W. Biederman, Greg Kroah-Hartman, linux-kernel, Chris Wright,
linuxppc-dev, James E.J. Bottomley, Richard Purdie, Nick Cheng,
Dmitry Torokhov, Jean Delvare, Paul Mackerras, Benjamin Thery,
linux-scsi, Alex Iannicelli, Liam Girdwood
In-Reply-To: <1280380166-29196-1-git-send-email-guenter.roeck@ericsson.com>
On 07/29/2010 07:09 AM, Guenter Roeck wrote:
> The following comment is found in include/linux/sysfs.h:
>
> /* FIXME
> * The *owner field is no longer used.
> * x86 tree has been cleaned up. The owner
> * attribute is still left for other arches.
> */
>
> As it turns out, the *owner field is (again?) initialized in several modules,
> suggesting that such initialization may be creeping back into the code.
>
> This patch set removes the above comment, the *owner field, and each instance
> in the code where it was found to be initialized.
>
> Compiled with x86 allmodconfig as well as with all alpha, arm, mips, powerpc,
> and sparc defconfig builds.
Yeah, the change is way overdue. Maybe we should have just removed
them back then.
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 1/4] irq: Add new IRQ flag IRQF_NO_SUSPEND
From: Benjamin Herrenschmidt @ 2010-07-30 10:29 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, xen-devel, devicetree-discuss,
Dmitry Torokhov, linux-kernel, linuxppc-dev, Paul Mackerras,
linux-input, Thomas Gleixner
In-Reply-To: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com>
On Thu, 2010-07-29 at 11:16 +0100, Ian Campbell wrote:
> A small number of users of IRQF_TIMER are using it for the implied no
> suspend behaviour on interrupts which are not timer interrupts.
>
> Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
> __IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: xen-devel@lists.xensource.com
> Cc: linux-input@vger.kernel.org
> Cc: linuxppc-dev@ozlabs.org
> Cc: devicetree-discuss@lists.ozlabs.org
> ---
> include/linux/interrupt.h | 7 ++++++-
> kernel/irq/manage.c | 2 +-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index c233113..a0384a4 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -53,16 +53,21 @@
> * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
> * Used by threaded interrupts which need to keep the
> * irq line disabled until the threaded handler has been run.
> + * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
> + *
> */
> #define IRQF_DISABLED 0x00000020
> #define IRQF_SAMPLE_RANDOM 0x00000040
> #define IRQF_SHARED 0x00000080
> #define IRQF_PROBE_SHARED 0x00000100
> -#define IRQF_TIMER 0x00000200
> +#define __IRQF_TIMER 0x00000200
> #define IRQF_PERCPU 0x00000400
> #define IRQF_NOBALANCING 0x00000800
> #define IRQF_IRQPOLL 0x00001000
> #define IRQF_ONESHOT 0x00002000
> +#define IRQF_NO_SUSPEND 0x00004000
> +
> +#define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
>
> /*
> * Bits used by threaded handlers:
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index e149748..c3003e9 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -216,7 +216,7 @@ static inline int setup_affinity(unsigned int irq, struct irq_desc *desc)
> void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
> {
> if (suspend) {
> - if (!desc->action || (desc->action->flags & IRQF_TIMER))
> + if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
> return;
> desc->status |= IRQ_SUSPENDED;
> }
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Use IRQF_NO_SUSPEND not IRQF_TIMER for non-timer interrupts
From: Benjamin Herrenschmidt @ 2010-07-30 10:30 UTC (permalink / raw)
To: Ian Campbell
Cc: devicetree-discuss, linux-kernel, linuxppc-dev, Paul Mackerras,
Thomas Gleixner
In-Reply-To: <1280398595-29708-3-git-send-email-ian.campbell@citrix.com>
On Thu, 2010-07-29 at 11:16 +0100, Ian Campbell wrote:
> kw_i2c_irq and via_pmu_interrupt are not timer interrupts and
> therefore should not use IRQF_TIMER. Use the recently introduced
> IRQF_NO_SUSPEND instead since that is the actual desired behaviour.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: linuxppc-dev@ozlabs.org
> Cc: devicetree-discuss@lists.ozlabs.org
> ---
> arch/powerpc/platforms/powermac/low_i2c.c | 5 +++--
> drivers/macintosh/via-pmu.c | 9 +++++----
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
> index 06a137c..480567e 100644
> --- a/arch/powerpc/platforms/powermac/low_i2c.c
> +++ b/arch/powerpc/platforms/powermac/low_i2c.c
> @@ -542,11 +542,12 @@ static struct pmac_i2c_host_kw *__init kw_i2c_host_init(struct device_node *np)
> /* Make sure IRQ is disabled */
> kw_write_reg(reg_ier, 0);
>
> - /* Request chip interrupt. We set IRQF_TIMER because we don't
> + /* Request chip interrupt. We set IRQF_NO_SUSPEND because we don't
> * want that interrupt disabled between the 2 passes of driver
> * suspend or we'll have issues running the pfuncs
> */
> - if (request_irq(host->irq, kw_i2c_irq, IRQF_TIMER, "keywest i2c", host))
> + if (request_irq(host->irq, kw_i2c_irq, IRQF_NO_SUSPEND,
> + "keywest i2c", host))
> host->irq = NO_IRQ;
>
> printk(KERN_INFO "KeyWest i2c @0x%08x irq %d %s\n",
> diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
> index 3d4fc0f..35bc273 100644
> --- a/drivers/macintosh/via-pmu.c
> +++ b/drivers/macintosh/via-pmu.c
> @@ -400,11 +400,12 @@ static int __init via_pmu_start(void)
> printk(KERN_ERR "via-pmu: can't map interrupt\n");
> return -ENODEV;
> }
> - /* We set IRQF_TIMER because we don't want the interrupt to be disabled
> - * between the 2 passes of driver suspend, we control our own disabling
> - * for that one
> + /* We set IRQF_NO_SUSPEND because we don't want the interrupt
> + * to be disabled between the 2 passes of driver suspend, we
> + * control our own disabling for that one
> */
> - if (request_irq(irq, via_pmu_interrupt, IRQF_TIMER, "VIA-PMU", (void *)0)) {
> + if (request_irq(irq, via_pmu_interrupt, IRQF_NO_SUSPEND,
> + "VIA-PMU", (void *)0)) {
> printk(KERN_ERR "via-pmu: can't request irq %d\n", irq);
> return -ENODEV;
> }
^ permalink raw reply
* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Benjamin Herrenschmidt @ 2010-07-30 10:28 UTC (permalink / raw)
To: Tejun Heo
Cc: Mark Brown, Linus Walleij, James Smart, Eric W. Biederman,
Dmitry Torokhov, Benjamin Thery, Greg Kroah-Hartman, linux-kernel,
Chris Wright, linuxppc-dev, James E.J. Bottomley, Paul Mackerras,
Nick Cheng, Jani Nikula, Jean Delvare, Richard Purdie,
Liam Girdwood, linux-scsi, Alex Iannicelli, Guenter Roeck
In-Reply-To: <4C52913C.9020204@kernel.org>
On Fri, 2010-07-30 at 10:45 +0200, Tejun Heo wrote:
> On 07/29/2010 07:09 AM, Guenter Roeck wrote:
> > The following comment is found in include/linux/sysfs.h:
> >
> > /* FIXME
> > * The *owner field is no longer used.
> > * x86 tree has been cleaned up. The owner
> > * attribute is still left for other arches.
> > */
> >
> > As it turns out, the *owner field is (again?) initialized in several modules,
> > suggesting that such initialization may be creeping back into the code.
> >
> > This patch set removes the above comment, the *owner field, and each instance
> > in the code where it was found to be initialized.
> >
> > Compiled with x86 allmodconfig as well as with all alpha, arm, mips, powerpc,
> > and sparc defconfig builds.
>
> Yeah, the change is way overdue. Maybe we should have just removed
> them back then.
I'm happy with the powerpc related patches as long as we all agree that
needs to go. Do you need me to put some of this in powerpc.git or are
you carrying them all to Linus ?
Cheers,
Ben.
> Acked-by: Tejun Heo <tj@kernel.org>
>
> Thanks.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox