Re: [PATCH 5.1 00/70] 5.1.9-stable review
On Sun, Jun 09, 2019 at 05:37:37PM -0500, Jiunn Chang wrote: > On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.9 release. > > There are 70 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > - > > Compiled and booted. No regressions on x86_64. Thanks for testing and letting me know. greg k-h
Re: [PATCH 4.14 03/35] neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit
On Mon, Jun 10, 2019 at 01:13:16AM +, nobuhiro1.iwama...@toshiba.co.jp
wrote:
> Hi again.
>
> > -Original Message-
> > From: stable-ow...@vger.kernel.org
> > [mailto:stable-ow...@vger.kernel.org] On Behalf Of Nobuhiro Iwamatsu
> > Sent: Monday, June 10, 2019 10:10 AM
> > To: Greg Kroah-Hartman
> > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Alan Maguire
> > ; David Ahern ; David S.
> > Miller
> > Subject: Re: [PATCH 4.14 03/35] neighbor: Call __ipv4_neigh_lookup_noref
> > in neigh_xmit
> >
> > Hi,
> >
> > On Sun, Jun 09, 2019 at 06:42:09PM +0200, Greg Kroah-Hartman wrote:
> > > From: David Ahern
> > >
> > > [ Upstream commit 4b2a2bfeb3f056461a90bd621e8bd7d03fa47f60 ]
> > >
> > > Commit cd9ff4de0107 changed the key for IFF_POINTOPOINT devices to
> > > INADDR_ANY but neigh_xmit which is used for MPLS encapsulations was
> > > not updated to use the altered key. The result is that every packet
> > Tx
> > > does a lookup on the gateway address which does not find an entry, a
> > > new one is created only to find the existing one in the table right
> > > before the insert since arp_constructor was updated to reset the
> > > primary key. This is seen in the allocs and destroys counters:
> > > ip -s -4 ntable show | head -10 | grep alloc
> > >
> > > which increase for each packet showing the unnecessary overhread.
> > >
> > > Fix by having neigh_xmit use __ipv4_neigh_lookup_noref for
> > NEIGH_ARP_TABLE.
> > >
> > > Fixes: cd9ff4de0107 ("ipv4: Make neigh lookup keys for
> > > loopback/point-to-point devices be INADDR_ANY")
> > > Reported-by: Alan Maguire
> > > Signed-off-by: David Ahern
> > > Tested-by: Alan Maguire
> > > Signed-off-by: David S. Miller
> > > Signed-off-by: Greg Kroah-Hartman
> > > ---
> >
> > This commit also requires the following commit:
> >
> > commit 9b3040a6aafd7898ece7fc7efcbca71e42aa8069
> > Author: David Ahern
> > Date: Sun May 5 11:16:20 2019 -0700
> >
> > ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled
> >
> > Define __ipv4_neigh_lookup_noref to return NULL when CONFIG_INET is
> > disabled.
> >
> > Fixes: 4b2a2bfeb3f0 ("neighbor: Call __ipv4_neigh_lookup_noref in
> > neigh_xmit")
> > Reported-by: kbuild test robot
> > Signed-off-by: David Ahern
> > Signed-off-by: David S. Miller
> >
> > And this is also necessary for 4.4.y, 4.14.y, 4.19.y and 5.1.y.
>
> 4.4.y, 4.9.y, 4.19.y and 5.1.y.
Thanks for the information, now queued up everywhere.
greg k-h
Re: [PATCH v3 0/3] KVM: Yield to IPI target if necessary
ping, :) On Thu, 30 May 2019 at 09:05, Wanpeng Li wrote: > > The idea is from Xen, when sending a call-function IPI-many to vCPUs, > yield if any of the IPI target vCPUs was preempted. 17% performance > increasement of ebizzy benchmark can be observed in an over-subscribe > environment. (w/ kvm-pv-tlb disabled, testing TLB flush call-function > IPI-many since call-function is not easy to be trigged by userspace > workload). > > v2 -> v3: > * add bounds-check on dest_id > > v1 -> v2: > * check map is not NULL > * check map->phys_map[dest_id] is not NULL > * make kvm_sched_yield static > * change dest_id to unsinged long > > Wanpeng Li (3): > KVM: X86: Yield to IPI target if necessary > KVM: X86: Implement PV sched yield hypercall > KVM: X86: Expose PV_SCHED_YIELD CPUID feature bit to guest > > Documentation/virtual/kvm/cpuid.txt | 4 > Documentation/virtual/kvm/hypercalls.txt | 11 +++ > arch/x86/include/uapi/asm/kvm_para.h | 1 + > arch/x86/kernel/kvm.c| 21 + > arch/x86/kvm/cpuid.c | 3 ++- > arch/x86/kvm/x86.c | 26 ++ > include/uapi/linux/kvm_para.h| 1 + > 7 files changed, 66 insertions(+), 1 deletion(-) > > -- > 2.7.4 >
Re: [RFC v1] clk: core: support clocks that need to be enabled during re-parent
On Mon, Jun 10, 2019 at 11:44:53AM +0800, Weiyi Lu wrote: > When using property assigned-clock-parents to assign parent clocks, > core clocks might still be disabled during re-parent. > Add flag 'CLK_OPS_CORE_ENABLE' for those clocks must be enabled > during re-parent. > > Signed-off-by: Weiyi Lu > --- > drivers/clk/clk.c| 9 + > include/linux/clk-provider.h | 1 + > 2 files changed, 10 insertions(+) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
[PATCH] locking/lockdep: Fix lock IRQ usage initialization bug
The commit:
091806515124b20 ("locking/lockdep: Consolidate lock usage bit initialization")
misses marking LOCK_USED flag at IRQ usage initialization when
CONFIG_TRACE_IRQFLAGS
or CONFIG_PROVE_LOCKING is not defined. Fix it.
Reported-by: Qian Cai
Signed-off-by: Yuyang Du
---
kernel/locking/lockdep.c | 110 +++
1 file changed, 53 insertions(+), 57 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 48a840a..c3db987 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3460,9 +3460,61 @@ void trace_softirqs_off(unsigned long ip)
debug_atomic_inc(redundant_softirqs_off);
}
+static inline unsigned int task_irq_context(struct task_struct *task)
+{
+ return 2 * !!task->hardirq_context + !!task->softirq_context;
+}
+
+static int separate_irq_context(struct task_struct *curr,
+ struct held_lock *hlock)
+{
+ unsigned int depth = curr->lockdep_depth;
+
+ /*
+* Keep track of points where we cross into an interrupt context:
+*/
+ if (depth) {
+ struct held_lock *prev_hlock;
+
+ prev_hlock = curr->held_locks + depth-1;
+ /*
+* If we cross into another context, reset the
+* hash key (this also prevents the checking and the
+* adding of the dependency to 'prev'):
+*/
+ if (prev_hlock->irq_context != hlock->irq_context)
+ return 1;
+ }
+ return 0;
+}
+
+#else /* defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING) */
+
+static inline
+int mark_lock_irq(struct task_struct *curr, struct held_lock *this,
+ enum lock_usage_bit new_bit)
+{
+ WARN_ON(1); /* Impossible innit? when we don't have TRACE_IRQFLAG */
+ return 1;
+}
+
+static inline unsigned int task_irq_context(struct task_struct *task)
+{
+ return 0;
+}
+
+static inline int separate_irq_context(struct task_struct *curr,
+ struct held_lock *hlock)
+{
+ return 0;
+}
+
+#endif /* defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING) */
+
static int
mark_usage(struct task_struct *curr, struct held_lock *hlock, int check)
{
+#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING)
if (!check)
goto lock_used;
@@ -3510,6 +3562,7 @@ void trace_softirqs_off(unsigned long ip)
}
lock_used:
+#endif
/* mark it as used: */
if (!mark_lock(curr, hlock, LOCK_USED))
return 0;
@@ -3517,63 +3570,6 @@ void trace_softirqs_off(unsigned long ip)
return 1;
}
-static inline unsigned int task_irq_context(struct task_struct *task)
-{
- return 2 * !!task->hardirq_context + !!task->softirq_context;
-}
-
-static int separate_irq_context(struct task_struct *curr,
- struct held_lock *hlock)
-{
- unsigned int depth = curr->lockdep_depth;
-
- /*
-* Keep track of points where we cross into an interrupt context:
-*/
- if (depth) {
- struct held_lock *prev_hlock;
-
- prev_hlock = curr->held_locks + depth-1;
- /*
-* If we cross into another context, reset the
-* hash key (this also prevents the checking and the
-* adding of the dependency to 'prev'):
-*/
- if (prev_hlock->irq_context != hlock->irq_context)
- return 1;
- }
- return 0;
-}
-
-#else /* defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING) */
-
-static inline
-int mark_lock_irq(struct task_struct *curr, struct held_lock *this,
- enum lock_usage_bit new_bit)
-{
- WARN_ON(1); /* Impossible innit? when we don't have TRACE_IRQFLAG */
- return 1;
-}
-
-static inline int
-mark_usage(struct task_struct *curr, struct held_lock *hlock, int check)
-{
- return 1;
-}
-
-static inline unsigned int task_irq_context(struct task_struct *task)
-{
- return 0;
-}
-
-static inline int separate_irq_context(struct task_struct *curr,
- struct held_lock *hlock)
-{
- return 0;
-}
-
-#endif /* defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING) */
-
/*
* Mark a lock with a usage bit, and validate the state transition:
*/
--
1.8.3.1
Re: [PATCH] staging: rtl8723bs: core: rtw_mlme_ext.c: Remove unused variables
On Mon, Jun 10, 2019 at 10:08:21AM +0530, Nishka Dasgupta wrote: > On 09/06/19 4:32 PM, Greg KH wrote: > > On Fri, Jun 07, 2019 at 12:41:23PM +0530, Nishka Dasgupta wrote: > > > Remove variables that are declared and assigned values but not otherwise > > > used. > > > Issue found with Coccinelle. > > > > > > Signed-off-by: Nishka Dasgupta > > > --- > > > drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 9 - > > > 1 file changed, 9 deletions(-) > > > > You sent me 8 patches for this driver, yet only 2 were ordered in a > > series. I have no idea what order to apply these in :( > > > > Please resend them _all_ in a numbered patch series so I have a chance > > to get this correct. > > Yes, I can do that. Who do I send the patch series to in that case? The > maintainers list is slightly different for each file, and most of the > patches in this driver are for different and unrelated files (except, I > think, the two that I did send as a patch series). Do I combine the > maintainers lists and send the entire patch series to everyone listed as a > maintainer for any one of the patches in it? The maintainer and mailing list is the same for all of the files in a single driver. If not, then something is wrong. And yes, you can combine the list of people if you wish but be sure you are not just randomly including people who happened to touch the driver "last". greg k-h
Re: [PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
On Sat, 08 Jun 2019, Mark Brown wrote: > On Sat, Jun 08, 2019 at 09:26:31AM +0530, keerthy wrote: > > > mfd patches are on linux-next already. Hope you can pull this one now that > > dependencies are met. > > Someone will need to send me a copy of the patch, if I acked it I was > expecting it to go in with the MFD changes. There is/was no need for that. Patches are built-time orthogonal. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/3] mfd: apple-ibridge: Add Apple iBridge MFD driver.
On Sun, 09 Jun 2019, Life is hard, and then you die wrote: > > On Tue, May 07, 2019 at 01:24:15PM +0100, Lee Jones wrote: > > On Sun, 21 Apr 2019, Ronald Tschalär wrote: > > > > > The iBridge device provides access to several devices, including: > > > - the Touch Bar > > > - the iSight webcam > > > - the light sensor > > > - the fingerprint sensor > > > > > > This driver provides the core support for managing the iBridge device > > > and the access to the underlying devices. In particular, since the > > > functionality for the touch bar and light sensor is exposed via USB HID > > > interfaces, and the same HID device is used for multiple functions, this > > > driver provides a multiplexing layer that allows multiple HID drivers to > > > be registered for a given HID device. This allows the touch bar and ALS > > > driver to be separated out into their own modules. > > > > > > Signed-off-by: Ronald Tschalär > > > --- > > > drivers/mfd/Kconfig | 15 + > > > drivers/mfd/Makefile | 1 + > > > drivers/mfd/apple-ibridge.c | 883 ++ > > > > I haven't taken a thorough look through, but I can tell you that the > > vast majority of what you're trying to do here does not belong in > > MFD. MFD drivers are used to register child devices. Almost all > > functionality or 'real work' should be contained in the drivers the > > MFD registers, not in the MFD parent itself. You will need to move > > all 'real work' out into the subordinate device drivers for > > acceptance. > > Thanks for your feedback. That was/is the idea: the actual Touch Bar > and ALS driver code is in separate modules - what is left in the > appple-ibridge mfd driver is a fairly generic hid driver > demultiplexer. However, that could be moved out into it's own > helper/module. > > Having said that, it looks like the preference is to do all of this as > a hid driver with virtual hid devices instead of as an mfd driver. Sounds like a better approach. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] staging: kpc2000: remove extra white space in kpc2000_spi.c
Since whitespace should not appear between asterisk and
variable name in a declaration statement, remove it and
fix checkpatch.pl error "foo * bar" should be "foo *bar".
Signed-off-by: Naoto Kobayashi
---
drivers/staging/kpc2000/kpc2000_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index 28132e9e260d..c3e5c1848f53 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -496,7 +496,7 @@ kp_spi_probe(struct platform_device *pldev)
static int
kp_spi_remove(struct platform_device *pldev)
{
- struct spi_master * master = platform_get_drvdata(pldev);
+ struct spi_master *master = platform_get_drvdata(pldev);
spi_unregister_master(master);
return 0;
}
--
2.16.5
[PATCH] clk: imx8mq: Use devm_platform_ioremap_resource() instead of of_iomap()
From: Anson Huang
i.MX8MQ clock driver uses platform driver model, better to use
devm_platform_ioremap_resource() instead of of_iomap() to get
IO base.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx8mq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 1292241..7da1edb 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -361,9 +361,9 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clks[IMX8MQ_SYS2_PLL_1000M] = imx_clk_fixed_factor("sys2_pll_1000m",
"sys2_pll_out", 1, 1);
np = dev->of_node;
- base = of_iomap(np, 0);
- if (WARN_ON(!base))
- return -ENOMEM;
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (WARN_ON(IS_ERR(base)))
+ return PTR_ERR(base);
/* CORE */
clks[IMX8MQ_CLK_A53_SRC] = imx_clk_mux2("arm_a53_src", base + 0x8000,
24, 3, imx8mq_a53_sels, ARRAY_SIZE(imx8mq_a53_sels));
--
2.7.4
[PATCH 1/2] clk: imx: Remove __init for imx_check_clocks() API
From: Anson Huang
Some of i.MX SoCs' clock driver use platform driver model,
and they need to call imx_check_clocks() API, so
imx_check_clocks() API should NOT be in .init section.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
index 9cd7097..b1416b2 100644
--- a/drivers/clk/imx/clk.c
+++ b/drivers/clk/imx/clk.c
@@ -23,7 +23,7 @@ void __init imx_mmdc_mask_handshake(void __iomem *ccm_base,
writel_relaxed(reg, ccm_base + CCM_CCDR);
}
-void __init imx_check_clocks(struct clk *clks[], unsigned int count)
+void imx_check_clocks(struct clk *clks[], unsigned int count)
{
unsigned i;
--
2.7.4
[PATCH 2/2] clk: imx8mq: Use imx_check_clocks() API directly
From: Anson Huang
Use imx_check_clocks() API to check clocks directly.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx8mq.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 7da1edb..5fbc2a7 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -278,7 +278,6 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
struct device_node *np = dev->of_node;
void __iomem *base;
int err;
- int i;
clks[IMX8MQ_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
clks[IMX8MQ_CLK_32K] = of_clk_get_by_name(np, "ckil");
@@ -548,10 +547,7 @@ static int imx8mq_clocks_probe(struct platform_device
*pdev)
clks[IMX8MQ_ARM_PLL_OUT],
clks[IMX8MQ_SYS1_PLL_800M]);
- for (i = 0; i < IMX8MQ_CLK_END; i++)
- if (IS_ERR(clks[i]))
- pr_err("i.MX8mq clk %u register failed with %ld\n",
- i, PTR_ERR(clks[i]));
+ imx_check_clocks(clks, ARRAY_SIZE(clks));
clk_data.clks = clks;
clk_data.clk_num = ARRAY_SIZE(clks);
--
2.7.4
possible fix for broken cmac crypto support
this is no real patch for this mailing list since i havent cloned yet a
git tree. take it as a hint
this fixes the BUG WARN if SAE encryption is used (mandatory for mesh /
802.11s crypto)
that will not fix that mesh is not working (likelly just with other
vendors), but it will fix crypto at least
Sebastian
Index: main.c
===
--- main.c (revision 4584)
+++ main.c (revision 4585)
@@ -180,6 +180,20 @@ static int mt7615_set_key(struct ieee80211_hw *hw,
!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
return -EOPNOTSUPP;
+ switch (key->cipher) {
+ case WLAN_CIPHER_SUITE_WEP40:
+ case WLAN_CIPHER_SUITE_WEP104:
+ case WLAN_CIPHER_SUITE_TKIP:
+ case WLAN_CIPHER_SUITE_CCMP:
+ case WLAN_CIPHER_SUITE_CCMP_256:
+ case WLAN_CIPHER_SUITE_GCMP:
+ case WLAN_CIPHER_SUITE_GCMP_256:
+ case WLAN_CIPHER_SUITE_SMS4:
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
if (cmd == SET_KEY) {
key->hw_key_idx = wcid->idx;
wcid->hw_key_idx = idx;
Am 09.06.2019 um 16:36 schrieb Sebastian Gottschall:
by the way. this big fat kernel warning exists in all operation modes
unless anything else but aes-128 ccmp is used. since the chipset is
capable of doing gcmp etc. as well
it would be nice if this issue can be fixed. otherwise encryption
support can be defined as "broken" for mt7615
Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:
i tested your patch against a qca 9984 chipset using SAE and without
encryption. both did not work. the devices are connecting, but no data
connection is possible
Hi Sebastian,
I tested Ryder's patch using mt76x2 as mesh peer and it works fine
for me.
Could you please provide some more info?
Regards,
Lorenzo
Sebastian
Am 03.06.2019 um 08:08 schrieb Ryder Lee:
Enable NL80211_IFTYPE_MESH_POINT and update its path.
Signed-off-by: Ryder Lee
---
Changes since v3 - fix a wrong expression
Changes since v2 - remove unused definitions
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 --
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit
if_limits[] = {
{
.max = MT7615_MAX_INTERFACES,
.types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_STATION)
}
};
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
dev->mt76.antenna_mask = 0xf;
wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_AP);
ret = mt76_register_device(>mt76, true, mt7615_rates,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type,
u32 mask)
switch (type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
/* ap use hw bssid 0 and ext bssid */
if (~mask & BIT(HW_BSSID_0))
return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 43f70195244c..e82297048449 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev
*dev,
switch (vif->type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
tx_wlan_idx = mvif->sta.wcid.idx;
conn_type = CONNECTION_INFRA_AP;
break;
@@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev,
struct ieee80211_vif *vif,
.rx_wtbl = {
.tag = cpu_to_le16(WTBL_RX),
.len = cpu_to_le16(sizeof(struct wtbl_rx)),
- .rca1 = vif->type != NL80211_IFTYPE_AP,
+ .rca1 = vif->type == NL80211_IFTYPE_STATION,
.rca2 = 1,
.rv = 1,
},
@@ -1042,6 +1043,7 @@ static void
[PATCH V3 6/6] i2c: tegra: remove BUG, BUG_ON
Remove redundant BUG_ON calls or replace with WARN_ON_ONCE
as needed. Replace BUG() with error handling code.
Define I2C_ERR_UNEXPECTED_STATUS for error handling.
Signed-off-by: Bitan Biswas
---
drivers/i2c/busses/i2c-tegra.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 4dfb4c1..d9e99b4 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -73,6 +73,7 @@
#define I2C_ERR_NO_ACK BIT(0)
#define I2C_ERR_ARBITRATION_LOST BIT(1)
#define I2C_ERR_UNKNOWN_INTERRUPT BIT(2)
+#define I2C_ERR_UNEXPECTED_STATUS BIT(3)
#define PACKET_HEADER0_HEADER_SIZE_SHIFT 28
#define PACKET_HEADER0_PACKET_ID_SHIFT 16
@@ -515,7 +516,6 @@ static int tegra_i2c_empty_rx_fifo(struct tegra_i2c_dev
*i2c_dev)
* prevent overwriting past the end of buf
*/
if (rx_fifo_avail > 0 && buf_remaining > 0) {
- BUG_ON(buf_remaining > 3);
val = i2c_readl(i2c_dev, I2C_RX_FIFO);
val = cpu_to_le32(val);
memcpy(buf, , buf_remaining);
@@ -523,7 +523,6 @@ static int tegra_i2c_empty_rx_fifo(struct tegra_i2c_dev
*i2c_dev)
rx_fifo_avail--;
}
- BUG_ON(rx_fifo_avail > 0 && buf_remaining > 0);
i2c_dev->msg_buf_remaining = buf_remaining;
i2c_dev->msg_buf = buf;
@@ -581,7 +580,6 @@ static int tegra_i2c_fill_tx_fifo(struct tegra_i2c_dev
*i2c_dev)
* boundary and fault.
*/
if (tx_fifo_avail > 0 && buf_remaining > 0) {
- BUG_ON(buf_remaining > 3);
memcpy(, buf, buf_remaining);
val = le32_to_cpu(val);
@@ -847,10 +845,13 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
if (!i2c_dev->is_curr_dma_xfer) {
if (i2c_dev->msg_read && (status & I2C_INT_RX_FIFO_DATA_REQ)) {
- if (i2c_dev->msg_buf_remaining)
+ if (i2c_dev->msg_buf_remaining) {
tegra_i2c_empty_rx_fifo(i2c_dev);
- else
- BUG();
+ } else {
+ dev_err(i2c_dev->dev, "unexpected rx data
request\n");
+ i2c_dev->msg_err |= I2C_ERR_UNEXPECTED_STATUS;
+ goto err;
+ }
}
if (!i2c_dev->msg_read && (status & I2C_INT_TX_FIFO_DATA_REQ)) {
@@ -876,7 +877,10 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
if (status & I2C_INT_PACKET_XFER_COMPLETE) {
if (i2c_dev->is_curr_dma_xfer)
i2c_dev->msg_buf_remaining = 0;
- BUG_ON(i2c_dev->msg_buf_remaining);
+ if (WARN_ON_ONCE(i2c_dev->msg_buf_remaining)) {
+ i2c_dev->msg_err |= I2C_ERR_UNKNOWN_INTERRUPT;
+ goto err;
+ }
complete(_dev->msg_complete);
}
goto done;
--
2.7.4
[PATCH V3 3/6] i2c: tegra: fix alignment and spacing violations
Fix checkpatch.pl alignment and blank line check(s) in i2c-tegra.c
Signed-off-by: Bitan Biswas
Reviewed-by: Dmitry Osipenko
---
drivers/i2c/busses/i2c-tegra.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index f7116b7..2d381de 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -295,7 +295,7 @@ static u32 dvc_readl(struct tegra_i2c_dev *i2c_dev,
unsigned long reg)
* to the I2C block inside the DVC block
*/
static unsigned long tegra_i2c_reg_addr(struct tegra_i2c_dev *i2c_dev,
- unsigned long reg)
+ unsigned long reg)
{
if (i2c_dev->is_dvc)
reg += (reg >= I2C_TX_FIFO) ? 0x10 : 0x40;
@@ -303,7 +303,7 @@ static unsigned long tegra_i2c_reg_addr(struct
tegra_i2c_dev *i2c_dev,
}
static void i2c_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
- unsigned long reg)
+ unsigned long reg)
{
writel(val, i2c_dev->base + tegra_i2c_reg_addr(i2c_dev, reg));
@@ -318,13 +318,13 @@ static u32 i2c_readl(struct tegra_i2c_dev *i2c_dev,
unsigned long reg)
}
static void i2c_writesl(struct tegra_i2c_dev *i2c_dev, void *data,
- unsigned long reg, int len)
+ unsigned long reg, int len)
{
writesl(i2c_dev->base + tegra_i2c_reg_addr(i2c_dev, reg), data, len);
}
static void i2c_readsl(struct tegra_i2c_dev *i2c_dev, void *data,
- unsigned long reg, int len)
+ unsigned long reg, int len)
{
readsl(i2c_dev->base + tegra_i2c_reg_addr(i2c_dev, reg), data, len);
}
@@ -669,10 +669,11 @@ static int tegra_i2c_wait_for_config_load(struct
tegra_i2c_dev *i2c_dev)
i2c_writel(i2c_dev, I2C_MSTR_CONFIG_LOAD, I2C_CONFIG_LOAD);
if (in_interrupt())
err = readl_poll_timeout_atomic(addr, val, val == 0,
- 1000, I2C_CONFIG_LOAD_TIMEOUT);
+ 1000,
+
I2C_CONFIG_LOAD_TIMEOUT);
else
- err = readl_poll_timeout(addr, val, val == 0,
- 1000, I2C_CONFIG_LOAD_TIMEOUT);
+ err = readl_poll_timeout(addr, val, val == 0, 1000,
+I2C_CONFIG_LOAD_TIMEOUT);
if (err) {
dev_warn(i2c_dev->dev,
@@ -1013,7 +1014,8 @@ static int tegra_i2c_issue_bus_clear(struct i2c_adapter
*adap)
}
static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
- struct i2c_msg *msg, enum msg_end_type end_state)
+ struct i2c_msg *msg,
+ enum msg_end_type end_state)
{
u32 packet_header;
u32 int_mask;
@@ -1150,9 +1152,8 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
if (err)
return err;
- time_left = wait_for_completion_timeout(
- _dev->dma_complete,
- msecs_to_jiffies(xfer_time));
+ time_left = wait_for_completion_timeout(_dev->dma_complete,
+
msecs_to_jiffies(xfer_time));
if (time_left == 0) {
dev_err(i2c_dev->dev, "DMA transfer timeout\n");
dmaengine_terminate_sync(i2c_dev->msg_read ?
@@ -1214,7 +1215,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
}
static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
- int num)
+ int num)
{
struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(adap);
int i;
@@ -1260,14 +1261,15 @@ static void tegra_i2c_parse_dt(struct tegra_i2c_dev
*i2c_dev)
{
struct device_node *np = i2c_dev->dev->of_node;
int ret;
+ bool multi_mode;
ret = of_property_read_u32(np, "clock-frequency",
- _dev->bus_clk_rate);
+ _dev->bus_clk_rate);
if (ret)
i2c_dev->bus_clk_rate = 10; /* default clock rate */
- i2c_dev->is_multimaster_mode = of_property_read_bool(np,
- "multi-master");
+ multi_mode = of_property_read_bool(np, "multi-master");
+ i2c_dev->is_multimaster_mode = multi_mode;
}
static const struct i2c_algorithm tegra_i2c_algo = {
@@ -1611,7 +1613,7 @@ static int tegra_i2c_probe(struct platform_device *pdev)
}
ret = devm_request_irq(>dev, i2c_dev->irq,
- tegra_i2c_isr, 0, dev_name(>dev), i2c_dev);
+ tegra_i2c_isr, 0, dev_name(>dev), i2c_dev);
if (ret) {
[PATCH V3 4/6] i2c: tegra: add spinlock definition comment
Fix checkpatch.pl CHECK as follows:
CHECK: spinlock_t definition without comment
+ spinlock_t xfer_lock;
Signed-off-by: Bitan Biswas
Reviewed-by: Dmitry Osipenko
---
drivers/i2c/busses/i2c-tegra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 2d381de..bececa6 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -269,6 +269,7 @@ struct tegra_i2c_dev {
u32 bus_clk_rate;
u16 clk_divisor_non_hs_mode;
bool is_multimaster_mode;
+ /* xfer_lock: lock to serialize transfer submission and processing */
spinlock_t xfer_lock;
struct dma_chan *tx_dma_chan;
struct dma_chan *rx_dma_chan;
--
2.7.4
[PATCH V3 1/6] i2c: tegra: clean up macros
Clean up macros by: 1) removing unused macros 2) replace constants by macro BIT() Signed-off-by: Bitan Biswas Reviewed-by: Dmitry Osipenko --- drivers/i2c/busses/i2c-tegra.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c index 1dbba39..00692d8 100644 --- a/drivers/i2c/busses/i2c-tegra.c +++ b/drivers/i2c/busses/i2c-tegra.c @@ -54,20 +54,15 @@ #define I2C_INT_STATUS 0x068 #define I2C_INT_BUS_CLR_DONE BIT(11) #define I2C_INT_PACKET_XFER_COMPLETE BIT(7) -#define I2C_INT_ALL_PACKETS_XFER_COMPLETE BIT(6) -#define I2C_INT_TX_FIFO_OVERFLOW BIT(5) -#define I2C_INT_RX_FIFO_UNDERFLOW BIT(4) #define I2C_INT_NO_ACK BIT(3) #define I2C_INT_ARBITRATION_LOST BIT(2) #define I2C_INT_TX_FIFO_DATA_REQ BIT(1) #define I2C_INT_RX_FIFO_DATA_REQ BIT(0) #define I2C_CLK_DIVISOR0x06c #define I2C_CLK_DIVISOR_STD_FAST_MODE_SHIFT16 -#define I2C_CLK_MULTIPLIER_STD_FAST_MODE 8 #define DVC_CTRL_REG1 0x000 #define DVC_CTRL_REG1_INTR_EN BIT(10) -#define DVC_CTRL_REG2 0x004 #define DVC_CTRL_REG3 0x008 #define DVC_CTRL_REG3_SW_PROG BIT(26) #define DVC_CTRL_REG3_I2C_DONE_INTR_EN BIT(30) @@ -75,24 +70,21 @@ #define DVC_STATUS_I2C_DONE_INTR BIT(30) #define I2C_ERR_NONE 0x00 -#define I2C_ERR_NO_ACK 0x01 -#define I2C_ERR_ARBITRATION_LOST 0x02 -#define I2C_ERR_UNKNOWN_INTERRUPT 0x04 +#define I2C_ERR_NO_ACK BIT(0) +#define I2C_ERR_ARBITRATION_LOST BIT(1) +#define I2C_ERR_UNKNOWN_INTERRUPT BIT(2) #define PACKET_HEADER0_HEADER_SIZE_SHIFT 28 #define PACKET_HEADER0_PACKET_ID_SHIFT 16 #define PACKET_HEADER0_CONT_ID_SHIFT 12 #define PACKET_HEADER0_PROTOCOL_I2CBIT(4) -#define I2C_HEADER_HIGHSPEED_MODE BIT(22) #define I2C_HEADER_CONT_ON_NAK BIT(21) -#define I2C_HEADER_SEND_START_BYTE BIT(20) #define I2C_HEADER_READBIT(19) #define I2C_HEADER_10BIT_ADDR BIT(18) #define I2C_HEADER_IE_ENABLE BIT(17) #define I2C_HEADER_REPEAT_STARTBIT(16) #define I2C_HEADER_CONTINUE_XFER BIT(15) -#define I2C_HEADER_MASTER_ADDR_SHIFT 12 #define I2C_HEADER_SLAVE_ADDR_SHIFT1 #define I2C_BUS_CLEAR_CNFG 0x084 @@ -106,8 +98,6 @@ #define I2C_CONFIG_LOAD0x08C #define I2C_MSTR_CONFIG_LOAD BIT(0) -#define I2C_SLV_CONFIG_LOADBIT(1) -#define I2C_TIMEOUT_CONFIG_LOADBIT(2) #define I2C_CLKEN_OVERRIDE 0x090 #define I2C_MST_CORE_CLKEN_OVR BIT(0) @@ -133,7 +123,6 @@ #define I2C_STANDARD_MODE 10 #define I2C_FAST_MODE 40 #define I2C_FAST_PLUS_MODE 100 -#define I2C_HS_MODE350 /* Packet header size in bytes */ #define I2C_PACKET_HEADER_SIZE 12 -- 2.7.4
[PATCH V3 2/6] i2c: tegra: remove unnecessary variable init
Remove variable initializations in functions that
are followed by assignments before use
Signed-off-by: Bitan Biswas
Reviewed-by: Dmitry Osipenko
---
drivers/i2c/busses/i2c-tegra.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 00692d8..f7116b7 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -689,7 +689,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev,
bool clk_reinit)
u32 val;
int err;
u32 clk_divisor, clk_multiplier;
- u32 tsu_thd = 0;
+ u32 tsu_thd;
u8 tlow, thigh;
err = pm_runtime_get_sync(i2c_dev->dev);
@@ -1218,7 +1218,7 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg msgs[],
{
struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(adap);
int i;
- int ret = 0;
+ int ret;
ret = pm_runtime_get_sync(i2c_dev->dev);
if (ret < 0) {
@@ -1489,7 +1489,7 @@ static int tegra_i2c_probe(struct platform_device *pdev)
void __iomem *base;
phys_addr_t base_phys;
int irq;
- int ret = 0;
+ int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base_phys = res->start;
--
2.7.4
[PATCH V3 5/6] i2c: tegra: fix msleep warning
Fix checkpatch.pl WARNING for delay of approximately 1msec in flush i2c FIFO polling loop by using usleep_range(1000, 2000): WARNING: msleep < 20ms can sleep for up to 20ms; see ... Documentation/timers/timers-howto.txt + msleep(1); Signed-off-by: Bitan Biswas Reviewed-by: Dmitry Osipenko --- drivers/i2c/busses/i2c-tegra.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c index bececa6..4dfb4c1 100644 --- a/drivers/i2c/busses/i2c-tegra.c +++ b/drivers/i2c/busses/i2c-tegra.c @@ -476,7 +476,7 @@ static int tegra_i2c_flush_fifos(struct tegra_i2c_dev *i2c_dev) dev_warn(i2c_dev->dev, "timeout waiting for fifo flush\n"); return -ETIMEDOUT; } - msleep(1); + usleep_range(1000, 2000); } return 0; } -- 2.7.4
Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
On 06/10/2019 10:27 AM, Dave Hansen wrote: > On 6/9/19 9:34 PM, Anshuman Khandual wrote: >>> Do you really think this is easier to read? >>> >>> Why not just move the x86 version to include/linux/kprobes.h, and replace >>> the int with bool? >> Will just return bool directly without an additional variable here as >> suggested >> before. But for the conditional statement, I guess the proposed one here is >> more >> compact than the x86 one. > > FWIW, I don't think "compact" is generally a good goal for code. Being > readable is 100x more important than being compact and being un-compact > is only a problem when it hurts readability. > > For a function like the one in question, having the individual return > conditions clearly commented is way more important than saving 10 lines > of code. Fair enough. Will keep the existing code flow from x86.
RE: [PATCH v7 1/6] dt-bindings: add binding for USBSS-DRD controller.
>>
>>>
>>> Pawel,
>>>
>>> On 05/06/2019 13:03, Pawel Laszczak wrote:
This patch aim at documenting USB related dt-bindings for the
Cadence USBSS-DRD controller.
Signed-off-by: Pawel Laszczak
Reviewed-by: Rob Herring
---
.../devicetree/bindings/usb/cdns-usb3.txt | 30 +++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/cdns-usb3.txt
diff --git a/Documentation/devicetree/bindings/usb/cdns-usb3.txt
b/Documentation/devicetree/bindings/usb/cdns-usb3.txt
new file mode 100644
index ..1d2b449e3cb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cdns-usb3.txt
@@ -0,0 +1,30 @@
+Binding for the Cadence USBSS-DRD controller
+
+Required properties:
+ - reg: Physical base address and size of the controller's register
areas.
+ Controller has 3 different regions:
+ region 1 - HOST registers area
+ region 2 - DEVICE registers area
+ region 3 - OTG/DRD registers area
+ - reg-names - register memory area names:
+ "xhci" - for HOST registers space
+ "dev" - for DEVICE registers space
+ "otg" - for OTG/DRD registers space
+ - compatible: Should contain: "cdns,usb3-1.0.0" or "cdns,usb3-1.0.1"
+ - interrupts: Interrupts used by cdns3 controller.
>>>
>>> Since we are requesting 3 separate named interrupts in code we need to
>>> mention them here.
>>
>> Hi Roger,
>>
>> Yes, I know, but this code is Reviewed-by: Rob Herring, so I thought to add
>> this as separate patch after putting this driver into kernel.
>>
>
>Binding document should be updated as code changes.
>
>> I assume that after making some change in this file I should remove statement
>> Reviewed-by: Rob Herring from this patch to start reviving
>> from the beginning.
>
>Yes.
>
>>
>> What do you think about such dt-binding:
>>
>> Required properties:
>> - reg: Physical base address and size of the controller's register areas.
>> Controller has 3 different regions:
>> region 1 - HOST registers area
>> region 2 - DEVICE registers area
>> region 3 - OTG/DRD registers area
>
>Is it so that region 1 is always HOST?
>offset 0 seems to be OTG though.
>
>If it is implementation specific then you could get rid of numbering.
Right, I rid of numbering.
>
>> - reg-names - register memory area names:
>> "xhci" - for HOST registers space
>> "dev" - for DEVICE registers space
>> "otg" - for OTG/DRD registers space
>> - compatible: Should contain:
>> "cdns,usb3-1.0.0" - for 0x00024502 controller version
>> "cdns,usb3-1.0.1" - for 0x00024509 controller version
>> "cdns,usb3-1.0.2" - for 0x0002450C controller version
>> "cdns,usb3-1.0.3" - for 0x0002450d controller version
>>
>> - interrupts: Interrupts used by cdns3 controller:
>> "host" - interrupt used by XHCI driver.
>> "peripheral" - interrupt used by device driver
>> "otg" - interrupt used by DRD/OTG part of driver
>>
>> Optional properties:
>> - maximum-speed : valid arguments are "super-speed", "high-speed" and
>>"full-speed"; refer to usb/generic.txt
>> - dr_mode: Should be one of "host", "peripheral" or "otg".
>> - phys: reference to the USB PHY
>
>need to add 'phy-names' since you request the PHY with name.
>
>> - on-chip-buff-size : size of memory intended as internal memory for
>> endpoints
>> buffers expressed in KB
>>
>> Example:
>> usb@f300 {
>> compatible = "cdns,usb3-1.0.1";
>> interrupts =
>
>coma missing.
>>
>here too.
>> ;
>
>What is 7 and 8 ?
Interrupt line number. As I remember device and host are connected to the same
interrupt
line.
I'm not sure but first element is probably the number indicating of Interrupt
controller,
so rather It should has the same name for all interrupts entries. I will change
it to GIC_USB_IRQ.
>
>> interrupt-names = "host", "peripheral", "otg";
>> reg = <0xf300 0x1 /* memory area for HOST
>> registers */
>
>should end with >,
I've checked in other dt-binding, and there use in this form.
I will change it. Checkpatch script doesn't complain for both version.
>
>> 0xf301 0x1 /* memory area for DEVICE
>> registers */
>here too
>
>> 0xf302 0x1>;/* memory area for OTG/DRD
>> registers */
>> reg-names = "xhci", "dev", "otg";
>> };
>
>Isn't otg at offset 0, xhci at offset 0x1 and dev at offset 0x2?
I think that it's FPGA implementation specific. I have connected registers in
this way.
In register specification OTG offset is 0.
>
>>
>> Is this correct now ?
>>
>> Maybe I should add something
Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
On 6/9/19 9:34 PM, Anshuman Khandual wrote: >> Do you really think this is easier to read? >> >> Why not just move the x86 version to include/linux/kprobes.h, and replace >> the int with bool? > Will just return bool directly without an additional variable here as > suggested > before. But for the conditional statement, I guess the proposed one here is > more > compact than the x86 one. FWIW, I don't think "compact" is generally a good goal for code. Being readable is 100x more important than being compact and being un-compact is only a problem when it hurts readability. For a function like the one in question, having the individual return conditions clearly commented is way more important than saving 10 lines of code.
Re: [RFC PATCH 5/6] dt-bindings: soundwire: add bindings for Qcom controller
On 07-06-19, 09:56, Srinivas Kandagatla wrote: > This patch adds bindings for Qualcomm soundwire controller. > > Qualcomm SoundWire Master controller is present in most Qualcomm SoCs > either integrated as part of WCD audio codecs via slimbus or > as part of SOC I/O. > > Signed-off-by: Srinivas Kandagatla > --- > .../bindings/soundwire/qcom,swr.txt | 62 +++ So I was expecting to see bus support patches for OF first. I think you have missed those changes. Please do include those in v2 with bindings and OF support for bus. > 1 file changed, 62 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,swr.txt > > diff --git a/Documentation/devicetree/bindings/soundwire/qcom,swr.txt > b/Documentation/devicetree/bindings/soundwire/qcom,swr.txt > new file mode 100644 > index ..eb84d0f4f36f > --- /dev/null > +++ b/Documentation/devicetree/bindings/soundwire/qcom,swr.txt > @@ -0,0 +1,62 @@ > +Qualcomm SoundWire Controller > + > +This binding describes the Qualcomm SoundWire Controller Bindings. > + > +Required properties: > + > +- compatible:Must be > "qcom,soundwire-v..", > + example: > + "qcom,soundwire-v1.3.0" > + "qcom,soundwire-v1.5.0" > + "qcom,soundwire-v1.6.0" > +- reg: SoundWire controller address space. > +- interrupts:SoundWire controller interrupt. > +- clock-names: Must contain "iface". > +- clocks:Interface clocks needed for controller. > +- #sound-dai-cells: Must be 1 for digital audio interfaces on the > controllers. > +- #address-cells:Must be 1 for SoundWire devices; > +- #size-cells: Must be <0> as SoundWire addresses have no size > component. > +- qcom,dout-ports: Must be count of data out ports > +- qcom,din-ports:Must be count of data in ports On these I think we should have specified dpn properties as specified in DisCo, but then looking at spec we do not define that for master, but bus seems to have it. Pierre do you why master does not have dpn properties in DisCo? > +- qcom,ports-offset1:Must be frame offset1 of each data port. > + Out followed by In. Used for Block size calculation. > +- qcom,ports-offset2:Must be frame offset2 of each data port. > + Out followed by In. Used for Block size calculation. > +- qcom,ports-sinterval-low: Must be sample interval low of each data port. > + Out followed by In. Used for Sample Interval > calculation. These are software so do not belong here -- ~Vinod
Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
okay. curious is, that my variant works with sane results too.
i will test your variant and check the results
Sebastian
Am 10.06.2019 um 06:22 schrieb Ryder Lee:
On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
according to my findings
MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
so it must be rxdg4 = rxd[4] etc.
RXV start from 1 in the code.
That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal
calculation.
i already wrote a similar code for this driver which i sended to felix a long
time ago.
my variant looks like
status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220)
/ 2;
status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) -
220) / 2;
status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) -
220) / 2;
status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) -
220) / 2;
status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) -
220) / 2;
mt7615 actually doesn't use in-band RSSI for signal calculation, but it
occurs to me that i should modify the code to compare per-chain's
signal. Something like this:
status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
status->signal = status->chain_signal[0];
switch (status->chains) {
case 0xf:
status->signal = max(status->signal,
status->chain_signal[3]);
case 0x7:
status->signal = max(status->signal,
status->chain_signal[2]);
case 0x3:
status->signal = max(status->signal,
status->chain_signal[1]);
break;
default:
break;
}
I could send a v2 or you can take care of that.
Ryder
Re: [PATCH] staging: rtl8723bs: core: rtw_mlme_ext.c: Remove unused variables
On 09/06/19 4:32 PM, Greg KH wrote: On Fri, Jun 07, 2019 at 12:41:23PM +0530, Nishka Dasgupta wrote: Remove variables that are declared and assigned values but not otherwise used. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta --- drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 9 - 1 file changed, 9 deletions(-) You sent me 8 patches for this driver, yet only 2 were ordered in a series. I have no idea what order to apply these in :( Please resend them _all_ in a numbered patch series so I have a chance to get this correct. Yes, I can do that. Who do I send the patch series to in that case? The maintainers list is slightly different for each file, and most of the patches in this driver are for different and unrelated files (except, I think, the two that I did send as a patch series). Do I combine the maintainers lists and send the entire patch series to everyone listed as a maintainer for any one of the patches in it? Thanking you, Nishka thanks, greg k-h
Re: [RFC PATCH 1/6] ASoC: core: add support to snd_soc_dai_get_sdw_stream()
On 07-06-19, 09:56, Srinivas Kandagatla wrote:
> On platforms which have smart speaker amplifiers connected via
> soundwire and modeled as aux devices in ASoC, in such usecases machine
> driver should be able to get sdw master stream from dai so that it can
> use the runtime stream to setup slave streams.
>
> soundwire already as a set function, get function would provide more
> flexibility to above configurations.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> include/sound/soc-dai.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
> index f5d70041108f..9f90b936fd9a 100644
> --- a/include/sound/soc-dai.h
> +++ b/include/sound/soc-dai.h
> @@ -177,6 +177,7 @@ struct snd_soc_dai_ops {
>
> int (*set_sdw_stream)(struct snd_soc_dai *dai,
> void *stream, int direction);
> + void *(*get_sdw_stream)(struct snd_soc_dai *dai, int direction);
So who would be calling this API? Machine or someone else?
--
~Vinod
Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
On 06/07/2019 08:36 PM, Dave Hansen wrote:
> On 6/7/19 3:34 AM, Anshuman Khandual wrote:
>> +static nokprobe_inline bool kprobe_page_fault(struct pt_regs *regs,
>> + unsigned int trap)
>> +{
>> +int ret = 0;
>> +
>> +/*
>> + * To be potentially processing a kprobe fault and to be allowed
>> + * to call kprobe_running(), we have to be non-preemptible.
>> + */
>> +if (kprobes_built_in() && !preemptible() && !user_mode(regs)) {
>> +if (kprobe_running() && kprobe_fault_handler(regs, trap))
>> +ret = 1;
>> +}
>> +return ret;
>> +}
>
> Nits: Other that taking the nice, readable, x86 one and globbing it onto
> a single line, looks OK to me. It does seem a _bit_ silly to go to the
> trouble of converting to 'bool' and then using 0/1 and an 'int'
> internally instead of true/false and a bool, though. It's also not a
Changing to 'bool'...
> horrible thing to add a single line comment to this sucker to say:
>
> /* returns true if kprobes handled the fault */
>
Picking this in-code comment.
> In any case, and even if you don't clean any of this up:
>
> Reviewed-by: Dave Hansen
>
Thanks !
Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
On 06/08/2019 01:42 AM, Matthew Wilcox wrote:
> Before:
>
>> @@ -46,23 +46,6 @@ kmmio_fault(struct pt_regs *regs, unsigned long addr)
>> return 0;
>> }
>>
>> -static nokprobe_inline int kprobes_fault(struct pt_regs *regs)
>> -{
>> -if (!kprobes_built_in())
>> -return 0;
>> -if (user_mode(regs))
>> -return 0;
>> -/*
>> - * To be potentially processing a kprobe fault and to be allowed to call
>> - * kprobe_running(), we have to be non-preemptible.
>> - */
>> -if (preemptible())
>> -return 0;
>> -if (!kprobe_running())
>> -return 0;
>> -return kprobe_fault_handler(regs, X86_TRAP_PF);
>> -}
>
> After:
>
>> +++ b/include/linux/kprobes.h
>> @@ -458,4 +458,20 @@ static inline bool is_kprobe_optinsn_slot(unsigned long
>> addr)
>> }
>> #endif
>>
>> +static nokprobe_inline bool kprobe_page_fault(struct pt_regs *regs,
>> + unsigned int trap)
>> +{
>> +int ret = 0;
>> +
>> +/*
>> + * To be potentially processing a kprobe fault and to be allowed
>> + * to call kprobe_running(), we have to be non-preemptible.
>> + */
>> +if (kprobes_built_in() && !preemptible() && !user_mode(regs)) {
>> +if (kprobe_running() && kprobe_fault_handler(regs, trap))
>> +ret = 1;
>> +}
>> +return ret;
>> +}
>
> Do you really think this is easier to read?
>
> Why not just move the x86 version to include/linux/kprobes.h, and replace
> the int with bool?
Will just return bool directly without an additional variable here as suggested
before. But for the conditional statement, I guess the proposed one here is more
compact than the x86 one.
>
> On Fri, Jun 07, 2019 at 04:04:15PM +0530, Anshuman Khandual wrote:
>> Very similar definitions for notify_page_fault() are being used by multiple
>> architectures duplicating much of the same code. This attempts to unify all
>> of them into a generic implementation, rename it as kprobe_page_fault() and
>> then move it to a common header.
>
> I think this description suffers from having been written for v1 of
> this patch. It describes what you _did_, but it's not what this patch
> currently _is_.
>
> Why not something like:
>
> Architectures which support kprobes have very similar boilerplate around
> calling kprobe_fault_handler(). Use a helper function in kprobes.h to
> unify them, based on the x86 code.
>
> This changes the behaviour for other architectures when preemption
> is enabled. Previously, they would have disabled preemption while
> calling the kprobe handler. However, preemption would be disabled
> if this fault was due to a kprobe, so we know the fault was not due
> to a kprobe handler and can simply return failure. This behaviour was
> introduced in commit a980c0ef9f6d ("x86/kprobes: Refactor kprobes_fault()
> like kprobe_exceptions_notify()")
Will replace commit message with above.
>
>> arch/arm/mm/fault.c | 24 +---
>> arch/arm64/mm/fault.c| 24 +---
>> arch/ia64/mm/fault.c | 24 +---
>> arch/powerpc/mm/fault.c | 23 ++-
>> arch/s390/mm/fault.c | 16 +---
>> arch/sh/mm/fault.c | 18 ++
>> arch/sparc/mm/fault_64.c | 16 +---
>> arch/x86/mm/fault.c | 21 ++---
>> include/linux/kprobes.h | 16
>
> What about arc and mips?
+ Vineet Gupta
+ linux-snps-...@lists.infradead.org
+ James Hogan
+ Paul Burton
+ Ralf Baechle
+ linux-m...@vger.kernel.org
Both the above architectures dont call kprobe_fault_handler() from the
page fault context (do_page_fault() to be specific). Though it gets called
from mips kprobe_exceptions_notify (DIE_PAGE_FAULT). Am I missing something
here ?
Re: [PATCH 1/2] staging: rtl8712: r8712_setdatarate_cmd(): Change
On 07/06/19 7:45 PM, Dan Carpenter wrote: Probably you sent this patch unintentionally. The subject doesn't make any sort of sense. :P So the problem with the subject line is that git send-email and vim (as configured on my laptop) tend to line-wrap even the subject line. Since I have two patches that do the same thing for different functions, I felt I should have the driver and the function name in the subject line (to avoid confusion between the patches and to allow for easy searching later). But that doesn't leave enough space in the subject line for "Change return values/type" or any other descriptive message. What should I do? On Fri, Jun 07, 2019 at 07:36:57PM +0530, Nishka Dasgupta wrote: Change the return values of function r8712_setdatarate_cmd from _SUCCESS and _FAIL to 0 and -ENOMEM respectively. Change the return type of the function from u8 to int to reflect this. Change the call site of the function to check for 0 instead of _SUCCESS. (Checking that the return value != 0 is not necessary; the return value ^^^ itself can simply be passed into the conditional.) ^ This is obvious. No need to mention it in the commit message. Okay, I'll amend that. diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c index b424b8436fcf..761e2ba68a42 100644 --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c @@ -1367,7 +1367,7 @@ static int r8711_wx_set_rate(struct net_device *dev, datarates[i] = 0xff; } } - if (r8712_setdatarate_cmd(padapter, datarates) != _SUCCESS) + if (r8712_setdatarate_cmd(padapter, datarates)) ret = -ENOMEM; return ret; It would be better to write this like so: ret = r8712_setdatarate_cmd(padapter, datarates); if (ret) return ret; return 0; Or you could write it like: return r8712_setdatarate_cmd(padapter, datarates); Okay, since this is the only point at which a return happens in this function, I can do this. Which ever one you prefer is fine Thanking you, Nishka regards, dan carpenter
Re: [PATCH v2 0/3] KVM: LAPIC: Implement Exitless Timer
On Thu, 6 Jun 2019 at 13:31, Wanpeng Li wrote:
>
> Dedicated instances are currently disturbed by unnecessary jitter due
> to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
> There is no hardware virtual timer on Intel for guest like ARM. Both
> programming timer in guest and the emulated timer fires incur vmexits.
> This patchset tries to avoid vmexit which is incurred by the emulated
> timer fires in dedicated instance scenario.
>
> When nohz_full is enabled in dedicated instances scenario, the unpinned
> timer will be moved to the nearest busy housekeepers after commit 444969223c8
> ("sched/nohz: Fix affine unpinned timers mess"). However, KVM always makes
> lapic timer pinned to the pCPU which vCPU residents, the reason is explained
> by commit 61abdbe0 (kvm: x86: make lapic hrtimer pinned). Actually, these
> emulated timers can be offload to the housekeeping cpus since APICv
> is really common in recent years. The guest timer interrupt is injected by
> posted-interrupt which is delivered by housekeeping cpu once the emulated
> timer fires.
>
> The host admin should fine tuned, e.g. dedicated instances scenario w/
> nohz_full cover the pCPUs which vCPUs resident, several pCPUs surplus
> for housekeeping, disable mwait/hlt/pause vmexits to occupy the pCPUs,
> fortunately preemption timer is disabled after mwait is exposed to
> guest which makes emulated timer offload can be possible.
> 3%~5% redis performance benefit can be observed on Skylake server.
w/o patchset:
VM-EXITSamples Samples% Time%
Min TimeMax Time Avg time
EXTERNAL_INTERRUPT 4291649.43%39.30% 0.47us
106.09us 0.71us ( +- 1.09% )
w/ patchset:
VM-EXITSamples Samples% Time%
Min TimeMax Time Avg time
EXTERNAL_INTERRUPT 6871 9.29% 2.96% 0.44us
57.88us 0.72us ( +- 4.02% )
Regards,
Wanpeng Li
Re: [PATCH v3 1/9] Documentation: Introduce EPT based Subpage Protection
On Fri, Jun 7, 2019 at 7:12 AM Yang Weijiang wrote: > > On Thu, Jun 06, 2019 at 09:57:00PM -0600, Jidong Xiao wrote: > > Hi, Weijiang, > > > > Does this require some specific Intel processors or is it supported by > > older processors as well? > > > > -Jidong > Hi, Jidong, > SPP is a feature on new platforms, so only available with new > Intel processors. Oh, I see. Thanks! -Jidong > > > > On Thu, Jun 6, 2019 at 9:33 AM Yang Weijiang > > wrote: > > > > > > Signed-off-by: Yang Weijiang > > > --- > > > Documentation/virtual/kvm/spp_kvm.txt | 216 ++ > > > 1 file changed, 216 insertions(+) > > > create mode 100644 Documentation/virtual/kvm/spp_kvm.txt > > > > > > diff --git a/Documentation/virtual/kvm/spp_kvm.txt > > > b/Documentation/virtual/kvm/spp_kvm.txt > > > new file mode 100644 > > > index ..4b5edcaf48b6 > > > --- /dev/null > > > +++ b/Documentation/virtual/kvm/spp_kvm.txt > > > @@ -0,0 +1,216 @@ > > > +EPT-Based Sub-Page Protection (SPP) for KVM > > > += > > > + > > > +1. Overview > > > + > > > +EPT-based Sub-Page Protection (SPP) capability to allow Virtual Machine > > > +Monitors to specify write-protection for guest physical memory at a > > > +sub-page (128 byte) granularity. When this capability is utilized, the > > > +CPU enforces write-access permissions for sub-page regions inside 4K > > > pages > > > +as specified by the VMI tools. > > > + > > > +2. Operation of SPP > > > + > > > +Sub-Page Protection Table (SPPT) is introduced to manage sub-page > > > +write-access. > > > + > > > +SPPT is active when: > > > +a) moddule parameter spp=on is configured for kvm-intel.ko > > > +b) large paging is disabled on host > > > +c) "sub-page write protection" VM-execution control bit is set > > > +SPPT looks up the guest physical address to seek a 64-bit > > > +bitmap indicating sub-page write permission in SPPT leaf entry. > > > + > > > +When the "sub-page write protection" VM-execution control is 1, the SPPT > > > +is used to lookup write permission bits for the 128 byte sub-page regions > > > +contained in the 4KB guest physical page. EPT specifies the 4KB page > > > +write-protection privilege whereas SPPT defines the write permissions > > > +at 128-byte granularity within one 4KB page. Write accesses > > > +prevented due to sub-page permissions induces EPT violation VM exits. > > > +Similar to EPT, a logical processor uses SPPT to lookup sub-page level > > > +write permissions for guest-physical addresses only when those addresses > > > +are used to access memory. > > > +__ > > > + > > > +How SPP hardware works: > > > +__ > > > + > > > +Guest write access --> GPA --> Walk EPT --> EPT leaf entry -| > > > +|---| > > > +|-> if VMexec_control.spp && ept_leaf_entry.spp_bit (bit 61) > > > + | > > > + |-> --> EPT legacy behavior > > > + | > > > + | > > > + |-> --> if ept_leaf_entry.writable > > > + | > > > + |-> --> Ignore SPP > > > + | > > > + |-> --> GPA --> Walk SPP 4-level table--| > > > + | > > > +|<--get-the-SPPT-point-from-VMCS-filed-<--| > > > +| > > > +Walk SPP L4E table > > > +| > > > +|---> if-entry-misconfiguration >---|---<-| > > > + | | | > > > +else| | > > > + | | | > > > + | |--SPP VMexit<-| | > > > + | || > > > + | |-> exit_qualification & sppt_misconfig --> sppt misconfig | > > > + | || > > > + | |-> exit_qualification & sppt_miss --> sppt miss | > > > + |---|| > > > + || > > > +walk SPPT L3E--|--> if-entry-misconfiguration>| > > > + | | > > > + else| > > > + | | > > > + | | > > > +walk SPPT L2E --|--> if-entry-misconfiguration>---| > > > +| | > > > +
Re: [PATCH v4 2/5] x86/umwait: Initialize umwait control values
On Sun, Jun 9, 2019 at 9:23 PM Fenghua Yu wrote: > > On Sat, Jun 08, 2019 at 03:52:42PM -0700, Andy Lutomirski wrote: > > On Fri, Jun 7, 2019 at 3:10 PM Fenghua Yu wrote: > > > > > > umwait or tpause allows processor to enter a light-weight > > > power/performance optimized state (C0.1 state) or an improved > > > power/performance optimized state (C0.2 state) for a period > > > specified by the instruction or until the system time limit or until > > > a store to the monitored address range in umwait. > > > > > > IA32_UMWAIT_CONTROL MSR register allows kernel to enable/disable C0.2 > > > on the processor and set maximum time the processor can reside in > > > C0.1 or C0.2. > > > > > > By default C0.2 is enabled so the user wait instructions can enter the > > > C0.2 state to save more power with slower wakeup time. > > > > Sounds good, but: > > > > > +#define MSR_IA32_UMWAIT_CONTROL_C02BIT(0) > > > > > +static u32 umwait_control_cached = 10; > > > > The code seems to disagree. > > The definition of bit[0] is: C0.2 is disabled when bit[0]=1. So > 10 means C0.2 is enabled (and max time is 10). > > Would it be better to change > +#define MSR_IA32_UMWAIT_CONTROL_C02BIT(0) > to > +#define MSR_IA32_UMWAIT_CONTROL_C02_DISABLEDBIT(0) Sounds like a good improvement. Thanks, Andy > ? > > Thanks. > > -Fenghua
Re: [PATCH v4 3/5] x86/umwait: Add sysfs interface to control umwait C0.2 state
On Sun, Jun 9, 2019 at 9:14 PM Fenghua Yu wrote:
>
> On Sat, Jun 08, 2019 at 03:52:03PM -0700, Andy Lutomirski wrote:
> > On Fri, Jun 7, 2019 at 3:10 PM Fenghua Yu wrote:
> > >
> > > C0.2 state in umwait and tpause instructions can be enabled or disabled
> > > on a processor through IA32_UMWAIT_CONTROL MSR register.
> > >
> >
> > > +static u32 get_umwait_control_c02(void)
> > > +{
> > > + return umwait_control_cached & MSR_IA32_UMWAIT_CONTROL_C02;
> > > +}
> > > +
> > > +static u32 get_umwait_control_max_time(void)
> > > +{
> > > + return umwait_control_cached & MSR_IA32_UMWAIT_CONTROL_MAX_TIME;
> > > +}
> > > +
> >
> > I'm not convinced that these helpers make the code any more readable.
>
> The helpers reduce length of statements that call them. Otherwise, all of
> the statements would be easily over 80 characters.
>
> Plus, each of the helpers is called multiple places in #0003 and #0004.
> So the helpers make the patches smaller and cleaner.
>
I was imagining things like:
umwait_control_cached &= ~MSR_IA32_UMWAIT_CONTROL_C02;
if (whatever condition)
umwait_control_cached |= MSR_IA32_UMWAIT_CONTROL_C02;
umwait_control_cached &= ~MSR_IA32_UMWAIT_CONTROL_MAX_TIME;
umwait_control_cached |= new_max_time;
You could save 8 characters by just calling the variable umwait_control.
Re: [PATCH v4 3/5] x86/umwait: Add sysfs interface to control umwait C0.2 state
On Sun, Jun 9, 2019 at 9:02 PM Fenghua Yu wrote:
>
> On Sat, Jun 08, 2019 at 03:50:32PM -0700, Andy Lutomirski wrote:
> > On Fri, Jun 7, 2019 at 3:10 PM Fenghua Yu wrote:
> > >
> > > C0.2 state in umwait and tpause instructions can be enabled or disabled
> > > on a processor through IA32_UMWAIT_CONTROL MSR register.
> > >
> > > By default, C0.2 is enabled and the user wait instructions result in
> > > lower power consumption with slower wakeup time.
> > >
> > > But in real time systems which require faster wakeup time although power
> > > savings could be smaller, the administrator needs to disable C0.2 and all
> > > C0.2 requests from user applications revert to C0.1.
> > >
> > > A sysfs interface "/sys/devices/system/cpu/umwait_control/enable_c02" is
> > > created to allow the administrator to control C0.2 state during run time.
> >
> > This looks better than the previous version. I think the locking is
> > still rather confused. You have a mutex that you hold while changing
> > the value, which is entirely reasonable. But, of the code paths that
> > write the MSR, only one takes the mutex.
> >
> > I think you should consider making a function that just does:
> >
> > wrmsr(MSR_IA32_UMWAIT_CONTROL, READ_ONCE(umwait_control_cached), 0);
> >
> > and using it in all the places that update the MSR. The only thing
> > that should need the lock is the sysfs code to avoid accidentally
> > corrupting the value, but that code should also use WRITE_ONCE to do
> > its update.
>
> Based on the comment, the illustrative CPU online and enable_c02 store
> functions would be:
>
> umwait_cpu_online()
> {
> wrmsr(MSR_IA32_UMWAIT_CONTROL, READ_ONCE(umwait_control_cached), 0);
> return 0;
> }
>
> enable_c02_store()
> {
>mutex_lock(_lock);
>umwait_control_c02 = (u32)!c02_enabled;
>WRITE_ONCE(umwait_control_cached, 2 | get_umwait_control_max_time());
>on_each_cpu(umwait_control_msr_update, NULL, 1);
>mutex_unlock(_lock);
> }
>
> Then suppose umwait_control_cached = 10 initially and only CPU0 is
> running. Admin change bit 0 in MSR from 0 to 1 to disable C0.2 and is
> onlining CPU1 in the same time:
>
> 1. On CPU1, read umwait_control_cached to eax as 10 in
> umwait_cpu_online()
> 2. On CPU0, write 11 to umwait_control_cached in enable_c02_store()
> 3. On CPU1, wrmsr with eax=10 in umwaint_cpu_online()
> 4. On CPU0, wrmsr with 11 in enabled_c02_store()
>
> The result is CPU0 and CPU1 have different MSR values.
Yes, but only transiently, because you didn't finish your example.
Step 5: enable_c02_store() does on_each_cpu(), and CPU 1 gets updated.
Re: [PATCH v4 2/5] x86/umwait: Initialize umwait control values
On Sat, Jun 08, 2019 at 03:52:42PM -0700, Andy Lutomirski wrote: > On Fri, Jun 7, 2019 at 3:10 PM Fenghua Yu wrote: > > > > umwait or tpause allows processor to enter a light-weight > > power/performance optimized state (C0.1 state) or an improved > > power/performance optimized state (C0.2 state) for a period > > specified by the instruction or until the system time limit or until > > a store to the monitored address range in umwait. > > > > IA32_UMWAIT_CONTROL MSR register allows kernel to enable/disable C0.2 > > on the processor and set maximum time the processor can reside in > > C0.1 or C0.2. > > > > By default C0.2 is enabled so the user wait instructions can enter the > > C0.2 state to save more power with slower wakeup time. > > Sounds good, but: > > > +#define MSR_IA32_UMWAIT_CONTROL_C02BIT(0) > > > +static u32 umwait_control_cached = 10; > > The code seems to disagree. The definition of bit[0] is: C0.2 is disabled when bit[0]=1. So 10 means C0.2 is enabled (and max time is 10). Would it be better to change +#define MSR_IA32_UMWAIT_CONTROL_C02BIT(0) to +#define MSR_IA32_UMWAIT_CONTROL_C02_DISABLEDBIT(0) ? Thanks. -Fenghua
Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
> On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> > according to my findings
> >
> > MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> > so it must be rxdg4 = rxd[4] etc.
>
> RXV start from 1 in the code.
>
> That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
>
> > however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal
> > calculation.
> > i already wrote a similar code for this driver which i sended to felix a
> > long time ago.
> > my variant looks like
> > status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) -
> > 220) / 2;
> > status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4)
> > - 220) / 2;
> > status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4)
> > - 220) / 2;
> > status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4)
> > - 220) / 2;
> > status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4)
> > - 220) / 2;
mt7615 actually doesn't use in-band RSSI for signal calculation, but it
occurs to me that i should modify the code to compare per-chain's
signal. Something like this:
status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
status->signal = status->chain_signal[0];
switch (status->chains) {
case 0xf:
status->signal = max(status->signal,
status->chain_signal[3]);
case 0x7:
status->signal = max(status->signal,
status->chain_signal[2]);
case 0x3:
status->signal = max(status->signal,
status->chain_signal[1]);
break;
default:
break;
}
I could send a v2 or you can take care of that.
Ryder
Re: [PATCH v4 3/5] x86/umwait: Add sysfs interface to control umwait C0.2 state
On Sat, Jun 08, 2019 at 03:52:03PM -0700, Andy Lutomirski wrote:
> On Fri, Jun 7, 2019 at 3:10 PM Fenghua Yu wrote:
> >
> > C0.2 state in umwait and tpause instructions can be enabled or disabled
> > on a processor through IA32_UMWAIT_CONTROL MSR register.
> >
>
> > +static u32 get_umwait_control_c02(void)
> > +{
> > + return umwait_control_cached & MSR_IA32_UMWAIT_CONTROL_C02;
> > +}
> > +
> > +static u32 get_umwait_control_max_time(void)
> > +{
> > + return umwait_control_cached & MSR_IA32_UMWAIT_CONTROL_MAX_TIME;
> > +}
> > +
>
> I'm not convinced that these helpers make the code any more readable.
The helpers reduce length of statements that call them. Otherwise, all of
the statements would be easily over 80 characters.
Plus, each of the helpers is called multiple places in #0003 and #0004.
So the helpers make the patches smaller and cleaner.
So is it still OK to keep the helpers?
Thanks.
-Fenghua
Re: [PATCH v4 3/5] x86/umwait: Add sysfs interface to control umwait C0.2 state
On Sat, Jun 08, 2019 at 03:50:32PM -0700, Andy Lutomirski wrote:
> On Fri, Jun 7, 2019 at 3:10 PM Fenghua Yu wrote:
> >
> > C0.2 state in umwait and tpause instructions can be enabled or disabled
> > on a processor through IA32_UMWAIT_CONTROL MSR register.
> >
> > By default, C0.2 is enabled and the user wait instructions result in
> > lower power consumption with slower wakeup time.
> >
> > But in real time systems which require faster wakeup time although power
> > savings could be smaller, the administrator needs to disable C0.2 and all
> > C0.2 requests from user applications revert to C0.1.
> >
> > A sysfs interface "/sys/devices/system/cpu/umwait_control/enable_c02" is
> > created to allow the administrator to control C0.2 state during run time.
>
> This looks better than the previous version. I think the locking is
> still rather confused. You have a mutex that you hold while changing
> the value, which is entirely reasonable. But, of the code paths that
> write the MSR, only one takes the mutex.
>
> I think you should consider making a function that just does:
>
> wrmsr(MSR_IA32_UMWAIT_CONTROL, READ_ONCE(umwait_control_cached), 0);
>
> and using it in all the places that update the MSR. The only thing
> that should need the lock is the sysfs code to avoid accidentally
> corrupting the value, but that code should also use WRITE_ONCE to do
> its update.
Based on the comment, the illustrative CPU online and enable_c02 store
functions would be:
umwait_cpu_online()
{
wrmsr(MSR_IA32_UMWAIT_CONTROL, READ_ONCE(umwait_control_cached), 0);
return 0;
}
enable_c02_store()
{
mutex_lock(_lock);
umwait_control_c02 = (u32)!c02_enabled;
WRITE_ONCE(umwait_control_cached, 2 | get_umwait_control_max_time());
on_each_cpu(umwait_control_msr_update, NULL, 1);
mutex_unlock(_lock);
}
Then suppose umwait_control_cached = 10 initially and only CPU0 is
running. Admin change bit 0 in MSR from 0 to 1 to disable C0.2 and is
onlining CPU1 in the same time:
1. On CPU1, read umwait_control_cached to eax as 10 in
umwait_cpu_online()
2. On CPU0, write 11 to umwait_control_cached in enable_c02_store()
3. On CPU1, wrmsr with eax=10 in umwaint_cpu_online()
4. On CPU0, wrmsr with 11 in enabled_c02_store()
The result is CPU0 and CPU1 have different MSR values.
The problem is because there is no wrmsr serialization b/w uwait_cpu_online()
and enable_c02_store(). The WRITE_ONCE() and READ_ONCE() only serialize
access to umwait_control_cached. But we need to serialize wrmsr() as well to
guarantee all CPUs have the same MSR value.
So does it make sense to keep the mutex and locking as the current patch does?
Thanks.
-Fenghua
[PATCH] tracing: Fix out-of-range read in trace_stack_print()
Puts range check before dereferencing the pointer.
Reproducer:
# echo stacktrace > trace_options
# echo 1 > events/enable
# cat trace > /dev/null
KASAN report:
==
BUG: KASAN: use-after-free in trace_stack_print+0x26b/0x2c0
Read of size 8 at addr 888069d2 by task cat/1953
CPU: 0 PID: 1953 Comm: cat Not tainted 5.2.0-rc3+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30
04/01/2014
Call Trace:
dump_stack+0x8a/0xce
print_address_description+0x60/0x224
? trace_stack_print+0x26b/0x2c0
? trace_stack_print+0x26b/0x2c0
__kasan_report.cold+0x1a/0x3e
? trace_stack_print+0x26b/0x2c0
kasan_report+0xe/0x20
trace_stack_print+0x26b/0x2c0
print_trace_line+0x6ea/0x14d0
? tracing_buffers_read+0x700/0x700
? trace_find_next_entry_inc+0x158/0x1d0
s_show+0xea/0x310
seq_read+0xaa7/0x10e0
? seq_escape+0x230/0x230
__vfs_read+0x7c/0x100
vfs_read+0x16c/0x3a0
ksys_read+0x121/0x240
? kernel_write+0x110/0x110
? perf_trace_sys_enter+0x8a0/0x8a0
? syscall_slow_exit_work+0xa9/0x410
do_syscall_64+0xb7/0x390
? prepare_exit_to_usermode+0x165/0x200
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f867681f910
Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f 1f 44
00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 04
RSP: 002b:7ffdabf23488 EFLAGS: 0246 ORIG_RAX:
RAX: ffda RBX: 0002 RCX: 7f867681f910
RDX: 0002 RSI: 7f8676cde000 RDI: 0003
RBP: 7f8676cde000 R08: R09:
R10: 0871 R11: 0246 R12: 7f8676cde000
R13: 0003 R14: 0002 R15: 0ec0
Allocated by task 1214:
save_stack+0x1b/0x80
__kasan_kmalloc.constprop.0+0xc2/0xd0
kmem_cache_alloc+0xaf/0x1a0
getname_flags+0xd2/0x5b0
do_sys_open+0x277/0x5a0
do_syscall_64+0xb7/0x390
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 1214:
save_stack+0x1b/0x80
__kasan_slab_free+0x12c/0x170
kmem_cache_free+0x8a/0x1c0
putname+0xe1/0x120
do_sys_open+0x2c5/0x5a0
do_syscall_64+0xb7/0x390
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at 888069d2
which belongs to the cache names_cache of size 4096
The buggy address is located 0 bytes inside of
4096-byte region [888069d2, 888069d21000)
The buggy address belongs to the page:
page:ea0001a74800 refcount:1 mapcount:0 mapping:88806ccd1380
index:0x0 compound_mapcount: 0
flags: 0x1010200(slab|head)
raw: 01010200 dead0100 dead0200 88806ccd1380
raw: 00070007 0001
page dumped because: kasan: bad access detected
Memory state around the buggy address:
888069d1ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
888069d1ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>888069d2: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
888069d20080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
888069d20100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==
Fixes: 4a9bd3f134dec ("tracing: Have dynamic size event stack traces")
Signed-off-by: Eiichi Tsukata
---
kernel/trace/trace_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 54373d93e251..ba751f993c3b 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -1057,7 +1057,7 @@ static enum print_line_t trace_stack_print(struct
trace_iterator *iter,
trace_seq_puts(s, "\n");
- for (p = field->caller; p && *p != ULONG_MAX && p < end; p++) {
+ for (p = field->caller; p && p < end && *p != ULONG_MAX; p++) {
if (trace_seq_has_overflowed(s))
break;
--
2.21.0
Re: [PATCH V2 6/6] i2c: tegra: remove BUG, BUG_ON
On 6/7/19 12:47 PM, Dmitry Osipenko wrote:
07.06.2019 22:30, Bitan Biswas пишет:
Remove redundant BUG_ON calls or replace with WARN_ON_ONCE
as needed. Replace BUG() with error handling code.
Define I2C_ERR_UNEXPECTED_STATUS for error handling.
Signed-off-by: Bitan Biswas
---
drivers/i2c/busses/i2c-tegra.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 4dfb4c1..c89d0ee 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -73,6 +73,7 @@
#define I2C_ERR_NO_ACKBIT(0)
#define I2C_ERR_ARBITRATION_LOST BIT(1)
#define I2C_ERR_UNKNOWN_INTERRUPT BIT(2)
+#define I2C_ERR_UNEXPECTED_STATUS BIT(3)
#define PACKET_HEADER0_HEADER_SIZE_SHIFT 28
#define PACKET_HEADER0_PACKET_ID_SHIFT16
@@ -515,7 +516,6 @@ static int tegra_i2c_empty_rx_fifo(struct tegra_i2c_dev
*i2c_dev)
* prevent overwriting past the end of buf
*/
if (rx_fifo_avail > 0 && buf_remaining > 0) {
- BUG_ON(buf_remaining > 3);
val = i2c_readl(i2c_dev, I2C_RX_FIFO);
val = cpu_to_le32(val);
memcpy(buf, , buf_remaining);
@@ -523,7 +523,6 @@ static int tegra_i2c_empty_rx_fifo(struct tegra_i2c_dev
*i2c_dev)
rx_fifo_avail--;
}
- BUG_ON(rx_fifo_avail > 0 && buf_remaining > 0);
i2c_dev->msg_buf_remaining = buf_remaining;
i2c_dev->msg_buf = buf;
@@ -581,7 +580,6 @@ static int tegra_i2c_fill_tx_fifo(struct tegra_i2c_dev *i2c_dev)
* boundary and fault.
*/
if (tx_fifo_avail > 0 && buf_remaining > 0) {
- BUG_ON(buf_remaining > 3);
memcpy(, buf, buf_remaining);
val = le32_to_cpu(val);
@@ -847,10 +845,13 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
if (!i2c_dev->is_curr_dma_xfer) {
if (i2c_dev->msg_read && (status & I2C_INT_RX_FIFO_DATA_REQ)) {
- if (i2c_dev->msg_buf_remaining)
+ if (i2c_dev->msg_buf_remaining) {
tegra_i2c_empty_rx_fifo(i2c_dev);
- else
- BUG();
+ } else {
+ dev_err(i2c_dev->dev, "unexpected rx data
request\n");
+ i2c_dev->msg_err |= I2C_ERR_UNEXPECTED_STATUS;
+ goto err;
+ }
}
if (!i2c_dev->msg_read && (status & I2C_INT_TX_FIFO_DATA_REQ)) {
@@ -876,7 +877,8 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
if (status & I2C_INT_PACKET_XFER_COMPLETE) {
if (i2c_dev->is_curr_dma_xfer)
i2c_dev->msg_buf_remaining = 0;
- BUG_ON(i2c_dev->msg_buf_remaining);
+ if (WARN_ON_ONCE(i2c_dev->msg_buf_remaining))
+ goto err;
complete(_dev->msg_complete);
}
goto done;
Unfortunately that's not enough because the indicator of the error is
the i2c_dev->msg_err and no error is set in yours case, hence no
hardware reset will be performed. It should be at least somewhat like this:
if (WARN_ON_ONCE(i2c_dev->msg_buf_remaining)) {
i2c_dev->msg_err |= I2C_ERR_UNKNOWN_INTERRUPT;
goto err;
}
Fine. I shall set msg_err as I2C_ERR_UNKNOWN_INTERRUPT instead of
I2C_ERR_UNEXPECTED_STATUS for condition of non-zero msg_bug_remaining in
PIO mode with transfer complete interrupt.
-Thanks,
Bitan
Re: [PATCH net-next 0/6] vhost: accelerate metadata access
On 2019/6/6 上午4:27, Michael S. Tsirkin wrote: On Fri, May 24, 2019 at 04:12:12AM -0400, Jason Wang wrote: Hi: This series tries to access virtqueue metadata through kernel virtual address instead of copy_user() friends since they had too much overheads like checks, spec barriers or even hardware feature toggling like SMAP. This is done through setup kernel address through direct mapping and co-opreate VM management with MMU notifiers. Test shows about 23% improvement on TX PPS. TCP_STREAM doesn't see obvious improvement. Thanks Thanks this is queued for next. Did you want to rebase and repost packed ring support on top? IIUC it's on par with split ring with these patches. Yes, it's on the way. Thanks
[RFC v1] clk: core: support clocks that need to be enabled during re-parent
When using property assigned-clock-parents to assign parent clocks,
core clocks might still be disabled during re-parent.
Add flag 'CLK_OPS_CORE_ENABLE' for those clocks must be enabled
during re-parent.
Signed-off-by: Weiyi Lu
---
drivers/clk/clk.c| 9 +
include/linux/clk-provider.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 443711f..b2e6fe3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1717,6 +1717,10 @@ static struct clk_core *__clk_set_parent_before(struct
clk_core *core,
clk_core_prepare_enable(parent);
}
+ /* enable core if CLK_OPS_CORE_ENABLE is set */
+ if (core->flags & CLK_OPS_CORE_ENABLE)
+ clk_core_prepare_enable(core);
+
/* migrate prepare count if > 0 */
if (core->prepare_count) {
clk_core_prepare_enable(parent);
@@ -1744,6 +1748,10 @@ static void __clk_set_parent_after(struct clk_core *core,
clk_core_disable_unprepare(old_parent);
}
+ /* re-balance ref counting if CLK_OPS_CORE_ENABLE is set */
+ if (core->flags & CLK_OPS_CORE_ENABLE)
+ clk_core_disable_unprepare(core);
+
/* re-balance ref counting if CLK_OPS_PARENT_ENABLE is set */
if (core->flags & CLK_OPS_PARENT_ENABLE) {
clk_core_disable_unprepare(parent);
@@ -2973,6 +2981,7 @@ static int clk_dump_show(struct seq_file *s, void *data)
ENTRY(CLK_IS_CRITICAL),
ENTRY(CLK_OPS_PARENT_ENABLE),
ENTRY(CLK_DUTY_CYCLE_PARENT),
+ ENTRY(CLK_OPS_CORE_ENABLE),
#undef ENTRY
};
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index bb6118f..39a1fed 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -34,6 +34,7 @@
#define CLK_OPS_PARENT_ENABLE BIT(12)
/* duty cycle call may be forwarded to the parent clock */
#define CLK_DUTY_CYCLE_PARENT BIT(13)
+#define CLK_OPS_CORE_ENABLEBIT(14) /* core need enable during re-parent */
struct clk;
struct clk_hw;
--
1.8.1.1.dirty
[PATCH] sctp: Add rcu lock to protect dst entry in sctp_transport_route
syzbot found a crash in rt_cache_valid. Problem is that when more
threads release dst in sctp_transport_route, the route cache can
be freed.
As follows,
p1:
sctp_transport_route
dst_release
get_dst
p2:
sctp_transport_route
dst_release
get_dst
...
If enough threads calling dst_release will cause dst->refcnt==0
then rcu softirq will reclaim the dst entry,get_dst then use
the freed memory.
This patch adds rcu lock to protect the dst_entry here.
Fixes: 6e91b578bf3f("sctp: re-use sctp_transport_pmtu in sctp_transport_route")
Signed-off-by: Su Yanjun
Reported-by: syzbot+a9e23ea2aa21044c2...@syzkaller.appspotmail.com
---
net/sctp/transport.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index ad158d3..5ad7e20 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -308,8 +308,13 @@ void sctp_transport_route(struct sctp_transport *transport,
struct sctp_association *asoc = transport->asoc;
struct sctp_af *af = transport->af_specific;
+ /* When dst entry is being released, route cache may be referred
+* again. Add rcu lock here to protect dst entry.
+*/
+ rcu_read_lock();
sctp_transport_dst_release(transport);
af->get_dst(transport, saddr, >fl, sctp_opt2sk(opt));
+ rcu_read_unlock();
if (saddr)
memcpy(>saddr, saddr, sizeof(union sctp_addr));
--
2.7.4
[PATCH 2/6] dpaa2-ptp: reuse ptp_qoriq driver
Although dpaa2-ptp.c driver is a fsl_mc_driver which
is using MC APIs for register accessing, it's same IP
block with eTSEC/DPAA/ENETC 1588 timer.
This patch is to convert to reuse ptp_qoriq driver by
using register ioremap and dropping related MC APIs.
However the interrupts could only be handled by MC which
fires MSIs to ARM cores. So the interrupt enabling and
handling still rely on MC APIs.
Signed-off-by: Yangbo Lu
---
drivers/net/ethernet/freescale/dpaa2/Kconfig | 3 +-
drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c | 160 +--
drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h | 13 --
drivers/net/ethernet/freescale/dpaa2/dprtc.c | 120 -
drivers/net/ethernet/freescale/dpaa2/dprtc.h | 20 ---
5 files changed, 34 insertions(+), 282 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig
b/drivers/net/ethernet/freescale/dpaa2/Kconfig
index 8bd3847..fbef282 100644
--- a/drivers/net/ethernet/freescale/dpaa2/Kconfig
+++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
@@ -10,8 +10,7 @@ config FSL_DPAA2_ETH
config FSL_DPAA2_PTP_CLOCK
tristate "Freescale DPAA2 PTP Clock"
- depends on FSL_DPAA2_ETH
- imply PTP_1588_CLOCK
+ depends on FSL_DPAA2_ETH && PTP_1588_CLOCK_QORIQ
default y
help
This driver adds support for using the DPAA2 1588 timer module
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
index 9b150db..6c57e17 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
@@ -5,114 +5,14 @@
*/
#include
-#include
-#include
+#include
+#include
#include
+#include
#include "dpaa2-ptp.h"
-struct ptp_dpaa2_priv {
- struct fsl_mc_device *ptp_mc_dev;
- struct ptp_clock *clock;
- struct ptp_clock_info caps;
- u32 freq_comp;
-};
-
-/* PTP clock operations */
-static int ptp_dpaa2_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
-{
- struct ptp_dpaa2_priv *ptp_dpaa2 =
- container_of(ptp, struct ptp_dpaa2_priv, caps);
- struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
- struct device *dev = _dev->dev;
- u64 adj;
- u32 diff, tmr_add;
- int neg_adj = 0;
- int err = 0;
-
- if (ppb < 0) {
- neg_adj = 1;
- ppb = -ppb;
- }
-
- tmr_add = ptp_dpaa2->freq_comp;
- adj = tmr_add;
- adj *= ppb;
- diff = div_u64(adj, 10ULL);
-
- tmr_add = neg_adj ? tmr_add - diff : tmr_add + diff;
-
- err = dprtc_set_freq_compensation(mc_dev->mc_io, 0,
- mc_dev->mc_handle, tmr_add);
- if (err)
- dev_err(dev, "dprtc_set_freq_compensation err %d\n", err);
- return err;
-}
-
-static int ptp_dpaa2_adjtime(struct ptp_clock_info *ptp, s64 delta)
-{
- struct ptp_dpaa2_priv *ptp_dpaa2 =
- container_of(ptp, struct ptp_dpaa2_priv, caps);
- struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
- struct device *dev = _dev->dev;
- s64 now;
- int err = 0;
-
- err = dprtc_get_time(mc_dev->mc_io, 0, mc_dev->mc_handle, );
- if (err) {
- dev_err(dev, "dprtc_get_time err %d\n", err);
- return err;
- }
-
- now += delta;
-
- err = dprtc_set_time(mc_dev->mc_io, 0, mc_dev->mc_handle, now);
- if (err)
- dev_err(dev, "dprtc_set_time err %d\n", err);
- return err;
-}
-
-static int ptp_dpaa2_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
-{
- struct ptp_dpaa2_priv *ptp_dpaa2 =
- container_of(ptp, struct ptp_dpaa2_priv, caps);
- struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
- struct device *dev = _dev->dev;
- u64 ns;
- u32 remainder;
- int err = 0;
-
- err = dprtc_get_time(mc_dev->mc_io, 0, mc_dev->mc_handle, );
- if (err) {
- dev_err(dev, "dprtc_get_time err %d\n", err);
- return err;
- }
-
- ts->tv_sec = div_u64_rem(ns, 10, );
- ts->tv_nsec = remainder;
- return err;
-}
-
-static int ptp_dpaa2_settime(struct ptp_clock_info *ptp,
-const struct timespec64 *ts)
-{
- struct ptp_dpaa2_priv *ptp_dpaa2 =
- container_of(ptp, struct ptp_dpaa2_priv, caps);
- struct fsl_mc_device *mc_dev = ptp_dpaa2->ptp_mc_dev;
- struct device *dev = _dev->dev;
- u64 ns;
- int err = 0;
-
- ns = ts->tv_sec * 10ULL;
- ns += ts->tv_nsec;
-
- err = dprtc_set_time(mc_dev->mc_io, 0, mc_dev->mc_handle, ns);
- if (err)
- dev_err(dev, "dprtc_set_time err %d\n", err);
- return err;
-}
-
-static const struct ptp_clock_info ptp_dpaa2_caps = {
+static const struct ptp_clock_info dpaa2_ptp_caps = {
.owner = THIS_MODULE,
[PATCH 0/6] Reuse ptp_qoriq driver for dpaa2-ptp
Although dpaa2-ptp.c driver is a fsl_mc_driver which is using MC APIs for register accessing, it's same IP block with eTSEC/DPAA/ENETC 1588 timer. This patch-set is to convert to reuse ptp_qoriq driver by using register ioremap and dropping related MC APIs. However the interrupts could only be handled by MC which fires MSIs to ARM cores. So the interrupt enabling and handling still rely on MC APIs. MC APIs for interrupt and PPS event support are also added by this patch-set. Yangbo Lu (6): ptp: add QorIQ PTP support for DPAA2 dpaa2-ptp: reuse ptp_qoriq driver dt-binding: ptp_qoriq: support DPAA2 PTP compatible arm64: dts: fsl: add ptp timer node for dpaa2 platforms dpaa2-ptp: add interrupt support MAINTAINERS: maintain DPAA2 PTP driver in QorIQ PTP entry .../devicetree/bindings/ptp/ptp-qoriq.txt | 3 +- MAINTAINERS| 9 +- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 8 + arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 8 + arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 8 + drivers/net/ethernet/freescale/dpaa2/Kconfig | 3 +- drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c | 242 +++-- drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h | 48 +++- drivers/net/ethernet/freescale/dpaa2/dprtc.c | 191 drivers/net/ethernet/freescale/dpaa2/dprtc.h | 62 -- drivers/ptp/Kconfig| 2 +- 11 files changed, 386 insertions(+), 198 deletions(-) -- 2.7.4
[PATCH 1/6] ptp: add QorIQ PTP support for DPAA2
This patch is to add QorIQ PTP support for DPAA2. Although dpaa2-ptp.c driver is a fsl_mc_driver which is using MC APIs for register accessing, it's same IP block with eTSEC/DPAA/ENETC 1588 timer. We will convert to reuse ptp_qoriq driver by using register ioremap and dropping related MC APIs. Signed-off-by: Yangbo Lu --- drivers/ptp/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index 9b8fee5..b1b454f 100644 --- a/drivers/ptp/Kconfig +++ b/drivers/ptp/Kconfig @@ -44,7 +44,7 @@ config PTP_1588_CLOCK_DTE config PTP_1588_CLOCK_QORIQ tristate "Freescale QorIQ 1588 timer as PTP clock" - depends on GIANFAR || FSL_DPAA_ETH || FSL_ENETC || FSL_ENETC_VF + depends on GIANFAR || FSL_DPAA_ETH || FSL_DPAA2_ETH || FSL_ENETC || FSL_ENETC_VF depends on PTP_1588_CLOCK default y help -- 2.7.4
[PATCH 5/6] dpaa2-ptp: add interrupt support
This patch is to add interrupt support for dpaa2 ptp clock,
including MC APIs and PPS interrupt support. Other events
haven't been supported in MC by now.
Signed-off-by: Yangbo Lu
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c | 110 +++-
drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h | 45 +
drivers/net/ethernet/freescale/dpaa2/dprtc.c | 219 +++
drivers/net/ethernet/freescale/dpaa2/dprtc.h | 44 +
4 files changed, 417 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
index 6c57e17..f915eb0 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
@@ -7,11 +7,55 @@
#include
#include
#include
+#include
#include
#include
#include "dpaa2-ptp.h"
+static int dpaa2_ptp_enable(struct ptp_clock_info *ptp,
+ struct ptp_clock_request *rq, int on)
+{
+ struct ptp_qoriq *ptp_qoriq = container_of(ptp, struct ptp_qoriq, caps);
+ struct fsl_mc_device *mc_dev;
+ struct device *dev;
+ u32 mask = 0;
+ u32 bit;
+ int err;
+
+ dev = ptp_qoriq->dev;
+ mc_dev = to_fsl_mc_device(dev);
+
+ switch (rq->type) {
+ case PTP_CLK_REQ_PPS:
+ bit = DPRTC_EVENT_PPS;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ err = dprtc_get_irq_mask(mc_dev->mc_io, 0, mc_dev->mc_handle,
+DPRTC_IRQ_INDEX, );
+ if (err < 0) {
+ dev_err(dev, "dprtc_get_irq_mask(): %d\n", err);
+ return err;
+ }
+
+ if (on)
+ mask |= bit;
+ else
+ mask &= ~bit;
+
+ err = dprtc_set_irq_mask(mc_dev->mc_io, 0, mc_dev->mc_handle,
+DPRTC_IRQ_INDEX, mask);
+ if (err < 0) {
+ dev_err(dev, "dprtc_set_irq_mask(): %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+
static const struct ptp_clock_info dpaa2_ptp_caps = {
.owner = THIS_MODULE,
.name = "DPAA2 PTP Clock",
@@ -25,11 +69,47 @@ static const struct ptp_clock_info dpaa2_ptp_caps = {
.adjtime= ptp_qoriq_adjtime,
.gettime64 = ptp_qoriq_gettime,
.settime64 = ptp_qoriq_settime,
+ .enable = dpaa2_ptp_enable,
};
+static irqreturn_t dpaa2_ptp_irq_handler_thread(int irq, void *priv)
+{
+ struct ptp_qoriq *ptp_qoriq = priv;
+ struct ptp_clock_event event;
+ struct fsl_mc_device *mc_dev;
+ struct device *dev;
+ u32 status = 0;
+ int err;
+
+ dev = ptp_qoriq->dev;
+ mc_dev = to_fsl_mc_device(dev);
+
+ err = dprtc_get_irq_status(mc_dev->mc_io, 0, mc_dev->mc_handle,
+ DPRTC_IRQ_INDEX, );
+ if (unlikely(err)) {
+ dev_err(dev, "dprtc_get_irq_status err %d\n", err);
+ return IRQ_NONE;
+ }
+
+ if (status & DPRTC_EVENT_PPS) {
+ event.type = PTP_CLOCK_PPS;
+ ptp_clock_event(ptp_qoriq->clock, );
+ }
+
+ err = dprtc_clear_irq_status(mc_dev->mc_io, 0, mc_dev->mc_handle,
+DPRTC_IRQ_INDEX, status);
+ if (unlikely(err)) {
+ dev_err(dev, "dprtc_clear_irq_status err %d\n", err);
+ return IRQ_NONE;
+ }
+
+ return IRQ_HANDLED;
+}
+
static int dpaa2_ptp_probe(struct fsl_mc_device *mc_dev)
{
struct device *dev = _dev->dev;
+ struct fsl_mc_device_irq *irq;
struct ptp_qoriq *ptp_qoriq;
struct device_node *node;
void __iomem *base;
@@ -71,15 +151,42 @@ static int dpaa2_ptp_probe(struct fsl_mc_device *mc_dev)
goto err_close;
}
+ err = fsl_mc_allocate_irqs(mc_dev);
+ if (err) {
+ dev_err(dev, "MC irqs allocation failed\n");
+ goto err_unmap;
+ }
+
+ irq = mc_dev->irqs[0];
+ ptp_qoriq->irq = irq->msi_desc->irq;
+
+ err = devm_request_threaded_irq(dev, ptp_qoriq->irq, NULL,
+ dpaa2_ptp_irq_handler_thread,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
+ dev_name(dev), ptp_qoriq);
+ if (err < 0) {
+ dev_err(dev, "devm_request_threaded_irq(): %d\n", err);
+ goto err_free_mc_irq;
+ }
+
+ err = dprtc_set_irq_enable(mc_dev->mc_io, 0, mc_dev->mc_handle,
+ DPRTC_IRQ_INDEX, 1);
+ if (err < 0) {
+ dev_err(dev, "dprtc_set_irq_enable(): %d\n", err);
+ goto err_free_mc_irq;
+ }
+
err = ptp_qoriq_init(ptp_qoriq, base, _ptp_caps);
if (err)
- goto err_unmap;
+ goto err_free_mc_irq;
[PATCH 4/6] arm64: dts: fsl: add ptp timer node for dpaa2 platforms
This patch is to add ptp timer device tree node for dpaa2
platforms(ls1088a/ls208xa/lx2160a).
Signed-off-by: Yangbo Lu
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 8
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 8
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 8
3 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 661137f..dacd8cf 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -609,6 +609,14 @@
;
};
+ ptp-timer@8b95000 {
+ compatible = "fsl,dpaa2-ptp";
+ reg = <0x0 0x8b95000 0x0 0x100>;
+ clocks = < 4 0>;
+ little-endian;
+ fsl,extts-fifo;
+ };
+
cluster1_core0_watchdog: wdt@c00 {
compatible = "arm,sp805-wdt", "arm,primecell";
reg = <0x0 0xc00 0x0 0x1000>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index d7e78dc..3ace919 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -321,6 +321,14 @@
};
};
+ ptp-timer@8b95000 {
+ compatible = "fsl,dpaa2-ptp";
+ reg = <0x0 0x8b95000 0x0 0x100>;
+ clocks = < 4 1>;
+ little-endian;
+ fsl,extts-fifo;
+ };
+
fsl_mc: fsl-mc@80c00 {
compatible = "fsl,qoriq-mc";
reg = <0x0008 0x0c00 0 0x40>,/* MC portal
base */
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 125a8cc..e6fdba3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -848,6 +848,14 @@
dma-coherent;
};
+ ptp-timer@8b95000 {
+ compatible = "fsl,dpaa2-ptp";
+ reg = <0x0 0x8b95000 0x0 0x100>;
+ clocks = < 4 1>;
+ little-endian;
+ fsl,extts-fifo;
+ };
+
fsl_mc: fsl-mc@80c00 {
compatible = "fsl,qoriq-mc";
reg = <0x0008 0x0c00 0 0x40>,
--
2.7.4
[PATCH 3/6] dt-binding: ptp_qoriq: support DPAA2 PTP compatible
Add a new compatible for DPAA2 PTP. Signed-off-by: Yangbo Lu --- Documentation/devicetree/bindings/ptp/ptp-qoriq.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt index 6ec0534..d48f9eb 100644 --- a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt +++ b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt @@ -4,7 +4,8 @@ General Properties: - compatible Should be "fsl,etsec-ptp" for eTSEC Should be "fsl,fman-ptp-timer" for DPAA FMan -Should be "fsl,enetc-ptp" for ENETC + Should be "fsl,dpaa2-ptp" for DPAA2 + Should be "fsl,enetc-ptp" for ENETC - reg Offset and length of the register set for the device - interrupts There should be at least two interrupts. Some devices have as many as four PTP related interrupts. -- 2.7.4
[PATCH 6/6] MAINTAINERS: maintain DPAA2 PTP driver in QorIQ PTP entry
Maintain DPAA2 PTP driver in QorIQ PTP entry. Signed-off-by: Yangbo Lu --- MAINTAINERS | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fcbd648..81762bb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4910,13 +4910,6 @@ L: linux-kernel@vger.kernel.org S: Maintained F: drivers/staging/fsl-dpaa2/ethsw -DPAA2 PTP CLOCK DRIVER -M: Yangbo Lu -L: net...@vger.kernel.org -S: Maintained -F: drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp* -F: drivers/net/ethernet/freescale/dpaa2/dprtc* - DPT_I2O SCSI RAID DRIVER M: Adaptec OEM Raid Solutions L: linux-s...@vger.kernel.org @@ -6359,6 +6352,8 @@ FREESCALE QORIQ PTP CLOCK DRIVER M: Yangbo Lu L: net...@vger.kernel.org S: Maintained +F: drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp* +F: drivers/net/ethernet/freescale/dpaa2/dprtc* F: drivers/net/ethernet/freescale/enetc/enetc_ptp.c F: drivers/ptp/ptp_qoriq.c F: drivers/ptp/ptp_qoriq_debugfs.c -- 2.7.4
Re: [PATCH -next] ocelot: remove unused variable 'rc' in vcap_cmd()
From: Mao Wenan
Date: Sun, 9 Jun 2019 15:11:26 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/mscc/ocelot_ace.c: In function ‘vcap_cmd’:
> drivers/net/ethernet/mscc/ocelot_ace.c:108:6: warning: variable ‘rc’ set
> but not used [-Wunused-but-set-variable]
> int rc;
> ^
> It's never used since introduction in commit b596229448dd ("net: mscc:
> ocelot: Add support for tcam")
>
> Signed-off-by: Mao Wenan
Applied.
Re: [PATCH net] mpls: fix af_mpls dependencies
From: Matteo Croce Date: Sat, 8 Jun 2019 14:50:19 +0200 > MPLS routing code relies on sysctl to work, so let it select PROC_SYSCTL. > > Reported-by: Randy Dunlap > Suggested-by: David Ahern > Signed-off-by: Matteo Croce Applied, thanks.
Re: [PATCH] af_key: make use of BUG_ON macro
From: Hariprasad Kelam Date: Sat, 8 Jun 2019 14:30:50 +0530 > fix below warnings reported by coccicheck > > net/key/af_key.c:932:2-5: WARNING: Use BUG_ON instead of if condition > followed by BUG. > net/key/af_key.c:948:2-5: WARNING: Use BUG_ON instead of if condition > followed by BUG. > > Signed-off-by: Hariprasad Kelam Applied to net-next.
Re: [PATCH] nfc: nci: fix warning comparison to bool
From: Hariprasad Kelam
Date: Sat, 8 Jun 2019 14:11:54 +0530
> Fix below warning reported by coccicheck
>
> net/nfc/nci/ntf.c:367:5-15: WARNING: Comparison to bool
>
> Signed-off-by: Hariprasad Kelam
> ---
> net/nfc/nci/ntf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c
> index 1e8c1a1..81e8570 100644
> --- a/net/nfc/nci/ntf.c
> +++ b/net/nfc/nci/ntf.c
> @@ -364,7 +364,7 @@ static void nci_rf_discover_ntf_packet(struct nci_dev
> *ndev,
> ntf.ntf_type = *data++;
> pr_debug("ntf_type %d\n", ntf.ntf_type);
>
> - if (add_target == true)
> + if (add_target)
add_target is a bool, these kinds of changes are not good.
Re: [PATCH] ipv6: exthdrs: fix warning comparison to bool
From: Hariprasad Kelam Date: Sat, 8 Jun 2019 14:05:33 +0530 > Fix below warning reported by coccicheck > > net/ipv6/exthdrs.c:180:9-29: WARNING: Comparison to bool > > Signed-off-by: Hariprasad Kelam ... > diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c > index ab5add0..e137325 100644 > --- a/net/ipv6/exthdrs.c > +++ b/net/ipv6/exthdrs.c > @@ -177,7 +177,7 @@ static bool ip6_parse_tlv(const struct tlvtype_proc > *procs, > /* type specific length/alignment > checks will be performed in the > func(). */ > - if (curr->func(skb, off) == false) > + if (!curr->func(skb, off)) curr->func() returns type 'bool', whats wrong with comparing against the same type? I'm not applying stuff like this, sorry.
[next PATCH] Revert "usb: mtu3: fix up undefined reference to usb_debug_root"
It's not needed after [1] is applied, because usb_debug_root is created
by usb common core but not usbcore now.
[1] 812086d362a1 ("USB: move usb debugfs directory creation to the usb common
core")
Signed-off-by: Chunfeng Yun
---
drivers/usb/mtu3/mtu3_debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_debugfs.c b/drivers/usb/mtu3/mtu3_debugfs.c
index 3ed666f94dd9..c96e5dab0a48 100644
--- a/drivers/usb/mtu3/mtu3_debugfs.c
+++ b/drivers/usb/mtu3/mtu3_debugfs.c
@@ -528,7 +528,8 @@ void ssusb_dr_debugfs_init(struct ssusb_mtk *ssusb)
void ssusb_debugfs_create_root(struct ssusb_mtk *ssusb)
{
- ssusb->dbgfs_root = debugfs_create_dir(dev_name(ssusb->dev), NULL);
+ ssusb->dbgfs_root =
+ debugfs_create_dir(dev_name(ssusb->dev), usb_debug_root);
}
void ssusb_debugfs_remove_root(struct ssusb_mtk *ssusb)
--
2.21.0
Re: [PATCH v5 07/26] leds: sc27xx-blt: Use generic support for composing LED names
Hi Jacek, On Mon, 10 Jun 2019 at 03:08, Jacek Anaszewski wrote: > > Switch to using generic LED support for composing LED class > device name. > > Signed-off-by: Jacek Anaszewski > Cc: Baolin Wang > Acked-by: Pavel Machek Thanks. Reviewed-by: Baolin Wang -- Baolin Wang Best Regards
Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
On 5/30/19 10:53 PM, Alex Elder wrote: > This series presents the driver for the Qualcomm IP Accelerator (IPA). > > This is version 2 of the series. This version has addressed almost > all of the feedback received in the first version: > https://lore.kernel.org/lkml/20190512012508.10608-1-el...@linaro.org/ > More detail is included in the individual patches, but here is a > high-level summary of what's changed since then: > - Two spinlocks have been removed. > - The code for enabling and disabling endpoint interrupts has > been simplified considerably, and the spinlock is no longer > required > - A spinlock used when updating ring buffer pointers is no > longer needed. Integers indexing the ring are used instead > (and they don't even have to be atomic). > - One spinlock remains to protect list updates, but it is always > acquired using spin_lock_bh() (no more irqsave). > - Information about the queueing and completion of messages is now > supplied to the network stack in batches rather than one at a > time. > - I/O completion handling has been simplified, with the IRQ > handler now consisting mainly of disabling the interrupt and > calling napi_schedule(). > - Some comments have been updated and improved througout. > > What follows is the introduction supplied with v1 of the series. Any more feedback? The only comment that I acted on is a trivial suggestion from Dave Miller: change the types for the route_virt and filter_virt fields of the ipa structure from void pointer to u64 pointer. That required no other changes to the code. At this point I plan to post a version 3 of this series in the coming week and it will include just that one change. I might do some comment updates before then as well. But if anyone expects to provide any additional input on the code in the near term, I can delay posting v3 until that has been addressed. If this applies to you, please let me know. (No pressure; things can always wait for v4...) Thanks. -Alex > - > > The IPA is a component present in some Qualcomm SoCs that allows > network functions such as aggregation, filtering, routing, and NAT > to be performed without active involvement of the main application > processor (AP). > > Initially, these advanced features are disabled; the IPA driver > simply provides a network interface that makes the modem's LTE > network available to the AP. In addition, only support for the > IPA found in the Qualcomm SDM845 SoC is provided. > > This code is derived from a driver developed internally by Qualcomm. > A version of the original source can be seen here: > https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree > in the "drivers/platform/msm/ipa" directory. Many were involved in > developing this, but the following individuals deserve explicit > acknowledgement for their substantial contributions: > > Abhishek Choubey > Ady Abraham > Chaitanya Pratapa > David Arinzon > Ghanim Fodi > Gidon Studinski > Ravi Gummadidala > Shihuan Liu > Skylar Chang > > A version of this code was posted in November 2018 as an RFC. > https://lore.kernel.org/lkml/20181107003250.5832-1-el...@linaro.org/ > All feedback received was addressed. The code has undergone > considerable further rework since that time, and most of the > "future work" described then has now been completed. > > This code is available in buildable form here, based on kernel > v5.2-rc1: > remote: ssh://g...@git.linaro.org/people/alex.elder/linux.git > branch: ipa-v2_kernel-v5.2-rc2 > 75adf2ac1266 arm64: defconfig: enable build of IPA code > > The branch depends on a commit now found in in net-next. It has > been cherry-picked, and (in this branch) has this commit ID: > 13c627b5a078 net: qualcomm: rmnet: Move common struct definitions to include > by > > -Alex > > Alex Elder (17): > bitfield.h: add FIELD_MAX() and field_max() > dt-bindings: soc: qcom: add IPA bindings > soc: qcom: ipa: main code > soc: qcom: ipa: configuration data > soc: qcom: ipa: clocking, interrupts, and memory > soc: qcom: ipa: GSI headers > soc: qcom: ipa: the generic software interface > soc: qcom: ipa: GSI transactions > soc: qcom: ipa: IPA interface to GSI > soc: qcom: ipa: IPA endpoints > soc: qcom: ipa: immediate commands > soc: qcom: ipa: IPA network device and microcontroller > soc: qcom: ipa: AP/modem communications > soc: qcom: ipa: support build of IPA code > MAINTAINERS: add entry for the Qualcomm IPA driver > arm64: dts: sdm845: add IPA information > arm64: defconfig: enable build of IPA code > > .../devicetree/bindings/net/qcom,ipa.yaml | 180 ++ > MAINTAINERS |6 + > arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 + > arch/arm64/configs/defconfig |1 + >
Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
On 06/07/2019 09:01 PM, Christophe Leroy wrote:
>
>
> Le 07/06/2019 à 12:34, Anshuman Khandual a écrit :
>> Very similar definitions for notify_page_fault() are being used by multiple
>> architectures duplicating much of the same code. This attempts to unify all
>> of them into a generic implementation, rename it as kprobe_page_fault() and
>> then move it to a common header.
>>
>> kprobes_built_in() can detect CONFIG_KPROBES, hence new kprobe_page_fault()
>> need not be wrapped again within CONFIG_KPROBES. Trap number argument can
>> now contain upto an 'unsigned int' accommodating all possible platforms.
>>
>> kprobe_page_fault() goes the x86 way while dealing with preemption context.
>> As explained in these following commits the invoking context in itself must
>> be non-preemptible for kprobes processing context irrespective of whether
>> kprobe_running() or perhaps smp_processor_id() is safe or not. It does not
>> make much sense to continue when original context is preemptible. Instead
>> just bail out earlier.
>>
>> commit a980c0ef9f6d
>> ("x86/kprobes: Refactor kprobes_fault() like kprobe_exceptions_notify()")
>>
>> commit b506a9d08bae ("x86: code clarification patch to Kprobes arch code")
>>
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-i...@vger.kernel.org
>> Cc: linuxppc-...@lists.ozlabs.org
>> Cc: linux-s...@vger.kernel.org
>> Cc: linux...@vger.kernel.org
>> Cc: sparcli...@vger.kernel.org
>> Cc: x...@kernel.org
>> Cc: Andrew Morton
>> Cc: Michal Hocko
>> Cc: Matthew Wilcox
>> Cc: Mark Rutland
>> Cc: Christophe Leroy
>> Cc: Stephen Rothwell
>> Cc: Andrey Konovalov
>> Cc: Michael Ellerman
>> Cc: Paul Mackerras
>> Cc: Russell King
>> Cc: Catalin Marinas
>> Cc: Will Deacon
>> Cc: Tony Luck
>> Cc: Fenghua Yu
>> Cc: Martin Schwidefsky
>> Cc: Heiko Carstens
>> Cc: Yoshinori Sato
>> Cc: "David S. Miller"
>> Cc: Thomas Gleixner
>> Cc: Peter Zijlstra
>> Cc: Ingo Molnar
>> Cc: Andy Lutomirski
>> Cc: Dave Hansen
>>
>> Signed-off-by: Anshuman Khandual
>> ---
>> Testing:
>>
>> - Build and boot tested on arm64 and x86
>> - Build tested on some other archs (arm, sparc64, alpha, powerpc etc)
>>
>> Changes in RFC V3:
>>
>> - Updated the commit message with an explaination for new preemption
>> behaviour
>> - Moved notify_page_fault() to kprobes.h with 'static nokprobe_inline' per
>> Matthew
>> - Changed notify_page_fault() return type from int to bool per Michael
>> Ellerman
>> - Renamed notify_page_fault() as kprobe_page_fault() per Peterz
>>
>> Changes in RFC V2: (https://patchwork.kernel.org/patch/10974221/)
>>
>> - Changed generic notify_page_fault() per Mathew Wilcox
>> - Changed x86 to use new generic notify_page_fault()
>> - s/must not/need not/ in commit message per Matthew Wilcox
>>
>> Changes in RFC V1: (https://patchwork.kernel.org/patch/10968273/)
>>
>> arch/arm/mm/fault.c | 24 +---
>> arch/arm64/mm/fault.c | 24 +---
>> arch/ia64/mm/fault.c | 24 +---
>> arch/powerpc/mm/fault.c | 23 ++-
>> arch/s390/mm/fault.c | 16 +---
>> arch/sh/mm/fault.c | 18 ++
>> arch/sparc/mm/fault_64.c | 16 +---
>> arch/x86/mm/fault.c | 21 ++---
>> include/linux/kprobes.h | 16
>> 9 files changed, 27 insertions(+), 155 deletions(-)
>>
>
> [...]
>
>> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
>> index 443d980..064dd15 100644
>> --- a/include/linux/kprobes.h
>> +++ b/include/linux/kprobes.h
>> @@ -458,4 +458,20 @@ static inline bool is_kprobe_optinsn_slot(unsigned long
>> addr)
>> }
>> #endif
>> +static nokprobe_inline bool kprobe_page_fault(struct pt_regs *regs,
>> + unsigned int trap)
>> +{
>> + int ret = 0;
>
> ret is pointless.
>
>> +
>> + /*
>> + * To be potentially processing a kprobe fault and to be allowed
>> + * to call kprobe_running(), we have to be non-preemptible.
>> + */
>> + if (kprobes_built_in() && !preemptible() && !user_mode(regs)) {
>> + if (kprobe_running() && kprobe_fault_handler(regs, trap))
>
> don't need an 'if A if B', can do 'if A && B'
Which will make it a very lengthy condition check.
>
>> + ret = 1;
>
> can do 'return true;' directly here
>
>> + }
>> + return ret;
>
> And 'return false' here.
Makes sense, will drop ret.
RE: [PATCH RESEND V13 2/5] thermal: of-thermal: add API for getting sensor ID from DT
Hi, Eduardo
> -Original Message-
> From: Anson Huang
> Sent: Wednesday, May 29, 2019 11:37 AM
> To: Eduardo Valentin
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> daniel.lezc...@linaro.org; Aisheng Dong ;
> ulf.hans...@linaro.org; Peng Fan ; Daniel Baluta
> ; maxime.rip...@bootlin.com; o...@lixom.net;
> ja...@amarulasolutions.com; horms+rene...@verge.net.au; Leonard
> Crestez ; bjorn.anders...@linaro.org;
> dingu...@kernel.org; enric.balle...@collabora.com;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux...@vger.kernel.org; dl-linux-imx i...@nxp.com>
> Subject: RE: [PATCH RESEND V13 2/5] thermal: of-thermal: add API for getting
> sensor ID from DT
>
> Hi, Eduardo
>
> > -Original Message-
> > From: Eduardo Valentin
> > Sent: Wednesday, May 29, 2019 11:02 AM
> > To: Anson Huang
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> > catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> > daniel.lezc...@linaro.org; Aisheng Dong ;
> > ulf.hans...@linaro.org; Peng Fan ; Daniel Baluta
> > ; maxime.rip...@bootlin.com; o...@lixom.net;
> > ja...@amarulasolutions.com; horms+rene...@verge.net.au; Leonard
> > Crestez ; bjorn.anders...@linaro.org;
> > dingu...@kernel.org; enric.balle...@collabora.com;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org; linux...@vger.kernel.org; dl-linux-imx
> >
> > Subject: Re: [PATCH RESEND V13 2/5] thermal: of-thermal: add API for
> > getting sensor ID from DT
> >
> > On Tue, May 28, 2019 at 02:06:18PM +0800, anson.hu...@nxp.com wrote:
> > > From: Anson Huang
> > >
> > > On some platforms like i.MX8QXP, the thermal driver needs a real HW
> > > sensor ID from DT thermal zone, the HW sensor ID is used to get
> > > temperature from SCU firmware, and the virtual sensor ID starting
> > > from
> > > 0 to N is NOT used at all, this patch adds new API
> > > thermal_zone_of_get_sensor_id() to provide the feature of getting
> > > sensor ID from DT thermal zone's node.
> > >
> > > Signed-off-by: Anson Huang
> > > ---
> > > Changes since V12:
> > > - adjust the second parameter of thermal_zone_of_get_sensor_id()
> > > API,
> > then caller no need
> > > to pass the of_phandle_args structure and put the sensor_specs.np
> > manually, also putting
> > > the sensor node device check inside this API to make it easy for
> > > usage;
> >
> > What happened to using nxp,resource-id property in your driver?
> > Why do we need this as an API in of-thermal? What other drivers may
> > benefit of this?
> >
> > Regardless, this patch needs to document the new API under
> > Documentation/
>
> As Rob has different opinion about this property, he thought it is
> unnecessary, see below discussion mail, that is why I need to add API to get
> the resource ID from phandle argument.
> I am totally confused now, which approach should we adopt?
>
> https://patchwork.kernel.org/patch/10831397/
I will add the new API document in V14, I remembered that there is also other
vendors
have similar sensor HW ID as i.MX8QXP, instead of adding private properties for
each vendor,
adding an API to read out the sensor ID can benefit us a lot I think.
Thanks,
Anson
>
> Thanks,
> Anson
>
> >
> > > ---
> > > drivers/thermal/of-thermal.c | 66
> > > +---
> >
> > > include/linux/thermal.h | 10 +++
> > > 2 files changed, 60 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/thermal/of-thermal.c
> > > b/drivers/thermal/of-thermal.c index dc5093b..a53792b 100644
> > > --- a/drivers/thermal/of-thermal.c
> > > +++ b/drivers/thermal/of-thermal.c
> > > @@ -449,6 +449,54 @@ thermal_zone_of_add_sensor(struct
> device_node
> > > *zone, }
> > >
> > > /**
> > > + * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal
> > > + zone
> > > + * @tz_np: a valid thermal zone device node.
> > > + * @sensor_np: a sensor node of a valid sensor device.
> > > + * @id: a sensor ID pointer will be passed back.
> > > + *
> > > + * This function will get sensor ID from a given thermal zone node,
> > > + use
> > > + * "thermal-sensors" as list name, and get sensor ID from first
> > > + phandle's
> > > + * argument.
> > > + *
> > > + * Return: 0 on success, proper error code otherwise.
> > > + */
> > > +
> > > +int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> > > + struct device_node *sensor_np,
> > > + u32 *id)
> > > +{
> > > + struct of_phandle_args sensor_specs;
> > > + int ret;
> > > +
> > > + ret = of_parse_phandle_with_args(tz_np,
> > > + "thermal-sensors",
> > > +
Re: [BACKPORT 4.4.y] PM / sleep: prohibit devices probing during suspend/hibernation
On Thu, 6 Jun 2019 at 09:08, Sasha Levin wrote: > > On Wed, Jun 05, 2019 at 07:14:12PM +0800, Chunyan Zhang wrote: > >From: "Strashko, Grygorii" > > > >[ Upstream commit 013c074f8642d8e815ad670601f8e27155a74b57 ] > > > >It is unsafe [1] if probing of devices will happen during suspend or > >hibernation and system behavior will be unpredictable in this case. > >So, let's prohibit device's probing in dpm_prepare() and defer their > >probing instead. The normal behavior will be restored in > >dpm_complete(). > > > >This patch introduces new DD core APIs: > > device_block_probing() > > It will disable probing of devices and defer their probes instead. > > device_unblock_probing() > > It will restore normal behavior and trigger re-probing of deferred > > devices. > > > >[1] https://lkml.org/lkml/2015/9/11/554 > > > >Signed-off-by: Grygorii Strashko > >Acked-by: Pavel Machek > >Signed-off-by: Rafael J. Wysocki > >Signed-off-by: Chunyan Zhang > > This patch had to be fixed a few times (see 015bb5e134 and 9a2a5a638f8), > we can't just take it as is. > > It might be just simpler to move to a newer kernel at this point. Thanks for the information and suggestion! Chunyan > > -- > Thanks, > Sasha
Re: [PATCH v4 01/14] dt-bindings: Add binding for MT2712 MIPI-CSI2
Hi, Stu:
"mediatek,mt2712-mipicsi" and "mediatek,mt2712-mipicsi-common" have many
common part with "mediatek,mt8183-seninf", and I've a discussion in [1],
so I would like these two to be merged together.
[1] https://patchwork.kernel.org/patch/10979131/
Regards,
CK
On Tue, 2019-06-04 at 18:11 +0800, Stu Hsieh wrote:
> Add MIPI-CSI2 dt-binding for Mediatek MT2712 SoC
>
> Signed-off-by: Stu Hsieh
> ---
> .../bindings/media/mediatek-mipicsi.txt | 58 +++
> 1 file changed, 58 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/mediatek-mipicsi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mipicsi.txt
> b/Documentation/devicetree/bindings/media/mediatek-mipicsi.txt
> new file mode 100644
> index ..e30b6a468129
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-mipicsi.txt
> @@ -0,0 +1,58 @@
> +* Mediatek MIPI-CSI2 receiver
> +
> +Mediatek MIPI-CSI2 receiver is the MIPI Signal capture hardware present in
> Mediatek SoCs
> +
> +Required properties:
> +- compatible: should be "mediatek,mt2712-mipicsi"
> +- reg : physical base address of the mipicsi receiver registers and length of
> + memory mapped region.
> +- power-domains: a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- mediatek,larb: must contain the local arbiters in the current Socs, see
> + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> + for details.
> +- iommus: should point to the respective IOMMU block with master port as
> + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> + for details.
> +- mediatek,seninf_mux_camsv: seninf_mux_camsv the data go through of the
> mipicsi port
> + any mipicsi port can contain max four seninf_mux_camsv
> + The Total seninf_mux_camsv is six for mt2712
> +- mediatek,mipicsiid: the id of the mipicsi port, there are two port for
> mt2712
> +- mediatek,mipicsi: the common component of the two mipicsi port
> +- mediatek,mipicsi_max_vc: the number of virtual channel which subdev used
> +- mediatek,serdes_link_reg: the register of subdev to get the link status
> +
> +Example:
> + mipicsi0: mipicsi@10217000 {
> + compatible = "mediatek,mt2712-mipicsi";
> + mediatek,mipicsi = <>;
> + iommus = < M4U_PORT_CAM_DMA0>,
> + < M4U_PORT_CAM_DMA1>;
> + mediatek,larb = <>;
> + power-domains = < MT2712_POWER_DOMAIN_ISP>;
> +
> + mediatek,seninf_mux_camsv = <_mux_camsv0
> + _mux_camsv1
> + _mux_camsv2
> + _mux_camsv3>;
> + reg = <0 0x10217000 0 0x60>,
> + <0 0x15002100 0 0x4>,
> + <0 0x15002300 0 0x100>;
> + mediatek,mipicsiid = <0>;
> + mediatek,mipicsi_max_vc = <4>;
> + mediatek,serdes_link_reg = <0x49>;
> + };
> +
> + mipicsi1: mipicsi@10218000 {
> + compatible = "mediatek,mt2712-mipicsi";
> + mediatek,mipicsi = <>;
> + iommus = < M4U_PORT_CAM_DMA2>;
> + mediatek,larb = <>;
> + power-domains = < MT2712_POWER_DOMAIN_ISP>;
> + mediatek,seninf_mux_camsv = <_mux_camsv4
> + _mux_camsv5>;
> + reg = <0 0x10218000 0 0x60>,
> + <0 0x15002500 0 0x4>,
> + <0 0x15002700 0 0x100>;
> + mediatek,mipicsiid = <1>;
> + };
Re: "locking/lockdep: Consolidate lock usage bit initialization" is buggy
Thanks for the further validation. On Fri, 7 Jun 2019 at 22:14, Qian Cai wrote: > Reverted the commit on the top of linux-next fixed the issue. > > With the commit (triggering the warning > DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused)), > > # cat /proc/lockdep_stats > lock-classes: 1110 [max: 8192] > stack-trace entries: 0 [max: 524288] > combined max dependencies: 1 > uncategorized locks: 0 > unused locks: 1110 > max locking depth: 14 > debug_locks: 0 > > Without the commit (no warning), > > # cat /proc/lockdep_stats > lock-classes: 1110 [max: 8192] > stack-trace entries: 9932 [max: 524288] > combined max dependencies: 1 > uncategorized locks: 1113 > unused locks:0 > max locking depth: 14 > debug_locks: 1 Then it is obviously we are talking on different things; then it is obviously a configuration problem. Fix will be posted soon. Sorry the bug. Thanks, Yuyang
Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
On 06/07/2019 05:33 PM, Stephen Rothwell wrote:
> Hi Anshuman,
>
> On Fri, 7 Jun 2019 16:04:15 +0530 Anshuman Khandual
> wrote:
>>
>> +static nokprobe_inline bool kprobe_page_fault(struct pt_regs *regs,
>> + unsigned int trap)
>> +{
>> +int ret = 0;
>> +
>> +/*
>> + * To be potentially processing a kprobe fault and to be allowed
>> + * to call kprobe_running(), we have to be non-preemptible.
>> + */
>> +if (kprobes_built_in() && !preemptible() && !user_mode(regs)) {
>> +if (kprobe_running() && kprobe_fault_handler(regs, trap))
>> +ret = 1;
>> +}
>> +return ret;
>> +}
>
> Since this is now declared as "bool" (thanks for that), you should make
> "ret" be bool and use true and false;
Sure, done.
[PATCH v2] clk: mediatek: mt8183: Register 13MHz clock earlier for clocksource
The 13MHz clock should be registered before clocksource driver is
initialized. Use CLK_OF_DECLARE_DRIVER() to guarantee.
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/clk-mt8183.c | 46 +--
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8183.c
b/drivers/clk/mediatek/clk-mt8183.c
index 9d86510..bc01611 100644
--- a/drivers/clk/mediatek/clk-mt8183.c
+++ b/drivers/clk/mediatek/clk-mt8183.c
@@ -25,9 +25,11 @@
FIXED_CLK(CLK_TOP_UNIVP_192M, "univpll_192m", "univpll", 19200),
};
+static const struct mtk_fixed_factor top_early_divs[] = {
+ FACTOR(CLK_TOP_CLK13M, "clk13m", "clk26m", 1, 2),
+};
+
static const struct mtk_fixed_factor top_divs[] = {
- FACTOR(CLK_TOP_CLK13M, "clk13m", "clk26m", 1,
- 2),
FACTOR(CLK_TOP_F26M_CK_D2, "csw_f26m_ck_d2", "clk26m", 1,
2),
FACTOR(CLK_TOP_SYSPLL_CK, "syspll_ck", "mainpll", 1,
@@ -1167,37 +1169,57 @@ static int clk_mt8183_apmixed_probe(struct
platform_device *pdev)
return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
}
+static struct clk_onecell_data *top_clk_data;
+
+static void clk_mt8183_top_init_early(struct device_node *node)
+{
+ int i;
+
+ top_clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
+
+ for (i = 0; i < CLK_TOP_NR_CLK; i++)
+ top_clk_data->clks[i] = ERR_PTR(-EPROBE_DEFER);
+
+ mtk_clk_register_factors(top_early_divs, ARRAY_SIZE(top_early_divs),
+ top_clk_data);
+
+ of_clk_add_provider(node, of_clk_src_onecell_get, top_clk_data);
+}
+
+CLK_OF_DECLARE_DRIVER(mt8183_topckgen, "mediatek,mt8183-topckgen",
+ clk_mt8183_top_init_early);
+
static int clk_mt8183_top_probe(struct platform_device *pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
void __iomem *base;
- struct clk_onecell_data *clk_data;
struct device_node *node = pdev->dev.of_node;
base = devm_ioremap_resource(>dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
- clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
-
mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
- clk_data);
+ top_clk_data);
+
+ mtk_clk_register_factors(top_early_divs, ARRAY_SIZE(top_early_divs),
+ top_clk_data);
- mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
+ mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), top_clk_data);
mtk_clk_register_muxes(top_muxes, ARRAY_SIZE(top_muxes),
- node, _clk_lock, clk_data);
+ node, _clk_lock, top_clk_data);
mtk_clk_register_composites(top_aud_muxes, ARRAY_SIZE(top_aud_muxes),
- base, _clk_lock, clk_data);
+ base, _clk_lock, top_clk_data);
mtk_clk_register_composites(top_aud_divs, ARRAY_SIZE(top_aud_divs),
- base, _clk_lock, clk_data);
+ base, _clk_lock, top_clk_data);
mtk_clk_register_gates(node, top_clks, ARRAY_SIZE(top_clks),
- clk_data);
+ top_clk_data);
- return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+ return of_clk_add_provider(node, of_clk_src_onecell_get, top_clk_data);
}
static int clk_mt8183_infra_probe(struct platform_device *pdev)
--
1.8.1.1.dirty
Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> according to my findings
>
> MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> so it must be rxdg4 = rxd[4] etc.
RXV start from 1 in the code.
That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
> however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal
> calculation.
> i already wrote a similar code for this driver which i sended to felix a long
> time ago.
> my variant looks like
> status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220)
> / 2;
> status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) -
> 220) / 2;
> status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) -
> 220) / 2;
> status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) -
> 220) / 2;
> status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) -
> 220) / 2;
> Am 09.06.2019 um 11:09 schrieb Ryder Lee:
> > Fill in RX status->chain_signal to avoid empty value.
> >
> > Signed-off-by: Ryder Lee
> > ---
> > .../net/wireless/mediatek/mt76/mt7615/mac.c | 30 ++-
> > .../net/wireless/mediatek/mt76/mt7615/mac.h | 5
> > 2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > index b60d42b5923d..9ee83ea11b8c
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > @@ -13,6 +13,11 @@
> > #include "../dma.h"
> > #include "mac.h"
> >
> > +static inline s8 to_rssi(u32 field, u32 rxv)
> > +{
> > + return (FIELD_GET(field, rxv) - 220) / 2;
> > +}
> > +
> > static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
> > u8 idx, bool unicast)
> > {
> > @@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct
> > sk_buff *skb)
> > if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
> > u32 rxdg0 = le32_to_cpu(rxd[0]);
> > u32 rxdg1 = le32_to_cpu(rxd[1]);
> > + u32 rxdg3 = le32_to_cpu(rxd[3]);
> > u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
> > bool cck = false;
> >
> > @@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct
> > sk_buff *skb)
> >
> > status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
> >
> > - /* TODO: RSSI */
> > + status->chains = dev->mt76.antenna_mask;
> > + status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> > + status->signal = status->chain_signal[0];
> > +
> > + switch (status->chains) {
> > + case 0x3:
> > + status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> > + status->signal = max(status->signal,
> > +status->chain_signal[1]);
> > + break;
> > + case 0x7:
> > + status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> > + status->signal = max(status->signal,
> > +status->chain_signal[2]);
> > + break;
> > + case 0xf:
> > + status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> > + status->signal = max(status->signal,
> > +status->chain_signal[3]);
> > + break;
> > + default:
> > + break;
> > + }
> > rxd += 6;
> > if ((u8 *)rxd - skb->data >= skb->len)
> > return -EINVAL;
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > index 18ad4b8a3807..b00ce8db58e9
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > @@ -98,6 +98,11 @@ enum rx_pkt_type {
> > #define MT_RXV2_GROUP_ID GENMASK(26, 21)
> > #define MT_RXV2_LENGTHGENMASK(20, 0)
> >
> > +#define MT_RXV4_RCPI3 GENMASK(31, 24)
> > +#define MT_RXV4_RCPI2 GENMASK(23, 16)
> > +#define MT_RXV4_RCPI1 GENMASK(15, 8)
> > +#define MT_RXV4_RCPI0 GENMASK(7, 0)
> > +
> > enum tx_header_format {
> > MT_HDR_FORMAT_802_3,
> > MT_HDR_FORMAT_CMD,
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1] clk: mediatek: mt8183: Register 13MHz clock earlier for clocksource
On Fri, 2019-06-07 at 10:59 -0700, Stephen Boyd wrote:
> Quoting Weiyi Lu (2019-06-06 20:11:52)
> > diff --git a/drivers/clk/mediatek/clk-mt8183.c
> > b/drivers/clk/mediatek/clk-mt8183.c
> > index 9d86510..a8f50bc 100644
> > --- a/drivers/clk/mediatek/clk-mt8183.c
> > +++ b/drivers/clk/mediatek/clk-mt8183.c
> > @@ -1167,37 +1169,62 @@ static int clk_mt8183_apmixed_probe(struct
> > platform_device *pdev)
> > return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> > }
> >
> > +static struct clk_onecell_data *top_clk_data;
> > +
> > +static void clk_mt8183_top_init_early(struct device_node *node)
> > +{
> > + int i;
> > +
> > + if (!top_clk_data) {
>
> Is this function ever called more than once? I believe the answer is no
> so this check should be removed.
>
Thanks for reminding. I'll fix in next version.
> > + top_clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
> > +
> > + for (i = 0; i < CLK_TOP_NR_CLK; i++)
> > + top_clk_data->clks[i] = ERR_PTR(-EPROBE_DEFER);
> > + }
> > +
> > + mtk_clk_register_factors(top_early_divs, ARRAY_SIZE(top_early_divs),
> > + top_clk_data);
> > +
> > + of_clk_add_provider(node, of_clk_src_onecell_get, top_clk_data);
> > +}
> > +
> > +CLK_OF_DECLARE_DRIVER(mt8183_topckgen, "mediatek,mt8183-topckgen",
> > + clk_mt8183_top_init_early);
> > +
> > static int clk_mt8183_top_probe(struct platform_device *pdev)
> > {
> > struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM,
> > 0);
> > void __iomem *base;
> > - struct clk_onecell_data *clk_data;
> > struct device_node *node = pdev->dev.of_node;
> >
> > base = devm_ioremap_resource(>dev, res);
> > if (IS_ERR(base))
> > return PTR_ERR(base);
> >
> > - clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
> > + if (!top_clk_data)
> > + top_clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
>
> And then this can be removed because top_clk_data must be allocated at
> this point.
>
I'll fix in next version. Many thanks.
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v6 06/10] device connection: Add fwnode_connection_find_match()
Hi Heikki, On Fri, 2019-06-07 at 13:30 +0300, Heikki Krogerus wrote: > Hi, > > On Wed, May 29, 2019 at 03:43:44PM +0800, Chunfeng Yun wrote: > > From: Heikki Krogerus > > > > The fwnode_connection_find_match() function is exactly the > > same as device_connection_find_match(), except it takes > > struct fwnode_handle as parameter instead of struct device. > > That allows locating device connections before the device > > entries have been created. > > > > Signed-off-by: Heikki Krogerus > > This one is also missing your SoB. > > There are now some other changes to the devcon API in Rafael's tree > [1] that will conflict with this one. I'm attaching a modified version > of the patch that is rebased on top of today's linux-next. If you use > it, you should make a note (probable in the cover letter) that the > series now depends on Rafael's tree. Got it, thanks > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next > > > thanks, >
Re: [bug report][stable] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
Confirmed the following 3 upstream commits can resolve this issue: d2a68c4effd8 x86/ftrace: Do not call function graph from dynamic trampolines 3c0dab44e227 x86/ftrace: Set trampoline pages as executable 7298e24f9042 x86/kprobes: Set instruction page as executable And they are all included in stable 4.19.49. Thanks, Joseph On 19/6/9 22:50, Greg KH wrote: > On Sun, Jun 09, 2019 at 09:10:45PM +0800, Joseph Qi wrote: >> Hi Nadav, >> Thanks for the comments. >> I'll test the 3 patches in the mentioned thread. > > This should all be fixed in the latest release that happened today. If > not, please let us know. > > thanks, > > greg k-h >
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Andre,
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, 3 Jun 2019 09:32:42 -0700
> Florian Fainelli wrote:
>
> Hi,
>
> > On 6/3/19 1:30 AM, peng@nxp.com wrote:
> > > From: Peng Fan
> > >
> > > This mailbox driver implements a mailbox which signals transmitted
> > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > receiver is implemented in firmware and can synchronously return
> > > data when it returns execution to the non-secure world again.
> > > An asynchronous receive path is not implemented.
> > > This allows the usage of a mailbox to trigger firmware actions on
> > > SoCs which either don't have a separate management processor or on
> > > which such a core is not available. A user of this mailbox could be
> > > the SCP interface.
> > >
> > > Modified from Andre Przywara's v2 patch
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > >
> re.kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%
> 7Cpen
> > >
> g.fan%40nxp.com%7C15c4180b8fe5405d3de808d6ea81d5f1%7C686ea1d3bc
> 2b4c6
> > >
> fa92cd99c5c301635%7C0%7C0%7C636954240720601454sdata=1Cp
> WSgTH7lF
> > > cBKxJnLeIDw%2FDAQJJO%2FVypV1LUU1BRQA%3Dreserved=0
> > >
> > > Cc: Andre Przywara
> > > Signed-off-by: Peng Fan
> > > ---
> >
> > [snip]
> >
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> >
> > That flag appears unused.
> >
> > > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > > + struct device *dev = >dev;
> > > + struct mbox_controller *mbox;
> > > + struct arm_smc_chan_data *chan_data;
> > > + const char *method;
> > > + bool use_hvc = false;
> > > + int ret, irq_count, i;
> > > + u32 val;
> > > +
> > > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
> > > + if (val < 1 || val > INT_MAX) {
> > > + dev_err(dev, "invalid arm,num-chans value %u
> of %pOFn\n", val,
> > > +pdev->dev.of_node);
>
> Isn't the of_node parameter redundant, because dev_err() already takes care
> of that?
I'll remove that.
>
> > > + return -EINVAL;
> > > + }
> > > + }
> >
> > Should not the upper bound check be done against UINT_MAX since val is
> > an unsigned int?
>
> But wouldn't that be somewhat pointless, given that val is a u32? So I guess
> we could just condense this down to:
> ...
> if (!val) {
> ...
make sense.
>
> > > +
> > > + irq_count = platform_irq_count(pdev);
> > > + if (irq_count == -EPROBE_DEFER)
> > > + return irq_count;
> > > +
> > > + if (irq_count && irq_count != val) {
> > > + dev_err(dev, "Interrupts not match num-chans\n");
> >
> > Interrupts property does not match \"arm,num-chans\" would be more
> correct.
>
> Given that interrupts are optional, do we have to rely on this?
If there is interrupt property, the interrupts should match channel counts.
Do we actually
> need one interrupt per channel?
I thought about this, provide one interrupt for all channels.
But there is no good way to let interrupt handlers know which
channel triggers the interrupt. So I use one interrupt per channel.
>
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (!of_property_read_string(dev->of_node, "method", )) {
> > > + if (!strcmp("hvc", method)) {
> > > + use_hvc = true;
> > > + } else if (!strcmp("smc", method)) {
> > > + use_hvc = false;
> > > + } else {
> > > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > > + method);
> > > +
> > > + return -EINVAL;
> > > + }
> >
> > Having at least one method specified does not seem to be checked later
> > on in the code, so if I omitted to specify that property, we would
> > still register the mailbox and default to use "smc" since the
> > ARM_SMC_MBOX_USE_HVC flag would not be set, would not we want to
> make
> > sure that we do have in fact a valid method specified given the
> > binding documents that property as mandatory?
> >
> > [snip]
> >
> > > + mbox->txdone_poll = false;
> > > + mbox->txdone_irq = false;
> > > + mbox->ops = _smc_mbox_chan_ops;
> > > + mbox->dev = dev;
> > > +
> > > + ret = mbox_controller_register(mbox);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + platform_set_drvdata(pdev, mbox);
> >
> > I would move this above mbox_controller_register() that way there is
> > no room for race conditions in case another part of the driver expects
> > to have pdev->dev.drvdata set before the mbox controller is registered.
> > Since you use devm_* functions for everything, you may even remove
> > that call.
> >
> > [snip]
> >
> > > +#ifndef _LINUX_ARM_SMC_MAILBOX_H_
> > > +#define _LINUX_ARM_SMC_MAILBOX_H_
> > > +
> > > +struct arm_smccc_mbox_cmd {
> > > + unsigned long a0, a1, a2, a3, a4, a5, a6, a7; };
> >
> > Do you expect this to be used by other in-kernel users? If so, it
> > might be good to document how a0 can have a special
Dear Friend (Assalamu Alaikum),
-- Dear Friend (Assalamu Alaikum), I came across your e-mail contact prior a private search while in need of your assistance. My name is Aisha Al-Qaddafi a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi). I have investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00 ) and i need a trusted investment Manager/Partner because of my current refugee status, however, I am interested in you for investment project assistance in your country, may be from there, we can build business relationship in the nearest future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project on my behalf kindly reply urgent to enable me provide you more information about the investment funds. Your Urgent Reply Will Be Appreciated. write me at this email address( ayishagdda...@mail.com ) for further discussion. Best Regards Mrs Aisha Al-Qaddafi Reply to: ayishagdda...@mail.com
RE: [PATCH 4.14 03/35] neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit
Hi again.
> -Original Message-
> From: stable-ow...@vger.kernel.org
> [mailto:stable-ow...@vger.kernel.org] On Behalf Of Nobuhiro Iwamatsu
> Sent: Monday, June 10, 2019 10:10 AM
> To: Greg Kroah-Hartman
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Alan Maguire
> ; David Ahern ; David S.
> Miller
> Subject: Re: [PATCH 4.14 03/35] neighbor: Call __ipv4_neigh_lookup_noref
> in neigh_xmit
>
> Hi,
>
> On Sun, Jun 09, 2019 at 06:42:09PM +0200, Greg Kroah-Hartman wrote:
> > From: David Ahern
> >
> > [ Upstream commit 4b2a2bfeb3f056461a90bd621e8bd7d03fa47f60 ]
> >
> > Commit cd9ff4de0107 changed the key for IFF_POINTOPOINT devices to
> > INADDR_ANY but neigh_xmit which is used for MPLS encapsulations was
> > not updated to use the altered key. The result is that every packet
> Tx
> > does a lookup on the gateway address which does not find an entry, a
> > new one is created only to find the existing one in the table right
> > before the insert since arp_constructor was updated to reset the
> > primary key. This is seen in the allocs and destroys counters:
> > ip -s -4 ntable show | head -10 | grep alloc
> >
> > which increase for each packet showing the unnecessary overhread.
> >
> > Fix by having neigh_xmit use __ipv4_neigh_lookup_noref for
> NEIGH_ARP_TABLE.
> >
> > Fixes: cd9ff4de0107 ("ipv4: Make neigh lookup keys for
> > loopback/point-to-point devices be INADDR_ANY")
> > Reported-by: Alan Maguire
> > Signed-off-by: David Ahern
> > Tested-by: Alan Maguire
> > Signed-off-by: David S. Miller
> > Signed-off-by: Greg Kroah-Hartman
> > ---
>
> This commit also requires the following commit:
>
> commit 9b3040a6aafd7898ece7fc7efcbca71e42aa8069
> Author: David Ahern
> Date: Sun May 5 11:16:20 2019 -0700
>
> ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled
>
> Define __ipv4_neigh_lookup_noref to return NULL when CONFIG_INET is
> disabled.
>
> Fixes: 4b2a2bfeb3f0 ("neighbor: Call __ipv4_neigh_lookup_noref in
> neigh_xmit")
> Reported-by: kbuild test robot
> Signed-off-by: David Ahern
> Signed-off-by: David S. Miller
>
> And this is also necessary for 4.4.y, 4.14.y, 4.19.y and 5.1.y.
4.4.y, 4.9.y, 4.19.y and 5.1.y.
> Please apply this commit.
>
Best regards,
Nobuhiro
Re: [PATCH 4.14 03/35] neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit
Hi,
On Sun, Jun 09, 2019 at 06:42:09PM +0200, Greg Kroah-Hartman wrote:
> From: David Ahern
>
> [ Upstream commit 4b2a2bfeb3f056461a90bd621e8bd7d03fa47f60 ]
>
> Commit cd9ff4de0107 changed the key for IFF_POINTOPOINT devices to
> INADDR_ANY but neigh_xmit which is used for MPLS encapsulations was not
> updated to use the altered key. The result is that every packet Tx does
> a lookup on the gateway address which does not find an entry, a new one
> is created only to find the existing one in the table right before the
> insert since arp_constructor was updated to reset the primary key. This
> is seen in the allocs and destroys counters:
> ip -s -4 ntable show | head -10 | grep alloc
>
> which increase for each packet showing the unnecessary overhread.
>
> Fix by having neigh_xmit use __ipv4_neigh_lookup_noref for NEIGH_ARP_TABLE.
>
> Fixes: cd9ff4de0107 ("ipv4: Make neigh lookup keys for
> loopback/point-to-point devices be INADDR_ANY")
> Reported-by: Alan Maguire
> Signed-off-by: David Ahern
> Tested-by: Alan Maguire
> Signed-off-by: David S. Miller
> Signed-off-by: Greg Kroah-Hartman
> ---
This commit also requires the following commit:
commit 9b3040a6aafd7898ece7fc7efcbca71e42aa8069
Author: David Ahern
Date: Sun May 5 11:16:20 2019 -0700
ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled
Define __ipv4_neigh_lookup_noref to return NULL when CONFIG_INET is
disabled.
Fixes: 4b2a2bfeb3f0 ("neighbor: Call __ipv4_neigh_lookup_noref in
neigh_xmit")
Reported-by: kbuild test robot
Signed-off-by: David Ahern
Signed-off-by: David S. Miller
And this is also necessary for 4.4.y, 4.14.y, 4.19.y and 5.1.y.
Please apply this commit.
Best regards,
Nobuhiro
Re: [PATCH] timers: Fix up get_target_base() to use old base properly
On Thu, Jun 06, 2019 at 12:28:08PM -0300, Marcelo Tosatti wrote: > On Mon, Jun 03, 2019 at 09:29:44PM +0800, Peter Xu wrote: > > get_target_base() in the timer code is not using the "base" parameter > > at all. My gut feeling is that instead of removing that extra > > parameter, what we really want to do is "return the old base if it > > does not suite for a new one". > > Hi Peter, Hi, Marcelo, > > I think its a dead parameter: you always want to use the local base > if the timer is not pinned. Thanks for the comment. But what if it was pinned? Could the old code always do right even in the scenario I mentioned below? https://lkml.org/lkml/2019/6/4/34 Also note that if the timer was not pinned, IMHO it'll go into the check below and it seems to likely to have another timer base instead of the local base if it's not a housekeeping cpu (because get_nohz_timer_target() will always try to provision timers onto the housekeeping ones), or did I misunderstand your comment? #if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON) if (static_branch_likely(_migration_enabled) && !(tflags & TIMER_PINNED)) return get_timer_cpu_base(tflags, get_nohz_timer_target()); #endif Regards, -- Peter Xu
[PATCH v2] lockdep: fix warning: print_lock_trace defined but not used
From: John Hubbard
Commit 0d2cc3b34532 ("locking/lockdep: Move valid_state() inside
CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING") moved the only usage of
print_lock_trace() that was originally outside of the CONFIG_PROVE_LOCKING
case. It moved that usage into a different case: CONFIG_PROVE_LOCKING &&
CONFIG_TRACE_IRQFLAGS. That leaves things not symmetrical, and as a result,
the following warning fires on my build, when I have
!CONFIG_TRACE_IRQFLAGS && !CONFIG_PROVE_LOCKING
set:
kernel/locking/lockdep.c:2821:13: warning: ‘print_lock_trace’ defined
but not used [-Wunused-function]
Fix this by annotating print_lock_trace() with "__maybe_unused".
Thanks to Paul E. McKenney for suggesting this less intrusive fix,
as compared to adding more ifdef noise.
Fixes: 0d2cc3b34532 ("locking/lockdep: Move valid_state() inside
CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING")
Cc: Frederic Weisbecker
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Signed-off-by: John Hubbard
---
kernel/locking/lockdep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c47788fa85f9..2726dafdb29b 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2818,7 +2818,8 @@ static inline int validate_chain(struct task_struct *curr,
return 1;
}
-static void print_lock_trace(struct lock_trace *trace, unsigned int spaces)
+static void __maybe_unused print_lock_trace(struct lock_trace *trace,
+ unsigned int spaces)
{
}
#endif
--
2.21.0
Re: [PATCH 1/3] mfd: apple-ibridge: Add Apple iBridge MFD driver.
On Tue, May 07, 2019 at 01:24:15PM +0100, Lee Jones wrote: > On Sun, 21 Apr 2019, Ronald Tschalär wrote: > > > The iBridge device provides access to several devices, including: > > - the Touch Bar > > - the iSight webcam > > - the light sensor > > - the fingerprint sensor > > > > This driver provides the core support for managing the iBridge device > > and the access to the underlying devices. In particular, since the > > functionality for the touch bar and light sensor is exposed via USB HID > > interfaces, and the same HID device is used for multiple functions, this > > driver provides a multiplexing layer that allows multiple HID drivers to > > be registered for a given HID device. This allows the touch bar and ALS > > driver to be separated out into their own modules. > > > > Signed-off-by: Ronald Tschalär > > --- > > drivers/mfd/Kconfig | 15 + > > drivers/mfd/Makefile | 1 + > > drivers/mfd/apple-ibridge.c | 883 ++ > > I haven't taken a thorough look through, but I can tell you that the > vast majority of what you're trying to do here does not belong in > MFD. MFD drivers are used to register child devices. Almost all > functionality or 'real work' should be contained in the drivers the > MFD registers, not in the MFD parent itself. You will need to move > all 'real work' out into the subordinate device drivers for > acceptance. Thanks for your feedback. That was/is the idea: the actual Touch Bar and ALS driver code is in separate modules - what is left in the appple-ibridge mfd driver is a fairly generic hid driver demultiplexer. However, that could be moved out into it's own helper/module. Having said that, it looks like the preference is to do all of this as a hid driver with virtual hid devices instead of as an mfd driver. Cheers, Ronald
Re: [PATCH 1/1] lockdep: fix warning: print_lock_trace defined but not used
On 6/9/19 6:51 AM, Paul E. McKenney wrote:
> On Tue, May 21, 2019 at 12:08:08AM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
>>
>> Commit 0d2cc3b34532 ("locking/lockdep: Move valid_state() inside
>> CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING") moved the only usage of
>> print_lock_trace() that was originally outside of the CONFIG_PROVE_LOCKING
>> case. It moved that usage into a different case: CONFIG_PROVE_LOCKING &&
>> CONFIG_TRACE_IRQFLAGS. That leaves things not symmetrical, and as a result,
>> the following warning fires on my build, when I have
>>
>> !CONFIG_TRACE_IRQFLAGS && !CONFIG_PROVE_LOCKING
>>
>> set:
>>
>> kernel/locking/lockdep.c:2821:13: warning: ‘print_lock_trace’ defined
>> but not used [-Wunused-function]
>>
>> Fix this by only defining print_lock_trace() in cases in which is it
>> called.
>>
>> Fixes: 0d2cc3b34532 ("locking/lockdep: Move valid_state() inside
>> CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING")
>> Cc: Frederic Weisbecker
>> Cc: Andrew Morton
>> Cc: Linus Torvalds
>> Cc: Paul E. McKenney
>> Cc: Peter Zijlstra
>> Cc: Thomas Gleixner
>> Cc: Will Deacon
>> Signed-off-by: John Hubbard
>> ---
>> kernel/locking/lockdep.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
>> index d06190fa5082..3065dc36c27a 100644
>> --- a/kernel/locking/lockdep.c
>> +++ b/kernel/locking/lockdep.c
>> @@ -2817,11 +2817,14 @@ static inline int validate_chain(struct task_struct
>> *curr,
>> return 1;
>> }
>>
>> +#if defined(CONFIG_TRACE_IRQFLAGS)
>> static void print_lock_trace(struct lock_trace *trace, unsigned int spaces)
>
> This works, but another approach is to put "__maybe_unused" in the
> above declaration, which avoids the need to have "#if" in a .c file.
Good idea, that approach appeals to me here, because tracing is a natural fit
for "might not be used" types of functions.
> But this file already has quite a few #if and #ifdef commands, so maybe
> it is OK here.
>
> Also, "#ifdef CONFIG_TRACE_IRQFLAGS" is a bit more conventional than
> the above, should the "__maybe_unused" be undesirable.
ah, OK, I'll keep that in mind. (The two seemed identical to my mind, but
it's good to make things look like surrounding code, of course.)
thanks,
--
John Hubbard
NVIDIA
>
> Yet another approach is to move this function to include/linux/lockdep.h,
> where #ifdef is considered less objectionable.
>
> But I must defer to the maintainers.
>
> Thanx, Paul
Re: [PATCH 5.1 00/70] 5.1.9-stable review
On Sun, Jun 09, 2019 at 06:41:11PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.1.9 release. > There are 70 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue 11 Jun 2019 04:40:04 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.9-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.1.y > and the diffstat can be found below. > > thanks, > > greg k-h > > - Compiled and booted. No regressions on x86_64. THX
Re: [RFC next v1 0/5] stmmac: honor the GPIO flags for the PHY reset GPIO
Hi Andrew, On Sun, Jun 9, 2019 at 10:45 PM Andrew Lunn wrote: > > > Patch #1 and #4 are minor cleanups which follow the boyscout rule: > > "Always leave the campground cleaner than you found it." > > > I > > am also looking for suggestions how to handle these cross-tree changes > > (patch #2 belongs to the linux-gpio tree, patches #1, 3 and #4 should > > go through the net-next tree. I will re-send patch #5 separately as > > this should go through Kevin's linux-amlogic tree). > > Hi Martin > > Patches 1 and 4 don't seem to have and dependencies. So i would > suggest splitting them out and submitting them to netdev for merging > independent of the rest. OK, I will do that but after the GPIO changes are applied because only then I can get rid of that "np" variable > Linus can probably create a stable branch with the GPIO changes, which > David can pull into net-next, and then apply the stmmac changes on > top. let's go this way since Linus is happy with that route also. I'll re-spin v2 tomorrow Martin
Re: [PATCH 4.4 000/241] 4.4.181-stable review
stable-rc/linux-4.4.y boot: 94 boots: 1 failed, 92 passed with 1 conflict (v4.4.180-242-gc9c6a085b72e) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.180-242-gc9c6a085b72e/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.180-242-gc9c6a085b72e/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.180-242-gc9c6a085b72e Git Commit: c9c6a085b72ef62ce2cdcfbee79476ad2bdbd703 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 44 unique boards, 20 SoC families, 14 builds out of 190 Boot Regressions Detected: x86_64: x86_64_defconfig: gcc-8: qemu: lab-baylibre: new failure (last pass: v4.4.180-230-g17950b5be27c) Boot Failure Detected: arm64: defconfig: gcc-8: qcom-qdf2400: 1 failed lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu: lab-drue: PASS (gcc-8) lab-baylibre: FAIL (gcc-8) lab-collabora: PASS (gcc-8) lab-linaro-lkft: PASS (gcc-8) lab-mhart: PASS (gcc-8) --- For more info write to
Re: [RFC next v1 5/5] arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY reset line
Hi Linus, On Mon, Jun 10, 2019 at 12:06 AM Linus Walleij wrote: > > On Sun, Jun 9, 2019 at 11:36 PM Martin Blumenstingl > wrote: > > > > If "snps,reset-active-low" was set it results in the sequence 1, 0, 1 > > > if it is not set it results in the sequence 0, 1, 0. > > > > I'm changing this logic with earlier patches of this series. > > can you please look at these as well because GPIO_OPEN_SOURCE doesn't > > work with the old version of stmmac_mdio_reset() that you are showing. > > OK but the logic is the same, just that the polarity handling is moved > into gpiolib. > > > > The high (reset) is asserted by switching the pin into high-z open drain > > > mode, which happens by switching the line into input mode in some > > > cases. > > > > > > I think the real reason it works now is that reset is actually active > > > high. > > > > let me write down what I definitely know so far > > > > the RTL8211F PHY wants the reset line to be LOW for a few milliseconds > > to put it into reset mode. > > driving the reset line HIGH again takes it out of reset. > > > > Odroid-N2's schematics [0] (page 30) shows that there's a pull-up for > > the PHYRSTB pin, which is also connected to the NRST signal which is > > GPIOZ_15 > > Looks correct, R143 is indeed a pull up indicating that the line is > open drain, active low. good so far > > > It makes a lot of sense, since if it resets the device when set as input > > > (open drain) it holds all devices on that line in reset, which is likely > > > what you want as most GPIOs come up as inputs (open drain). > > > A pull-up resistor will ascertain that the devices are in reset. > > > > my understanding is that the pull-up resistor holds it out of reset > > driving GPIOZ_15's (open drain) output LOW pulls the signal to ground > > and asserts the reset > > Yep that seems correct. > > Oh I guess it is this: > > amlogic,tx-delay-ns = <2>; > - snps,reset-gpio = < GPIOZ_14 0>; > + snps,reset-gpio = < GPIOZ_15 GPIO_OPEN_SOURCE>; > snps,reset-delays-us = <0 1 100>; > - snps,reset-active-low; > > Can you try: > snps,reset-gpio = < GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>; > ? I tried it and it works! > Open source is nominally (and rarely) used for lines that are active high. > For lines that are active low, we want to use open drain combined > with active low. thank you for the explanation - I'll take your version for v2 :) Martin
Re: [PATCH 4.9 00/83] 4.9.181-stable review
stable-rc/linux-4.9.y boot: 107 boots: 1 failed, 106 passed (v4.9.180-84-g4fcf72df7bc7) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.180-84-g4fcf72df7bc7/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.180-84-g4fcf72df7bc7/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.180-84-g4fcf72df7bc7 Git Commit: 4fcf72df7bc71264d86e616874a0a0cd382f1b12 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 53 unique boards, 23 SoC families, 15 builds out of 197 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: omap3-beagle-xm: lab-baylibre: new failure (last pass: v4.9.180-62-gd9b5fd7ab17b) Boot Failure Detected: arm: omap2plus_defconfig: gcc-8: omap3-beagle-xm: 1 failed lab --- For more info write to
Re: [RFC next v1 5/5] arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY reset line
On Sun, Jun 9, 2019 at 11:36 PM Martin Blumenstingl wrote: > > If "snps,reset-active-low" was set it results in the sequence 1, 0, 1 > > if it is not set it results in the sequence 0, 1, 0. > > I'm changing this logic with earlier patches of this series. > can you please look at these as well because GPIO_OPEN_SOURCE doesn't > work with the old version of stmmac_mdio_reset() that you are showing. OK but the logic is the same, just that the polarity handling is moved into gpiolib. > > The high (reset) is asserted by switching the pin into high-z open drain > > mode, which happens by switching the line into input mode in some > > cases. > > > > I think the real reason it works now is that reset is actually active high. > > let me write down what I definitely know so far > > the RTL8211F PHY wants the reset line to be LOW for a few milliseconds > to put it into reset mode. > driving the reset line HIGH again takes it out of reset. > > Odroid-N2's schematics [0] (page 30) shows that there's a pull-up for > the PHYRSTB pin, which is also connected to the NRST signal which is > GPIOZ_15 Looks correct, R143 is indeed a pull up indicating that the line is open drain, active low. > > It makes a lot of sense, since if it resets the device when set as input > > (open drain) it holds all devices on that line in reset, which is likely > > what you want as most GPIOs come up as inputs (open drain). > > A pull-up resistor will ascertain that the devices are in reset. > > my understanding is that the pull-up resistor holds it out of reset > driving GPIOZ_15's (open drain) output LOW pulls the signal to ground > and asserts the reset Yep that seems correct. Oh I guess it is this: amlogic,tx-delay-ns = <2>; - snps,reset-gpio = < GPIOZ_14 0>; + snps,reset-gpio = < GPIOZ_15 GPIO_OPEN_SOURCE>; snps,reset-delays-us = <0 1 100>; - snps,reset-active-low; Can you try: snps,reset-gpio = < GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>; ? Open source is nominally (and rarely) used for lines that are active high. For lines that are active low, we want to use open drain combined with active low. Yours, Linus Walleij
€ 2.000.000,00 Euro
Ich bin Herr Richard Wahl der Mega-Gewinner von $ 533M In Mega Millions Jackpot spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach einem Spinball ausgewählt. Ich habe den größten Teil meines Vermögens auf eine Reihe von Wohltätigkeitsorganisationen und Organisationen verteilt. Ich habe mich freiwillig dazu entschieden, Ihnen den Betrag von € 2.000.000,00 zu spenden eine der ausgewählten 5, um meine Gewinne zu überprüfen. Das ist dein Spendencode: [DF00430342018] Antworten Sie mit dem Spendencode auf diese E-Mail: richardpoverty...@gmail.com
Re: [RFC next v1 0/5] stmmac: honor the GPIO flags for the PHY reset GPIO
On Sun, Jun 9, 2019 at 10:45 PM Andrew Lunn wrote: > Linus can probably create a stable branch with the GPIO changes, which > David can pull into net-next, and then apply the stmmac changes on > top. Sure thing, just tell me what to queue and I'll create an immutable branch for this that David can pull. Yours, Linus Walleij
Re: [RFC next v1 3/5] net: stmmac: use GPIO descriptors in stmmac_mdio_reset
On Sun, Jun 9, 2019 at 8:06 PM Martin Blumenstingl wrote: > Switch stmmac_mdio_reset to use GPIO descriptors. GPIO core handles the > "snps,reset-gpio" for GPIO descriptors so we don't need to take care of > it inside the driver anymore. > > The advantage of this is that we now preserve the GPIO flags which are > passed via devicetree. This is required on some newer Amlogic boards > which use an Open Drain pin for the reset GPIO. This pin can only output > a LOW signal or switch to input mode but it cannot output a HIGH signal. > There are already devicetree bindings for these special cases and GPIO > core already takes care of them but only if we use GPIO descriptors > instead of GPIO numbers. > > Signed-off-by: Martin Blumenstingl This is in line with how I want the gpiolib to just swallow all quirks, so: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] drivers/ata: print trim features at device initialization
On Sat, 2019-06-08 at 17:13 +0300, Konstantin Khlebnikov wrote: > > On 08.06.2019 11:25, Christoph Hellwig wrote:> On Fri, Jun 07, 2019 > > at 10:34:39AM +0300, Konstantin Khlebnikov wrote: > > > > > > Do we really need to spam dmesg with even more ATA crap? What > > about > > > a sysfs file that can be read on demand instead? > > > > > > > Makes sense. > > > > Trim state is exposed for ata_device: > > /sys/class/ata_device/devX.Y/trim > > but there is no link from scsi device to ata device so they hard to > > match. > > > > I'll think about it. > > Nope. There is no obvious way to link scsi device with ata_device. > ata_device is built on top of "transport_class" and > "attribute_container". > This some extremely over engineered sysfs framework used only in > ata/scsi. I don't want to touch this. You don't need to know any of that. The problem is actually when the ata transport classes were first created, the devices weren't properly parented. What should have happened, like every other transport class, is that the devices should have descended down to the scsi device as the leaf in an integrated fashion. Instead, what we seem to have is three completely separate trees. So if you look at a SAS device, you see from the pci device: host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/block/sdb/sdb1 But if you look at a SATA device, you see three separate paths: ata3/host3/target3\:0\:0/3\:0\:0\:0/block/sda/sda1 ata3/link3/dev3.0/ata_device/dev3.0 ata3/ata_port/ata3 Instead of an integrated tree Unfortunately, this whole thing is unfixable now. If I integrate the tree properly, the separate port and link directories will get subsumed and we won't be able to recover them with judicious linking so scripts relying on them will break. The best we can probably do is add additional links with what we have. To follow the way we usually do it, there should be a link from the ata device to the scsi target, but that wouldn't help you find the "trim" files, so it sounds like you want a link from the scsi device to the ata device, which would? James
Re: [RFC next v1 5/5] arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY reset line
Hi Linus, On Sun, Jun 9, 2019 at 11:17 PM Linus Walleij wrote: > > On Sun, Jun 9, 2019 at 8:06 PM Martin Blumenstingl > wrote: > > > The PHY reset line and interrupt line are swapped on the X96 Max > > compared to the Odroid-N2 schematics. This means: > > - GPIOZ_14 is the interrupt line (on the Odroid-N2 it's the reset line) > > - GPIOZ_15 is the reset line (on the Odroid-N2 it's the interrupt line) > > > > Also the GPIOZ_14 and GPIOZ_15 pins are special. The datasheet describes > > that they are "3.3V input tolerant open drain (OD) output pins". This > > means the GPIO controller can drive the output LOW to reset the PHY. To > > release the reset it can only switch the pin to input mode. The output > > cannot be driven HIGH for these pins. > > This requires configuring the reset line as GPIO_OPEN_SOURCE because > > otherwise the PHY will be stuck in "reset" state (because driving the > > pin HIGH seeems to result in the same signal as driving it LOW). > > This far it seems all right. ...except the "seeems" typo which I just noticed. thank you for sanity-checking this so far! > > Switch to GPIOZ_15 for the reset GPIO with the correct flags and drop > > the "snps,reset-active-low" property as this is now encoded in the > > GPIO_OPEN_SOURCE flag. > > Open source doesn't imply active low. > > We have this in stmmac_mdio_reset(): > > gpio_direction_output(data->reset_gpio, > data->active_low ? 1 : 0); > if (data->delays[0]) > msleep(DIV_ROUND_UP(data->delays[0], 1000)); > > gpio_set_value(data->reset_gpio, data->active_low ? 0 : 1); > if (data->delays[1]) > msleep(DIV_ROUND_UP(data->delays[1], 1000)); > > gpio_set_value(data->reset_gpio, data->active_low ? 1 : 0); > if (data->delays[2]) > msleep(DIV_ROUND_UP(data->delays[2], 1000)); > > If "snps,reset-active-low" was set it results in the sequence 1, 0, 1 > if it is not set it results in the sequence 0, 1, 0. I'm changing this logic with earlier patches of this series. can you please look at these as well because GPIO_OPEN_SOURCE doesn't work with the old version of stmmac_mdio_reset() that you are showing. > The high (reset) is asserted by switching the pin into high-z open drain > mode, which happens by switching the line into input mode in some > cases. > > I think the real reason it works now is that reset is actually active high. let me write down what I definitely know so far the RTL8211F PHY wants the reset line to be LOW for a few milliseconds to put it into reset mode. driving the reset line HIGH again takes it out of reset. Odroid-N2's schematics [0] (page 30) shows that there's a pull-up for the PHYRSTB pin, which is also connected to the NRST signal which is GPIOZ_15 > It makes a lot of sense, since if it resets the device when set as input > (open drain) it holds all devices on that line in reset, which is likely > what you want as most GPIOs come up as inputs (open drain). > A pull-up resistor will ascertain that the devices are in reset. my understanding is that the pull-up resistor holds it out of reset driving GPIOZ_15's (open drain) output LOW pulls the signal to ground and asserts the reset > Other than the commit message: > Reviewed-by: Linus Walleij thank you for looking into this! Martin [0] https://dn.odroid.com/S922X/ODROID-N2/Schematic/odroid-n2_rev0.4_20190307.pdf
Re: [PATCH v2 2/3] i2c-mux-gpio: Unpin the platform-specific GPIOs request code
On 2019-04-26 01:20, Serge Semin wrote:
> The GPIOs request loop can be safely moved to a separate function.
> First of all it shall improve the code readability. Secondly the
> initialization loop at this point is used for both of- and
> platform_data-based initialization paths, but it will be changed in
> the next patch, so by isolating the code we'll simplify the future
> work.
This patch is just preparatory for patch 3/3, as I see it. And since
I'm not really fond of the end result after patch 3/3, I'm going to
sum up my issues here, instead of trying do it piecemeal in the two
patches.
Linus and Jean, for your convenience, link to this patch series [1].
While I agree with the goal (to use the more flexible gpiod functions
to get at the gpio descriptors), the cost is too high when the init
code for platform and OF is basically completely separated. I much
prefer the approach taken by Linus [2], which instead converts the
platform interface and its single user to use gpio descriptors instead
of the legacy gpio interface. The i2c-mux-gpio code then has the
potential to take a unified approach to the given gpio descriptors,
wherever they are originating from, which is much nicer than the
code-fork in this series.
I also think it is pretty pointless to first split the code into
platform and OF paths, just so that the next patch (from Linus) can
unify the two paths again. I'd like to skip the intermediate step.
So, I'm hoping for the following to happen.
1. Sergey sends a revised patch for patch 1/3.
2. I put the patch on the for-next branch.
3. Linus rebases his patch on top of that (while thinking about
the questions raised by Sergey).
4. Sergey tests the result, I and Jean review it, then possibly
go back to 3.
5. I put the patch on the for-next branch.
Is that ok? Or is someone insisting that we take a detour?
Cheers,
Peter
[1] https://patchwork.ozlabs.org/cover/1091119/ (and show related)
[2] https://patchwork.ozlabs.org/patch/1109521/
> Signed-off-by: Serge Semin
>
> ---
> Changelog v2
> - Create a dedicated initial_state field in the "gpiomux" structure to
> keep an initial channel selector state.
> ---
> drivers/i2c/muxes/i2c-mux-gpio.c | 113 +++
> 1 file changed, 68 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c
> b/drivers/i2c/muxes/i2c-mux-gpio.c
> index 54158b825acd..e10f72706b99 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> @@ -20,7 +20,8 @@
>
> struct gpiomux {
> struct i2c_mux_gpio_platform_data data;
> - unsigned gpio_base;
> + unsigned int gpio_base;
> + unsigned int initial_state;
> struct gpio_desc **gpios;
> };
>
> @@ -162,13 +163,68 @@ static int i2c_mux_gpio_probe_plat(struct gpiomux *mux,
> return 0;
> }
>
> +static int i2c_mux_gpio_request_plat(struct gpiomux *mux,
> + struct platform_device *pdev)
> +{
> + struct i2c_mux_core *muxc = platform_get_drvdata(pdev);
> + struct gpio_desc *gpio_desc;
> + struct i2c_adapter *root;
> + struct device *gpio_dev;
> + int i, ret;
> +
> + root = i2c_root_adapter(>parent->dev);
> +
> + for (i = 0; i < mux->data.n_gpios; i++) {
> + ret = gpio_request(mux->gpio_base + mux->data.gpios[i],
> +"i2c-mux-gpio");
> + if (ret) {
> + dev_err(>dev, "Failed to request GPIO %d\n",
> + mux->data.gpios[i]);
> + goto err_request_gpio;
> + }
> +
> + ret = gpio_direction_output(mux->gpio_base + mux->data.gpios[i],
> + mux->initial_state & (1 << i));
> + if (ret) {
> + dev_err(>dev,
> + "Failed to set direction of GPIO %d to
> output\n",
> + mux->data.gpios[i]);
> + i++;/* gpio_request above succeeded, so must free */
> + goto err_request_gpio;
> + }
> +
> + gpio_desc = gpio_to_desc(mux->gpio_base + mux->data.gpios[i]);
> + mux->gpios[i] = gpio_desc;
> +
> + if (!muxc->mux_locked)
> + continue;
> +
> + gpio_dev = _desc->gdev->dev;
> + muxc->mux_locked = i2c_root_adapter(gpio_dev) == root;
> + }
> +
> + return 0;
> +
> +err_request_gpio:
> + for (; i > 0; i--)
> + gpio_free(mux->gpio_base + mux->data.gpios[i - 1]);
> +
> + return ret;
> +}
> +
> +static void i2c_mux_gpio_free(struct gpiomux *mux)
> +{
> + int i;
> +
> + for (i = 0; i < mux->data.n_gpios; i++)
> + gpiod_free(mux->gpios[i]);
> +}
> +
> static int i2c_mux_gpio_probe(struct platform_device *pdev)
> {
> struct i2c_mux_core *muxc;
> struct gpiomux *mux;
> struct i2c_adapter *parent;
> - struct
Re: [RFC next v1 2/5] gpio: of: parse stmmac PHY reset line specific active-low property
On Sun, Jun 9, 2019 at 11:21 PM Martin Blumenstingl wrote: > my understanding that of_gpio_flags_quirks (which I'm touching with > this patch) is supposed to manage similar quirks to what we have in > stmmac (it also contains some regulator and MMC quirks too). > however, that's exactly the reason why I decided to mark this as RFC - > so I'm eager to hear Linus comments on this The idea with the quirks in gpiolib-of.c is to make device drivers simpler, and phase them over to ignoring quirks for mistakes done in the early days of DT standardization. This feature of the gpiolib API is supposed to make it "narrow and deep": make the generic case simple and handle any hardware description languages (DT or ACPI or board files) and quirks (mostly historical) under the hood. Especially drivers should not need to worry about polarity inversion instead just grab a GPIO descriptor and play away with it, asserting it as 1 and deasserting it as 0 whether that is the right polarity or not, the gpiolib should keep track of polarity no matter how that is described, even with historical weird bools like "snps,active-low" etc. So I think you are probably doing the right thing here. This patch is: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: Question about cacheline bounching with percpu-rwsem and rcu-sync
On Sun, Jun 09, 2019 at 05:22:26AM -0700, Paul E. McKenney wrote: > On Sat, Jun 08, 2019 at 08:24:36PM -0400, Joel Fernandes wrote: > > On Fri, May 31, 2019 at 10:43 AM Joel Fernandes > > wrote: > > [snip] > > > > > > > > Either way, it would be good for you to just try it. Create a kernel > > > > module or similar than hammers on percpu_down_read() and > > > > percpu_up_read(), > > > > and empirically check the scalability on a largish system. Then compare > > > > this to down_read() and up_read() > > > > > > Will do! thanks. > > > > I created a test for this and the results are quite amazing just > > stressed read lock/unlock for rwsem vs percpu-rwsem. > > The test is conducted on a dual socket Intel x86_64 machine with 14 > > cores each socket. > > > > Test runs 10,000,000 loops of rwsem vs percpu-rwsem: > > https://github.com/joelagnel/linux-kernel/commit/8fe968116bd887592301179a53b7b3200db84424 > > Interesting location, but looks functional. ;-) > > > Graphs/Results here: > > https://docs.google.com/spreadsheets/d/1cbVLNK8tzTZNTr-EDGDC0T0cnFCdFK3wg2Foj5-Ll9s/edit?usp=sharing > > > > The completion time of the test goes up somewhat exponentially with > > the number of threads, for the rwsem case, where as for percpu-rwsem > > it is the same. I could add this data to some of the documentation as > > well. > > Actually, the completion time looks to be pretty close to linear in the > number of CPUs. Which is still really bad, don't get me wrong. Sure, yes on second thought it is more linear than exponential :) > Thank you for doing this, and it might be good to have some documentation > on this. In perfbook, I use counters to make this point, and perhaps > I need to emphasize more that it also applies to other algorithms, > including locking. Me, I learned this lesson from a logic analyzer > back in the very early 1990s. This was back in the days before on-CPU > caches when a logic analyzer could actually tell you something about > the detailed execution. ;-) > > The key point is that you can often closely approximate the performance > of synchronization algorithms by counting the number of cache misses and > the number of CPUs competing for each cache line. Cool, thanks for that insight. It has been some years since I used a logic analyzer for some bus protocol debugging, but those are fun! > If you want to get the microbenchmark test code itself upstream, > one approach might be to have a kernel/locking/lockperf.c similar to > kernel/rcu/rcuperf.c. > Thoughts? That sounds great to me, there's no other locking performance tests in the kernel. There's locking api selftests at boot (DEBUG_LOCKING_API_SELFTESTS) which just tests whether lockdep catches locking issues, and there's locktorture, but I believe none of these test for lock performance. I think a lockperf.c could also test other things about locking mechanisms, such as how they perform if the owner of the lock is currently running vs sleeping, while another thread is trying to acquire etc. What do you think? I can add this to my list to do. Right now I'm working on the list-RCU lockdep checking I started to work on [1] and want to post another series soon. Thanks a lot, - Joel [1] https://lkml.org/lkml/2019/6/1/495 https://lore.kernel.org/patchwork/patch/1082846/ > > Thanx, Paul >
Re: [RFC next v1 2/5] gpio: of: parse stmmac PHY reset line specific active-low property
Hi Andrew, On Sun, Jun 9, 2019 at 10:38 PM Andrew Lunn wrote: > > On Sun, Jun 09, 2019 at 08:06:18PM +0200, Martin Blumenstingl wrote: > > The stmmac driver currently ignores the GPIO flags which are passed via > > devicetree because it operates with legacy GPIO numbers instead of GPIO > > descriptors. > > Hi Martin > > I don't think this is the reason. I think historically stmmac messed > up and ignored the flags. There are a number of device tree blobs > which have the incorrect flag value, but since it was always ignored, > it did not matter. Then came along a board which really did need the > flag, but it was too late, it could not be enabled because too many > boards would break. So the hack was made, and snps,reset-active-low > was added. that seems appropriate. I don't know whether you can fetch the GPIO flags when using legacy GPIO numbers. so it may also be a mix of your explanation and mine. in the end it's the same though: stmmac ignores the GPIO flags > Since snps,reset-active-low is a hack, it should not be in the > core. Please don't add it to gpiolib-of.c, keep it within stmmac > driver. I don't know how to keep backwards compatibility with old .dtb / .dts when moving this into the stmmac driver again. let's assume I put the "snps,reset-active-low" inversion logic back into stmmac. then I need to ignore the flags because some .dts file use the flag GPIO_ACTIVE_LOW *and* set "snps,reset-active-low" at the same time. "snps,reset-active-low" would then invert GPIO_ACTIVE_LOW again, which basically results in GPIO_ACTIVE_HIGH however, I can't ignore the flags because then I'm losing the information I need for the newer Amlogic SoCs like open drain / open source. so the logic that I need is: - use GPIO flags from .dtb / .dts - set GPIO_ACTIVE_LOW in addition to the flags if "snps,reset-active-low" is set (this is different to "always invert the output value") my understanding that of_gpio_flags_quirks (which I'm touching with this patch) is supposed to manage similar quirks to what we have in stmmac (it also contains some regulator and MMC quirks too). however, that's exactly the reason why I decided to mark this as RFC - so I'm eager to hear Linus comments on this Martin
Re: [RFC next v1 5/5] arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY reset line
On Sun, Jun 9, 2019 at 8:06 PM Martin Blumenstingl
wrote:
> The PHY reset line and interrupt line are swapped on the X96 Max
> compared to the Odroid-N2 schematics. This means:
> - GPIOZ_14 is the interrupt line (on the Odroid-N2 it's the reset line)
> - GPIOZ_15 is the reset line (on the Odroid-N2 it's the interrupt line)
>
> Also the GPIOZ_14 and GPIOZ_15 pins are special. The datasheet describes
> that they are "3.3V input tolerant open drain (OD) output pins". This
> means the GPIO controller can drive the output LOW to reset the PHY. To
> release the reset it can only switch the pin to input mode. The output
> cannot be driven HIGH for these pins.
> This requires configuring the reset line as GPIO_OPEN_SOURCE because
> otherwise the PHY will be stuck in "reset" state (because driving the
> pin HIGH seeems to result in the same signal as driving it LOW).
This far it seems all right.
> Switch to GPIOZ_15 for the reset GPIO with the correct flags and drop
> the "snps,reset-active-low" property as this is now encoded in the
> GPIO_OPEN_SOURCE flag.
Open source doesn't imply active low.
We have this in stmmac_mdio_reset():
gpio_direction_output(data->reset_gpio,
data->active_low ? 1 : 0);
if (data->delays[0])
msleep(DIV_ROUND_UP(data->delays[0], 1000));
gpio_set_value(data->reset_gpio, data->active_low ? 0 : 1);
if (data->delays[1])
msleep(DIV_ROUND_UP(data->delays[1], 1000));
gpio_set_value(data->reset_gpio, data->active_low ? 1 : 0);
if (data->delays[2])
msleep(DIV_ROUND_UP(data->delays[2], 1000));
If "snps,reset-active-low" was set it results in the sequence 1, 0, 1
if it is not set it results in the sequence 0, 1, 0.
The high (reset) is asserted by switching the pin into high-z open drain
mode, which happens by switching the line into input mode in some
cases.
I think the real reason it works now is that reset is actually active high.
It makes a lot of sense, since if it resets the device when set as input
(open drain) it holds all devices on that line in reset, which is likely
what you want as most GPIOs come up as inputs (open drain).
A pull-up resistor will ascertain that the devices are in reset.
After power on you need to actively de-assert the reset (to low) for
it to go out of reset.
> Fixes: 51d116557b2044 ("arm64: dts: meson-g12a-x96-max: Add Gigabit Ethernet
> Support")
> Signed-off-by: Martin Blumenstingl
Other than the commit message:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH V5 02/11] misc: xilinx-sdfec: add core driver
On Sun, Jun 09, 2019 at 06:48:31PM +, Dragan Cvetic wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Sunday 9 June 2019 12:23 > > To: Dragan Cvetic > > Cc: a...@arndb.de; Michal Simek ; > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > linux-kernel@vger.kernel.org; Derek Kiernan > > Subject: Re: [PATCH V5 02/11] misc: xilinx-sdfec: add core driver > > > > On Sun, Jun 09, 2019 at 01:04:07AM +0100, Dragan Cvetic wrote: > > > Implement a platform driver that matches with xlnx, > > > sd-fec-1.1 device tree node and registers as a character > > > device, including: > > > - SD-FEC driver binds to sdfec DT node. > > > - creates and initialise an initial driver dev structure. > > > - add the driver in Linux build and Kconfig. > > > > > > Tested-by: Dragan Cvetic > > > Signed-off-by: Derek Kiernan > > > Signed-off-by: Dragan Cvetic > > > --- > > > drivers/misc/Kconfig| 12 + > > > drivers/misc/Makefile | 1 + > > > drivers/misc/xilinx_sdfec.c | 118 > > > > > > 3 files changed, 131 insertions(+) > > > create mode 100644 drivers/misc/xilinx_sdfec.c > > > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > > > index 6b0417b..319a6bf 100644 > > > --- a/drivers/misc/Kconfig > > > +++ b/drivers/misc/Kconfig > > > @@ -471,6 +471,18 @@ config PCI_ENDPOINT_TEST > > > Enable this configuration option to enable the host side test > > > driver > > > for PCI Endpoint. > > > > > > +config XILINX_SDFEC > > > + tristate "Xilinx SDFEC 16" > > > + help > > > + This option enables support for the Xilinx SDFEC (Soft Decision > > > + Forward Error Correction) driver. This enables a char driver > > > + for the SDFEC. > > > + > > > + You may select this driver if your design instantiates the > > > + SDFEC(16nm) hardened block. To compile this as a module choose M. > > > + > > > + If unsure, say N. > > > + > > > config MISC_RTSX > > > tristate > > > default MISC_RTSX_PCI || MISC_RTSX_USB > > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile > > > index b9affcd..0cb3546 100644 > > > --- a/drivers/misc/Makefile > > > +++ b/drivers/misc/Makefile > > > @@ -59,3 +59,4 @@ obj-$(CONFIG_OCXL) += ocxl/ > > > obj-y+= cardreader/ > > > obj-$(CONFIG_PVPANIC)+= pvpanic.o > > > obj-$(CONFIG_HABANA_AI) += habanalabs/ > > > +obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o > > > diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c > > > new file mode 100644 > > > index 000..75cc980 > > > --- /dev/null > > > +++ b/drivers/misc/xilinx_sdfec.c > > > @@ -0,0 +1,118 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Xilinx SDFEC > > > + * > > > + * Copyright (C) 2019 Xilinx, Inc. > > > + * > > > + * Description: > > > + * This driver is developed for SDFEC16 (Soft Decision FEC 16nm) > > > + * IP. It exposes a char device which supports file operations > > > + * like open(), close() and ioctl(). > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +static int xsdfec_ndevs; > > > > You should use an idr for this, not just a number you bump up and down. > > This will not work properly at all. > > > > Think about this situation: > > probe device 0 > > xsdfec_ndevs = 1 > > probe device 1 > > xsdfec_ndevs = 2 > > remove device 0 > > xsdfec_ndevs = 0 > > probe another device > > misc device fails due to duplicate name. > > > > My bad. > I can use idr, but couldn't be better optimized code if use simple mutex to > protect the variable. mutex does not protect from this at all, it's a logic bug. Think about adding 5 devices and then removing the 2nd one. What is the number assigned to the new device that is added afterward? And you need a mutex for the idr anyway, if you are touching it in a non probe/release callback way (those are already serialized by the bus lock). thanks, greg k-h
Re: [PATCH V5 04/11] misc: xilinx_sdfec: Store driver config and state
On Sun, Jun 09, 2019 at 07:04:05PM +, Dragan Cvetic wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Sunday 9 June 2019 12:28 > > To: Dragan Cvetic > > Cc: a...@arndb.de; Michal Simek ; > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > linux-kernel@vger.kernel.org; Derek Kiernan > > Subject: Re: [PATCH V5 04/11] misc: xilinx_sdfec: Store driver config and > > state > > > > On Sun, Jun 09, 2019 at 01:04:09AM +0100, Dragan Cvetic wrote: > > > Stores configuration based on parameters from the DT > > > node and values from the SD-FEC core plus reads > > > the default state from the SD-FEC core. To obtain > > > values from the core register read, write capabilities > > > have been added plus related register map details. > > > > > > Tested-by: Dragan Cvetic > > > Signed-off-by: Derek Kiernan > > > Signed-off-by: Dragan Cvetic > > > --- > > > drivers/misc/xilinx_sdfec.c | 293 > > > +++ > > > include/uapi/misc/xilinx_sdfec.h | 138 ++ > > > 2 files changed, 431 insertions(+) > > > create mode 100644 include/uapi/misc/xilinx_sdfec.h > > > > > > diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c > > > index 4524677..ddfca54 100644 > > > --- a/drivers/misc/xilinx_sdfec.c > > > +++ b/drivers/misc/xilinx_sdfec.c > > > @@ -20,8 +20,89 @@ > > > #include > > > #include > > > > > > +#include > > > + > > > static int xsdfec_ndevs; > > > > > > +/* Xilinx SDFEC Register Map */ > > > +/* CODE_WRI_PROTECT Register */ > > > +#define XSDFEC_CODE_WR_PROTECT_ADDR (0x4) > > > + > > > +/* ACTIVE Register */ > > > +#define XSDFEC_ACTIVE_ADDR (0x8) > > > +#define XSDFEC_IS_ACTIVITY_SET (0x1) > > > + > > > +/* AXIS_WIDTH Register */ > > > +#define XSDFEC_AXIS_WIDTH_ADDR (0xC) > > > +#define XSDFEC_AXIS_DOUT_WORDS_LSB (5) > > > +#define XSDFEC_AXIS_DOUT_WIDTH_LSB (3) > > > +#define XSDFEC_AXIS_DIN_WORDS_LSB (2) > > > +#define XSDFEC_AXIS_DIN_WIDTH_LSB (0) > > > + > > > +/* AXIS_ENABLE Register */ > > > +#define XSDFEC_AXIS_ENABLE_ADDR (0x10) > > > +#define XSDFEC_AXIS_OUT_ENABLE_MASK (0x38) > > > +#define XSDFEC_AXIS_IN_ENABLE_MASK (0x7) > > > +#define XSDFEC_AXIS_ENABLE_MASK > > > \ > > > + (XSDFEC_AXIS_OUT_ENABLE_MASK | XSDFEC_AXIS_IN_ENABLE_MASK) > > > + > > > +/* FEC_CODE Register */ > > > +#define XSDFEC_FEC_CODE_ADDR (0x14) > > > + > > > +/* ORDER Register Map */ > > > +#define XSDFEC_ORDER_ADDR (0x18) > > > + > > > +/* Interrupt Status Register */ > > > +#define XSDFEC_ISR_ADDR (0x1C) > > > +/* Interrupt Status Register Bit Mask */ > > > +#define XSDFEC_ISR_MASK (0x3F) > > > + > > > +/* Write Only - Interrupt Enable Register */ > > > +#define XSDFEC_IER_ADDR (0x20) > > > +/* Write Only - Interrupt Disable Register */ > > > +#define XSDFEC_IDR_ADDR (0x24) > > > +/* Read Only - Interrupt Mask Register */ > > > +#define XSDFEC_IMR_ADDR (0x28) > > > + > > > +/* ECC Interrupt Status Register */ > > > +#define XSDFEC_ECC_ISR_ADDR (0x2C) > > > +/* Single Bit Errors */ > > > +#define XSDFEC_ECC_ISR_SBE_MASK (0x7FF) > > > +/* PL Initialize Single Bit Errors */ > > > +#define XSDFEC_PL_INIT_ECC_ISR_SBE_MASK (0x3C0) > > > +/* Multi Bit Errors */ > > > +#define XSDFEC_ECC_ISR_MBE_MASK (0x3FF800) > > > +/* PL Initialize Multi Bit Errors */ > > > +#define XSDFEC_PL_INIT_ECC_ISR_MBE_MASK (0x3C00) > > > +/* Multi Bit Error to Event Shift */ > > > +#define XSDFEC_ECC_ISR_MBE_TO_EVENT_SHIFT (11) > > > +/* PL Initialize Multi Bit Error to Event Shift */ > > > +#define XSDFEC_PL_INIT_ECC_ISR_MBE_TO_EVENT_SHIFT (4) > > > +/* ECC Interrupt Status Bit Mask */ > > > +#define XSDFEC_ECC_ISR_MASK (XSDFEC_ECC_ISR_SBE_MASK | > > > XSDFEC_ECC_ISR_MBE_MASK) > > > +/* ECC Interrupt Status PL Initialize Bit Mask */ > > > +#define XSDFEC_PL_INIT_ECC_ISR_MASK > > > \ > > > + (XSDFEC_PL_INIT_ECC_ISR_SBE_MASK | XSDFEC_PL_INIT_ECC_ISR_MBE_MASK) > > > +/* ECC Interrupt Status All Bit Mask */ > > > +#define XSDFEC_ALL_ECC_ISR_MASK > > > \ > > > + (XSDFEC_ECC_ISR_MASK | XSDFEC_PL_INIT_ECC_ISR_MASK) > > > +/* ECC Interrupt Status Single Bit Errors Mask */ > > > +#define XSDFEC_ALL_ECC_ISR_SBE_MASK > > > \ > > > + (XSDFEC_ECC_ISR_SBE_MASK | XSDFEC_PL_INIT_ECC_ISR_SBE_MASK) > > > +/* ECC Interrupt Status Multi Bit Errors Mask */ > > > +#define XSDFEC_ALL_ECC_ISR_MBE_MASK > > > \ > > > + (XSDFEC_ECC_ISR_MBE_MASK | XSDFEC_PL_INIT_ECC_ISR_MBE_MASK) > > > + > > > +/* Write Only - ECC Interrupt Enable Register */ > > > +#define XSDFEC_ECC_IER_ADDR (0x30) > > > +/* Write Only - ECC Interrupt Disable Register */ > > > +#define XSDFEC_ECC_IDR_ADDR (0x34) > > > +/* Read Only - ECC Interrupt Mask Register */ > > > +#define
[PATCH] regulator: wm831x: Convert to use GPIO descriptors
This converts the Wolfson Micro WM831x DCDC converter to use
a GPIO descriptor for the GPIO driving the DVS pin.
There is just one (non-DT) machine in the kernel using this, and
that is the Wolfson Micro (now Cirrus) Cragganmore 6410 so we
patch this board to pass a descriptor table and fix up the driver
accordingly.
Cc: Charles Keepax
Cc: Richard Fitzgerald
Cc: patc...@opensource.cirrus.com
Signed-off-by: Linus Walleij
---
arch/arm/mach-s3c64xx/mach-crag6410.c | 20 +-
drivers/regulator/wm831x-dcdc.c | 29 ---
include/linux/mfd/wm831x/pdata.h | 1 -
3 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 379424d72ae7..b90ded91916c 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -398,7 +399,6 @@ static struct pca953x_platform_data crag6410_pca_data = {
/* VDDARM is controlled by DVS1 connected to GPK(0) */
static struct wm831x_buckv_pdata vddarm_pdata = {
.dvs_control_src = 1,
- .dvs_gpio = S3C64XX_GPK(0),
};
static struct regulator_consumer_supply vddarm_consumers[] = {
@@ -596,6 +596,23 @@ static struct wm831x_pdata crag_pmic_pdata = {
.touch = _pdata,
};
+/*
+ * VDDARM is eventually ending up as a regulator hanging on the MFD cell device
+ * "wm831x-buckv.1" spawn from drivers/mfd/wm831x-core.c.
+ *
+ * From the note on the platform data we can see that this is clearly DVS1
+ * and assigned as dcdc1 resource to the MFD core which sets .id of the cell
+ * spawning the DVS1 platform device to 1, resulting in the device name
+ * "wm831x-buckv.1".
+ */
+static struct gpiod_lookup_table crag_pmic_gpiod_table = {
+ .dev_id = "wm831x-buckv.1",
+ .table = {
+ GPIO_LOOKUP("GPIOK", 0, "dvs", GPIO_ACTIVE_HIGH),
+ { },
+ },
+};
+
static struct i2c_board_info i2c_devs0[] = {
{ I2C_BOARD_INFO("24c08", 0x50), },
{ I2C_BOARD_INFO("tca6408", 0x20),
@@ -836,6 +853,7 @@ static void __init crag6410_machine_init(void)
s3c_fb_set_platdata(_lcd_pdata);
dwc2_hsotg_set_platdata(_hsotg_pdata);
+ gpiod_add_lookup_table(_pmic_gpiod_table);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index b422eef97b77..319a743e242a 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -15,7 +15,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -50,7 +50,7 @@ struct wm831x_dcdc {
int base;
struct wm831x *wm831x;
struct regulator_dev *regulator;
- int dvs_gpio;
+ struct gpio_desc *dvs_gpiod;
int dvs_gpio_state;
int on_vsel;
int dvs_vsel;
@@ -217,7 +217,7 @@ static int wm831x_buckv_set_dvs(struct regulator_dev *rdev,
int state)
return 0;
dcdc->dvs_gpio_state = state;
- gpio_set_value(dcdc->dvs_gpio, state);
+ gpiod_set_value(dcdc->dvs_gpiod, state);
/* Should wait for DVS state change to be asserted if we have
* a GPIO for it, for now assume the device is configured
@@ -237,10 +237,10 @@ static int wm831x_buckv_set_voltage_sel(struct
regulator_dev *rdev,
int ret;
/* If this value is already set then do a GPIO update if we can */
- if (dcdc->dvs_gpio && dcdc->on_vsel == vsel)
+ if (dcdc->dvs_gpiod && dcdc->on_vsel == vsel)
return wm831x_buckv_set_dvs(rdev, 0);
- if (dcdc->dvs_gpio && dcdc->dvs_vsel == vsel)
+ if (dcdc->dvs_gpiod && dcdc->dvs_vsel == vsel)
return wm831x_buckv_set_dvs(rdev, 1);
/* Always set the ON status to the minimum voltage */
@@ -249,7 +249,7 @@ static int wm831x_buckv_set_voltage_sel(struct
regulator_dev *rdev,
return ret;
dcdc->on_vsel = vsel;
- if (!dcdc->dvs_gpio)
+ if (!dcdc->dvs_gpiod)
return ret;
/* Kick the voltage transition now */
@@ -296,7 +296,7 @@ static int wm831x_buckv_get_voltage_sel(struct
regulator_dev *rdev)
{
struct wm831x_dcdc *dcdc = rdev_get_drvdata(rdev);
- if (dcdc->dvs_gpio && dcdc->dvs_gpio_state)
+ if (dcdc->dvs_gpiod && dcdc->dvs_gpio_state)
return dcdc->dvs_vsel;
else
return dcdc->on_vsel;
@@ -337,7 +337,7 @@ static void wm831x_buckv_dvs_init(struct platform_device
*pdev,
int ret;
u16 ctrl;
- if (!pdata || !pdata->dvs_gpio)
+ if (!pdata)
return;
/* gpiolib won't let us read the GPIO status so pick the higher
@@ -345,17 +345,14 @@ static void wm831x_buckv_dvs_init(struct
Re: [PATCH 0/7] TTY Keyboard Status Request
On Sun, Jun 09, 2019 at 09:51:32PM +0200, Pavel Machek wrote: > Hi! > > > > > This patch series introduces TTY keyboard status request, a feature of > > > > the n_tty line discipline that reserves a character in struct termios > > > > (^T by default) and reacts to it by printing a short informational line > > > > to the terminal and sending a Unix signal to the tty's foreground > > > > process group. The processes may, in response to the signal, output a > > > > textual description of what they're doing. > > > > > > > > The feature has been present in a similar form at least in > > > > Free/Open/NetBSD; it would be nice to have something like this in Linux > > > > as well. There is an LKML thread[1] where users have previously > > > > expressed the rationale for this. > > > > > > > > The current implementation does not break existing kernel API in any > > > > way, since, fortunately, all the architectures supported by the kernel > > > > happen to have at least 1 free byte in the termios control character > > > > array. > > > > > > I like the idea... I was often wondering "how long will this dd take". > > > (And in > > > case of dd, SIGUSR1 does the job). > > > > > > I assume this will off by default, so that applications using ^T today > > > will not > > > get surprise signals? > > > > If any of isig, icanon and iexten is disabled on the tty, the signal is > > not sent. > > As expected. > > > Any application that wants to handle raw terminal input events itself, > > e.g. vim, mutt, libreadline, anything ncurses-based, etc., has to turn > > off the tty's cooked mode, i.e. at least icanon. This means those > > applications are unaffected. > > Agreed, those are unaffected. > > But if I have an application doing read() from console (without > manipulating tty), am I going to get surprise signal when user types > ^T? > >Pavel As of now, that application will indeed receive a signal that is guaranteed to be ignored by default. This is similar to SIGWINCH, which is default-ignored as well: if the terminal width/height changes (like when a terminal emulator window is resized), its foreground pgrp gets a surprise signal as well, and the processes that don't care about WINCH (and thus have default disposition) do not get confused. E.g. 'strace cat' demonstrates this quite clearly. signature.asc Description: PGP signature
Re: [RFC next v1 3/5] net: stmmac: use GPIO descriptors in stmmac_mdio_reset
> + struct gpio_desc *reset_gpio;
> +
> if (data->reset_gpio < 0) {
> struct device_node *np = priv->device->of_node;
>
> - data->reset_gpio = of_get_named_gpio(np,
> - "snps,reset-gpio", 0);
> - if (data->reset_gpio < 0)
> - return 0;
> + reset_gpio = devm_gpiod_get_optional(priv->device,
> + "snps,reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(reset_gpio))
> + return PTR_ERR(reset_gpio);
>
> - data->active_low = of_property_read_bool(np,
> - "snps,reset-active-low");
Hi Martin
I think you need to keep this here. You can then use it to decide how
to change gpio_desc to remove flags that should be ignored.
Andrew
Re: [PATCH v2 1/3] i2c-mux-gpio: Unpin a platform-based device initialization
Thanks for your patches, and sorry for the slow review...
On 2019-04-26 01:20, Serge Semin wrote:
> We can unpin a code specific for i2c-mux-gpio device declared
Unpin? I think the common phrase is "factor out"? That unpin is also
present in the subject. BTW, I prefer the subject to start with
[PATCH ...] i2c: mux: gpio: factor out...
> as platform device. In this case the platform data just needs to be
> copied to the private storage and if GPIO chip pointer is referring to
> a valid GPIO chip descriptor save it' base number for further GPIOs
> request and initialization. The rest of the code is common for both
> platform and OF-based setups.
>
> It's also pointless and might be even errors prone to proceed with
> further initialization if OF kernel config is disabled and plat-based
> initialization isn't defined. Just return an error in this case.
Hmm, there are a couple of other language issues, how about:
Subject: i2c: mux: gpio: factor out platform-based device init
We can factor out the probe code specific for i2c-mux-gpio when used as
a platform device. In this case the platform data just needs to be
copied to the private storage except if the GPIO chip pointer is
referring to a valid GPIO chip descriptor, in which case we save its
base number for further GPIO requests and init. The rest of the code
is common for both platform and OF-based setups.
It's also pointless and might even be error prone to proceed with
further initialization if neither OF nor platform-based parameters
are given. Just error out in this case.
> Signed-off-by: Serge Semin
>
> ---
> Changelog v2
> - Return an error if OF kconfig is disabled while dt-based GPIOs probe
> is called.
> ---
> drivers/i2c/muxes/i2c-mux-gpio.c | 69 ++--
> 1 file changed, 38 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c
> b/drivers/i2c/muxes/i2c-mux-gpio.c
> index 13882a2a4f60..54158b825acd 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> @@ -132,48 +132,55 @@ static int i2c_mux_gpio_probe_dt(struct gpiomux *mux,
> static int i2c_mux_gpio_probe_dt(struct gpiomux *mux,
> struct platform_device *pdev)
> {
> - return 0;
> + return -EINVAL;
This is unrelated and should be a separate patch, as is almost always the
case when there is an "also" like you have in the commit message.
> }
> #endif
>
> +static int i2c_mux_gpio_probe_plat(struct gpiomux *mux,
> + struct platform_device *pdev)
I think you should spell out platform, and please align the arguments
vertically.
> +{
> + struct i2c_mux_gpio_platform_data *data = dev_get_platdata(>dev);
> + struct gpio_chip *gpio;
> +
> + /*
> + * If a GPIO chip name is provided, the GPIO pin numbers provided are
> + * relative to its base GPIO number. Otherwise they are absolute.
> + */
> + if (data->gpio_chip) {
> + gpio = gpiochip_find(data->gpio_chip,
> + match_gpio_chip_by_label);
> + if (!gpio)
> + return -EPROBE_DEFER;
> +
> + mux->gpio_base = gpio->base;
> + } else {
> + mux->gpio_base = 0;
This else-branch is pointless. I realize that you are just moving
code around, but mux->gpio_base is already zero here. Could be
simplified in a followup commit, I suppose.
Cheers,
Peter
> + }
> +
> + memcpy(>data, data, sizeof(mux->data));
> +
> + return 0;
> +}
> +
> static int i2c_mux_gpio_probe(struct platform_device *pdev)
> {
> struct i2c_mux_core *muxc;
> struct gpiomux *mux;
> struct i2c_adapter *parent;
> struct i2c_adapter *root;
> - unsigned initial_state, gpio_base;
> + unsigned initial_state;
> int i, ret;
>
> mux = devm_kzalloc(>dev, sizeof(*mux), GFP_KERNEL);
> if (!mux)
> return -ENOMEM;
>
> - if (!dev_get_platdata(>dev)) {
> + if (!dev_get_platdata(>dev))
> ret = i2c_mux_gpio_probe_dt(mux, pdev);
> - if (ret < 0)
> - return ret;
> - } else {
> - memcpy(>data, dev_get_platdata(>dev),
> - sizeof(mux->data));
> - }
> -
> - /*
> - * If a GPIO chip name is provided, the GPIO pin numbers provided are
> - * relative to its base GPIO number. Otherwise they are absolute.
> - */
> - if (mux->data.gpio_chip) {
> - struct gpio_chip *gpio;
> -
> - gpio = gpiochip_find(mux->data.gpio_chip,
> - match_gpio_chip_by_label);
> - if (!gpio)
> - return -EPROBE_DEFER;
> -
> - gpio_base = gpio->base;
> - } else {
> - gpio_base = 0;
> - }
> + else
> + ret = i2c_mux_gpio_probe_plat(mux, pdev);
> + if (ret)
> + return ret;
>
> parent =
Re: [PATCH v3 30/33] docs: watchdog: convert docs to ReST and rename to *.rst
On Sat, Jun 08, 2019 at 11:27:20PM -0300, Mauro Carvalho Chehab wrote:
> Convert those documents and prepare them to be part of the kernel
> API book, as most of the stuff there are related to the
> Kernel interfaces.
>
> Still, in the future, it would make sense to split the docs,
> as some of the stuff is clearly focused on sysadmin tasks.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Cc: Mauro Carvalho Chehab ,
> linux-kernel@vger.kernel.org, Jonathan Corbet
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Guenter Roeck
> ---
> .../admin-guide/kernel-parameters.txt | 2 +-
> Documentation/kernel-per-CPU-kthreads.txt | 2 +-
> txt => convert_drivers_to_kernel_api.rst} | 109 +--
> .../watchdog/{hpwdt.txt => hpwdt.rst} | 25 +-
> Documentation/watchdog/index.rst | 25 +
> .../watchdog/{mlx-wdt.txt => mlx-wdt.rst} | 24 +-
> .../{pcwd-watchdog.txt => pcwd-watchdog.rst} | 13 +-
> .../{watchdog-api.txt => watchdog-api.rst}| 76 +-
> ...kernel-api.txt => watchdog-kernel-api.rst} | 91 ++-
> ...parameters.txt => watchdog-parameters.rst} | 672 +-
> .../{watchdog-pm.txt => watchdog-pm.rst} | 3 +
> Documentation/watchdog/{wdt.txt => wdt.rst} | 31 +-
> MAINTAINERS | 2 +-
> drivers/watchdog/Kconfig | 6 +-
> drivers/watchdog/smsc37b787_wdt.c | 2 +-
> 15 files changed, 767 insertions(+), 316 deletions(-)
> rename Documentation/watchdog/{convert_drivers_to_kernel_api.txt =>
> convert_drivers_to_kernel_api.rst} (75%)
> rename Documentation/watchdog/{hpwdt.txt => hpwdt.rst} (79%)
> create mode 100644 Documentation/watchdog/index.rst
> rename Documentation/watchdog/{mlx-wdt.txt => mlx-wdt.rst} (78%)
> rename Documentation/watchdog/{pcwd-watchdog.txt => pcwd-watchdog.rst} (89%)
> rename Documentation/watchdog/{watchdog-api.txt => watchdog-api.rst} (80%)
> rename Documentation/watchdog/{watchdog-kernel-api.txt =>
> watchdog-kernel-api.rst} (90%)
> rename Documentation/watchdog/{watchdog-parameters.txt =>
> watchdog-parameters.rst} (42%)
> rename Documentation/watchdog/{watchdog-pm.txt => watchdog-pm.rst} (92%)
> rename Documentation/watchdog/{wdt.txt => wdt.rst} (68%)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 0092a453f7dc..3d072ca532bb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5182,7 +5182,7 @@
> Default: 3 = cyan.
>
> watchdog timers [HW,WDT] For information on watchdog timers,
> - see Documentation/watchdog/watchdog-parameters.txt
> + see Documentation/watchdog/watchdog-parameters.rst
> or other driver-specific files in the
> Documentation/watchdog/ directory.
>
> diff --git a/Documentation/kernel-per-CPU-kthreads.txt
> b/Documentation/kernel-per-CPU-kthreads.txt
> index 23b0c8b20cd1..5623b9916411 100644
> --- a/Documentation/kernel-per-CPU-kthreads.txt
> +++ b/Documentation/kernel-per-CPU-kthreads.txt
> @@ -348,7 +348,7 @@ To reduce its OS jitter, do at least one of the following:
> 2. Boot with "nosoftlockup=0", which will also prevent these kthreads
> from being created. Other related watchdog and softlockup boot
> parameters may be found in
> Documentation/admin-guide/kernel-parameters.rst
> - and Documentation/watchdog/watchdog-parameters.txt.
> + and Documentation/watchdog/watchdog-parameters.rst.
> 3. Echo a zero to /proc/sys/kernel/watchdog to disable the
> watchdog timer.
> 4. Echo a large number of /proc/sys/kernel/watchdog_thresh in
> diff --git a/Documentation/watchdog/convert_drivers_to_kernel_api.txt
> b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
> similarity index 75%
> rename from Documentation/watchdog/convert_drivers_to_kernel_api.txt
> rename to Documentation/watchdog/convert_drivers_to_kernel_api.rst
> index 9fffb2958d13..dd934cc08e40 100644
> --- a/Documentation/watchdog/convert_drivers_to_kernel_api.txt
> +++ b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
> @@ -1,6 +1,8 @@
> +=
> Converting old watchdog drivers to the watchdog framework
> +=
> +
> by Wolfram Sang
> -=
>
> Before the watchdog framework came into the kernel, every driver had to
> implement the API on its own. Now, as the framework
