* help on dts compiler please.
From: Bizhan Gholikhamseh (bgholikh) @ 2007-07-03 0:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
Hi
I have downloaded the latest Linux code from the following git tree:
git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
I have also installed dtc compiler version.
I am trying to create dtb file from mpc8541cds.dts.
I ran the following command and get error:
$ dtc -f -I dts -O dtb mpc8541cds.dts
DTC: dts->dtb on file "mpc8541cds.dts"
syntax error at line 15
FATAL ERROR: Couldn't read input tree
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1867 bytes --]
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Paul Mackerras @ 2007-07-02 23:21 UTC (permalink / raw)
To: Jason Wessel
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
Andrew Morton
In-Reply-To: <46890F8D.3080807@windriver.com>
Jason Wessel writes:
> I suppose the argument could be made to remove the check in the compiled
> file, but it does serve as a way to protect kgdb for now if someone
> tries to hard compile in xmon and kgdb. Completely unpredictable
> results will occur with the debugger unless some pieces are fixed. I
> would rather make sure until that happens there is no way head down the
> rat hole.
It should all work provided kgdb plays nicely. We used to be able to
compile in both xmon and kdb and select at runtime which one gets
used.
> That issue aside would it be useful to have xmon+kgdb? After having
> looked at the hook points for xmon, if a command was added to xmon to
> provide an "detach" it would be easy enough to have kgdb and xmon in the
> same kernel. Obviously only one or the other can be used at any given time.
Well, xmon_init(0) will do a detach. However, I don't see that it is
needed; there is plenty of flexibility to choose to have xmon or not
using the CONFIG_XMON_DEFAULT config option and the xmon= boot command
line option.
Paul.
^ permalink raw reply
* Re: [PATCH v2.1 ] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Tony Breeds @ 2007-07-02 23:20 UTC (permalink / raw)
To: Will Schmidt; +Cc: LinuxPPC-dev
In-Reply-To: <1183150190.22547.62.camel@farscape.rchland.ibm.com>
On Fri, Jun 29, 2007 at 03:49:50PM -0500, Will Schmidt wrote:
>
> The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527 for
> fixing problems with NULL gettimeofday input mistakenly checks for a
> null tz field twice, when it should be checking for null tz once, and
> null tv once; by way of a r10/r11 typo.
>
> Any application calling gettimeofday(&tv,NULL) will "fail".
>
> This corrects that typo, and makes my G5 happy.
Ooops thanks Will!
The /really/ sad thing is I got it right in the first version of the
patch :(
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 23:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <20070702224643.GA21539@ld0162-tx32.am.freescale.net>
>> AFAIK, i2c is not specified by OF standard. So, we are free to chose
>> any
>> "compatible" fields for our dts. Which we then would need to match
>> against
>> drivers. So, why not make this a 1-to-1 match? I.e.,
>> [OF] [I2C]
>> compatible <-> driver_name
>> model <-> type
>
> If we do this, then the compatible field should probably be preceded
> with
> "linux,", which would get stripped by of_register_i2c_devices(). This
> would only be an interim measure until we can figure out some sort of
> name registry via power.org. Once that happens, non-"linux,"
> compatible
> fields could be looked up in an OF-to-linux table, or there could be a
> way for i2c devices to specify OF matches in addition to driver name.
Why even think of doing this? Just put the bloody name of
the device in the "compatible" property and match on that.
What is so hard about this?
If the answer is "the Linux I2C stuff is badly structured",
well, you know what to do :-)
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 23:06 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707022114020.3339@poirot.grange>
>> of_for_each_child_node() or whatever it is called?
>
> Sure, would be nice, only I cannot find anything like that. I seem to
> remember seeing a patch like that, but maybe I'me mistaken... Do you
> remember details / can you find it?
Not right now, sorry. Use grep? :-)
>>> + name = of_get_property(node, "compatible", NULL);
>>> + if (!name)
>>> + name = node->name;
>>> + if (!name)
>>> + continue;
>>
>> Look at "name" first, then look at "compatible", not
>> the other way around.
>
> ok
Which btw is what the "is_compatible()" stuff does
(or, ought to do).
>>> + /* FIXME: the i2c code should allow drivers to specify
>>> + * multiple match names; board code shouldn't need to
>>> + * know what driver will handle a given type.
>>> + */
>>
>> This should be handled by the OF matching stuff, there
>> is no direct connection between device tree naming and
>> Linux driver naming. I don't want to see this patch
>> going in without this problem being fixed first.
>
> Right, this one is interesting. But this time I cannot even vaguely
> remember seeing any "OF matching" code. I can only remember each driver
> (or OF glue to a generic driver) parsing compatible of entries, like
> legacy_serial.c. Or you mean we need to write such a matching layer?
The OF glue parsing stuff and setting up the data structures
the generic drivers want to see. I say make it work for your
board first, then when later more boards need it we have a
better idea about what is needed from a more generic I2C glue
layer.
> AFAIK, i2c is not specified by OF standard.
Yes.
> So, we are free to chose any "compatible" fields for our dts.
Within bounds. What goes into "compatible" properties is
well-defined for _any_ device.
> Which we then would need to match against
> drivers. So, why not make this a 1-to-1 match?
Because the device tree describes the hardware, not what
Linux (or anything else) is going to do with it. Let me
give you an example of why this is a good thing for _you_:
say a future version of Linux drops the I2C driver for a
device you have, since some other driver should be used
preferably instead (maybe it is just a better driver for
the same device, maybe it supports more devices, whatever).
Suddenly boards with your old device tree cannot run that
new Linux version anymore. Ouch.
Just use "compatible" exactly the way it is meant to be
used and your life will be so much simpler. And don't
even think about using a very generic property like "model"
for a purpose totally different from its intended purpose.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Scott Wood @ 2007-07-02 22:46 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707022114020.3339@poirot.grange>
On Mon, Jul 02, 2007 at 10:11:04PM +0200, Guennadi Liakhovetski wrote:
> AFAIK, i2c is not specified by OF standard. So, we are free to chose any
> "compatible" fields for our dts. Which we then would need to match against
> drivers. So, why not make this a 1-to-1 match? I.e.,
> [OF] [I2C]
> compatible <-> driver_name
> model <-> type
If we do this, then the compatible field should probably be preceded with
"linux,", which would get stripped by of_register_i2c_devices(). This
would only be an interim measure until we can figure out some sort of
name registry via power.org. Once that happens, non-"linux," compatible
fields could be looked up in an OF-to-linux table, or there could be a
way for i2c devices to specify OF matches in addition to driver name.
-Scott
^ permalink raw reply
* Re: idr_get_new_above() limitation?
From: Andrew Morton @ 2007-07-02 22:56 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: linux-kernel, openib-general, Stefan Roscher, linuxppc-dev,
raisch, jim.houston
In-Reply-To: <200707021919.27251.hnguyen@linux.vnet.ibm.com>
On Mon, 2 Jul 2007 19:19:26 +0200
Hoang-Nam Nguyen <hnguyen@linux.vnet.ibm.com> wrote:
> For ehca device driver we're intending to utilize
> idr_get_new_above() and have written a test case, which I'm attaching
> at the end. Basically it tries to get an idr token above a lower boundary
> by calling idr_get_new_above() and then uses idr_find() to check if
> the returned token can be found.
> Here is our observation with 2.6.22-rc7 on ppc64:
>
> Use lower boundary 0x3ffffffc
> [root@xyz idr_bug]# insmod idr_test_mod.ko start=1073741820
> insmod: error inserting 'idr_test_mod.ko': -1 Unknown symbol in module
> [root@xyz idr_bug]# dmesg -c
> i=3ffffffc token=3ffffffc t=000000003ffffffc
> i=3ffffffd token=3ffffffd t=000000003ffffffd
> i=3ffffffe token=3ffffffe t=000000003ffffffe
> i=3fffffff token=3fffffff t=000000003fffffff
> i=40000000 token=40000000 t=0000000000000000
> Invalid object 0000000000000000. Expected 40000000
>
> That means token 0x40000000 seems to be the "upper boundary" of idr_find().
> However the behaviour is not consistent in that it was returned by
> idr_get_new_above().
>
> Looking at void *idr_find(struct idr *idp, int id)
> {
> int n;
> struct idr_layer *p;
>
> n = idp->layers * IDR_BITS;
> p = idp->top;
>
> /* Mask off upper bits we don't use for the search. */
> id &= MAX_ID_MASK;
>
> if (id >= (1 << n))
> return NULL;
>
> while (n > 0 && p) {
> n -= IDR_BITS;
> p = p->ary[(id >> n) & IDR_MASK];
> }
> return((void *)p);
> }
> we found that the if-condition has failed:
> layers = 5
> IDR_BITS = 6
> n = 30
> (id >= (1 << n)) = (0x40000000 >= 0x40000000) = 1
>
> Since MAX_ID_MASK=0x7fffffff, I'm wondering if 0x40000000 is the actual
> upper boundary. Any hints or suggestions are appreciated.
Looks like a bug to me. Really an IDR tree on 32-bit should go all
the way up to 0xffffffff. Certainly up to 0x7fffffff. And the fact
that idr_find() disagrees with idr_get_new_above() is a big hint
that the code is getting it wrong.
^ permalink raw reply
* Re: Porting Linux to Xilinx ML410
From: Grant Likely @ 2007-07-02 22:51 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <11401755.post@talk.nabble.com>
On 7/2/07, khollan <khollan@daktronics.com> wrote:
>
> Im trying to mount the root file system off of compact flash and now I get
> this happening during boot
>
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
>
> any ideas what this is and how to fix it? I tried applying a patch that
> talked about this but my version of xsysace.c already had those changes.
It means the driver is not getting interrupts from the systemace
device, so it's reverting to (extremely slow) polling.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Porting Linux to Xilinx ML410
From: khollan @ 2007-07-02 20:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11328063.post@talk.nabble.com>
Im trying to mount the root file system off of compact flash and now I get
this happening during boot
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
any ideas what this is and how to fix it? I tried applying a patch that
talked about this but my version of xsysace.c already had those changes.
Thanks
Kevin
--
View this message in context: http://www.nabble.com/Porting-Linux-to-Xilinx-ML410-tf3989483.html#a11401755
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-07-02 20:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <00a85f152aa3547f0f0b4acd7954468a@kernel.crashing.org>
Hi Segher,
On Mon, 2 Jul 2007, Segher Boessenkool wrote:
> > + while ((node = of_get_next_child(adap_node, node))) {
>
> of_for_each_child_node() or whatever it is called?
Sure, would be nice, only I cannot find anything like that. I seem to
remember seeing a patch like that, but maybe I'me mistaken... Do you
remember details / can you find it?
> > + addr = of_get_property(node, "reg", &len);
> > + if (!addr || len < sizeof(int) || *addr > 0xffff)
> > + continue;
>
> Addresses aren't 16 bit AFAIK?
Maximum 10 bits. So, yes, it can become 0x3ff.
> > + name = of_get_property(node, "compatible", NULL);
> > + if (!name)
> > + name = node->name;
> > + if (!name)
> > + continue;
>
> Look at "name" first, then look at "compatible", not
> the other way around.
ok
> > + model = of_get_property(node, "model", NULL);
> > + if (!model)
> > + model = name;
>
> No way. "model" and "name" have nothing in common
> semantically.
ok
> > + /* FIXME: the i2c code should allow drivers to specify
> > + * multiple match names; board code shouldn't need to
> > + * know what driver will handle a given type.
> > + */
>
> This should be handled by the OF matching stuff, there
> is no direct connection between device tree naming and
> Linux driver naming. I don't want to see this patch
> going in without this problem being fixed first.
Right, this one is interesting. But this time I cannot even vaguely
remember seeing any "OF matching" code. I can only remember each driver
(or OF glue to a generic driver) parsing compatible of entries, like
legacy_serial.c. Or you mean we need to write such a matching layer?
AFAIK, i2c is not specified by OF standard. So, we are free to chose any
"compatible" fields for our dts. Which we then would need to match against
drivers. So, why not make this a 1-to-1 match? I.e.,
[OF] [I2C]
compatible <-> driver_name
model <-> type
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: current-speed property in serial devices causes kernel panic
From: Timur Tabi @ 2007-07-02 20:01 UTC (permalink / raw)
To: linuxppc-dev list
In-Reply-To: <4685DB63.7040705@freescale.com>
Timur Tabi wrote:
> The kernel panic occurs only if I call of_platform_bus_probe().
FYI, thanks to Kumar, I found the problem: I had CONFIG_SERIAL_OF_PLATFORM enabled. This
causes of_serial.c to be compiled and loaded. On my platform, that wasn't doing anything
because initially I wasn't calling of_platform_bus_probe(). When I added that call to my
platform code, of_serial.c sprang to life and tried to probe the serial nodes in my device
tree. Apparently, of_serial.c is not compatible with fsl_soc.c.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* RE: mpc8270 & Intel 82551ER on 2.6.17.14
From: Nicholas Hickman @ 2007-07-02 18:41 UTC (permalink / raw)
To: Pradyumna Sampath; +Cc: linuxppc-embedded
In-Reply-To: <f87351060706290112o407f75e5h9dffd9939ab80ef9@mail.gmail.com>
Pradyumna,
With the help of some others I have finally figured it out. I took a
step back and read the manual over and over along with debugging my
U-boot until it worked. My issue there was with the SIUMCR. Since I now
had that working in U-boot I moved on to the kernel where I found that I
was redefining the SIUMCR here:
arch/ppc/syslib/m82xx_pci.c=20
approx line 248
#elif defined CONFIG_PQ2FADS || MYBOARD
/*
* Setting required to enable IRQ1-IRQ7 (SIUMCR [DPPC]),
* and local bus for PCI (SIUMCR [LBPC]).
*/
immap->im_siu_conf.siu_82xx.sc_siumcr =3D
I was entering this routine since I was basing my config off of the
PQ2FADS board. I removed my board definition from the elif and
everything seems to be working fine.
Good luck!
-Nick
-----Original Message-----
From: Pradyumna Sampath [mailto:pradyumna.sampath@gmail.com]=20
Sent: Friday, June 29, 2007 4:12 AM
To: Nicholas Hickman
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: mpc8270 & Intel 82551ER on 2.6.17.14
Hi Nicholas,
On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
>
>
> I am having trouble getting two 82551ER Ethernet controllers running=20
> in Linux. I am able to scan the PCI bus and see the devices and I was
> even able to program the EEPROM from U-boot.
>
> In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. I've=20
> been using the e100 drive that comes with the 2.6.17.14 kernel and=20
> have also tried the driver directly from Intel. Both give the same=20
> results. The PCI scan shows the correct output for how the device
should be configured.
<snip..>
I have the same, exact same problem. But there are some of the
differences with the setup though. I have an MPC5200B and the other
difference is that I have a 2.6.21-rt3. However its the same ethernet
controller.
I am trying out a few things here, some of them being complete guesses.
But if I hit something, I will let this list know. Anyone else had
similar issues ? Request you to please holler.
regards
prady
--
htp://prady.livejournal.com
^ permalink raw reply
* [PATCH]: PCI Error Recovery: Symbios SCSI device driver
From: Linas Vepstas @ 2007-07-02 18:39 UTC (permalink / raw)
To: James.Bottomley, matthew, willy
Cc: Andrew Morton, linux-scsi, linux-kernel, linuxppc-dev,
Paul Mackerras, linux-pci
Various PCI bus errors can be signaled by newer PCI controllers.
This patch adds the PCI error recovery callbacks to the Symbios
SCSI device driver. The patch has been tested, and appears to
work well.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
Hi,
This patch has been bouncing around for a long time, and has made
appearences in various -mm trees since 2.6.something-teen. However,
it has never made it into mainline, and I'm starting to get concerned
that it will miss 2.6.23 as well.
There was some discussion, and I think I addressed all of the various
issues that came up. I'd really like to get this patch in, but am unclear
on exactly who to pester at this point. Matt Wilcox seems to be looking
for a job (???) and I am unable to git-clone James Bottmley's
git://kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
git tree; there's some error on the server side.
Linas.
drivers/scsi/sym53c8xx_2/sym_glue.c | 136 ++++++++++++++++++++++++++++++++++++
drivers/scsi/sym53c8xx_2/sym_glue.h | 4 +
drivers/scsi/sym53c8xx_2/sym_hipd.c | 6 +
3 files changed, 146 insertions(+)
Index: linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.c
===================================================================
--- linux-2.6.22-rc1.orig/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-04-25 22:08:32.000000000 -0500
+++ linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-05-14 17:31:44.000000000 -0500
@@ -657,6 +657,10 @@ static irqreturn_t sym53c8xx_intr(int ir
unsigned long flags;
struct sym_hcb *np = (struct sym_hcb *)dev_id;
+ /* Avoid spinloop trying to handle interrupts on frozen device */
+ if (pci_channel_offline(np->s.device))
+ return IRQ_HANDLED;
+
if (DEBUG_FLAGS & DEBUG_TINY) printf_debug ("[");
spin_lock_irqsave(np->s.host->host_lock, flags);
@@ -726,6 +730,20 @@ static int sym_eh_handler(int op, char *
dev_warn(&cmd->device->sdev_gendev, "%s operation started.\n", opname);
+ /* We may be in an error condition because the PCI bus
+ * went down. In this case, we need to wait until the
+ * PCI bus is reset, the card is reset, and only then
+ * proceed with the scsi error recovery. There's no
+ * point in hurrying; take a leisurely wait.
+ */
+#define WAIT_FOR_PCI_RECOVERY 35
+ if (pci_channel_offline(np->s.device)) {
+ int finished_reset = wait_for_completion_timeout(
+ &np->s.io_reset_wait, WAIT_FOR_PCI_RECOVERY*HZ);
+ if (!finished_reset)
+ return SCSI_FAILED;
+ }
+
spin_lock_irq(host->host_lock);
/* This one is queued in some place -> to wait for completion */
FOR_EACH_QUEUED_ELEMENT(&np->busy_ccbq, qp) {
@@ -1510,6 +1528,7 @@ static struct Scsi_Host * __devinit sym_
np->maxoffs = dev->chip.offset_max;
np->maxburst = dev->chip.burst_max;
np->myaddr = dev->host_id;
+ init_completion(&np->s.io_reset_wait);
/*
* Edit its name.
@@ -1948,6 +1967,116 @@ static void __devexit sym2_remove(struct
attach_count--;
}
+/**
+ * sym2_io_error_detected() -- called when PCI error is detected
+ * @pdev: pointer to PCI device
+ * @state: current state of the PCI slot
+ */
+static pci_ers_result_t sym2_io_error_detected(struct pci_dev *pdev,
+ enum pci_channel_state state)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ /* If slot is permanently frozen, turn everything off */
+ if (state == pci_channel_io_perm_failure) {
+ sym2_remove(pdev);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ init_completion(&np->s.io_reset_wait);
+ disable_irq(pdev->irq);
+ pci_disable_device(pdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * sym2_reset_workarounds -- hardware-specific work-arounds
+ *
+ * This routine is similar to sym_set_workarounds(), except
+ * that, at this point, we already know that the device was
+ * succesfully intialized at least once before, and so most
+ * of the steps taken there are un-needed here.
+ */
+static void sym2_reset_workarounds(struct pci_dev *pdev)
+{
+ u_char revision;
+ u_short status_reg;
+ struct sym_chip *chip;
+
+ pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision);
+ chip = sym_lookup_chip_table(pdev->device, revision);
+
+ /* Work around for errant bit in 895A, in a fashion
+ * similar to what is done in sym_set_workarounds().
+ */
+ pci_read_config_word(pdev, PCI_STATUS, &status_reg);
+ if (!(chip->features & FE_66MHZ) && (status_reg & PCI_STATUS_66MHZ)) {
+ status_reg = PCI_STATUS_66MHZ;
+ pci_write_config_word(pdev, PCI_STATUS, status_reg);
+ pci_read_config_word(pdev, PCI_STATUS, &status_reg);
+ }
+}
+
+/**
+ * sym2_io_slot_reset() -- called when the pci bus has been reset.
+ * @pdev: pointer to PCI device
+ *
+ * Restart the card from scratch.
+ */
+static pci_ers_result_t sym2_io_slot_reset(struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ printk(KERN_INFO "%s: recovering from a PCI slot reset\n",
+ sym_name(np));
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR "%s: Unable to enable afer PCI reset\n",
+ sym_name(np));
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_set_master(pdev);
+ enable_irq(pdev->irq);
+
+ /* If the chip can do Memory Write Invalidate, enable it */
+ if (np->features & FE_WRIE) {
+ if (pci_set_mwi(pdev))
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ /* Perform work-arounds, analogous to sym_set_workarounds() */
+ sym2_reset_workarounds(pdev);
+
+ /* Perform host reset only on one instance of the card */
+ if (PCI_FUNC (pdev->devfn) == 0) {
+ if (sym_reset_scsi_bus(np, 0)) {
+ printk(KERN_ERR "%s: Unable to reset scsi host\n",
+ sym_name(np));
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ sym_start_up(np, 1);
+ }
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * sym2_io_resume() -- resume normal ops after PCI reset
+ * @pdev: pointer to PCI device
+ *
+ * Called when the error recovery driver tells us that its
+ * OK to resume normal operation. Use completion to allow
+ * halted scsi ops to resume.
+ */
+static void sym2_io_resume(struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+ complete_all(&np->s.io_reset_wait);
+}
+
static void sym2_get_signalling(struct Scsi_Host *shost)
{
struct sym_hcb *np = sym_get_hcb(shost);
@@ -2110,11 +2239,18 @@ static struct pci_device_id sym2_id_tabl
MODULE_DEVICE_TABLE(pci, sym2_id_table);
+static struct pci_error_handlers sym2_err_handler = {
+ .error_detected = sym2_io_error_detected,
+ .slot_reset = sym2_io_slot_reset,
+ .resume = sym2_io_resume,
+};
+
static struct pci_driver sym2_driver = {
.name = NAME53C8XX,
.id_table = sym2_id_table,
.probe = sym2_probe,
.remove = __devexit_p(sym2_remove),
+ .err_handler = &sym2_err_handler,
};
static int __init sym2_init(void)
Index: linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.h
===================================================================
--- linux-2.6.22-rc1.orig/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-04-25 22:08:32.000000000 -0500
+++ linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-05-14 17:31:44.000000000 -0500
@@ -40,6 +40,7 @@
#ifndef SYM_GLUE_H
#define SYM_GLUE_H
+#include <linux/completion.h>
#include <linux/delay.h>
#include <linux/ioport.h>
#include <linux/pci.h>
@@ -179,6 +180,9 @@ struct sym_shcb {
char chip_name[8];
struct pci_dev *device;
+ /* Waiter for clearing of frozen PCI bus */
+ struct completion io_reset_wait;
+
struct Scsi_Host *host;
void __iomem * ioaddr; /* MMIO kernel io address */
Index: linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_hipd.c
===================================================================
--- linux-2.6.22-rc1.orig/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-04-25 22:08:32.000000000 -0500
+++ linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-05-14 17:31:44.000000000 -0500
@@ -2809,6 +2809,12 @@ void sym_interrupt (struct sym_hcb *np)
dstat |= INB(np, nc_dstat);
istatc = INB(np, nc_istat);
istat |= istatc;
+
+ /* Prevent deadlock waiting on a condition that may never clear. */
+ if (unlikely(sist == 0xffff && dstat == 0xff)) {
+ if (pci_channel_offline(np->s.device))
+ return;
+ }
} while (istatc & (SIP|DIP));
if (DEBUG_FLAGS & DEBUG_TINY)
^ permalink raw reply
* idr_get_new_above() limitation?
From: Hoang-Nam Nguyen @ 2007-07-02 17:19 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, openib-general, jim.houston
Cc: raisch, Stefan Roscher
Hello,
For ehca device driver we're intending to utilize
idr_get_new_above() and have written a test case, which I'm attaching
at the end. Basically it tries to get an idr token above a lower boundary
by calling idr_get_new_above() and then uses idr_find() to check if
the returned token can be found.
Here is our observation with 2.6.22-rc7 on ppc64:
Use lower boundary 0x3ffffffc
[root@xyz idr_bug]# insmod idr_test_mod.ko start=1073741820
insmod: error inserting 'idr_test_mod.ko': -1 Unknown symbol in module
[root@xyz idr_bug]# dmesg -c
i=3ffffffc token=3ffffffc t=000000003ffffffc
i=3ffffffd token=3ffffffd t=000000003ffffffd
i=3ffffffe token=3ffffffe t=000000003ffffffe
i=3fffffff token=3fffffff t=000000003fffffff
i=40000000 token=40000000 t=0000000000000000
Invalid object 0000000000000000. Expected 40000000
That means token 0x40000000 seems to be the "upper boundary" of idr_find().
However the behaviour is not consistent in that it was returned by
idr_get_new_above().
Looking at void *idr_find(struct idr *idp, int id)
{
int n;
struct idr_layer *p;
n = idp->layers * IDR_BITS;
p = idp->top;
/* Mask off upper bits we don't use for the search. */
id &= MAX_ID_MASK;
if (id >= (1 << n))
return NULL;
while (n > 0 && p) {
n -= IDR_BITS;
p = p->ary[(id >> n) & IDR_MASK];
}
return((void *)p);
}
we found that the if-condition has failed:
layers = 5
IDR_BITS = 6
n = 30
(id >= (1 << n)) = (0x40000000 >= 0x40000000) = 1
Since MAX_ID_MASK=0x7fffffff, I'm wondering if 0x40000000 is the actual
upper boundary. Any hints or suggestions are appreciated.
Thanks!
Nam
#include <linux/module.h>
#include <linux/idr.h>
MODULE_LICENSE("GPL");
int start_opt = 0x7e000000;
module_param_named(start, start_opt, int, 0);
MODULE_PARM_DESC(start,
"Start token for idr_get_new_above(). Default 0x7e000000");
static int __init idr_test_init(void)
{
DEFINE_IDR(idr);
int token, ret;
unsigned long i;
for (i = start_opt; i <= MAX_ID_MASK; i++) {
void * t;
if (!idr_pre_get(&idr, GFP_KERNEL)) {
printk(KERN_ERR "ERROR: Out of mem\n");
return -ENOENT;
}
ret = idr_get_new_above(&idr, (void*)i, start_opt, &token);
switch (ret) {
case 0:
t = idr_find(&idr, token);
printk(KERN_ERR "i=%lx token=%x t=%p\n", i, token, t);
if (t != (void*)i) {
printk(KERN_ERR "Invalid object %p. Expected %lx\n",
t, i);
return -ENOENT;
}
break;
case -EAGAIN:
i--;
printk("idr_get_new_above() ret=-EAGAIN\n");
break;
default:
printk(KERN_ERR "ERROR: Out of mem\n");
break;
}
}
/*
* return an error in any case since we don't need the module
* loaded anyway.
*/
return -ENOENT;
}
static void __exit idr_test_exit(void)
{
printk(KERN_ERR "module exit\n");
}
module_init(idr_test_init);
module_exit(idr_test_exit);
^ permalink raw reply
* Re: current-speed property in serial devices causes kernel panic
From: Kumar Gala @ 2007-07-02 16:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev list, Arnd Bergmann
In-Reply-To: <4685DB63.7040705@freescale.com>
On Jun 29, 2007, at 11:26 PM, Timur Tabi wrote:
> I see this code in function of_platform_serial_setup():
>
> static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> int type, struct uart_port
> *port)
> {
> struct resource resource;
> struct device_node *np = ofdev->node;
> const unsigned int *clk, *spd;
> int ret;
>
> memset(port, 0, sizeof *port);
> spd = of_get_property(np, "current-speed", NULL);
> ...
> port->custom_divisor = *clk / (16 * (*spd));
>
> return 0;
> }
>
> There is no check in this code to make sure spd is not null. And
> sure enough, in most DTS files, current-speed does not exist. So
> whenever this function is called on a node like this, the kernel
> panics.
I'm wondering why we set port->custom_divisor instead of setting port-
>speed. (plus the null check).
- k
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Jason Wessel @ 2007-07-02 13:49 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
paulus, Andrew Morton
In-Reply-To: <4685010C.4000108@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
Sergei Shtylyov wrote:
> Hello.
>
> Mariusz Kozlowski wrote:
>
>
>> allmodconfig on powerpc (iMac g3) fails due to
>> git-kgdb.patch. allmodconfig defaults should be changed?
>>
>
>
>> CC arch/powerpc/kernel/kgdb.o
>> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
>> in .config. Unselect one of them.
>> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
>> make: *** [arch/powerpc/kernel] Blad 2
>>
>
> I'm not sure if this will work out but maybe it's worth to disable XMON if
> KGDB is selected, like this?
>
> config XMON
> bool "Include xmon kernel debugger"
> depends on DEBUGGER && !KGDB
>
>
It did not seem that you can make a radio button / multi-select kernel
config option unless the options are in the same Kconfig file. Given
that xmon and kgdb are mutually exclusive at the moment.
What Sergei mentioned is the fix that needs to be used for the time being.
Attached is the patch I put in the for_mm branch in the linux-2.6-kgdb
git tree.
Jason.
[-- Attachment #2: xmon_or_kgdb.patch --]
[-- Type: text/plain, Size: 1532 bytes --]
xmon_or_kgdb.patch
From: Jason Wessel <jason.wessel@windriver.com>
Subject: [PATCH] Turn off xmon if kgdb is active on ppc and powerpc
Xmon and kgdb are mutuall exclusive at the moment so xmon should be
turned off in the kernel config options if kgdb selected. The case with "make allmodconfig" was failing and this patch addresses the problem.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
arch/powerpc/Kconfig.debug | 2 +-
arch/ppc/Kconfig.debug | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-kgdb/arch/powerpc/Kconfig.debug
===================================================================
--- linux-2.6-kgdb.orig/arch/powerpc/Kconfig.debug
+++ linux-2.6-kgdb/arch/powerpc/Kconfig.debug
@@ -43,7 +43,7 @@ config HCALL_STATS
config XMON
bool "Include xmon kernel debugger"
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL && !KGDB
help
Include in-kernel hooks for the xmon kernel monitor/debugger.
Unless you are intending to debug the kernel, say N here.
Index: linux-2.6-kgdb/arch/ppc/Kconfig.debug
===================================================================
--- linux-2.6-kgdb.orig/arch/ppc/Kconfig.debug
+++ linux-2.6-kgdb/arch/ppc/Kconfig.debug
@@ -4,7 +4,7 @@ source "lib/Kconfig.debug"
config XMON
bool "Include xmon kernel debugger"
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL && !KGDB
help
Include in-kernel hooks for the xmon kernel monitor/debugger.
Unless you are intending to debug the kernel, say N here.
^ permalink raw reply
* [PATCH] Consolidate PowerPC 750 cputable features
From: Josh Boyer @ 2007-07-02 16:06 UTC (permalink / raw)
To: linuxppc-dev
The 750 CPU_FTR macros have quite a bit of duplication in them. Consolidate
them to use CPU_FTRS_750 and only list the unique features for derivatives.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
include/asm-powerpc/cputable.h | 26 ++++++--------------------
1 file changed, 6 insertions(+), 20 deletions(-)
--- linux-2.6.orig/include/asm-powerpc/cputable.h
+++ linux-2.6/include/asm-powerpc/cputable.h
@@ -225,26 +225,12 @@ extern void do_feature_fixups(unsigned l
CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_PPC_LE)
-#define CPU_FTRS_750CL (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_HAS_HIGH_BATS | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750FX1 (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_NO_DPM | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750FX2 (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_NO_DPM | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750FX (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750GX (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS | CPU_FTR_PPC_LE)
+#define CPU_FTRS_750CL (CPU_FTRS_750 | CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_750FX1 (CPU_FTRS_750 | CPU_FTR_DUAL_PLL_750FX | CPU_FTR_NO_DPM)
+#define CPU_FTRS_750FX2 (CPU_FTRS_750 | CPU_FTR_NO_DPM)
+#define CPU_FTRS_750FX (CPU_FTRS_750 | CPU_FTR_DUAL_PLL_750FX | \
+ CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_750GX (CPU_FTRS_750FX)
#define CPU_FTRS_7400_NOTAU (CPU_FTR_COMMON | \
CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_HPTE_TABLE | \
^ permalink raw reply
* RE: Anyone using QE UART mode?
From: Ying Lin @ 2007-07-02 16:01 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded
In-Reply-To: <46891C6B.3090507@freescale.com>
OK, the missing piece (UART driver) I am looking for is not available
yet. I will seek alternative solutions (create a simple UART driver, or
just wait).
Thanks for the information.=20
Ying=20
-----Original Message-----
From: Timur Tabi [mailto:timur@freescale.com]=20
Sent: Monday, July 02, 2007 11:40 AM
To: Ying Lin
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Anyone using QE UART mode?
Ying Lin wrote:
> How to enable TTY devices using QUICC Engine UCC UART Mode?
>=20
> Are Linux kernel patches enough to enable them? Or, additional=20
> programming required?
I'm working on a device driver for QE UART mode, but it's not working
yet. The QE UART is=20
like the CPM UART, but I'm having troubel getting it to work.
It is *not* trivial, or even easy, to enabled. It's a full-blown UART
driver that also=20
deals with the complexity of the QE.
--=20
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Anyone using QE UART mode?
From: Timur Tabi @ 2007-07-02 15:40 UTC (permalink / raw)
To: Ying Lin; +Cc: linuxppc-embedded
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A905@airmail.wirelessworld.airvananet.com>
Ying Lin wrote:
> How to enable TTY devices using QUICC Engine UCC UART Mode?
>
> Are Linux kernel patches enough to enable them? Or, additional
> programming required?
I'm working on a device driver for QE UART mode, but it's not working yet. The QE UART is
like the CPM UART, but I'm having troubel getting it to work.
It is *not* trivial, or even easy, to enabled. It's a full-blown UART driver that also
deals with the complexity of the QE.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Jason Wessel @ 2007-07-02 14:45 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
paulus, Andrew Morton
In-Reply-To: <46890A52.6020201@ru.mvista.com>
Sergei Shtylyov wrote:
> Hello.
>
> Jason Wessel wrote:
>
>>>> allmodconfig on powerpc (iMac g3) fails due to
>>>> git-kgdb.patch. allmodconfig defaults should be changed?
>
>>>> CC arch/powerpc/kernel/kgdb.o
>>>> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB
>>>> selected in .config. Unselect one of them.
>>>> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
>>>> make: *** [arch/powerpc/kernel] Blad 2
>
> This patch does not seem complete as the #error that was tiggering
> has not been deleleted from arch/powerpc/kernel/kgdb.c (and not it's
> useless)
>
I suppose the argument could be made to remove the check in the compiled
file, but it does serve as a way to protect kgdb for now if someone
tries to hard compile in xmon and kgdb. Completely unpredictable
results will occur with the debugger unless some pieces are fixed. I
would rather make sure until that happens there is no way head down the
rat hole.
That issue aside would it be useful to have xmon+kgdb? After having
looked at the hook points for xmon, if a command was added to xmon to
provide an "detach" it would be easy enough to have kgdb and xmon in the
same kernel. Obviously only one or the other can be used at any given time.
Jason.
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Jon Loeliger @ 2007-07-02 14:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, david
In-Reply-To: <1183384015.16523.0.camel@weaponx.rchland.ibm.com>
So, like, the other day Josh Boyer mumbled:
> > Applied with the following changes --amend'ed in as well:
>
> Great. Thanks Jon, saves me from having to send out yet another patch.
No problem. --amend is spiffy. And besides, we
really should avoid those "doulbe slash" [sic] issues!
jdl
PS -- Thankfully, we avoided any Angryflower Incidents! :-)
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Sergei Shtylyov @ 2007-07-02 14:23 UTC (permalink / raw)
To: Jason Wessel
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
paulus, Andrew Morton
In-Reply-To: <4689025C.8000001@windriver.com>
Hello.
Jason Wessel wrote:
>>> allmodconfig on powerpc (iMac g3) fails due to
>>> git-kgdb.patch. allmodconfig defaults should be changed?
>>> CC arch/powerpc/kernel/kgdb.o
>>> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB
>>> selected in .config. Unselect one of them.
>>> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
>>> make: *** [arch/powerpc/kernel] Blad 2
>> I'm not sure if this will work out but maybe it's worth to disable
>> XMON if KGDB is selected, like this?
>> config XMON
>> bool "Include xmon kernel debugger"
>> depends on DEBUGGER && !KGDB
> It did not seem that you can make a radio button / multi-select kernel
> config option unless the options are in the same Kconfig file. Given
> that xmon and kgdb are mutually exclusive at the moment.
> What Sergei mentioned is the fix that needs to be used for the time being.
> Attached is the patch I put in the for_mm branch in the linux-2.6-kgdb
> git tree.
> Jason.
> ------------------------------------------------------------------------
> xmon_or_kgdb.patch
> From: Jason Wessel <jason.wessel@windriver.com>
> Subject: [PATCH] Turn off xmon if kgdb is active on ppc and powerpc
> Xmon and kgdb are mutuall exclusive at the moment so xmon should be
> turned off in the kernel config options if kgdb selected. The case with "make allmodconfig" was failing and this patch addresses the problem.
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> ---
> arch/powerpc/Kconfig.debug | 2 +-
> arch/ppc/Kconfig.debug | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
This patch does not seem complete as the #error that was tiggering has not
been deleleted from arch/powerpc/kernel/kgdb.c (and not it's useless)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Josh Boyer @ 2007-07-02 13:46 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, david
In-Reply-To: <E1I5MAY-0005jS-Hk@jdl.com>
On Mon, 2007-07-02 at 08:42 -0500, Jon Loeliger wrote:
> So, like, the other day Josh Boyer mumbled:
> > Add a minimal install target
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> Applied with the following changes --amend'ed in as well:
Great. Thanks Jon, saves me from having to send out yet another patch.
josh
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Jon Loeliger @ 2007-07-02 13:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, david
In-Reply-To: <1183128803.30145.29.camel@weaponx.rchland.ibm.com>
So, like, the other day Josh Boyer mumbled:
> Add a minimal install target
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Applied with the following changes --amend'ed in as well:
> +install: dtc ftdump
> + $(INSTALL) -d $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
Don't put a slash after $(DESTDIR). You'll end up with a doulbe slash.
Andreas.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Remove bogus break statement
From: Jon Loeliger @ 2007-07-02 13:33 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, 5B
In-Reply-To: <20070628013231.GF15298@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Commit 0738774fcc34b78a708a127fb4b2f193d08c94ba introduced some
> incorrect indentation / bracketing in unflatten_tree(). By luck, the
> extra break statement intended to be within an if block, but actually
> afterwards has no semantic effect. Still, this patch gets rid of it
> for cleanliness.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ 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