* [PATCH 1/2] net: arc_emac: annonce IFF_MULTICAST support
From: Alexander Kochetkov @ 2016-11-14 13:20 UTC (permalink / raw)
To: netdev, linux-kernel, davem, tremyfr, peter.chen, wxt, weiyj.lk
Cc: Alexander Kochetkov
Multicast support was implemented by commit 775dd682e2b0ec7
('arc_emac: implement promiscuous mode and multicast filtering').
It can be enabled explicity using 'ifconfig eth0 multicast'.
The patch is needed in order to remove explicit configuration
as most devices has multicast mode enabled by default.
---
drivers/net/ethernet/arc/emac_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index b0da969..2e4ee86 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -764,8 +764,6 @@ int arc_emac_probe(struct net_device *ndev, int interface)
ndev->netdev_ops = &arc_emac_netdev_ops;
ndev->ethtool_ops = &arc_emac_ethtool_ops;
ndev->watchdog_timeo = TX_TIMEOUT;
- /* FIXME :: no multicast support yet */
- ndev->flags &= ~IFF_MULTICAST;
priv = netdev_priv(ndev);
priv->dev = dev;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] net: arc_emac: don't pass multicast packets to kernel in non-multicast mode
From: Alexander Kochetkov @ 2016-11-14 13:20 UTC (permalink / raw)
To: netdev, linux-kernel, davem, tremyfr, peter.chen, wxt, weiyj.lk
Cc: Alexander Kochetkov
In-Reply-To: <1479129627-27524-1-git-send-email-al.kochet@gmail.com>
The patch disable capturing multicast packets when multicast mode
disabled for ethernet ('ifconfig eth0 -multicast'). In that case
no multicast packet will be passed to kernel.
---
drivers/net/ethernet/arc/emac_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 2e4ee86..30ad833 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -460,7 +460,7 @@ static void arc_emac_set_rx_mode(struct net_device *ndev)
if (ndev->flags & IFF_ALLMULTI) {
arc_reg_set(priv, R_LAFL, ~0);
arc_reg_set(priv, R_LAFH, ~0);
- } else {
+ } else if (ndev->flags & IFF_MULTICAST) {
struct netdev_hw_addr *ha;
unsigned int filter[2] = { 0, 0 };
int bit;
@@ -469,9 +469,11 @@ static void arc_emac_set_rx_mode(struct net_device *ndev)
bit = ether_crc_le(ETH_ALEN, ha->addr) >> 26;
filter[bit >> 5] |= 1 << (bit & 31);
}
-
arc_reg_set(priv, R_LAFL, filter[0]);
arc_reg_set(priv, R_LAFH, filter[1]);
+ } else {
+ arc_reg_set(priv, R_LAFL, 0);
+ arc_reg_set(priv, R_LAFH, 0);
}
}
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] NVMe: Call nvme_pci_disable on error path of nvme_probe_work
From: Gabriel Krisman Bertazi @ 2016-11-14 13:21 UTC (permalink / raw)
In-Reply-To: <62459369-5c23-8819-d360-58892b4ff1fc@amazon.com>
Rashika Kheria <rashika at amazon.com> writes:
> Hi everyone,
>
> Could you please review the following patch? This solves a regression in
> stable 4.4.y tree.
>
>
> On 11/12/16 18:41, Christoph Hellwig wrote:
>> Bouncing to Keith and linux-nvme
>>
>> On Tue, Nov 01, 2016@04:27:56PM +0100, Rashika Kheria wrote:
>>> Commit d5537e988eec ("NVMe: Don't unmap controller registers on reset"),
>>> introduced a regression in which it did not replace nvme_dev_unmap()
>>> with nvme_pci_disable() in the error path of nvme_probe_work().
>>>
Hmm, the original commit had the same issue, which I think was fixed
upstream by f58944e265d4 ("NVMe: Simplify device reset failure"), which
was included in 4.5-rc7. Isn't the upstream commit a better candidate
for -stable? It's a bit larger but the commit message says it may
prevent other issues too.
--
Gabriel Krisman Bertazi
^ permalink raw reply
* Re: [RFC][PATCH 2/2] fsnotify: handle permission events without holding fsnotify_mark_srcu[0]
From: Jan Kara @ 2016-11-14 13:20 UTC (permalink / raw)
To: Amir Goldstein
Cc: Jan Kara, Jeff Layton, Miklos Szeredi, Eric Paris, Eryu Guan,
linux-kernel, linux-fsdevel
In-Reply-To: <1479124107-8477-3-git-send-email-amir73il@gmail.com>
On Mon 14-11-16 13:48:27, Amir Goldstein wrote:
> Handling fanotify events does not entail dereferencing fsnotify_mark
> beyond the point of fanotify_should_send_event().
>
> For the case of permission events, which may block indefinitely,
> return -EAGAIN and then fsnotify() will call handle_event() again
> without a reference to the mark.
>
> Without a reference to the mark, there is no need to call
> handle_event() under fsnotify_mark_srcu[0] read side lock,
> so we drop fsnotify_mark_srcu[0] while handling the event
> and grab it back before continuing to the next mark.
>
> After this change, a blocking permission event will no longer
> block closing of any file descriptors of 0 priority groups,
> i.e: inotify and fanotify groups of class FAN_CLASS_NOTIF.
>
> Reported-by: Miklos Szeredi <miklos@szeredi.hu>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Well, this has a similar problem as my attempt to fix the issue. The
current mark can get removed from the mark list while waiting for userspace
response. ->next pointer is still valid at that moment but ->next->pprev
already points to mark preceding us (that's how rcu lists work). When
->next mark then gets removed from the list and destroyed (it may be
protected by the second srcu), our ->next pointer points to freed memory.
Furthermore I don't like the scheme of ->handle_event returning -EAGAIN and
then dropping the srcu lock - I'd rather have some helpers provided by the
generic fsnotify code to drop srcu lock. That needs some propagation of
information inside the ->handle_event and then the helper but that's IMO
cleaner. Anyway, that is just a technical detail.
I have some ideas how to fix up issues with my refcounting approach -
refcount would pin marks not only in memory but also in lists but I have
yet to see whether that works out sensibly (it would mean that dropping
mark reference would then need to take group->mark_mutex and that may cause
lock ordering issues).
Honza
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index e0e5f7c..c7689ad 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -176,7 +176,7 @@ init: __maybe_unused
> static int fanotify_handle_event(struct fsnotify_group *group,
> struct inode *inode,
> struct fsnotify_mark *inode_mark,
> - struct fsnotify_mark *fanotify_mark,
> + struct fsnotify_mark *vfsmnt_mark,
> u32 mask, void *data, int data_type,
> const unsigned char *file_name, u32 cookie)
> {
> @@ -195,9 +195,16 @@ static int fanotify_handle_event(struct fsnotify_group *group,
> BUILD_BUG_ON(FAN_ACCESS_PERM != FS_ACCESS_PERM);
> BUILD_BUG_ON(FAN_ONDIR != FS_ISDIR);
>
> - if (!fanotify_should_send_event(inode_mark, fanotify_mark, mask, data,
> - data_type))
> - return 0;
> + if (inode_mark || vfsmnt_mark) {
> + if (!fanotify_should_send_event(inode_mark, vfsmnt_mark, mask,
> + data, data_type))
> + return 0;
> +#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
> + /* Ask to be called again without a reference to mark */
> + if (mask & FAN_ALL_PERM_EVENTS)
> + return -EAGAIN;
> +#endif
> + }
>
> pr_debug("%s: group=%p inode=%p mask=%x\n", __func__, group, inode,
> mask);
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index af5c523a..5b9a248 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -291,6 +291,29 @@ int fsnotify(struct inode *to_tell, __u32 mask, void *data, int data_is,
> ret = send_to_group(to_tell, inode_mark, vfsmount_mark, mask,
> data, data_is, cookie, file_name);
>
> + /*
> + * If handle_event() is going to block, we call it again
> + * witout holding fsnotify_mark_srcu[0], which is protecting
> + * the low priority mark lists.
> + * We are still holding fsnotify_mark_srcu[1], which
> + * is protecting the high priority marks in the first half
> + * of the mark list, which is where we are at.
> + */
> + if (group->priority > 0 && ret == -EAGAIN) {
> + srcu_read_unlock(&fsnotify_mark_srcu[0], idx);
> +
> + ret = group->ops->handle_event(group, to_tell,
> + NULL, NULL,
> + mask, data, data_is,
> + file_name, cookie);
> +
> + /*
> + * We need to hold fsnotify_mark_srcu[0], because
> + * next mark may be low priority.
> + */
> + idx = srcu_read_lock(&fsnotify_mark_srcu[0]);
> + }
> +
> if (ret && (mask & ALL_FSNOTIFY_PERM_EVENTS))
> goto out;
>
> --
> 2.7.4
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-14 13:10 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, Icenowy Zheng, Jonathan Corbet, Rob Herring,
Mark Rutland, Russell King, linux-doc@vger.kernel.org,
linux-arm-kernel, linux-kernel, devicetree, linux-sunxi
In-Reply-To: <cbbf8ae1-ff29-2a83-265b-a9ff5bacf97b@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]
On Mon, Nov 14, 2016 at 11:00:32AM +0100, Hans de Goede wrote:
> > > > +&usbphy {
> > > > + /* USB VBUS is always on */
> > >
> > > You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
> >
> > AFAIK the regulator properties are optional the the USB PHY.
> > So we probably don't need to add it. Hans (CC-ed) could explain
> > his original intent?
>
> I've made the regulators optional exactly for boards like these,
> where there is no regulator. Likely the Vbus is simply wired
> directly to the 5V DC-in jack. So IMHO adding something like
> the fixed reg_vcc5v0 a supply here just makes the dt
> harder to read.
It also makes the regulator tree more complete and accurate because
you'd list all the devices that are needing those regulators. That
would also make it easier to deal with in the future.
But fair enough.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 13:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: geert+renesas, vireshk, magnus.damm, linux-kernel,
Krzysztof Kozlowski, Russell King, rmk+kernel, horms,
thomas.ab@samsung.com, shiraz.linux.kernel,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <3587281.4kOCcW9Ryd@wuerfel>
Hi Arnd,
On 14 November 2016 at 17:26, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
>> static const struct of_device_id realview_scu_match[] = {
>> { .compatible = "arm,arm11mp-scu", },
>> - { .compatible = "arm,cortex-a9-scu", },
>> - { .compatible = "arm,cortex-a5-scu", },
>> { }
>> };
>>
>> @@ -41,27 +39,18 @@ static void __init realview_smp_prepare_cpus(unsigned int max_cpus)
>> struct device_node *np;
>> void __iomem *scu_base;
>> struct regmap *map;
>> - unsigned int ncores;
>> int i;
>>
>> - np = of_find_matching_node(NULL, realview_scu_match);
>> - if (!np) {
>> - pr_err("PLATSMP: No SCU base address\n");
>> - return;
>> + if (of_scu_enable()) {
>> + np = of_find_matching_node(NULL, realview_scu_match);
>> + scu_base = of_iomap(np, 0);
>> + of_node_put(np);
>> + if (!scu_base) {
>> + pr_err("PLATSMP: No SCU remap\n");
>> + return;
>> + }
>> + scu_enable(scu_base);
>> }
>>
>
> The only difference here seems to be that realview also needs to handle
> "arm,arm11mp-scu". Why not move that into the generic implementation?
>
Just checked scu binding documentation for "arm,arm11mp-scu" and came
to know its for ARM11 MPCore based SoC's SCU. So as you said, it can
surely be moved to genenric imeplemenation. Will do this change and
resubmit again.
Thanks,
Pankaj Dubey
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3587281.4kOCcW9Ryd@wuerfel>
Hi Arnd,
On 14 November 2016 at 17:26, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
>> static const struct of_device_id realview_scu_match[] = {
>> { .compatible = "arm,arm11mp-scu", },
>> - { .compatible = "arm,cortex-a9-scu", },
>> - { .compatible = "arm,cortex-a5-scu", },
>> { }
>> };
>>
>> @@ -41,27 +39,18 @@ static void __init realview_smp_prepare_cpus(unsigned int max_cpus)
>> struct device_node *np;
>> void __iomem *scu_base;
>> struct regmap *map;
>> - unsigned int ncores;
>> int i;
>>
>> - np = of_find_matching_node(NULL, realview_scu_match);
>> - if (!np) {
>> - pr_err("PLATSMP: No SCU base address\n");
>> - return;
>> + if (of_scu_enable()) {
>> + np = of_find_matching_node(NULL, realview_scu_match);
>> + scu_base = of_iomap(np, 0);
>> + of_node_put(np);
>> + if (!scu_base) {
>> + pr_err("PLATSMP: No SCU remap\n");
>> + return;
>> + }
>> + scu_enable(scu_base);
>> }
>>
>
> The only difference here seems to be that realview also needs to handle
> "arm,arm11mp-scu". Why not move that into the generic implementation?
>
Just checked scu binding documentation for "arm,arm11mp-scu" and came
to know its for ARM11 MPCore based SoC's SCU. So as you said, it can
surely be moved to genenric imeplemenation. Will do this change and
resubmit again.
Thanks,
Pankaj Dubey
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Tegra baseline test results for v4.9-rc5
From: Jon Hunter @ 2016-11-14 13:19 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9-rc5.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc5/20161114020102/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc4 (bc33b0ca11e3df467777a4fa7639ba488c9d4911)):
text data bss total kernel
-1032 -2736 0 -3768 defconfig
+1056 -8 0 +1048 multi_v7_defconfig
+688 -4104 0 -3416 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc4 (bc33b0ca11e3df467777a4fa7639ba488c9d4911))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* Tegra baseline test results for v4.9-rc5
From: Jon Hunter @ 2016-11-14 13:19 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: kernel-build-reports-cunTk1MwBs8s++Sfvej+rw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Here are some basic Tegra test results for Linux v4.9-rc5.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc5/20161114020102/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc4 (bc33b0ca11e3df467777a4fa7639ba488c9d4911)):
text data bss total kernel
-1032 -2736 0 -3768 defconfig
+1056 -8 0 +1048 multi_v7_defconfig
+688 -4104 0 -3416 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc4 (bc33b0ca11e3df467777a4fa7639ba488c9d4911))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* Re: [PATCH] pinctrl: amd: Add support for additional GPIO
From: Linus Walleij @ 2016-11-14 13:18 UTC (permalink / raw)
To: Shah, Nehal-bakulchandra
Cc: gnurou@gmail.com, linux-gpio@vger.kernel.org, S-k, Shyam-sundar
In-Reply-To: <MWHPR12MB1357C965EBE3F1161823C223A0B90@MWHPR12MB1357.namprd12.prod.outlook.com>
On Wed, Nov 9, 2016 at 11:28 AM, Shah, Nehal-bakulchandra
<Nehal-bakulchandra.Shah@amd.com> wrote:
> This Provide IRQ sharing for AMD's GPIO devices.And set IRQCHIP_SKIP_SET_WAKE flag.
>
> Also, fix the build issue for devm_request_irq()
>
> Reviewed-by: S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com>
> Signed-off-by: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
This is not looking correct at all.
> @@ -529,16 +531,13 @@ static void amd_gpio_irq_handler(struct irq_desc *desc)
> }
> }
>
> - if (handled == 0)
> - handle_bad_irq(desc);
> -
> spin_lock_irqsave(&gpio_dev->lock, flags);
> reg = readl(gpio_dev->base + WAKE_INT_MASTER_REG);
> reg |= EOI_MASK;
> writel(reg, gpio_dev->base + WAKE_INT_MASTER_REG);
> spin_unlock_irqrestore(&gpio_dev->lock, flags);
>
> - chained_irq_exit(chip, desc);
> + return 0;
You are removing the chained interrupt handling for no good reason.
The commit message does not say why this is being done.
It's especially erroneous to remove chained_irq_exit() but not
chained_irq_enter(), but generally, NONE of them should be
removed this *is* a chained interrupt handler.
> gpiochip_set_chained_irqchip(&gpio_dev->gc,
> &amd_gpio_irqchip,
> irq_base,
> - amd_gpio_irq_handler);
> + NULL);
> +
> + ret = devm_request_irq(&pdev->dev, irq_base, amd_gpio_irq_handler,
> + IRQF_SHARED, dev_name(&pdev->dev), gpio_dev);
> + if (ret)
> + goto out2;
This is just wrong. The gpiochip_set_chained_irqchip() should not
be called in combination with devm_request_irq() like this.
devm_request_irq() should not be used at all. Keep the chained
handler.
I'm worried that this patch has a "trial-and-error" quality, it seems
you don't really know what is going on.
Please investigate and send the patch with a commitlog that describes
exactly why you are doing what you are doing.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH for-4.8 2/2] x86/traps: Don't call hvm_hypervisor_cpuid_leaf() for PV guests
From: Andrew Cooper @ 2016-11-14 13:18 UTC (permalink / raw)
To: Jan Beulich; +Cc: Wei Liu, Xen-devel
In-Reply-To: <5829B03F020000780011E661@prv-mh.provo.novell.com>
On 14/11/16 11:38, Jan Beulich wrote:
>>>> On 14.11.16 at 12:01, <andrew.cooper3@citrix.com> wrote:
>> Luckily, hvm_hypervisor_cpuid_leaf() and vmx_hypervisor_cpuid_leaf() are safe
>> to execute in the context of a PV guest, but HVM-specific feature flags
>> shouldn't be visible to PV guests.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> albeit ...
>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -928,6 +928,11 @@ int cpuid_hypervisor_leaves( uint32_t idx, uint32_t sub_idx,
>> break;
>>
>> case 4:
>> + if ( !has_hvm_container_domain(currd) )
>> + {
>> + *eax = *ebx = *ecx = *edx = 0;
>> + break;
>> + }
>> hvm_hypervisor_cpuid_leaf(sub_idx, eax, ebx, ecx, edx);
>> break;
> ... this being the last leaf, wouldn't we better limit the number of
> leaves (reported in leaf 0) to 3 for PV?
I considered this, but decided not to.
The current max leaf handling is fragile, owing to some dubious control
from the toolstack, and the existence of XEN_CPUID_MAX_NUM_LEAVES in the
public API is absolutely broken.
I am going to need to rework this all anyway, and its not clear whether
we can/should report less than 4 leaves to PV guests.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: Is Documentation/networking/phy.txt still up-to-date?
From: Sebastian Frias @ 2016-11-14 13:18 UTC (permalink / raw)
To: Florian Fainelli, afleming, jgarzik, Måns Rullgård
Cc: netdev, LKML, David S. Miller, Mason
In-Reply-To: <24676d24-5b07-7d26-6ffa-14e857960a52@gmail.com>
On 11/09/2016 06:07 PM, Florian Fainelli wrote:
> On 11/09/2016 05:24 AM, Sebastian Frias wrote:
>> Hi,
>>
>> Documentation/networking/phy.txt discusses phy_connect and states that:
>>
>> "...
>>
>> interface is a u32 which specifies the connection type used
>> between the controller and the PHY. Examples are GMII, MII,
>> RGMII, and SGMII. For a full list, see include/linux/phy.h
>>
>> Now just make sure that phydev->supported and phydev->advertising have any
>> values pruned from them which don't make sense for your controller (a 10/100
>> controller may be connected to a gigabit capable PHY, so you would need to
>> mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions
>> for these bitfields. Note that you should not SET any bits, or the PHY may
>> get put into an unsupported state.
>>
>> ..."
>>
>> However, 'drivers/net/ethernet/aurora/nb8800.c' for example, does SETs some
>> bits (in function 'nb8800_pause_adv').
>
> All pause/flow control related bits should be set by the Ethernet MAC
> driver because this is an Ethernet MAC, not PHY, thing. See this
> discussion for some details:
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg135347.html
>
> So the nb8800 drivers does the correct thing here, but the documentation
> should be updated to reflect that this applies to all bits, except the
> Pause capabilities because these need to come from the Ethernet MAC.
>
Ok, thanks.
>>
>> I checked 'drivers/net/ethernet/broadcom/genet/bcmmii.c' and that one CLEARs
>> bits (as per the documentation).
>>
>> Does anybody knows what is the correct/recommended approach?
>
> Both drivers do correct things, they just don't set the same things here.
>
Thanks!
^ permalink raw reply
* Re: [RFC 05/14] SoundWire: Add SoundWire bus driver interfaces
From: Mark Brown @ 2016-11-14 13:17 UTC (permalink / raw)
To: Hardik Shah
Cc: alsa-devel, linux-kernel, tiwai, pierre-louis.bossart, lgirdwood,
plai, patches.audio, Sanyog Kale
In-Reply-To: <1477053673-16021-6-git-send-email-hardik.t.shah@intel.com>
[-- Attachment #1: Type: text/plain, Size: 8831 bytes --]
On Fri, Oct 21, 2016 at 06:11:03PM +0530, Hardik Shah wrote:
> This patch adds the SoundWire bus driver interfaces for following.
>
> 1. APIs to register/unregister SoundWire Master device and driver.
> 2. APIs to register/unregister SoundWire Slave driver.
> 3. API to Read/Write Slave registers.
> 4. API for Master driver to update Slave status to bus driver.
> 5. APIs for Master driver to prepare and initiate clock stop.
> 6. APIs for SoundWire stream configuration.
> 7. APIs to prepare, enable, deprepare and disable SoundWire stream.
This is a very large patch (85K, 2000 lines) and the changelog is just a
long list of different things being added. This suggests that you could
easily split the patch up along the lines you've given above which would
make it a lot more digestable, as it is it's really hard to review. It
is also very hard to review because it's pure header, there's none of
the implementation in here, which makes it hard to see how things are
going to be used.
At a very high level this doesn't look or feel like normal Linux code,
there's some obvious coding style stuff, a bunch of things that look
like this was copied from legacy code and perhaps most worryingly all
the stuff about a "bus driver" which doesn't seem to fit with the normal
Linux models at all.
> +/**
> + * sdw_slave_addr: Structure representing the read-only unique device ID
> + * and the SoundWire logical device number (assigned by bus driver).
With the name of this structure I was expecting it to represent an
address in the same way that an in_addr is an IP address but really it's
a bundle of several different addresses and runtime state associated
with them. This is going to cause confusion I imagine, it seems better
to rename it or bundle it into the slave struct.
> +/**
> + * sdw_dpn_caps: Capabilities of the Data Port, other than Data Port 0 for
> + * SoundWire Master and Slave. This follows the definitions in the
Why not just _dp_caps?
> + * @max_bps: Maximum bits per sample supported by Port. This is same as word
> + * length in SoundWire Spec.
Might be better to rename all these _bps variables to _wl or something -
bps looks like bits per second which is going to confuse people.
> +/**
> + * sdw_prepare_ch: Prepare/De-prepare the Data Port channel. This is similar
> + * to the prepare API of Alsa, where most of the hardware interfaces
> + * are prepared for the playback/capture to start. All the parameters
> + * are known to the hardware at this point for starting
> + * playback/capture next.
This is information used for preparing or depreparing, the description
reads like this is a function.
> + * @num: Port number.
> + * @ch_mask: Channels to be prepared/deprepared specified by ch_mask.
> + * @prepare: Prepare/de-prepare channel, true (prepare) or false
> + * (de-prepare).
Do actual implementations look like something other than an if
statement with two unrelated halves?
> + * @bank: Register bank, which bank Slave/Master driver should program for
> + * implementation defined registers. This is the inverted value of the
> + * current bank.
If this is the inverted value of the current bank should we not just
look at the current bank?
> + * @r_w_flag: Read/Write operation. Read(0) or Write(1) based on above #def
Which above #define? (please write out #define fully too). I'm also
noticing lots of random capitalisation in the comments in this patch.
> +/**
> + * sdw_msg: Message to be sent on bus. This is similar to i2c_msg on I2C
> + * bus. Message is sent from the bus driver to the Slave device. Slave
> + * driver can also initiate transfer of the message to program
> + * implementation defined registers. Message is formatted and
> + * transmitted on to the bus by Master interface in hardware-specific
> + * way. Bus driver initiates the Master interface callback to transmit
> + * the message on bus.
> + *
> + * @addr: Address of the register to be read.
Only reads?
> + * @frame_rate: Audio frame rate of the stream (not the bus frame rate
> + * defining command bandwidth).
In units of...?
> +/**
> + * snd_sdw_alloc_stream_tag: Allocates unique stream_tag. Stream tag is
> + * a unique identifier for each SoundWire stream across all SoundWire
> + * bus instances. Stream tag is a software concept defined by bus
> + * driver for stream management and not by MIPI SoundWire Spec. Each
> + * SoundWire Stream is individually configured and controlled using the
> + * stream tag. Multiple Master(s) and Slave(s) associated with the
> + * stream, uses stream tag as an identifier. All the operations on the
> + * stream e.g. stream configuration, port configuration, prepare and
> + * enable of the ports are done based on stream tag. This API shall be
> + * called once per SoundWire stream either by the Master or Slave
> + * associated with the stream.
> + *
> + * @stream_tag: Stream tag returned by bus driver.
> + */
> +int snd_sdw_alloc_stream_tag(unsigned int *stream_tag);
In Linux we put documentation for functions next to their
implementation not their prototype. This also doesn't look like good
kerneldoc - normally we'd have a separate paragraph for the summary.
This sort of stylistic stuff is important not just for itself but also
because it's a warning sign that the code hasn't been written by someone
who's really familiar with how things are expected to look and work in
terms of the kernel internal abstractions.
> + * @slv_list: List of SoundWire Slaves registered to the bus.
The driver model already maintains a list of devices on a bus, why are
we maintaining a separate one?
> + * @sdw_addr: Array containing Slave SoundWire bus Slave address
> + * information. Its a part of Slave list as well, but for easier access
> + * its part of array to find the Slave reference by directly indexing
> + * the Slave number into the array.
This seems like a worrying idea... I'd be entirely unsurprised if this
cache went wrong, are we sure we need the optimisation?
> + * @num_slv: Number of SoundWire Slaves assigned DeviceNumber after
> + * enumeration. The SoundWire specification does not place a
> + * restriction on how many Slaves are physically connected, as long as
> + * only 11 are active concurrently. This bus driver adds a pragmatic
> + * restriction to 11 Slaves, the current implementation assigns a
> + * DeviceNumber once and will never use the same DeviceNumber for
> + * different devices.
This is not a driver, it is a bus. Please do not refer to it as a
driver, that's at best confusing and at worst worrying. It's also
unclear why we're maintaining this count separately to the driver model.
> + char name[SOUNDWIRE_NAME_SIZE];
> + struct sdw_slave_addr sdw_addr[SDW_MAX_DEVICES];
Best to use SDW_ consistently.
> +/**
> + * sdw_master_driver: Manage SoundWire Master device driver.
> + *
> + * @driver_type: To distinguish between Master and Slave driver. This should
> + * be set by driver based on its handling Slave or Master SoundWire
> + * interface.
> + *
> + * @probe: Binds this driver to a SoundWire Master.
> + * @remove: Unbinds this driver from the SoundWire Master.
> + * @shutdown: Standard shutdown callback used during power down/halt.
> + * @suspend: Standard suspend callback used during system suspend
> + * @resume: Standard resume callback used during system resume
Modern buses have moved to using dev_pm_ops which enables them to use a
lot of generic code for power management implementation.
> + * @driver: SoundWire device drivers should initialize name and owner field
> + * of this structure.
Initializing .owner shouldn't be required with kernels from the past few
years.
> +/**
> + * snd_sdw_master_get: Return the Master handle from Master number.
> + * Increments the reference count of the module. Similar to
> + * i2c_get_adapter.
> + *
> + * @nr: Master number.
> + *
> + * Returns Master handle on success, else NULL
> + */
> +struct sdw_master *snd_sdw_master_get(int nr);
This is a legacy interface for I2C, why are we adding it for a new bus?
> + * @portn_mask: Implementation defined mask for Slave Ports other than port0.
> + * Mask bits are exactly same as defined in MIPI Spec 1.1. Array size
> + * shall be same as number of Ports in Slave. For bidirectional ports,
> + * masks can be different for Source and Sink ports.
Is this implementation defined or spec defined? It's really non-obvious
what these implementation defined things actually mean or do.
> +struct sdw_slave {
> + struct device dev;
> + struct sdw_master *mstr;
Why do we have a direct reference to the master here? Shouldn't this
just be the parent of the device?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [Buildroot] [PATCH next v2] cmake: bump version to 3.7.0
From: Vicente Olivert Riera @ 2016-11-14 13:15 UTC (permalink / raw)
To: buildroot
libuv is now a required dependency.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
Changes v1 -> v2:
- Do not say that !BR2_STATIC_LIBS dependency is there only because libuv
---
package/cmake/Config.in | 9 +++++++--
package/cmake/cmake.hash | 4 ++--
package/cmake/cmake.mk | 6 +++---
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/package/cmake/Config.in b/package/cmake/Config.in
index 6f04a4a..716d80e 100644
--- a/package/cmake/Config.in
+++ b/package/cmake/Config.in
@@ -20,11 +20,14 @@ config BR2_PACKAGE_CMAKE_CTEST
select BR2_PACKAGE_EXPAT
select BR2_PACKAGE_BZIP2
select BR2_PACKAGE_XZ
+ select BR2_PACKAGE_LIBUV
depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 # from jsoncpp
depends on BR2_USE_WCHAR # libarchive
depends on BR2_INSTALL_LIBSTDCPP
depends on !BR2_STATIC_LIBS
+ depends on BR2_TOOLCHAIN_HAS_THREADS # libuv
+ depends on BR2_USE_MMU # libuv
help
CTest is a testing tool distributed as a part of CMake. It
can be used to automate updating (using CVS for example),
@@ -34,7 +37,9 @@ config BR2_PACKAGE_CMAKE_CTEST
http://www.cmake.org/
-comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7"
+comment "ctest needs a toolchain w/ C++, wchar, dynamic library, gcc >= 4.7, threads"
depends on BR2_PACKAGE_CMAKE_ARCH_SUPPORTS
+ depends on BR2_USE_MMU
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
- BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
+ BR2_STATIC_LIBS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 || \
+ !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash
index f846dc9..687e5a4 100644
--- a/package/cmake/cmake.hash
+++ b/package/cmake/cmake.hash
@@ -1,2 +1,2 @@
-# From http://www.cmake.org/files/v3.6/cmake-3.6.3-SHA-256.txt
-sha256 7d73ee4fae572eb2d7cd3feb48971aea903bb30a20ea5ae8b4da826d8ccad5fe cmake-3.6.3.tar.gz
+# From http://www.cmake.org/files/v3.7/cmake-3.7.0-SHA-256.txt
+sha256 ed63e05c41aeb6c036e503114ab15847f29c312f9f21f5f1a7060a4b4ec2fb31 cmake-3.7.0.tar.gz
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index fadb09e..522d7fe 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -4,8 +4,8 @@
#
################################################################################
-CMAKE_VERSION_MAJOR = 3.6
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3
+CMAKE_VERSION_MAJOR = 3.7
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).0
CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
CMAKE_LICENSE = BSD-3c
CMAKE_LICENSE_FILES = Copyright.txt
@@ -22,7 +22,7 @@ CMAKE_LICENSE_FILES = Copyright.txt
# the system-wide libraries instead of rebuilding and statically
# linking with the ones bundled into the CMake sources.
-CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz
+CMAKE_DEPENDENCIES = zlib jsoncpp libcurl libarchive expat bzip2 xz libuv
CMAKE_CONF_OPTS = \
-DKWSYS_LFS_WORKS=TRUE \
--
2.10.1
^ permalink raw reply related
* [PATCH] [media] gp8psk-fe: add missing MODULE_foo() macros
From: Mauro Carvalho Chehab @ 2016-11-14 13:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Rothwell, linux-next, linux-kernel
This file was converted to a separate module at commit
7a0786c19d65 ("gp8psk: Fix DVB frontend attach"), because
the DVB attach routines require it to work. However,
I forgot to copy the MODULE_foo() macros from the original
module, causing this warning:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/dvb-frontends/gp8psk-fe.o
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 7a0786c19d65 ("gp8psk: Fix DVB frontend attach")
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/drivers/media/dvb-frontends/gp8psk-fe.c b/drivers/media/dvb-frontends/gp8psk-fe.c
index be19afeed7a9..93f59bfea092 100644
--- a/drivers/media/dvb-frontends/gp8psk-fe.c
+++ b/drivers/media/dvb-frontends/gp8psk-fe.c
@@ -1,5 +1,5 @@
-/* DVB USB compliant Linux driver for the
- * - GENPIX 8pks/qpsk/DCII USB2.0 DVB-S module
+/*
+ * Frontend driver for the GENPIX 8pks/qpsk/DCII USB2.0 DVB-S module
*
* Copyright (C) 2006,2007 Alan Nisota (alannisota@gmail.com)
* Copyright (C) 2006,2007 Genpix Electronics (genpix@genpix-electronics.com)
@@ -8,11 +8,9 @@
*
* This module is based off the vp7045 and vp702x modules
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation, version 2.
- *
- * see Documentation/dvb/README.dvb-usb for more information
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation, version 2.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -395,3 +393,8 @@ static struct dvb_frontend_ops gp8psk_fe_ops = {
.dishnetwork_send_legacy_command = gp8psk_fe_send_legacy_dish_cmd,
.enable_high_lnb_voltage = gp8psk_fe_enable_high_lnb_voltage
};
+
+MODULE_AUTHOR("Alan Nisota <alannisota@gamil.com>");
+MODULE_DESCRIPTION("Frontend Driver for Genpix DVB-S");
+MODULE_VERSION("1.1");
+MODULE_LICENSE("GPL");
Thanks,
Mauro
^ permalink raw reply related
* Re: Which version of xfs-progs to use on Debian?
From: Brian Foster @ 2016-11-14 13:14 UTC (permalink / raw)
To: John Henderson; +Cc: linux-xfs
In-Reply-To: <CA+sGqUv5X4JKQrMoOvVJupL4JadocZCd=AgzwfeR4iWjc_tG7w@mail.gmail.com>
On Mon, Nov 14, 2016 at 01:23:50AM -0600, John Henderson wrote:
> Hi,
>
> I'm trying to determine the optimal combination of kernel version and
> xfs-progs version to use on a Debian Jessie system (for amd64).
>
> I've searched this mailing list, and noticed the following exchange:
>
> http://www.spinics.net/lists/xfs/msg36165.html
>
> specifically, Dave's response:
>
> "As it is, in future the version of xfsprogs will tell you what
> kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly
> the same code/feature support as kernel 4.2.0. Similarly for
> xfsprogs/kernel 4.3.0."
>
> I'm also aware that prior to xfsprogs 4.2.0, userspace versioning did
> not match kernel numbering, as noted:
>
> https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/refs/tags
> https://www.spinics.net/lists/xfs/msg33984.html
>
> So, as I understand the situation, xfsprogs 3.2.x was associated with
> a lot of different 3.x and 4.y (y<2) kernels. Further, I want to make
> sure to take advantage of all the (current and future) reliability
> improvements of the new xfs v5 on-disk format, which means (from what
> I follow) that I need at least kernel 3.15 and xfsprogs 3.2.0, as seen
> here:
>
> https://www.spinics.net/lists/xfs/msg27961.html
>
> My main concern focuses on the options currently available in Debian
> (primarily Jessie + backports). Here's the matchup of what Debian
> ships (jessie, jessie-bpo, and stretch):
>
> linux-kernel xfs-progs
> Jessie: 3.16.36 3.2.1
> Jessie Backports: 4.7.8 4.3.0
> Stretch: 4.8.5 4.3.0
>
> So, at first pass, I could just use native jessie's kernel 3.16.36 and
> xfsprogs 3.2.1 (and they seem to match well, as they were released
> together). However, I actually have to use a more recent kernel
> anyway for some SkyLake support issues. So, that takes us to at least
> kernel 4.7.8. I note, though, that jessie-backports is *not*
> packaging xfsprogs 4.7 alongside its kernel (but instead xfsprogs
> 4.3.0); similar issues exist for the 4.8.5 kernel from stretch.
>
Others might be able to chime in on this, but that strikes me as a
packaging issue. My understanding is that the marriage between the
kernel revision and xfsprogs revision tracking numbers is to help define
dependencies between the two. That said, it might not be a problem for
you if you aren't using anything notable introduced between 4.3 and 4.7.
> Assuming I stick to binary packages distributed through the official
> Debian repos, what's the recommendation of the xfs experts: would I be
> better off (in terms of reliability) with xfsprogs 3.2.1 or xfsprogs
> 4.3.0 used with kernel 4.7.8? As an alternative, would it be even
> better for me to use xfsprogs 4.7 (via compiling from source, even
> though I'd rather not)?
>
v4.7 of xfsprogs is probably best, but IMO, you'll probably be fine with
the v4.3 in the simple cases (you haven't mentioned whether you're
planning to use xfsprogs for anything beyond mkfs and possibly repair if
something goes wrong). Just keep in mind that it is out of date with
respect to your kernel in the event that you do run into problems down
the road and may want to update.
> Also, what are current best-practice parameters for 'mkfs.xfs' in
> order to optimize reliability? Filesystem size is ~10 TB on top of
> LUKS-encrypted Software RAID-1 (using enterprise 512e drives).
>
> I'd assume, we'd at least want the following:
>
> -m crc=1 finobt=1
>
Usually it is best to go with defaults. Indeed, crc=1,finobt=1 are both
defaults and have been for a while now. See commit 566ebd5a ("mkfs:
default to CRC enabled filesystems") which first appeared in xfsprogs
v3.2.3. I'm not aware of any special/magic options required for raid1 or
encryption.
Brian
> Any pointers to a good write-up on optimizing such creation (and
> later, mount-time) decisions?
>
> Thanks so much (and for all your work on XFS, too).
>
> -John
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Connection problems with Qualcomm Atheros QCA6174
From: Michal Kazior @ 2016-11-14 13:13 UTC (permalink / raw)
To: Henrý Þór Baldursson; +Cc: ath10k@lists.infradead.org
In-Reply-To: <CABkmk0WJhXOW2voJwNSHa7G0oz7T70grS2PGt_eNUcJKgxe0wg@mail.gmail.com>
On 13 November 2016 at 06:57, Henrý Þór Baldursson
<henry.baldursson@gmail.com> wrote:
> Hello
>
> I have a Lenovo Ideapad Yoga 910 running Athergos, kernel version 4.8.7.
>
> My problem is that intermittently my wifi will just grind to a halt
> and even stop working.
>
> The driver reports the firmware as being WLAN.RM.2.0-00180-QCARMSWPZ-1
>
> Here's the initialization in dmesg:
>
> [ 1.900033] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2
> irq_mode 0 reset_mode 0
> [ 2.173039] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
> [ 2.173054] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/cal-pci-0000:01:00.0.bin failed with error -2
> [ 2.174217] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
> [ 2.174218] ath10k_pci 0000:01:00.0: could not fetch firmware file
> 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
> [ 2.175485] ath10k_pci 0000:01:00.0: qca6174 hw3.2 target
> 0x05030000 chip_id 0x00340aff sub 17aa:0827
> [ 2.175487] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 0 testmode 0
> [ 2.175876] ath10k_pci 0000:01:00.0: firmware ver
> WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features
> wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
> [ 2.240312] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id N/A
> crc32 6fc88fe7
> [ 4.405741] ath10k_pci 0000:01:00.0: htt-ver 3.26 wmi-op 4 htt-op 3
> cal otp max-sta 32 raw 0 hwcrypto 1
> [ 4.485362] ath10k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
>
>
> Here's what dmesg shows during the errors:
>
> [ 1238.710899] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
> [ 1238.710920] pcieport 0000:00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1238.710935] pcieport 0000:00:1c.0: device [8086:9d14] error
> status/mask=00001000/00000000
> [ 1238.710945] pcieport 0000:00:1c.0: [12] Replay Timer Timeout
> [ 1243.855456] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
> [ 1243.855472] pcieport 0000:00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1243.855484] pcieport 0000:00:1c.0: device [8086:9d14] error
> status/mask=00001000/00000000
> [ 1243.855491] pcieport 0000:00:1c.0: [12] Replay Timer Timeout
> [ 1296.095437] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
> [ 1296.095452] pcieport 0000:00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1296.095464] pcieport 0000:00:1c.0: device [8086:9d14] error
> status/mask=00001000/00000000
> [ 1296.095472] pcieport 0000:00:1c.0: [12] Replay Timer Timeout
> [ 1305.877547] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
> [ 1305.877562] pcieport 0000:00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1305.877574] pcieport 0000:00:1c.0: device [8086:9d14] error
> status/mask=00001000/00000000
> [ 1305.877581] pcieport 0000:00:1c.0: [12] Replay Timer Timeout
> [ 1556.596092] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
> [ 1556.596107] pcieport 0000:00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1556.596115] pcieport 0000:00:1c.0: device [8086:9d14] error
> status/mask=00001000/00000000
> [ 1556.596122] pcieport 0000:00:1c.0: [12] Replay Timer Timeout
> [ 1612.764108] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
> [ 1612.764124] pcieport 0000:00:1c.0: PCIe Bus Error:
> severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
> [ 1612.764135] pcieport 0000:00:1c.0: device [8086:9d14] error
> status/mask=00001000/00000000
> [ 1612.764143] pcieport 0000:00:1c.0: [12] Replay Timer Timeout
Can you try to override ar_pci->pci_ps to false in ath10k_pci_probe()
and see if it helps? Something along the diff:
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3236,7 +3236,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
ar_pci->dev = &pdev->dev;
ar_pci->ar = ar;
ar->dev_id = pci_dev->device;
- ar_pci->pci_ps = pci_ps;
+ ar_pci->pci_ps = false;
ar_pci->bus_ops = &ath10k_pci_bus_ops;
ar_pci->pci_soft_reset = pci_soft_reset;
ar_pci->pci_hard_reset = pci_hard_reset;
Another thing which could be happening is ACPI S0ix states which - to
the best of my knowledge - Linux does not support. I've seen at least
i915 not being able to wake-up DSI displays properly when S0ix states
are enabled on some 10 inch 2-in-1 devices. I wouldn't be surprised if
other PCI-E (such as wifi/network devices) can be affected adversely
as well.
Therefore, can you check UEFI/BIOS (you may need to enable "expert
settings") if there are any mentions about S0x or S0ix ACPI modes
there and - if found - try disabling them and checking back if you
still get AER/bus errors, please?
Michał
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* [WireGuard] [PATCH] kernel: enable pcrypt
From: Jason A. Donenfeld @ 2016-11-14 13:16 UTC (permalink / raw)
To: openwrt, lede-dev, wireguard, Felix Fietkau
In-Reply-To: <5a31f30c-1fe3-8012-18d4-7545fd86d290@nbd.name>
This is a powerful API for parallel crypto from which many other modules
can benefit. It only winds up being turned on on SMP systems, which
means this adds 0 bytes to the kernel on tiny machines, while only
adding a small bit to SMP systems for big performance improvements.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
target/linux/generic/config-3.18 | 2 +-
target/linux/generic/config-4.1 | 2 +-
target/linux/generic/config-4.4 | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/linux/generic/config-3.18 b/target/linux/generic/config-3.18
index 8b70c7d..c61a4b3 100644
--- a/target/linux/generic/config-3.18
+++ b/target/linux/generic/config-3.18
@@ -762,7 +762,7 @@ CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_PCOMP is not set
# CONFIG_CRYPTO_PCOMP2 is not set
-# CONFIG_CRYPTO_PCRYPT is not set
+CONFIG_CRYPTO_PCRYPT=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
diff --git a/target/linux/generic/config-4.1 b/target/linux/generic/config-4.1
index 68bd849..4fae342 100644
--- a/target/linux/generic/config-4.1
+++ b/target/linux/generic/config-4.1
@@ -792,7 +792,7 @@ CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_PCOMP is not set
# CONFIG_CRYPTO_PCOMP2 is not set
-# CONFIG_CRYPTO_PCRYPT is not set
+CONFIG_CRYPTO_PCRYPT=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
diff --git a/target/linux/generic/config-4.4 b/target/linux/generic/config-4.4
index 28e7068..843154d 100644
--- a/target/linux/generic/config-4.4
+++ b/target/linux/generic/config-4.4
@@ -791,7 +791,7 @@ CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_PCOMP is not set
# CONFIG_CRYPTO_PCOMP2 is not set
-# CONFIG_CRYPTO_PCRYPT is not set
+CONFIG_CRYPTO_PCRYPT=y
# CONFIG_CRYPTO_POLY1305 is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
--
2.10.2
^ permalink raw reply related
* [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)
From: Tom Rini @ 2016-11-14 13:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <41d484ce-4dfa-803e-c8d8-a216ee78f987@redhat.com>
On Mon, Nov 14, 2016 at 12:53:13PM +0100, Hans de Goede wrote:
> Hi All,
>
> A while back I wrote:
>
> "Between my $dayjob, linux-sunxi, other foss projects and last but
> not least spending time with my wife and children I'm way too
> busy lately.
>
> So I've decided to seriously scale back my involvement in
> linux-sunxi, as such I'm going to step down as u-boot sunxi
> custodian."
>
> After that I did get some breathing room, and kept doing
> sunxi u-boot maintenance until now, but this still feels
> too much like a job rather then a hobby. The problem is
> that I don't want to think during the weekend:
> "Oh !@#$ I still need to prep a u-boot sunxi pull-req"
>
> This is nothing against the u-boot community, I think
> you're all great and I still love thinkering with this
> kind of stuff, but when a hobby starts feeling as a chore
> something is wrong.
>
> So after this mail I'm going to send a mail updating
> the MAINTAINERS status of sunxi to orphan and I will also
> unsubscribe myself from the u-boot list to protect myself
> against getting dragged in again.
>
> I do expect (after taking a break for a couple of weeks)
> that I will likely submit the occasional patch, but at
> this point in time I do not want any maintainer
> responsibilities.
>
> Yesterday and today I've gone over my pending patches
> queue, reviewed then all and I've merged all the ones
> which looked good into u-boot-sunxi/next, so that
> should be a good starting point for the next
> maintainer.
I just want to thank you for all the time and effort you've put in on
U-Boot you've put in. We would not be where we are today without what
you've done, so once again, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/fd8a49e1/attachment.sig>
^ permalink raw reply
* [PATCH v6 2/3] clocksource: update "fn" at CLOCKSOURCE_OF_DECLARE() of nps400 timer
From: Noam Camus @ 2016-11-14 9:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, daniel.lezcano
Cc: tglx, devicetree, linux-kernel, Noam Camus
In-Reply-To: <1479116447-29483-1-git-send-email-noamca@mellanox.com>
From: Noam Camus <noamca@mellanox.com>
nps_setup_clocksource() should take node as only argument as defined by
typedef int (*of_init_fn_1_ret)(struct device_node *)
Therefore need to replace:
int __init nps_setup_clocksource(struct device_node *node, struct clk *clk)
with
int __init nps_setup_clocksource(struct device_node *node)
This patch also serve as preparation for next patch which add support
for clockevents to nps400.
Specifically we add new function nps_get_timer_clk() to serve clocksource
and later clockevent registration.
Signed-off-by: Noam Camus <noamca@mellanox.com>
---
drivers/clocksource/timer-nps.c | 65 +++++++++++++++++++++++---------------
1 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
index 70c149a..0c8e21f 100644
--- a/drivers/clocksource/timer-nps.c
+++ b/drivers/clocksource/timer-nps.c
@@ -46,7 +46,35 @@
/* This array is per cluster of CPUs (Each NPS400 cluster got 256 CPUs) */
static void *nps_msu_reg_low_addr[NPS_CLUSTER_NUM] __read_mostly;
-static unsigned long nps_timer_rate;
+static int __init nps_get_timer_clk(struct device_node *node,
+ unsigned long *timer_freq,
+ struct clk **clk)
+{
+ int ret;
+
+ *clk = of_clk_get(node, 0);
+ if (IS_ERR(*clk)) {
+ pr_err("timer missing clk");
+ return PTR_ERR(*clk);
+ }
+
+ ret = clk_prepare_enable(*clk);
+ if (ret) {
+ pr_err("Couldn't enable parent clk\n");
+ clk_put(*clk);
+ return ret;
+ }
+
+ *timer_freq = clk_get_rate(*clk);
+ if (!(*timer_freq)) {
+ pr_err("Couldn't get clk rate\n");
+ clk_disable_unprepare(*clk);
+ clk_put(*clk);
+ return -EINVAL;
+ }
+
+ return 0;
+}
static cycle_t nps_clksrc_read(struct clocksource *clksrc)
{
@@ -55,26 +83,24 @@ static cycle_t nps_clksrc_read(struct clocksource *clksrc)
return (cycle_t)ioread32be(nps_msu_reg_low_addr[cluster]);
}
-static int __init nps_setup_clocksource(struct device_node *node,
- struct clk *clk)
+static int __init nps_setup_clocksource(struct device_node *node)
{
int ret, cluster;
+ struct clk *clk;
+ unsigned long nps_timer1_freq;
+
for (cluster = 0; cluster < NPS_CLUSTER_NUM; cluster++)
nps_msu_reg_low_addr[cluster] =
nps_host_reg((cluster << NPS_CLUSTER_OFFSET),
- NPS_MSU_BLKID, NPS_MSU_TICK_LOW);
+ NPS_MSU_BLKID, NPS_MSU_TICK_LOW);
- ret = clk_prepare_enable(clk);
- if (ret) {
- pr_err("Couldn't enable parent clock\n");
+ ret = nps_get_timer_clk(node, &nps_timer1_freq, &clk);
+ if (ret)
return ret;
- }
- nps_timer_rate = clk_get_rate(clk);
-
- ret = clocksource_mmio_init(nps_msu_reg_low_addr, "EZnps-tick",
- nps_timer_rate, 301, 32, nps_clksrc_read);
+ ret = clocksource_mmio_init(nps_msu_reg_low_addr, "nps-tick",
+ nps_timer1_freq, 300, 32, nps_clksrc_read);
if (ret) {
pr_err("Couldn't register clock source.\n");
clk_disable_unprepare(clk);
@@ -83,18 +109,5 @@ static int __init nps_setup_clocksource(struct device_node *node,
return ret;
}
-static int __init nps_timer_init(struct device_node *node)
-{
- struct clk *clk;
-
- clk = of_clk_get(node, 0);
- if (IS_ERR(clk)) {
- pr_err("Can't get timer clock.\n");
- return PTR_ERR(clk);
- }
-
- return nps_setup_clocksource(node, clk);
-}
-
CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
- nps_timer_init);
+ nps_setup_clocksource);
--
1.7.1
^ permalink raw reply related
* [LTP] new shell library
From: Cyril Hrubis @ 2016-11-14 13:12 UTC (permalink / raw)
To: ltp
In-Reply-To: <827120068.2432301.1477908222614.JavaMail.zimbra@redhat.com>
Hi!
I've added a few patches that remove tst_kvercmp in favor of tst_kvcmp
into the repository[1]. These are more or less trivial, the rest of the
patchset is the same, I only converted one more test (ar01) and keep
fixing conflicts so that it could be applied on the top of the latest
git tree.
Has anybody any feedback that would stop the inclusion of these patches?
If not I would like to get them into the git once I test that these
testcases can run fine from an installed tree so that we have enough
time to test the changes out before the next release.
[1] https://github.com/metan-ucw/ltp
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* [PATCH v2] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-14 13:11 UTC (permalink / raw)
To: linux-arm-kernel
commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
adds bma180 chip-ids to the input bma150 driver, assuming that they are
100% compatible, but the bma180 is not compatible with the bma150 at all,
it has 14 bits resolution instead of 10, and it has quite different
control registers too.
Treating the bma180 as a bma150 wrt its data registers will just result
in throwing away the lowest 4 bits, which is not too bad. But the ctrl
registers are a different story. Things happen to just work but supporting
that certainly does not make treating the bma180 the same as the bma150
right.
Since some setups depend on the evdev interface the bma150 driver offers
on top of the bma180, we cannot simply remove the bma180 ids.
So this commit only removes the bma180 id when the bma180 iio driver,
which does treat the bma180 properly, is enabled.
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Use IS_ENABLED(CONFIG_BMA180) instead of #ifdef CONFIG_BMA180
---
drivers/input/misc/bma150.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
index b0d4453..2124390 100644
--- a/drivers/input/misc/bma150.c
+++ b/drivers/input/misc/bma150.c
@@ -538,8 +538,13 @@ static int bma150_probe(struct i2c_client *client,
return -EIO;
}
+ /*
+ * Note if the IIO CONFIG_BMA180 driver is enabled we want to fail
+ * the probe for the bma180 as the iio driver is preferred.
+ */
chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
- if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
+ if (chip_id != BMA150_CHIP_ID &&
+ (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
return -EINVAL;
}
@@ -643,7 +648,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
static const struct i2c_device_id bma150_id[] = {
{ "bma150", 0 },
+#if !IS_ENABLED(CONFIG_BMA180)
{ "bma180", 0 },
+#endif
{ "smb380", 0 },
{ "bma023", 0 },
{ }
--
2.9.3
^ permalink raw reply related
* [PATCH v2] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-14 13:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dr . H . Nikolaus Schaller, Hans de Goede, linux-arm-kernel,
linux-input
commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
adds bma180 chip-ids to the input bma150 driver, assuming that they are
100% compatible, but the bma180 is not compatible with the bma150 at all,
it has 14 bits resolution instead of 10, and it has quite different
control registers too.
Treating the bma180 as a bma150 wrt its data registers will just result
in throwing away the lowest 4 bits, which is not too bad. But the ctrl
registers are a different story. Things happen to just work but supporting
that certainly does not make treating the bma180 the same as the bma150
right.
Since some setups depend on the evdev interface the bma150 driver offers
on top of the bma180, we cannot simply remove the bma180 ids.
So this commit only removes the bma180 id when the bma180 iio driver,
which does treat the bma180 properly, is enabled.
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Use IS_ENABLED(CONFIG_BMA180) instead of #ifdef CONFIG_BMA180
---
drivers/input/misc/bma150.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
index b0d4453..2124390 100644
--- a/drivers/input/misc/bma150.c
+++ b/drivers/input/misc/bma150.c
@@ -538,8 +538,13 @@ static int bma150_probe(struct i2c_client *client,
return -EIO;
}
+ /*
+ * Note if the IIO CONFIG_BMA180 driver is enabled we want to fail
+ * the probe for the bma180 as the iio driver is preferred.
+ */
chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
- if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
+ if (chip_id != BMA150_CHIP_ID &&
+ (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
return -EINVAL;
}
@@ -643,7 +648,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
static const struct i2c_device_id bma150_id[] = {
{ "bma150", 0 },
+#if !IS_ENABLED(CONFIG_BMA180)
{ "bma180", 0 },
+#endif
{ "smb380", 0 },
{ "bma023", 0 },
{ }
--
2.9.3
^ permalink raw reply related
* Re: Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-14 13:10 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, Icenowy Zheng, Jonathan Corbet, Rob Herring,
Mark Rutland, Russell King,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel, linux-kernel, devicetree, linux-sunxi
In-Reply-To: <cbbf8ae1-ff29-2a83-265b-a9ff5bacf97b-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On Mon, Nov 14, 2016 at 11:00:32AM +0100, Hans de Goede wrote:
> > > > +&usbphy {
> > > > + /* USB VBUS is always on */
> > >
> > > You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
> >
> > AFAIK the regulator properties are optional the the USB PHY.
> > So we probably don't need to add it. Hans (CC-ed) could explain
> > his original intent?
>
> I've made the regulators optional exactly for boards like these,
> where there is no regulator. Likely the Vbus is simply wired
> directly to the 5V DC-in jack. So IMHO adding something like
> the fixed reg_vcc5v0 a supply here just makes the dt
> harder to read.
It also makes the regulator tree more complete and accurate because
you'd list all the devices that are needing those regulators. That
would also make it easier to deal with in the future.
But fair enough.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-14 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbbf8ae1-ff29-2a83-265b-a9ff5bacf97b@redhat.com>
On Mon, Nov 14, 2016 at 11:00:32AM +0100, Hans de Goede wrote:
> > > > +&usbphy {
> > > > + /* USB VBUS is always on */
> > >
> > > You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
> >
> > AFAIK the regulator properties are optional the the USB PHY.
> > So we probably don't need to add it. Hans (CC-ed) could explain
> > his original intent?
>
> I've made the regulators optional exactly for boards like these,
> where there is no regulator. Likely the Vbus is simply wired
> directly to the 5V DC-in jack. So IMHO adding something like
> the fixed reg_vcc5v0 a supply here just makes the dt
> harder to read.
It also makes the regulator tree more complete and accurate because
you'd list all the devices that are needing those regulators. That
would also make it easier to deal with in the future.
But fair enough.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4cfb2c48/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.