RE: [PATCH 0/6] net: macb patch set cover letter
Hi All, Please ignore patches sent in-reply chain to patch 0001. Sending all patches in reply to patch -cover-letter.patch. Regards, Parshuram Thombare >-Original Message- >From: Parshuram Thombare >Sent: Sunday, June 16, 2019 5:15 AM >To: and...@lunn.ch; nicolas.fe...@microchip.com; da...@davemloft.net; >f.faine...@gmail.com >Cc: net...@vger.kernel.org; hkallwe...@gmail.com; linux- >ker...@vger.kernel.org; Rafal Ciepiela ; Anil Joy >Varughese ; Piotr Sroka ; >Parshuram Raju Thombare >Subject: [PATCH 0/6] net: macb patch set cover letter > >Hello !, > >This is second version of patch set containing following patches for Cadence >ethernet controller driver. > >1. 0001-net-macb-add-phylink-support.patch > Replace phylib API's with phylink API's. >2. 0002-net-macb-add-support-for-sgmii-MAC-PHY-interface.patch > This patch add support for SGMII mode. >3. 003-net-macb-add-PHY-configuration-in-MACB-PCI-wrapper.patch > This patch is to configure TI PHY DP83867 in SGMII mode from > our MAC PCI wrapper driver. > With this change there is no need of PHY driver and dp83867 > module must be disabled. Users wanting to setup DP83867 PHY > in SGMII mode can disable dp83867.ko driver, else dp83867.ko > overwrite this configuration and PHY is setup as per dp83867.ko. >4. 0004-net-macb-add-support-for-c45-PHY.patch > This patch is to support C45 PHY. >5. 0005-net-macb-add-support-for-high-speed-interface > This patch add support for 10G USXGMII PCS in fixed mode. > Since emulated PHY used in fixed mode doesn't seems to > support anything above 1G, additional parameter is used outside > "fixed-link" node for selecting speed and "fixed-link" > node speed is still set at 1G. >6. 0006-net-macb-parameter-added-to-cadence-ethernet-controller-DT-binding > New parameters added to Cadence ethernet controller DT binding > for USXGMII interface. > >Regards, >Parshuram Thombare > >Parshuram Thombare (6): > net: macb: add phylink support > net: macb: add support for sgmii MAC-PHY interface > net: macb: add PHY configuration in MACB PCI wrapper > net: macb: add support for c45 PHY > net: macb: add support for high speed interface > net: macb: parameter added to cadence ethernet controller DT binding > > .../devicetree/bindings/net/macb.txt | 4 + > drivers/net/ethernet/cadence/Kconfig | 2 +- > drivers/net/ethernet/cadence/macb.h | 136 +++- > drivers/net/ethernet/cadence/macb_main.c | 659 ++ > drivers/net/ethernet/cadence/macb_pci.c | 225 ++ > 5 files changed, 860 insertions(+), 166 deletions(-) > >-- >2.17.1
Re: [PATCH] tomoyo: Don't check open/getattr permission on sockets.
Hello, Al.
Q1: Do you agree that we should fix TOMOYO side rather than SOCKET_I()->sk
management.
Q2: Do you see any problem with using f->f_path.dentry->d_inode ?
Do we need to use d_backing_inode() or d_inode() ?
Regards.
On 2019/06/09 15:41, Tetsuo Handa wrote:
> syzbot is reporting that use of SOCKET_I()->sk from open() can result in
> use after free problem [1], for socket's inode is still reachable via
> /proc/pid/fd/n despite destruction of SOCKET_I()->sk already completed.
>
> But there is no point with calling security_file_open() on sockets
> because open("/proc/pid/fd/n", !O_PATH) on sockets fails with -ENXIO.
>
> There is some point with calling security_inode_getattr() on sockets
> because stat("/proc/pid/fd/n") and fstat(open("/proc/pid/fd/n", O_PATH))
> are valid. If we want to access "struct sock"->sk_{family,type,protocol}
> fields, we will need to use security_socket_post_create() hook and
> security_inode_free() hook in order to remember these fields because
> security_sk_free() hook is called before the inode is destructed. But
> since information which can be protected by checking
> security_inode_getattr() on sockets is trivial, let's not be bothered by
> "struct inode"->i_security management.
>
> There is point with calling security_file_ioctl() on sockets. Since
> ioctl(open("/proc/pid/fd/n", O_PATH)) is invalid, security_file_ioctl()
> on sockets should remain safe.
>
> [1]
> https://syzkaller.appspot.com/bug?id=73d590010454403d55164cca23bd0565b1eb3b74
>
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> ---
> security/tomoyo/tomoyo.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
> index 716c92e..9661b86 100644
> --- a/security/tomoyo/tomoyo.c
> +++ b/security/tomoyo/tomoyo.c
> @@ -126,6 +126,9 @@ static int tomoyo_bprm_check_security(struct linux_binprm
> *bprm)
> */
> static int tomoyo_inode_getattr(const struct path *path)
> {
> + /* It is not safe to call tomoyo_get_socket_name(). */
> + if (path->dentry->d_inode && S_ISSOCK(path->dentry->d_inode->i_mode))
> + return 0;
> return tomoyo_path_perm(TOMOYO_TYPE_GETATTR, path, NULL);
> }
>
> @@ -316,6 +319,10 @@ static int tomoyo_file_open(struct file *f)
> /* Don't check read permission here if called from do_execve(). */
> if (current->in_execve)
> return 0;
> + /* Sockets can't be opened by open(). */
> + if (f->f_path.dentry->d_inode &&
> + S_ISSOCK(f->f_path.dentry->d_inode->i_mode))
> + return 0;
> return tomoyo_check_open_permission(tomoyo_domain(), &f->f_path,
> f->f_flags);
> }
>
Re: [PATCH v3 1/2] staging: erofs: add requirements field in superblock
Hi Sasha, On 2019/6/16 6:16, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: ba2b77a82022 staging: erofs: add super block operations. > > The bot has tested the following trees: v5.1.9, v4.19.50. > > v5.1.9: Failed to apply! Possible dependencies: > Unable to calculate > > v4.19.50: Failed to apply! Possible dependencies: > Unable to calculate > > > How should we proceed with this patch? I will manually make patches for v5.1.9 and v4.19.50 after it gets merged. Thanks, Gao Xiang > > -- > Thanks, > Sasha >
Re: [PATCH] memcg: Ignore unprotected parent in mem_cgroup_protected()
Hi Chirs,
On 2019/6/16 AM 12:08, Chris Down wrote:
> Hi Xunlei,
>
> Xunlei Pang writes:
>> Currently memory.min|low implementation requires the whole
>> hierarchy has the settings, otherwise the protection will
>> be broken.
>>
>> Our hierarchy is kind of like(memory.min value in brackets),
>>
>> root
>> |
>> docker(0)
>> / \
>> c1(max) c2(0)
>>
>> Note that "docker" doesn't set memory.min. When kswapd runs,
>> mem_cgroup_protected() returns "0" emin for "c1" due to "0"
>> @parent_emin of "docker", as a result "c1" gets reclaimed.
>>
>> But it's hard to maintain parent's "memory.min" when there're
>> uncertain protected children because only some important types
>> of containers need the protection. Further, control tasks
>> belonging to parent constantly reproduce trivial memory which
>> should not be protected at all. It makes sense to ignore
>> unprotected parent in this scenario to achieve the flexibility.
>
> I'm really confused by this, why don't you just set memory.{min,low} in
> the docker cgroup and only propagate it to the children that want it?
>
> If you only want some children to have the protection, only request it
> in those children, or create an additional intermediate layer of the
> cgroup hierarchy with protections further limited if you don't trust the
> task to request the right amount.
>
> Breaking the requirement for hierarchical propagation of protections
> seems like a really questionable API change, not least because it makes
> it harder to set systemwide policies about the constraints of
> protections within a subtree.
docker and various types(different memory capacity) of containers
are managed by k8s, it's a burden for k8s to maintain those dynamic
figures, simply set "max" to key containers is always welcome.
Set "max" to docker also protects docker cgroup memory(as docker
itself has tasks) unnecessarily.
This patch doesn't take effect on any intermediate layer with
positive memory.min set, it requires all the ancestors having
0 memory.min to work.
Nothing special change, but more flexible to business deployment...
Re: [PATCH v9 04/12] mm/sparsemem: Convert kmalloc_section_memmap() to populate_section_memmap()
Dan Williams writes:
> Allow sub-section sized ranges to be added to the memmap.
> populate_section_memmap() takes an explict pfn range rather than
> assuming a full section, and those parameters are plumbed all the way
> through to vmmemap_populate(). There should be no sub-section usage in
> current deployments. New warnings are added to clarify which memmap
> allocation paths are sub-section capable.
>
> Cc: Michal Hocko
> Cc: David Hildenbrand
> Cc: Logan Gunthorpe
> Cc: Oscar Salvador
> Reviewed-by: Pavel Tatashin
> Signed-off-by: Dan Williams
> ---
> arch/x86/mm/init_64.c |4 ++-
> include/linux/mm.h|4 ++-
> mm/sparse-vmemmap.c | 21 +++--
> mm/sparse.c | 61
> +++--
> 4 files changed, 57 insertions(+), 33 deletions(-)
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 8335ac6e1112..688fb0687e55 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1520,7 +1520,9 @@ int __meminit vmemmap_populate(unsigned long start,
> unsigned long end, int node,
> {
> int err;
>
> - if (boot_cpu_has(X86_FEATURE_PSE))
> + if (end - start < PAGES_PER_SECTION * sizeof(struct page))
> + err = vmemmap_populate_basepages(start, end, node);
> + else if (boot_cpu_has(X86_FEATURE_PSE))
> err = vmemmap_populate_hugepages(start, end, node, altmap);
> else if (altmap) {
> pr_err_once("%s: no cpu support for altmap allocations\n",
Can we move this to another patch? I am wondering what the x86 behaviour
here is? If the range is less that PAGES_PER_SECTION we don't allow to
use pmem as the map device? We sliently use memory range?
-aneesh
[PATCH] staging: rtl8723bs: os_dep: ioctl_linux: Make use rtw_zmalloc
rtw_malloc with memset can be replace with rtw_zmalloc.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index fc3885d..c59e366 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -478,14 +478,12 @@ static int wpa_set_encryption(struct net_device *dev,
struct ieee_param *param,
if (wep_key_len > 0) {
wep_key_len = wep_key_len <= 5 ? 5 : 13;
wep_total_len = wep_key_len + FIELD_OFFSET(struct
ndis_802_11_wep, KeyMaterial);
- pwep = rtw_malloc(wep_total_len);
+ pwep = rtw_zmalloc(wep_total_len);
if (pwep == NULL) {
RT_TRACE(_module_rtl871x_ioctl_os_c, _drv_err_,
(" wpa_set_encryption: pwep allocate fail !!!\n"));
goto exit;
}
- memset(pwep, 0, wep_total_len);
-
pwep->KeyLength = wep_key_len;
pwep->Length = wep_total_len;
@@ -2144,12 +2142,10 @@ static int rtw_wx_set_enc_ext(struct net_device *dev,
int ret = 0;
param_len = sizeof(struct ieee_param) + pext->key_len;
- param = rtw_malloc(param_len);
+ param = rtw_zmalloc(param_len);
if (param == NULL)
return -1;
- memset(param, 0, param_len);
-
param->cmd = IEEE_CMD_SET_ENCRYPTION;
memset(param->sta_addr, 0xff, ETH_ALEN);
@@ -3521,14 +3517,12 @@ static int rtw_set_encryption(struct net_device *dev,
struct ieee_param *param,
if (wep_key_len > 0) {
wep_key_len = wep_key_len <= 5 ? 5 : 13;
wep_total_len = wep_key_len + FIELD_OFFSET(struct
ndis_802_11_wep, KeyMaterial);
- pwep = rtw_malloc(wep_total_len);
+ pwep = rtw_zmalloc(wep_total_len);
if (pwep == NULL) {
DBG_871X(" r871x_set_encryption: pwep allocate
fail !!!\n");
goto exit;
}
- memset(pwep, 0, wep_total_len);
-
pwep->KeyLength = wep_key_len;
pwep->Length = wep_total_len;
--
2.7.4
[PATCH] staging: rtl8723bs: os_dep: Make use rtw_zmalloc
rtw_malloc with memset can be replaced with rtw_zmalloc.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 9bc6856..aa7cc50 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1078,12 +1078,10 @@ static int cfg80211_rtw_add_key(struct wiphy *wiphy,
struct net_device *ndev,
DBG_871X("pairwise =%d\n", pairwise);
param_len = sizeof(struct ieee_param) + params->key_len;
- param = rtw_malloc(param_len);
+ param = rtw_zmalloc(param_len);
if (param == NULL)
return -1;
- memset(param, 0, param_len);
-
param->cmd = IEEE_CMD_SET_ENCRYPTION;
memset(param->sta_addr, 0xff, ETH_ALEN);
--
2.7.4
Re: [PATCH] psi: Don't account force reclaim as memory pressure
Hi Chris, On 2019/6/15 PM 11:58, Chris Down wrote: > Hi Xunlei, > > Xunlei Pang writes: >> There're several cases like resize and force_empty that don't >> need to account to psi, otherwise is misleading. > > I'm afraid I'm quite confused by this patch. Why do you think accounting > for force reclaim in PSI is misleading? I completely expect that force > reclaim should still be accounted for as memory pressure, can you > present some reason why it shouldn't be? We expect psi stands for negative factors to applications which affect their response time, but force reclaims are behaviours triggered on purpose like "/proc/sys/vm/drop_caches", not the real negative pressure. e.g. my module force reclaims the dead memcgs, there's no application attached to it, and its memory(page caches) is usually useless, force reclaiming them doesn't mean the system or parent memcg is under memory pressure, while actually the whole system or the parent memcg has plenty of free memory. If the force reclaim causes further memory pressure like hot page cache miss, then the workingset refault psi will catch that.
Re: [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page()
Dan Williams writes:
> On Fri, Jun 14, 2019 at 9:18 AM Aneesh Kumar K.V
> wrote:
>>
>> On 6/14/19 9:05 PM, Oscar Salvador wrote:
>> > On Fri, Jun 14, 2019 at 02:28:40PM +0530, Aneesh Kumar K.V wrote:
>> >> Can you check with this change on ppc64. I haven't reviewed this series
>> >> yet.
>> >> I did limited testing with change . Before merging this I need to go
>> >> through the full series again. The vmemmap poplulate on ppc64 needs to
>> >> handle two translation mode (hash and radix). With respect to vmemap
>> >> hash doesn't setup a translation in the linux page table. Hence we need
>> >> to make sure we don't try to setup a mapping for a range which is
>> >> arleady convered by an existing mapping.
>> >>
>> >> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
>> >> index a4e17a979e45..15c342f0a543 100644
>> >> --- a/arch/powerpc/mm/init_64.c
>> >> +++ b/arch/powerpc/mm/init_64.c
>> >> @@ -88,16 +88,23 @@ static unsigned long __meminit
>> >> vmemmap_section_start(unsigned long page)
>> >>* which overlaps this vmemmap page is initialised then this page is
>> >>* initialised already.
>> >>*/
>> >> -static int __meminit vmemmap_populated(unsigned long start, int
>> >> page_size)
>> >> +static bool __meminit vmemmap_populated(unsigned long start, int
>> >> page_size)
>> >> {
>> >> unsigned long end = start + page_size;
>> >> start = (unsigned long)(pfn_to_page(vmemmap_section_start(start)));
>> >>
>> >> -for (; start < end; start += (PAGES_PER_SECTION * sizeof(struct
>> >> page)))
>> >> -if (pfn_valid(page_to_pfn((struct page *)start)))
>> >> -return 1;
>> >> +for (; start < end; start += (PAGES_PER_SECTION * sizeof(struct
>> >> page))) {
>> >>
>> >> -return 0;
>> >> +struct mem_section *ms;
>> >> +unsigned long pfn = page_to_pfn((struct page *)start);
>> >> +
>> >> +if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>> >> +return 0;
>> >
>> > I might be missing something, but is this right?
>> > Having a section_nr above NR_MEM_SECTIONS is invalid, but if we return 0
>> > here,
>> > vmemmap_populate will go on and populate it.
>>
>> I should drop that completely. We should not hit that condition at all.
>> I will send a final patch once I go through the full patch series making
>> sure we are not breaking any ppc64 details.
>>
>> Wondering why we did the below
>>
>> #if defined(ARCH_SUBSECTION_SHIFT)
>> #define SUBSECTION_SHIFT (ARCH_SUBSECTION_SHIFT)
>> #elif defined(PMD_SHIFT)
>> #define SUBSECTION_SHIFT (PMD_SHIFT)
>> #else
>> /*
>> * Memory hotplug enabled platforms avoid this default because they
>> * either define ARCH_SUBSECTION_SHIFT, or PMD_SHIFT is a constant, but
>> * this is kept as a backstop to allow compilation on
>> * !ARCH_ENABLE_MEMORY_HOTPLUG archs.
>> */
>> #define SUBSECTION_SHIFT 21
>> #endif
>>
>> why not
>>
>> #if defined(ARCH_SUBSECTION_SHIFT)
>> #define SUBSECTION_SHIFT (ARCH_SUBSECTION_SHIFT)
>> #else
>> #define SUBSECTION_SHIFT SECTION_SHIFT
>> #endif
>>
>> ie, if SUBSECTION is not supported by arch we have one sub-section per
>> section?
>
> A couple comments:
>
> The only reason ARCH_SUBSECTION_SHIFT exists is because PMD_SHIFT on
> PowerPC was a non-constant value. However, I'm planning to remove the
> distinction in the next rev of the patches. Jeff rightly points out
> that having a variable subsection size per arch will lead to
> situations where persistent memory namespaces are not portable across
> archs. So I plan to just make SUBSECTION_SHIFT 21 everywhere.
What is the dependency between subsection and pageblock_order? Shouldn't
subsection size >= pageblock size?
We do have pageblock size drived from HugeTLB size.
-aneesh
[PATCH] staging/rtl8723bs/core/rtw_ap: Remove redundant call to memset
rtw_zmalloc is internally doing memset . So there is no need to call memset again. Signed-off-by: Hariprasad Kelam --- drivers/staging/rtl8723bs/core/rtw_ap.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c index 87b201a..df055b8 100644 --- a/drivers/staging/rtl8723bs/core/rtw_ap.c +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c @@ -1502,8 +1502,6 @@ static int rtw_ap_set_key( goto exit; } - memset(psetkeyparm, 0, sizeof(struct setkey_parm)); - psetkeyparm->keyid = (u8)keyid; if (is_wep_enc(alg)) padapter->securitypriv.key_mask |= BIT(psetkeyparm->keyid); -- 2.7.4
[PATCH] staging/rtl8723bs/core: Remove redundant call to memset
rtw_zmalloc is doing memset . So there is no need to call memset again.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index d26d8cf..a8dab1a 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -2229,7 +2229,6 @@ sint rtw_set_auth(struct adapter *adapter, struct
security_priv *psecuritypriv)
goto exit;
}
- memset(psetauthparm, 0, sizeof(struct setauth_parm));
psetauthparm->mode = (unsigned char)psecuritypriv->dot11AuthAlgrthm;
pcmd->cmdcode = _SetAuth_CMD_;
@@ -2262,7 +2261,6 @@ sint rtw_set_key(struct adapter *adapter, struct
security_priv *psecuritypriv, s
res = _FAIL;
goto exit;
}
- memset(psetkeyparm, 0, sizeof(struct setkey_parm));
if (psecuritypriv->dot11AuthAlgrthm == dot11AuthAlgrthm_8021X) {
psetkeyparm->algorithm = (unsigned
char)psecuritypriv->dot118021XGrpPrivacy;
--
2.7.4
[PATCH] staging: rtl8723bs: hal: Add null check after memory allocation
Add NULL check post call to rtw_zmalloc.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/sdio_ops.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c
b/drivers/staging/rtl8723bs/hal/sdio_ops.c
index ac79de8..9177c18 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_ops.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_ops.c
@@ -816,6 +816,9 @@ void clearinterrupt8723bsdio(struct adapter *adapter)
haldata = GET_HAL_DATA(adapter);
clear = rtw_zmalloc(4);
+ if (!clear)
+ return;
+
/* Clear corresponding HISR Content if needed */
*(__le32 *)clear = cpu_to_le32(haldata->sdio_hisr &
MASK_SDIO_HISR_CLEAR);
if (*(__le32 *)clear) {
--
2.7.4
[Patch v2 1/2] staging: rtl8723bs: hal: Remove return type of initrecvbuf
change return of initrecvbuf from s32 to void. As this function always
returns SUCCESS .
Signed-off-by: Hariprasad Kelam
---
changes in v2: break the patch for specific change
---
drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
index b269de5..07bee19 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
@@ -10,14 +10,12 @@
#include
#include
-static s32 initrecvbuf(struct recv_buf *precvbuf, struct adapter *padapter)
+static void initrecvbuf(struct recv_buf *precvbuf, struct adapter *padapter)
{
INIT_LIST_HEAD(&precvbuf->list);
spin_lock_init(&precvbuf->recvbuf_lock);
precvbuf->adapter = padapter;
-
- return _SUCCESS;
}
static void update_recvframe_attrib(struct adapter *padapter,
@@ -435,9 +433,7 @@ s32 rtl8723bs_init_recv_priv(struct adapter *padapter)
/* init each recv buffer */
precvbuf = (struct recv_buf *)precvpriv->precv_buf;
for (i = 0; i < NR_RECVBUFF; i++) {
- res = initrecvbuf(precvbuf, padapter);
- if (res == _FAIL)
- break;
+ initrecvbuf(precvbuf, padapter);
if (!precvbuf->pskb) {
SIZE_PTR tmpaddr = 0;
--
2.7.4
[Patch v2 2/2] staging: rtl8723bs: hal: fix Using comparison to false is error prone
fix below issue reported by checkpatch
CHECK: Using comparison to false is error prone
Signed-off-by: Hariprasad Kelam
---
changes in v2: break the patch for specific change
---
drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
index 07bee19..e23b39a 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
@@ -175,7 +175,7 @@ static void rtl8723bs_c2h_packet_handler(struct adapter
*padapter,
res = rtw_c2h_packet_wk_cmd(padapter, tmp, length);
- if (res == false)
+ if (!res)
kfree(tmp);
/* DBG_871X("-%s res(%d)\n", __func__, res); */
--
2.7.4
Re: [PATCH v2 1/2] media: vimc: stream: add missing function documentation
On 6/15/19 7:09 PM, André Almeida wrote:
> Add comments at vimc_streamer_s_stream and vimc_streamer_thread, making
> the vimc-stream totally documented.
>
> Signed-off-by: André Almeida
> ---
> Commit extracted from [PATCH 0/4] media: vimc: Minor code cleanup
> and documentation
>
> Changes in v2: fix typos
>
> drivers/media/platform/vimc/vimc-streamer.c | 22 +
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/media/platform/vimc/vimc-streamer.c
> b/drivers/media/platform/vimc/vimc-streamer.c
> index 236ade38f1da..76435e87d609 100644
> --- a/drivers/media/platform/vimc/vimc-streamer.c
> +++ b/drivers/media/platform/vimc/vimc-streamer.c
> @@ -122,6 +122,14 @@ static int vimc_streamer_pipeline_init(struct
> vimc_stream *stream,
> return -EINVAL;
> }
>
> +/*
> + * vimc_streamer_thread - process frames through the pipeline
> + *
> + * @data:vimc_stream struct of the current streaming
of the current stream ??
> + *
> + * From the source to the sink, gets a frame from each subdevice and send to
> + * the next one of the pipeline in a fixed framerate.
> + */
> static int vimc_streamer_thread(void *data)
> {
> struct vimc_stream *stream = data;
> @@ -149,6 +157,20 @@ static int vimc_streamer_thread(void *data)
> return 0;
> }
>
> +/*
> + * vimc_streamer_s_stream - start/stop the streaming on the media pipeline
> + *
> + * @stream: the pointer to the stream structure of the current stream
> + * @ved: pointer to the vimc entity of the entity of the stream
> + * @enable: flag to determine if stream should start/stop
> + *
> + * When starting, check if there is no stream->kthread allocated. This should
> + * indicate that a streaming is already running. Then, it initializes
> + * the pipeline, creates and runs a kthread to consume buffers through the
> + * pipeline.
> + * When stopping, analogously check if there is a stream running, stops
> + * the thread and terminates the pipeline.
> + */
> int vimc_streamer_s_stream(struct vimc_stream *stream,
> struct vimc_ent_device *ved,
> int enable)
>
--
~Randy
[PATCH v2 1/2] media: vimc: stream: add missing function documentation
Add comments at vimc_streamer_s_stream and vimc_streamer_thread, making
the vimc-stream totally documented.
Signed-off-by: André Almeida
---
Commit extracted from [PATCH 0/4] media: vimc: Minor code cleanup
and documentation
Changes in v2: fix typos
drivers/media/platform/vimc/vimc-streamer.c | 22 +
1 file changed, 22 insertions(+)
diff --git a/drivers/media/platform/vimc/vimc-streamer.c
b/drivers/media/platform/vimc/vimc-streamer.c
index 236ade38f1da..76435e87d609 100644
--- a/drivers/media/platform/vimc/vimc-streamer.c
+++ b/drivers/media/platform/vimc/vimc-streamer.c
@@ -122,6 +122,14 @@ static int vimc_streamer_pipeline_init(struct vimc_stream
*stream,
return -EINVAL;
}
+/*
+ * vimc_streamer_thread - process frames through the pipeline
+ *
+ * @data: vimc_stream struct of the current streaming
+ *
+ * From the source to the sink, gets a frame from each subdevice and send to
+ * the next one of the pipeline in a fixed framerate.
+ */
static int vimc_streamer_thread(void *data)
{
struct vimc_stream *stream = data;
@@ -149,6 +157,20 @@ static int vimc_streamer_thread(void *data)
return 0;
}
+/*
+ * vimc_streamer_s_stream - start/stop the streaming on the media pipeline
+ *
+ * @stream:the pointer to the stream structure of the current stream
+ * @ved: pointer to the vimc entity of the entity of the stream
+ * @enable:flag to determine if stream should start/stop
+ *
+ * When starting, check if there is no stream->kthread allocated. This should
+ * indicate that a streaming is already running. Then, it initializes
+ * the pipeline, creates and runs a kthread to consume buffers through the
+ * pipeline.
+ * When stopping, analogously check if there is a stream running, stops
+ * the thread and terminates the pipeline.
+ */
int vimc_streamer_s_stream(struct vimc_stream *stream,
struct vimc_ent_device *ved,
int enable)
--
2.22.0
[PATCH v2 2/2] media: docs: create vimc documentation
Create vimc documentation file to explain it basics features, it's
topology, how to configure it and to document vimc's subdevices.
Signed-off-by: André Almeida
Suggested-by: Helen Koike
---
Commit extracted from [PATCH 0/4] media: vimc: Minor code cleanup
and documentation
Changes in v2:
- Fix typos
- Make clear what does means scale factor
Documentation/media/v4l-drivers/index.rst | 1 +
Documentation/media/v4l-drivers/vimc.dot | 22 +
Documentation/media/v4l-drivers/vimc.rst | 98 +++
3 files changed, 121 insertions(+)
create mode 100644 Documentation/media/v4l-drivers/vimc.dot
create mode 100644 Documentation/media/v4l-drivers/vimc.rst
diff --git a/Documentation/media/v4l-drivers/index.rst
b/Documentation/media/v4l-drivers/index.rst
index 33a055907258..c4c78a28654c 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -64,5 +64,6 @@ For more details see the file COPYING in the source
distribution of Linux.
si476x
soc-camera
uvcvideo
+ vimc
vivid
zr364xx
diff --git a/Documentation/media/v4l-drivers/vimc.dot
b/Documentation/media/v4l-drivers/vimc.dot
new file mode 100644
index ..57863a13fa39
--- /dev/null
+++ b/Documentation/media/v4l-drivers/vimc.dot
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0
+
+digraph board {
+ rankdir=TB
+ n0001 [label="{{} | Sensor A\n/dev/v4l-subdev0 | { 0}}",
shape=Mrecord, style=filled, fillcolor=green]
+ n0001:port0 -> n0005:port0 [style=bold]
+ n0001:port0 -> n000b [style=bold]
+ n0003 [label="{{} | Sensor B\n/dev/v4l-subdev1 | { 0}}",
shape=Mrecord, style=filled, fillcolor=green]
+ n0003:port0 -> n0008:port0 [style=bold]
+ n0003:port0 -> n000f [style=bold]
+ n0005 [label="{{ 0} | Debayer A\n/dev/v4l-subdev2 | {
1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0005:port1 -> n0017:port0
+ n0008 [label="{{ 0} | Debayer B\n/dev/v4l-subdev3 | {
1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0008:port1 -> n0017:port0 [style=dashed]
+ n000b [label="Raw Capture 0\n/dev/video0", shape=box, style=filled,
fillcolor=yellow]
+ n000f [label="Raw Capture 1\n/dev/video1", shape=box, style=filled,
fillcolor=yellow]
+ n0013 [label="RGB/YUV Input\n/dev/video2", shape=box, style=filled,
fillcolor=yellow]
+ n0013 -> n0017:port0 [style=dashed]
+ n0017 [label="{{ 0} | Scaler\n/dev/v4l-subdev4 | {
1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0017:port1 -> n001a [style=bold]
+ n001a [label="RGB/YUV Capture\n/dev/video3", shape=box,
style=filled, fillcolor=yellow]
+}
diff --git a/Documentation/media/v4l-drivers/vimc.rst
b/Documentation/media/v4l-drivers/vimc.rst
new file mode 100644
index ..e235f806e252
--- /dev/null
+++ b/Documentation/media/v4l-drivers/vimc.rst
@@ -0,0 +1,98 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+The Virtual Media Controller Driver (vimc)
+==
+
+The vimc driver emulates complex video hardware using the V4L2 API and the
Media
+API. It has a capture device and three subdevices: sensor, debayer and scaler.
+
+Topology
+
+
+The topology is hardcoded, although you could modify it in vimc-core and
+recompile the driver to achieve your own topology. This is the default
topology:
+
+.. _vimc_topology_graph:
+
+.. kernel-figure:: vimc.dot
+:alt: vimc.dot
+:align: center
+
+Media pipeline graph on vimc
+
+Configuring the topology
+
+
+Each subdevice will come with its default configuration (pixelformat, height,
+width, ...). One needs to configure the topology in order to match the
+configuration on each linked subdevice to stream frames through the pipeline.
+If the configuration doesn't match, the stream will fail. The ``v4l2-utils``
+is a bundle of user-space applications, that comes with ``media-ctl`` and
+``v4l2-ctl`` that can be used to configure the vimc configuration. This
sequence
+of commands fits for the default topology:
+
+.. code-block:: bash
+
+media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
+media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
+media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
+media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'
+v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v
width=1920,height=1440
+v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
+v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81
+
+Subdevices
+--
+
+Subdevices define the behavior of an entity in the topology. Depending on the
+subdevice, the entity can have multiple pads of type source or sink.
+
+vimc-sensor:
+ Generat
[PATCH 1/6] net: macb: add phylink support
This patch replace phylib API's by phylink API's.
Signed-off-by: Parshuram Thombare
---
drivers/net/ethernet/cadence/Kconfig | 2 +-
drivers/net/ethernet/cadence/macb.h | 3 +
drivers/net/ethernet/cadence/macb_main.c | 288 +--
3 files changed, 173 insertions(+), 120 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig
b/drivers/net/ethernet/cadence/Kconfig
index 1766697c9c5a..d71411a71587 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -22,7 +22,7 @@ if NET_VENDOR_CADENCE
config MACB
tristate "Cadence MACB/GEM support"
depends on HAS_DMA
- select PHYLIB
+ select PHYLINK
---help---
The Cadence MACB ethernet interface is found on many Atmel AT32 and
AT91 parts. This driver also supports the Cadence GEM (Gigabit
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 00ee5e8e0ff0..35ed13236c8b 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_ARCH_DMA_ADDR_T_64BIT) || defined(CONFIG_MACB_USE_HWSTAMP)
#define MACB_EXT_DESC
@@ -1227,6 +1228,8 @@ struct macb {
u32 rx_intr_mask;
struct macb_pm_data pm_data;
+ struct phylink *pl;
+ struct phylink_config pl_config;
};
#ifdef CONFIG_MACB_USE_HWSTAMP
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index f825e3960540..52d5e5efe2ad 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "macb.h"
#define MACB_RX_BUFFER_SIZE128
@@ -428,115 +429,146 @@ static void macb_set_tx_clk(struct clk *clk, int speed,
struct net_device *dev)
netdev_err(dev, "adjusting tx_clk failed.\n");
}
-static void macb_handle_link_change(struct net_device *dev)
+static void gem_phylink_validate(struct phylink_config *pl_config,
+unsigned long *supported,
+struct phylink_link_state *state)
{
- struct macb *bp = netdev_priv(dev);
- struct phy_device *phydev = dev->phydev;
+ struct net_device *netdev = to_net_dev(pl_config->dev);
+ struct macb *bp = netdev_priv(netdev);
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+ switch (state->interface) {
+ case PHY_INTERFACE_MODE_GMII:
+ case PHY_INTERFACE_MODE_RGMII:
+ if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+ if (!(bp->caps & MACB_CAPS_NO_GIGABIT_HALF)) {
+ phylink_set(mask, 1000baseT_Half);
+ phylink_set(mask, 1000baseT_Half);
+ }
+ }
+ /* fallthrough */
+ case PHY_INTERFACE_MODE_MII:
+ case PHY_INTERFACE_MODE_RMII:
+ phylink_set(mask, 10baseT_Half);
+ phylink_set(mask, 10baseT_Full);
+ phylink_set(mask, 100baseT_Half);
+ phylink_set(mask, 100baseT_Full);
+ break;
+ default:
+ break;
+ }
+
+ bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
+ bitmap_and(state->advertising, state->advertising, mask,
+ __ETHTOOL_LINK_MODE_MASK_NBITS);
+}
+
+static int gem_phylink_mac_link_state(struct phylink_config *pl_config,
+ struct phylink_link_state *state)
+{
+ struct net_device *netdev = to_net_dev(pl_config->dev);
+ struct macb *bp = netdev_priv(netdev);
+
+ state->speed = bp->speed;
+ state->duplex = bp->duplex;
+ state->link = bp->link;
+ return 1;
+}
+
+static void gem_mac_config(struct phylink_config *pl_config, unsigned int mode,
+ const struct phylink_link_state *state)
+{
+ struct net_device *netdev = to_net_dev(pl_config->dev);
+ struct macb *bp = netdev_priv(netdev);
unsigned long flags;
- int status_change = 0;
spin_lock_irqsave(&bp->lock, flags);
- if (phydev->link) {
- if ((bp->speed != phydev->speed) ||
- (bp->duplex != phydev->duplex)) {
- u32 reg;
-
- reg = macb_readl(bp, NCFGR);
- reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
- if (macb_is_gem(bp))
- reg &= ~GEM_BIT(GBE);
+ if (bp->speed != state->speed ||
+ bp->duplex != state->duplex) {
+ u32 reg;
- if (phydev->duplex)
- reg |= MACB_BIT(FD);
-
[PATCH 5/6] net: macb: add support for high speed interface
This patch add support for high speed USXGMII PCS and 10G
speed in Cadence ethernet controller driver.
Signed-off-by: Parshuram Thombare
---
drivers/net/ethernet/cadence/macb.h | 42 +
drivers/net/ethernet/cadence/macb_main.c | 219 +++
2 files changed, 228 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 75f093bc52fe..e00b9f647757 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -85,6 +85,7 @@
#define GEM_USRIO 0x000c /* User IO */
#define GEM_DMACFG 0x0010 /* DMA Configuration */
#define GEM_JML0x0048 /* Jumbo Max Length */
+#define GEM_HS_MAC_CONFIG 0x0050 /* GEM high speed config */
#define GEM_HRB0x0080 /* Hash Bottom */
#define GEM_HRT0x0084 /* Hash Top */
#define GEM_SA1B 0x0088 /* Specific1 Bottom */
@@ -172,6 +173,9 @@
#define GEM_DCFG7 0x0298 /* Design Config 7 */
#define GEM_DCFG8 0x029C /* Design Config 8 */
#define GEM_DCFG10 0x02A4 /* Design Config 10 */
+#define GEM_DCFG12 0x02AC /* Design Config 12 */
+#define GEM_USX_CONTROL0x0A80 /* USXGMII control register */
+#define GEM_USX_STATUS 0x0A88 /* USXGMII status register */
#define GEM_TXBDCTRL 0x04cc /* TX Buffer Descriptor control register */
#define GEM_RXBDCTRL 0x04d0 /* RX Buffer Descriptor control register */
@@ -279,6 +283,8 @@
#define MACB_IRXFCS_SIZE 1
/* GEM specific NCR bitfields. */
+#define GEM_ENABLE_HS_MAC_OFFSET 31
+#define GEM_ENABLE_HS_MAC_SIZE 1
#define GEM_TWO_PT_FIVE_GIG_OFFSET 29
#define GEM_TWO_PT_FIVE_GIG_SIZE 1
@@ -470,6 +476,10 @@
#define MACB_REV_OFFSET0
#define MACB_REV_SIZE 16
+/* Bitfield in HS_MAC_CONFIG */
+#define GEM_HS_MAC_SPEED_OFFSET0
+#define GEM_HS_MAC_SPEED_SIZE 3
+
/* Bitfields in PCS_CONTROL. */
#define GEM_PCS_CTRL_RST_OFFSET15
#define GEM_PCS_CTRL_RST_SIZE 1
@@ -535,6 +545,34 @@
#define GEM_RXBD_RDBUFF_OFFSET 8
#define GEM_RXBD_RDBUFF_SIZE 4
+/* Bitfields in DCFG12. */
+#define GEM_HIGH_SPEED_OFFSET 26
+#define GEM_HIGH_SPEED_SIZE1
+
+/* Bitfields in USX_CONTROL. */
+#define GEM_USX_CTRL_SPEED_OFFSET 14
+#define GEM_USX_CTRL_SPEED_SIZE3
+#define GEM_SERDES_RATE_OFFSET 12
+#define GEM_SERDES_RATE_SIZE 2
+#define GEM_RX_SCR_BYPASS_OFFSET 9
+#define GEM_RX_SCR_BYPASS_SIZE 1
+#define GEM_TX_SCR_BYPASS_OFFSET 8
+#define GEM_TX_SCR_BYPASS_SIZE 1
+#define GEM_RX_SYNC_RESET_OFFSET 2
+#define GEM_RX_SYNC_RESET_SIZE 1
+#define GEM_TX_EN_OFFSET 1
+#define GEM_TX_EN_SIZE 1
+#define GEM_SIGNAL_OK_OFFSET 0
+#define GEM_SIGNAL_OK_SIZE 1
+
+/* Bitfields in USX_STATUS. */
+#define GEM_USX_TX_FAULT_OFFSET28
+#define GEM_USX_TX_FAULT_SIZE 1
+#define GEM_USX_RX_FAULT_OFFSET27
+#define GEM_USX_RX_FAULT_SIZE 1
+#define GEM_USX_BLOCK_LOCK_OFFSET 0
+#define GEM_USX_BLOCK_LOCK_SIZE1
+
/* Bitfields in TISUBN */
#define GEM_SUBNSINCR_OFFSET 0
#define GEM_SUBNSINCR_SIZE 16
@@ -695,6 +733,7 @@
#define MACB_CAPS_MACB_IS_GEM BIT(31)
#define MACB_CAPS_PCS BIT(24)
#define MACB_CAPS_MACB_IS_GEM_GXL BIT(25)
+#define MACB_CAPS_HIGH_SPEED BIT(26)
#define MACB_GEM7010_IDNUM 0x009
#define MACB_GEM7014_IDNUM 0x107
@@ -774,6 +813,7 @@
})
#define MACB_READ_NSR(bp) macb_readl(bp, NSR)
+#define GEM_READ_USX_STATUS(bp)gem_readl(bp, USX_STATUS)
/* struct macb_dma_desc - Hardware DMA descriptor
* @addr: DMA address of data buffer
@@ -1287,6 +1327,8 @@ struct macb {
struct macb_pm_data pm_data;
struct phylink *pl;
struct phylink_config pl_config;
+ u32 serdes_rate;
+ u32 fixed_speed;
};
#ifdef CONFIG_MACB_USE_HWSTAMP
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index 57ffc4e9d2b9..4af0b434e818 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -77,6 +77,20 @@
#define MACB_WOL_HAS_MAGIC_PACKET (0x1 << 0)
#define MACB_WOL_ENABLED (0x1 << 1)
+enum {
+ HS_MAC_SPEED_100M,
+ HS_MAC_SPEED_1000M,
+ HS_MAC_SPEED_2500M,
Re: [PATCHv4 0/2] Document memory-to-memory video codec interfaces
Le samedi 15 juin 2019 à 10:08 +0200, Hans Verkuil a écrit : > On 6/14/19 3:09 AM, Nicolas Dufresne wrote: > > Le jeudi 13 juin 2019 à 08:48 +0200, Hans Verkuil a écrit : > > > On 6/3/19 1:28 PM, Hans Verkuil wrote: > > > > Since Tomasz was very busy with other things, I've taken over this > > > > patch series. This v4 includes his draft changes and additional changes > > > > from me. > > > > > > > > This series attempts to add the documentation of what was discussed > > > > during Media Workshops at LinuxCon Europe 2012 in Barcelona and then > > > > later Embedded Linux Conference Europe 2014 in Düsseldorf and then > > > > eventually written down by Pawel Osciak and tweaked a bit by Chrome OS > > > > video team (but mostly in a cosmetic way or making the document more > > > > precise), during the several years of Chrome OS using the APIs in > > > > production. > > > > > > > > Note that most, if not all, of the API is already implemented in > > > > existing mainline drivers, such as s5p-mfc or mtk-vcodec. Intention of > > > > this series is just to formalize what we already have. > > > > > > > > Thanks everyone for the huge amount of useful comments to previous > > > > versions of this series. Much of the credits should go to Pawel Osciak > > > > too, for writing most of the original text of the initial RFC. > > > > > > > > This v4 incorporates all known comments (let me know if I missed > > > > something!) and should be complete for the decoder. > > > > > > > > For the encoder there are two remaining TODOs for the API: > > > > > > > > 1) Setting the frame rate so bitrate control can make sense, since > > > >they need to know this information. > > > > > > > >Suggested solution: require support for ENUM_FRAMEINTERVALS for the > > > >coded pixelformats and S_PARM(OUTPUT). Open question: some drivers > > > >(mediatek, hva, coda) require S_PARM(OUTPUT), some (venus) allow both > > > >S_PARM(CAPTURE) and S_PARM(OUTPUT). I am inclined to allow both since > > > >this is not a CAPTURE vs OUTPUT thing, it is global to both queues. > > > > > > Alternative proposal: > > > > > > 1) Add support for fractions (struct v4l2_fract) as a control type: > > >V4L2_CTRL_TYPE_FRACT. > > > > > > 2) Add a new V4L2_CID_MPEG_FRAME_INTERVAL control. > > > > Is the MPEG namespace historical ? That might be confusing for users. > > Yes, it's historical. I have toyed with the idea of renaming all the > defines to something like V4L2_CID_CODEC_... (keeping the old defines, of > course), but I'm not sure it is worth it. > > > > Encoders shall support this control. > > > > > > 3) For backwards compatibility reasons encoder drivers still have to > > > support G/S_PARM, but this can now be implemented by standard helpers > > > that query this control. Drivers also have to implement > > > ENUM_FRAMEINTERVALS. > > > > That's won't be very friendly for UI generator like qv4l2. Support for > > v4l2_fract as control should include a way to describe the supported > > values of that control the usual way I think. > > Such a control will definitely have the usual min/max/step/default control > values. > > > Also, long term, it would be nice to have two sets of frame rates. The > > one that the HW can handle "real-time" and the one that can be used for > > bitrate calculation. So staying away from ENUM_FRAMEINTERVALS for > > bitrate configuration would be nicer. > > I'm not sure if that's feasible in practice, although the idea is nice. > The 'real-time' framerate will likely depend to a huge extent on the > frequency of various internal clocks and the content of the bitstream. > > I suspect it will be very hard if not impossible to report realistic > ENUM_FRAMEINTERVAL values for codecs. > > > > If the range of intervals is always the same regardless of the frame size, > > > then a helper can be used that queries the min/max/step of the control, > > > but > > > if it is dependent on the frame size, then it has to be implemented in the > > > driver itself. > > > > > > I'm sticking to frame intervals instead of frame rates for the simple > > > reason > > > that that's what V4L2 has used since the beginning. I think it is too > > > confusing > > > to change this to a frame rate. This is just my opinion, though. > > > > I suggested frame rate since this is what I saw implemented by HW > > registers (if you think it's worth it, I can try and make a list). > > Also, frame-interval steps are not compatible with frame-rate steps > > (something that was raised through a venus driver bug) last year. Even > > v4l2-ctl was displaying that in a very confusing way. Something as > > simple as 1 to 30 fps cannot be exposed through ENU_FRAMEINTERVALS. You > > are forced to expose the full fractional range of interval, from 1/30 > > to 1/1. For Venus it was not that much of a trouble, since its stores a > > framerate as Q16.. > > Since this is used for bitrate calculations, and not for determining the > exact fra
[PATCH 6/6] net: macb: parameter added to cadence ethernet controller DT binding
New parameters added to Cadence ethernet controller DT binding for USXGMII interface. Signed-off-by: Parshuram Thombare --- Documentation/devicetree/bindings/net/macb.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 9c5e94482b5f..cd79ec9dddfb 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -25,6 +25,10 @@ Required properties: Optional elements: 'rx_clk' applies to cdns,zynqmp-gem Optional elements: 'tsu_clk' - clocks: Phandles to input clocks. +- serdes-rate External serdes rate.Mandatory for USXGMII mode. + 0 - 5G + 1 - 10G +- fixed-speed Speed for fixed mode UXSGMII interface based link The MAC address will be determined using the optional properties defined in ethernet.txt. -- 2.17.1
[PATCH 4/6] net: macb: add support for c45 PHY
This patch modify MDIO read/write functions to support
communication with C45 PHY.
Signed-off-by: Parshuram Thombare
---
drivers/net/ethernet/cadence/macb.h | 15 --
drivers/net/ethernet/cadence/macb_main.c | 61 +++-
drivers/net/ethernet/cadence/macb_pci.c | 60 +++
3 files changed, 91 insertions(+), 45 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 85c7e4cb1057..75f093bc52fe 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -667,10 +667,17 @@
#define GEM_CLK_DIV96 5
/* Constants for MAN register */
-#define MACB_MAN_SOF 1
-#define MACB_MAN_WRITE 1
-#define MACB_MAN_READ 2
-#define MACB_MAN_CODE 2
+#define MACB_MAN_C22_SOF1
+#define MACB_MAN_C22_WRITE 1
+#define MACB_MAN_C22_READ 2
+#define MACB_MAN_C22_CODE 2
+
+#define MACB_MAN_C45_SOF0
+#define MACB_MAN_C45_ADDR 0
+#define MACB_MAN_C45_WRITE 1
+#define MACB_MAN_C45_POST_READ_INCR 2
+#define MACB_MAN_C45_READ 3
+#define MACB_MAN_C45_CODE 2
/* Capability mask bits */
#define MACB_CAPS_ISR_CLEAR_ON_WRITE BIT(0)
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index 5b3e7d9f4384..57ffc4e9d2b9 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -334,11 +334,30 @@ static int macb_mdio_read(struct mii_bus *bus, int
mii_id, int regnum)
if (status < 0)
goto mdio_read_exit;
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_READ)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)));
+ if (regnum & MII_ADDR_C45) {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_ADDR)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(DATA, regnum & 0x)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+
+ status = macb_mdio_wait_for_idle(bp);
+ if (status < 0)
+ goto mdio_read_exit;
+
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_READ)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+ } else {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C22_SOF)
+ | MACB_BF(RW, MACB_MAN_C22_READ)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, regnum)
+ | MACB_BF(CODE, MACB_MAN_C22_CODE)));
+ }
status = macb_mdio_wait_for_idle(bp);
if (status < 0)
@@ -367,12 +386,32 @@ static int macb_mdio_write(struct mii_bus *bus, int
mii_id, int regnum,
if (status < 0)
goto mdio_write_exit;
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_WRITE)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)
- | MACB_BF(DATA, value)));
+ if (regnum & MII_ADDR_C45) {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_ADDR)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(DATA, regnum & 0x)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)));
+
+ status = macb_mdio_wait_for_idle(bp);
+ if (status < 0)
+ goto mdio_write_exit;
+
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
+ | MACB_BF(RW, MACB_MAN_C45_WRITE)
+ | MACB_BF(PHYA, mii_id)
+ | MACB_BF(REGA, (regnum >> 16) & 0x1F)
+ | MACB_BF(CODE, MACB_MAN_C45_CODE)
+ | MACB_BF(DATA, value)));
+ } else {
+ macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C22_SOF)
+ | MACB_BF(RW, MACB_
[PATCH 3/6] net: macb: add PHY configuration in MACB PCI wrapper
This patch add TI PHY DP83867 configuration for SGMII link in
Cadence MACB PCI wrapper.
Signed-off-by: Parshuram Thombare
---
drivers/net/ethernet/cadence/macb_pci.c | 225
1 file changed, 225 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_pci.c
b/drivers/net/ethernet/cadence/macb_pci.c
index 248a8fc45069..1001e03191a1 100644
--- a/drivers/net/ethernet/cadence/macb_pci.c
+++ b/drivers/net/ethernet/cadence/macb_pci.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include "macb.h"
@@ -37,6 +38,224 @@
#define GEM_PCLK_RATE 5000
#define GEM_HCLK_RATE 5000
+#define TI_PHY_DP83867_ID 0x2000a231
+#define TI_PHY_DEVADDR 0x1f
+#define PHY_REGCR 0x0D
+#define PHY_ADDAR 0x0E
+
+#define MACB_MDIO_TIMEOUT 100 /* in usecs */
+
+#define MACB_REGCR_OP_OFFSET 14
+#define MACB_REGCR_OP_SIZE 2
+#define MACB_REGCR_DEVADDR_OFFSET 0
+#define MACB_REGCR_DEVADDR_SIZE5
+
+#define MACB_REGCR_OP_ADDR 0
+#define MACB_REGCR_OP_DATA 1
+
+static int macb_mdio_wait_for_idle(void __iomem *macb_base_addr)
+{
+ u32 val;
+
+ return readx_poll_timeout(readl, macb_base_addr + MACB_NSR, val,
+ val & MACB_BIT(IDLE), 1, MACB_MDIO_TIMEOUT);
+}
+
+static int macb_mdiobus_read(void __iomem *macb_base_addr,
+u32 phy_id,
+u32 regnum)
+{
+ u32 i;
+ int status;
+
+ if (regnum < 32) {
+ i = MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_READ) |
+ MACB_BF(PHYA, phy_id) |
+ MACB_BF(REGA, regnum) |
+ MACB_BF(CODE, MACB_MAN_CODE);
+
+ writel(i, macb_base_addr + MACB_MAN);
+ status = macb_mdio_wait_for_idle(macb_base_addr);
+ if (status < 0)
+ return status;
+ } else {
+ u16 reg;
+
+ reg = MACB_BF(REGCR_OP, MACB_REGCR_OP_ADDR) |
+ MACB_BF(REGCR_DEVADDR, TI_PHY_DEVADDR);
+ i = MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_WRITE) |
+ MACB_BF(PHYA, phy_id) |
+ MACB_BF(REGA, PHY_REGCR) |
+ MACB_BF(CODE, MACB_MAN_CODE) |
+ MACB_BF(DATA, reg);
+ writel(i, macb_base_addr + MACB_MAN);
+ status = macb_mdio_wait_for_idle(macb_base_addr);
+ if (status < 0)
+ return status;
+
+ i = MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_WRITE) |
+ MACB_BF(PHYA, phy_id) |
+ MACB_BF(REGA, PHY_ADDAR) |
+ MACB_BF(CODE, MACB_MAN_CODE) |
+ MACB_BF(DATA, regnum);
+ writel(i, macb_base_addr + MACB_MAN);
+ status = macb_mdio_wait_for_idle(macb_base_addr);
+ if (status < 0)
+ return status;
+
+ reg = MACB_BF(REGCR_OP, MACB_REGCR_OP_DATA) |
+ MACB_BF(REGCR_DEVADDR, TI_PHY_DEVADDR);
+ i = MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_WRITE) |
+ MACB_BF(PHYA, phy_id) |
+ MACB_BF(REGA, PHY_REGCR) |
+ MACB_BF(CODE, MACB_MAN_CODE) |
+ MACB_BF(DATA, reg);
+ writel(i, macb_base_addr + MACB_MAN);
+ status = macb_mdio_wait_for_idle(macb_base_addr);
+ if (status < 0)
+ return status;
+
+ i = MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_READ) |
+ MACB_BF(PHYA, phy_id) |
+ MACB_BF(REGA, PHY_ADDAR) |
+ MACB_BF(CODE, MACB_MAN_CODE);
+
+ writel(i, macb_base_addr + MACB_MAN);
+ status = macb_mdio_wait_for_idle(macb_base_addr);
+ if (status < 0)
+ return status;
+ }
+
+ return readl(macb_base_addr + MACB_MAN);
+}
+
+static int macb_mdiobus_write(void __iomem *macb_base_addr, u32 phy_id,
+ u32 regnum, u16 value)
+{
+ u32 i;
+ int status;
+
+ if (regnum < 32) {
+ i = MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_WRITE) |
+ MACB_BF(PHYA, phy_id) |
+ MACB_BF(REGA, regnum) |
+ MACB_BF(CODE, MACB_MAN_CODE) |
+ MACB_BF(DATA, value);
+
+ writel(i, macb_base_addr + MACB_MAN);
+ status = macb_mdio_wait_for_idle(macb_base_addr);
+ if (status < 0)
+ return status;
+ } else
[PATCH 2/6] net: macb: add support for sgmii MAC-PHY interface
This is version 2 of patch to add support for SGMII interface) and 2.5Gbps MAC in Cadence ethernet controller driver. Signed-off-by: Parshuram Thombare --- drivers/net/ethernet/cadence/macb.h | 76 +-- drivers/net/ethernet/cadence/macb_main.c | 157 --- 2 files changed, 202 insertions(+), 31 deletions(-) diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h index 35ed13236c8b..85c7e4cb1057 100644 --- a/drivers/net/ethernet/cadence/macb.h +++ b/drivers/net/ethernet/cadence/macb.h @@ -80,6 +80,7 @@ #define MACB_RBQPH 0x04D4 /* GEM register offsets. */ +#define GEM_NCR0x /* Network Control */ #define GEM_NCFGR 0x0004 /* Network Config */ #define GEM_USRIO 0x000c /* User IO */ #define GEM_DMACFG 0x0010 /* DMA Configuration */ @@ -159,6 +160,9 @@ #define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */ #define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */ #define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */ +#define GEM_PCS_CTRL 0x0200 /* PCS Control */ +#define GEM_PCS_STATUS 0x0204 /* PCS Status */ +#define GEM_PCS_AN_LP_BASE 0x0214 /* PCS AN LP BASE*/ #define GEM_DCFG1 0x0280 /* Design Config 1 */ #define GEM_DCFG2 0x0284 /* Design Config 2 */ #define GEM_DCFG3 0x0288 /* Design Config 3 */ @@ -274,6 +278,10 @@ #define MACB_IRXFCS_OFFSET 19 #define MACB_IRXFCS_SIZE 1 +/* GEM specific NCR bitfields. */ +#define GEM_TWO_PT_FIVE_GIG_OFFSET 29 +#define GEM_TWO_PT_FIVE_GIG_SIZE 1 + /* GEM specific NCFGR bitfields. */ #define GEM_GBE_OFFSET 10 /* Gigabit mode enable */ #define GEM_GBE_SIZE 1 @@ -326,6 +334,9 @@ #define MACB_MDIO_SIZE 1 #define MACB_IDLE_OFFSET 2 /* The PHY management logic is idle */ #define MACB_IDLE_SIZE 1 +#define MACB_DUPLEX_OFFSET 3 +#define MACB_DUPLEX_SIZE1 + /* Bitfields in TSR */ #define MACB_UBR_OFFSET0 /* Used bit read */ @@ -459,11 +470,37 @@ #define MACB_REV_OFFSET0 #define MACB_REV_SIZE 16 +/* Bitfields in PCS_CONTROL. */ +#define GEM_PCS_CTRL_RST_OFFSET15 +#define GEM_PCS_CTRL_RST_SIZE 1 +#define GEM_PCS_CTRL_EN_AN_OFFSET 12 +#define GEM_PCS_CTRL_EN_AN_SIZE1 +#define GEM_PCS_CTRL_RESTART_AN_OFFSET 9 +#define GEM_PCS_CTRL_RESTART_AN_SIZE 1 + +/* Bitfields in PCS_STATUS. */ +#define GEM_PCS_STATUS_AN_DONE_OFFSET 5 +#define GEM_PCS_STATUS_AN_DONE_SIZE 1 +#define GEM_PCS_STATUS_AN_SUPPORT_OFFSET3 +#define GEM_PCS_STATUS_AN_SUPPORT_SIZE 1 +#define GEM_PCS_STATUS_LINK_OFFSET 2 +#define GEM_PCS_STATUS_LINK_SIZE1 + +/* Bitfield in PCS_AN_LP_BASE */ +#define GEM_PCS_AN_LP_BASE_LINK_OFFSET 15 +#define GEM_PCS_AN_LP_BASE_LINK_SIZE1 +#define GEM_PCS_AN_LP_BASE_DUPLEX_OFFSET12 +#define GEM_PCS_AN_LP_BASE_DUPLEX_SIZE 1 +#define GEM_PCS_AN_LP_BASE_SPEED_OFFSET 10 +#define GEM_PCS_AN_LP_BASE_SPEED_SIZE 2 + /* Bitfields in DCFG1. */ #define GEM_IRQCOR_OFFSET 23 #define GEM_IRQCOR_SIZE1 #define GEM_DBWDEF_OFFSET 25 #define GEM_DBWDEF_SIZE3 +#define GEM_NO_PCS_OFFSET 0 +#define GEM_NO_PCS_SIZE1 /* Bitfields in DCFG2. */ #define GEM_RX_PKT_BUFF_OFFSET 20 @@ -636,19 +673,32 @@ #define MACB_MAN_CODE 2 /* Capability mask bits */ -#define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x0001 -#define MACB_CAPS_USRIO_HAS_CLKEN 0x0002 -#define MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII0x0004 -#define MACB_CAPS_NO_GIGABIT_HALF 0x0008 -#define MACB_CAPS_USRIO_DISABLED 0x0010 -#define MACB_CAPS_JUMBO0x0020 -#define MACB_CAPS_GEM_HAS_PTP 0x0040 -#define MACB_CAPS_BD_RD_PREFETCH 0x0080 -#define MACB_CAPS_NEEDS_RSTONUBR 0x0100 -#define MACB_CAPS_FIFO_MODE0x1000 -#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000 -#define MACB_CAPS_SG_DISABLED 0x4000 -#define MACB_CAPS_MACB_IS_GEM 0x8000 +#define MACB_CAPS_ISR_CLEAR_ON_WRITE BIT(0) +#define MACB_CAPS_USRIO_HAS_CLKEN BIT(1) +#define MACB_CAPS_USRIO_DEFAULT_IS_MII_GMIIBIT(2) +#define MACB_CAPS_NO_GIGABIT_HALF BIT(3) +#define MACB_CAPS_USRIO_DISABLED BIT(4) +#define MACB_CAPS_JUMBOBIT(5) +#define MACB_CAPS_GEM_HAS
[PATCH 0/6] net: macb patch set cover letter
Hello !, This is second version of patch set containing following patches for Cadence ethernet controller driver. 1. 0001-net-macb-add-phylink-support.patch Replace phylib API's with phylink API's. 2. 0002-net-macb-add-support-for-sgmii-MAC-PHY-interface.patch This patch add support for SGMII mode. 3. 003-net-macb-add-PHY-configuration-in-MACB-PCI-wrapper.patch This patch is to configure TI PHY DP83867 in SGMII mode from our MAC PCI wrapper driver. With this change there is no need of PHY driver and dp83867 module must be disabled. Users wanting to setup DP83867 PHY in SGMII mode can disable dp83867.ko driver, else dp83867.ko overwrite this configuration and PHY is setup as per dp83867.ko. 4. 0004-net-macb-add-support-for-c45-PHY.patch This patch is to support C45 PHY. 5. 0005-net-macb-add-support-for-high-speed-interface This patch add support for 10G USXGMII PCS in fixed mode. Since emulated PHY used in fixed mode doesn't seems to support anything above 1G, additional parameter is used outside "fixed-link" node for selecting speed and "fixed-link" node speed is still set at 1G. 6. 0006-net-macb-parameter-added-to-cadence-ethernet-controller-DT-binding New parameters added to Cadence ethernet controller DT binding for USXGMII interface. Regards, Parshuram Thombare Parshuram Thombare (6): net: macb: add phylink support net: macb: add support for sgmii MAC-PHY interface net: macb: add PHY configuration in MACB PCI wrapper net: macb: add support for c45 PHY net: macb: add support for high speed interface net: macb: parameter added to cadence ethernet controller DT binding .../devicetree/bindings/net/macb.txt | 4 + drivers/net/ethernet/cadence/Kconfig | 2 +- drivers/net/ethernet/cadence/macb.h | 136 +++- drivers/net/ethernet/cadence/macb_main.c | 659 ++ drivers/net/ethernet/cadence/macb_pci.c | 225 ++ 5 files changed, 860 insertions(+), 166 deletions(-) -- 2.17.1
Re: [PATCH bpf v2] bpf: fix nested bpf tracepoints with per-cpu data
On Tue, Jun 11, 2019 at 2:54 PM Matt Mullins wrote:
>
> BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as
> they do not increment bpf_prog_active while executing.
>
> This enables three levels of nesting, to support
> - a kprobe or raw tp or perf event,
> - another one of the above that irq context happens to call, and
> - another one in nmi context
> (at most one of which may be a kprobe or perf event).
>
> Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data")
> Signed-off-by: Matt Mullins
Applied. Thanks
general protection fault in sctp_sched_prio_sched
Hello,
syzbot found the following crash on:
HEAD commit:35fc07ae Merge branch 'tcp-add-three-static-keys'
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=118e5caea0
kernel config: https://syzkaller.appspot.com/x/.config?x=e8b7a9cd7feeb720
dashboard link: https://syzkaller.appspot.com/bug?extid=c1a380d42b190ad1e559
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11551df1a0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12417076a0
The bug was bisected to:
commit 4ff40b86262b73553ee47cc3784ce8ba0f220bd8
Author: Xin Long
Date: Mon Jan 21 18:42:09 2019 +
sctp: set chunk transport correctly when it's a new asoc
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=104d1df1a0
final crash:https://syzkaller.appspot.com/x/report.txt?x=124d1df1a0
console output: https://syzkaller.appspot.com/x/log.txt?x=144d1df1a0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c1a380d42b190ad1e...@syzkaller.appspotmail.com
Fixes: 4ff40b86262b ("sctp: set chunk transport correctly when it's a new
asoc")
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8330 Comm: syz-executor666 Not tainted 5.2.0-rc3+ #52
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:sctp_sched_prio_sched+0x96/0x6f0 net/sctp/stream_sched_prio.c:132
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 0d 05 00 00 48 b8 00 00 00 00
00 fc ff df 4c 8b 73 50 4d 8d 6e 20 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f
85 f4 04 00 00 4d 8b 7e 20 4d 85 ff 0f 84 f8 00 00
RSP: 0018:88809e4e7448 EFLAGS: 00010202
RAX: dc00 RBX: 8880a9533b80 RCX: 111010347201
RDX: 0004 RSI: 8696a77e RDI: 8880a9533bd0
RBP: 88809e4e7488 R08: 88808bf8e300 R09: 88809e4e7580
R10: ed1013c9cee2 R11: 0003 R12: 8880a9533bc0
R13: 0020 R14: R15: 8880a4e92380
FS: 7f48c9337700() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f48c9315e78 CR3: 9db54000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
sctp_sched_prio_enqueue+0x117/0x170 net/sctp/stream_sched_prio.c:243
sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1101 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1748 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1184 [inline]
sctp_do_sm+0x2fd0/0x5190 net/sctp/sm_sideeffect.c:1155
sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:163
sctp_sendmsg_to_asoc+0x1118/0x1f10 net/sctp/socket.c:1944
sctp_sendmsg+0x109a/0x17d0 net/sctp/socket.c:2102
inet_sendmsg+0x141/0x5d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:665
sock_write_iter+0x27c/0x3e0 net/socket.c:994
call_write_iter include/linux/fs.h:1872 [inline]
new_sync_write+0x4d3/0x770 fs/read_write.c:483
__vfs_write+0xe1/0x110 fs/read_write.c:496
vfs_write+0x20c/0x580 fs/read_write.c:558
ksys_write+0x14f/0x290 fs/read_write.c:611
__do_sys_write fs/read_write.c:623 [inline]
__se_sys_write fs/read_write.c:620 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:620
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447a69
Code: e8 cc e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f48c9336d88 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 006ddc38 RCX: 00447a69
RDX: 00010094 RSI: 2040 RDI: 0003
RBP: 006ddc30 R08: 7f48c9337700 R09:
R10: 7f48c9337700 R11: 0246 R12: 006ddc3c
R13: 7f48c9336d90 R14: 7f48c93379c0 R15: 006ddc3c
Modules linked in:
---[ end trace 01e405583d741588 ]---
RIP: 0010:sctp_sched_prio_sched+0x96/0x6f0 net/sctp/stream_sched_prio.c:132
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 0d 05 00 00 48 b8 00 00 00 00
00 fc ff df 4c 8b 73 50 4d 8d 6e 20 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f
85 f4 04 00 00 4d 8b 7e 20 4d 85 ff 0f 84 f8 00 00
RSP: 0018:88809e4e7448 EFLAGS: 00010202
RAX: dc00 RBX: 8880a9533b80 RCX: 111010347201
RDX: 0004 RSI: 8696a77e RDI: 8880a9533bd0
RBP: 88809e4e7488 R08: 88808bf8e300 R09: 88809e4e7580
R10: ed1013c9cee2 R11: 0003 R12: 8880a9533bc0
R13: 0020 R14: R15: 8880a4e92380
FS: 7f48c9337700() GS:8880ae80() knlGS:000
Re: [PATCH] i2c: mux-gpio: Use "mux" con_id to find channel GPIOs
On Sat, Jun 15, 2019 at 02:43:09PM +0300, Andy Shevchenko wrote:
> On Sat, Jun 15, 2019 at 12:51 AM Serge Semin wrote:
> >
> > Recent patch - ("i2c: mux/i801: Switch to use descriptor passing")
> > altered the i2c-mux-gpio driver to use the GPIO-descriptor
> > based interface to find and request the GPIOs then being utilized
> > to select and deselect the channels of GPIO-driven i2c-muxes. Even
> > though the proposed modification was correct for the platform_data-based
> > systems, it was invalid for the OF-based ones and caused the kernel
> > to crash at the driver probe procedure. There were two problems with
> > that modification. First of all the gpiod_count() and gpiod_get_index()
> > were called with NULL con_id.
>
> I always thought that this means "count me all GPIO's for this device
> despite their names" and "get me GPIO by index despite it's name".
> What's went wrong?
>
No. It's wrong as far as I can see for kernels 4.4, 4.9 and the modern
5.2.0-rcX. dt_gpio_count()/of_find_gpio()will always try to count/request
either "-gpio(s)" or "gpio(s)" GPIOs in the device of-node. While
platform_gpio_count()/gpiod_find() will take into account GPIOs with matching
's even if it is NULL.
Regards,
-Sergey
>
> > Due to this the methods couldn't find
> > the "mux-gpios" OF-properties and returned the -ENOENT error. Secondly
> > the return value of gpiod_count() wasn't checked for being negative,
> > which in case of an error caused the driver to crash. This patch
> > is intended to fix the described problems.
>
> --
> With Best Regards,
> Andy Shevchenko
[PATCH] HID: uclogic: Add support for Huion HS64 tablet
Add support for Huion HS64 drawing tablet to hid-uclogic
Signed-off-by: Kyle Godbey
---
drivers/hid/hid-ids.h| 1 +
drivers/hid/hid-uclogic-core.c | 2 ++
drivers/hid/hid-uclogic-params.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 84e0c78d73cd..86ed32dd18ca 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -569,6 +569,7 @@
#define USB_VENDOR_ID_HUION0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
+#define USB_DEVICE_ID_HUION_HS64 0x006d
#define USB_VENDOR_ID_IBM 0x04b3
#define USB_DEVICE_ID_IBM_SCROLLPOINT_III 0x3100
diff --git a/drivers/hid/hid-uclogic-core.c b/drivers/hid/hid-uclogic-core.c
index 8fe02d81265d..914fb527ae7a 100644
--- a/drivers/hid/hid-uclogic-core.c
+++ b/drivers/hid/hid-uclogic-core.c
@@ -369,6 +369,8 @@ static const struct hid_device_id uclogic_devices[] = {
USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HUION,
USB_DEVICE_ID_HUION_TABLET) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HUION,
+ USB_DEVICE_ID_HUION_HS64) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_HUION_TABLET) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
index 0187c9f8fc22..273d784fff66 100644
--- a/drivers/hid/hid-uclogic-params.c
+++ b/drivers/hid/hid-uclogic-params.c
@@ -977,6 +977,8 @@ int uclogic_params_init(struct uclogic_params *params,
/* FALL THROUGH */
case VID_PID(USB_VENDOR_ID_HUION,
USB_DEVICE_ID_HUION_TABLET):
+ case VID_PID(USB_VENDOR_ID_HUION,
+USB_DEVICE_ID_HUION_HS64):
case VID_PID(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_HUION_TABLET):
case VID_PID(USB_VENDOR_ID_UCLOGIC,
--
2.21.0
[PATCH v2] usb: cp210x: Add cp2108 GPIOs support
Each chip from the cp210x series got GPIOs on board. This commit
provides the support for sixteen ones placed on the cp2108 four-ports
serial console controller. Since all GPIOs are accessible via any
cp2108 USB interface we manually and equally distributed them between
all interfaces in accordance with GPIOs alternative functions attachment.
So the driver provides four GPIOs per each cp2108 USB interface.
cp2108 GPIOs can be either in open-drain or push-pull modes setup once
after reset was cleared. In this matter it doesn't differ from the rest
of cp210x devices supported by the driver. So with minor alterations the
standard output/intput GPIO interface is implemented for cp2108.
Aside from traditional GPIO functions like setting/getting pins value,
each GPIO is also multiplexed with alternative functions: TX/RX LEDs, RS485
TX-enable and Clocks source. These functions can't be activated on-fly.
Instead the chips firmware should be properly setup, so they would be
enabled in the ports-config structure at the controller logic startup.
Needless to say, that when the alternative functions are activated,
the GPIOs can't be used. Thus we need to check the GPIO pin config in the
request callback and deny the request if GPIO standard function is
disabled.
Signed-off-by: Serge Semin
---
Changelog v2:
- Rebase onto kernel 5.2.0-rc4.
- Move USB_SERIAL_CP210X config descriptor modification to a separate patch.
- Add more descriptive info of cp2108 state and config structures.
- Replace _NUM suffix with _CNT.
- Add _IDX suffix to CP2108_GPIO_PB macro.
- Add _MODE suffix to CP2108_DYNAMIC_SUSPEND macro.
- Discard __packed attribute from struct cp2108_gpio_write.
- Discard CP2108_GPIO_CNT macro and use literal 4 instead.
- Simplify cp210x_gpio_get() method by replacing the union with a u16 buffer.
- Replace ternary operations of cp210x_gpio_set() with a conditional statement.
- Add more descriptive comments regarding the gpio_altfunc bits collection.
- Fix a bug in the GPIOs setter/getter methods of invalid bit being utilized
to set/get GPIO values.
---
drivers/usb/serial/cp210x.c | 178 +---
1 file changed, 164 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 979bef9bfb6b..32f0a4273abb 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -505,6 +505,60 @@ struct cp210x_gpio_write {
u8 state;
} __packed;
+/*
+ * Number of CP2108 USB interfaces, port-blocks and GPIO port-block index,
+ * where port-blocks are the internal pins containers of the chip.
+ */
+#define CP2108_IFACE_CNT 4
+#define CP2108_PB_CNT 5
+#define CP2108_GPIO_PB_IDX 1
+
+/*
+ * CP2108 default pins state. There are five port-blocks (PB). Each one is with
+ * it' specific pins-set: Port 0 - UART 0 and 1, Port 1 - GPIOs, Port 2 - chip
+ * suspend and a part of UART 2 pins, Port 3 and 4 - UART 2 and 3 pins
+ * (for details see USB Express SDK sources or SDK-based smt application
+ * accessible here https://github.com/fancer/smt-cp210x).
+ */
+struct cp2108_state {
+ __le16 mode[CP2108_PB_CNT];/* 0 - Open-Drain, 1 - Push-Pull */
+ __le16 low_power[CP2108_PB_CNT];
+ __le16 latch[CP2108_PB_CNT]; /* 0 - Logic Low, 1 - Logic High */
+} __packed;
+
+/*
+ * CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 73 bytes.
+ * Reset/Suspend latches describe default states after reset/suspend of the
+ * pins. The rest are responsible for alternate functions settings of the
+ * chip pins (see USB Express SDK sources or SDK-based smt application
+ * https://github.com/fancer/smt-cp210x for details).
+ */
+struct cp2108_config {
+ struct cp2108_state reset_latch;
+ struct cp2108_state suspend_latch;
+ u8 ip_delay[CP2108_IFACE_CNT];
+ u8 enhanced_fxn[CP2108_IFACE_CNT];
+ u8 enhanced_fxn_dev;
+ u8 ext_clock_freq[CP2108_IFACE_CNT];
+} __packed;
+
+/* CP2108 port alternate functions fields. */
+#define CP2108_GPIO_TXLED_MODE BIT(0)
+#define CP2108_GPIO_RXLED_MODE BIT(1)
+#define CP2108_GPIO_RS485_MODE BIT(2)
+#define CP2108_GPIO_RS485_LOGICBIT(3)
+#define CP2108_GPIO_CLOCK_MODE BIT(4)
+#define CP2108_DYNAMIC_SUSPEND_MODEBIT(5)
+
+/*
+ * CP210X_VENDOR_SPECIFIC, CP210X_WRITE_LATCH call writes these 0x4 bytes
+ * to CP2108 controller.
+ */
+struct cp2108_gpio_write {
+ __le16 mask;
+ __le16 state;
+};
+
/*
* Helper to get interface number when we only have struct usb_serial.
*/
@@ -1366,10 +1420,13 @@ static int cp210x_gpio_get(struct gpio_chip *gc,
unsigned int gpio)
struct usb_serial *serial = gpiochip_get_data(gc);
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
u8 req_type = REQTYPE_DEVICE_TO_HOST;
+ int bufsize = 1;
int result;
- u8 buf;
+ u16 buf;
- if (pr
Re: [PATCH] usb: cp210x: Add cp2108 GPIOs support
Hello Johan
On Mon, Jun 03, 2019 at 02:52:05PM +0200, Johan Hovold wrote:
> On Tue, May 14, 2019 at 01:53:57PM +0300, Serge Semin wrote:
> > Each chip from the cp210x series got GPIOs on board. This commit
> > provides the support for sixteen ones placed on the cp2108 four-ports
> > serial console controller. All of the GPIOs are equally distributed
> > to four USB interfaces in accordance with GPIOs alternative functions
> > attachment.
> >
> > cp2108 GPIOs can be either in open-drain or push-pull modes setup once
> > after reset was cleared. In this matter it doesn't differ from the rest
> > of cp210x devices supported by the driver. So with minor alterations the
> > standard output/intput GPIO interface is implemented for cp2108.
> >
> > Aside from traditional GPIO functions like setting/getting pins value,
> > each GPIO is also multiplexed with alternative functions: TX/RX LEDs, RS485
> > TX-enable and Clocks source. These functions can't be activated on-fly.
> > Instead the chips firmware should be properly setup, so they would be
> > enabled in the ports-config structure at the controller logic startup.
> > Needless to say, that when the alternative functions are activated,
> > the GPIOs can't be used. Thus we need to check the GPIO pin config in the
> > request callback and deny the request if GPIO standard function is
> > disabled.
>
> Thanks for the patch.
>
> I'm a bit worried about the logic getting too convoluted when dealing
> with the cp2108 and cp2105 differences. Please see if you can do
> something about that.
>
> Other than that, just some minor comments and request for
> clarifications.
>
> > Signed-off-by: Serge Semin
> > ---
> > drivers/usb/serial/Kconfig | 2 +-
> > drivers/usb/serial/cp210x.c | 158
> > 2 files changed, 143 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
> > index 7d031911d04e..20bd4c0632c7 100644
> > --- a/drivers/usb/serial/Kconfig
> > +++ b/drivers/usb/serial/Kconfig
> > @@ -138,7 +138,7 @@ config USB_SERIAL_DIGI_ACCELEPORT
> > config USB_SERIAL_CP210X
> > tristate "USB CP210x family of UART Bridge Controllers"
> > help
> > - Say Y here if you want to use a CP2101/CP2102/CP2103 based USB
> > + Say Y here if you want to use a CP2101/2/3/4/5/8 based USB
>
> Please drop this since it's a separate change. If anything we should
> probably just change this to "CP210X" not have to worry about it getting
> outdated again.
>
Ok. Moved to a separate patch.
> > to RS232 converters.
> >
> > To compile this driver as a module, choose M here: the
> > diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> > index 979bef9bfb6b..a97f04d9e99f 100644
> > --- a/drivers/usb/serial/cp210x.c
> > +++ b/drivers/usb/serial/cp210x.c
> > @@ -505,6 +505,56 @@ struct cp210x_gpio_write {
> > u8 state;
> > } __packed;
> >
> > +/* CP2108 interfaces, gpio (per interface), port-blocks number, GPIO
> > block. */
> > +#define CP2108_IFACE_NUM 4
> > +#define CP2108_GPIO_NUM4
> > +#define CP2108_PB_NUM 5
> > +#define CP2108_GPIO_PB 1
>
> Please try to give these more descriptive names; I'd prefer COUNT over
> NUM when used as a suffix.
>
> Perhaps slap an INDEX suffix on CP2108_GPIO_PB etc.
>
Ok. Added CNT and IDX suffixes.
> > +/*
> > + * CP2108 default pins state. There are five PBs. Each one is with its
> > specific
> > + * pins-set (see USB Express SDK sources or SDK-based smt application
> > + * https://github.com/fancer/smt-cp210x for details).
> > + */
> > +struct cp2108_state {
> > + __le16 mode[CP2108_PB_NUM];/* 0 - Open-Drain, 1 - Push-Pull */
> > + __le16 low_power[CP2108_PB_NUM];
> > + __le16 latch[CP2108_PB_NUM]; /* 0 - Logic Low, 1 - Logic High */
> > +} __packed;
>
> Ok, so you use mode[CP2108_GPIO_PB] to get the pin modes below;
> what are the other "PB"s used for? Why is it a "port" block, if all 16
> pins allocated to four different ports are accessible through one block?
>
> Please try to make the comment self-contained (even if you leave some
> details out). And perhaps we shouldn't refer to proprietary code in
> here, and in any case the link may go away.
>
Ok added a bit more detailed information regarding the port blocks. But
I'd prefer to keep the link. First of all I can't provide the complete
description of the fields here because it would take too much space and
in fact is pointless since only a single port block with GPIOs is utilized.
So the link and the SDK info are a good reference to find some details
(especially due to lacking such an info in the chip datasheet). Secondly
even though the code is distributed under the Silicon Labs specific license
it is open-source. Finally the link may go away only if I removed the
application from my github account, which I don't intend to.
> > +/*
> > + * CP210X_VEND
[PATCH bpf] bpf: fix the check that forwarding is enabled in bpf_ipv6_fib_lookup
The bpf_ipv6_fib_lookup function should return BPF_FIB_LKUP_RET_FWD_DISABLED
when forwarding is disabled for the input device. However instead of checking
if forwarding is enabled on the input device, it checked the global
net->ipv6.devconf_all->forwarding flag. Change it to behave as expected.
Signed-off-by: Anton Protopopov
---
net/core/filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index f615e42cf4ef..3fdf1b21be36 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -4737,7 +4737,7 @@ static int bpf_ipv6_fib_lookup(struct net *net, struct
bpf_fib_lookup *params,
return -ENODEV;
idev = __in6_dev_get_safely(dev);
- if (unlikely(!idev || !net->ipv6.devconf_all->forwarding))
+ if (unlikely(!idev || !idev->cnf.forwarding))
return BPF_FIB_LKUP_RET_FWD_DISABLED;
if (flags & BPF_FIB_LOOKUP_OUTPUT) {
--
2.19.1
Re: [PATCH AUTOSEL 5.1 16/59] fpga: dfl: Add lockdep classes for pdata->lock
On Sat, Jun 15, 2019 at 07:47:39AM +0200, Greg Kroah-Hartman wrote:
On Fri, Jun 14, 2019 at 04:28:00PM -0400, Sasha Levin wrote:
From: Scott Wood
[ Upstream commit dfe3de8d397bf878b31864d4e489d41118ec475f ]
struct dfl_feature_platform_data (and it's mutex) is used
by both fme and port devices, and when lockdep is enabled it
complains about nesting between these locks. Tell lockdep about
the difference so it can track each class separately.
Here's the lockdep complaint:
[ 409.680668] WARNING: possible recursive locking detected
[ 409.685983] 5.1.0-rc3.fpga+ #1 Tainted: GE
[ 409.691469]
[ 409.696779] fpgaconf/9348 is trying to acquire lock:
[ 409.701746] a443fe2e (&pdata->lock){+.+.}, at:
port_enable_set+0x24/0x60 [dfl_afu]
[ 409.710006]
[ 409.710006] but task is already holding lock:
[ 409.715837] 63b78782 (&pdata->lock){+.+.}, at:
fme_pr_ioctl+0x21d/0x330 [dfl_fme]
[ 409.724012]
[ 409.724012] other info that might help us debug this:
[ 409.730535] Possible unsafe locking scenario:
[ 409.730535]
[ 409.736457]CPU0
[ 409.738910]
[ 409.741360] lock(&pdata->lock);
[ 409.744679] lock(&pdata->lock);
[ 409.747999]
[ 409.747999] *** DEADLOCK ***
[ 409.747999]
[ 409.753920] May be due to missing lock nesting notation
[ 409.753920]
[ 409.760704] 4 locks held by fpgaconf/9348:
[ 409.764805] #0: 63b78782 (&pdata->lock){+.+.}, at:
fme_pr_ioctl+0x21d/0x330 [dfl_fme]
[ 409.773408] #1: 213c8a66 (®ion->mutex){+.+.}, at:
fpga_region_program_fpga+0x24/0x200 [fpga_region]
[ 409.783489] #2: fe63afb9 (&mgr->ref_mutex){+.+.}, at:
fpga_mgr_lock+0x15/0x40 [fpga_mgr]
[ 409.792354] #3: 0b2285c5 (&bridge->mutex){+.+.}, at:
__fpga_bridge_get+0x26/0xa0 [fpga_bridge]
[ 409.801740]
[ 409.801740] stack backtrace:
[ 409.806102] CPU: 45 PID: 9348 Comm: fpgaconf Kdump: loaded Tainted: G
E 5.1.0-rc3.fpga+ #1
[ 409.815658] Hardware name: Intel Corporation S2600BT/S2600BT, BIOS
SE5C620.86B.01.00.0763.022420181017 02/24/2018
[ 409.825911] Call Trace:
[ 409.828369] dump_stack+0x5e/0x8b
[ 409.831686] __lock_acquire+0xf3d/0x10e0
[ 409.835612] ? find_held_lock+0x3c/0xa0
[ 409.839451] lock_acquire+0xbc/0x1d0
[ 409.843030] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.847823] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.852616] __mutex_lock+0x86/0x970
[ 409.856195] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.860989] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.865777] ? __mutex_unlock_slowpath+0x4b/0x290
[ 409.870486] port_enable_set+0x24/0x60 [dfl_afu]
[ 409.875106] fpga_bridges_disable+0x36/0x50 [fpga_bridge]
[ 409.880502] fpga_region_program_fpga+0xea/0x200 [fpga_region]
[ 409.886338] fme_pr_ioctl+0x13e/0x330 [dfl_fme]
[ 409.890870] fme_ioctl+0x66/0xe0 [dfl_fme]
[ 409.894973] do_vfs_ioctl+0xa9/0x720
[ 409.898548] ? lockdep_hardirqs_on+0xf0/0x1a0
[ 409.902907] ksys_ioctl+0x60/0x90
[ 409.906225] __x64_sys_ioctl+0x16/0x20
[ 409.909981] do_syscall_64+0x5a/0x220
[ 409.913644] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 409.918698] RIP: 0033:0x7f9d31b9b8d7
[ 409.922276] Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff
ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48
[ 409.941020] RSP: 002b:7ffe4cae0d68 EFLAGS: 0202 ORIG_RAX:
0010
[ 409.948588] RAX: ffda RBX: 7f9d32ade6a0 RCX: 7f9d31b9b8d7
[ 409.955719] RDX: 7ffe4cae0df0 RSI: b680 RDI: 0003
[ 409.962852] RBP: 0003 R08: 7f9d2b70a177 R09: 7ffe4cae0e40
[ 409.969984] R10: 7ffe4cae0160 R11: 0202 R12: 7ffe4cae0df0
[ 409.977115] R13: b680 R14: R15: 7ffe4cae0f60
Signed-off-by: Scott Wood
Acked-by: Wu Hao
Acked-by: Alan Tull
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/fpga/dfl.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
Adding lockdep stuff is not really needed for stable kernels, please
drop this from all trees.
For actual splats? Why? I treat them as compiler warnings. Keeping these
around will just make them show up over and over in testing (at least
until we unify our testing story...).
--
Thanks,
Sasha
Re: [PATCH 16/43] KVM: nVMX: Always sync GUEST_BNDCFGS when it comes from vmcs01
You should apply something as the following instead of the original fix by Sean
to play nicely on upstream without additional dependency:
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index f1a69117ac0f..3fc44852ed4f 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2234,12 +2234,9 @@ static void prepare_vmcs02_full(struct vcpu_vmx *vmx,
struct vmcs12 *vmcs12)
set_cr4_guest_host_mask(vmx);
- if (kvm_mpx_supported()) {
- if (vmx->nested.nested_run_pending &&
- (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
- vmcs_write64(GUEST_BNDCFGS, vmcs12->guest_bndcfgs);
- else
- vmcs_write64(GUEST_BNDCFGS,
vmx->nested.vmcs01_guest_bndcfgs);
+ if (kvm_mpx_supported() && vmx->nested.nested_run_pending &&
+ (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS)) {
+ vmcs_write64(GUEST_BNDCFGS, vmcs12->guest_bndcfgs);
}
}
@@ -2283,6 +2280,10 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct
vmcs12 *vmcs12,
kvm_set_dr(vcpu, 7, vcpu->arch.dr7);
vmcs_write64(GUEST_IA32_DEBUGCTL, vmx->nested.vmcs01_debugctl);
}
+ if (kvm_mpx_supported() && (!vmx->nested.nested_run_pending ||
+ !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))) {
+ vmcs_write64(GUEST_BNDCFGS, vmx->nested.vmcs01_guest_bndcfgs);
+ }
vmx_set_rflags(vcpu, vmcs12->guest_rflags);
/* EXCEPTION_BITMAP and CR0_GUEST_HOST_MASK should basically be the
-Liran
> On 16 Jun 2019, at 1:16, Sasha Levin wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 62cf9bd8118c KVM: nVMX: Fix emulation of VM_ENTRY_LOAD_BNDCFGS.
>
> The bot has tested the following trees: v5.1.9, v4.19.50.
>
> v5.1.9: Build OK!
> v4.19.50: Failed to apply! Possible dependencies:
>09abb5e3e5e5 ("KVM: nVMX: call kvm_skip_emulated_instruction in
> nested_vmx_{fail,succeed}")
>09abe3200266 ("KVM: nVMX: split pieces of prepare_vmcs02() to
> prepare_vmcs02_early()")
>1438921c6dc1 ("KVM: nVMX: Flush TLB entries tagged by dest EPTP on L1<->L2
> transitions")
>199b118ab3d5 ("KVM: VMX: Alphabetize the includes in vmx.c")
>1abf23fb42f5 ("KVM: nVMX: use vm_exit_controls_init() to write exit
> controls for vmcs02")
>327c072187f7 ("KVM: nVMX: Flush linear and combined mappings on VPID02
> related flushes")
>3d5bdae8b164 ("KVM: nVMX: Use correct VPID02 when emulating L1 INVVPID")
>3df5c37e55c8 ("KVM: nVMX: try to set EFER bits correctly when initializing
> controls")
>55d2375e58a6 ("KVM: nVMX: Move nested code to dedicated files")
>5b8ba41dafd7 ("KVM: nVMX: move vmcs12 EPTP consistency check to
> check_vmentry_prereqs()")
>609363cf81fc ("KVM: nVMX: Move vmcs12 code to dedicated files")
>75edce8a4548 ("KVM: VMX: Move eVMCS code to dedicated files")
>7671ce21b13b ("KVM: nVMX: move check_vmentry_postreqs() call to
> nested_vmx_enter_non_root_mode()")
>945679e301ea ("KVM: nVMX: add enlightened VMCS state")
>a633e41e7362 ("KVM: nVMX: assimilate nested_vmx_entry_failure() into
> nested_vmx_enter_non_root_mode()")
>a821bab2d1ee ("KVM: VMX: Move VMX specific files to a "vmx" subdirectory")
>b8bbab928fb1 ("KVM: nVMX: implement enlightened VMPTRLD and VMCLEAR")
>d63907dc7dd1 ("KVM: nVMX: rename enter_vmx_non_root_mode to
> nested_vmx_enter_non_root_mode")
>efebf0aaec3d ("KVM: nVMX: Do not flush TLB on L1<->L2 transitions if L1
> uses VPID and EPT")
>
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
Re: [PATCH 2/3] hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race
On Fri, Jun 14, 2019 at 04:33:53PM -0700, Mike Kravetz wrote: On 6/14/19 2:56 PM, Sasha Levin wrote: Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: ebed4bfc8da8 [PATCH] hugetlb: fix absurd HugePages_Rsvd. How should we proceed with this patch? I hope you do nothing with this as the patch is not upstream. We do not, it's just a way to get more responses before people moved on to dealing with other work. -- Thanks, Sasha
Re: [PATCH AUTOSEL 5.1 06/60] driver core: platform: Fix the usage of platform device name(pdev->name)
On Wed, Jun 05, 2019 at 06:58:46AM +0200, Greg Kroah-Hartman wrote: On Tue, Jun 04, 2019 at 07:21:16PM -0400, Sasha Levin wrote: From: Venkata Narendra Kumar Gutta [ Upstream commit edb16da34b084c66763f29bee42b4e6bb33c3d66 ] Platform core is using pdev->name as the platform device name to do the binding of the devices with the drivers. But, when the platform driver overrides the platform device name with dev_set_name(), the pdev->name is pointing to a location which is freed and becomes an invalid parameter to do the binding match. use-after-free instance: [ 33.325013] BUG: KASAN: use-after-free in strcmp+0x8c/0xb0 [ 33.330646] Read of size 1 at addr ffc10beae600 by task modprobe [ 33.339068] CPU: 5 PID: 518 Comm: modprobe Tainted: G S W O 4.19.30+ #3 [ 33.346835] Hardware name: MTP (DT) [ 33.350419] Call trace: [ 33.352941] dump_backtrace+0x0/0x3b8 [ 33.356713] show_stack+0x24/0x30 [ 33.360119] dump_stack+0x160/0x1d8 [ 33.363709] print_address_description+0x84/0x2e0 [ 33.368549] kasan_report+0x26c/0x2d0 [ 33.372322] __asan_report_load1_noabort+0x2c/0x38 [ 33.377248] strcmp+0x8c/0xb0 [ 33.380306] platform_match+0x70/0x1f8 [ 33.384168] __driver_attach+0x78/0x3a0 [ 33.388111] bus_for_each_dev+0x13c/0x1b8 [ 33.392237] driver_attach+0x4c/0x58 [ 33.395910] bus_add_driver+0x350/0x560 [ 33.399854] driver_register+0x23c/0x328 [ 33.403886] __platform_driver_register+0xd0/0xe0 So, use dev_name(&pdev->dev), which fetches the platform device name from the kobject(dev->kobj->name) of the device instead of the pdev->name. Signed-off-by: Venkata Narendra Kumar Gutta Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/base/platform.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) Please drop this from everywhere as it was reverted from Linus's tree because it causes big problems. Dropped from all branches, thanks! -- Thanks, Sasha
Re: [PATCH] mtd: rawnand: ingenic: Fix build error
Hi,
I don't think the patch is correct. We want to be able to build
the ingenic_nand driver without the ingenic_ecc code.
The actual problem is that if the ingenic_nand driver is built-in,
then the ingenic_ecc driver must be built-in too (if enabled),
and we don't verify that constraint.
Something like that should work better:
config MTD_NAND_INGENIC_ECC
def_tristate m if MTD_NAND_JZ4780=m
def_tristate y if MTD_NAND_JZ4780=y
Thanks,
-Paul
Le sam. 15 juin 2019 à 15:44, YueHaibing a
écrit :
If MTD_NAND_JZ4780 is y and MTD_NAND_JZ4780_BCH is m,
which select CONFIG_MTD_NAND_INGENIC_ECC to m, building fails:
drivers/mtd/nand/raw/ingenic/ingenic_nand.o: In function
`ingenic_nand_remove':
ingenic_nand.c:(.text+0x177): undefined reference to
`ingenic_ecc_release'
drivers/mtd/nand/raw/ingenic/ingenic_nand.o: In function
`ingenic_nand_ecc_correct':
ingenic_nand.c:(.text+0x2ee): undefined reference to
`ingenic_ecc_correct'
Select MTD_NAND_INGENIC_ECC if MTD_NAND_JZ4780 is set
Reported-by: Hulk Robot
Fiexes: 15de8c6efd0e ("mtd: rawnand: ingenic: Separate top-level and
SoC specific code")
Signed-off-by: YueHaibing
---
drivers/mtd/nand/raw/ingenic/Kconfig | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/ingenic/Kconfig
b/drivers/mtd/nand/raw/ingenic/Kconfig
index 19a96ce..d0b1909 100644
--- a/drivers/mtd/nand/raw/ingenic/Kconfig
+++ b/drivers/mtd/nand/raw/ingenic/Kconfig
@@ -9,6 +9,7 @@ config MTD_NAND_JZ4740
config MTD_NAND_JZ4780
tristate "JZ4780 NAND controller"
depends on JZ4780_NEMC
+ select MTD_NAND_INGENIC_ECC
help
Enables support for NAND Flash connected to the NEMC on JZ4780 SoC
based boards, using the BCH controller for hardware error
correction.
@@ -20,7 +21,6 @@ config MTD_NAND_INGENIC_ECC
config MTD_NAND_JZ4740_ECC
tristate "Hardware BCH support for JZ4740 SoC"
- select MTD_NAND_INGENIC_ECC
help
Enable this driver to support the Reed-Solomon error-correction
hardware present on the JZ4740 SoC from Ingenic.
@@ -30,7 +30,6 @@ config MTD_NAND_JZ4740_ECC
config MTD_NAND_JZ4725B_BCH
tristate "Hardware BCH support for JZ4725B SoC"
- select MTD_NAND_INGENIC_ECC
help
Enable this driver to support the BCH error-correction hardware
present on the JZ4725B SoC from Ingenic.
@@ -40,7 +39,6 @@ config MTD_NAND_JZ4725B_BCH
config MTD_NAND_JZ4780_BCH
tristate "Hardware BCH support for JZ4780 SoC"
- select MTD_NAND_INGENIC_ECC
help
Enable this driver to support the BCH error-correction hardware
present on the JZ4780 SoC from Ingenic.
--
2.7.4
Re: [PATCH bpf] bpf, x64: fix stack layout of JITed bpf code
On Fri, Jun 14, 2019 at 4:10 PM Alexei Starovoitov wrote:
>
> Since commit 177366bf7ceb the %rbp stopped pointing to %rbp of the
> previous stack frame. That broke frame pointer based stack unwinding.
> This commit is a partial revert of it.
> Note that the location of tail_call_cnt is fixed, since the verifier
> enforces MAX_BPF_STACK stack size for programs with tail calls.
>
> Fixes: 177366bf7ceb ("bpf: change x86 JITed program stack layout")
> Signed-off-by: Alexei Starovoitov
Applied to bpf tree.
Re: [PATCH v2 bpf-next] bpf: sk_storage: Fix out of bounds memory access
On Fri, Jun 14, 2019 at 3:36 PM Daniel Borkmann wrote:
> >
> >> Force the minimum number of locks to two.
> >>
> >> Signed-off-by: Arthur Fabre
> >> Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage")
>
> The offending commit is already in Linus tree hence if so bpf tree. Arthur,
> please
> elaborate why bpf-next is targeted specifically here?
It's certainly should be in bpf tree.
It didn't apply directly, so I tweaked it a tiny bit,
reduced verbosity of commit log and pushed to bpf tree.
Thanks for the fix!
Re: general protection fault in oom_unkillable_task
On 2019/06/16 3:50, Shakeel Butt wrote: >> While dump_tasks() traverses only each thread group, mem_cgroup_scan_tasks() >> traverses each thread. > > I think mem_cgroup_scan_tasks() traversing threads is not intentional > and css_task_iter_start in it should use CSS_TASK_ITER_PROCS as the > oom killer only cares about the processes or more specifically > mm_struct (though two different thread groups can have same mm_struct > but that is fine). We can't use CSS_TASK_ITER_PROCS from mem_cgroup_scan_tasks(). I've tried CSS_TASK_ITER_PROCS in an attempt to evaluate only one thread from each thread group, but I found that CSS_TASK_ITER_PROCS causes skipping whole threads in a thread group (and trivially allowing "Out of memory and no killable processes...\n" flood) if thread group leader has already exited. If we can agree with using a flag in mm_struct in order to track whether each mm_struct was already evaluated for each out_of_memory() call, we can printk() only one thread from all thread groups sharing that mm_struct...
[PATCH v2] staging: rtl8723bs: Resolve checkpatch error "that open brace { should be on the previous line" in the rtl8723 driver
Cleaned up the code from the following files to get rid of
check patch error "that open brace { should be on the previous line"
drivers/staging/rtl8723bs/os_dep/mlme_linux.c
drivers/staging/rtl8723bs/os_dep/recv_linux.c
drivers/staging/rtl8723bs/os_dep/rtw_proc.c
drivers/staging/rtl8723bs/os_dep/sdio_intf.c
drivers/staging/rtl8723bs/os_dep/sdio_ops_linux.c
Signed-off-by: Shobhit Kukreti
---
Changes in v2:
- Removed Trailing whitespace introduced in the previous patch
- Moved comments to a new line
drivers/staging/rtl8723bs/os_dep/mlme_linux.c | 15 +++--
drivers/staging/rtl8723bs/os_dep/recv_linux.c | 77 ---
drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 6 +-
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 15 ++---
drivers/staging/rtl8723bs/os_dep/sdio_ops_linux.c | 24 +++
5 files changed, 49 insertions(+), 88 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
index aa2499f..4631b68 100644
--- a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
@@ -46,8 +46,7 @@ void rtw_os_indicate_connect(struct adapter *adapter)
struct mlme_priv *pmlmepriv = &(adapter->mlmepriv);
if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
- (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true))
- {
+ (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)) {
rtw_cfg80211_ibss_indicate_connect(adapter);
}
else
@@ -77,8 +76,8 @@ void rtw_reset_securitypriv(struct adapter *adapter)
spin_lock_bh(&adapter->security_key_mutex);
- if (adapter->securitypriv.dot11AuthAlgrthm == dot11AuthAlgrthm_8021X)/*
802.1x */
- {
+ if (adapter->securitypriv.dot11AuthAlgrthm == dot11AuthAlgrthm_8021X) {
/* 802.1x */
+
/* Added by Albert 2009/02/18 */
/* We have to backup the PMK information for WiFi PMK Caching
test item. */
/* */
@@ -106,8 +105,9 @@ void rtw_reset_securitypriv(struct adapter *adapter)
adapter->securitypriv.ndisencryptstatus = Ndis802_11WEPDisabled;
}
- else /* reset values in securitypriv */
- {
+ else {
+ /* reset values in securitypriv */
+
/* if (adapter->mlmepriv.fw_state & WIFI_STATION_STATE) */
/* */
struct security_priv *psec_priv = &adapter->securitypriv;
@@ -150,8 +150,7 @@ void rtw_report_sec_ie(struct adapter *adapter, u8
authmode, u8 *sec_ie)
RT_TRACE(_module_mlme_osdep_c_, _drv_info_, ("+rtw_report_sec_ie,
authmode =%d\n", authmode));
buff = NULL;
- if (authmode == _WPA_IE_ID_)
- {
+ if (authmode == _WPA_IE_ID_) {
RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
("rtw_report_sec_ie, authmode =%d\n", authmode));
buff = rtw_zmalloc(IW_CUSTOM_MAX);
diff --git a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
index 3fe9c22..a2055f6 100644
--- a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
@@ -12,8 +12,7 @@
void rtw_os_free_recvframe(union recv_frame *precvframe)
{
- if (precvframe->u.hdr.pkt)
- {
+ if (precvframe->u.hdr.pkt) {
dev_kfree_skb_any(precvframe->u.hdr.pkt);/* free skb by driver
*/
precvframe->u.hdr.pkt = NULL;
@@ -34,10 +33,8 @@ void rtw_os_recv_resource_free(struct recv_priv *precvpriv)
precvframe = (union recv_frame*) precvpriv->precv_frame_buf;
- for (i = 0; i < NR_RECVFRAME; i++)
- {
- if (precvframe->u.hdr.pkt)
- {
+ for (i = 0; i < NR_RECVFRAME; i++) {
+ if (precvframe->u.hdr.pkt) {
dev_kfree_skb_any(precvframe->u.hdr.pkt);/* free skb by
driver */
precvframe->u.hdr.pkt = NULL;
}
@@ -48,8 +45,7 @@ void rtw_os_recv_resource_free(struct recv_priv *precvpriv)
/* free os related resource in struct recv_buf */
void rtw_os_recvbuf_resource_free(struct adapter *padapter, struct recv_buf
*precvbuf)
{
- if (precvbuf->pskb)
- {
+ if (precvbuf->pskb) {
dev_kfree_skb_any(precvbuf->pskb);
}
}
@@ -63,22 +59,18 @@ _pkt *rtw_os_alloc_msdu_pkt(union recv_frame *prframe, u16
nSubframe_Length, u8
pattrib = &prframe->u.hdr.attrib;
sub_skb = rtw_skb_alloc(nSubframe_Length + 12);
- if (sub_skb)
- {
+ if (sub_skb) {
skb_reserve(sub_skb, 12);
skb_put_data(sub_skb, (pdata + ETH_HLEN), nSubframe_Length);
}
- else
- {
+ else {
sub_skb = rtw_skb_clone(prframe->u.hdr.pkt);
- if (sub_skb)
- {
+ if (sub_skb) {
sub_
Re: [PATCH net-next] net: stmmac: Fix wrapper drivers not detecting PHY
From: Jose Abreu
Date: Fri, 14 Jun 2019 17:06:57 +0200
> Because of PHYLINK conversion we stopped parsing the phy-handle property
> from DT. Unfortunatelly, some wrapper drivers still rely on this phy
> node to configure the PHY.
>
> Let's restore the parsing of PHY handle while these wrapper drivers are
> not fully converted to PHYLINK.
>
> Reported-by: Corentin Labbe
> Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib
> logic")
> Signed-off-by: Jose Abreu
Applied, thanks.
Re: [RFC 0/5] livepatch: new API to track system state changes
On Tue, Jun 11, 2019 at 03:56:22PM +0200, Petr Mladek wrote: > Hi, > > this is another piece in the puzzle that helps to maintain more > livepatches. > > Especially pre/post (un)patch callbacks might change a system state. > Any newly installed livepatch has to somehow deal with system state > modifications done be already installed livepatches. > > This patchset provides, hopefully, a simple and generic API that > helps to keep and pass information between the livepatches. > It is also usable to prevent loading incompatible livepatches. > > There was also a related idea to add a sticky flag. It should be > easy to add it later. It would perfectly fit into the new struct > klp_state. > > Petr Mladek (5): > livepatch: Keep replaced patches until post_patch callback is called > livepatch: Basic API to track system state changes > livepatch: Allow to distinguish different version of system state > changes > livepatch: Documentation of the new API for tracking system state > changes > livepatch: Selftests of the API for tracking system state changes I confess I missed most of the previous discussion, but from a first read-through this seems reasonable, and the code looks simple and self-contained. -- Josh
Re: [v2, 0/6] Reuse ptp_qoriq driver for dpaa2-ptp
From: Yangbo Lu Date: Fri, 14 Jun 2019 18:40:49 +0800 > 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. > > --- > Changes for v2: > - Allowed to compile with COMPILE_TEST. Series applied, thanks.
Re: [PATCH v4 0/3] livepatch: Cleanup of reliable stacktrace warnings
On Tue, Jun 11, 2019 at 04:13:17PM +0200, Miroslav Benes wrote: > This is the fourth attempt to improve the situation of reliable stack > trace warnings in livepatch. Based on discussion in > 20190531074147.27616-1-pmla...@suse.com (v3). > > Changes against v3: > + weak save_stack_trace_tsk_reliable() removed, because it is not needed > anymore thanks to Thomas' recent improvements > + klp_have_reliable_stack() check reintroduced in klp_try_switch_task() > > Changes against v2: > > + Put back the patch removing WARN_ONCE in the weak > save_stack_trace_tsk_reliable(). It is related. > + Simplified patch removing the duplicate warning from klp_check_stack() > + Update commit message for 3rd patch [Josh] > > Miroslav Benes (2): > stacktrace: Remove weak version of save_stack_trace_tsk_reliable() > Revert "livepatch: Remove reliable stacktrace check in > klp_try_switch_task()" > > Petr Mladek (1): > livepatch: Remove duplicate warning about missing reliable stacktrace > support > > kernel/livepatch/transition.c | 8 +++- > kernel/stacktrace.c | 8 > 2 files changed, 7 insertions(+), 9 deletions(-) Thanks Miroslav for wrapping this up, and thanks to Petr for his previous work on this. Acked-by: Josh Poimboeuf -- Josh
Re: [PATCH net-next] hinic: Use devm_kasprintf instead of hard coding it
From: Christophe JAILLET Date: Thu, 13 Jun 2019 21:54:12 +0200 > 'devm_kasprintf' is less verbose than: >snprintf(NULL, 0, ...); >devm_kzalloc(...); >sprintf > so use it instead. > > Signed-off-by: Christophe JAILLET Applied.
Re: [PATCH] net: ipva: fix uninitialized variable warning
From: Charles <18oliveira.char...@gmail.com>
Date: Thu, 13 Jun 2019 14:28:41 -0300
> Avoid following compiler warning on uninitialized variable
>
> net/ipv4/fib_semantics.c: In function ‘fib_check_nh_v4_gw’:
> net/ipv4/fib_semantics.c:1023:12: warning: ‘err’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>if (!tbl || err) {
>
> Signed-off-by: Charles Oliveira <18oliveira.char...@gmail.com>
This is already fixed in the 'net' GIT tree, please always submit networking
patches against the appropriate tree.
Thank you.
Re: [PATCH] fix double-fetch bug in sock_getsockopt()
From: JingYi Hou Date: Thu, 13 Jun 2019 18:44:57 +0800 > In sock_getsockopt(), 'optlen' is fetched the first time from userspace. > 'len < 0' is then checked. Then in condition 'SO_MEMINFO', 'optlen' is > fetched the second time from userspace without check. > > if a malicious user can change it between two fetches may cause security > problems or unexpected behaivor. > > To fix this, we need to recheck it in the second fetch. > > Signed-off-by: JingYi Hou THere is no reason to fetch len a second time, so please just remove the get_user() call here instead. Also, please format your Subject line properly with appropriate subsystem prefixes etc.
Re: [PATCH 4.19 080/118] ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
Hi! > [ Upstream commit 918bbde8085ae147a43dcb491953e0dd8f3e9d6a ] > > Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" > clock to determine if it needs to configure the IP block as operating > at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both > clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that > ratio is 1:1 which results in broken SDMA funtionality. Fix the code > to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting > incorrect clock ratio. I don't see 25aaa75df1e6 commit in stable-4.19.y branch. Is that intentional? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v6 1/4] PCI: Consider alignment of hot-added bridges when distributing available resources
Mika, this patch changes code you added in 1a5767725cec ("PCI:
Distribute available resources to hotplug-capable bridges"). Is there
any chance you could help review this?
On Wed, May 22, 2019 at 02:30:44PM +, Nicholas Johnson wrote:
> Rewrite pci_bus_distribute_available_resources to better handle bridges
> with different resource alignment requirements. Pass more details
> arguments recursively to track the resource start and end addresses
> relative to the initial hotplug bridge. This is especially useful for
> Thunderbolt with native PCI enumeration, enabling external graphics
> cards and other devices with bridge alignment higher than 0x10
> bytes.
>
> Change extend_bridge_window to resize the actual resource, rather than
> using add_list and dev_res->add_size. If an additional resource entry
> exists for the given resource, zero out the add_size field to avoid it
> interfering. Because add_size is considered optional when allocating,
> using add_size could cause issues in some cases, because successful
> resource distribution requires sizes to be guaranteed. Such cases
> include hot-adding nested hotplug bridges in one enumeration, and
> potentially others which are yet to be encountered.
>
> Signed-off-by: Nicholas Johnson
> ---
> drivers/pci/setup-bus.c | 169
> 1 file changed, 84 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 0cdd5ff38..1b5b851ca 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1835,12 +1835,10 @@ static void extend_bridge_window(struct pci_dev
> *bridge, struct resource *res,
> }
>
> static void pci_bus_distribute_available_resources(struct pci_bus *bus,
> - struct list_head *add_list,
> - resource_size_t available_io,
> - resource_size_t available_mmio,
> - resource_size_t available_mmio_pref)
> + struct list_head *add_list, struct resource io,
> + struct resource mmio, struct resource mmio_pref)
Follow the parameter indentation style of the rest of the file.
> {
> - resource_size_t remaining_io, remaining_mmio, remaining_mmio_pref;
> + resource_size_t io_per_hp, mmio_per_hp, mmio_pref_per_hp, align;
> unsigned int normal_bridges = 0, hotplug_bridges = 0;
> struct resource *io_res, *mmio_res, *mmio_pref_res;
> struct pci_dev *dev, *bridge = bus->self;
> @@ -1850,29 +1848,36 @@ static void
> pci_bus_distribute_available_resources(struct pci_bus *bus,
> mmio_pref_res = &bridge->resource[PCI_BRIDGE_RESOURCES + 2];
>
> /*
> - * Update additional resource list (add_list) to fill all the
> - * extra resource space available for this port except the space
> - * calculated in __pci_bus_size_bridges() which covers all the
> - * devices currently connected to the port and below.
> + * The alignment of this bridge is yet to be considered, hence it must
> + * be done now before extending its bridge window. A single bridge
> + * might not be able to occupy the whole parent region if the alignment
> + * differs - for example, an external GPU at the end of a Thunderbolt
> + * daisy chain.
The example seems needlessly specific. There isn't anything GPU- or
Thunderbolt-specific about this, is there?
Bridge windows can be aligned to any multiple of 1MB. But a device
BAR must be aligned on its size, so any BAR larger than 1MB should be
able to cause this, e.g.,
[mem 0x10-0x3f] (bridge A 3MB window)
[mem 0x20-0x3f] (bridge B 2MB window)
[mem 0x20-0x3f] (device 2MB BAR)
Bridge B *could* occupy the the entire 3MB parent region, but it
doesn't need to. But you say it "might not be *able* to", so maybe
you're thinking of something different?
> - extend_bridge_window(bridge, io_res, add_list, available_io);
> - extend_bridge_window(bridge, mmio_res, add_list, available_mmio);
> - extend_bridge_window(bridge, mmio_pref_res, add_list,
> - available_mmio_pref);
> + align = pci_resource_alignment(bridge, io_res);
> + if (!io_res->parent && align)
> + io.start = ALIGN(io.start, align);
> +
> + align = pci_resource_alignment(bridge, mmio_res);
> + if (!mmio_res->parent && align)
> + mmio.start = ALIGN(mmio.start, align);
> +
> + align = pci_resource_alignment(bridge, mmio_pref_res);
> + if (!mmio_pref_res->parent && align)
> + mmio_pref.start = ALIGN(mmio_pref.start, align);
>
> /*
> - * Calculate the total amount of extra resource space we can
> - * pass to bridges below this one. This is basically the
> - * extra space reduced by the minimal required space for the
> - * non-hotplug bridges.
> + * Update the resources to fill as much remai
Re: [PATCH v6 2/4] PCI: Modify extend_bridge_window() to set resource size directly
On Wed, May 22, 2019 at 02:30:57PM +, Nicholas Johnson wrote:
> Background
> ==
>
> In the current state, the PCI allocation could fail with Thunderbolt
> under certain unusual circumstances, because add_list resources are
> "optional". Guaranteed allocation requires guaranteed resource sizes.
I don't see anything here specific to Thunderbolt, so this boils down
to "allocation might fail in unusual cases". That's true, of course,
but in order to fix something we have to identify a failure that could
be avoided.
Part of the reason for "add_size" is for SR-IOV devices where we can
control the amount of space they require. The PF space is mandatory,
but we can adjust the number of VFs and the space they use.
If we don't have enough space for all the possible VFs, we'd rather
allocate space for some of them than fail completely.
We can never guarantee that there's enough space for all devices, even
if we make all the possible VF space required instead of optional.
> It is difficult to give examples of these failures - because without the
> previous patch in the series, the symptoms of the problem are hidden by
> larger problems. This patch has been split from the previous patch and
> makes little sense on its own - as it is almost impossible to see the
> effect of this patch without first fixing the problems addressed by the
> previous patch. So the evidence I put forward for making this change is
> that because add_list resources are "optional", there could be any
> number of unforeseen bugs that are yet to be encountered if the kernel
> decides not to assign all of the optional size. In kernel development,
> we should not play around with chance.
>
> Moving away from add_size also allows for use of pci=hpmemsize to assign
> resources. Previously, when using add_size and not allowing the add_size
> to shrink, it made it impossible to distribute resources. If a hotplug
> bridge has size X, and below it is some devices with non-zero size Y and
> a nested hotplug bridge of same size X, fitting X+Y into size X is
> mathematically impossible.
>
> This patch solves this by dropping add_size and giving each bridge the
> maximum size possible without failing resource assignment. Using
> pci=hpmemsize still works as pci_assign_unassigned_root_bus_resources()
> does not call pci_bus_distribute_available_resources(). At boot,
> pci_assign_unassigned_root_bus_resources() is used, instead of
> pci_bridge_distribute_available_resources().
>
> By allowing to use pci=hpmemsize, it removes the reliance on the
> firmware to declare the window resources under the root port, and could
> pay off in the future with USB4 (which is backward-compatible to
> Thunderbolt devices, and not specific to Intel systems). Users of
> Thunderbolt hardware on unsupported systems will be able to specify the
> resources in the kernel parameters. Users of official systems will be
> able to override the default firmware window sizes to allocate much
> larger resource sizes, potentially enabling Thunderbolt support for
> devices with massive BARs (with a few other problems solved by later
> patches in this series).
>
> Patch notes
> ==
>
> Modify extend_bridge_window() to remove the resource from add_list and
> change the resource size directly.
>
> Modify extend_bridge_window() to reset resources that are being assigned
> zero size. This is required to prevent the bridge not being enabled due
> to resources with zero size. This is a direct requirement to prevent the
> change away from using add_list from introducing a regression - because
> before, it was not possible to end up with zero size.
>
> Signed-off-by: Nicholas Johnson
> ---
> drivers/pci/setup-bus.c | 42 ++---
> 1 file changed, 27 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 1b5b851ca..5675254fa 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1810,28 +1810,40 @@ void __init pci_assign_unassigned_resources(void)
> }
>
> static void extend_bridge_window(struct pci_dev *bridge, struct resource
> *res,
> - struct list_head *add_list,
> - resource_size_t available)
> + struct list_head *add_list, resource_size_t new_size)
Follow parameter indentation style of the rest of the file. It's OK if it
requires another line.
> {
> - struct pci_dev_resource *dev_res;
> + resource_size_t add_size;
>
> if (res->parent)
> return;
>
> - if (resource_size(res) >= available)
> - return;
> -
> - dev_res = res_to_dev_res(add_list, res);
> - if (!dev_res)
> - return;
> + if (new_size >= resource_size(res)) {
> + add_size = new_size - resource_size(res);
>
Re: [PATCH v6 0/4] PCI: Patch series to support Thunderbolt without any BIOS support
[+cc Ben, Logan] Ben, Logan, since you're looking at the resource code, maybe you'd be interested in this as well? On Wed, May 22, 2019 at 02:30:30PM +, Nicholas Johnson wrote: > Rebase patches to apply cleanly to 5.2-rc1 source. Remove patch for > comment style cleanup as this has already been applied. Thanks for rebasing these. They do apply cleanly, but they seem to be base64-encoded MIME attachments, and I don't know how to make mutt extract them easily. I had to save each patch attachment individually, apply it, insert the commit log manually, etc. Is there any chance you could send the next series as plain-text patches? That would be a lot easier for me. > Anybody interested in testing, you can do so with: > > a) Intel system with Thunderbolt 3 and native enumeration. The Gigabyte > Z390 Designare is one of the most perfect for this that I have never had > the opportunity to use - it does not even have the option for BIOS > assisted enumeration present in the BIOS. > > b) Any system with PCIe and the Gigabyte GC-TITAN RIDGE add-in card, > jump the header as described and use kernel parameters like: > > pci=assign-busses,hpbussize=0x33,realloc,hpmemsize=128M,hpmemprefsize=1G,nocrs > > pcie_ports=native > > [optional] pci.dyndbg > > ___ > __/ \__ > |o o o o o| When looking into the receptacle on back of PCIe card. > |_| Jump pins 3 and 5. > > 1 2 3 4 5 > > The Intel system is nice in that it should just work. The add-in card > setup is nice in that you can go nuts and assign copious amounts of > MMIO_PREF - can anybody show a Xeon Phi coprocessor with 16G BAR working > in an eGPU enclosure with these patches? > > However, if you specify the above kernel parameters on the Intel system, > you should be able to override it to allocate more space. > > Nicholas Johnson (4): > PCI: Consider alignment of hot-added bridges when distributing > available resources > PCI: Modify extend_bridge_window() to set resource size directly > PCI: Fix bug resulting in double hpmemsize being assigned to MMIO > window > PCI: Add pci=hpmemprefsize parameter to set MMIO_PREF size > independently > > .../admin-guide/kernel-parameters.txt | 7 +- > drivers/pci/pci.c | 18 +- > drivers/pci/setup-bus.c | 265 ++ > include/linux/pci.h | 3 +- > 4 files changed, 167 insertions(+), 126 deletions(-) > > -- > 2.20.1 >
Re: [PATCH] staging: rtl8723bs: Resolve checkpatch error "that open brace { should be on the previous line" in the rtl8723bs driver
On Thu, Jun 13, 2019 at 07:12:10PM -0700, Shobhit Kukreti wrote:
> Cleaned up the code from the following files to get rid of
> check patch error "that open brace { should be on the previous line"
>
> drivers/staging/rtl8723bs/os_dep/mlme_linux.c
> drivers/staging/rtl8723bs/os_dep/recv_linux.c
> drivers/staging/rtl8723bs/os_dep/rtw_proc.c
> drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> drivers/staging/rtl8723bs/os_dep/sdio_ops_linux.c
>
> Signed-off-by: Shobhit Kukreti
> ---
> drivers/staging/rtl8723bs/os_dep/mlme_linux.c | 14 ++---
> drivers/staging/rtl8723bs/os_dep/recv_linux.c | 76
> ---
> drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 6 +-
> drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 15 ++---
> drivers/staging/rtl8723bs/os_dep/sdio_ops_linux.c | 24 +++
> 5 files changed, 47 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
> b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
> index aa2499f..6799ed4 100644
> --- a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
> +++ b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
> @@ -46,8 +46,7 @@ void rtw_os_indicate_connect(struct adapter *adapter)
> struct mlme_priv *pmlmepriv = &(adapter->mlmepriv);
>
> if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
> - (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true))
> - {
> + (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)) {
> rtw_cfg80211_ibss_indicate_connect(adapter);
> }
> else
> @@ -77,8 +76,8 @@ void rtw_reset_securitypriv(struct adapter *adapter)
>
> spin_lock_bh(&adapter->security_key_mutex);
>
> - if (adapter->securitypriv.dot11AuthAlgrthm == dot11AuthAlgrthm_8021X)/*
> 802.1x */
> - {
> + if (adapter->securitypriv.dot11AuthAlgrthm == dot11AuthAlgrthm_8021X) {
> /* 802.1x */
> +
> /* Added by Albert 2009/02/18 */
> /* We have to backup the PMK information for WiFi PMK Caching
> test item. */
> /* */
> @@ -106,8 +105,8 @@ void rtw_reset_securitypriv(struct adapter *adapter)
> adapter->securitypriv.ndisencryptstatus = Ndis802_11WEPDisabled;
>
> }
> - else /* reset values in securitypriv */
> - {
> + else { /* reset values in securitypriv */
> +
Trailing whitespace?
The comment should be on a new line, not on the same line.
thanks,
greg k-h
Re: [PATCH] staging: rtl8723bs: hal: Remove return type of initrecvbuf
On Sat, Jun 15, 2019 at 10:52:20PM +0530, Hariprasad Kelam wrote: > change return of initrecvbuf from s32 to void. As this function always > returns SUCCESS . > > fix checkpatch warning "Comparison to false is error prone" That is doing multiple things in the same patch, please break this up :(
Re: general protection fault in oom_unkillable_task
On Sat, Jun 15, 2019 at 9:49 AM Tetsuo Handa wrote: > > On 2019/06/16 1:11, Shakeel Butt wrote: > > On Sat, Jun 15, 2019 at 6:50 AM Michal Hocko wrote: > >> diff --git a/mm/oom_kill.c b/mm/oom_kill.c > >> index 5a58778c91d4..43eb479a5dc7 100644 > >> --- a/mm/oom_kill.c > >> +++ b/mm/oom_kill.c > >> @@ -161,8 +161,8 @@ static bool oom_unkillable_task(struct task_struct *p, > >> return true; > >> > >> /* When mem_cgroup_out_of_memory() and p is not member of the > >> group */ > >> - if (memcg && !task_in_mem_cgroup(p, memcg)) > >> - return true; > >> + if (memcg) > >> + return false; > > > > This will break the dump_tasks() usage of oom_unkillable_task(). We > > can change dump_tasks() to traverse processes like > > mem_cgroup_scan_tasks() for memcg OOMs. > > While dump_tasks() traverses only each thread group, mem_cgroup_scan_tasks() > traverses each thread. I think mem_cgroup_scan_tasks() traversing threads is not intentional and css_task_iter_start in it should use CSS_TASK_ITER_PROCS as the oom killer only cares about the processes or more specifically mm_struct (though two different thread groups can have same mm_struct but that is fine). > To avoid printk()ing all threads in a thread group, > moving that check to > > if (memcg && !task_in_mem_cgroup(p, memcg)) > continue; > > in dump_tasks() is better? > > > > >> > >> /* p may not have freeable memory in nodemask */ > >> if (!has_intersects_mems_allowed(p, nodemask)) >
RE: [PATCH] scsi: storvsc: Add ability to change scsi queue depth
From: Branden Bonaby Sent: Friday, June 14, 2019
4:48 PM
>
> Adding functionality to allow the SCSI queue depth to be changed,
> by utilizing the "scsi_change_queue_depth" function.
>
> Signed-off-by: Branden Bonaby
> ---
> drivers/scsi/storvsc_drv.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 8472de1007ff..719ca9906fc2 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -387,6 +387,7 @@ enum storvsc_request_type {
>
> static int storvsc_ringbuffer_size = (128 * 1024);
> static u32 max_outstanding_req_per_channel;
> +static int storvsc_change_queue_depth(struct scsi_device *sdev, int
> queue_depth);
>
> static int storvsc_vcpus_per_sub_channel = 4;
>
> @@ -1711,6 +1712,7 @@ static struct scsi_host_template scsi_driver = {
> .dma_boundary = PAGE_SIZE-1,
> .no_write_same =1,
> .track_queue_depth =1,
> + .change_queue_depth = storvsc_change_queue_depth,
> };
>
> enum {
> @@ -1917,6 +1919,15 @@ static int storvsc_probe(struct hv_device *device,
> return ret;
> }
>
> +/* Change a scsi target's queue depth */
> +static int storvsc_change_queue_depth(struct scsi_device *sdev, int
> queue_depth)
> +{
> + if (queue_depth > scsi_driver.can_queue){
> + queue_depth = scsi_driver.can_queue;
> + }
> + return scsi_change_queue_depth(sdev, queue_depth);
> +}
> +
> static int storvsc_remove(struct hv_device *dev)
> {
> struct storvsc_device *stor_device = hv_get_drvdata(dev);
> --
> 2.17.1
Reviewed-by: Michael Kelley
Re: [GIT PULL] platform-drivers-x86 for 5.2-3
The pull request you sent on Sat, 15 Jun 2019 20:15:15 +0300: > git://git.infradead.org/linux-platform-drivers-x86.git > tags/platform-drivers-x86-v5.2-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e01e060fe00dca46959bbf055b75d9f57ba6e7be Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] tracing: A few fixes for 5.2-rc4
The pull request you sent on Sat, 15 Jun 2019 08:49:03 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > trace-v5.2-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6a71398c6aead255efe445ea96d52b33f0d5f0b2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-4 tag
The pull request you sent on Sat, 15 Jun 2019 23:34:46 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.2-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fa1827d7731ac24f44309ddc2ca806650912bf0e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] USB fixes for 5.2-rc5
The pull request you sent on Sat, 15 Jun 2019 17:48:45 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.2-rc5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ff39074b1d4e727c299ccfd1588f9cca17a59c86 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Greetings My Dear, Please I Need Your Help.
Greetings My Dear, I sent this mail praying it will found you in a good condition of health, since I myself are in a very critical health condition in which I sleep every night without knowing if I may be alive to see the next day. I am Mrs. Monika John Carlsen from Denmark wife of late Mr John Carlsen, a widow suffering from long time illness. I have some funds I inherited from my late husband, the sum of (eleven million dollars) my Doctor told me recently that I have serious sickness which is cancer problem. What disturbs me most is my stroke sickness. Having known my condition, I decided to donate this fund to a good person that will utilize it the way i am going to instruct herein. I need a very honest and God fearing person who can claim this money and use it for Charity works, for orphanages, widows and also build schools for less privileges that will be named after my late husband if possible and to promote the word of God and the effort that the house of God is maintained. I do not want a situation where this money will be used in an ungodly manner. That's why I'm taking this decision. I'm not afraid of death so I know where I'm going. I accept this decision because I do not have any child who will inherit this money after I die. Please I want your sincerely and urgent answer to know if you will be able to execute this project, and I will give you more information on how the fund will be transferred to your bank account. I am waiting for your reply. May God Bless you, Mrs. Monika John Carlsen
[PATCH] staging: rtl8723bs: hal: Remove return type of initrecvbuf
change return of initrecvbuf from s32 to void. As this function always
returns SUCCESS .
fix checkpatch warning "Comparison to false is error prone"
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
index b269de5..e23b39a 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
@@ -10,14 +10,12 @@
#include
#include
-static s32 initrecvbuf(struct recv_buf *precvbuf, struct adapter *padapter)
+static void initrecvbuf(struct recv_buf *precvbuf, struct adapter *padapter)
{
INIT_LIST_HEAD(&precvbuf->list);
spin_lock_init(&precvbuf->recvbuf_lock);
precvbuf->adapter = padapter;
-
- return _SUCCESS;
}
static void update_recvframe_attrib(struct adapter *padapter,
@@ -177,7 +175,7 @@ static void rtl8723bs_c2h_packet_handler(struct adapter
*padapter,
res = rtw_c2h_packet_wk_cmd(padapter, tmp, length);
- if (res == false)
+ if (!res)
kfree(tmp);
/* DBG_871X("-%s res(%d)\n", __func__, res); */
@@ -435,9 +433,7 @@ s32 rtl8723bs_init_recv_priv(struct adapter *padapter)
/* init each recv buffer */
precvbuf = (struct recv_buf *)precvpriv->precv_buf;
for (i = 0; i < NR_RECVBUFF; i++) {
- res = initrecvbuf(precvbuf, padapter);
- if (res == _FAIL)
- break;
+ initrecvbuf(precvbuf, padapter);
if (!precvbuf->pskb) {
SIZE_PTR tmpaddr = 0;
--
2.7.4
[PATCH] regulator: twl: mark vdd1/2 as continuous on twl4030
_opp_supported_by_regulators() wrongly ignored errors from
regulator_is_supported_voltage(), so it considered errors as
success. Since
commit 498209445124 ("regulator: core: simplify return value on
suported_voltage")
regulator_is_supported_voltage() returns a real boolean, so
errors make _opp_supported_by_regulators() return false.
The VDD1/VDD2 regulators on twl4030 are neither defined with
voltage lists nor with the continuous flag set, so
regulator_is_supported_voltage() returns false and an error
before above mentioned commit (which was considered success)
The result is that after the above mentioned commit cpufreq
does not work properly e.g. dm3730.
[2.490997] core: _opp_supported_by_regulators: OPP minuV: 1012500 maxuV:
1012500, not supported by regulator
[2.501617] cpu cpu0: _opp_add: OPP not supported by regulators (3)
[2.509246] core: _opp_supported_by_regulators: OPP minuV: 120 maxuV:
120, not supported by regulator
[2.519775] cpu cpu0: _opp_add: OPP not supported by regulators (6)
[2.527313] core: _opp_supported_by_regulators: OPP minuV: 1325000 maxuV:
1325000, not supported by regulator
[2.537750] cpu cpu0: _opp_add: OPP not supported by regulators (8)
The patch fixes declaration of VDD1/2 regulators.
Fixes: 498209445124 ("regulator: core: simplify return value on
suported_voltage")
Signed-off-by: Andreas Kemnade
---
drivers/regulator/twl-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 6fa15b2d6fb3..f7bfdf53701d 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -478,6 +478,7 @@ static const struct twlreg_info TWL4030_INFO_##label = { \
.type = REGULATOR_VOLTAGE, \
.owner = THIS_MODULE, \
.enable_time = turnon_delay, \
+ .continuous_voltage_range = true, \
.of_map_mode = twl4030reg_map_mode, \
}, \
}
--
2.20.1
[GIT PULL] platform-drivers-x86 for 5.2-3
Hi Linus, Bunch of few fixes for v5.2 cycle, no merge conflicts observed. Thanks, With Best Regards, Andy Shevchenko The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) are available in the Git repository at: git://git.infradead.org/linux-platform-drivers-x86.git tags/platform-drivers-x86-v5.2-3 for you to fetch changes up to 8c2eb7b6468ad4aa5600aed01aa0715f921a3f8b: platform/mellanox: mlxreg-hotplug: Add devm_free_irq call to remove flow (2019-06-12 11:49:20 +0300) platform-drivers-x86 for v5.2-3 Couple of driver enumeration issues have been fixed for Mellanox. ASUS laptops got a regression with backlight, which is fixed now. Dell computers got a wrong mode (tablet versus laptop) after resume, that is fixed now. The following is an automated git shortlog grouped by driver: asus-wmi: - Only Tell EC the OS will handle display hotkeys from asus_nb_wmi intel-vbtn: - Report switch events when event wakes device mlx-platform: - Fix parent device in i2c-mux-reg device registration platform/mellanox: - mlxreg-hotplug: Add devm_free_irq call to remove flow Hans de Goede (1): platform/x86: asus-wmi: Only Tell EC the OS will handle display hotkeys from asus_nb_wmi Mathew King (1): platform/x86: intel-vbtn: Report switch events when event wakes device Vadim Pasternak (2): platform/x86: mlx-platform: Fix parent device in i2c-mux-reg device registration platform/mellanox: mlxreg-hotplug: Add devm_free_irq call to remove flow drivers/platform/mellanox/mlxreg-hotplug.c | 1 + drivers/platform/x86/asus-nb-wmi.c | 8 drivers/platform/x86/asus-wmi.c| 2 +- drivers/platform/x86/asus-wmi.h| 1 + drivers/platform/x86/intel-vbtn.c | 16 ++-- drivers/platform/x86/mlx-platform.c| 2 +- 6 files changed, 26 insertions(+), 4 deletions(-) -- With Best Regards, Andy Shevchenko
Dear Friend,
-- Dear Friend, I am Mrs Alice Johnson.am sending you this brief letter to solicit your partnership to transfer $18.5 million US Dollars.I shall send you more information and procedures when I receive positive response from you. please send me a message in my Email box (mrsalicejohns...@gmail.com) as i wait to hear from you. Best regard Mrs Alice Johnson --
RE: [PATCH net] hvsock: fix epollout hang from race condition
> From: Sunil Muthuswamy > Sent: Saturday, June 15, 2019 12:23 AM > To: Dexuan Cui ; David Miller > > ... > > It looks a simple inline assembly code can confuse gcc. I'm not sure if I > > should > > report a bug for gcc... > > > > I posted a patch to suppress these bogus warnings just now. The Subject is: > > > > [PATCH net] hv_sock: Suppress bogus "may be used uninitialized" warnings David, as I described, these warnings are spurious and can be safely ignored. Please consider not applying my two-line patch to avoid merge conflict with Sunil's another patch in net-next.git. > Yes, these warnings are not specific to this patch. And, additionally these > should already addressed in the commit ... > I was trying to avoid making the same changes here to avoid merge > conflicts when 'net-next' merges with 'net' next. Yeah, I agree. Thanks, -- Dexuan
Re: general protection fault in oom_unkillable_task
On 2019/06/16 1:11, Shakeel Butt wrote: > On Sat, Jun 15, 2019 at 6:50 AM Michal Hocko wrote: >> diff --git a/mm/oom_kill.c b/mm/oom_kill.c >> index 5a58778c91d4..43eb479a5dc7 100644 >> --- a/mm/oom_kill.c >> +++ b/mm/oom_kill.c >> @@ -161,8 +161,8 @@ static bool oom_unkillable_task(struct task_struct *p, >> return true; >> >> /* When mem_cgroup_out_of_memory() and p is not member of the group >> */ >> - if (memcg && !task_in_mem_cgroup(p, memcg)) >> - return true; >> + if (memcg) >> + return false; > > This will break the dump_tasks() usage of oom_unkillable_task(). We > can change dump_tasks() to traverse processes like > mem_cgroup_scan_tasks() for memcg OOMs. While dump_tasks() traverses only each thread group, mem_cgroup_scan_tasks() traverses each thread. To avoid printk()ing all threads in a thread group, moving that check to if (memcg && !task_in_mem_cgroup(p, memcg)) continue; in dump_tasks() is better? > >> >> /* p may not have freeable memory in nodemask */ >> if (!has_intersects_mems_allowed(p, nodemask))
[PATCH v2] ARM: dts: qcom: ipq4019: fix high resolution timer
From: Abhishek Sahu
Cherry-picked from CAF QSDK repo with Change-Id
I7c00b3c74d97c2a30ac9f05e18b511a0550fd459.
Original commit message:
The kernel is failing in switching the timer for high resolution
mode and clock source operates in 10ms resolution. The always-on
property needs to be given for timer device tree node to make
clock source working in 1ns resolution.
Signed-off-by: Abhishek Sahu
Signed-off-by: Pavel Kubelun
Signed-off-by: Christian Lamparter
---
v2: fixed subject [Abhishek Sahu is bouncing]
---
arch/arm/boot/dts/qcom-ipq4019.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index bbcb7db810f7..0e3e79442c50 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -169,6 +169,7 @@
<1 4 0xf08>,
<1 1 0xf08>;
clock-frequency = <4800>;
+ always-on;
};
soc {
--
2.20.1
Re: [PATCH RFC] mm: memcontrol: add cgroup v2 interface to read memory watermark
On Sat, Jun 15, 2019 at 04:20:04PM +0800, Xi Ruoyao wrote: > Introduce a control file memory.watermark showing the watermark > consumption of the cgroup and its descendants, in bytes. > > Signed-off-by: Xi Ruoyao Memory usage w/o pressure metric isn't all that useful and reporting just the historical maximum of memory.current can be outright misleading. The use case of determining maximum amount of required memory is legit but it needs to maintain sustained positive pressure while taking measurements. There are efforts on this front, so let's not merge this one for now. Nacked-by: Tejun Heo Thanks. -- tejun
Re: general protection fault in oom_unkillable_task
On Sat, Jun 15, 2019 at 6:50 AM Michal Hocko wrote: > > On Fri 14-06-19 20:15:31, Shakeel Butt wrote: > > On Fri, Jun 14, 2019 at 6:08 PM syzbot > > wrote: > > > > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:3f310e51 Add linux-next specific files for 20190607 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15ab8771a0 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=5d176e1849bbc45 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=d0fc9d3c166bc5e4a94b > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+d0fc9d3c166bc5e4a...@syzkaller.appspotmail.com > > > > > > kasan: CONFIG_KASAN_INLINE enabled > > > kasan: GPF could be caused by NULL-ptr deref or user memory access > > > general protection fault: [#1] PREEMPT SMP KASAN > > > CPU: 0 PID: 28426 Comm: syz-executor.5 Not tainted 5.2.0-rc3-next-20190607 > > > #11 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > > Google 01/01/2011 > > > RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline] > > > RIP: 0010:has_intersects_mems_allowed mm/oom_kill.c:84 [inline] > > > > It seems like oom_unkillable_task() is broken for memcg OOMs. It > > should not be calling has_intersects_mems_allowed() for memcg OOMs. > > You are right. It doesn't really make much sense to check for the NUMA > policy/cpusets when the memcg oom is NUMA agnostic. Now that I am > looking at the code then I am really wondering why do we even call > oom_unkillable_task from oom_badness. proc_oom_score shouldn't care > about NUMA either. > > In other words the following should fix this unless I am missing > something (task_in_mem_cgroup seems to be a relict from before the group > oom handling). But please note that I am still not fully operation and > laying in the bed. > Yes, we need something like this but not exactly. > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 5a58778c91d4..43eb479a5dc7 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -161,8 +161,8 @@ static bool oom_unkillable_task(struct task_struct *p, > return true; > > /* When mem_cgroup_out_of_memory() and p is not member of the group */ > - if (memcg && !task_in_mem_cgroup(p, memcg)) > - return true; > + if (memcg) > + return false; This will break the dump_tasks() usage of oom_unkillable_task(). We can change dump_tasks() to traverse processes like mem_cgroup_scan_tasks() for memcg OOMs. > > /* p may not have freeable memory in nodemask */ > if (!has_intersects_mems_allowed(p, nodemask)) > @@ -318,7 +318,7 @@ static int oom_evaluate_task(struct task_struct *task, > void *arg) > struct oom_control *oc = arg; > unsigned long points; > > - if (oom_unkillable_task(task, NULL, oc->nodemask)) > + if (oom_unkillable_task(task, oc->memcg, oc->nodemask)) > goto next; > > -- > Michal Hocko > SUSE Labs
Re: [PATCH] memcg: Ignore unprotected parent in mem_cgroup_protected()
Hi Xunlei,
Xunlei Pang writes:
Currently memory.min|low implementation requires the whole
hierarchy has the settings, otherwise the protection will
be broken.
Our hierarchy is kind of like(memory.min value in brackets),
root
|
docker(0)
/\
c1(max) c2(0)
Note that "docker" doesn't set memory.min. When kswapd runs,
mem_cgroup_protected() returns "0" emin for "c1" due to "0"
@parent_emin of "docker", as a result "c1" gets reclaimed.
But it's hard to maintain parent's "memory.min" when there're
uncertain protected children because only some important types
of containers need the protection. Further, control tasks
belonging to parent constantly reproduce trivial memory which
should not be protected at all. It makes sense to ignore
unprotected parent in this scenario to achieve the flexibility.
I'm really confused by this, why don't you just set memory.{min,low} in the
docker cgroup and only propagate it to the children that want it?
If you only want some children to have the protection, only request it in those
children, or create an additional intermediate layer of the cgroup hierarchy
with protections further limited if you don't trust the task to request the
right amount.
Breaking the requirement for hierarchical propagation of protections seems like
a really questionable API change, not least because it makes it harder to set
systemwide policies about the constraints of protections within a subtree.
[PATCH] dmaengine: fix semicolon.cocci warnings
From: kbuild test robot
drivers/dma/dw-edma/dw-edma-core.c:617:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
CC: Gustavo Pimentel
Signed-off-by: kbuild test robot
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: f4788d37bc84e27ac9370be252afb451bf6ef718
commit: e63d79d1ffcd2201a2dbff1d7a1184b8f3ec74cf [5032/6646] dmaengine: Add
Synopsys eDMA IP core driver
dw-edma-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -614,7 +614,7 @@ static void dw_edma_free_chan_resources(
return;
cpu_relax();
- };
+ }
pm_runtime_put(chan->chip->dev);
}
Re: [PATCH] media: v4l2-ioctl: clear fields in s_parm
On Wed, May 29, 2019 at 12:32:47PM +0100, Naresh Kamboju wrote: > From: Hans Verkuil > > commit 8a7c5594c02022ca5fa7fb603e11b3e1feb76ed5 upstream. > > Zero the reserved capture/output array. > > Zero the extendedmode (it is never used in drivers). > > Clear all flags in capture/outputmode except for V4L2_MODE_HIGHQUALITY, > as that is the only valid flag. > > Cc: # v4.9 v4.14 > Signed-off-by: Hans Verkuil > Reviewed-by: Hans de Goede > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/v4l2-core/v4l2-ioctl.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) Now queued up, thanks. greg k-h
Re: general protection fault in oom_unkillable_task
On 2019/06/15 10:10, Tetsuo Handa wrote: > I'm not sure this patch is correct/safe. Can you try memcg OOM torture > test (including memcg group OOM killing enabled) with this patch applied? Well, I guess this patch was wrong. The ordering of removing threads does not matter as long as we start traversing via signal_struct. The reason why crashed at for_each_thread() is unknown...
Re: [PATCH] psi: Don't account force reclaim as memory pressure
Hi Xunlei, Xunlei Pang writes: There're several cases like resize and force_empty that don't need to account to psi, otherwise is misleading. I'm afraid I'm quite confused by this patch. Why do you think accounting for force reclaim in PSI is misleading? I completely expect that force reclaim should still be accounted for as memory pressure, can you present some reason why it shouldn't be?
Re: [PATCH 08/10] blkcg: implement blk-ioweight
Hello, On Fri, Jun 14, 2019 at 10:50:34PM +0200, Toke Høiland-Jørgensen wrote: > > Within a single cgroup, the IOs are FIFO. When an IO has enough vtime > > credit, it just passes through. When it doesn't, it always waits > > behind any other IOs which are already waiting. > > OK. Is there any fundamental reason why requests from individual > processes could not be interleaved? Or does it just not give the same > benefits in an IO request context as it does for network packets? I don't think there's any fundamental reason we can't. Currently, it just isn't doing anything it doesn't have to do while preserving the existing ordering. One different from networking could be that there's more sharing - buffered writes are attributed to the whole domain (either system or cgroup) rather than individual tasks, so the ownership of IOs gets a bit mushy beyond resource domain level. Thanks. -- tejun
[PATCH] ARM: dts: qcom: ipq4019: directly define voltage per opp
From: Pavel Kubelun
This should align opp table with what it was before converting to OPP v2.
Signed-off-by: Pavel Kubelun
Signed-off-by: Christian Lamparter
---
arch/arm/boot/dts/qcom-ipq4019.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index c7fa9f61e1f1..0e3e79442c50 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -111,20 +111,24 @@
opp-4800 {
opp-hz = /bits/ 64 <4800>;
+ opp-microvolt = <110>;
clock-latency-ns = <256000>;
};
opp-2 {
opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <110>;
clock-latency-ns = <256000>;
};
opp-5 {
opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <110>;
clock-latency-ns = <256000>;
};
opp-71600 {
opp-hz = /bits/ 64 <71600>;
+ opp-microvolt = <110>;
clock-latency-ns = <256000>;
- };
+ };
};
memory {
--
2.20.1
[PATCH] ipq40xx: fix high resolution timer
From: Abhishek Sahu
Cherry-picked from CAF QSDK repo with Change-Id
I7c00b3c74d97c2a30ac9f05e18b511a0550fd459.
Original commit message:
The kernel is failing in switching the timer for high resolution
mode and clock source operates in 10ms resolution. The always-on
property needs to be given for timer device tree node to make
clock source working in 1ns resolution.
Signed-off-by: Abhishek Sahu
Signed-off-by: Pavel Kubelun
Signed-off-by: Christian Lamparter
---
arch/arm/boot/dts/qcom-ipq4019.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index 83eb5c29274b..c7fa9f61e1f1 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -165,6 +165,7 @@
<1 4 0xf08>,
<1 1 0xf08>;
clock-frequency = <4800>;
+ always-on;
};
soc {
--
2.20.1
[GIT PULL] USB fixes for 5.2-rc5
The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a: Linux 5.2-rc3 (2019-06-02 13:55:33 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.2-rc5 for you to fetch changes up to 5f54a85db5df67df8161739a4b2f9c2b7ab219fe: usb: typec: Make sure an alt mode exist before getting its partner (2019-06-12 17:13:02 +0200) USB fixes for 5.2-rc5 Here are some small USB driver fixes for 5.2-rc5 Nothing major, just some small gadget fixes, usb-serial new device ids, a few new quirks, and some small fixes for some regressions that have been found after the big 5.2-rc1 merge. All of these have been in linux-next for a while with no reported issues. Signed-off-by: Greg Kroah-Hartman Alexandre Belloni (1): usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC Andrey Smirnov (1): usb: phy: mxs: Disable external charger detect in mxs_phy_hw_init() Andrzej Pietrasiewicz (1): usb: gadget: dwc2: fix zlp handling Chris Packham (1): USB: serial: pl2303: add Allied Telesis VT-Kit3 Daniele Palmas (1): USB: serial: option: add Telit 0x1260 and 0x1261 compositions Douglas Anderson (1): usb: dwc2: host: Fix wMaxPacketSize handling (fix webcam regression) Greg Kroah-Hartman (2): Merge tag 'fixes-for-v5.2-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'usb-serial-5.2-rc5' of https://git.kernel.org/.../johan/usb-serial into usb-linus Gustavo A. R. Silva (1): usb: typec: ucsi: ccg: fix memory leak in do_flash Heikki Krogerus (1): usb: typec: Make sure an alt mode exist before getting its partner Jörgen Storvist (1): USB: serial: option: add support for Simcom SIM7500/SIM7600 RNDIS mode Kai-Heng Feng (1): USB: usb-storage: Add new ID to ums-realtek Marco Zatta (1): USB: Fix chipmunk-like voice when using Logitech C270 for recording audio. Martin Schiller (1): usb: dwc2: Fix DMA cache alignment issues Minas Harutyunyan (1): usb: dwc2: Set actual frame number for completed ISOC transfer for none DDMA Wei Yongjun (1): usb: gadget: udc: lpc32xx: fix return value check in lpc32xx_udc_probe() Young Xiao (1): usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i] drivers/usb/core/quirks.c | 3 +++ drivers/usb/dwc2/gadget.c | 24 ++--- drivers/usb/dwc2/hcd.c| 39 +-- drivers/usb/dwc2/hcd.h| 20 ++ drivers/usb/dwc2/hcd_intr.c | 5 +++-- drivers/usb/dwc2/hcd_queue.c | 10 + drivers/usb/gadget/udc/fusb300_udc.c | 5 + drivers/usb/gadget/udc/lpc32xx_udc.c | 7 +++ drivers/usb/phy/phy-mxs-usb.c | 14 + drivers/usb/serial/option.c | 6 ++ drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 3 +++ drivers/usb/storage/unusual_realtek.h | 5 + drivers/usb/typec/bus.c | 2 +- drivers/usb/typec/ucsi/ucsi_ccg.c | 6 -- 15 files changed, 105 insertions(+), 45 deletions(-)
Re: [PATCH v2] pwm: rockchip: Use of_clk_get_parent_count()
Am Montag, 27. Mai 2019, 15:55:09 CEST schrieb Kefeng Wang: > Use of_clk_get_parent_count() instead of open coding. > > Cc: Thierry Reding > Cc: Heiko Stuebner > Signed-off-by: Kefeng Wang Reviewed-by: Heiko Stuebner > --- > v2: > - add include > drivers/pwm/pwm-rockchip.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c > index 4d99d468df09..d8f23daca290 100644 > --- a/drivers/pwm/pwm-rockchip.c > +++ b/drivers/pwm/pwm-rockchip.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -329,8 +330,8 @@ static int rockchip_pwm_probe(struct platform_device > *pdev) > } > } > > - count = of_count_phandle_with_args(pdev->dev.of_node, > -"clocks", "#clock-cells"); > + count = of_clk_get_parent_count(pdev->dev.of_node); > + > if (count == 2) > pc->pclk = devm_clk_get(&pdev->dev, "pclk"); > else >
Re: Linux 5.1.10
Thanks, a bunch Greg! :) On 17:09 Sat 15 Jun , Greg KH wrote: I'm announcing the release of the 5.1.10 kernel. All users of the 5.1 kernel series must upgrade. The updated 5.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.1.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/input/touchscreen/goodix.txt |1 Makefile |2 arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 arch/arm/boot/dts/imx50.dtsi |2 arch/arm/boot/dts/imx51.dtsi |2 arch/arm/boot/dts/imx53.dtsi |2 arch/arm/boot/dts/imx6qdl.dtsi |2 arch/arm/boot/dts/imx6sl.dtsi |2 arch/arm/boot/dts/imx6sll.dtsi |2 arch/arm/boot/dts/imx6sx.dtsi |2 arch/arm/boot/dts/imx6ul.dtsi |2 arch/arm/boot/dts/imx7s.dtsi |4 arch/arm/include/asm/hardirq.h |1 arch/arm/kernel/smp.c |6 arch/arm/mach-exynos/suspend.c | 19 + arch/arm/mach-omap2/pm33xx-core.c |8 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c |6 arch/arm64/boot/dts/freescale/imx8mq.dtsi |2 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 28 +- arch/arm64/configs/defconfig |6 arch/mips/kernel/prom.c| 14 + arch/powerpc/include/asm/drmem.h | 21 + arch/powerpc/mm/drmem.c|6 arch/powerpc/platforms/pseries/hotplug-memory.c| 17 - arch/um/kernel/time.c |2 arch/x86/events/intel/core.c |2 arch/x86/pci/irq.c | 10 block/bfq-iosched.c|2 block/blk-core.c |1 block/blk-mq.c |2 drivers/clk/rockchip/clk-rk3288.c | 11 drivers/dma/idma64.c |6 drivers/dma/idma64.h |2 drivers/edac/Kconfig |4 drivers/gpio/gpio-omap.c | 53 ++-- drivers/gpio/gpio-vf610.c | 26 -- drivers/gpu/drm/amd/display/dc/core/dc_link.c |9 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c |6 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c |2 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |6 drivers/gpu/drm/drm_ioctl.c| 20 - drivers/gpu/drm/msm/msm_gem.c |3 drivers/gpu/drm/nouveau/Kconfig| 13 - drivers/gpu/drm/nouveau/dispnv50/disp.h|1 drivers/gpu/drm/nouveau/dispnv50/head.c|3 drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c|1 drivers/gpu/drm/nouveau/dispnv50/wndw.c|2 drivers/gpu/drm/nouveau/nouveau_drm.c |7 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 11 drivers/gpu/drm/pl111/pl111_display.c |5 drivers/input/touchscreen/goodix.c |2 drivers/iommu/arm-smmu-v3.c| 10 drivers/iommu/intel-iommu.c| 19 + drivers/mailbox/stm32-ipcc.c | 13 - drivers/media/platform/atmel/atmel-isc.c |8 drivers/media/v4l2-core/v4l2-ctrls.c | 18 - drivers/media/v4l2-core/v4l2-fwnode.c |6 drivers/mfd/intel-lpss.c |3 drivers/mfd/tps65912-spi.c |1 drivers/mfd/twl6040.c | 13 - drivers/misc/pci_endpoint_test.c |1 drivers/mmc/host/mmci.c|5 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c|7 drivers/net/ethernet/intel/i40e/i40e_main.c|3 drivers
[PATCH 2/3] clk: rockchip: add watchdog pclk on rk3328
The watchdog pclk is controlled from the secure GRF but we still
want to mention it explicitly to not use arbitary parent clocks
in the devicetree wdt node, so add a SGRF_GATE for it.
Suggested-by: Leonidas P. Papadakos
Signed-off-by: Heiko Stuebner
---
drivers/clk/rockchip/clk-rk3328.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3328.c
b/drivers/clk/rockchip/clk-rk3328.c
index 076b9777a955..c186a1985bf4 100644
--- a/drivers/clk/rockchip/clk-rk3328.c
+++ b/drivers/clk/rockchip/clk-rk3328.c
@@ -791,6 +791,9 @@ static struct rockchip_clk_branch rk3328_clk_branches[]
__initdata = {
GATE(PCLK_SARADC, "pclk_saradc", "pclk_bus", 0, RK3328_CLKGATE_CON(17),
15, GFLAGS),
GATE(0, "pclk_pmu", "pclk_bus", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(28), 3, GFLAGS),
+ /* Watchdog pclk is controlled from the secure GRF */
+ SGRF_GATE(PCLK_WDT, "pclk_wdt", "pclk_bus"),
+
GATE(PCLK_USB3PHY_OTG, "pclk_usb3phy_otg", "pclk_phy_pre", 0,
RK3328_CLKGATE_CON(28), 1, GFLAGS),
GATE(PCLK_USB3PHY_PIPE, "pclk_usb3phy_pipe", "pclk_phy_pre", 0,
RK3328_CLKGATE_CON(28), 2, GFLAGS),
GATE(PCLK_USB3_GRF, "pclk_usb3_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 2, GFLAGS),
--
2.20.1
[PATCH 1/3] clk: rockchip: add clock id for watchdog pclk on rk3328
Needed to export that added clock. Signed-off-by: Heiko Stuebner --- include/dt-bindings/clock/rk3328-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index afb811340382..555b4ff660ae 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -164,6 +164,7 @@ #define PCLK_DCF 233 #define PCLK_SARADC234 #define PCLK_ACODECPHY 235 +#define PCLK_WDT 236 /* hclk gates */ #define HCLK_PERI 308 -- 2.20.1
[PATCH 3/3] arm64: dts: rockchip: enable rk3328 watchdog clock
From: Leonidas P. Papadakos
Add the missing clock property for the watchdog on rk3328.
Signed-off-by: Leonidas P. Papadakos
[set wdt node to always enabled, as it is not board-specific]
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 994468671b19..e9fefd8a7e02 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -407,6 +407,7 @@
compatible = "snps,dw-wdt";
reg = <0x0 0xff1a 0x0 0x100>;
interrupts = ;
+ clocks = <&cru PCLK_WDT>;
};
pwm0: pwm@ff1b {
--
2.20.1
Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
> On Jun 14, 2019, at 3:06 PM, Dave Hansen wrote: > >> On 6/14/19 2:34 PM, Yu-cheng Yu wrote: >> On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote: I have a related question: Do we allow the application to read the bitmap, or any fault from the application on bitmap pages? >>> >>> We have to allow apps to read it. Otherwise they can't execute >>> instructions. >> >> What I meant was, if an app executes some legacy code that results in bitmap >> lookup, but the bitmap page is not yet populated, and if we then populate >> that >> page with all-zero, a #CP should follow. So do we even populate that zero >> page >> at all? >> >> I think we should; a #CP is more obvious to the user at least. > > Please make an effort to un-Intel-ificate your messages as much as > possible. I'd really prefer that folks say "missing end branch fault" > rather than #CP. I had to Google "#CP". > > I *think* you are saying that: The *only* lookups to this bitmap are on > "missing end branch" conditions. Normal, proper-functioning code > execution that has ENDBR instructions in it will never even look at the > bitmap. The only case when we reference the bitmap locations is when > the processor is about do do a "missing end branch fault" so that it can > be suppressed. Any population with the zero page would be done when > code had already encountered a "missing end branch" condition, and > populating with a zero-filled page will guarantee that a "missing end > branch fault" will result. You're arguing that we should just figure > this out at fault time and not ever reach the "missing end branch fault" > at all. > > Is that right? > > If so, that's an architecture subtlety that I missed until now and which > went entirely unmentioned in the changelog and discussion up to this > point. Let's make sure that nobody else has to walk that path by > improving our changelog, please. > > In any case, I don't think this is worth special-casing our zero-fill > code, FWIW. It's not performance critical and not worth the complexity. > If apps want to handle the signals and abuse this to fill space up with > boring page table contents, they're welcome to. There are much easier > ways to consume a lot of memory. Isn’t it a special case either way? Either we look at CR2 and populate a page, or we look at CR2 and the “tracker” state and send a different signal. Admittedly the former is very common in the kernel. > >>> We don't have to allow them to (popuating) fault on it. But, if we >>> don't, we need some kind of kernel interface to avoid the faults. >> >> The plan is: >> >> * Move STACK_TOP (and vdso) down to give space to the bitmap. > > Even for apps with 57-bit address spaces? > >> * Reserve the bitmap space from (mm->start_stack + PAGE_SIZE) to cover a code >> size of TASK_SIZE_LOW, which is (TASK_SIZE_LOW / PAGE_SIZE / 8). > > The bitmap size is determined by CR4.LA57, not the app. If you place > the bitmap here, won't references to it for high addresses go into the > high address space? > > Specifically, on a CR4.LA57=0 system, we have 48 bits of address space, > so 128TB for apps. You are proposing sticking the bitmap above the > stack which is near the top of that 128TB address space. But on a > 5-level paging system with CR4.LA57=1, there could be valid data at > 129GB. Is there something keeping that data from being mistaken for > being part of the bitmap? > I think we need to make the vma be full sized — it should cover the entire range that the CPU might access. If that means it spans the 48-bit boundary, so be it. > Also, if you're limiting it to TASK_SIZE_LOW, please don't forget that > this is yet another thing that probably won't work with the vsyscall > page. Please make sure you consider it and mention it in your next post. Why not? The vsyscall page is at a negative address. > >> * Mmap the space only when the app issues the first mark-legacy prctl. This >> avoids the core-dump issue for most apps and the accounting problem that >> MAP_NORESERVE probably won't solve What happens if there’s another VMA there by the time you map it?
Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
On Sat, Jun 15, 2019 at 12:03:04PM +0300, Thomas Backlund wrote: > Den 15-06-2019 kl. 08:50, skrev Greg KH: > > On Fri, Jun 14, 2019 at 04:09:35PM -0600, James Feeney wrote: > > > Hey Everyone > > > > > > On 4/24/19 10:41 AM, Benjamin Tissoires wrote: > > > > > > For a patch to be picked up by stable, it first needs to go in > > > > > > Linus' > > > > > > tree. Currently we are working on 5.1, so any stable patches need to > > > > > > go in 5.1 first. Then, once they hit Linus' tree, the stable team > > > > > > will > > > > > > pick them and backport them in the appropriate stable tree. > > > > > > Hmm - so, I just booted linux 5.1.9, and this patch set is *still* > > > missing from the kernel. > > > > > > Is there anything that we can do about this? > > > > What is the git commit id of the patch in Linus's tree? > > > > As I said before, it can not be backported until it shows up there > > first. > > > > That would be: > d43c17ead879ba7c076dc2f5fd80cd76047c9ff4 > > and > > 39b3c3a5fbc5d744114e497d35bf0c12f798c134 Thanks, now queued up. greg k-h
Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n
On Sat, Jun 15, 2019 at 01:21:59PM +0300, Thomas Backlund wrote: > Den 13-06-2019 kl. 10:42, skrev Greg Kroah-Hartman: > > > I've just reverted it now. > > > > If someone can send me a patch series of all of what needs to be > > applied, in a format that I can actually apply them in, I will be glad > > to do so. But for now, I'd like to get people's systems building again. > > > > > That would be basically re-adding the b30a43ac7132 commit and adding the > following patch (also attached in case the inlined version gets mangled): Thanks for this, I've queued it up now, let's try this all again :) greg k-h
Re: Linux 5.1.10
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index 8cf0b4d38a7e..109cc0cebaa2 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen
controller
Required properties:
- compatible : Should be "goodix,gt1151"
+or "goodix,gt5663"
or "goodix,gt5688"
or "goodix,gt911"
or "goodix,gt9110"
diff --git a/Makefile b/Makefile
index 2884a8d3b6d6..e7d1973d9c26 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 1
-SUBLEVEL = 9
+SUBLEVEL = 10
EXTRAVERSION =
NAME = Shy Crocodile
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 3447160e1fbf..a0e27e1c0feb 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -107,6 +107,7 @@
regulator-name = "PVDD_APIO_1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
};
ldo3_reg: LDO3 {
@@ -145,6 +146,7 @@
regulator-name = "PVDD_ABB_1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
};
ldo9_reg: LDO9 {
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index ee1e3e8bf4ec..4a68e30cc668 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -411,7 +411,7 @@
reg = <0x63fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx50.bin";
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index a5ee25cedc10..0a4b9a5d9a9c 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -489,7 +489,7 @@
reg = <0x83fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx51.bin";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index b3300300aabe..9b672ed2486d 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -702,7 +702,7 @@
reg = <0x63fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx53.bin";
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fe17a3405edc..2df39c308c83 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -918,7 +918,7 @@
compatible = "fsl,imx6q-sdma", "fsl,imx35-sdma";
reg = <0x020ec000 0x4000>;
interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6QDL_CLK_SDMA>,
+ clocks = <&clks IMX6QDL_CLK_IPG>,
<&clks IMX6QDL_CLK_SDMA>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 4b4813f176cd..1f2a4ed99ed3 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -741,7 +741,7 @@
reg = <0x02
Linux 4.19.51
I'm announcing the release of the 4.19.51 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 arch/arm/boot/dts/imx50.dtsi |2 arch/arm/boot/dts/imx51.dtsi |2 arch/arm/boot/dts/imx53.dtsi |2 arch/arm/boot/dts/imx6qdl.dtsi|2 arch/arm/boot/dts/imx6sl.dtsi |2 arch/arm/boot/dts/imx6sll.dtsi|2 arch/arm/boot/dts/imx6sx.dtsi |2 arch/arm/boot/dts/imx6ul.dtsi |2 arch/arm/boot/dts/imx7s.dtsi |4 arch/arm/include/asm/hardirq.h|1 arch/arm/kernel/smp.c |6 arch/arm/mach-exynos/suspend.c| 19 ++ arch/arm/mach-omap2/pm33xx-core.c |8 arch/mips/kernel/prom.c | 14 + arch/um/kernel/time.c |2 arch/x86/events/intel/core.c |2 arch/x86/pci/irq.c| 10 - block/bfq-iosched.c |2 block/blk-core.c |1 block/blk-mq.c|2 drivers/clk/rockchip/clk-rk3288.c | 11 + drivers/dma/idma64.c |6 drivers/dma/idma64.h |2 drivers/edac/Kconfig |4 drivers/gpio/gpio-omap.c | 25 +- drivers/gpio/gpio-vf610.c | 26 +- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c |6 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c |2 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |6 drivers/gpu/drm/nouveau/Kconfig | 13 - drivers/gpu/drm/nouveau/dispnv50/disp.h |1 drivers/gpu/drm/nouveau/dispnv50/head.c |2 drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c |1 drivers/gpu/drm/nouveau/dispnv50/wndw.c |2 drivers/gpu/drm/nouveau/nouveau_drm.c |7 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 11 - drivers/gpu/drm/pl111/pl111_display.c |5 drivers/gpu/drm/vc4/vc4_plane.c |1 drivers/iommu/arm-smmu-v3.c | 10 - drivers/iommu/intel-iommu.c |7 drivers/mailbox/stm32-ipcc.c | 13 - drivers/mfd/intel-lpss.c |3 drivers/mfd/tps65912-spi.c|1 drivers/mfd/twl6040.c | 13 + drivers/misc/pci_endpoint_test.c |1 drivers/mmc/host/mmci.c |5 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c |7 drivers/net/ethernet/intel/i40e/i40e_main.c |3 drivers/net/ethernet/intel/ice/ice_main.c |3 drivers/net/thunderbolt.c |3 drivers/nvme/host/pci.c | 10 - drivers/nvmem/core.c | 15 + drivers/nvmem/sunxi_sid.c |2 drivers/pci/controller/dwc/pci-keystone.c |4 drivers/pci/controller/dwc/pcie-designware-ep.c |7 drivers/pci/controller/dwc/pcie-designware-host.c | 21 +- drivers/pci/controller/dwc/pcie-designware.h |1 drivers/pci/controller/pcie-rcar.c| 10 - drivers/pci/controller/pcie-xilinx.c | 12 + drivers/pci/hotplug/rpadlpar_core.c |4 drivers/pci/switch/switchtec.c|3 drivers/platform/chrome/cros_ec_proto.c | 11 + drivers/platform/x86/intel_pmc_ipc.c |6 drivers/power/supply/max14656_charger_detector.c | 14 - drivers/pwm/core.c| 10 - drivers/pwm/pwm-meson.c | 25 +
Linux 5.1.10
I'm announcing the release of the 5.1.10 kernel. All users of the 5.1 kernel series must upgrade. The updated 5.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.1.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/input/touchscreen/goodix.txt |1 Makefile |2 arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 arch/arm/boot/dts/imx50.dtsi |2 arch/arm/boot/dts/imx51.dtsi |2 arch/arm/boot/dts/imx53.dtsi |2 arch/arm/boot/dts/imx6qdl.dtsi |2 arch/arm/boot/dts/imx6sl.dtsi |2 arch/arm/boot/dts/imx6sll.dtsi |2 arch/arm/boot/dts/imx6sx.dtsi |2 arch/arm/boot/dts/imx6ul.dtsi |2 arch/arm/boot/dts/imx7s.dtsi |4 arch/arm/include/asm/hardirq.h |1 arch/arm/kernel/smp.c |6 arch/arm/mach-exynos/suspend.c | 19 + arch/arm/mach-omap2/pm33xx-core.c |8 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c |6 arch/arm64/boot/dts/freescale/imx8mq.dtsi |2 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 28 +- arch/arm64/configs/defconfig |6 arch/mips/kernel/prom.c| 14 + arch/powerpc/include/asm/drmem.h | 21 + arch/powerpc/mm/drmem.c|6 arch/powerpc/platforms/pseries/hotplug-memory.c| 17 - arch/um/kernel/time.c |2 arch/x86/events/intel/core.c |2 arch/x86/pci/irq.c | 10 block/bfq-iosched.c|2 block/blk-core.c |1 block/blk-mq.c |2 drivers/clk/rockchip/clk-rk3288.c | 11 drivers/dma/idma64.c |6 drivers/dma/idma64.h |2 drivers/edac/Kconfig |4 drivers/gpio/gpio-omap.c | 53 ++-- drivers/gpio/gpio-vf610.c | 26 -- drivers/gpu/drm/amd/display/dc/core/dc_link.c |9 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c |6 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c |2 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |6 drivers/gpu/drm/drm_ioctl.c| 20 - drivers/gpu/drm/msm/msm_gem.c |3 drivers/gpu/drm/nouveau/Kconfig| 13 - drivers/gpu/drm/nouveau/dispnv50/disp.h|1 drivers/gpu/drm/nouveau/dispnv50/head.c|3 drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c|1 drivers/gpu/drm/nouveau/dispnv50/wndw.c|2 drivers/gpu/drm/nouveau/nouveau_drm.c |7 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 11 drivers/gpu/drm/pl111/pl111_display.c |5 drivers/input/touchscreen/goodix.c |2 drivers/iommu/arm-smmu-v3.c| 10 drivers/iommu/intel-iommu.c| 19 + drivers/mailbox/stm32-ipcc.c | 13 - drivers/media/platform/atmel/atmel-isc.c |8 drivers/media/v4l2-core/v4l2-ctrls.c | 18 - drivers/media/v4l2-core/v4l2-fwnode.c |6 drivers/mfd/intel-lpss.c |3 drivers/mfd/tps65912-spi.c |1 drivers/mfd/twl6040.c | 13 - drivers/misc/pci_endpoint_test.c |1 drivers/mmc/host/mmci.c|5 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c|7 drivers/net/ethernet/intel/i
Re: Linux 4.19.51
diff --git a/Makefile b/Makefile
index f7e7e365e2ff..dd4be2f32b88 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 50
+SUBLEVEL = 51
EXTRAVERSION =
NAME = "People's Front"
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index cdda614e417e..a370857beac0 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -106,6 +106,7 @@
regulator-name = "PVDD_APIO_1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
};
ldo3_reg: LDO3 {
@@ -144,6 +145,7 @@
regulator-name = "PVDD_ABB_1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
};
ldo9_reg: LDO9 {
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 7fae2ffb76fe..ab522c2da6df 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -420,7 +420,7 @@
reg = <0x63fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx50.bin";
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 5c4ba91e43ba..ef2abc097843 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -481,7 +481,7 @@
reg = <0x83fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx51.bin";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 6386185ae234..b6b0818343c4 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -701,7 +701,7 @@
reg = <0x63fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx53.bin";
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 61d2d26afbf4..00d44a60972f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -905,7 +905,7 @@
compatible = "fsl,imx6q-sdma", "fsl,imx35-sdma";
reg = <0x020ec000 0x4000>;
interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6QDL_CLK_SDMA>,
+ clocks = <&clks IMX6QDL_CLK_IPG>,
<&clks IMX6QDL_CLK_SDMA>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 7a4f5dace902..2fa88c6f1882 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -739,7 +739,7 @@
reg = <0x020ec000 0x4000>;
interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_SDMA>,
-<&clks IMX6SL_CLK_SDMA>;
+<&clks IMX6SL_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
/* imx6sl reuses imx6q sdma firmware */
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index 3e6ffaf5f104..7c7d5c47578e 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -591,7 +591,7 @@
Re: Linux 4.14.126
diff --git a/Makefile b/Makefile
index 9182c0b13988..631f8a8e28e0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 125
+SUBLEVEL = 126
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index ee1bb9b8b366..38538211a967 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -109,6 +109,7 @@
regulator-name = "PVDD_APIO_1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
};
ldo3_reg: LDO3 {
@@ -147,6 +148,7 @@
regulator-name = "PVDD_ABB_1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
};
ldo9_reg: LDO9 {
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 3747d80104f4..63e1d2fe2e19 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -441,7 +441,7 @@
reg = <0x63fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx50.bin";
};
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 1ee1d542d9ad..29c965126817 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -476,7 +476,7 @@
reg = <0x83fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx51.bin";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 2e516f4985e4..ddc3ce67c29a 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -676,7 +676,7 @@
reg = <0x63fb 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
-<&clks IMX5_CLK_SDMA_GATE>;
+<&clks IMX5_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name =
"imx/sdma/sdma-imx53.bin";
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 8884b4a3cafb..0fedb0c24eca 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -909,7 +909,7 @@
compatible = "fsl,imx6q-sdma", "fsl,imx35-sdma";
reg = <0x020ec000 0x4000>;
interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6QDL_CLK_SDMA>,
+ clocks = <&clks IMX6QDL_CLK_IPG>,
<&clks IMX6QDL_CLK_SDMA>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 3f76f980947e..bd9308b222ba 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -718,7 +718,7 @@
reg = <0x020ec000 0x4000>;
interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_SDMA>,
-<&clks IMX6SL_CLK_SDMA>;
+<&clks IMX6SL_CLK_AHB>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
/* imx6sl reuses imx6q sdma firmware */
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index d64438bfa68b..61ad4e296257 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -766,7 +766,7 @@
c
Linux 4.14.126
I'm announcing the release of the 4.14.126 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - arch/arm/boot/dts/exynos5420-arndale-octa.dts|2 + arch/arm/boot/dts/imx50.dtsi |2 - arch/arm/boot/dts/imx51.dtsi |2 - arch/arm/boot/dts/imx53.dtsi |2 - arch/arm/boot/dts/imx6qdl.dtsi |2 - arch/arm/boot/dts/imx6sl.dtsi|2 - arch/arm/boot/dts/imx6sx.dtsi|2 - arch/arm/boot/dts/imx6ul.dtsi|2 - arch/arm/boot/dts/imx7s.dtsi |4 +-- arch/arm/include/asm/hardirq.h |1 arch/arm/kernel/smp.c|6 +++- arch/arm/mach-exynos/suspend.c | 19 ++ arch/um/kernel/time.c|2 - arch/x86/events/intel/core.c |2 - arch/x86/pci/irq.c | 10 ++- block/bfq-iosched.c |2 + block/blk-core.c |1 block/blk-mq.c |2 + drivers/clk/rockchip/clk-rk3288.c| 11 drivers/dma/idma64.c |6 +++- drivers/dma/idma64.h |2 + drivers/edac/Kconfig |4 +-- drivers/gpio/gpio-omap.c | 25 +-- drivers/gpio/gpio-vf610.c| 26 +-- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |6 ++-- drivers/gpu/drm/drm_atomic_helper.c | 10 +++ drivers/gpu/drm/nouveau/Kconfig | 13 - drivers/gpu/drm/nouveau/nouveau_drm.c|7 + drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c| 11 ++-- drivers/iommu/intel-iommu.c |7 +++-- drivers/mfd/intel-lpss.c |3 ++ drivers/mfd/tps65912-spi.c |1 drivers/mfd/twl6040.c| 13 + drivers/misc/pci_endpoint_test.c |1 drivers/mmc/host/mmci.c |5 ++- drivers/nvme/host/pci.c |5 +++ drivers/nvmem/core.c | 15 +++ drivers/pci/dwc/pci-keystone.c |4 +++ drivers/pci/host/pcie-rcar.c | 10 +-- drivers/pci/host/pcie-xilinx.c | 12 +++-- drivers/pci/hotplug/rpadlpar_core.c |4 +++ drivers/platform/chrome/cros_ec_proto.c | 11 drivers/platform/x86/intel_pmc_ipc.c |6 +++- drivers/power/supply/max14656_charger_detector.c | 14 +- drivers/pwm/core.c | 10 +++ drivers/pwm/pwm-meson.c | 25 +-- drivers/pwm/pwm-tiehrpwm.c |2 + drivers/pwm/sysfs.c | 14 -- drivers/rapidio/rio_cm.c |8 ++ drivers/soc/mediatek/mtk-pmic-wrap.c |2 - drivers/soc/rockchip/grf.c |2 + drivers/spi/spi-pxa2xx.c |7 - drivers/staging/typec/fusb302/fusb302.c |2 + drivers/thermal/qcom/tsens.c |3 +- drivers/thermal/rcar_gen3_thermal.c |3 ++ drivers/tty/serial/8250/8250_dw.c|4 +-- drivers/vfio/vfio.c | 30 +++ drivers/video/fbdev/hgafb.c |2 + drivers/video/fbdev/imsttfb.c|5 +++ drivers/watchdog/Kconfig |1 drivers/watchdog/imx2_wdt.c |4 ++- fs/configfs/dir.c| 17 + fs/f2fs/f2fs.h | 12 +++-- fs/f2fs/inode.c |1 fs/f2fs/recovery.c | 10 ++- fs/f2fs/segment.h|3 -- fs/fat/file.c| 11 ++-- fs/fuse/dev.c|2 - fs/nfsd/vfs.h|5 +++ include/drm/drm_modeset_helper_vtables.h |8 ++ include/linux/pwm.h |5 --- include/net/bluetooth/hci_core.h |3
Re: [PATCH v4] fs/proc: add VmTaskSize field to /proc/$$/status
The most immediate use case is the optimization of an internal test, but upon closer examination neither this patch nor the test itself turn out to be worth pursuing. Thank you for your time and constructive comments. Best, Joel Savitz On Thu, Jun 13, 2019 at 3:30 PM Andrew Morton wrote: > > On Thu, 13 Jun 2019 10:54:50 -0400 Joel Savitz wrote: > > > The kernel provides no architecture-independent mechanism to get the > > size of the virtual address space of a task (userspace process) without > > brute-force calculation. This patch allows a user to easily retrieve > > this value via a new VmTaskSize entry in /proc/$$/status. > > Why is access to ->task_size required? Please fully describe the > use case. > > > --- a/Documentation/filesystems/proc.txt > > +++ b/Documentation/filesystems/proc.txt > > @@ -187,6 +187,7 @@ read the file /proc/PID/status: > >VmLib: 1412 kB > >VmPTE:20 kb > >VmSwap:0 kB > > + VmTaskSize:137438953468 kB > >HugetlbPages: 0 kB > >CoreDumping:0 > >THP_enabled: 1 > > @@ -263,6 +264,7 @@ Table 1-2: Contents of the status files (as of 4.19) > > VmPTE size of page table entries > > VmSwap amount of swap used by anonymous private data > > (shmem swap usage is not included) > > + VmTaskSize size of task (userspace process) vm space > > This is rather vague. Is it the total amount of physical memory? The > sum of all vma sizes, populated or otherwise? Something else? > >
Re: [PATCH] MAINTAINERS: don't automatically patches involving SiFive to the linux-riscv list
On Thu, 13 Jun 2019 00:02:25 PDT (-0700), Paul Walmsley wrote: The current K: entry in the "SIFIVE DRIVERS" section causes scripts/get_maintainer.pl to recommend that all patches that originate from, or are sent or copied to, anyone with a @sifive.com E-mail address to be copied to the linux-ri...@lists.infradead.org mailing list: https://lore.kernel.org/linux-riscv/CABEDWGxKCqCq2HBU8u1-=qgmmcdb69oxxn5rz65nxnodxdc...@mail.gmail.com/ This is undesirable, since not all of these patches may be relevant to the linux-riscv@ mailing list. Fix by excluding K: matches that look like a sifive.com E-mail address. Based on the following patch from Palmer Dabbelt : https://lore.kernel.org/linux-riscv/mhng-2a897a66-1f3d-4878-ba47-1ae36b40@palmer-si-x1e/ Signed-off-by: Paul Walmsley Cc: Palmer Dabbelt --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 57f496cff999..66d23856781d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14332,7 +14332,7 @@ M: Paul Walmsley L: linux-ri...@lists.infradead.org T: git git://github.com/sifive/riscv-linux.git S: Supported -K: sifive +K: [^@]sifive N: sifive SILEAD TOUCHSCREEN DRIVER Reviewed-by: Palmer Dabbelt
Re: [PATCH] MAINTAINERS: change the arch/riscv git tree to the new shared tree
On Thu, 13 Jun 2019 00:07:21 PDT (-0700), Paul Walmsley wrote: Palmer, with Konstantin's gracious help, set up a shared kernel.org git tree for arch/riscv patches going forward. Change the MAINTAINERS file accordingly. Signed-off-by: Paul Walmsley Cc: Palmer Dabbelt --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 57f496cff999..290359a46bbe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13476,7 +13476,7 @@ RISC-V ARCHITECTURE M: Palmer Dabbelt M: Albert Ou L: linux-ri...@lists.infradead.org -T: git git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git S: Supported F: arch/riscv/ K: riscv Reiewed-by: Palmer Dabbelt
Re: [PATCH] powerpc/mm/32s: only use MMU to mark initmem NX if STRICT_KERNEL_RWX
On Jun 15 2019, Christophe Leroy wrote: > Andreas Schwab a écrit : > >> If STRICT_KERNEL_RWX is disabled, never use the MMU to mark initmen >> nonexecutable. > > I dont understand, can you elaborate ? It breaks suspend. > This area is mapped with BATs so using change_page_attr() is pointless. There must be a reason STRICT_KERNEL_RWX is not available with HIBERNATE. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [RFC PATCH 8/8] svm: Allow AVIC with in-kernel irqchip mode
On Wed, 2019-02-06 at 11:20 +, Suthikulpanit, Suravee wrote: > Alex, > > On 2/6/19 1:34 AM, Alex Williamson wrote: > > On Mon, 4 Feb 2019 14:42:32 + > > "Suthikulpanit, Suravee" wrote: > > > > > Once the IRQ ack notifier for in-kernel PIT is no longer required > > > and run-time AVIC activate/deactivate is supported, we can remove > > > the kernel irqchip split mode requirement for AVIC. > > > > > > Hence, remove the check for irqchip split mode when enabling AVIC. > > > > Yay! Could we also at this point make avic enabled by default or are > > there remaining incompatibilities? Thanks, > > I'm looking into that next. I would need to ensure that enabling > AVIC would not cause issues with other features. > > Suravee Hi! Do you have any update on the state of this patch? I kind of stumbled on it accidently, while trying to understand why AVIC is only enabled in the split irqchip mode. Best regards, Maxim Levitsky
Re: [PATCH v2 1/1] watchdog: atmel: atmel-sama5d4-wdt: Disable watchdog on system suspend
On Fri, Jun 14, 2019 at 08:45:28PM +, Ken Sloat wrote: > > -Original Message- > > From: Alexandre Belloni > > Sent: Friday, June 14, 2019 4:33 PM > > To: Ken Sloat > > Cc: Guenter Roeck ; nicolas.fe...@microchip.com; > > ludovic.desroc...@microchip.com; w...@linux-watchdog.org; linux-arm- > > ker...@lists.infradead.org; linux-watch...@vger.kernel.org; linux- > > ker...@vger.kernel.org > > Subject: Re: [PATCH v2 1/1] watchdog: atmel: atmel-sama5d4-wdt: Disable > > watchdog on system suspend > > > > [This is an EXTERNAL EMAIL] > > > > > > On 14/06/2019 18:43:22+, Ken Sloat wrote: > > > Well I'm a little confused still because there are two separate > > > comments in these statements. The first within resume implies that the > > > init should be called because we might have lost register values for > > > some reason unexplained. > > > > The sama5d2 has a suspend mode where power to the core is completely > > cut. Only a few IPs remain powered (in the backup power domain). > > Unfortunately, the watchdog is not in that domain and may lose its > > registers. > > > > > Then within the init it says that the bootloader might have modified > > > the registers so we should check them and then update it or otherwise > > > disable it. I'm not trying to pick apart the logic or anything, I'm > > > just readily assuming it is good as it was already reviewed before. > > > > > > > The bootloaders may have started the watchdog (this makes sense if you > > really care about reliability) and so we need to be careful to keep the > > proper > > parameters. > > Thanks for the explanation Alexandre I appreciate it. > > > > So without digging into that too much, if we don't know if any of the > > > runtime situations above might have occurred, then isn't it best to > > > leave my patch as is? Yes this has the side effect of resetting the > > > timer count, but if the init call is needed and we don't have any way > > > to know if any of the situations occurred, then we have no choice right? > > > > > > > Until we can differentiate between suspend modes, we have no other > > choice. > > Ok I will leave my patch as is for now then > If that is what those involved in this discussion argue for, they will need to confirm with Reviewed-by: or Acked-by: tags. Thanks, Guenter > > -- > > Alexandre Belloni, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > > Thanks, > Ken Sloat
Re: [RFC] Disable lockref on arm64
On Sat, 15 Jun 2019 at 15:59, Kees Cook wrote: > > On Sat, Jun 15, 2019 at 10:47:19AM +0200, Ard Biesheuvel wrote: > > remaining question Will had was whether it makes sense to do the > > condition checks before doing the actual store, to avoid having a time > > window where the refcount assumes its illegal value. Since arm64 does > > not have memory operands, the instruction count wouldn't change, but > > it will definitely result in a performance hit on out-of-order CPUs. > > What do the races end up looking like? Is it possible to have two > threads ordered in a way that a second thread could _un_saturate a > counter? > > CPU 1 CPU 2 > inc() > load INT_MAX-1 > about to overflow? > yes > dec() > load INT_MAX-1 > set to INT_MAX > set to INT_MAX-2 > > Or would you use the same INT_MIN/2 saturation point done on x86? > Yes, I am using the same saturation point as x86. In this example, I am not entirely sure I understand why it matters, though: the atomics guarantee that the write by CPU2 fails if CPU1 changed the value in the mean time, regardless of which value it wrote. I think the concern is more related to the likelihood of another CPU doing something nasty between the moment that the refcount overflows and the moment that the handler pins it at INT_MIN/2, e.g., > CPU 1 CPU 2 > inc() > load INT_MAX > about to overflow? > yes > > set to 0 > > set to INT_MIN/2 > As for performance, it should be easy to measure with the LKDTM test > to find out exactly the differences. > Yes, I intend to look into this on Monday.
