* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-23 0:03 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development
In-Reply-To: <49EF9B50.7010904@freescale.com>
On Wed, Apr 22, 2009 at 5:33 PM, Scott Wood <scottwood@freescale.com> wrote:
> All I'm asking is that we treat a mandatory dts upgrade as seriously as a
> mandatory firmware upgrade.
I agree with this statement 100%.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2] powerpc: Refactor board check for quirk
From: Stephen Rothwell @ 2009-04-22 23:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1240419370-1971-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
Hi Kumar,
On Wed, 22 Apr 2009 11:56:10 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> Refactor the check to determine if the quirk is applicable to the boards
> into one inline function so we only have to change one place to add more
> boards that the quirks might be applicable to.
>
> Also removed a warning related to unused temp variable.
This commit message could be made better by giving the reader a hint as to
which board is being referred to.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [OT] Lite5200B w/ nfs root hangs after some time
From: Roy Siu @ 2009-04-22 23:35 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Albrecht Dreß, Linux PPC Development
In-Reply-To: <20090422181059.7510A83420E8@gemini.denx.de>
good try for the expr., platform.
=A6b 2009=A6~4=A4=EB23=A4=E9 =A4W=A4=C82:10 =AE=C9=A1A Wolfgang Denk =
=BCg=A8=EC=A1G
> Dear Albrecht =3D?iso-8859-1?b?RHJl3w=3D=3D?=3D,
>
> In message <1240422181.5492.0@antares> you wrote:
>>
>> this question is maybe off-topic on this list...
>
> This is not off topic (actually, if you had bothered to check the
> mailing ist archives before posting, you would have known - because
> you would have found previous discussions of this issue, including the
> necessary fix).
>
>> I use the Lite5200B board with stock kernel 2.6.29, and boot with the
>
> That's known to show this problem.
>
>> [ 4912.350855] nfs: server 10.16.10.29 not responding, still trying
>
> well known symptom.
>
>> an the the system is *completely* dead, i.e. it doesn't respond to
>
> No, it is NOT completely dead, just extremely slow.
>
>> Any idea what goes wrong here, and how I could fix it?
>
> Apply this patch:
>
> http://patchwork.ozlabs.org/patch/24487/
>
> Best regards,
>
> Wolfgang Denk
>
> --=20
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> When all is said and done, more is said than done.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc: adjust oprofile_cpu_type
From: Mike Wolf @ 2009-04-22 23:40 UTC (permalink / raw)
To: linuxppc-dev
Resending. the patch was munged last time.
Oprofile is changing the naming it is using for the compatibility modes.
Instead of having compat-power<x>, oprofile will go to family naming
convention and use compat-v<x>. Currently only compat-v1 will be
defined.
Signed-off-by: Mike Wolf <mjw@linux.vnet.ibm.com>
----
--- mainline.orig/arch/powerpc/kernel/cputable.c 2009-04-16 09:47:49.000000000 -0500
+++ mainline/arch/powerpc/kernel/cputable.c 2009-04-16 14:28:28.000000000 -0500
@@ -382,7 +382,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power5+",
+ .oprofile_cpu_type = "ppc64/compat-v1",
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5+",
},
{ /* Power6 */
@@ -416,7 +417,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power6",
+ .oprofile_cpu_type = "ppc64/compat-v1",
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power6",
},
{ /* 2.06-compliant processor, i.e. Power7 "architected" mode */
@@ -429,7 +431,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power7",
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .oprofile_cpu_type = "ppc64/compat-v1",
.platform = "power7",
},
{ /* Power7 */
@@ -1833,8 +1836,10 @@
* and, in that case, keep the current value for
* oprofile_cpu_type.
*/
- if (old.oprofile_cpu_type == NULL)
+ if (old.oprofile_cpu_type == NULL) {
t->oprofile_cpu_type = s->oprofile_cpu_type;
+ t->oprofile_type = s->oprofile_type;
+ }
}
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-22 22:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <5D0145E3-0A98-429E-8D53-1A8DF4216462@kernel.crashing.org>
Kumar Gala wrote:
> On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
>> Kumar Gala wrote:
>>> I disagree. If you update your kernel you should update your device
>>> tree (thus we have .dts in the kernel tree and not somewhere else).
>>
>> No. The device tree is a means to pass information from the firmware
>> to the kernel. It is part of the firmware. That the repository of
>> trees is in the Linux kernel for any boards which are not including
>> the tree inside a bootwrapper is a historical accident.
>
> I think its a point of view argument.
I don't. It is the responsibility of u-boot to produce a complete
device tree; what bits are in the dts and what bits are programatically
generated is an internal implementation detail. We are currently
hosting some parts of that implementation detail in the Linux tree, but
it is still a u-boot implementation detail. U-boot is perfectly within
its rights to generate the entire tree from scratch if it wanted to.
Just a few hours ago you were telling me that you didn't want to put
accurate information in the device tree because you wanted u-boot to
generate it instead. :-)
The reason we have standards such as ePAPR in the first place is so that
we are dealing with well-defined interfaces that can be used even when
the firmware is not U-Boot at all (but merely something that is
standards-compliant) and/or the kernel is not Linux at all (but merely
something that is standards-compliant). The downside to that is that
revising standards is a bit more of a pain than revising code. We can
do it if it's worthwhile, but we should try to avoid doing it gratuitously.
> I don't agree its part of the
> firmware, at least not part of the firmware we use (u-boot).
We have had many instances of certain versions of device trees being
incompatible with certain versions of u-boot.
All I'm asking is that we treat a mandatory dts upgrade as seriously as
a mandatory firmware upgrade.
>> Updating the dtb with the kernel just shifts the risk of
>> incompatibility to interactions between the firmware and the dtb. The
>> same backwards compatibility considerations when making kernel changes
>> that depend on firmware changes should be made when making kernel
>> changes that depend on dts changes.
>
> As I told Timur, I'm speaking of addition of new nodes and code that
> parses and expect those nodes to be there.
And what do we gain from this change in interface with the firmware on
hardware that is not exactly under active development? What problem are
you trying to solve? Why do we need to get rid of get_immrbase() (as
opposed to being less reliant on it going forward, and tolerating its
failure on platforms that may be virtualized and thus not have the
complete IMMR/CCSR)?
Will any of these new nodes need anything to be filled in by u-boot?
-Scott
^ permalink raw reply
* Re: removing get_immrbase()??
From: Kumar Gala @ 2009-04-22 22:07 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <49EF92E6.4090301@freescale.com>
On Apr 22, 2009, at 4:57 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> New nodes. For example I've proposed a "local access window" node.
>> Once I add it I plan on changing code to use it. This will break an
>> old device tree booting with the new kernel and I'm completely ok
>> with
>> that.
>
> Are we having two different conversations? I was talking about this
> block from your email:
>
>>> arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR
>>> (get_immrbase() +
>>> 0x80000)
>>> arch/powerpc/sysdev/cpm2.c: cpm2_immr = ioremap(get_immrbase(),
>>> CPM_MAP_SIZE);
>>> these two are related and seem like we could look for
>>> "fsl,cpm2"
>>
>> That's okay, as long as you don't break compatibility with older
>> device trees that don't have that property, unless you can
>> demonstrate
>> that these trees would never work with the current kernel anyway.
>
> Specifically, I was referring to this comment:
>
> these two are related and seem like we could look for "fsl,cpm2"
>
> And my point was that not all device trees have "fsl,cpm2" in their
> CPM
> nodes.
Yes -- we are having two different conversations. I've moved on from
the specific issue of "fsl,cpm2" not existing in old device trees.
I've moved to a more general statement about how I can solve some of
the CPM2 related uses of cpm2_immr. For example we assign cpmp based
on cpm2_immr. I could stop using cpm2_immr and solve this problem by
adding a new device node for the comm-proc registers in the device
trees at which point I'd break older .dts working with the kernel.
- k
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-22 22:00 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development
In-Reply-To: <49EF938C.9050704@freescale.com>
Scott Wood wrote:
> That is indeed the case. A "demonstration" of that for the tree you
> quote is that the "reg" address changed -- if you tried feeding the old
> tree into the new kernel, it would not find the CPM command register.
> There is no code in the kernel that looks for the command-proc property
> anymore.
In that case, I have no issues.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-22 22:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev Development
In-Reply-To: <49EF9019.7000102@freescale.com>
Timur Tabi wrote:
> Kumar Gala wrote:
>
>> The specific issue I'm talking about is the addition of new nodes that
>> might break old device trees.
>
> New nodes or new properties? The CPM nodes are not new. On some device
> trees, the original versions did not have a compatible property for the
> CPM nodes (e.g. commit 0b5cf10691eb2c95a9126bf25f5e084d83d5d743).
As I said earlier, old-style CPM trees are a completely different
binding. They are not supported. They have not been supported for a
long time. They were only supported very briefly at the introduction of
CPM hardware to arch/powerpc, and were full of problems.
> Like I said earlier, if you can demonstrate that *all* of these device
> tree would be broken with the latest kernel anyway, then we don't need
> to worry about backwards compatibility.
That is indeed the case. A "demonstration" of that for the tree you
quote is that the "reg" address changed -- if you tried feeding the old
tree into the new kernel, it would not find the CPM command register.
There is no code in the kernel that looks for the command-proc property
anymore.
> I'm tired of debugging customer issues where the kernel is updated but
> the firmware and device tree aren't. IMHO, Kernel developers are
> generally too lax when it comes to firmware and device tree backwards
> compatibility, and I think that's wrong.
I understand and agree (and it would be easier to get the backwards
compatibility right if we didn't have the attitude of "we'll fix the dts
later if we decide we actually care about that aspect of the hardware"
when adding it in the first place) -- it just isn't an issue in this
particular case.
-Scott
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-22 21:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <C86B0B8A-C031-4F4C-AF79-58D77ED6EA2F@kernel.crashing.org>
Kumar Gala wrote:
> New nodes. For example I've proposed a "local access window" node.
> Once I add it I plan on changing code to use it. This will break an
> old device tree booting with the new kernel and I'm completely ok with
> that.
Are we having two different conversations? I was talking about this
block from your email:
>> arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR (get_immrbase() +
>> 0x80000)
>> arch/powerpc/sysdev/cpm2.c: cpm2_immr = ioremap(get_immrbase(),
>> CPM_MAP_SIZE);
>> these two are related and seem like we could look for "fsl,cpm2"
>
> That's okay, as long as you don't break compatibility with older
> device trees that don't have that property, unless you can demonstrate
> that these trees would never work with the current kernel anyway.
Specifically, I was referring to this comment:
these two are related and seem like we could look for "fsl,cpm2"
And my point was that not all device trees have "fsl,cpm2" in their CPM
nodes.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: removing get_immrbase()??
From: Kumar Gala @ 2009-04-22 21:55 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <49EF8E3A.4060304@freescale.com>
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> I disagree. If you update your kernel you should update your
>> device tree (thus we have .dts in the kernel tree and not somewhere
>> else).
>
> No. The device tree is a means to pass information from the
> firmware to the kernel. It is part of the firmware. That the
> repository of trees is in the Linux kernel for any boards which are
> not including the tree inside a bootwrapper is a historical accident.
I think its a point of view argument. I don't agree its part of the
firmware, at least not part of the firmware we use (u-boot).
> Updating the dtb with the kernel just shifts the risk of
> incompatibility to interactions between the firmware and the dtb.
> The same backwards compatibility considerations when making kernel
> changes that depend on firmware changes should be made when making
> kernel changes that depend on dts changes.
As I told Timur, I'm speaking of addition of new nodes and code that
parses and expect those nodes to be there.
- k
^ permalink raw reply
* Re: removing get_immrbase()??
From: Kumar Gala @ 2009-04-22 21:54 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <49EF9019.7000102@freescale.com>
On Apr 22, 2009, at 4:46 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> The specific issue I'm talking about is the addition of new nodes
>> that
>> might break old device trees.
>
> New nodes or new properties? The CPM nodes are not new. On some
> device
> trees, the original versions did not have a compatible property for
> the
> CPM nodes (e.g. commit 0b5cf10691eb2c95a9126bf25f5e084d83d5d743).
> Therefore, there are device trees out there that are missing some
> property.
>
> Like I said earlier, if you can demonstrate that *all* of these device
> tree would be broken with the latest kernel anyway, then we don't need
> to worry about backwards compatibility.
>
> I'm tired of debugging customer issues where the kernel is updated but
> the firmware and device tree aren't. IMHO, Kernel developers are
> generally too lax when it comes to firmware and device tree backwards
> compatibility, and I think that's wrong.
New nodes. For example I've proposed a "local access window" node.
Once I add it I plan on changing code to use it. This will break an
old device tree booting with the new kernel and I'm completely ok with
that.
- k
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-22 21:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <DC91BA72-AF10-41DD-B610-EDEFD106A811@kernel.crashing.org>
Kumar Gala wrote:
> The specific issue I'm talking about is the addition of new nodes that
> might break old device trees.
New nodes or new properties? The CPM nodes are not new. On some device
trees, the original versions did not have a compatible property for the
CPM nodes (e.g. commit 0b5cf10691eb2c95a9126bf25f5e084d83d5d743).
Therefore, there are device trees out there that are missing some property.
Like I said earlier, if you can demonstrate that *all* of these device
tree would be broken with the latest kernel anyway, then we don't need
to worry about backwards compatibility.
I'm tired of debugging customer issues where the kernel is updated but
the firmware and device tree aren't. IMHO, Kernel developers are
generally too lax when it comes to firmware and device tree backwards
compatibility, and I think that's wrong.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [Question] PPC440EPx SMII ethernet
From: Steven A. Falco @ 2009-04-22 21:44 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
We have built a new board based on the PPC440EPx. We are
using an SMII-mode phy for the ethernet.
The .dts file started as the one for Sequoia, and I have
changed the phy specifier to phy-mode = "smii" - I've also
removed the has-mdio property from RGMII0. The ethernet
is working in U-Boot, but when Linux tries to start the
emac I get:
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
RGMII /plb/opb/emac-rgmii@ef601000 initialized without MDIO support
/plb/opb/emac-zmii@ef600d00: bridge in SMII mode
/plb/opb/emac-rgmii@ef601000: unsupported settings !
/plb/opb/emac-rgmii@ef601000: unsupported settings !
and the ethernet is not functional. I don't see any
example .dts files for smii mode. If anyone can tell me
what the .dts settings should be for this configuration,
I'd appreciate it.
The kernel version is 2.6.28.7 - I know that is a bit old
now, but hopefully I can still make progress with it.
Here is the whole .dts section for reference:
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-440epx", "ibm,zmii";
reg = <0xef600d00 0x0000000c>;
};
RGMII0: emac-rgmii@ef601000 {
compatible = "ibm,rgmii-440epx", "ibm,rgmii";
reg = <0xef601000 0x00000008>;
/* has-mdio; */
};
EMAC0: ethernet@ef600e00 {
device_type = "network";
compatible = "ibm,emac-440epx", "ibm,emac4";
interrupt-parent = <&EMAC0>;
interrupts = <0x0 0x1>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*Status*/ 0x0 &UIC0 0x18 0x4
/*Wake*/ 0x1 &UIC1 0x1d 0x4>;
reg = <0xef600e00 0x00000074>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
phy-mode = "smii";
phy-map = <0x00000000>;
zmii-device = <&ZMII0>;
zmii-channel = <0>;
rgmii-device = <&RGMII0>;
rgmii-channel = <0>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
^ permalink raw reply
* Re: removing get_immrbase()??
From: Kumar Gala @ 2009-04-22 21:39 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <49EF8D42.7010104@freescale.com>
On Apr 22, 2009, at 4:33 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> I disagree. If you update your kernel you should update your device
>> tree (thus we have .dts in the kernel tree and not somewhere else).
>
> Is this a new policy? I was under the impression that supporting
> older
> device trees, if not too inconvenient, is desirable. I've nack'd
> patches before that broke backwards compatibility unnecessarily.
The specific issue I'm talking about is the addition of new nodes that
might break old device trees. I have no desire to try and say that I
can't add new nodes and code related to them just because old device
tree's didn't have them.
- k
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-22 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <282847E1-AE1A-44EF-9D18-AF2884105FA5@kernel.crashing.org>
Kumar Gala wrote:
> I disagree. If you update your kernel you should update your device
> tree (thus we have .dts in the kernel tree and not somewhere else).
No. The device tree is a means to pass information from the firmware to
the kernel. It is part of the firmware. That the repository of trees
is in the Linux kernel for any boards which are not including the tree
inside a bootwrapper is a historical accident.
Updating the dtb with the kernel just shifts the risk of incompatibility
to interactions between the firmware and the dtb. The same backwards
compatibility considerations when making kernel changes that depend on
firmware changes should be made when making kernel changes that depend
on dts changes.
-Scott
^ permalink raw reply
* [PATCH v2] fs_enet: Remove dead code
From: Kumar Gala @ 2009-04-22 21:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev
CONFIG_DUET doesn't exist anymore, remove all the code that exists to
support it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* Removed stale comment that went along w/DUET support
drivers/net/fs_enet/fs_enet-main.c | 35 +----------------------------------
drivers/net/fs_enet/fs_enet.h | 5 -----
drivers/net/fs_enet/mac-fec.c | 34 ----------------------------------
3 files changed, 1 insertions(+), 73 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index a9cbc31..76cd206 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -938,30 +938,6 @@ extern void fs_mii_disconnect(struct net_device *dev);
/**************************************************************************************/
-/* handy pointer to the immap */
-void __iomem *fs_enet_immap = NULL;
-
-static int setup_immap(void)
-{
-#ifdef CONFIG_CPM1
- fs_enet_immap = ioremap(IMAP_ADDR, 0x4000);
- WARN_ON(!fs_enet_immap);
-#elif defined(CONFIG_CPM2)
- fs_enet_immap = cpm2_immr;
-#endif
-
- return 0;
-}
-
-static void cleanup_immap(void)
-{
-#if defined(CONFIG_CPM1)
- iounmap(fs_enet_immap);
-#endif
-}
-
-/**************************************************************************************/
-
static int __devinit find_phy(struct device_node *np,
struct fs_platform_info *fpi)
{
@@ -1191,25 +1167,16 @@ static struct of_platform_driver fs_enet_driver = {
static int __init fs_init(void)
{
- int r = setup_immap();
+ int r = of_register_platform_driver(&fs_enet_driver);
if (r != 0)
return r;
- r = of_register_platform_driver(&fs_enet_driver);
- if (r != 0)
- goto out;
-
return 0;
-
-out:
- cleanup_immap();
- return r;
}
static void __exit fs_cleanup(void)
{
of_unregister_platform_driver(&fs_enet_driver);
- cleanup_immap();
}
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index 85a4bab..ef01e09 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -194,9 +194,4 @@ extern const struct fs_ops fs_scc_ops;
/*******************************************************************/
-/* handy pointer to the immap */
-extern void __iomem *fs_enet_immap;
-
-/*******************************************************************/
-
#endif
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index 14e5753..ca7bcb8 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -245,10 +245,6 @@ static void set_multicast_list(struct net_device *dev)
static void restart(struct net_device *dev)
{
-#ifdef CONFIG_DUET
- immap_t *immap = fs_enet_immap;
- u32 cptr;
-#endif
struct fs_enet_private *fep = netdev_priv(dev);
fec_t __iomem *fecp = fep->fec.fecp;
const struct fs_platform_info *fpi = fep->fpi;
@@ -315,36 +311,6 @@ static void restart(struct net_device *dev)
FW(fecp, ievent, 0xffc0);
FW(fecp, ivec, (virq_to_hw(fep->interrupt) / 2) << 29);
- /*
- * adjust to speed (only for DUET & RMII)
- */
-#ifdef CONFIG_DUET
- if (fpi->use_rmii) {
- cptr = in_be32(&immap->im_cpm.cp_cptr);
- switch (fs_get_fec_index(fpi->fs_no)) {
- case 0:
- cptr |= 0x100;
- if (fep->speed == 10)
- cptr |= 0x0000010;
- else if (fep->speed == 100)
- cptr &= ~0x0000010;
- break;
- case 1:
- cptr |= 0x80;
- if (fep->speed == 10)
- cptr |= 0x0000008;
- else if (fep->speed == 100)
- cptr &= ~0x0000008;
- break;
- default:
- BUG(); /* should never happen */
- break;
- }
- out_be32(&immap->im_cpm.cp_cptr, cptr);
- }
-#endif
-
-
FW(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
/*
* adjust to duplex mode
--
1.6.0.6
^ permalink raw reply related
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-22 21:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <282847E1-AE1A-44EF-9D18-AF2884105FA5@kernel.crashing.org>
Kumar Gala wrote:
> I disagree. If you update your kernel you should update your device
> tree (thus we have .dts in the kernel tree and not somewhere else).
Is this a new policy? I was under the impression that supporting older
device trees, if not too inconvenient, is desirable. I've nack'd
patches before that broke backwards compatibility unnecessarily.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: removing get_immrbase()??
From: Kumar Gala @ 2009-04-22 21:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <49EF7B1C.2080105@freescale.com>
On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
> Scott Wood wrote:
>> Timur Tabi wrote:
>>>> these two are related and seem like we could look for
>>>> "fsl,cpm2"
>>> That's okay, as long as you don't break compatibility with older
>>> device trees that don't have that property, unless you can
>>> demonstrate
>>> that these trees would never work with the current kernel anyway.
>>
>> All CPM2 device trees should have fsl,cpm2 listed in the compatible
>> of
>> the CPM node.
>
> Yes, but did they always have that compatible field? I'm concerned
> about situations where someone updates his kernel but not his device
> tree. This is a scenerio that we always need to try to support.
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
- k
^ permalink raw reply
* Re: [PATCH] fs_enet: Remove dead code
From: Scott Wood @ 2009-04-22 21:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, David Miller, linuxppc-dev
In-Reply-To: <1240435170-5183-1-git-send-email-galak@kernel.crashing.org>
Kumar Gala wrote:
> @@ -318,32 +314,6 @@ static void restart(struct net_device *dev)
> /*
> * adjust to speed (only for DUET & RMII)
> */
> -#ifdef CONFIG_DUET
> - if (fpi->use_rmii) {
Please remove the comment that goes with the code being removed.
Otherwise, ACK.
-Scott
^ permalink raw reply
* [PATCH] fs_enet: Remove dead code
From: Kumar Gala @ 2009-04-22 21:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev
CONFIG_DUET doesn't exist anymore, remove all the code that exists to
support it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/net/fs_enet/fs_enet-main.c | 35 +----------------------------------
drivers/net/fs_enet/fs_enet.h | 5 -----
drivers/net/fs_enet/mac-fec.c | 30 ------------------------------
3 files changed, 1 insertions(+), 69 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index a9cbc31..76cd206 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -938,30 +938,6 @@ extern void fs_mii_disconnect(struct net_device *dev);
/**************************************************************************************/
-/* handy pointer to the immap */
-void __iomem *fs_enet_immap = NULL;
-
-static int setup_immap(void)
-{
-#ifdef CONFIG_CPM1
- fs_enet_immap = ioremap(IMAP_ADDR, 0x4000);
- WARN_ON(!fs_enet_immap);
-#elif defined(CONFIG_CPM2)
- fs_enet_immap = cpm2_immr;
-#endif
-
- return 0;
-}
-
-static void cleanup_immap(void)
-{
-#if defined(CONFIG_CPM1)
- iounmap(fs_enet_immap);
-#endif
-}
-
-/**************************************************************************************/
-
static int __devinit find_phy(struct device_node *np,
struct fs_platform_info *fpi)
{
@@ -1191,25 +1167,16 @@ static struct of_platform_driver fs_enet_driver = {
static int __init fs_init(void)
{
- int r = setup_immap();
+ int r = of_register_platform_driver(&fs_enet_driver);
if (r != 0)
return r;
- r = of_register_platform_driver(&fs_enet_driver);
- if (r != 0)
- goto out;
-
return 0;
-
-out:
- cleanup_immap();
- return r;
}
static void __exit fs_cleanup(void)
{
of_unregister_platform_driver(&fs_enet_driver);
- cleanup_immap();
}
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index 85a4bab..ef01e09 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -194,9 +194,4 @@ extern const struct fs_ops fs_scc_ops;
/*******************************************************************/
-/* handy pointer to the immap */
-extern void __iomem *fs_enet_immap;
-
-/*******************************************************************/
-
#endif
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index 14e5753..7abe1fd 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -245,10 +245,6 @@ static void set_multicast_list(struct net_device *dev)
static void restart(struct net_device *dev)
{
-#ifdef CONFIG_DUET
- immap_t *immap = fs_enet_immap;
- u32 cptr;
-#endif
struct fs_enet_private *fep = netdev_priv(dev);
fec_t __iomem *fecp = fep->fec.fecp;
const struct fs_platform_info *fpi = fep->fpi;
@@ -318,32 +314,6 @@ static void restart(struct net_device *dev)
/*
* adjust to speed (only for DUET & RMII)
*/
-#ifdef CONFIG_DUET
- if (fpi->use_rmii) {
- cptr = in_be32(&immap->im_cpm.cp_cptr);
- switch (fs_get_fec_index(fpi->fs_no)) {
- case 0:
- cptr |= 0x100;
- if (fep->speed == 10)
- cptr |= 0x0000010;
- else if (fep->speed == 100)
- cptr &= ~0x0000010;
- break;
- case 1:
- cptr |= 0x80;
- if (fep->speed == 10)
- cptr |= 0x0000008;
- else if (fep->speed == 100)
- cptr &= ~0x0000008;
- break;
- default:
- BUG(); /* should never happen */
- break;
- }
- out_be32(&immap->im_cpm.cp_cptr, cptr);
- }
-#endif
-
FW(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
/*
--
1.6.0.6
^ permalink raw reply related
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-22 20:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development
In-Reply-To: <49EF7394.30606@freescale.com>
Scott Wood wrote:
>> arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR (get_immrbase() +
>> 0x80000)
>> arch/powerpc/sysdev/cpm2.c: cpm2_immr = ioremap(get_immrbase(),
>> CPM_MAP_SIZE);
>> these two are related and seem like we could look for "fsl,cpm2"
>
> And do what with it that wouldn't be a reimplementation of get_immrbase()?
Sorry, I missed that you're referring to the CPM node rather than the
IMMR node. The CPM node's address points specifically to some CPM
control registers, not to the start of a CPM "region" of IMMR/CCSR -- it
has an empty ranges property to bypass address translation.
I think this needs more careful untangling, and some new device tree
nodes (sorry Timur) if we want to get rid of the magic offsets and huge
multiple-block-spanning structures. I'm not sure it's worth it given
the microscopic odds of a new CPM2 chip coming out, unless it's part of
a CPM/QE merge.
-Scott
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-22 20:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev Development
In-Reply-To: <49EF7B1C.2080105@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>> Timur Tabi wrote:
>>>> these two are related and seem like we could look for "fsl,cpm2"
>>> That's okay, as long as you don't break compatibility with older
>>> device trees that don't have that property, unless you can demonstrate
>>> that these trees would never work with the current kernel anyway.
>> All CPM2 device trees should have fsl,cpm2 listed in the compatible of
>> the CPM node.
>
> Yes, but did they always have that compatible field?
Yes, except for trees from the previous era of CPM2 bindings which are
not supported at all. This isn't new.
-Scott
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-22 20:16 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development
In-Reply-To: <49EF7B11.2000006@freescale.com>
Scott Wood wrote:
> Timur Tabi wrote:
>>> these two are related and seem like we could look for "fsl,cpm2"
>> That's okay, as long as you don't break compatibility with older
>> device trees that don't have that property, unless you can demonstrate
>> that these trees would never work with the current kernel anyway.
>
> All CPM2 device trees should have fsl,cpm2 listed in the compatible of
> the CPM node.
Yes, but did they always have that compatible field? I'm concerned
about situations where someone updates his kernel but not his device
tree. This is a scenerio that we always need to try to support.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-22 20:16 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev Development
In-Reply-To: <ed82fe3e0904221235i51fb75dap44b1fad09a10ea91@mail.gmail.com>
Timur Tabi wrote:
>> these two are related and seem like we could look for "fsl,cpm2"
>
> That's okay, as long as you don't break compatibility with older
> device trees that don't have that property, unless you can demonstrate
> that these trees would never work with the current kernel anyway.
All CPM2 device trees should have fsl,cpm2 listed in the compatible of
the CPM node.
-Scott
^ permalink raw reply
* Re: [PATCH v6] spi: Add PPC4xx SPI driver
From: David Brownell @ 2009-04-22 20:00 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <1231411250-25380-1-git-send-email-sr@denx.de>
On Thursday 08 January 2009, Stefan Roese wrote:
> This adds a SPI driver for the SPI controller found in the IBM/AMCC
> 4xx PowerPC's.
> +/*
> + * The PPC4xx SPI controller has no FIFO so each sent/received byte will
> + * generate an interrupt to the CPU. This can cause high CPU utilization.
> + * This driver allows platforms to reduce the interrupt load on the CPU
> + * during SPI transfers by setting max_speed_hz via the device tree.
Note that an alternate strategy is to use polling instead of IRQs,
at least when the data rate is high enough that the IRQ processing
is also slowing down the data transfers.
> +/* bits in mode register - bit 0 ist MSb */
> +/* data latched on leading edge of clock, else trailing edge */
> +#define SPI_PPC4XX_MODE_SCP (0x80 >> 3)
Or in short, SCP == CPHA.
> +/* port enabled */
> +#define SPI_PPC4XX_MODE_SPE (0x80 >> 4)
> +/* MSB first, else LSB first */
> +#define SPI_PPC4XX_MODE_RD (0x80 >> 5)
> +/* clock invert - idle clock = 1, active clock = 0; else reversed */
> +#define SPI_PPC4XX_MODE_CI (0x80 >> 6)
Or in short, CI == CPOL.
> +/* loopback enable */
> +#define SPI_PPC4XX_MODE_IL (0x80 >> 7)
> +/* bits in control register */
> +/* starts a transfer when set */
> +#define SPI_PPC4XX_CR_STR (0x80 >> 7)
> +/* bits in status register */
> +/* port is busy with a transfer */
> +#define SPI_PPC4XX_SR_BSY (0x80 >> 6)
> +/* RxD ready */
> +#define SPI_PPC4XX_SR_RBR (0x80 >> 7)
> +
> +/* the spi->mode bits understood by this driver: */
> +#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
> +
> +/* clock settings (SCP and CI) for various SPI modes */
> +#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
> +#define SPI_CLK_MODE1 0
> +#define SPI_CLK_MODE2 SPI_PPC4XX_MODE_CI
> +#define SPI_CLK_MODE3 (SPI_PPC4XX_MODE_SCP | SPI_PPC4XX_MODE_CI)
Color me puzzled then. Either the definitions of MODE0 and MODE1
are swapped here ... or the comments above are wrong, and SCP should
describe "falling" vs "rising" instead of "leading" vs "trailing".
> +static int spi_ppc4xx_setupxfer(struct spi_device *spi, struct spi_transfer *t)
> +{
> + struct ppc4xx_spi *hw = spi_master_get_devdata(spi->master);
> + struct spi_ppc4xx_cs *cs = spi->controller_state;
> + int scr;
> + u8 cdm = 0;
> + u32 speed;
> + u8 bits_per_word;
> +
> + bits_per_word = (t) ? t->bits_per_word : spi->bits_per_word;
> + speed = (t) ? t->speed_hz : spi->max_speed_hz;
> +
> + ...
> +
> + if (!speed || (speed > spi->max_speed_hz)) {
This is wrong. Typical case is that t->speed_hz is zero,
meaning "use spi->max_speed_hz" ... you treat that as an error.
> + dev_err(&spi->dev, "invalid speed_hz (%d)\n", speed);
> + return -EINVAL;
> + }
> +
> + ...
> +}
> +
> +static int spi_ppc4xx_setup(struct spi_device *spi)
> +{
> + int ret;
> + struct spi_ppc4xx_cs *cs = spi->controller_state;
> + int init = 0;
This "init" thing is still wrong.
Consider: board gets set up with one device. Later,
*WHILE BUSY TRANSFERRING DATA TO/FROM THAT DEVICE*
some other device gets instantiated. Then ...
> + if (cs == NULL) {
> + cs = kzalloc(sizeof *cs, GFP_KERNEL);
> + if (!cs)
> + return -ENOMEM;
> + spi->controller_state = cs;
> +
> + /*
> + * First time called, so let's init the SPI controller
> + * at the end of this function
> + */
> + init = 1;
"init" becomes true here, although the controller has
already been initialized. If it needs to be set up,
do it in probe() before registering the spi_master.
> + }
> +
> + ...
> +
> + /*
> + * New configuration (mode, speed etc) will be written to the
> + * controller in spi_ppc4xx_setupxfer(). Only call
> + * spi_ppc4xx_setupxfer() directly upon first initialization.
> + */
> + if (init) {
> + ret = spi_ppc4xx_setupxfer(spi, NULL);
... so blam, you clobber the settings currently being used for
the active transfer. So this would be a bug.
If not ... this driver deserves a comment on exactly how
unusual this driver is. Specifically, that all spi_device
children must be set up *in advance* so that standard calls
like spi_new_device() don't work with it; and why.
I don't think I see anything in this driver which would
prevent that from working, though. Sure you've got to
have a list of chipselect GPIOs in advance, but that's
distinct from being unable to use spi_new_device().
> + ...
> +}
> +
> +static void spi_ppc4xx_chipsel(struct spi_device *spi, int value)
> +{
> + struct ppc4xx_spi *hw = spi_master_get_devdata(spi->master);
> + unsigned int cspol = spi->mode & SPI_CS_HIGH ? 1 : 0;
> + unsigned int cs = spi->chip_select;
> +
> + if (!hw->num_gpios)
> + return;
Hmm, num_gpios ... can never be zero, right? You always
set it up so that of_gpio_count() GPIOs can all be used
as chipselects. Looks like this check is not needed.
> +
> + if (cs >= hw->num_gpios)
> + return;
I guess I don't see why you have num_gpio instead of just
using the chipselect count, either. (Assuming that the
of_gpio_count routine isn't counting *all* gpios, instead
of just ones allocated to this controller, which would be
a different issue.)
> +
> + if (value != BITBANG_CS_INACTIVE && value != BITBANG_CS_ACTIVE)
> + return;
Strange, what other values could be passed??
> +
> + if (value == BITBANG_CS_INACTIVE)
> + cspol = !cspol;
> +
> + gpio_set_value(hw->gpios[cs], cspol);
> +}
> +
> +static irqreturn_t spi_ppc4xx_int(int irq, void *dev_id)
> +{
> + struct ppc4xx_spi *hw;
> + u8 status;
> + u8 data;
> + unsigned int count;
> +
> + hw = (struct ppc4xx_spi *)dev_id;
> +
> + status = in_8(&hw->regs->sr);
> + if (!status)
> + return IRQ_NONE;
> +
> + /* should never happen but check anyway */
> + if (status & SPI_PPC4XX_SR_BSY) {
Maybe "if (unlikely(...)) {" then.
> + u8 lstatus;
> + int cnt = 0;
> +
> + dev_dbg(hw->dev, "got interrupt but spi still busy?\n");
But ... *does* this ever happen? If not, I'd strike this
code. And if it does, I'd add a comment explaining what's
known about this hardware bug. Without this, the IRQ handler
would look pretty tight.
> + do {
> + ndelay(10);
> + lstatus = in_8(&hw->regs->sr);
> + } while (++cnt < 100 && lstatus & SPI_PPC4XX_SR_BSY);
> +
> + if (cnt >= 100) {
> + dev_err(hw->dev, "busywait: too many loops!\n");
> + complete(&hw->done);
> + return IRQ_HANDLED;
> + } else {
> + /* status is always 1 (RBR) here */
> + status = in_8(&hw->regs->sr);
> + dev_dbg(hw->dev, "loops %d status %x\n", cnt, status);
> + }
> + }
> +
> + count = hw->count;
> + hw->count++;
> +
> + if (status & SPI_PPC4XX_SR_RBR) {
> + /* Data Ready */
Most SPI hardware I've seen has at most a weak distinction
between "tx done" and "rx done" IRQs ... there's little
point to separate IRQs, since shifting out the last TX bit
is what shifts in the last RX bit.
Unless this is unusual hardware you can probably just assume
that there's RX data, and only read it if hw->rx is non-null.
Or, if this is *not* set, report the odd behavior...
> + data = in_8(&hw->regs->rxd);
> + if (hw->rx)
> + hw->rx[count] = data;
> + }
> +
> + count++;
> +
> + if (count < hw->len) {
> + data = hw->tx ? hw->tx[count] : 0;
> + out_8(&hw->regs->txd, data);
> + out_8(&hw->regs->cr, SPI_PPC4XX_CR_STR);
> + } else {
> + complete(&hw->done);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> + ...
> +
> +static int __init spi_ppc4xx_of_probe(struct of_device *op,
> + const struct of_device_id *match)
> +{
> + struct ppc4xx_spi *hw;
> + struct spi_master *master;
> + struct spi_bitbang *bbp;
> + struct resource resource;
> + struct device_node *np = op->node;
> + struct device *dev = &op->dev;
> + struct device_node *opbnp;
> + int ret;
> + const unsigned int *clk;
> +
> + master = spi_alloc_master(dev, sizeof *hw);
> + if (master == NULL)
> + return -ENOMEM;
> + dev_set_drvdata(dev, master);
> + hw = spi_master_get_devdata(master);
> + memset(hw, 0, sizeof(struct ppc4xx_spi));
That memset is not required, it comes to you pre-zeroed.
> +
> + hw->master = spi_master_get(master);
> + hw->dev = dev;
> +
> + init_completion(&hw->done);
> +
> + hw->num_gpios = of_gpio_count(np);
Worth a comment what's going on there. I'm assuming this
of_gpio_count() thing returns a count of GPIOs somehow
associated with this specific device tree node, rather than
say all GPIOs known to the device tree...
> + if (hw->num_gpios) {
> + int i;
> +
> + hw->gpios = kzalloc(sizeof(int) * hw->num_gpios,
> + GFP_KERNEL);
> + if (!hw->gpios) {
> + ret = -ENOMEM;
> + goto free_master;
> + }
> +
> + for (i = 0; i < hw->num_gpios; i++) {
> + int gpio = of_get_gpio(np, i);
> + if (gpio < 0) {
> + dev_err(dev, "Invalid gpio spec %d\n", i);
> + ret = gpio;
> + goto free_gpios;
> + }
> +
> + ret = gpio_request(gpio, np->name);
> + if (ret < 0) {
> + dev_err(dev, "gpio %d already in use\n", i);
> + ret = gpio;
> + goto free_gpios;
> + }
> +
> + gpio_direction_output(gpio, 0);
> + hw->gpios[i] = gpio;
> + }
> + }
Else ... error, if there are no chipselects?
I've got a patch pending to add a "no chipselect" spi->mode flag.
If you expect to support that, please let me know.
> +
> + /* Setup the state for the bitbang driver */
> + bbp = &hw->bitbang;
> + bbp->master = hw->master;
> + bbp->setup_transfer = spi_ppc4xx_setupxfer;
> + bbp->chipselect = spi_ppc4xx_chipsel;
> + bbp->txrx_bufs = spi_ppc4xx_txrx;
> + bbp->use_dma = 0;
> + bbp->master->setup = spi_ppc4xx_setup;
> + bbp->master->cleanup = spi_ppc4xx_cleanup;
> + /* only one SPI controller */
> + bbp->master->bus_num = 0;
Bad assumption. There could be GPIO-based adapters,
of course. And aren't these the cores which can be
found on higher end Xilinx FPGAs? And, accordingly,
integrated with any number of additional controllers?
If so, the restriction is just that this controller
be bus #0. If not ... the Kconfig should say more
about *which* PPC4xx chips have this controller.
(I suspect it's the latter.)
> + if (bbp->master->num_chipselect == 0) {
You didn't set it, so of course it's still zeroed.
> + /* this many pins in al GPIO controllers */
> + bbp->master->num_chipselect = hw->num_gpios;
So num_chipselect is alays num_gpios, and there's no point
to having num_gpios since you could always use num_chipselect.
> + }
> +
> + ...
> +}
^ 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