* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: Benjamin Herrenschmidt @ 2012-04-03 1:26 UTC (permalink / raw)
To: David Gibson
Cc: Frank Svendsbøe, LinuxPPC-dev, Wolfgang Denk,
robert.karl.berger
In-Reply-To: <20120403010002.GE7481@truffala.fritz.box>
On Tue, 2012-04-03 at 11:00 +1000, David Gibson wrote:
> On Tue, Apr 03, 2012 at 10:55:59AM +1000, Tony Breeds wrote:
> > Currently we build all board files regardless of the final zImage
> > target. This is sub-optimal (in terms on compilation) and leads to
> > problems in one platform needlessly causing failures for other
> > platforms.
>
> Um.. I believe the one platform breaking another is actually working
> as intended. I think Paulus did it this way to stop people breaking
> platforms other than the one they were working on without realising
> it.
But that doesn't make sense to enforce that accross CPU families since
they cannot be built together within a single kernel anyway...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: David Gibson @ 2012-04-03 1:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, LinuxPPC-dev, Josh Boyer, Wolfgang Denk,
robert.karl.berger, Frank Svendsbøe
In-Reply-To: <20120403005558.GA9194@thor.bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
On Tue, Apr 03, 2012 at 10:55:59AM +1000, Tony Breeds wrote:
> Currently we build all board files regardless of the final zImage
> target. This is sub-optimal (in terms on compilation) and leads to
> problems in one platform needlessly causing failures for other
> platforms.
Um.. I believe the one platform breaking another is actually working
as intended. I think Paulus did it this way to stop people breaking
platforms other than the one they were working on without realising
it.
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] powerpc/boot: Only build board support files when required.
From: Tony Breeds @ 2012-04-03 0:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt, LinuxPPC-dev, Josh Boyer
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger
[-- Attachment #1: Type: text/plain, Size: 3791 bytes --]
Currently we build all board files regardless of the final zImage
target. This is sub-optimal (in terms on compilation) and leads to
problems in one platform needlessly causing failures for other
platforms.
Use the Kconfig variables to selectively construct this board files to
build.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/boot/Makefile | 69 +++++++++++++++++++++++++++++++++-----------
1 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e8461cb..3d4d9ea 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -65,23 +65,58 @@ $(addprefix $(obj)/,$(libfdt) libfdt-wrapper.o simpleboot.o epapr.o): \
src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
$(libfdt) libfdt-wrapper.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
- gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
- 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
- cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
- fsl-soc.c mpc8xx.c pq2.c ugecon.c
-src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c cuboot-hotfoot.c epapr.c treeboot-ebony.c \
- prpmc2800.c \
- ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
- cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
- fixed-head.S ep88xc.c ep405.c cuboot-c2k.c \
- cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c \
- virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
- cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c \
- gamecube-head.S gamecube.c wii-head.S wii.c treeboot-iss4xx.c \
- treeboot-currituck.c
+ gunzip_util.c elf_util.c $(zlib) devtree.c stdlib.c \
+ oflib.c ofconsole.c cuboot.c mpsc.c cpm-serial.c \
+ uartlite.c mpc52xx-psc.c
+src-plat := of.c
+ifeq ($(CONFIG_40x),y)
+src-wlib += 4xx.c planetcore.c
+src-plat += fixed-head.S ep405.c cuboot-hotfoot.c treeboot-walnut.c \
+ cuboot-acadia.c cuboot-kilauea.c \
+ simpleboot.c virtex405-head.S virtex.c
+endif
+ifeq ($(CONFIG_44x),y)
+src-wlib += 4xx.c ebony.c bamboo.c
+src-plat += treeboot-ebony cuboot-ebony treeboot-bamboo cuboot-bamboo \
+ cuboot-sam440ep.c cuboot-sequoia.c cuboot-rainier.c \
+ cuboot-taishan.c cuboot-katmai.c cuboot-warp.c \
+ cuboot-yosemite.c treeboot-iss4xx.c treeboot-currituck.c \
+ simpleboot.c fixed-head.S virtex.c
+endif
+ifeq ($(CONFIG_8xx),y)
+src-wlib += mpc8xx.c planetcore.c
+src-plat += cuboot-8xx.c fixed-head.S ep88xc.c redboot-8xx.c
+endif
+ifeq ($(CONFIG_PPC_MPC52xx),y)
+src-plat += cuboot-52xx.c
+endif
+ifeq ($(CONFIG_PPC_82xx),y)
+src-wlib += pq2.c fsl-soc.c
+src-plat += cuboot-pq2.c fixed-head.S ep8248e.c cuboot-824x.c
+endif
+ifeq ($(CONFIG_PPC_83xx),y)
+src-plat += cuboot-83xx.c fixed-head.S redboot-83xx.c
+endif
+ifeq ($(CONFIG_FSL_SOC_BOOKE),y)
+src-plat += cuboot-85xx.c cuboot-85xx-cpm2.c
+endif
+ifeq ($(CONFIG_EMBEDDED6xx),y)
+src-wlib += mv64x60.c mv64x60_i2c.c ugecon.c
+src-plat += cuboot-pq2.c cuboot-mpc7448hpc2.c cuboot-c2k.c \
+ gamecube-head.S gamecube.c wii-head.S wii.c holly.c \
+ prpmc2800.c
+endif
+ifeq ($(CONFIG_AMIGAONE),y)
+src-plat += cuboot-amigaone.c
+endif
+ifeq ($(CONFIG_PPC_PS3),y)
+src-plat += ps3-head.S ps3-hvcall.S ps3.c
+endif
+ifeq ($(CONFIG_EPAPR_BOOT),y)
+src-plat += epapr.c
+endif
+src-wlib := $(sort $(src-wlib))
+src-plat := $(sort $(src-plat))
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
--
1.7.7.6
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-03 0:37 UTC (permalink / raw)
To: Andreas Schwab
Cc: devicetree-discuss, linux-kernel, Rob Herring, Milton Miller,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <m2hax2qeqs.fsf@igel.home>
On Mon, 2012-04-02 at 18:29 +0200, Andreas Schwab wrote:
> > This breaks irqs on PowerMac G5. I see lost irq errors from the sata
> > driver.
>
> When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> long-term regression in genirq irq_set_irq_type() handling") on top of
> 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
> interrupts. Also the X server is broken somehow, though I don't know
> whether that is related or a different bug.
I can't explain why but it works for me with your config on a similar
dual G5.
It would be interesting to figure out what causes the call to
set_irq_type(NONE)...
The SATA driver isn't doing anything. What should be happening
is that:
- pci_read_irq_line() in arch/powerpc/kernel/pci-common.c
This will call of_irq_map_pci() and then call irq_of_create_mapping()
with the result if it's successful (it should be).
- irq_of_create_mapping in kernel/irq/irqdomain.c
That should then call domain->ops->xlate() where domain is the domain
of the first MPIC (the one in K2), which should return your IRQ number
for the SATA controller (btw, it's 0, in case that matters, ie, HW irq 0
on MPIC 1 iirc) and the interrupt type. This is where you should
get IRQ_TYPE_LEVEL_LOW (i verified and that's what my device-tree
contains).
You can add printk's in there to see what's happening in your case ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 23:38 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree-discuss, linux-kernel, Rob Herring, Andreas Schwab,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120402225223.GN24211@n2100.arm.linux.org.uk>
On Mon, 2012-04-02 at 23:52 +0100, Russell King - ARM Linux wrote:
> If we want to fix it a better way, then sure, that'll be good. But
> what
> we shouldn't do is re-introduce one regression to fix a different
> regression.
>
> So, Thomas, what do you think about providing a way that a disabled
> interrupt could have its pending status cleared such that when it's
> enabled, any queued events are ignored? Maybe an
> enable_and_clear_irq() ?
Ok. Doesn't matter anyway, this shouldn't be the problem in this
specific case. IE. we shouldn't be setting that interrupt to NONE.
We should have parsed the device-tree and set the trigger appropriately.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Russell King - ARM Linux @ 2012-04-02 22:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, linux-kernel, Rob Herring, Andreas Schwab,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1333406005.30734.61.camel@pasglop>
On Tue, Apr 03, 2012 at 08:33:25AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-04-02 at 22:55 +0100, Russell King - ARM Linux wrote:
> > Well, presumably someone is calling irq_set_irq_type() asking explicitly
> > for IRQ_TYPE_NONE. The code will now (as it always used to before David's
> > change) do exactly what you ask this to: it will ask the type to be set
> > to none.
> >
> > If you don't want to set the type to none, don't call the interface asking
> > for that to happen.
>
> I think part of the idea with NONE is to use it as "reset that interrupt
> to the "default" setting, whatever that means ...
No, it never was (anyone who thought that is plain wrong because that
wasn't my original design.)
NONE really did mean "I don't want any trigger level" for set_irq_type()
as it was originally designed on ARM, and there's a number of PCMCIA
socket drivers which rely on that behaviour: the reason is that with
edge triggered interrupts, Linux normally remembers edges which happen
with the interrupt disabled, and delivers those events when the interrupt
is re-enabled. There are situations (such as edge triggered status GPIOs)
where we _really_ do want to ignore transitions on an edge triggered
input. And PCMCIA soc_common uses set_irq_type() with NONE to do this.
The reason you can't request an interrupt with a NONE type is because
I saw that to be pointless - and in any case, the type is a bitmask and
NONE ended up being zero. Zero is also what you get with request_irq()
used with drivers which don't pass any IRQ trigger flags, so request_irq()
has to ignore this case.
Now, arguably, we could say that there should be an interface for clearing
pending edges in our interrupt model, but traditionally there hasn't been,
even when my ARM IRQ stuff was moved forward into genirq. However,
subsequently changing genirq in a way which breaks previously working
stuff is a regression, and that's what my revert addresses.
If we want to fix it a better way, then sure, that'll be good. But what
we shouldn't do is re-introduce one regression to fix a different
regression.
So, Thomas, what do you think about providing a way that a disabled
interrupt could have its pending status cleared such that when it's
enabled, any queued events are ignored? Maybe an enable_and_clear_irq() ?
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 22:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree-discuss, linux-kernel, Rob Herring, Andreas Schwab,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120402215524.GM24211@n2100.arm.linux.org.uk>
On Mon, 2012-04-02 at 22:55 +0100, Russell King - ARM Linux wrote:
> Well, presumably someone is calling irq_set_irq_type() asking explicitly
> for IRQ_TYPE_NONE. The code will now (as it always used to before David's
> change) do exactly what you ask this to: it will ask the type to be set
> to none.
>
> If you don't want to set the type to none, don't call the interface asking
> for that to happen.
I think part of the idea with NONE is to use it as "reset that interrupt
to the "default" setting, whatever that means ...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 22:32 UTC (permalink / raw)
To: Thomas Gleixner
Cc: devicetree-discuss, LKML, Milton Miller, Andreas Schwab,
Rob Herring, Russell King, linuxppc-dev, LAK
In-Reply-To: <alpine.LFD.2.02.1204022324140.2542@ionos>
On Mon, 2012-04-02 at 23:27 +0200, Thomas Gleixner wrote:
> So it's covered by this section:
>
> mpic_set_irq_type()
>
> if (flow_type == IRQ_TYPE_NONE)
> if (mpic->senses && src < mpic->senses_count)
> flow_type = mpic->senses[src];
> if (flow_type == IRQ_TYPE_NONE)
> flow_type = IRQ_TYPE_LEVEL_LOW;
>
> And with IRQ_TYPE_NONE this is always going to end up with
> IRQ_TYPE_LEVEL_LOW simply because the only function which might set
> mpic->senses is mpic_set_default_senses(). And this function does not
> have a single caller .....
>
> /me scratches head
Something must have broken ... when converting from the device-tree we
should be calling xlate which should extract the polarity/sense from the
device-tree.
Now, afaik, IRQ_LEVEL_LOW is correct for PCI unless the interrupt is
inverted inside Apple ASIC which is possible... (it's not an external
PCI, it's a cell inside K2).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Russell King - ARM Linux @ 2012-04-02 21:55 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Andreas Schwab,
Rob Herring, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120402202848.1EB833E02A7@localhost>
On Mon, Apr 02, 2012 at 02:28:48PM -0600, Grant Likely wrote:
> On Mon, 02 Apr 2012 18:29:15 +0200, Andreas Schwab <schwab@linux-m68k.org> wrote:
> > Andreas Schwab <schwab@linux-m68k.org> writes:
> >
> > > Grant Likely <grant.likely@secretlab.ca> writes:
> > >
> > >> This patch drops the powerpc-specific irq_map table and replaces it with
> > >> directly using the irq_alloc_desc()/irq_free_desc() interfaces for allocating
> > >> and freeing irq_desc structures.
> > >
> > > This breaks irqs on PowerMac G5. I see lost irq errors from the sata
> > > driver.
> >
> > When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> > long-term regression in genirq irq_set_irq_type() handling") on top of
> > 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
> > interrupts. Also the X server is broken somehow, though I don't know
> > whether that is related or a different bug.
>
> That change is:
>
> @@ -61,8 +61,7 @@ int irq_set_irq_type(unsigned int irq, unsigned int type)
> return -EINVAL;
>
> type &= IRQ_TYPE_SENSE_MASK;
> - if (type != IRQ_TYPE_NONE)
> - ret = __irq_set_trigger(desc, irq, type);
> + ret = __irq_set_trigger(desc, irq, type);
> irq_put_desc_busunlock(desc, flags);
> return ret;
>
> So presumably irq_set_irq_type() is getting called with type ==
> IRQ_TYPE_NONE. From Russell's description, presumably that would mean
> the G5 sata driver isn't setting the correct type for the interrupt,
> but I have *no* idea how that intersects with the change removing the
> powerpc irq map.
Well, presumably someone is calling irq_set_irq_type() asking explicitly
for IRQ_TYPE_NONE. The code will now (as it always used to before David's
change) do exactly what you ask this to: it will ask the type to be set
to none.
If you don't want to set the type to none, don't call the interface asking
for that to happen.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Thomas Gleixner @ 2012-04-02 21:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, LKML, Milton Miller, Andreas Schwab,
Rob Herring, Russell King, linuxppc-dev, LAK
In-Reply-To: <1333401600.30734.56.camel@pasglop>
On Tue, 3 Apr 2012, Benjamin Herrenschmidt wrote:
> On Mon, 2012-04-02 at 22:52 +0200, Thomas Gleixner wrote:
> > > When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> > > long-term regression in genirq irq_set_irq_type() handling") on top
> > of
> > > 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
> >
> > Hmm. Which irq chip is handling the interrupt for that sata irq ?
>
> MPIC. The irq is a PCI IRQ, and so should be level-low, it should have
> been mapped by the PCI code using the of_* calls.
So it's covered by this section:
mpic_set_irq_type()
if (flow_type == IRQ_TYPE_NONE)
if (mpic->senses && src < mpic->senses_count)
flow_type = mpic->senses[src];
if (flow_type == IRQ_TYPE_NONE)
flow_type = IRQ_TYPE_LEVEL_LOW;
And with IRQ_TYPE_NONE this is always going to end up with
IRQ_TYPE_LEVEL_LOW simply because the only function which might set
mpic->senses is mpic_set_default_senses(). And this function does not
have a single caller .....
/me scratches head
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Josh Boyer @ 2012-04-02 21:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
linuxppc-dev
In-Reply-To: <1333400910.30734.54.camel@pasglop>
On Mon, Apr 2, 2012 at 5:08 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2012-04-02 at 08:10 -0400, Josh Boyer wrote:
>> On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsb=F8e wrote:
>> >
>> >> Hi Josh Boyer,
>> >>
>> >> just wanted to add that I'm experiencing the same problem that Robert
>> >> reported, but on 8xx instead of 4xx. The mpc8xx does not support the
>> >> mfdcrx instruction, so maybe it's more to it than just a binutils bug=
?
>> >
>> > The kernel shouldn't have tried to build that instruction on 8xx, thou=
gh
>> > I suppose if it's in arch/powerpc/boot, we are a bit too eager at
>> > building everything including what's not relevant, we might to be a bi=
t
>> > more careful at excluding 4xx stuff on a 8xx kernel.
>>
>> It's still a binutils issue. =A0Sounds like the toolchain being used to
>> build the 8xx kernel is specifically built for 8xx. =A0A generally built
>> binutils should have worked fine (assuming it was new enough), since
>> we pass -mcpu=3D405.
>
> Still, it makes sense to limit the building of the wrappers to the CPU
> family of the kernel...
Oh, I'm not really disagreeing with that. I think I said as much about
4 years ago, but at the time the prevailing opinion was what we
currently have. I never really understood why.
Out with the old, in with the sane.
josh
^ permalink raw reply
* Re: [PATCH 08/18] PCI, powerpc: Register busn_res for root buses
From: Benjamin Herrenschmidt @ 2012-04-02 21:22 UTC (permalink / raw)
To: Milton Miller
Cc: Tony Luck, Linus Torvalds, linuxppc-dev, lkml, Dominik Brodowski,
Jesse Barnes, Greg Kroah-Hartmann, Bjorn Helgaas, Andrew Morton,
Yinghai Lu
In-Reply-To: <powerpc-pci-domains-by-busnumber-resend@mdm.bga.com>
On Mon, 2012-04-02 at 05:19 -0500, Milton Miller wrote:
>
> In the POWER3 era we had several boxes that split the pci bus number
> space across domains and RTAS used the bus number to find the correct
> PHB. This contineed to the first RS64 boxes. By S80 and RS64-III
> it was obvious that we didn't have enough numbers to continue this
> ilusion and we added the presently used RTAS calls that take the pci
> domain as well as bus, device, and function numbers.
>
> The bus numbers split across pci domains started with the F50
> F50 chrp 32 bit platforms.
Ok, so old CHRPs would have a split as well...
I think the best is to honor the bus-range property of the PHB as min &
max values, and if we feel a need to allow the kernel to assign busses
beyond that, we can always quirk the appropriate platform code.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Andreas Schwab @ 2012-04-02 21:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: devicetree-discuss, LKML, Milton Miller, Rob Herring,
Russell King, linuxppc-dev, LAK
In-Reply-To: <alpine.LFD.2.02.1204022251420.2542@ionos>
Thomas Gleixner <tglx@linutronix.de> writes:
> Hmm. Which irq chip is handling the interrupt for that sata irq ?
It's MPIC 1.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 21:20 UTC (permalink / raw)
To: Thomas Gleixner
Cc: devicetree-discuss, LKML, Milton Miller, Andreas Schwab,
Rob Herring, Russell King, linuxppc-dev, LAK
In-Reply-To: <alpine.LFD.2.02.1204022251420.2542@ionos>
On Mon, 2012-04-02 at 22:52 +0200, Thomas Gleixner wrote:
> > When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> > long-term regression in genirq irq_set_irq_type() handling") on top
> of
> > 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
>
> Hmm. Which irq chip is handling the interrupt for that sata irq ?
MPIC. The irq is a PCI IRQ, and so should be level-low, it should have
been mapped by the PCI code using the of_* calls.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 21:11 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2r4w6jugo.fsf@linux-m68k.org>
On Mon, 2012-04-02 at 12:31 +0200, Andreas Schwab wrote:
> > - PowerMac7,3 aka Dual G5 AGP. This ones has U3 + K2 and
> > uses cascaded MPICs
>
> That's the same as mine, config is attached. I'm currently trying to
> bisect the commit that actually broke the series.
Hrm, odd.. I'll dbl check today that I didn't b0rk something in my test
(like loading the wrong kernel :-) I'll also try with your config.
Cheers,
Ben.
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Benjamin Herrenschmidt @ 2012-04-02 21:08 UTC (permalink / raw)
To: Josh Boyer
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
linuxppc-dev
In-Reply-To: <CA+5PVA6jQgme0sS=i8yYX6b_R5179+BtWPh7QXCGNfoLTCt46A@mail.gmail.com>
On Mon, 2012-04-02 at 08:10 -0400, Josh Boyer wrote:
> On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
> >
> >> Hi Josh Boyer,
> >>
> >> just wanted to add that I'm experiencing the same problem that Robert
> >> reported, but on 8xx instead of 4xx. The mpc8xx does not support the
> >> mfdcrx instruction, so maybe it's more to it than just a binutils bug?
> >
> > The kernel shouldn't have tried to build that instruction on 8xx, though
> > I suppose if it's in arch/powerpc/boot, we are a bit too eager at
> > building everything including what's not relevant, we might to be a bit
> > more careful at excluding 4xx stuff on a 8xx kernel.
>
> It's still a binutils issue. Sounds like the toolchain being used to
> build the 8xx kernel is specifically built for 8xx. A generally built
> binutils should have worked fine (assuming it was new enough), since
> we pass -mcpu=405.
Still, it makes sense to limit the building of the wrappers to the CPU
family of the kernel...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Thomas Gleixner @ 2012-04-02 20:52 UTC (permalink / raw)
To: Andreas Schwab
Cc: devicetree-discuss, LKML, Milton Miller, Rob Herring,
Russell King, linuxppc-dev, LAK
In-Reply-To: <m2hax2qeqs.fsf@igel.home>
On Mon, 2 Apr 2012, Andreas Schwab wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
> > Grant Likely <grant.likely@secretlab.ca> writes:
> >
> >> This patch drops the powerpc-specific irq_map table and replaces it with
> >> directly using the irq_alloc_desc()/irq_free_desc() interfaces for allocating
> >> and freeing irq_desc structures.
> >
> > This breaks irqs on PowerMac G5. I see lost irq errors from the sata
> > driver.
>
> When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> long-term regression in genirq irq_set_irq_type() handling") on top of
> 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
Hmm. Which irq chip is handling the interrupt for that sata irq ?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Grant Likely @ 2012-04-02 20:28 UTC (permalink / raw)
To: Andreas Schwab
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <m2hax2qeqs.fsf@igel.home>
On Mon, 02 Apr 2012 18:29:15 +0200, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
> > Grant Likely <grant.likely@secretlab.ca> writes:
> >
> >> This patch drops the powerpc-specific irq_map table and replaces it with
> >> directly using the irq_alloc_desc()/irq_free_desc() interfaces for allocating
> >> and freeing irq_desc structures.
> >
> > This breaks irqs on PowerMac G5. I see lost irq errors from the sata
> > driver.
>
> When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> long-term regression in genirq irq_set_irq_type() handling") on top of
> 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
> interrupts. Also the X server is broken somehow, though I don't know
> whether that is related or a different bug.
That change is:
@@ -61,8 +61,7 @@ int irq_set_irq_type(unsigned int irq, unsigned int type)
return -EINVAL;
type &= IRQ_TYPE_SENSE_MASK;
- if (type != IRQ_TYPE_NONE)
- ret = __irq_set_trigger(desc, irq, type);
+ ret = __irq_set_trigger(desc, irq, type);
irq_put_desc_busunlock(desc, flags);
return ret;
So presumably irq_set_irq_type() is getting called with type ==
IRQ_TYPE_NONE. From Russell's description, presumably that would mean
the G5 sata driver isn't setting the correct type for the interrupt,
but I have *no* idea how that intersects with the change removing the
powerpc irq map.
Can you dump out /debug/powerpc/virq_mapping from both before and
after the irq_map patch is applied?
g.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Andreas Schwab @ 2012-04-02 16:29 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <m2iphj3zxr.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Grant Likely <grant.likely@secretlab.ca> writes:
>
>> This patch drops the powerpc-specific irq_map table and replaces it with
>> directly using the irq_alloc_desc()/irq_free_desc() interfaces for allocating
>> and freeing irq_desc structures.
>
> This breaks irqs on PowerMac G5. I see lost irq errors from the sata
> driver.
When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
long-term regression in genirq irq_set_irq_type() handling") on top of
3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
interrupts. Also the X server is broken somehow, though I don't know
whether that is related or a different bug.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Tabi Timur-B04825 @ 2012-04-02 15:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <CAOZdJXWyfdMX4mxFqeh=gpyorS9E0aFEhXuxzzvZ_uMV5zhc3g@mail.gmail.com>
Ping!
Kumar, you forgot to deal with this patch for 3.3. The window for 3.4
is closing rapidly. There are no objections to my patch. Could you
please apply it and get it merged into 3.4? I'm tired of waiting.
On Thu, Mar 29, 2012 at 4:47 PM, Tabi Timur-B04825 <b04825@freescale.com> w=
rote:
> On Thu, Mar 29, 2012 at 3:44 PM, Kumar Gala <galak@kernel.crashing.org> w=
rote:
>>
>> A few minor bug fixes and missing dts updates for 3.4. =A0There got lost=
in
>> the mix. =A0Sorry for the delay
>
> What about my "don't call of_platform_bus_probe() twice" patch?
> That's still an important fix for the P1022DS.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [REGRESSION][PATCH V4 1/3] bpf jit: Make the filter.c::__load_pointer helper non-static for the jits
From: Jan Seiffert @ 2012-04-02 13:02 UTC (permalink / raw)
To: David Laight
Cc: Matt Evans, Eric Dumazet, netdev, linux-kernel, linuxppc-dev,
David S. Miller
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6ECE@saturn3.aculab.com>
David Laight schrieb:
>
>> The function is renamed to make it a little more clear what it does.
>> It is not added to any .h because it is not for general
>> consumption, only for bpf internal use (and so by the jits).
>
> I'd have thought it better to put in into a bfp_internal.h
> (or similar) with a big warning there about the asm users.
>
Hmmm, OK, where would i put the .h? Right there under ./include/linux/?
> Possibly even worth adding some other defs that the asm
> files will need (if there are any).
>
There is at least one other define, the lowest negative address range,
but it would be a copy of the same define in filter.h, or i would have
to massage filter.h to make it fit for inclusion by assembly.
So I'm unsure how to proceed.
> David
>
Greetings
Jan
--
An IPv4 address space walks into a bar: "A strong CIDR please. I'm
exhausted."
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Josh Boyer @ 2012-04-02 12:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
linuxppc-dev
In-Reply-To: <1333152184.30734.3.camel@pasglop>
On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsb=F8e wrote:
>
>> Hi Josh Boyer,
>>
>> just wanted to add that I'm experiencing the same problem that Robert
>> reported, but on 8xx instead of 4xx. The mpc8xx does not support the
>> mfdcrx instruction, so maybe it's more to it than just a binutils bug?
>
> The kernel shouldn't have tried to build that instruction on 8xx, though
> I suppose if it's in arch/powerpc/boot, we are a bit too eager at
> building everything including what's not relevant, we might to be a bit
> more careful at excluding 4xx stuff on a 8xx kernel.
It's still a binutils issue. Sounds like the toolchain being used to
build the 8xx kernel is specifically built for 8xx. A generally built
binutils should have worked fine (assuming it was new enough), since
we pass -mcpu=3D405.
josh
^ permalink raw reply
* [PATCH 37/69] TTY: HVC, add tty_port
From: Jiri Slaby @ 2012-04-02 11:54 UTC (permalink / raw)
To: gregkh; +Cc: jirislaby, linuxppc-dev, linux-kernel, alan
In-Reply-To: <1333367693-3244-1-git-send-email-jslaby@suse.cz>
And use kref from that. This means we need tty_port->ops->destruct to
properly free the structure. This is what destroy_hvc_struct used to
do so we leverage that.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/hvc/hvc_console.c | 23 ++++++++++++++---------
drivers/tty/hvc/hvc_console.h | 2 +-
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 8880adf..12a4273 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -107,7 +107,7 @@ static struct hvc_struct *hvc_get_by_index(int index)
list_for_each_entry(hp, &hvc_structs, next) {
spin_lock_irqsave(&hp->lock, flags);
if (hp->index == index) {
- kref_get(&hp->kref);
+ tty_port_get(&hp->port);
spin_unlock_irqrestore(&hp->lock, flags);
spin_unlock(&hvc_structs_lock);
return hp;
@@ -229,9 +229,9 @@ static int __init hvc_console_init(void)
console_initcall(hvc_console_init);
/* callback when the kboject ref count reaches zero. */
-static void destroy_hvc_struct(struct kref *kref)
+static void hvc_port_destruct(struct tty_port *port)
{
- struct hvc_struct *hp = container_of(kref, struct hvc_struct, kref);
+ struct hvc_struct *hp = container_of(port, struct hvc_struct, port);
unsigned long flags;
spin_lock(&hvc_structs_lock);
@@ -264,7 +264,7 @@ int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops)
/* make sure no no tty has been registered in this index */
hp = hvc_get_by_index(index);
if (hp) {
- kref_put(&hp->kref, destroy_hvc_struct);
+ tty_port_put(&hp->port);
return -1;
}
@@ -343,7 +343,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->lock, flags);
tty_kref_put(tty);
tty->driver_data = NULL;
- kref_put(&hp->kref, destroy_hvc_struct);
+ tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
}
/* Force wakeup of the polling thread */
@@ -397,7 +397,7 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
}
tty_kref_put(tty);
- kref_put(&hp->kref, destroy_hvc_struct);
+ tty_port_put(&hp->port);
}
static void hvc_hangup(struct tty_struct *tty)
@@ -437,7 +437,7 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
tty_kref_put(tty);
- kref_put(&hp->kref, destroy_hvc_struct);
+ tty_port_put(&hp->port);
}
}
@@ -817,6 +817,10 @@ static const struct tty_operations hvc_ops = {
#endif
};
+static const struct tty_port_operations hvc_port_ops = {
+ .destruct = hvc_port_destruct,
+};
+
struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
const struct hv_ops *ops,
int outbuf_size)
@@ -842,7 +846,8 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
hp->outbuf_size = outbuf_size;
hp->outbuf = &((char *)hp)[ALIGN(sizeof(*hp), sizeof(long))];
- kref_init(&hp->kref);
+ tty_port_init(&hp->port);
+ hp->port.ops = &hvc_port_ops;
INIT_WORK(&hp->tty_resize, hvc_set_winsz);
spin_lock_init(&hp->lock);
@@ -891,7 +896,7 @@ int hvc_remove(struct hvc_struct *hp)
* kref cause it to be removed, which will probably be the tty_vhangup
* below.
*/
- kref_put(&hp->kref, destroy_hvc_struct);
+ tty_port_put(&hp->port);
/*
* This function call will auto chain call hvc_hangup.
diff --git a/drivers/tty/hvc/hvc_console.h b/drivers/tty/hvc/hvc_console.h
index c335a14..926d9e4 100644
--- a/drivers/tty/hvc/hvc_console.h
+++ b/drivers/tty/hvc/hvc_console.h
@@ -46,6 +46,7 @@
#define HVC_ALLOC_TTY_ADAPTERS 8
struct hvc_struct {
+ struct tty_port port;
spinlock_t lock;
int index;
struct tty_struct *tty;
@@ -61,7 +62,6 @@ struct hvc_struct {
struct winsize ws;
struct work_struct tty_resize;
struct list_head next;
- struct kref kref; /* ref count & hvc_struct lifetime */
};
/* implemented by a low level driver */
--
1.7.9.2
^ permalink raw reply related
* [PATCH 44/69] TTY: hvsi, add tty_port
From: Jiri Slaby @ 2012-04-02 11:54 UTC (permalink / raw)
To: gregkh; +Cc: jirislaby, linuxppc-dev, linux-kernel, alan
In-Reply-To: <1333367693-3244-1-git-send-email-jslaby@suse.cz>
And use count from there.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/hvc/hvsi.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 4006aed..113a09a 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -69,6 +69,7 @@
#define __ALIGNED__ __attribute__((__aligned__(sizeof(long))))
struct hvsi_struct {
+ struct tty_port port;
struct delayed_work writer;
struct work_struct handshaker;
wait_queue_head_t emptyq; /* woken when outbuf is emptied */
@@ -76,7 +77,6 @@ struct hvsi_struct {
spinlock_t lock;
int index;
struct tty_struct *tty;
- int count;
uint8_t throttle_buf[128];
uint8_t outbuf[N_OUTBUF]; /* to implement write_room and chars_in_buffer */
/* inbuf is for packet reassembly. leave a little room for leftovers. */
@@ -751,7 +751,7 @@ static int hvsi_open(struct tty_struct *tty, struct file *filp)
spin_lock_irqsave(&hp->lock, flags);
hp->tty = tty;
- hp->count++;
+ hp->port.count++;
atomic_set(&hp->seqno, 0);
h_vio_signal(hp->vtermno, VIO_IRQ_ENABLE);
spin_unlock_irqrestore(&hp->lock, flags);
@@ -808,7 +808,7 @@ static void hvsi_close(struct tty_struct *tty, struct file *filp)
spin_lock_irqsave(&hp->lock, flags);
- if (--hp->count == 0) {
+ if (--hp->port.count == 0) {
hp->tty = NULL;
hp->inbuf_end = hp->inbuf; /* discard remaining partial packets */
@@ -841,9 +841,9 @@ static void hvsi_close(struct tty_struct *tty, struct file *filp)
spin_lock_irqsave(&hp->lock, flags);
}
- } else if (hp->count < 0)
+ } else if (hp->port.count < 0)
printk(KERN_ERR "hvsi_close %lu: oops, count is %d\n",
- hp - hvsi_ports, hp->count);
+ hp - hvsi_ports, hp->port.count);
spin_unlock_irqrestore(&hp->lock, flags);
}
@@ -857,7 +857,7 @@ static void hvsi_hangup(struct tty_struct *tty)
spin_lock_irqsave(&hp->lock, flags);
- hp->count = 0;
+ hp->port.count = 0;
hp->n_outbuf = 0;
hp->tty = NULL;
@@ -1228,6 +1228,7 @@ static int __init hvsi_console_init(void)
init_waitqueue_head(&hp->emptyq);
init_waitqueue_head(&hp->stateq);
spin_lock_init(&hp->lock);
+ tty_port_init(&hp->port);
hp->index = hvsi_count;
hp->inbuf_end = hp->inbuf;
hp->state = HVSI_CLOSED;
--
1.7.9.2
^ permalink raw reply related
* [PATCH 45/69] TTY: hvsi, sanitize uses of tty
From: Jiri Slaby @ 2012-04-02 11:54 UTC (permalink / raw)
To: gregkh; +Cc: jirislaby, linuxppc-dev, linux-kernel, alan
In-Reply-To: <1333367693-3244-1-git-send-email-jslaby@suse.cz>
- use tty, not hp->tty wherever possible
- pass tty down to some functions and go to step one
- do not defer tty_hangup calls -- it is as simple as schedule_work,
so might be called with hp->lock held
- do not defer tty buffer flips -- since the driver does not use
low_latency (it cannot actually), the flip is a simple tail move
plus schedule_work. It will make our life easier in the next patch.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/hvc/hvsi.c | 88 +++++++++++++++++-------------------------------
1 file changed, 30 insertions(+), 58 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 113a09a..68b729b 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -237,7 +237,7 @@ static int hvsi_read(struct hvsi_struct *hp, char *buf, int count)
}
static void hvsi_recv_control(struct hvsi_struct *hp, uint8_t *packet,
- struct tty_struct **to_hangup, struct hvsi_struct **to_handshake)
+ struct tty_struct *tty, struct hvsi_struct **to_handshake)
{
struct hvsi_control *header = (struct hvsi_control *)packet;
@@ -247,9 +247,8 @@ static void hvsi_recv_control(struct hvsi_struct *hp, uint8_t *packet,
/* CD went away; no more connection */
pr_debug("hvsi%i: CD dropped\n", hp->index);
hp->mctrl &= TIOCM_CD;
- /* If userland hasn't done an open(2) yet, hp->tty is NULL. */
- if (hp->tty && !C_CLOCAL(hp->tty))
- *to_hangup = hp->tty;
+ if (tty && !C_CLOCAL(tty))
+ tty_hangup(tty);
}
break;
case VSV_CLOSE_PROTOCOL:
@@ -331,7 +330,8 @@ static void hvsi_recv_query(struct hvsi_struct *hp, uint8_t *packet)
}
}
-static void hvsi_insert_chars(struct hvsi_struct *hp, const char *buf, int len)
+static void hvsi_insert_chars(struct hvsi_struct *hp, struct tty_struct *tty,
+ const char *buf, int len)
{
int i;
@@ -347,7 +347,7 @@ static void hvsi_insert_chars(struct hvsi_struct *hp, const char *buf, int len)
continue;
}
#endif /* CONFIG_MAGIC_SYSRQ */
- tty_insert_flip_char(hp->tty, c, 0);
+ tty_insert_flip_char(tty, c, 0);
}
}
@@ -360,7 +360,7 @@ static void hvsi_insert_chars(struct hvsi_struct *hp, const char *buf, int len)
* revisited.
*/
#define TTY_THRESHOLD_THROTTLE 128
-static struct tty_struct *hvsi_recv_data(struct hvsi_struct *hp,
+static bool hvsi_recv_data(struct hvsi_struct *hp, struct tty_struct *tty,
const uint8_t *packet)
{
const struct hvsi_header *header = (const struct hvsi_header *)packet;
@@ -371,14 +371,14 @@ static struct tty_struct *hvsi_recv_data(struct hvsi_struct *hp,
pr_debug("queueing %i chars '%.*s'\n", datalen, datalen, data);
if (datalen == 0)
- return NULL;
+ return false;
if (overflow > 0) {
pr_debug("%s: got >TTY_THRESHOLD_THROTTLE bytes\n", __func__);
datalen = TTY_THRESHOLD_THROTTLE;
}
- hvsi_insert_chars(hp, data, datalen);
+ hvsi_insert_chars(hp, tty, data, datalen);
if (overflow > 0) {
/*
@@ -390,7 +390,7 @@ static struct tty_struct *hvsi_recv_data(struct hvsi_struct *hp,
hp->n_throttle = overflow;
}
- return hp->tty;
+ return true;
}
/*
@@ -399,14 +399,13 @@ static struct tty_struct *hvsi_recv_data(struct hvsi_struct *hp,
* machine during console handshaking (in which case tty = NULL and we ignore
* incoming data).
*/
-static int hvsi_load_chunk(struct hvsi_struct *hp, struct tty_struct **flip,
- struct tty_struct **hangup, struct hvsi_struct **handshake)
+static int hvsi_load_chunk(struct hvsi_struct *hp, struct tty_struct *tty,
+ struct hvsi_struct **handshake)
{
uint8_t *packet = hp->inbuf;
int chunklen;
+ bool flip = false;
- *flip = NULL;
- *hangup = NULL;
*handshake = NULL;
chunklen = hvsi_read(hp, hp->inbuf_end, HVSI_MAX_READ);
@@ -440,12 +439,12 @@ static int hvsi_load_chunk(struct hvsi_struct *hp, struct tty_struct **flip,
case VS_DATA_PACKET_HEADER:
if (!is_open(hp))
break;
- if (hp->tty == NULL)
+ if (tty == NULL)
break; /* no tty buffer to put data in */
- *flip = hvsi_recv_data(hp, packet);
+ flip = hvsi_recv_data(hp, tty, packet);
break;
case VS_CONTROL_PACKET_HEADER:
- hvsi_recv_control(hp, packet, hangup, handshake);
+ hvsi_recv_control(hp, packet, tty, handshake);
break;
case VS_QUERY_RESPONSE_PACKET_HEADER:
hvsi_recv_response(hp, packet);
@@ -462,28 +461,26 @@ static int hvsi_load_chunk(struct hvsi_struct *hp, struct tty_struct **flip,
packet += len_packet(packet);
- if (*hangup || *handshake) {
- pr_debug("%s: hangup or handshake\n", __func__);
- /*
- * we need to send the hangup now before receiving any more data.
- * If we get "data, hangup, data", we can't deliver the second
- * data before the hangup.
- */
+ if (*handshake) {
+ pr_debug("%s: handshake\n", __func__);
break;
}
}
compact_inbuf(hp, packet);
+ if (flip)
+ tty_flip_buffer_push(tty);
+
return 1;
}
-static void hvsi_send_overflow(struct hvsi_struct *hp)
+static void hvsi_send_overflow(struct hvsi_struct *hp, struct tty_struct *tty)
{
pr_debug("%s: delivering %i bytes overflow\n", __func__,
hp->n_throttle);
- hvsi_insert_chars(hp, hp->throttle_buf, hp->n_throttle);
+ hvsi_insert_chars(hp, tty, hp->throttle_buf, hp->n_throttle);
hp->n_throttle = 0;
}
@@ -494,8 +491,6 @@ static void hvsi_send_overflow(struct hvsi_struct *hp)
static irqreturn_t hvsi_interrupt(int irq, void *arg)
{
struct hvsi_struct *hp = (struct hvsi_struct *)arg;
- struct tty_struct *flip;
- struct tty_struct *hangup;
struct hvsi_struct *handshake;
unsigned long flags;
int again = 1;
@@ -504,25 +499,9 @@ static irqreturn_t hvsi_interrupt(int irq, void *arg)
while (again) {
spin_lock_irqsave(&hp->lock, flags);
- again = hvsi_load_chunk(hp, &flip, &hangup, &handshake);
+ again = hvsi_load_chunk(hp, hp->tty, &handshake);
spin_unlock_irqrestore(&hp->lock, flags);
- /*
- * we have to call tty_flip_buffer_push() and tty_hangup() outside our
- * spinlock. But we also have to keep going until we've read all the
- * available data.
- */
-
- if (flip) {
- /* there was data put in the tty flip buffer */
- tty_flip_buffer_push(flip);
- flip = NULL;
- }
-
- if (hangup) {
- tty_hangup(hangup);
- }
-
if (handshake) {
pr_debug("hvsi%i: attempting re-handshake\n", handshake->index);
schedule_work(&handshake->handshaker);
@@ -534,15 +513,11 @@ static irqreturn_t hvsi_interrupt(int irq, void *arg)
&& (!test_bit(TTY_THROTTLED, &hp->tty->flags))) {
/* we weren't hung up and we weren't throttled, so we can deliver the
* rest now */
- flip = hp->tty;
- hvsi_send_overflow(hp);
+ hvsi_send_overflow(hp, hp->tty);
+ tty_flip_buffer_push(hp->tty);
}
spin_unlock_irqrestore(&hp->lock, flags);
- if (flip) {
- tty_flip_buffer_push(flip);
- }
-
return IRQ_HANDLED;
}
@@ -966,8 +941,8 @@ static int hvsi_write(struct tty_struct *tty,
* and hvsi_write_worker will be scheduled. subsequent hvsi_write() calls
* will see there is no room in outbuf and return.
*/
- while ((count > 0) && (hvsi_write_room(hp->tty) > 0)) {
- int chunksize = min(count, hvsi_write_room(hp->tty));
+ while ((count > 0) && (hvsi_write_room(tty) > 0)) {
+ int chunksize = min(count, hvsi_write_room(tty));
BUG_ON(hp->n_outbuf < 0);
memcpy(hp->outbuf + hp->n_outbuf, source, chunksize);
@@ -1014,19 +989,16 @@ static void hvsi_unthrottle(struct tty_struct *tty)
{
struct hvsi_struct *hp = tty->driver_data;
unsigned long flags;
- int shouldflip = 0;
pr_debug("%s\n", __func__);
spin_lock_irqsave(&hp->lock, flags);
if (hp->n_throttle) {
- hvsi_send_overflow(hp);
- shouldflip = 1;
+ hvsi_send_overflow(hp, tty);
+ tty_flip_buffer_push(tty);
}
spin_unlock_irqrestore(&hp->lock, flags);
- if (shouldflip)
- tty_flip_buffer_push(hp->tty);
h_vio_signal(hp->vtermno, VIO_IRQ_ENABLE);
}
--
1.7.9.2
^ permalink raw reply related
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