* Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
From: Benjamin Herrenschmidt @ 2013-11-05 19:52 UTC (permalink / raw)
To: Alan Stern; +Cc: Alistair Popple, linux-usb, linuxppc-dev
In-Reply-To: <Pine.LNX.4.44L0.1311051004080.1360-100000@iolanthe.rowland.org>
On Tue, 2013-11-05 at 10:04 -0500, Alan Stern wrote:
> On Tue, 5 Nov 2013, Alistair Popple wrote:
>
> > The IBM Akebono board has an EHCI compliant USB host interface. This
> > patch adds support for it to the EHCI platform driver.
> >
> > Signed-off-by: Alistair Popple <alistair@popple.id.au>
> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: linux-usb@vger.kernel.org
> > ---
> > drivers/usb/host/ehci-platform.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> > index f6b790c..0a67616 100644
> > --- a/drivers/usb/host/ehci-platform.c
> > +++ b/drivers/usb/host/ehci-platform.c
> > @@ -203,9 +203,10 @@ static int ehci_platform_resume(struct device *dev)
> > #define ehci_platform_resume NULL
> > #endif /* CONFIG_PM */
> >
> > -static const struct of_device_id vt8500_ehci_ids[] = {
> > +static const struct of_device_id ehci_platform_ids[] = {
> > { .compatible = "via,vt8500-ehci", },
> > { .compatible = "wm,prizm-ehci", },
> > + { .compatible = "ibm,akebono-ehci", },
> > {}
> > };
Why ? Do we need to add an entry for every platform in there ? Besides,
it probably should be the SoC name not the platform here....
Why not simply a generic compatible "usb-ehci" ? It's a standard
programming interface, there are no specific quirks, we shouldn't
need to have to add new entries to the driver like that for every
new SoC/platform.
> > @@ -229,7 +230,7 @@ static struct platform_driver ehci_platform_driver = {
> > .owner = THIS_MODULE,
> > .name = "ehci-platform",
> > .pm = &ehci_platform_pm_ops,
> > - .of_match_table = vt8500_ehci_ids,
> > + .of_match_table = ehci_platform_ids,
> > }
> > };
>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Benjamin Herrenschmidt @ 2013-11-05 19:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Alistair Popple, linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383675404.2868.8.camel@bwh-desktop.uk.level5networks.com>
On Tue, 2013-11-05 at 18:16 +0000, Ben Hutchings wrote:
> On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> [...]
> > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > bool
> > default n
> >
> > +config IBM_EMAC_RGMII_WOL
> > + bool
> > + default n
> > +
> [...]
>
> So no-one can even build-test this at present!
Patch 7/7 adds the select to the platform, isn't that sufficient ?
It's an SoC bit so there's little point making it generally
selectable by the user.
Alistair: The commit name should be different, it's not a PHY you are
adding, it's a PHY interface (the PHY itself is off chip).
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH v2] KVM: PPC: vfio kvm device: support spapr tce
From: Alex Williamson @ 2013-11-05 21:32 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Gleb Natapov, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1383638731-13467-1-git-send-email-aik@ozlabs.ru>
On Tue, 2013-11-05 at 19:05 +1100, Alexey Kardashevskiy wrote:
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> Changes:
> v2:
> * it does not try to introduce a realmode search function.
> Instead, liobn-to-iommu-group lookup is done by VFIO KVM device
> in virtual mode and the result (iommu_group pointer) is cached
> in kvm_arch so the realmode handlers do not use VFIO KVM device for that.
> And the iommu groups get released on KVM termination.
>
> I tried this, seems viable.
>
> Did not I miss anything? Thanks.
A commit message ;)
> ---
> arch/powerpc/include/asm/kvm_host.h | 3 ++
> arch/powerpc/kvm/Kconfig | 1 +
> arch/powerpc/kvm/Makefile | 3 ++
> include/linux/vfio.h | 3 ++
> include/uapi/linux/kvm.h | 1 +
> virt/kvm/vfio.c | 74 +++++++++++++++++++++++++++++++++++++
> 6 files changed, 85 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 48dbe8b..e1163d7 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -293,6 +293,9 @@ struct kvm_arch {
> #ifdef CONFIG_KVM_XICS
> struct kvmppc_xics *xics;
> #endif
> +#ifdef CONFIG_KVM_VFIO
> + struct kvm_vfio *vfio;
> +#endif
> };
>
> /*
> diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
> index 61b3535..d1b7f64 100644
> --- a/arch/powerpc/kvm/Kconfig
> +++ b/arch/powerpc/kvm/Kconfig
> @@ -60,6 +60,7 @@ config KVM_BOOK3S_64
> select KVM_BOOK3S_64_HANDLER
> select KVM
> select SPAPR_TCE_IOMMU
> + select KVM_VFIO
> ---help---
> Support running unmodified book3s_64 and book3s_32 guest kernels
> in virtual machines on book3s_64 host processors.
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 6646c95..2438d2e 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
> kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
> book3s_xics.o
>
> +kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
> + $(KVM)/vfio.o \
> +
> kvm-book3s_64-module-objs := \
> $(KVM)/kvm_main.o \
> $(KVM)/eventfd.o \
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 24579a0..681e19b 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -97,4 +97,7 @@ extern struct vfio_group *vfio_group_get_external_user(struct file *filep);
> extern void vfio_group_put_external_user(struct vfio_group *group);
> extern int vfio_external_user_iommu_id(struct vfio_group *group);
>
> +extern struct iommu_group *vfio_find_group_by_liobn(struct kvm *kvm,
> + unsigned long liobn);
> +
Nope, this doesn't go in vfio.h, it's a function provided by kvm. It
should be named as such too, kvm_vfio_... It also depends on both
CONFIG_KVM_VFIO and CONFIG_SPAPR_TCE_IOMMU and needs stub version
otherwise. Is just _liobn specific enough or does it need a spapr_tce
thrown in to avoid confusion with embedded ppc folks?
> #endif /* VFIO_H */
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 7c1a349..a74ad16 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -847,6 +847,7 @@ struct kvm_device_attr {
> #define KVM_DEV_VFIO_GROUP 1
> #define KVM_DEV_VFIO_GROUP_ADD 1
> #define KVM_DEV_VFIO_GROUP_DEL 2
> +#define KVM_DEV_VFIO_SPAPR_TCE_LIOBN 2
I wonder if it would be better architecturally if this was an attribute
rather than a new group, ex:
#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN 3
It's a mouthful, but we are setting an attribute of a VFIO group, so it
makes sense. kvm_device_attr.addr would then need to point to a struct
containing both the fd and liobn.
Whatever we come up with need a documentation addition in
Documentation/virtual/kvm/devices/vfio.txt.
>
> /*
> * ioctls for VM fds
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index ca4260e..f9271d5 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -22,6 +22,9 @@
> struct kvm_vfio_group {
> struct list_head node;
> struct vfio_group *vfio_group;
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + uint64_t liobn;
Why is liobn an unsigned long in the exported function but a uint64_t
here?
> +#endif
> };
>
> struct kvm_vfio {
> @@ -188,12 +191,76 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
> return -ENXIO;
> }
>
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> +static int kvm_vfio_set_spapr_tce_liobn(struct kvm_device *dev,
> + long attr, u64 arg)
> +{
> + struct kvm_vfio *kv = dev->private;
> + struct vfio_group *vfio_group;
> + struct kvm_vfio_group *kvg;
> + void __user *argp = (void __user *)arg;
> + struct fd f;
> + int32_t fd;
> + uint64_t liobn = attr;
> +
> + if (get_user(fd, (int32_t __user *)argp))
> + return -EFAULT;
> +
> + f = fdget(fd);
> + if (!f.file)
> + return -EBADF;
> +
> + vfio_group = kvm_vfio_group_get_external_user(f.file);
> + fdput(f);
Not sure why you dropped this from the example of kvm_vfio_set_group:
if (IS_ERR(vfio_group))
return PTR_ERR(vfio_group);
You're also ignoring kv->lock.
> +
> + list_for_each_entry(kvg, &kv->group_list, node) {
> + if (kvg->vfio_group == vfio_group) {
> + WARN_ON(kvg->liobn);
Userspace should not be able to trigger a WARN this easily. Return
EBUSY if it's an error, otherwise let it go.
> + kvg->liobn = liobn;
> + kvm_vfio_group_put_external_user(vfio_group);
> + return 0;
> + }
> + }
> +
> + kvm_vfio_group_put_external_user(vfio_group);
> +
> + return -ENXIO;
> +}
> +
> +struct iommu_group *vfio_find_group_by_liobn(struct kvm *kvm,
> + unsigned long liobn)
As mentioned, kvm_vfio_...
> +{
> + struct kvm_vfio_group *kvg;
> +
> + if (!kvm->arch.vfio)
> + return NULL;
If this is already a slow path you can avoid stashing this pointer and
search kvm->devices for the matching ops struct.
kv->lock...
> +
> + list_for_each_entry(kvg, &kvm->arch.vfio->group_list, node) {
> + if (kvg->liobn == liobn) {
> + int group_id = vfio_external_user_iommu_id(
> + kvg->vfio_group);
> + struct iommu_group *grp =
> + iommu_group_get_by_id(group_id);
nit, ugly line wrapping. Where's the iommu_group_put() done?
> + return grp;
So you've now got an liobn to iommu_group mapping cached away somewhere,
what happens when a group is removed? Would it be invalid for userspace
to re-use the liobn? Do we need a way to invalidate your cached entry
and perhaps do an iommu_group_put()?
This version is actually plausible, so big improvement from v1! Thanks,
Alex
> + }
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(vfio_find_group_by_liobn);
> +#endif
> +
> static int kvm_vfio_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> switch (attr->group) {
> case KVM_DEV_VFIO_GROUP:
> return kvm_vfio_set_group(dev, attr->attr, attr->addr);
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + case KVM_DEV_VFIO_SPAPR_TCE_LIOBN:
> + return kvm_vfio_set_spapr_tce_liobn(dev, attr->attr,
> + attr->addr);
> +#endif
> }
>
> return -ENXIO;
> @@ -211,6 +278,10 @@ static int kvm_vfio_has_attr(struct kvm_device *dev,
> }
>
> break;
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + case KVM_DEV_VFIO_SPAPR_TCE_LIOBN:
> + return 0;
> +#endif
> }
>
> return -ENXIO;
> @@ -251,6 +322,9 @@ static int kvm_vfio_create(struct kvm_device *dev, u32 type)
> mutex_init(&kv->lock);
>
> dev->private = kv;
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + dev->kvm->arch.vfio = kv;
> +#endif
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Arnaud Ebalard @ 2013-11-05 22:12 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1383611239-14556-1-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
> present' made the call to phy_scan optional, if the DT has a link to
> the phy node.
>
> However phy_scan has the side effect of calling phy_addr_set, which
> writes the phy MDIO address to the ethernet controller. If phy_addr_set
> is not called, and the bootloader has not set the correct address then
> the driver will fail to function.
Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
(Armada 370 based) which I had put on a todo list and temporarily
workarounded by including a 'ping whatever' call in my u-boot env in
order to force it to do the init. Without it, I was unable to properly
use the interface. With your fix, after multiple reboots to test it,
everything works as expected. So, FWIW:
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Cheers,
a+
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Sebastian Hesselbarth @ 2013-11-05 22:17 UTC (permalink / raw)
To: Arnaud Ebalard, Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, linux-kernel, Lennert Buytenhek,
netdev, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <87sivacxcf.fsf@natisbad.org>
On 11/05/2013 11:12 PM, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>
>> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
>> present' made the call to phy_scan optional, if the DT has a link to
>> the phy node.
>>
>> However phy_scan has the side effect of calling phy_addr_set, which
>> writes the phy MDIO address to the ethernet controller. If phy_addr_set
>> is not called, and the bootloader has not set the correct address then
>> the driver will fail to function.
>
> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
> (Armada 370 based) which I had put on a todo list and temporarily
Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta,
are you sure it is (was) related to Jason's fix?
Sebastian
> workarounded by including a 'ping whatever' call in my u-boot env in
> order to force it to do the init. Without it, I was unable to properly
> use the interface. With your fix, after multiple reboots to test it,
> everything works as expected. So, FWIW:
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Jason Cooper @ 2013-11-05 23:00 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <87sivacxcf.fsf@natisbad.org>
On Tue, Nov 05, 2013 at 11:12:00PM +0100, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>
> > Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
> > present' made the call to phy_scan optional, if the DT has a link to
> > the phy node.
> >
> > However phy_scan has the side effect of calling phy_addr_set, which
> > writes the phy MDIO address to the ethernet controller. If phy_addr_set
> > is not called, and the bootloader has not set the correct address then
> > the driver will fail to function.
>
> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
> (Armada 370 based) which I had put on a todo list and temporarily
readynas duo v2?
thx,
Jason.
> workarounded by including a 'ping whatever' call in my u-boot env in
> order to force it to do the init. Without it, I was unable to properly
> use the interface. With your fix, after multiple reboots to test it,
> everything works as expected. So, FWIW:
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
>
> Cheers,
>
> a+
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Ben Hutchings @ 2013-11-05 23:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alistair Popple, linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383681240.4776.97.camel@pasglop>
On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-11-05 at 18:16 +0000, Ben Hutchings wrote:
> > On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> > [...]
> > > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > > bool
> > > default n
> > >
> > > +config IBM_EMAC_RGMII_WOL
> > > + bool
> > > + default n
> > > +
> > [...]
> >
> > So no-one can even build-test this at present!
>
> Patch 7/7 adds the select to the platform, isn't that sufficient ?
I suppose so, but I don't think that went to netdev.
> It's an SoC bit so there's little point making it generally
> selectable by the user.
I think a better way to do this is:
config IBM_EMAC_RGMII_WOL
bool "IBM EMAC RGMII wake-on-LAN support"
depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
default y if MY_WONDERFUL_NEW_SOC
Then anyone making an API change that affects this driver can check that
it still complies.
Ben.
> Alistair: The commit name should be different, it's not a PHY you are
> adding, it's a PHY interface (the PHY itself is off chip).
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Arnaud Ebalard @ 2013-11-05 23:14 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, netdev, linux-kernel,
Jason Gunthorpe, Lennert Buytenhek, linuxppc-dev, David Miller,
linux-arm-kernel
In-Reply-To: <52796E82.5010800@gmail.com>
Hi,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> writes:
> On 11/05/2013 11:12 PM, Arnaud Ebalard wrote:
>> Hi Jason,
>>
>> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>>
>>> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
>>> present' made the call to phy_scan optional, if the DT has a link to
>>> the phy node.
>>>
>>> However phy_scan has the side effect of calling phy_addr_set, which
>>> writes the phy MDIO address to the ethernet controller. If phy_addr_set
>>> is not called, and the bootloader has not set the correct address then
>>> the driver will fail to function.
>>
>> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
>> (Armada 370 based) which I had put on a todo list and temporarily
>
> Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta,
> are you sure it is (was) related to Jason's fix?
Thanks for pointing this, Sebastian and my apologies for the noise.
Jason's fix is indeed for a file which is not compiled for my RN102.
As the problem perfectly matched the issue I had and current kernel w/
the patch applied does indeed fix it, I did not try and do the test w/o
the patch applied. It would have showed the problem was fixed by
something else in 3.12. Well, I spent some time digging the changes on
mvneta.c and:
commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed Sep 4 16:21:18 2013 +0200
net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
This commit fixes a long-standing bug that has been reported by many
users: on some Armada 370 platforms, only the network interface that
has been used in U-Boot to tftp the kernel works properly in
Linux. The other network interfaces can see a 'link up', but are
unable to transmit data. The reports were generally made on the Armada
370-based Mirabox, but have also been given on the Armada 370-RD
board.
[SNIP]
$ git tag --contains 714086029116
v3.12
v3.12-rc1
v3.12-rc2
v3.12-rc3
v3.12-rc4
v3.12-rc5
v3.12-rc6
v3.12-rc7
So the problem was indeed fixed at the beginning of 3.12 series by Thomas.
Anyway, my bad and thanks again for pointing it out.
Cheers,
a+
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Alistair Popple @ 2013-11-06 0:08 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, linuxppc-dev, David S. Miller
In-Reply-To: <CAGVrzcZQ26kbim2piOwrvpyOcSaTET5da7Yh4GWv+erfuOBDhQ@mail.gmail.com>
On Tue, 5 Nov 2013 10:47:22 Florian Fainelli wrote:
> [snip]
>
> > +/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
> > +static inline int rgmii_valid_mode(int phy_mode)
> > +{
> > + return phy_mode == PHY_MODE_GMII ||
> > + phy_mode == PHY_MODE_MII ||
> > + phy_mode == PHY_MODE_RGMII ||
> > + phy_mode == PHY_MODE_TBI ||
> > + phy_mode == PHY_MODE_RTBI;
> > +}
> > +
> > +static inline const char *rgmii_mode_name(int mode)
> > +{
> > + switch (mode) {
> > + case PHY_MODE_RGMII:
> > + return "RGMII";
> > + case PHY_MODE_TBI:
> > + return "TBI";
> > + case PHY_MODE_GMII:
> > + return "GMII";
> > + case PHY_MODE_MII:
> > + return "MII";
> > + case PHY_MODE_RTBI:
> > + return "RTBI";
> > + default:
> > + BUG();
> > + }
>
> Any reasons why you are duplicating what is available in
> drivers/of/of_net.c ::of_get_phy_mode()?
Unless I'm missing something of_get_phy_mode() is going the other way.
rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
couldn't find any obvious kernel method to do this but maybe I missed it?
Regards,
Alistair
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Florian Fainelli @ 2013-11-06 0:16 UTC (permalink / raw)
To: Alistair Popple; +Cc: netdev, linuxppc-dev, David S. Miller
In-Reply-To: <81419762.0SyAdYsUqu@mexican>
2013/11/5 Alistair Popple <alistair@popple.id.au>:
> On Tue, 5 Nov 2013 10:47:22 Florian Fainelli wrote:
>> [snip]
>>
>> > +/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
>> > +static inline int rgmii_valid_mode(int phy_mode)
>> > +{
>> > + return phy_mode == PHY_MODE_GMII ||
>> > + phy_mode == PHY_MODE_MII ||
>> > + phy_mode == PHY_MODE_RGMII ||
>> > + phy_mode == PHY_MODE_TBI ||
>> > + phy_mode == PHY_MODE_RTBI;
>> > +}
>> > +
>> > +static inline const char *rgmii_mode_name(int mode)
>> > +{
>> > + switch (mode) {
>> > + case PHY_MODE_RGMII:
>> > + return "RGMII";
>> > + case PHY_MODE_TBI:
>> > + return "TBI";
>> > + case PHY_MODE_GMII:
>> > + return "GMII";
>> > + case PHY_MODE_MII:
>> > + return "MII";
>> > + case PHY_MODE_RTBI:
>> > + return "RTBI";
>> > + default:
>> > + BUG();
>> > + }
>>
>> Any reasons why you are duplicating what is available in
>> drivers/of/of_net.c ::of_get_phy_mode()?
>
> Unless I'm missing something of_get_phy_mode() is going the other way.
> rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
> couldn't find any obvious kernel method to do this but maybe I missed it?
Right, rgmii_mode_name() just has informative purposes and should be
removed, I would suggest using standard device tree bindings property
(phy-mode) anyway such that you could use of_get_phy_mode() and use
phy_interface_t types.
--
Florian
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Alistair Popple @ 2013-11-06 1:34 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383693110.2868.17.camel@bwh-desktop.uk.level5networks.com>
On Tue, 5 Nov 2013 23:11:50 Ben Hutchings wrote:
> On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
[snip]
> > It's an SoC bit so there's little point making it generally
> > selectable by the user.
>
> I think a better way to do this is:
>
> config IBM_EMAC_RGMII_WOL
> bool "IBM EMAC RGMII wake-on-LAN support"
> depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
> default y if MY_WONDERFUL_NEW_SOC
>
> Then anyone making an API change that affects this driver can check that
> it still complies.
The method used in this patch is the same as what is currently used by the
other IBM EMAC PHY interfaces (eg. config IBM_EMAC_ZMII etc). I'm happy to
send a patch to update all of those as well for consistency but that would
mean adding what each platform requires into EMACS Kconfig as well.
Personally I think it is nicer to keep the definitions of what each platform
requires in one place (ie. arch/powerpc/platforms/44x/Kconfig) as it is
consistent with what we do for other 44x drivers, however I am happy to use
the above method if people think it's better.
Alternatively we could do something like this:
config IBM_EMAC_RGMII_WOL
bool
default y if COMPILE_TEST
default n
This would leave the platform dependencies as they are currently but still
allow compile testing.
Regards,
Alistair
> Ben.
>
> > Alistair: The commit name should be different, it's not a PHY you are
> > adding, it's a PHY interface (the PHY itself is off chip).
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Alistair Popple @ 2013-11-06 1:38 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, linuxppc-dev, David S. Miller
In-Reply-To: <CAGVrzcYzBtDcxYXDopOJn_=vW_58SFs9y0uKeGNB9TDPh6J4wg@mail.gmail.com>
On Tue, 5 Nov 2013 16:16:08 Florian Fainelli wrote:
[snip]
> 2013/11/5 Alistair Popple <alistair@popple.id.au>:
> >> Any reasons why you are duplicating what is available in
> >> drivers/of/of_net.c ::of_get_phy_mode()?
> >
> > Unless I'm missing something of_get_phy_mode() is going the other way.
> > rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
> > couldn't find any obvious kernel method to do this but maybe I missed it?
>
> Right, rgmii_mode_name() just has informative purposes and should be
> removed, I would suggest using standard device tree bindings property
> (phy-mode) anyway such that you could use of_get_phy_mode() and use
> phy_interface_t types.
Ok, that's what is currently done in the core IBM EMAC driver. As this is used
just for informative purposes I will remove it. Thanks.
Regards,
Alistair
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Benjamin Herrenschmidt @ 2013-11-06 2:17 UTC (permalink / raw)
To: Alistair Popple; +Cc: netdev, Florian Fainelli, linuxppc-dev, David S. Miller
In-Reply-To: <9250529.5UedqhaNce@mexican>
On Wed, 2013-11-06 at 12:38 +1100, Alistair Popple wrote:
> > Right, rgmii_mode_name() just has informative purposes and should be
> > removed, I would suggest using standard device tree bindings
> property
> > (phy-mode) anyway such that you could use of_get_phy_mode() and use
> > phy_interface_t types.
>
> Ok, that's what is currently done in the core IBM EMAC driver. As this
> is used
> just for informative purposes I will remove it. Thanks.
Why ? Information is useful...
Ben.
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Florian Fainelli @ 2013-11-06 2:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alistair Popple, linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383704240.4776.115.camel@pasglop>
2013/11/5 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> On Wed, 2013-11-06 at 12:38 +1100, Alistair Popple wrote:
>> > Right, rgmii_mode_name() just has informative purposes and should be
>> > removed, I would suggest using standard device tree bindings
>> property
>> > (phy-mode) anyway such that you could use of_get_phy_mode() and use
>> > phy_interface_t types.
>>
>> Ok, that's what is currently done in the core IBM EMAC driver. As this
>> is used
>> just for informative purposes I will remove it. Thanks.
>
> Why ? Information is useful...
Not the way they are currently handled:
+ /* Check if we need to attach to a RGMII */
+ if (!rgmii_valid_mode(mode)) {
+ dev_err(&ofdev->dev, "unsupported settings !\n");
Considering that nothing useful is being printed, that or nothing at
all really looks identical to me.
--
Florian
^ permalink raw reply
* RE: [PATCH V5 1/2] powerpc/85xx: Add QE common init function
From: Xiaobo Xie @ 2013-11-06 2:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1380301237.24959.397.camel@snotra.buserror.net>
SGkgU2NvdHQsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBT
Y290dC1CMDc0MjENCj4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyOCwgMjAxMyAxOjAxIEFN
DQo+IFRvOiBYaWUgWGlhb2JvLVI2MzA2MQ0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFi
cy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBWNSAxLzJdIHBvd2VycGMvODV4eDogQWRkIFFF
IGNvbW1vbiBpbml0IGZ1bmN0aW9uDQo+IA0KPiBPbiBUaHUsIDIwMTMtMDktMjYgYXQgMTc6Mzcg
KzA4MDAsIFhpZSBYaWFvYm8gd3JvdGU6DQo+ID4gKyNpZmRlZiBDT05GSUdfUVVJQ0NfRU5HSU5F
DQo+ID4gK3ZvaWQgX19pbml0IG1wYzg1eHhfcWVfaW5pdCh2b2lkKQ0KPiA+ICt7DQo+ID4gKwlz
dHJ1Y3QgZGV2aWNlX25vZGUgKm5wOw0KPiA+ICsNCj4gPiArCW5wID0gb2ZfZmluZF9jb21wYXRp
YmxlX25vZGUoTlVMTCwgTlVMTCwgImZzbCxxZSIpOw0KPiA+ICsJaWYgKCFucCkgew0KPiA+ICsJ
CW5wID0gb2ZfZmluZF9ub2RlX2J5X25hbWUoTlVMTCwgInFlIik7DQo+ID4gKwkJaWYgKCFucCkg
ew0KPiA+ICsJCQlwcl9lcnIoIiVzOiBDb3VsZCBub3QgZmluZCBRdWljYyBFbmdpbmUgbm9kZVxu
IiwNCj4gPiArCQkJCQlfX2Z1bmNfXyk7DQo+ID4gKwkJCXJldHVybjsNCj4gPiArCQl9DQo+ID4g
Kwl9DQo+ID4gKw0KPiA+ICsJcWVfcmVzZXQoKTsNCj4gPiArCW9mX25vZGVfcHV0KG5wKTsNCj4g
DQo+IFlvdSdyZSBtaXNzaW5nIHRoZSBvZl9kZXZpY2VfaXNfYXZhaWxhYmxlKCkgY2hlY2s6DQoN
Ckkgd2lsbCBhZGQgdGhpcyBjaGVjaywgdGhhbmtzLg0KDQo+IA0KPiA+IC0JbnAgPSBvZl9maW5k
X2NvbXBhdGlibGVfbm9kZShOVUxMLCBOVUxMLCAiZnNsLHFlIik7DQo+ID4gLQlpZiAoIW5wKSB7
DQo+ID4gLQkJbnAgPSBvZl9maW5kX25vZGVfYnlfbmFtZShOVUxMLCAicWUiKTsNCj4gDQo+IC1T
Y290dA0KPiANCg0K
^ permalink raw reply
* RE: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support
From: Xiaobo Xie @ 2013-11-06 2:31 UTC (permalink / raw)
To: Scott Wood; +Cc: Michael Johnston, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1380230838.24959.322.camel@snotra.buserror.net>
SGkgU2NvdHQsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBT
Y290dC1CMDc0MjENCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTMgNToyNyBBTQ0K
PiBUbzogWGllIFhpYW9iby1SNjMwNjENCj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51eHBw
Yy1kZXZAbGlzdHMub3psYWJzLm9yZzsgSm9obnN0b24gTWljaGFlbC0NCj4gUjQ5NjEwDQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggVjQgMy8zXSBwb3dlcnBjLzg1eHg6IEFkZCBUV1ItUDEwMjUgYm9h
cmQgc3VwcG9ydA0KPiANCj4gPiA+ID4gPiA+ICsJLyogQ1MyIGZvciBEaXNwbGF5ICovDQo+ID4g
PiA+ID4gPiArCXNzZDEyODlAMiwwIHsNCj4gPiA+ID4gPiA+ICsJCSNhZGRyZXNzLWNlbGxzID0g
PDE+Ow0KPiA+ID4gPiA+ID4gKwkJI3NpemUtY2VsbHMgPSA8MT47DQo+ID4gPiA+ID4gPiArCQlj
b21wYXRpYmxlID0gInNzZDEyODkiOw0KPiA+ID4gPiA+ID4gKwkJcmVnID0gPDB4MiAweDAwMDAg
MHgwMDAyDQo+ID4gPiA+ID4gPiArCQkgICAgICAgMHgyIDB4MDAwMiAweDAwMDI+Ow0KPiA+ID4g
PiA+ID4gKwl9Ow0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gTm9kZSBuYW1lcyBzaG91bGQgYmUgZ2Vu
ZXJpYy4gIFdoYXQgZG9lcyBzc2QxMjg5IGRvPyAgSWYgdGhpcyBpcw0KPiA+ID4gPiA+IGFjdHVh
bGx5IHRoZSBkaXNwbGF5IGRldmljZSwgdGhlbiBpdCBzaG91bGQgYmUgY2FsbGVkDQo+ICJkaXNw
bGF5QDIsMCIuDQo+ID4gPiA+DQo+ID4gPiA+IE9LLiBUaGUgc3NkMTI4OSBpcyBhIExDRCBjb250
cm9sbGVyLg0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSG93IGFib3V0IGEgdmVuZG9y
IHByZWZpeCBvbiB0aGF0IGNvbXBhdGlibGU/ICBXaHkNCj4gPiA+ID4gPiAjYWRkcmVzcy1jZWxs
cy8jc2l6ZS0gY2VsbHMgZGVzcGl0ZSBubyBjaGlsZCBub2Rlcz8gIFdoZXJlIGlzIGENCj4gPiA+
ID4gPiBiaW5kaW5nIHRoYXQgc2F5cyB3aGF0IGVhY2ggb2YgdGhvc2UgdHdvIHJlZyByZXNvdXJj
ZXMgbWVhbj8NCj4gPiA+ID4NCj4gPiA+ID4gSSB3aWxsIGFkZCB0aGUgdmVuZG9yIHByZWZpeC4g
SSByZXZpZXcgdGhlIHNzZDEyODkgZHJpdmVyLCBhbmQgdGhlDQo+ID4gPiAjYWRkcmVzcy1jZWxs
cy8jc2l6ZS1jZWxscyB3ZXJlIHVuLXVzZWQuIEkgd2lsbCByZW1vdmUgdGhlbS4NCj4gPiA+DQo+
ID4gPiBBbmQgYSBiaW5kaW5nPw0KPiA+ID4NCj4gPiA+IFdoeSBkbyB5b3UgbmVlZCB0d28gc2Vw
YXJhdGUgcmVnIHJlc291cmNlcyByYXRoZXIgdGhhbiBqdXN0IDwyIDAgND4/DQo+ID4gPiBXaWxs
IHRoZXkgZXZlciBiZSBkaXNjb250aWd1b3VzPw0KPiA+DQo+ID4gW1hpZV0gSSByZXZpZXcgdGhl
IHNzZDEyODkgZHJpdmVyIGNvZGUsIGFuZCBmb3VuZCB0aGUgZHJpdmVyIG5lZWQgdHdvDQo+ID4g
cmVnIHJlc291cmNlcywNCj4gDQo+IFRoZSBkZXZpY2UgdHJlZSBkZXNjcmliZXMgdGhlIGhhcmR3
YXJlLCBub3QgdGhlIGN1cnJlbnQgc3RhdGUgb2YgTGludXgNCj4gZHJpdmVycy4gIEVzcGVjaWFs
bHkgZHJpdmVycyB0aGF0IGFyZW4ndCB5ZXQgaW4gTGludXguIDotKQ0KPiANCg0KT0ssIEkgd2ls
bCByZW1haW4gdGhlIGRpc3BsYXkgbm9kZS4NCg0KPiA+IGlmIGNoYW5nZSB0aGUgZHRzLCB0aGUg
ZHJpdmVyIGFsc28gc2hvdWxkIGJlIG1vZGlmaWVkIGFjY29yZGluZ2x5LiBTbw0KPiA+IEkgcmVt
b3ZlIHRoZSBzc2QxMjg5IG5vZGUgZnJvbSB0aGlzIHBhdGNoLiBJIHdpbGwgc3VibWl0IG5ldyBw
YXRjaA0KPiA+IGluY2x1ZGUgdGhlIGR0cyBtb2RpZmljYXRpb24sIHNzZDEyODkgZHJpdmVyIGFu
ZCB0aGUgYmluZGluZy4NCj4gDQo+IElkZWFsbHkgYWxsIGRldmljZXMgKGFuZCBiaW5kaW5ncykg
c2hvdWxkIGJlIGRlc2NyaWJlZCB3aGVuIHRoZSBkZXZpY2UNCj4gdHJlZSBpcyBpbml0YWxseSBh
ZGRlZCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHlvdSBoYXZlIGEgZHJpdmVyIHlldC4NCj4gDQog
DQpJIHdpbGwgYWRkIGEgYmluZGluZyBkb2N1bWVudCBmb3IgdGhlIHNzZDEyODkgZGV2aWNlLg0K
DQo+IC1TY290dA0KPiANCi0gWGlhb2JvDQo=
^ permalink raw reply
* [PATCH] powerpc/boot: Properly handle the base "of" boot wrapper
From: Benjamin Herrenschmidt @ 2013-11-06 3:09 UTC (permalink / raw)
To: linuxppc-dev
The wrapper script needs an explicit rule for the "of" boot
wrapper (generic wrapper, similar to pseries). Before
0c9fa29149d3726e14262aeb0c8461a948cc9d56 it was hanlded
implicitly by the statement:
platformo=$object/"$platform".o
But now that epapr.o needs to be added, that doesn't work
and an explicit rule must be added.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/boot/wrapper | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index ac16e99..2e1af74 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -147,6 +147,10 @@ link_address='0x400000'
make_space=y
case "$platform" in
+of)
+ platformo="$object/of.o $object/epapr.o"
+ make_space=n
+ ;;
pseries)
platformo="$object/of.o $object/epapr.o"
link_address='0x4000000'
^ permalink raw reply related
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-06 3:27 UTC (permalink / raw)
To: Timur Tabi, Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Huan Wang,
perex@perex.cz, Shawn Guo, LW@KARO-electronics.de,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, oskar@scara.com, Fabio Estevam,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, Zhengxiong Jin, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5278F1FA.1060706@tabi.org>
> > But fsl-ssi.o and fsl-spdif.o is based PowrePC platform? Which we can
> see from the comments.
>=20
> fsl_ssi was originally PPC-only, but it now supports PPC and ARM. You
> can see that from the git history.
>=20
> If there are any comments that say PPC but are not PPC-specific, that
> should be fixed.
Yes, find it.
The comments is in "sound/soc/fsl/Makefile" :
+++++++++++
"# Freescale PowerPC SSI/DMA Platform Support"
-----------
But fsl-spdif.o is also under it.
And this is also support ARM and PowerPC platforms at the same time ?
If so, the comments should be modified to :
+++++++++++
"# Freescale PowerPC and ARM SSI/DMA Platform Support"
-----------
Best Regards,
Xiubo
^ permalink raw reply
* Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Timur Tabi @ 2013-11-06 3:31 UTC (permalink / raw)
To: Li Xiubo, Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Huan Wang,
perex@perex.cz, Shawn Guo, LW@KARO-electronics.de,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, oskar@scara.com, Fabio Estevam,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, Zhengxiong Jin, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F82876A53@039-SN2MPN1-013.039d.mgd.msft.net>
Li Xiubo wrote:
>> If there are any comments that say PPC but are not PPC-specific, that
>> >should be fixed.
> Yes, find it.
>
> The comments is in "sound/soc/fsl/Makefile" :
> +++++++++++
> "# Freescale PowerPC SSI/DMA Platform Support"
> -----------
>
> But fsl-spdif.o is also under it.
> And this is also support ARM and PowerPC platforms at the same time ?
> If so, the comments should be modified to :
> +++++++++++
> "# Freescale PowerPC and ARM SSI/DMA Platform Support"
> -----------
Yes, this should be changed.
^ permalink raw reply
* Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
From: Alistair Popple @ 2013-11-06 3:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-usb, Alan Stern
In-Reply-To: <1383681133.4776.95.camel@pasglop>
On Wed, 6 Nov 2013 06:52:13 Benjamin Herrenschmidt wrote:
[snip]
>
> Why ? Do we need to add an entry for every platform in there ? Besides,
> it probably should be the SoC name not the platform here....
>
> Why not simply a generic compatible "usb-ehci" ? It's a standard
> programming interface, there are no specific quirks, we shouldn't
> need to have to add new entries to the driver like that for every
> new SoC/platform.
>
Actually a grep of "usb-ehci" turns up the ehci-ppc-of driver which I somehow
missed. This driver works and uses .compatible = "usb-ehci" so I can use that
instead if that is preferable?
However it is basically the same as the ehci-platform driver so I guess at
some point the two should be merged...
> > > @@ -229,7 +230,7 @@ static struct platform_driver ehci_platform_driver =
> > > {
> > >
> > > .owner = THIS_MODULE,
> > > .name = "ehci-platform",
> > > .pm = &ehci_platform_pm_ops,
> > >
> > > - .of_match_table = vt8500_ehci_ids,
> > > + .of_match_table = ehci_platform_ids,
> > >
> > > }
> > >
> > > };
> >
> > Acked-by: Alan Stern <stern@rowland.harvard.edu>
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-06 3:53 UTC (permalink / raw)
To: Timur Tabi, Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Huan Wang,
perex@perex.cz, Shawn Guo, LW@KARO-electronics.de,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, oskar@scara.com, Fabio Estevam,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, Zhengxiong Jin, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5279B822.9010401@tabi.org>
> >> If there are any comments that say PPC but are not PPC-specific, that
> >> >should be fixed.
> > Yes, find it.
> >
> > The comments is in "sound/soc/fsl/Makefile" :
> > +++++++++++
> > "# Freescale PowerPC SSI/DMA Platform Support"
> > -----------
> >
> > But fsl-spdif.o is also under it.
> > And this is also support ARM and PowerPC platforms at the same time ?
> > If so, the comments should be modified to :
> > +++++++++++
> > "# Freescale PowerPC and ARM SSI/DMA Platform Support"
> > -----------
>=20
> Yes, this should be changed.
>=20
How about :
+++++++++
"# Freescale PowerPC and ARM SSI/DMA/SAI/SPDIF Platform Support"=09
---------
?
^ permalink raw reply
* Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
From: Benjamin Herrenschmidt @ 2013-11-06 3:58 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, linux-usb, Alan Stern
In-Reply-To: <2440701.siW6M1PPWz@mexican>
On Wed, 2013-11-06 at 14:50 +1100, Alistair Popple wrote:
> Actually a grep of "usb-ehci" turns up the ehci-ppc-of driver which I somehow
> missed. This driver works and uses .compatible = "usb-ehci" so I can use that
> instead if that is preferable?
>
> However it is basically the same as the ehci-platform driver so I guess at
> some point the two should be merged...
I think the split predates the grand unification of "of" driver and platform,
so yes they should.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/kvm: simplify the entering logic for secondary thread
From: Paul Mackerras @ 2013-11-06 5:01 UTC (permalink / raw)
To: Liu Ping Fan; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <1383637364-14691-1-git-send-email-pingfank@linux.vnet.ibm.com>
On Tue, Nov 05, 2013 at 03:42:42PM +0800, Liu Ping Fan wrote:
> After the primary vcpu changes vcore_state to VCORE_RUNNING, there is
> very little chance to schedule to secondary vcpu. So if we change the
Why do you say there is very little chance to run the secondary vcpu?
> code sequence around set vcore_state to VCORE_RUNNING and disable
> preemption, we lost little. But we simplify the entering logi, based on
> the fact that if primary vcpu runs, the secondary vcpu can not be scheduled.
If a vcpu does a hypercall or something else that requires the host
(kernel or userspace) to do something, that can happen in the context
of the vcpu task for that vcpu. That vcpu task can run on another
core (unless it has been pinned). When it is finished we would like
the vcpu to continue executing in the guest as soon as possible. The
code that you remove in this patch enables that to happen without
having to wait until the other threads exit the guest. So I don't
think it is a good idea to remove this code.
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/kvm: fix rare but potential deadlock scene
From: Paul Mackerras @ 2013-11-06 5:04 UTC (permalink / raw)
To: Liu Ping Fan; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <1383637364-14691-2-git-send-email-pingfank@linux.vnet.ibm.com>
On Tue, Nov 05, 2013 at 03:42:43PM +0800, Liu Ping Fan wrote:
> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
> realmode, so it can trigger the deadlock.
Good catch, we should have preemption disabled while ever we have a
HPTE locked.
> @@ -474,8 +474,10 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu *vcpu, gva_t eaddr,
> }
>
> /* Find the HPTE in the hash table */
> + preempt_disable();
> index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v,
> HPTE_V_VALID | HPTE_V_ABSENT);
> + preempt_enable();
Which means we need to add the preempt_enable after unlocking the
HPTE, not here.
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/kvm: remove redundant assignment
From: Paul Mackerras @ 2013-11-06 5:04 UTC (permalink / raw)
To: Liu Ping Fan; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <1383637364-14691-3-git-send-email-pingfank@linux.vnet.ibm.com>
On Tue, Nov 05, 2013 at 03:42:44PM +0800, Liu Ping Fan wrote:
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 28160ac..7682837 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -731,7 +731,6 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct kvm_vcpu *vcpu,
> lock_rmap(rmap);
>
> /* Check if we might have been invalidated; let the guest retry if so */
> - ret = RESUME_GUEST;
> if (mmu_notifier_retry(vcpu->kvm, mmu_seq)) {
> unlock_rmap(rmap);
> goto out_unlock;
Acked-by: Paul Mackerras <paulus@samba.org>
^ 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