[PATCH] MAINTAINERS: replace non-matching patterns for loongson{2,3}

[Lukas Bulwahn]

Commit ffe1f9356fbe ("MAINTAINERS: Add Loongson-2/Loongson-3 maintainers")
adds quite generic file entries for drivers/*/*loongson{2,3}* and
drivers/*/*/*loongson{2,3}* to be informed on changes to all loongson{2,3}
files in drivers.

However, only the pattern 'drivers/*/*loongson2*' matches to one file in
the repository, i.e., drivers/cpufreq/loongson2_cpufreq.c; all other
patterns have no file matches.

Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:

  warning: no file matchesF:drivers/*/*/*loongson2*
  warning: no file matchesF:drivers/*/*/*loongson3*
  warning: no file matchesF:drivers/*/*loongson3*

As in the last two and half years, no further files and drivers have
showed up to match those patterns, just name the one file that matches
explicitly and delete the others without a match.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on current master and next-20201102

Keguang, Huacai, Jiaxun, please ack.

Thomas, please pick this minor non-urgent cleanup patch.

 MAINTAINERS | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b4197e9da495..fc08f628e196 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11719,8 +11719,7 @@ L:  linux-m...@vger.kernel.org
 S: Maintained
 F: arch/mips/include/asm/mach-loongson2ef/
 F: arch/mips/loongson2ef/
-F: drivers/*/*/*loongson2*
-F: drivers/*/*loongson2*
+F: drivers/cpufreq/loongson2_cpufreq.c
 
 MIPS/LOONGSON64 ARCHITECTURE
 M: Huacai Chen 
@@ -11729,8 +11728,6 @@ L:  linux-m...@vger.kernel.org
 S: Maintained
 F: arch/mips/include/asm/mach-loongson64/
 F: arch/mips/loongson64/
-F: drivers/*/*/*loongson3*
-F: drivers/*/*loongson3*
 F: drivers/irqchip/irq-loongson*
 F: drivers/platform/mips/cpu_hwmon.c
 
-- 
2.17.1

[PATCH v2] staging: gdm724x: Fix DMA from stack

[Amey Narkhede]

Stack allocated buffers cannot be used for DMA
on all architectures so allocate hci_packet buffer
using kzalloc().

Signed-off-by: Amey Narkhede 
---
Changes in v2:
- Fixed build warning
- Fixed memory leak using kfree

 drivers/staging/gdm724x/gdm_usb.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/gdm724x/gdm_usb.c 
b/drivers/staging/gdm724x/gdm_usb.c
index dc4da66c3..c4a9b90c5 100644
--- a/drivers/staging/gdm724x/gdm_usb.c
+++ b/drivers/staging/gdm724x/gdm_usb.c
@@ -56,11 +56,15 @@ static int gdm_usb_recv(void *priv_dev,

 static int request_mac_address(struct lte_udev *udev)
 {
-   u8 buf[16] = {0,};
-   struct hci_packet *hci = (struct hci_packet *)buf;
+   u8 *buf;
+   struct hci_packet *hci;
struct usb_device *usbdev = udev->usbdev;
int actual;
int ret = -1;
+   buf = kzalloc(16, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+   hci = (struct hci_packet *)buf;

hci->cmd_evt = gdm_cpu_to_dev16(udev->gdm_ed, LTE_GET_INFORMATION);
hci->len = gdm_cpu_to_dev16(udev->gdm_ed, 1);
@@ -70,6 +74,7 @@ static int request_mac_address(struct lte_udev *udev)
   &actual, 1000);

udev->request_mac_addr = 1;
+   kfree(buf);

return ret;
 }
--
2.30.0

Re: [PATCH] sign-file: add openssl engine support

[David Woodhouse]

On 10 February 2021 07:45:54 GMT, Yang Song  wrote:
>Use a customized signature service supported by openssl engine
>to sign the kernel module.
>Add command line parameters that support engine for sign-file
>to use the customized openssl engine service to sign kernel modules.
>
>Signed-off-by: Yang Song 

Aren't engines already obsolete in the latest versions of OpenSSL, as well as 
being an implementation detail of one particular crypto library? They aren't 
really a concept we should be exposing in *our* user interface.

Better to make sign-file automatically recognise RFC7512 PKCS#11 URIs and 
handle them by automatically loading the PKCS#11 engine.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH v3] mm: cma: support sysfs

[Greg KH]

On Tue, Feb 09, 2021 at 11:55:09PM -0800, Minchan Kim wrote:
> Since CMA is getting used more widely, it's more important to
> keep monitoring CMA statistics for system health since it's
> directly related to user experience.
> 
> This patch introduces sysfs statistics for CMA, in order to provide
> some basic monitoring of the CMA allocator.
> 
>  * the number of CMA page allocation attempts
>  * the number of CMA page allocation failures
> 
> These two values allow the user to calcuate the allocation
> failure rate for each CMA area.
> 
> e.g.)
>   /sys/kernel/mm/cma/WIFI/cma_alloc_pages_[attempts|fails]
>   /sys/kernel/mm/cma/SENSOR/cma_alloc_pages_[attempts|fails]
>   /sys/kernel/mm/cma/BLUETOOTH/cma_alloc_pages_[attempts|fails]
> 
> Signed-off-by: Minchan Kim 

For the sysfs stuff:

Reviewed-by: Greg Kroah-Hartman 

Re: [RFC PATCH v1 0/4] vfio: Add IOPF support for VFIO passthrough

[Shenming Lu]

On 2021/2/9 19:06, Liu, Yi L wrote:
>> From: Tian, Kevin 
>> Sent: Thursday, February 4, 2021 2:52 PM
>>
>>> From: Shenming Lu 
>>> Sent: Tuesday, February 2, 2021 2:42 PM
>>>
>>> On 2021/2/1 15:56, Tian, Kevin wrote:
> From: Alex Williamson 
> Sent: Saturday, January 30, 2021 6:58 AM
>
> On Mon, 25 Jan 2021 17:03:58 +0800
> Shenming Lu  wrote:
>
>> Hi,
>>
>> The static pinning and mapping problem in VFIO and possible
>> solutions
>> have been discussed a lot [1, 2]. One of the solutions is to add I/O
>> page fault support for VFIO devices. Different from those relatively
>> complicated software approaches such as presenting a vIOMMU that
> provides
>> the DMA buffer information (might include para-virtualized
>>> optimizations),
>> IOPF mainly depends on the hardware faulting capability, such as the
>>> PCIe
>> PRI extension or Arm SMMU stall model. What's more, the IOPF
>> support
>>> in
>> the IOMMU driver is being implemented in SVA [3]. So do we
>> consider to
>> add IOPF support for VFIO passthrough based on the IOPF part of SVA
>> at
>> present?
>>
>> We have implemented a basic demo only for one stage of translation
>>> (GPA
>> -> HPA in virtualization, note that it can be configured at either 
>> stage),
>> and tested on Hisilicon Kunpeng920 board. The nested mode is more
> complicated
>> since VFIO only handles the second stage page faults (same as the
>> non-
> nested
>> case), while the first stage page faults need to be further delivered to
>> the guest, which is being implemented in [4] on ARM. My thought on
>> this
>> is to report the page faults to VFIO regardless of the occured stage
>> (try
>> to carry the stage information), and handle respectively according to
>> the
>> configured mode in VFIO. Or the IOMMU driver might evolve to
>> support
> more...
>>
>> Might TODO:
>>  - Optimize the faulting path, and measure the performance (it might
>> still
>>be a big issue).
>>  - Add support for PRI.
>>  - Add a MMU notifier to avoid pinning.
>>  - Add support for the nested mode.
>> ...
>>
>> Any comments and suggestions are very welcome. :-)
>
> I expect performance to be pretty bad here, the lookup involved per
> fault is excessive.  There are cases where a user is not going to be
> willing to have a slow ramp up of performance for their devices as they
> fault in pages, so we might need to considering making this
> configurable through the vfio interface.  Our page mapping also only

 There is another factor to be considered. The presence of IOMMU_
 DEV_FEAT_IOPF just indicates the device capability of triggering I/O
 page fault through the IOMMU, but not exactly means that the device
 can tolerate I/O page fault for arbitrary DMA requests.
>>>
>>> Yes, so I add a iopf_enabled field in VFIO to indicate the whole path
>> faulting
>>> capability and set it to true after registering a VFIO page fault handler.
>>>
 In reality, many
 devices allow I/O faulting only in selective contexts. However, there
 is no standard way (e.g. PCISIG) for the device to report whether
 arbitrary I/O fault is allowed. Then we may have to maintain device
 specific knowledge in software, e.g. in an opt-in table to list devices
 which allows arbitrary faults. For devices which only support selective
 faulting, a mediator (either through vendor extensions on vfio-pci-core
 or a mdev wrapper) might be necessary to help lock down non-faultable
 mappings and then enable faulting on the rest mappings.
>>>
>>> For devices which only support selective faulting, they could tell it to the
>>> IOMMU driver and let it filter out non-faultable faults? Do I get it wrong?
>>
>> Not exactly to IOMMU driver. There is already a vfio_pin_pages() for
>> selectively page-pinning. The matter is that 'they' imply some device
>> specific logic to decide which pages must be pinned and such knowledge
>> is outside of VFIO.
>>
>> From enabling p.o.v we could possibly do it in phased approach. First
>> handles devices which tolerate arbitrary DMA faults, and then extends
>> to devices with selective-faulting. The former is simpler, but with one
>> main open whether we want to maintain such device IDs in a static
>> table in VFIO or rely on some hints from other components (e.g. PF
>> driver in VF assignment case). Let's see how Alex thinks about it.
>>
>>>

> grows here, should mappings expire or do we need a least recently
> mapped tracker to avoid exceeding the user's locked memory limit?
>> How
> does a user know what to set for a locked memory limit?  The behavior
> here would lead to cases where an idle system might be ok, but as
>> soon
> as load increases with more inflight DMA, we start seeing
> "unpredictable" I/O faults from the user perspective.  Seems 

Re: [PATCH 4/5] ath10k: detect conf_mutex held ath10k_drain_tx() calls

[kernel test robot]

Hi Shuah,

I love your patch! Yet something to improve:

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on wireless-drivers/master v5.11-rc7 next-20210125]
[cannot apply to ath6kl/ath-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Shuah-Khan/ath10k-fixes-for-warns/20210210-085259
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/5a96c0c9dfec2bd59e680b7ec8ade9378b654c4c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Shuah-Khan/ath10k-fixes-for-warns/20210210-085259
git checkout 5a96c0c9dfec2bd59e680b7ec8ade9378b654c4c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "lockdep_is_held" 
>> [drivers/net/wireless/ath/ath10k/ath10k_core.ko] undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] x86, sched: Allow NUMA nodes to share an LLC on Intel platforms

[Peter Zijlstra]

On Tue, Feb 09, 2021 at 02:39:43PM -0800, Alison Schofield wrote:

> Commit 1340ccfa9a9a ("x86,sched: Allow topologies where NUMA nodes
> share an LLC") added a vendor and model specific check to skip the
> topology_sane() check for Intel's Sky Lake Server CPUs where NUMA
> nodes shared an LLC.
> 
> This topology is no longer a quirk for Intel CPUs as Ice Lake and
> Sapphire Rapids CPUs exhibit the same topology. Rather than maintain
> the quirk list, define a synthetic flag that directs the scheduler
> to allow this topology without warning for all Intel CPUs when NUMA
> is configured.

Hurmph, I still think it's daft.

> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 816fdbec795a..027348261080 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -719,6 +719,21 @@ static void init_intel(struct cpuinfo_x86 *c)
>   tsx_disable();
>  
>   split_lock_init();
> +
> + /*
> +  * Set X86_BUG_NUMA_SHARES_LLC to allow topologies where NUMA
> +  * nodes share an LLC. In Sub-NUMA Clustering mode Intel CPUs
> +  * may enumerate an LLC as shared by multiple NUMA nodes. The
> +  * LLC is shared for off-package data access but private to
> +  * the NUMA node for on-package access. This topology first
> +  * appeared in SKYLAKE_X. It was treated as a quirk and allowed.
> +  * This topology reappeared in ICELAKE_X and SAPPHIRERAPIDS_X.
> +  * Rather than maintain a list of quirk CPUS, allow this topology
> +  * on all Intel CPUs with NUMA configured. When this X86_BUG is
> +  * set, the scheduler accepts this topology without warning.
> +  */
> + if (IS_ENABLED(CONFIG_NUMA))
> + set_cpu_bug(c, X86_BUG_NUMA_SHARES_LLC);
>  }

This seens wrong too, it shouldn't be allowed pre SKX. And ideally only
be allowed when SNC is enabled.

Please make this more specific than: all Intel CPUs. Ofcourse, since you
all knew this was an issue, you could've made it discoverable
_somewhere_ :-(

Re: [PATCH v3] mm: cma: support sysfs

[John Hubbard]

On 2/9/21 11:55 PM, Minchan Kim wrote:

Since CMA is getting used more widely, it's more important to
keep monitoring CMA statistics for system health since it's
directly related to user experience.

This patch introduces sysfs statistics for CMA, in order to provide
some basic monitoring of the CMA allocator.

  * the number of CMA page allocation attempts
  * the number of CMA page allocation failures

These two values allow the user to calcuate the allocation
failure rate for each CMA area.

e.g.)
   /sys/kernel/mm/cma/WIFI/cma_alloc_pages_[attempts|fails]
   /sys/kernel/mm/cma/SENSOR/cma_alloc_pages_[attempts|fails]
   /sys/kernel/mm/cma/BLUETOOTH/cma_alloc_pages_[attempts|fails]

Signed-off-by: Minchan Kim 
---


Looks good.

Reviewed-by: John Hubbard 


thanks,
--
John Hubbard
NVIDIA


 From v2 - 
https://lore.kernel.org/linux-mm/20210208180142.2765456-1-minc...@kernel.org/
  * sysfs doc and description modification - jhubbard

 From v1 - 
https://lore.kernel.org/linux-mm/20210203155001.4121868-1-minc...@kernel.org/
  * fix sysfs build and refactoring - willy
  * rename and drop some attributes - jhubbard
  Documentation/ABI/testing/sysfs-kernel-mm-cma |  25 
  mm/Kconfig|   7 ++
  mm/Makefile   |   1 +
  mm/cma.c  |   6 +-
  mm/cma.h  |  18 +++
  mm/cma_sysfs.c| 114 ++
  6 files changed, 170 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-cma
  create mode 100644 mm/cma_sysfs.c

diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cma 
b/Documentation/ABI/testing/sysfs-kernel-mm-cma
new file mode 100644
index ..f518af819cee
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-cma
@@ -0,0 +1,25 @@
+What:  /sys/kernel/mm/cma/
+Date:  Feb 2021
+Contact:   Minchan Kim 
+Description:
+   /sys/kernel/mm/cma/ contains a subdirectory for each CMA
+   heap name (also sometimes called CMA areas).
+
+   Each CMA heap subdirectory (that is, each
+   /sys/kernel/mm/cma/ directory) contains the
+   following items:
+
+   cma_alloc_pages_attempts
+   cma_alloc_pages_fails
+
+What:  /sys/kernel/mm/cma//cma_alloc_pages_attempts
+Date:  Feb 2021
+Contact:   Minchan Kim 
+Description:
+   the number of pages CMA API tried to allocate
+
+What:  /sys/kernel/mm/cma//cma_alloc_pages_fails
+Date:  Feb 2021
+Contact:   Minchan Kim 
+Description:
+   the number of pages CMA API failed to allocate
diff --git a/mm/Kconfig b/mm/Kconfig
index ec35bf406439..ad7e9c065657 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -513,6 +513,13 @@ config CMA_DEBUGFS
help
  Turns on the DebugFS interface for CMA.
  
+config CMA_SYSFS

+   bool "CMA information through sysfs interface"
+   depends on CMA && SYSFS
+   help
+ This option exposes some sysfs attributes to get information
+ from CMA.
+
  config CMA_AREAS
int "Maximum count of the CMA areas"
depends on CMA
diff --git a/mm/Makefile b/mm/Makefile
index b2a564eec27f..e10c14300191 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_CMA)   += cma.o
  obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
  obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
  obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+obj-$(CONFIG_CMA_SYSFS) += cma_sysfs.o
  obj-$(CONFIG_USERFAULTFD) += userfaultfd.o
  obj-$(CONFIG_IDLE_PAGE_TRACKING) += page_idle.o
  obj-$(CONFIG_DEBUG_PAGE_REF) += debug_page_ref.o
diff --git a/mm/cma.c b/mm/cma.c
index 23d4a97c834a..b42ccafc71e5 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -447,9 +447,10 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
unsigned int align,
offset = cma_bitmap_aligned_offset(cma, align);
bitmap_maxno = cma_bitmap_maxno(cma);
bitmap_count = cma_bitmap_pages_to_bits(cma, count);
+   cma_sysfs_alloc_count(cma, count);
  
  	if (bitmap_count > bitmap_maxno)

-   return NULL;
+   goto out;
  
  	for (;;) {

mutex_lock(&cma->lock);
@@ -504,6 +505,9 @@ struct page *cma_alloc(struct cma *cma, size_t count, 
unsigned int align,
__func__, count, ret);
cma_debug_show_areas(cma);
}
+out:
+   if (!page)
+   cma_sysfs_fail_count(cma, count);
  
  	pr_debug("%s(): returned %p\n", __func__, page);

return page;
diff --git a/mm/cma.h b/mm/cma.h
index 42ae082cb067..24a1d61eabc7 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -3,6 +3,14 @@
  #define __MM_CMA_H__
  
  #include 

+#include 
+
+struct cma_stat {
+   spinlock_t lock;
+   unsigned long pages_attempts;   /* the number of CMA page allocation 
attempts */
+   unsigned

Re: [PATCH] selftests/vDSO: fix ABI selftest on riscv

[Tobias Klauser]

On 2021-02-09 at 00:37:24 +0100, Shuah Khan  wrote:
> On 2/5/21 12:57 AM, Tobias Klauser wrote:
> > On 2021-02-05 at 08:06:37 +0100, Palmer Dabbelt  wrote:
> > > On Thu, 04 Feb 2021 06:50:42 PST (-0800), tklau...@distanz.ch wrote:
> > 
> > [...]
> > 
> > > Reviewed-by: Palmer Dabbelt 
> > > Acked-by: Palmer Dabbelt 
> > 
> > Thank you!
> > 
> > > Not sure if you want this through the RISC-V tree, so I'm leaving it out 
> > > for
> > > now and assuming it'll go through a kselftest tree.
> > 
> > Either way is fine for me.
> > 
> 
> Thank you. Applied to linux-kselftest next for 5.12-rc1

Thank you Shuah!

Re: linux-next: build failure after merge of the modules tree

[Jessica Yu]

+++ Stephen Rothwell [10/02/21 08:50 +1100]:

Hi Jessica,

On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu  wrote:


Hmm, these errors don't look like it's related to that particular commit. I was


I found this commit by bisection and then tested by reverting it.

Before this commit, CONFIG_TRIM_UNUSED_KSYMS would not be set in the
allyesconfig build because CONFIG_UNUSED_SYMBOLS was set.  After this
commit, CONFIG_TRIM_UNUSED_KSYMS will be set in the allyesconfig build.


Ah, that makes sense then. I would get the error on powerpc whenever
CONFIG_TRIM_UNUSED_KSYMS was enabled.


able to reproduce these weird autoksym errors even without any modules-next
patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run into
these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler and got
the same compiler warnings. It seems to not compile on powerpc properly because
it looks like some symbols have an extra dot "." prefix, for example in
kthread.o:

168: 031824 NOTYPE  GLOBAL DEFAULT6 
kthread_create_worker
169: 1d90   104 FUNCGLOBAL DEFAULT1 
.kthread_create_worker
170: 033024 NOTYPE  GLOBAL DEFAULT6 
kthread_create_worker_on_cpu
171: 1e0088 FUNCGLOBAL DEFAULT1 
.kthread_create_worker_on_cpu
172: 034824 NOTYPE  GLOBAL DEFAULT6 kthread_queue_work
173: 1e60   228 FUNCGLOBAL DEFAULT1 .kthread_queue_work

So I suppose this dot prefix is specific to powerpc. From the ppc64 elf abi 
docs:

 Symbol names with a dot (.) prefix are reserved for holding entry point
 addresses. The value of a symbol named ".FN", if it exists, is the entry 
point
 of the function "FN".

I guess the presence of the extra dot symbols is confusing
scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which the
preprocessor doesn't like. I am wondering how this was never caught until now
and also now curious if this feature was ever functional on powerpc..


Which feature?


Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
option was introduced around v4.7. If simply enabling it produces
these compilation errors I was wondering if it ever built properly on
powerpc.

Thanks,

Jessica

Re: [PATCH v2] staging: gdm724x: Fix DMA from stack

[Greg KH]

On Wed, Feb 10, 2021 at 01:31:34PM +0530, Amey Narkhede wrote:
> Stack allocated buffers cannot be used for DMA
> on all architectures so allocate hci_packet buffer
> using kzalloc().
> 
> Signed-off-by: Amey Narkhede 
> ---
> Changes in v2:
>   - Fixed build warning
>   - Fixed memory leak using kfree
> 
>  drivers/staging/gdm724x/gdm_usb.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/gdm724x/gdm_usb.c 
> b/drivers/staging/gdm724x/gdm_usb.c
> index dc4da66c3..c4a9b90c5 100644
> --- a/drivers/staging/gdm724x/gdm_usb.c
> +++ b/drivers/staging/gdm724x/gdm_usb.c
> @@ -56,11 +56,15 @@ static int gdm_usb_recv(void *priv_dev,
> 
>  static int request_mac_address(struct lte_udev *udev)
>  {
> - u8 buf[16] = {0,};
> - struct hci_packet *hci = (struct hci_packet *)buf;
> + u8 *buf;
> + struct hci_packet *hci;
>   struct usb_device *usbdev = udev->usbdev;
>   int actual;
>   int ret = -1;
> + buf = kzalloc(16, GFP_KERNEL);

checkpatch did not complain about this?

And why do you need 'buf' anymore now?  Why not just allocate hci and
pass that to the request instead?  Saves you an extra cast and an extra
pointer.

thanks,

greg k-h

Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc

[Dan Carpenter]

On Wed, Feb 10, 2021 at 02:42:30AM +0530, karthik alapati wrote:
> fix checkpatch.pl warning for "block comments should align the
>  * on each line" and make function comments follow kernel-doc
> 
> Signed-off-by: karthik alapati 
> ---
>  .../staging/rtl8723bs/hal/rtl8723b_phycfg.c   | 209 --
>  1 file changed, 91 insertions(+), 118 deletions(-)
> 
> diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c 
> b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> index cf23414d7..b7fca881c 100644
> --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> @@ -20,16 +20,11 @@
>  #define MAX_DOZE_WAITING_TIMES_9x 64
>  
>  /**
> -* Function:  phy_CalculateBitShift
> -*
> -* OverView:  Get shifted position of the BitMask
> -*
> -* Input:
> -*u32 BitMask,
> -*
> -* Output:none
> -* Return:u32 Return the shift bit bit position of the mask
> -*/
> + *   phy_CalculateBitShift - Get shifted position of the BitMask.
> + *   @BitMask: Bitmask.
> + *
> + *   Return: Return the shift bit position of the mask
> + */
>  static   u32 phy_CalculateBitShift(u32 BitMask)
>  {
>   u32 i;
> @@ -43,19 +38,17 @@ staticu32 phy_CalculateBitShift(u32 BitMask)
>  
>  
>  /**
> -* Function:  PHY_QueryBBReg
> -*
> -* OverView:  Read "specific bits" from BB register
> -*
> -* Input:
> -*struct adapter *Adapter,
> -*u32 RegAddr,The target address to be 
> readback
> -*u32 BitMask The target bit position in the 
> target address
> -*to be readback
> -* Output:None
> -* Return:u32 DataThe readback register 
> value
> -* Note:  This function is equal to "GetRegSetting" in PHY 
> programming guide
> -*/
> + *   PHY_QueryBBReg - Read "specific bits" from BB register.
> + *   @Adapter:
> + *   @RegAddr:   The target address to be readback
> + *   @BitMask:   The target bit position in the target address
> + *   to be readback
> + *
> + * Return:   The readback register value
> + *
> + * .. Note:: This function is equal to "GetRegSetting" in PHY programming
> + *   guide
> + */
>  u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32 RegAddr, u32 BitMask)
>  {
>   u32 OriginalValue, BitShift;
> @@ -64,7 +57,10 @@ u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32 
> RegAddr, u32 BitMask)
>   return 0;
>  #endif
>  
> - /* RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_QueryBBReg(): RegAddr(%#lx), 
> BitMask(%#lx)\n", RegAddr, BitMask)); */
> + /**
> +  * RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_QueryBBReg():
> +  * RegAddr(%#lx), BitMask(%#lx)\n", RegAddr, BitMask));
> +  */

Just delete this (in a separate patch).

>  
>   OriginalValue = rtw_read32(Adapter, RegAddr);
>   BitShift = phy_CalculateBitShift(BitMask);
> @@ -75,22 +71,17 @@ u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32 
> RegAddr, u32 BitMask)
>  
>  
>  /**
> -* Function:  PHY_SetBBReg
> -*
> -* OverView:  Write "Specific bits" to BB register (page 8~)
> -*
> -* Input:
> -*struct adapter *Adapter,
> -*u32 RegAddr,The target address to be 
> modified
> -*u32 BitMask The target bit position in the 
> target address
> -*to be modified
> -*u32 DataThe new register value in the 
> target bit position
> -*of the target 
> address
> -*
> -* Output:None
> -* Return:None
> -* Note:  This function is equal to "PutRegSetting" in PHY 
> programming guide
> -*/
> + *   PHY_SetBBReg - Write "Specific bits" to BB register (page 8~).
> + *   @Adapter:
> + *   @RegAddr:   The target address to be modified
> + *   @BitMask:   The target bit position in the target address
> + *   to be modified
> + *   @Data:  The new register value in the target bit position
> + *   of the target address
> + *
> + * .. Note:: This function is equal to "PutRegSetting" in PHY programming
> + *   guide
> + */
>  
>  void PHY_SetBBReg_8723B(
>   struct adapter *Adapter,
> @@ -106,7 +97,10 @@ void PHY_SetBBReg_8723B(
>   return;
>  #endif
>  
> - /* RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_SetBBReg(): RegAddr(%#lx), 
> BitMask(%#lx), Data(%#lx)\n", RegAddr, BitMask, Data)); */
> + /**
> +  * RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_SetBBReg():
> +  * RegAddr(%#lx), BitMask(%#lx), Data(%#lx)\n", RegAddr, BitMask, 
> Data));
> +  */

Delete.

>  
>   if (BitMask != bMaskDWord) { /* if not "double word" write */
>   OriginalValue = rtw_read32(Adapter, Reg

[PATCH v2 0/2] phy: amlogic: Add support for the G12A Analog MIPI D-PHY

[Neil Armstrong]

The Amlogic G12A SoCs embeds an Analog MIPI D-PHY to communicate with DSI
panels, this adds the bindings.

This Analog D-PHY works with a separate Digital MIPI D-PHY.

This serie adds the Bindings and the PHY driver.

Changes from v1 at [1]:
- Bindings fixes

[1] https://lore.kernel.org/r/20201123145157.300456-1-narmstr...@baylibre.com

Neil Armstrong (2):
  dt-bindings: phy: add Amlogic G12A Analog MIPI D-PHY bindings
  phy: amlogic: Add G12A Analog MIPI D-PHY driver

 .../phy/amlogic,g12a-mipi-dphy-analog.yaml|  35 
 drivers/phy/amlogic/Kconfig   |  12 ++
 drivers/phy/amlogic/Makefile  |   1 +
 .../amlogic/phy-meson-g12a-mipi-dphy-analog.c | 177 ++
 4 files changed, 225 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
 create mode 100644 drivers/phy/amlogic/phy-meson-g12a-mipi-dphy-analog.c

-- 
2.25.1

[PATCH v2 2/2] phy: amlogic: Add G12A Analog MIPI D-PHY driver

[Neil Armstrong]

The Amlogic G12A SoCs embeds an Analog MIPI D-PHY used to communicate with DSI
panels.

Signed-off-by: Neil Armstrong 
---
 drivers/phy/amlogic/Kconfig   |  12 ++
 drivers/phy/amlogic/Makefile  |   1 +
 .../amlogic/phy-meson-g12a-mipi-dphy-analog.c | 177 ++
 3 files changed, 190 insertions(+)
 create mode 100644 drivers/phy/amlogic/phy-meson-g12a-mipi-dphy-analog.c

diff --git a/drivers/phy/amlogic/Kconfig b/drivers/phy/amlogic/Kconfig
index db5d0cd757e3..ac898a102bcc 100644
--- a/drivers/phy/amlogic/Kconfig
+++ b/drivers/phy/amlogic/Kconfig
@@ -49,6 +49,18 @@ config PHY_MESON_G12A_USB3_PCIE
  in Meson G12A SoCs.
  If unsure, say N.
 
+config PHY_MESON_G12A_MIPI_DPHY_ANALOG
+   tristate "Meson G12A MIPI Analog DPHY driver"
+   default ARCH_MESON
+   depends on OF && (ARCH_MESON || COMPILE_TEST)
+   select GENERIC_PHY
+   select REGMAP_MMIO
+   select GENERIC_PHY_MIPI_DPHY
+   help
+ Enable this to support the Meson MIPI Analog DPHY found in Meson G12A
+ SoCs.
+ If unsure, say N.
+
 config PHY_MESON_AXG_PCIE
tristate "Meson AXG PCIE PHY driver"
default ARCH_MESON
diff --git a/drivers/phy/amlogic/Makefile b/drivers/phy/amlogic/Makefile
index 8fa07fbd0d92..2eada0a683ca 100644
--- a/drivers/phy/amlogic/Makefile
+++ b/drivers/phy/amlogic/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PHY_MESON8B_USB2)  += 
phy-meson8b-usb2.o
 obj-$(CONFIG_PHY_MESON_GXL_USB2)   += phy-meson-gxl-usb2.o
 obj-$(CONFIG_PHY_MESON_G12A_USB2)  += phy-meson-g12a-usb2.o
 obj-$(CONFIG_PHY_MESON_G12A_USB3_PCIE) += phy-meson-g12a-usb3-pcie.o
+obj-$(CONFIG_PHY_MESON_G12A_MIPI_DPHY_ANALOG)  += 
phy-meson-g12a-mipi-dphy-analog.o
 obj-$(CONFIG_PHY_MESON_AXG_PCIE)   += phy-meson-axg-pcie.o
 obj-$(CONFIG_PHY_MESON_AXG_MIPI_PCIE_ANALOG)   += 
phy-meson-axg-mipi-pcie-analog.o
 obj-$(CONFIG_PHY_MESON_AXG_MIPI_DPHY)  += phy-meson-axg-mipi-dphy.o
diff --git a/drivers/phy/amlogic/phy-meson-g12a-mipi-dphy-analog.c 
b/drivers/phy/amlogic/phy-meson-g12a-mipi-dphy-analog.c
new file mode 100644
index ..6e9d416c0552
--- /dev/null
+++ b/drivers/phy/amlogic/phy-meson-g12a-mipi-dphy-analog.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Meson G12A MIPI DSI Analog PHY
+ *
+ * Copyright (C) 2018 Amlogic, Inc. All rights reserved
+ * Copyright (C) 2020 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HHI_MIPI_CNTL0 0x00
+#defineHHI_MIPI_CNTL0_DIF_REF_CTL1 GENMASK(31, 16)
+#defineHHI_MIPI_CNTL0_DIF_REF_CTL0 GENMASK(15, 0)
+
+#define HHI_MIPI_CNTL1 0x04
+#defineHHI_MIPI_CNTL1_BANDGAP  BIT(16)
+#defineHHI_MIPI_CNTL2_DIF_REF_CTL2 GENMASK(15, 0)
+
+#define HHI_MIPI_CNTL2 0x08
+#defineHHI_MIPI_CNTL2_DIF_TX_CTL1  GENMASK(31, 16)
+#defineHHI_MIPI_CNTL2_CH_ENGENMASK(15, 11)
+#defineHHI_MIPI_CNTL2_DIF_TX_CTL0  GENMASK(10, 0)
+
+#define DSI_LANE_0 BIT(4)
+#define DSI_LANE_1 BIT(3)
+#define DSI_LANE_CLK   BIT(2)
+#define DSI_LANE_2 BIT(1)
+#define DSI_LANE_3 BIT(0)
+
+struct phy_g12a_mipi_dphy_analog_priv {
+   struct phy *phy;
+   struct regmap *regmap;
+   struct phy_configure_opts_mipi_dphy config;
+};
+
+static int phy_g12a_mipi_dphy_analog_configure(struct phy *phy,
+  union phy_configure_opts *opts)
+{
+   struct phy_g12a_mipi_dphy_analog_priv *priv = phy_get_drvdata(phy);
+   int ret;
+
+   ret = phy_mipi_dphy_config_validate(&opts->mipi_dphy);
+   if (ret)
+   return ret;
+
+   memcpy(&priv->config, opts, sizeof(priv->config));
+
+   return 0;
+}
+
+static int phy_g12a_mipi_dphy_analog_power_on(struct phy *phy)
+{
+   struct phy_g12a_mipi_dphy_analog_priv *priv = phy_get_drvdata(phy);
+   unsigned int reg;
+
+   regmap_write(priv->regmap, HHI_MIPI_CNTL0,
+FIELD_PREP(HHI_MIPI_CNTL0_DIF_REF_CTL0, 0x8) |
+FIELD_PREP(HHI_MIPI_CNTL0_DIF_REF_CTL1, 0xa487));
+
+   regmap_write(priv->regmap, HHI_MIPI_CNTL1,
+FIELD_PREP(HHI_MIPI_CNTL2_DIF_REF_CTL2, 0x2e) |
+HHI_MIPI_CNTL1_BANDGAP);
+
+   regmap_write(priv->regmap, HHI_MIPI_CNTL2,
+FIELD_PREP(HHI_MIPI_CNTL2_DIF_TX_CTL0, 0x459) |
+FIELD_PREP(HHI_MIPI_CNTL2_DIF_TX_CTL1, 0x2680));
+
+   reg = DSI_LANE_CLK;
+   switch (priv->config.lanes) {
+   case 4:
+   reg |= DSI_LANE_3;
+   fallthrough;
+   case 3:
+   reg |= DSI_LANE_2;
+   fallthr

[PATCH v2 1/2] dt-bindings: phy: add Amlogic G12A Analog MIPI D-PHY bindings

[Neil Armstrong]

The Amlogic G12A SoCs embeds an Analog MIPI D-PHY to communicate with DSI
panels, this adds the bindings.

This Analog D-PHY works with a separate Digital MIPI D-PHY.

Signed-off-by: Neil Armstrong 
---
 .../phy/amlogic,g12a-mipi-dphy-analog.yaml| 35 +++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml

diff --git 
a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml 
b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
new file mode 100644
index ..14bb8d78a860
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Amlogic G12A MIPI analog PHY
+
+maintainers:
+  - Neil Armstrong 
+
+properties:
+  compatible:
+const: amlogic,g12a-mipi-dphy-analog
+
+  "#phy-cells":
+const: 0
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+phy@0 {
+  compatible = "amlogic,g12a-mipi-dphy-analog";
+  #phy-cells = <0>;
+  reg = <0>;
+};
-- 
2.25.1

Re: [PATCH 1/5] ath10k: fix conf_mutex lock assert in ath10k_debug_fw_stats_request()

[Kalle Valo]

Shuah Khan  wrote:

> ath10k_debug_fw_stats_request() is called ath10k_sta_statistics()
> without holding conf_mutex. ath10k_debug_fw_stats_request() simply
> returns when CONFIG_ATH10K_DEBUGFS is disabled.
> 
> When CONFIG_ATH10K_DEBUGFS is enabled, ath10k_debug_fw_stats_request()
> code path isn't protected. This assert is triggered when CONFIG_LOCKDEP
> and CONFIG_ATH10K_DEBUGFS are enabled.
> 
> All other ath10k_debug_fw_stats_request() callers hold conf_mutex.
> Fix ath10k_sta_statistics() to do the same.
> 
> WARNING: CPU: 5 PID: 696 at drivers/net/wireless/ath/ath10k/debug.c:357 
> ath10k_debug_fw_stats_request+0x29a/0x2d0 [ath10k_core]
> Modules linked in: rfcomm ccm fuse cmac algif_hash algif_skcipher af_alg bnep 
> binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common 
> snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi 
> snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm 
> amdgpu snd_seq_midi snd_seq_midi_event snd_rawmidi edac_mce_amd snd_seq 
> ath10k_pci ath10k_core aesni_intel gpu_sched drm_ttm_helper btusb ttm 
> glue_helper crypto_simd btrtl ath cryptd drm_kms_helper snd_seq_device btbcm 
> snd_timer rapl btintel cec i2c_algo_bit mac80211 bluetooth fb_sys_fops 
> input_leds ecdh_generic snd wmi_bmof syscopyarea ecc serio_raw efi_pstore ccp 
> k10temp sysfillrect soundcore sysimgblt snd_pci_acp3x cfg80211 ipmi_devintf 
> libarc4 ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport drm 
> ip_tables x_tables autofs4 hid_generic usbhid hid crc32_pclmul psmouse ahci 
> nvme libahci i2c_piix4 nvme_core r8169 realtek wmi video
> CPU: 5 PID: 696 Comm: NetworkManager Tainted: GW 5.11.0-rc7+ 
> #20
> Hardware name: LENOVO 10VGCTO1WW/3130, BIOS M1XKT45A 08/21/2019
> RIP: 0010:ath10k_debug_fw_stats_request+0x29a/0x2d0 [ath10k_core]
> Code: 83 c4 10 44 89 f8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8d bf e8 20 00 00 
> be ff ff ff ff e8 de 2d 47 fa 85 c0 0f 85 8d fd ff ff <0f> 0b e9 86 fd ff ff 
> 41 bf a1 ff ff ff 44 89 fa 48 c7 c6 2c 71 c4
> RSP: 0018:affbc124b7d0 EFLAGS: 00010246
> RAX:  RBX: 93d02e4fec70 RCX: 0001
> RDX:  RSI: 93d00cba5248 RDI: 93d00ab309a0
> RBP: affbc124b808 R08:  R09: 93d02e4fec70
> R10: 0001 R11: 0246 R12: 93d00cba3160
> R13: 93d00cba3160 R14: 93d02e4fe4f0 R15: 0001
> FS:  7f7ce8d50bc0() GS:93d137d4() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fc3595ad160 CR3: 00010d492000 CR4: 003506e0
> Call Trace:
>  ? sta_info_get_bss+0xeb/0x1f0 [mac80211]
>  ath10k_sta_statistics+0x4f/0x280 [ath10k_core]
>  sta_set_sinfo+0xda/0xd20 [mac80211]
>  ieee80211_get_station+0x58/0x80 [mac80211]
>  nl80211_get_station+0xbd/0x340 [cfg80211]
>  genl_family_rcv_msg_doit+0xe7/0x150
>  genl_rcv_msg+0xe2/0x1e0
>  ? nl80211_dump_station+0x3a0/0x3a0 [cfg80211]
>  ? nl80211_send_station+0xef0/0xef0 [cfg80211]
>  ? genl_get_cmd+0xd0/0xd0
>  netlink_rcv_skb+0x55/0x100
>  genl_rcv+0x29/0x40
>  netlink_unicast+0x1a8/0x270
>  netlink_sendmsg+0x253/0x480
>  sock_sendmsg+0x65/0x70
>  sys_sendmsg+0x219/0x260
>  ? __import_iovec+0x32/0x170
>  ___sys_sendmsg+0xb7/0x100
>  ? end_opal_session+0x39/0xd0
>  ? __fget_files+0xe0/0x1d0
>  ? find_held_lock+0x31/0x90
>  ? __fget_files+0xe0/0x1d0
>  ? __fget_files+0x103/0x1d0
>  ? __fget_light+0x32/0x80
>  __sys_sendmsg+0x5a/0xa0
>  ? syscall_enter_from_user_mode+0x21/0x60
>  __x64_sys_sendmsg+0x1f/0x30
>  do_syscall_64+0x38/0x50
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f7cea2c791d
> Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 4a ee ff ff 8b 54 24 1c 48 
> 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 
> 33 44 89 c7 48 89 44 24 08 e8 9e ee ff ff 48
> RSP: 002b:7ffedf612a30 EFLAGS: 0293 ORIG_RAX: 002e
> RAX: ffda RBX: 5618c4cfec00 RCX: 7f7cea2c791d
> RDX:  RSI: 7ffedf612a80 RDI: 000b
> RBP: 7ffedf612a80 R08:  R09: 5618c4e74000
> R10: 5618c4da0590 R11: 0293 R12: 5618c4cfec00
> R13: 5618c4cfe2c0 R14: 7f7cea32ef80 R15: 5618c4cff340
> irq event stamp: 520897
> hardirqs last  enabled at (520903): [] 
> console_unlock+0x4e5/0x5d0
> hardirqs last disabled at (520908): [] 
> console_unlock+0x458/0x5d0
> softirqs last  enabled at (520722): [] 
> asm_call_irq_on_stack+0x12/0x20
> softirqs last disabled at (520717): [] 
> asm_call_irq_on_stack+0x12/0x20
> 
> Signed-off-by: Shuah Khan 

Bad timing, just yesterday I applied an identical patch: 

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=7df28718928d08034b36168200d67b558ce36f3d

Patch set to Superseded.

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/1c38ef6d39ed89a564bc817d964d923ff0676c53.1612915444.git.sk...@linu

Re: [PATCH] virtio-mmio: Use to_virtio_mmio_device() to simply code

[Jason Wang]

On 2021/2/10 上午11:04, Tang Bin wrote:

The file virtio_mmio.c has defined the function to_virtio_mmio_device,
so use it instead of container_of() to simply code. And remove
superfluous blank lines in this file.

Signed-off-by: Tang Bin 
---
  drivers/virtio/virtio_mmio.c | 16 +---
  1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 627ac0487..449d0f209 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -69,14 +69,10 @@
  #include 
  #include 
  
-

-



It's better not mix the patch with style changes.

Other looks good.

Thanks



  /* The alignment to use between consumer and producer parts of vring.
   * Currently hardcoded to the page size. */
  #define VIRTIO_MMIO_VRING_ALIGN   PAGE_SIZE
  
-

-
  #define to_virtio_mmio_device(_plat_dev) \
container_of(_plat_dev, struct virtio_mmio_device, vdev)
  
@@ -100,8 +96,6 @@ struct virtio_mmio_vq_info {

struct list_head node;
  };
  
-

-
  /* Configuration interface */
  
  static u64 vm_get_features(struct virtio_device *vdev)

@@ -264,8 +258,6 @@ static void vm_reset(struct virtio_device *vdev)
writel(0, vm_dev->base + VIRTIO_MMIO_STATUS);
  }
  
-

-
  /* Transport interface */
  
  /* the notify function used when creating a virt queue */

@@ -307,8 +299,6 @@ static irqreturn_t vm_interrupt(int irq, void *opaque)
return ret;
  }
  
-

-
  static void vm_del_vq(struct virtqueue *vq)
  {
struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vq->vdev);
@@ -512,13 +502,11 @@ static const struct virtio_config_ops 
virtio_mmio_config_ops = {
.bus_name   = vm_bus_name,
  };
  
-

  static void virtio_mmio_release_dev(struct device *_d)
  {
struct virtio_device *vdev =
container_of(_d, struct virtio_device, dev);
-   struct virtio_mmio_device *vm_dev =
-   container_of(vdev, struct virtio_mmio_device, vdev);
+   struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
struct platform_device *pdev = vm_dev->pdev;
  
  	devm_kfree(&pdev->dev, vm_dev);

@@ -608,8 +596,6 @@ static int virtio_mmio_remove(struct platform_device *pdev)
return 0;
  }
  
-

-
  /* Devices list parameter */
  
  #if defined(CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES)

Re: [PATCH] clk: at91: sama5d2: Mark device OF_POPULATED after setup

[Tudor.Ambarus]

Hi, Saravana,

On 2/9/21 9:06 PM, Saravana Kannan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
> On Tue, Feb 9, 2021 at 7:21 AM  wrote:
>>
>> Hi, Saravana,
>>
>> On 2/9/21 11:11 AM, Saravana Kannan wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
>>> content is safe
>>>
>>> On Mon, Feb 8, 2021 at 11:55 PM Stephen Boyd  wrote:

 Quoting Saravana Kannan (2021-01-28 09:01:41)
> On Thu, Jan 28, 2021 at 2:45 AM Tudor Ambarus
>  wrote:
>>
>> The sama5d2 requires the clock provider initialized before timers.
>> We can't use a platform driver for the sama5d2-pmc driver, as the
>> platform_bus_init() is called later on, after time_init().
>>
>> As fw_devlink considers only devices, it does not know that the
>> pmc is ready. Hence probing of devices that depend on it fail:
>> probe deferral - supplier f0014000.pmc not ready
>>
>> Fix this by setting the OF_POPULATED flag for the sama5d2_pmc
>> device node after successful setup. This will make
>> of_link_to_phandle() ignore the sama5d2_pmc device node as a
>> dependency, and consumer devices will be probed again.
>>
>> Fixes: e590474768f1cc04 ("driver core: Set fw_devlink=on by default")
>> Signed-off-by: Tudor Ambarus 
>> ---
>> I'll be out of office, will check the rest of the at91 SoCs
>> at the begining of next week.
>>
>>  drivers/clk/at91/sama5d2.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
>> index 9a5cbc7cd55a..5eea2b4a63dd 100644
>> --- a/drivers/clk/at91/sama5d2.c
>> +++ b/drivers/clk/at91/sama5d2.c
>> @@ -367,6 +367,8 @@ static void __init sama5d2_pmc_setup(struct 
>> device_node *np)
>>
>> of_clk_add_hw_provider(np, of_clk_hw_pmc_get, sama5d2_pmc);
>>
>> +   of_node_set_flag(np, OF_POPULATED);
>> +
>> return;
>
> Hi Tudor,
>
> Thanks for looking into this.
>
> I already accounted for early clocks like this when I designed
> fw_devlink. Each driver shouldn't need to set OF_POPULATED.
> drivers/clk/clk.c already does this for you.
>
> I think the problem is that your driver is using
> CLK_OF_DECLARE_DRIVER() instead of CLK_OF_DECLARE(). The comments for
> CLK_OF_DECLARE_DRIVER() says:
> /*
>  * Use this macro when you have a driver that requires two initialization
>  * routines, one at of_clk_init(), and one at platform device probe
>  */
>
> In your case, you are explicitly NOT having a driver bind to this
> clock later. So you shouldn't be using CLK_OF_DECLARE() instead.
>

 I see

 drivers/power/reset/at91-sama5d2_shdwc.c:   { .compatible = 
 "atmel,sama5d2-pmc" },

 so isn't that the driver that wants to bind to the same device node
 again? First at of_clk_init() time here and then second for the reset
 driver?
>>>
>>> You are right. I assumed that when Tudor was setting OF_POPULATED,
>>
>> No, there's a single driver that binds to that compatible.
>>
>>> they didn't want to create a struct device and they knew it was right
>>> for their platform.
>>>
>>> However...
>>> $ git grep "atmel,sama5d2-pmc"
>>> arch/arm/boot/dts/sama5d2.dtsi: compatible =
>>> "atmel,sama5d2-pmc", "syscon";
>>> arch/arm/mach-at91/pm.c:{ .compatible = "atmel,sama5d2-pmc",
>>> .data = &pmc_infos[1] },
>>> drivers/clk/at91/pmc.c: { .compatible = "atmel,sama5d2-pmc" },
>>> drivers/clk/at91/sama5d2.c:CLK_OF_DECLARE_DRIVER(sama5d2_pmc,
>>> "atmel,sama5d2-pmc", sama5d2_pmc_setup);
>>> drivers/power/reset/at91-sama5d2_shdwc.c:   { .compatible =
>>> "atmel,sama5d2-pmc" },
>>>
>>> Geez! How many drivers are there for this one device. Clearly not all
>>> of them are going to bind. But I'm not going to dig into this. You can
>>
>> From this entire list only the drivers/clk/at91/sama5d2.c driver binds to the
>> "atmel,sama5d2-pmc" compatible, the rest are just using the compatible to
>> map the PMC memory.
>>
>>> reject this patch. I expect this series [1] to take care of the issue
>>> Tudor was trying to fix.
>>>
>>> Tudor,
>>>
>>> Want to give this series [1] a shot?
>>
>> The series at [1] doesn't apply clean neither on next-20210209, nor on
>> driver-core-next. On top of which sha1 should I apply them?
> 
> It's on top of driver-core-next:
> 4731210c09f5 gpiolib: Bind gpio_device to a driver to enable
> fw_devlink=on by default

I see Greg took your series. I tried the driver-core-next (with your series
included), it doesn't solve my boot problem on sama5d2_xplained.

With [2] applied, sama5d2_xplained can boot again.

Cheers,
ta

> 
>> Anyway, I think the patch at [2] is still needed, regardless of the outcome
>> of [1].
> 
> Right, [2] is still a good clean up based on your comment above

Re: [PATCH] x86, sched: Allow NUMA nodes to share an LLC on Intel platforms

[Peter Zijlstra]

On Tue, Feb 09, 2021 at 11:09:27PM +, Luck, Tony wrote:
> > +#define X86_BUG_NUMA_SHARES_LLCX86_BUG(25) /* CPU may 
> > enumerate an LLC shared by multiple NUMA nodes */
> 
> During internal review I wondered why this is a "BUG" rather than a "FEATURE" 
> bit.
> 
> Apparently, the suggestion for "BUG" came from earlier community discussions.
> 
> Historically it may have seemed reasonable to say that a cache cannot span
> NUMA domains. But with more and more things moving off the motherboard
> and into the socket, this doesn't seem too weird now.

If you look at the details this SNC LLC span doesn't behave quite right
either.

It really isn't a regular cache, but behaves a bit like a mash-up of the
s390 book caches and a normal LLC.

Did anybody play with adding the book domain to these SNC
configurations? Can we detect SNC other than by this quirk?

[PATCH] net: dsa: mv88e6xxx: NET_DSA_MV88E6XXX_PTP should depend on NET_DSA_MV88E6XXX

[Geert Uytterhoeven]

Making global2 support mandatory removed the Kconfig symbol
NET_DSA_MV88E6XXX_GLOBAL2.  This symbol also served as an intermediate
symbol to make NET_DSA_MV88E6XXX_PTP depend on NET_DSA_MV88E6XXX.  With
the symbol removed, the user is always asked about PTP support for
Marvell 88E6xxx switches, even if the latter support is not enabled.

Fix this by reinstating the dependency.

Fixes: 63368a7416df144b ("net: dsa: mv88e6xxx: Make global2 support mandatory")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/net/dsa/mv88e6xxx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/Kconfig 
b/drivers/net/dsa/mv88e6xxx/Kconfig
index 05af632b0f597da9..634a48e6616b953a 100644
--- a/drivers/net/dsa/mv88e6xxx/Kconfig
+++ b/drivers/net/dsa/mv88e6xxx/Kconfig
@@ -12,7 +12,7 @@ config NET_DSA_MV88E6XXX
 config NET_DSA_MV88E6XXX_PTP
bool "PTP support for Marvell 88E6xxx"
default n
-   depends on PTP_1588_CLOCK
+   depends on NET_DSA_MV88E6XXX && PTP_1588_CLOCK
help
  Say Y to enable PTP hardware timestamping on Marvell 88E6xxx switch
  chips that support it.
-- 
2.25.1

Re: [PATCH 2/2] arm64: dts: meson: add initial device-tree for Minix NEO U9-H

[Neil Armstrong]

On 01/02/2021 22:05, Christian Hewitt wrote:
> Minix NEO U9-H is based on the Amlogic Q200 reference board with an
> S912-H chip and the following specs:
> 
> - 2GB DDR3 RAM
> - 16GB eMMC
> - 10/100/1000 Base-T Ethernet
> - AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
> - RTC chip
> - HDMI 2.1 video
> - S/PDIF optical output
> - ES8323 audio codec
> - Analogue headphone output
> - 3x USB 2.0 ports (1x OTG)
> - IR receiver
> - 1x Power LED (white)
> - 1x Power button (rear)
> - 1x Update/Reset button (underside)
> - 1x micro SD card slot
> 
> Tested-by: Wes Bradley 
> Signed-off-by: Christian Hewitt 
> ---
>  arch/arm64/boot/dts/amlogic/Makefile  |   1 +
>  .../dts/amlogic/meson-gxm-minix-neo-u9h.dts   | 120 ++
>  2 files changed, 121 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts
> 
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
> b/arch/arm64/boot/dts/amlogic/Makefile
> index dce41cd3f347..46e67de3d6d2 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -38,6 +38,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905w-p281.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905w-tx3-mini.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-libretech-pc.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-gxm-khadas-vim2.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-minix-neo-u9h.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts 
> b/arch/arm64/boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts
> new file mode 100644
> index ..a414cd39c2b1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) Christian Hewitt 
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-gxm.dtsi"
> +#include "meson-gx-p23x-q20x.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + compatible = "minix,neo-u9h", "amlogic,s912", "amlogic,meson-gxm";
> + model = "Minix Neo U9-H";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + white {
> + color = ;
> + function = LED_FUNCTION_POWER;
> + gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + panic-indicator;
> + };
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 0>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <171>;
> +
> + button-function {
> + label = "update";
> + linux,code = ;
> + press-threshold-microvolt = <1>;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <100>;
> +
> + button@0 {
> + label = "power";
> + linux,code = ;
> + gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +ðmac {
> + pinctrl-0 = <ð_pins>;
> + pinctrl-names = "default";
> + phy-handle = <&external_phy>;
> + amlogic,tx-delay-ns = <2>;
> + phy-mode = "rgmii";
> +};
> +
> +&external_mdio {
> + external_phy: ethernet-phy@0 {
> + /* Realtek RTL8211F (0x001cc916) */
> + reg = <0>;
> + max-speed = <1000>;
> +
> + reset-assert-us = <1>;
> + reset-deassert-us = <8>;
> + reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
> +
> + interrupt-parent = <&gpio_intc>;
> + /* MAC_INTR on GPIOZ_15 */
> + interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +&ir {
> + linux,rc-map-name = "rc-minix-neo";
> +};
> +
> +&i2c_B {
> + status = "okay";
> + pinctrl-0 = <&i2c_b_pins>;
> + pinctrl-names = "default";
> +
> + rtc: rtc@51 {
> + status = "okay";
> + compatible = "haoyu,hym8563";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + clock-output-names = "xin32k";
> + wakeup-source;
> + };
> +};
> +
> +&sd_emmc_a {
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + };
> +};
> +
> +&uart_A {
> + status = "okay";
> + pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
> + pinctrl-names = "default";
> + uart-has-rtscts;
> +
> + bluetooth {
> + compatible = "brcm,bcm43438-bt";
> + shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
> + 

Re: [PATCH 2/5] ath10k: fix WARNING: suspicious RCU usage

[Kalle Valo]

Shuah Khan  wrote:

> ieee80211_find_sta_by_ifaddr() must be called under the RCU lock and
> the resulting pointer is only valid under RCU lock as well.
> 
> Fix ath10k_wmi_tlv_parse_peer_stats_info() to hold RCU lock before it
> calls ieee80211_find_sta_by_ifaddr() and release it when the resulting
> pointer is no longer needed. The log below shows the problem.
> 
> While at it, fix ath10k_wmi_tlv_op_pull_peer_stats_info() to do the same.
> 
> =
> WARNING: suspicious RCU usage
> 5.11.0-rc7+ #20 Tainted: GW
> -
> include/linux/rhashtable.h:594 suspicious rcu_dereference_check() usage!
> other info that might help us debug this:
>rcu_scheduler_active = 2, debug_locks = 1
> no locks held by ksoftirqd/5/44.
> 
> stack backtrace:
> CPU: 5 PID: 44 Comm: ksoftirqd/5 Tainted: GW 5.11.0-rc7+ #20
> Hardware name: LENOVO 10VGCTO1WW/3130, BIOS M1XKT45A 08/21/2019
> Call Trace:
>  dump_stack+0x7d/0x9f
>  lockdep_rcu_suspicious+0xdb/0xe5
>  __rhashtable_lookup+0x1eb/0x260 [mac80211]
>  ieee80211_find_sta_by_ifaddr+0x5b/0xc0 [mac80211]
>  ath10k_wmi_tlv_parse_peer_stats_info+0x3e/0x90 [ath10k_core]
>  ath10k_wmi_tlv_iter+0x6a/0xc0 [ath10k_core]
>  ? ath10k_wmi_tlv_op_pull_mgmt_tx_bundle_compl_ev+0xe0/0xe0 [ath10k_core]
>  ath10k_wmi_tlv_op_rx+0x5da/0xda0 [ath10k_core]
>  ? trace_hardirqs_on+0x54/0xf0
>  ? ath10k_ce_completed_recv_next+0x4e/0x60 [ath10k_core]
>  ath10k_wmi_process_rx+0x1d/0x40 [ath10k_core]
>  ath10k_htc_rx_completion_handler+0x115/0x180 [ath10k_core]
>  ath10k_pci_process_rx_cb+0x149/0x1b0 [ath10k_pci]
>  ? ath10k_htc_process_trailer+0x2d0/0x2d0 [ath10k_core]
>  ? ath10k_pci_sleep.part.0+0x6a/0x80 [ath10k_pci]
>  ath10k_pci_htc_rx_cb+0x15/0x20 [ath10k_pci]
>  ath10k_ce_per_engine_service+0x61/0x80 [ath10k_core]
>  ath10k_ce_per_engine_service_any+0x7d/0xa0 [ath10k_core]
>  ath10k_pci_napi_poll+0x48/0x120 [ath10k_pci]
>  net_rx_action+0x136/0x500
>  __do_softirq+0xc6/0x459
>  ? smpboot_thread_fn+0x2b/0x1f0
>  run_ksoftirqd+0x2b/0x60
>  smpboot_thread_fn+0x116/0x1f0
>  kthread+0x14b/0x170
>  ? smpboot_register_percpu_thread+0xe0/0xe0
>  ? __kthread_bind_mask+0x70/0x70
>  ret_from_fork+0x22/0x30
> 
> Signed-off-by: Shuah Khan 

Unlucky timing also on this one, it conflicts with a patch I applied yesterday:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=2615e3cdbd9c0e864f5906279c952a309871d225

Can you redo the patch to only change ath10k_wmi_event_tdls_peer()?

error: patch failed: drivers/net/wireless/ath/ath10k/wmi-tlv.c:240
error: drivers/net/wireless/ath/ath10k/wmi-tlv.c: patch does not apply
stg import: Diff does not apply cleanly

Patch set to Changes Requested.

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/23a1333dfb0367cc69e7177a2e373df0b6d42980.1612915444.git.sk...@linuxfoundation.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] MAINTAINERS: replace non-matching patterns for loongson{2,3}

[Joe Perches]

On Wed, 2021-02-10 at 08:59 +0100, Lukas Bulwahn wrote:
> Commit ffe1f9356fbe ("MAINTAINERS: Add Loongson-2/Loongson-3 maintainers")
> adds quite generic file entries for drivers/*/*loongson{2,3}* and
> drivers/*/*/*loongson{2,3}* to be informed on changes to all loongson{2,3}
> files in drivers.
> 
> However, only the pattern 'drivers/*/*loongson2*' matches to one file in
> the repository, i.e., drivers/cpufreq/loongson2_cpufreq.c; all other
> patterns have no file matches.

Thank you.  I hope one day it gets applied...

https://lore.kernel.org/linux-mips/20190325212717.27044-1-...@perches.com/
https://lore.kernel.org/linux-mips/20180928215928.30611-1-...@perches.com/
https://lore.kernel.org/linux-mips/20180928220034.30697-1-...@perches.com/

[PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits

[Amit Pundir]

From: Sumit Semwal 

Enabling the Display panel for beryllium requires DSI
labibb regulators and panel dts nodes to be added.
It is also required to keep some of the regulators as
always-on.

Signed-off-by: Sumit Semwal 
Signed-off-by: Amit Pundir 
---
v3: Addressed Konrad's concerns. Configured labibb regulators
explicitly based on downstream microvolt values. Display
comes up fine with default discharge-resistor-kohms and
soft-start-us properties, so didn't touch them.
Smoke tested on next-20210209.
v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.

 .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts  | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts 
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index 86cbae63eaf7..5ac049a247e1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -157,6 +157,14 @@
regulator-initial-mode = ;
};
 
+   vreg_l14a_1p8: ldo14 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-initial-mode = ;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -191,6 +199,7 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+   regulator-boot-on;
};
};
 };
@@ -200,6 +209,43 @@
firmware-name = "qcom/sdm845/cdsp.mdt";
 };
 
+&dsi0 {
+   status = "okay";
+   vdda-supply = <&vreg_l26a_1p2>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel@0 {
+   compatible = "tianma,fhd-video";
+   reg = <0>;
+   vddi0-supply = <&vreg_l14a_1p8>;
+   vddpos-supply = <&lab>;
+   vddneg-supply = <&ibb>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+
+   port {
+   tianma_nt36672a_in_0: endpoint {
+   remote-endpoint = <&dsi0_out>;
+   };
+   };
+   };
+};
+
+&dsi0_out {
+   remote-endpoint = <&tianma_nt36672a_in_0>;
+   data-lanes = <0 1 2 3>;
+};
+
+&dsi0_phy {
+   status = "okay";
+   vdds-supply = <&vreg_l1a_0p875>;
+};
+
 &gcc {
protected-clocks = ,
   ,
@@ -215,6 +261,24 @@
};
 };
 
+&ibb {
+   regulator-min-microvolt = <460>;
+   regulator-max-microvolt = <600>;
+};
+
+&lab {
+   regulator-min-microvolt = <460>;
+   regulator-max-microvolt = <600>;
+};
+
+&mdss {
+   status = "okay";
+};
+
+&mdss_mdp {
+   status = "okay";
+};
+
 &mss_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
-- 
2.7.4

Re: [PATCH RESEND v2 4/5] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

[Nicolin Chen]

Hi Guillaume,

On Sat, Feb 06, 2021 at 01:40:13PM +, Guillaume Tucker wrote:
> > It'd be nicer if I can get both logs of the vanilla kernel (failing)
> > and the commit-reverted version (passing), each applying this patch.
> 
> Sure, I've run 3 jobs:
> 
> * v5.11-rc6 as a reference, to see the original issue:
>   https://lava.collabora.co.uk/scheduler/job/3187848
> 
> * + your debug patch:
>   https://lava.collabora.co.uk/scheduler/job/3187849
> 
> * + the "breaking" commit reverted, passing the tests:
>   https://lava.collabora.co.uk/scheduler/job/3187851

Thanks for the help!

I am able to figure out what's probably wrong, yet not so sure
about the best solution at this point.

Would it be possible for you to run one more time with another
debugging patch? I'd like to see the same logs as previous:
1. Vanilla kernel + debug patch
2. Vanilla kernel + Reverted + debug patch

Thank you
Nicolin
>From dce84731e12900b0e98dffc0ff981638a0bb3405 Mon Sep 17 00:00:00 2001
From: Nicolin Chen 
Date: Fri, 5 Feb 2021 01:41:07 -0800
Subject: [PATCH] iommu: debug tegra-smmu v2

Signed-off-by: Nicolin Chen 
---
 arch/arm/mm/dma-mapping.c   |  6 +++--
 drivers/gpu/drm/tegra/dc.c  |  1 +
 drivers/gpu/drm/tegra/drm.c |  4 +++
 drivers/iommu/iommu.c   | 47 +++--
 drivers/iommu/tegra-smmu.c  | 31 +-
 drivers/memory/tegra/tegra124.c |  2 ++
 6 files changed, 80 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c4b8df2ad328..6a6715817707 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2136,13 +2136,15 @@ static int __arm_iommu_attach_device(struct device *dev,
 	int err;
 
 	err = iommu_attach_device(mapping->domain, dev);
-	if (err)
+	if (err) {
+		dev_alert(dev, "--%s failed with err: %d", __func__, err);
 		return err;
+	}
 
 	kref_get(&mapping->kref);
 	to_dma_iommu_mapping(dev) = mapping;
 
-	pr_debug("Attached IOMMU controller to %s device.\n", dev_name(dev));
+	pr_alert("Attached IOMMU controller to %s device.\n", dev_name(dev));
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0ae3a025efe9..96af9186e81a 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2033,6 +2033,7 @@ static int tegra_dc_init(struct host1x_client *client)
 	struct drm_plane *cursor = NULL;
 	int err;
 
+	dev_alert(dc->dev, "---%s, %d\n", __func__, __LINE__);
 	/*
 	 * XXX do not register DCs with no window groups because we cannot
 	 * assign a primary plane to them, which in turn will cause KMS to
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e9ce7d6992d2..ea6bf26f4df3 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -906,6 +906,7 @@ int host1x_client_iommu_attach(struct host1x_client *client)
 	struct iommu_group *group = NULL;
 	int err;
 
+	dev_alert(client->dev, "---%s, %d\n", __func__, __LINE__);
 	/*
 	 * If the host1x client is already attached to an IOMMU domain that is
 	 * not the shared IOMMU domain, don't try to attach it to a different
@@ -914,7 +915,9 @@ int host1x_client_iommu_attach(struct host1x_client *client)
 	if (domain && domain != tegra->domain)
 		return 0;
 
+	dev_alert(client->dev, "---%s, %d\n", __func__, __LINE__);
 	if (tegra->domain) {
+	dev_alert(client->dev, "---%s, %d\n", __func__, __LINE__);
 		group = iommu_group_get(client->dev);
 		if (!group)
 			return -ENODEV;
@@ -932,6 +935,7 @@ int host1x_client_iommu_attach(struct host1x_client *client)
 
 	client->group = group;
 
+	dev_alert(client->dev, "---%s, %d\n", __func__, __LINE__);
 	return 0;
 }
 
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba84..890c7c7ecf94 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -220,6 +220,7 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
 
 	group = iommu_group_get_for_dev(dev);
 	if (IS_ERR(group)) {
+		dev_alert(dev, "-%s, %d\n", __func__, __LINE__);
 		ret = PTR_ERR(group);
 		goto out_release;
 	}
@@ -268,7 +269,9 @@ int iommu_probe_device(struct device *dev)
 	 */
 	iommu_alloc_default_domain(group, dev);
 
+	dev_alert(dev, "-%s, %d\n", __func__, __LINE__);
 	if (group->default_domain) {
+		dev_alert(dev, "-%s, %d\n", __func__, __LINE__);
 		ret = __iommu_attach_device(group->default_domain, dev);
 		if (ret) {
 			iommu_group_put(group);
@@ -852,8 +855,11 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
 
 	mutex_lock(&group->mutex);
 	list_add_tail(&device->list, &group->devices);
-	if (group->domain  && !iommu_is_attach_deferred(group->domain, dev))
+	dev_alert(dev, "-%s, %d\n", __func__, __LINE__);
+	if (group->domain  && !iommu_is_attach_deferred(group->domain, dev)) {
+		dev_alert(dev, "-%s, %d\n", __func__, __LINE__);
 		ret = __iommu_attach_device(g

Re: [PATCH v4 0/8] Make fw_devlink=on more forgiving

[Tudor.Ambarus]

Hi, Saravana,

On 2/6/21 12:26 AM, Saravana Kannan wrote:
> There are a lot of devices/drivers where they never have a struct device
> created for them or the driver initializes the hardware without ever
> binding to the struct device.
> 
> This series is intended to avoid any boot regressions due to such
> devices/drivers when fw_devlink=on and also address the handling of
> optional suppliers.
> 
> Patch 1 and 2 addresses the issue of firmware nodes that look like
> they'll have struct devices created for them, but will never actually
> have struct devices added for them. For example, DT nodes with a
> compatible property that don't have devices added for them.
> 
> Patch 3 and 4 allow for handling optional DT bindings.
> 
> Patch 5 sets up a generic API to handle drivers that never bind with
> their devices.
> 
> Patch 6 through 8 update different frameworks to use the new API.
> 
> Thanks,
> Saravana
> 
> Saravana Kannan (8):
>   driver core: fw_devlink: Detect supplier devices that will never be
> added
>   of: property: Don't add links to absent suppliers
>   driver core: Add fw_devlink.strict kernel param
>   of: property: Add fw_devlink support for optional properties
>   driver core: fw_devlink: Handle suppliers that don't use driver core
>   irqdomain: Mark fwnodes when their irqdomain is added/removed
>   PM: domains: Mark fwnodes when their powerdomain is added/removed
>   clk: Mark fwnodes when their clock provider is added/removed
> 
>  .../admin-guide/kernel-parameters.txt |  5 ++
>  drivers/base/core.c   | 58 ++-
>  drivers/base/power/domain.c   |  2 +
>  drivers/clk/clk.c |  3 +
>  drivers/of/property.c | 16 +++--
>  include/linux/fwnode.h| 20 ++-
>  kernel/irq/irqdomain.c|  2 +
>  7 files changed, 98 insertions(+), 8 deletions(-)
> 

Even with this patch set applied, sama5d2_xplained can not boot.
Patch at [1] makes sama5d2_xplained boot again. Stephen applied it
to clk-next.

Cheers,
ta

[1] 
https://lore.kernel.org/lkml/20210203154332.470587-1-tudor.amba...@microchip.com/

Re: [PATCH RFC 6/6] btrfs: Add roundrobin raid1 read policy

[Anand Jain]

On 10/02/2021 04:30, Michal Rostecki wrote:

From: Michal Rostecki 

Add a new raid1 read policy `roundrobin`. For each read request, it
selects the mirror which has lower load than queue depth and it starts
iterating from the last used mirror (by the current CPU). Load is
defined as the number of inflight requests + a potential penalty value.

The policy can be enabled through sysfs:

   # echo roundrobin > /sys/fs/btrfs/[fsid]/read_policies/policy

This policy was tested with fio and compared with the default `pid`
policy.

The singlethreaded test has the following parameters:

   [global]
   name=btrfs-raid1-seqread
   filename=btrfs-raid1-seqread
   rw=read
   bs=64k
   direct=0
   numjobs=1
   time_based=0

   [file1]
   size=10G
   ioengine=libaio

and shows the following results:

- raid1c3 with 3 HDDs:
   3 x Segate Barracuda ST2000DM008 (2TB)
   * pid policy
 READ: bw=217MiB/s (228MB/s), 217MiB/s-217MiB/s (228MB/s-228MB/s),
 io=10.0GiB (10.7GB), run=47082-47082msec
   * roundrobin policy
 READ: bw=409MiB/s (429MB/s), 409MiB/s-409MiB/s (429MB/s-429MB/s),
 io=10.0GiB (10.7GB), run=25028-25028mse
- raid1c3 with 2 HDDs and 1 SSD:
   2 x Segate Barracuda ST2000DM008 (2TB)
   1 x Crucial CT256M550SSD1 (256GB)
   * pid policy (the worst case when only HDDs were chosen)
 READ: bw=220MiB/s (231MB/s), 220MiB/s-220MiB/s (231MB/s-231MB/s),
 io=10.0GiB (10.7GB), run=46577-46577mse
   * pid policy (the best case when SSD was used as well)
 READ: bw=513MiB/s (538MB/s), 513MiB/s-513MiB/s (538MB/s-538MB/s),
 io=10.0GiB (10.7GB), run=19954-19954msec
   * roundrobin (there are no noticeable differences when testing multiple
 times)
 READ: bw=541MiB/s (567MB/s), 541MiB/s-541MiB/s (567MB/s-567MB/s),
 io=10.0GiB (10.7GB), run=18933-18933msec

The multithreaded test has the following parameters:

   [global]
   name=btrfs-raid1-seqread
   filename=btrfs-raid1-seqread
   rw=read
   bs=64k
   direct=0
   numjobs=8
   time_based=0

   [file1]
   size=10G
   ioengine=libaio

and shows the following results:

- raid1c3 with 3 HDDs: 3 x Segate Barracuda ST2000DM008 (2TB)
   3 x Segate Barracuda ST2000DM008 (2TB)
   * pid policy
 READ: bw=1569MiB/s (1645MB/s), 196MiB/s-196MiB/s (206MB/s-206MB/s),
 io=80.0GiB (85.9GB), run=52210-52211msec
   * roundrobin
 READ: bw=1733MiB/s (1817MB/s), 217MiB/s-217MiB/s (227MB/s-227MB/s),
 io=80.0GiB (85.9GB), run=47269-47271msec
- raid1c3 with 2 HDDs and 1 SSD:
   2 x Segate Barracuda ST2000DM008 (2TB)
   1 x Crucial CT256M550SSD1 (256GB)
   * pid policy
 READ: bw=1843MiB/s (1932MB/s), 230MiB/s-230MiB/s (242MB/s-242MB/s),
 io=80.0GiB (85.9GB), run=9-44450msec
   * roundrobin
 READ: bw=2485MiB/s (2605MB/s), 311MiB/s-311MiB/s (326MB/s-326MB/s),
 io=80.0GiB (85.9GB), run=32969-32970msec






The penalty value is an additional value added to the number of inflight
requests when a scheduled request is non-local (which means it would
start from the different physical location than the physical location of
the last request processed by the given device). By default, it's
applied only in filesystems which have mixed types of devices
(non-rotational and rotational), but it can be configured to be applied
without that condition.

The configuration is done through sysfs:
> - /sys/fs/btrfs/[fsid]/read_policies/roundrobin_nonlocal_inc_mixed_only

where 1 (the default) value means applying penalty only in mixed arrays,
0 means applying it unconditionally.

>

The exact penalty value is defined separately for non-rotational and
rotational devices. By default, it's 0 for non-rotational devices and 1
for rotational devices. Both values are configurable through sysfs:

- /sys/fs/btrfs/[fsid]/read_policies/roundrobin_nonrot_nonlocal_inc
- /sys/fs/btrfs/[fsid]/read_policies/roundrobin_rot_nonlocal_inc

To sum it up - the default case is applying the penalty under the
following conditions:

- the raid1 array consists of mixed types of devices
- the scheduled request is going to be non-local for the given disk
- the device is rotational

>

That default case is based on a slight preference towards non-rotational
disks in mixed arrays and has proven to give the best performance in
tested arrays.

>> For the array with 3 HDDs, not adding any penalty resulted in 409MiB/s

(429MB/s) performance. Adding the penalty value 1 resulted in a
performance drop to 404MiB/s (424MB/s). Increasing the value towards 10
was making the performance even worse.

For the array with 2 HDDs and 1 SSD, adding penalty value 1 to
rotational disks resulted in the best performance - 541MiB/s (567MB/s).
Not adding any value and increasing the value was making the performance
worse.
> Adding penalty value to non-rotational disks was always decreasing the
performance, which motivated setting it as 0 by default. For the purpose
of testing, it's still configurable.

>

To measure the performance of each policy and find optimal penalty
values, I created scripts which a

Re: linux-next: build failure after merge of the powerpc tree

[Nicholas Piggin]

Excerpts from Stephen Rothwell's message of February 9, 2021 8:19 pm:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x0): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `do_page_fault' defined in .opd 
> section in arch/powerpc/mm/fault.o
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x8): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `do_page_fault' defined in .opd 
> section in arch/powerpc/mm/fault.o
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x28): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `unknown_exception' defined in .opd 
> section in arch/powerpc/kernel/traps.o
> 
> Not sure exactly which commit caused this, but it is most likkely part
> of a series in the powerpc tree.
> 
> I have left the allyesconfig build broken for today.

Hey Stephen,

Thanks for that, it's due to .noinstr section being put on the other 
side of .text, so all our interrupt handler asm code can't reach them 
directly anymore since the ppc interrupt wrappers patch added noinstr
attribute.

That's not strictly required though, we've used NOKPROBE_SYMBOL okay
until now. If you can take this patch for now, it should get 
allyesconfig to build again. I'll fix it in the powerpc tree before the 
merge window.

Thanks,
Nick
--

diff --git a/arch/powerpc/include/asm/interrupt.h 
b/arch/powerpc/include/asm/interrupt.h
index 4badb3e51c19..fee1e4dd1e84 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -172,6 +172,8 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #define DECLARE_INTERRUPT_HANDLER_RAW(func)\
__visible long func(struct pt_regs *regs)
 
+#define ppc_noinstr noinline notrace __no_kcsan __no_sanitize_address
+
 /**
  * DEFINE_INTERRUPT_HANDLER_RAW - Define raw interrupt handler function
  * @func:  Function name of the entry point
@@ -198,7 +200,7 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #define DEFINE_INTERRUPT_HANDLER_RAW(func) \
 static __always_inline long ##func(struct pt_regs *regs);  \
\
-__visible noinstr long func(struct pt_regs *regs)  \
+__visible ppc_noinstr long func(struct pt_regs *regs)  \
 {  \
long ret;   \
\
@@ -228,7 +230,7 @@ static __always_inline long ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER(func) \
 static __always_inline void ##func(struct pt_regs *regs);  \
\
-__visible noinstr void func(struct pt_regs *regs)  \
+__visible ppc_noinstr void func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
\
@@ -262,7 +264,7 @@ static __always_inline void ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_RET(func) \
 static __always_inline long ##func(struct pt_regs *regs);  \
\
-__visible noinstr long func(struct pt_regs *regs)  \
+__visible ppc_noinstr long func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
long ret;   \
@@ -297,7 +299,7 @@ static __always_inline long ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_ASYNC(func)   \
 static __always_inline void ##func(struct pt_regs *regs);  \
\
-__visible noinstr void func(struct pt_regs *regs)  \
+__visible ppc_noinstr void func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
\
@@ -331,7 +333,7 @@ static __always_inline void ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_NMI(func) \
 static __always_inline long ##func(struct pt_regs *regs);  

Re: [PATCH 1/2] power: supply: bq25980: Applies multiple fixes brought on

[Krzysztof Kozlowski]

On Wed, 10 Feb 2021 at 00:52, Ricardo Rivera-Matos
 wrote:
>
> fix: corrects various register step size and offset values
>
> fix: corrects bq25980_get_input_curr_lim() and bq25980_set_input_curr_lim()
>
> fix: corrects bq25980_get_const_charge_curr() and 
> bq25980_set_const_charge_curr()
>
> fix: corrects BQ25960_BATOVP_MIN_uV, BQ25960_BATOVP_OFFSET_uV,
>
> BQ25960_BATOVP_STEP_uV, and BQ25960_BATOVP_MAX_uV
>
> fix: corrects busocp_sc_min and busocp_byp_min members
>
> fix: removes unnecessary polarity check from bq25980_get_adc_ibus()
>
> fix: removes unnecessary polarity check from bq25980_get_adc_ibat()
>
> fix: clamps ibat_adc to match datasheet change

Thanks for the patch.

Only one fix at a time and please exactly describe what is being fixed
using proper sentences (starting with capital letter, ending with a
full stop... and usually description needs multiple of such
sentences). You add here multiple changes without proper description
of a problem being fixed. This is not the correct style of a patch.

Best regards,
Krzysztof

Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default

[Saravana Kannan]

On Tue, Feb 9, 2021 at 9:54 PM Guenter Roeck  wrote:
>
> On Thu, Dec 17, 2020 at 07:17:03PM -0800, Saravana Kannan wrote:
> > Cyclic dependencies in some firmware was one of the last remaining
> > reasons fw_devlink=on couldn't be set by default. Now that cyclic
> > dependencies don't block probing, set fw_devlink=on by default.
> >
> > Setting fw_devlink=on by default brings a bunch of benefits (currently,
> > only for systems with device tree firmware):
> > * Significantly cuts down deferred probes.
> > * Device probe is effectively attempted in graph order.
> > * Makes it much easier to load drivers as modules without having to
> >   worry about functional dependencies between modules (depmod is still
> >   needed for symbol dependencies).
> >
> > If this patch prevents some devices from probing, it's very likely due
> > to the system having one or more device drivers that "probe"/set up a
> > device (DT node with compatible property) without creating a struct
> > device for it.  If we hit such cases, the device drivers need to be
> > fixed so that they populate struct devices and probe them like normal
> > device drivers so that the driver core is aware of the devices and their
> > status. See [1] for an example of such a case.
> >
> > [1] - 
> > https://lore.kernel.org/lkml/CAGETcx9PiX==mlxb9po8myyk6u2vhpvwtmsa5nkd-ywh5xh...@mail.gmail.com/
> > Signed-off-by: Saravana Kannan 
>
> This patch breaks nios2 boot tests in qemu. The system gets stuck when
> trying to reboot. Reverting this patch fixes the problem. Bisect log
> is attached.

Thanks for the report Guenter. Can you please try this series?
https://lore.kernel.org/lkml/20210205222644.2357303-1-sarava...@google.com/

It's in driver-core-testing too if that's easier.

-Saravana

Re: [PATCH v2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits

[Amit Pundir]

Hi,

On Mon, 8 Feb 2021 at 20:11, Konrad Dybcio  wrote:
>
>
> >>> +  ports {
> >>> +  port@1 {
> >>> +  endpoint {
> >>> +  remote-endpoint = <&tianma_nt36672a_in_0>;
> >>> +  data-lanes = <0 1 2 3>;
> >>> +  };
> >>> +  };
> >>> +  };
> >> The endpoint has a label, you can simply use &dsi0_out {};.
> > I didn't get what you meant there. Care to point to some reference dts
> > snippet please?
>
> sdm845.dtsi, L4139 as of v5.11-rc7:
>
>
> port@1 {
> reg = <1>;
> dsi0_out: endpoint {
> };
> };
>
>
> This means you can essentially do:
>
> &dsi0_out {
>
> remote-endpoint = <&tianma_nt36672a_in_0>;
> lanes = <0 1 2 3>;
>
> };
>
>
> in your dt :)
>

Thank you. Added in v3.

>
> >>> +  vddpos-supply = <&lab>;
> >>> +  vddneg-supply = <&ibb>;
> >> With Angelo's latest series [1] merged in, I reckon you should explicitly 
> >> configure lab/ibb (like in [2]),
> >> as wrong settings (which CAN BE SET BY THE BOOTLOADER in some instances!!) 
> >> can lead to hardware damage.
> > So iirc in the case of beryllium device, these regulators are pre set
> > by the bootloader and I can't find any reference of we
> > setting/resetting it explicitly to switch ON the panel and display. So
> > far default lab/ibb nodes are working fine for us and I'm hesitant to
> > tinker around anything regulator related that can potentially damage
> > the hardware. Having said that, I do see lab/ibb nodes being set in
> > the downstream dts, with relevant soft-start and discharge-resistor
> > properties and I can try switching to that once the new lab/ibb
> > changes land upstream.
> >
> > Regards,
> > Amit Pundir
> >
> I understand your concerns, however we actually did find out that at least 
> one device had LAB/IBB set up by the bootloader in a way that could 
> potentially damage the electronics, so I'm just making you aware. If it works 
> as-is, it's probably OK.

Device seem to be booting fine with downstream labibb regulator node
changes, hence added them in v3 as well. Smoke tested on
5.11.0-rc7-next-20210209.

Regards,
Amit Pundir

>
>
> Konrad
>

Re: [PATCH] checkpatch: add warning for non-lore mailing list URLs

[Kees Cook]

On Thu, Dec 17, 2020 at 04:50:41PM -0800, Joe Perches wrote:
> On Thu, 2020-12-17 at 17:56 -0600, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas 
> > 
> > The lkml.org, marc.info, spinics.net, etc archives are not quite as useful
> > as lore.kernel.org because they use different styles, add advertising, and
> > may disappear in the future.  The lore archives are more consistent and
> > more likely to stick around, so prefer https://lore.kernel.org URLs when
> > they exist.
> 
> Hi Bjorn.
> 
> I like the idea, thanks, but a couple notes.
> 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -564,6 +564,17 @@ sub find_standard_signature {
> >     return "";
> >  }
>  
> > +our $obsolete_archives = qr{(?xi:
> > +   freedesktop.org/archives/dri-devel|
> > +   lists.infradead.org|
> > +   lkml.org|
> > +   mail-archive.com|
> > +   mailman.alsa-project.org/pipermail|
> > +   marc.info|
> > +   ozlabs.org/pipermail|
> > +   spinics.net
> > +)};
> 
> Strictly, these all need \Q \E escaping so uses like lkmlAorg do not match.
> 
> 
> > @@ -3101,6 +3112,12 @@ sub process {
> >     }
> >     }
> >  
> > +# Check for mailing list archives other than lore.kernel.org
> > +   if ($line =~ /(http|https):\/\/\S*$obsolete_archives/) {
> 
> The https?:// doesn't seem necessary.  Perhaps:
> 
>   if ($line =~ m{\b$obsolete_archives}) {
> 
> > +   WARN("PREFER_LORE_ARCHIVE",
> > +"Use lore.kernel.org archive links when possible; 
> > see https://lore.kernel.org/lists.html\n"; . $herecurr);
> 
> Perhaps:
>"Prefer lore.kernel.org links. see: 
> https://www.kernel.org/lore.html#linking-to-list-discussions-from-commits\n"; 
> . $herecurr);
> 
> So maybe instead:
> ---
>  scripts/checkpatch.pl | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 00085308ed9d..c2a324d628a6 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -564,6 +564,17 @@ sub find_standard_signature {
>   return "";
>  }
>  
> +our $obsolete_archives = qr{(?xi:
> + \Qfreedesktop.org/archives/dri-devel\E |
> + \Qlists.infradead.org\E |
> + \Qlkml.org\E |
> + \Qmail-archive.com\E |
> + \Qmailman.alsa-project.org/pipermail\E |
> + \Qmarc.info\E |
> + \Qozlabs.org/pipermail\E |
> + \Qspinics.net\E
> +)};
> +
>  our @typeListMisordered = (
>   qr{char\s+(?:un)?signed},
>   qr{int\s+(?:(?:un)?signed\s+)?short\s},
> @@ -3101,6 +3112,12 @@ sub process {
>   }
>   }
>  
> + # Check for mailing list archives other than lore.kernel.org
> + if ($rawline =~ m{\b$obsolete_archives}) {
> + WARN("PREFER_LORE_ARCHIVE",
> +  "Use lore.kernel.org archive links when possible - 
> see https://lore.kernel.org/lists.html\n"; . $herecurr);
> + }
> +
>  # Check for added, moved or deleted files
>   if (!$reported_maintainer_file && !$in_commit_log &&
>   ($line =~ /^(?:new|deleted) file mode\s*\d+\s*$/ ||
> 
> 

Ah, nice. Yes, this would be great to get added. Joe, can you respin as
a full path? Please consider it:

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH] video: use getter/setter functions

[Lee Jones]

On Tue, 09 Feb 2021, Julia Lawall wrote:

> Use getter and setter functions, for platform_device structures and a
> spi_device structure.
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/video/backlight/qcom-wled.c  |2 
> +-

This patch is fine.

Could you please split it out and submit it separately though please.

>  drivers/video/fbdev/amifb.c  |4 
> ++--
>  drivers/video/fbdev/da8xx-fb.c   |4 
> ++--
>  drivers/video/fbdev/imxfb.c  |2 
> +-
>  drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c |6 
> +++---
>  drivers/video/fbdev/omap2/omapfb/dss/dpi.c   |4 
> ++--
>  drivers/video/fbdev/omap2/omapfb/dss/dsi.c   |4 
> ++--
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c |2 
> +-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c |2 
> +-
>  drivers/video/fbdev/xilinxfb.c   |2 
> +-
>  10 files changed, 16 insertions(+), 16 deletions(-)

...]

> diff --git a/drivers/video/backlight/qcom-wled.c 
> b/drivers/video/backlight/qcom-wled.c
> index 3bc7800eb0a9..091f07e7c145 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -1692,7 +1692,7 @@ static int wled_probe(struct platform_device *pdev)
>  
>  static int wled_remove(struct platform_device *pdev)
>  {
> - struct wled *wled = dev_get_drvdata(&pdev->dev);
> + struct wled *wled = platform_get_drvdata(pdev);
>  
>   mutex_destroy(&wled->lock);
>   cancel_delayed_work_sync(&wled->ovp_work);

For my own reference (apply this as-is to your sign-off block):

  Acked-for-Backlight-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/2] power: supply: bq25980: Moves properties from battery node

[Krzysztof Kozlowski]

On Wed, 10 Feb 2021 at 00:52, Ricardo Rivera-Matos
 wrote:
>
> fix: exposes POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT on the
>
> charger node

Why is this a fix? Why is exposing this property wrong? What is the
problem here? Why do you start sentences with a small letter? Your
commit message should answer such questions.

Best regards,
Krzysztof

Re: [RFC PATCH 2/2] mm,page_alloc: Make alloc_contig_range handle free hugetlb pages

[David Hildenbrand]

On 08.02.21 11:38, Oscar Salvador wrote:

Free hugetlb pages are trickier to handle as to in order to guarantee
no userspace appplication disruption, we need to replace the
current free hugepage with a new one.

In order to do that, a new function called alloc_and_dissolve_huge_page
in introduced.
This function will first try to get a new fresh hugetlb page, and if it
succeeds, it will dissolve the old one.



Thanks for looking into this! Can we move this patch to #1 in the 
series? It is the easier case.


I also wonder if we should at least try on the memory unplug path to 
keep nr_pages by at least trying to allocate at new one if required, and 
printing a warning if that fails (after all, we're messing with 
something configured by the admin - "nr_pages"). Note that gigantic 
pages are special (below).



Signed-off-by: Oscar Salvador 
---
  include/linux/hugetlb.h |  6 ++
  mm/compaction.c | 11 +++
  mm/hugetlb.c| 35 +++
  3 files changed, 52 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index ebca2ef02212..f81afcb86e89 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -505,6 +505,7 @@ struct huge_bootmem_page {
struct hstate *hstate;
  };
  
+bool alloc_and_dissolve_huge_page(struct page *page);

  struct page *alloc_huge_page(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve);
  struct page *alloc_huge_page_nodemask(struct hstate *h, int preferred_nid,
@@ -773,6 +774,11 @@ static inline void huge_ptep_modify_prot_commit(struct 
vm_area_struct *vma,
  #else /* CONFIG_HUGETLB_PAGE */
  struct hstate {};
  
+static inline bool alloc_and_dissolve_huge_page(struct page *page)

+{
+   return false;
+}
+
  static inline struct page *alloc_huge_page(struct vm_area_struct *vma,
   unsigned long addr,
   int avoid_reserve)
diff --git a/mm/compaction.c b/mm/compaction.c
index 89cd2e60da29..7969ddc10856 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -952,6 +952,17 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
low_pfn += compound_nr(page) - 1;
goto isolate_success_no_list;
}
+   } else {


} else if (alloc_and_dissolve_huge_page(page))) {

...


+   /*
+* Free hugetlb page. Allocate a new one and
+* dissolve this is if succeed.
+*/
+   if (alloc_and_dissolve_huge_page(page)) {
+   unsigned long order = 
buddy_order_unsafe(page);
+
+   low_pfn += (1UL << order) - 1;
+   continue;
+   }




Note that there is a very ugly corner case we will have to handle 
gracefully (I think also in patch #1):


Assume you allocated a gigantic page (and assume that we are not using 
CMA for gigantic pages for simplicity). Assume you want to allocate 
another one. alloc_pool_huge_page()->...->alloc_contig_pages() will 
stumble over the first allocated page. It will try to 
alloc_and_dissolve_huge_page() the existing gigantic page. To do that, 
it will alloc_pool_huge_page()->...->alloc_contig_pages() ... and so on. 
Bad.


We really don't want to mess with gigantic pages (migrate, dissolve) 
while allocating a gigantic page. I think the easiest (and cleanest) way 
forward is to not mess (isolate, migrate, dissolve) with gigantic pages 
at all.


Gigantic pages are not movable, so they won't be placed on random CMA / 
ZONE_MOVABLE.


Some hstate_is_gigantic(h) calls (maybe inside 
alloc_and_dissolve_huge_page() ? ) along with a nice comment might be 
good enough to avoid having to pass down some kind of alloc_contig 
context. I even think that should be handled inside


(the main issue is that in contrast to CMA, plain alloc_contig_pages() 
has no memory about which parts were allocated and will simply try 
re-allocating what it previously allocated and never freed - which is 
usually fine, unless we're dealing with such special cases)


Apart from that, not messing with gigantic pages feels like the right 
approach (allocating/migrating gigantic pages is just horribly slow and 
most probably not worth it anyway).


--
Thanks,

David / dhildenb

Re: [PATCH net-next 7/9] net: phy: icplus: select page before writing control register

[Michael Walle]

Hi,

Am 2021-02-10 08:03, schrieb Heiner Kallweit:

On 09.02.2021 17:40, Michael Walle wrote:

Registers >= 16 are paged. Be sure to set the page. It seems this was
working for now, because the default is correct for the registers used
in the driver at the moment. But this will also assume, nobody will
change the page select register before linux is started. The page 
select

register is _not_ reset with a soft reset of the PHY.

Add read_page()/write_page() support for the IP101G and use it
accordingly.

Signed-off-by: Michael Walle 
---
 drivers/net/phy/icplus.c | 50 
+++-

 1 file changed, 39 insertions(+), 11 deletions(-)

diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/icplus.c
index a6e1c7611f15..858b9326a72d 100644
--- a/drivers/net/phy/icplus.c
+++ b/drivers/net/phy/icplus.c
@@ -49,6 +49,8 @@ MODULE_LICENSE("GPL");
 #define IP101G_DIGITAL_IO_SPEC_CTRL0x1d
 #define IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32 BIT(2)

+#define IP101G_DEFAULT_PAGE16
+
 #define IP175C_PHY_ID 0x02430d80
 #define IP1001_PHY_ID 0x02430d90
 #define IP101A_PHY_ID 0x02430c54
@@ -250,23 +252,25 @@ static int ip101a_g_probe(struct phy_device 
*phydev)

 static int ip101a_g_config_init(struct phy_device *phydev)
 {
struct ip101a_g_phy_priv *priv = phydev->priv;
-   int err;
+   int oldpage, err;
+
+   oldpage = phy_select_page(phydev, IP101G_DEFAULT_PAGE);

 	/* configure the RXER/INTR_32 pin of the 32-pin IP101GR if needed: 
*/

switch (priv->sel_intr32) {
case IP101GR_SEL_INTR32_RXER:
-   err = phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
-IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32, 0);
+   err = __phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
+  IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32, 0);
if (err < 0)
-   return err;
+   goto out;
break;

case IP101GR_SEL_INTR32_INTR:
-   err = phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
-IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32,
-IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32);
+   err = __phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
+  IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32,
+  IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32);
if (err < 0)
-   return err;
+   goto out;
break;

default:
@@ -284,12 +288,14 @@ static int ip101a_g_config_init(struct 
phy_device *phydev)

 * reserved as 'write-one'.
 */
if (priv->model == IP101A) {
-		err = phy_set_bits(phydev, IP10XX_SPEC_CTRL_STATUS, 
IP101A_G_APS_ON);

+   err = __phy_set_bits(phydev, IP10XX_SPEC_CTRL_STATUS,
+IP101A_G_APS_ON);
if (err)
-   return err;
+   goto out;
}

-   return 0;
+out:
+   return phy_restore_page(phydev, oldpage, err);


If a random page was set before entering config_init, do we actually 
want

to restore it? Or wouldn't it be better to set the default page as part
of initialization?


First, I want to convert this to the match_phy_device() and while at it,
I noticed that there is this one "problem". Short summary: the IP101A 
isn't

paged, the IP101G has serveral and if page 16 is selected it is more or
less compatible with the IP101A. My problem here is now how to share the
functions for both PHYs without duplicating all the code. Eg. the IP101A
will phy_read/phy_write/phy_modify(), that is, all the locked versions.
For the IP101G I'd either need the _paged() versions or the __phy ones
which don't take the mdio_bus lock.

Here is what I came up with:
(1) provide a common function which uses the __phy ones, then the
callback for the A version will take the mdio_bus lock and calls
the common one. The G version will use phy_{select,restore}_page().
(2) the phy_driver ops for A will also provde a .read/write_page()
callback which is just a no-op. So A can just use the G versions.
(3) What Heiner mentioned here, just set the default page in
config_init().

(1) will still bloat the code; (3) has the disadvantage, that the
userspace might fiddle around with the page register and then the
whole PHY driver goes awry. I don't know if we have to respect that
use case in general. I know there is an API to read/write the PHY
registers and it could happen.

That being said, I'm either fine with (2) and (3) but I'm preferring
(2).

BTW, this patch is still missing read/writes to the interrupt status
and control registers which is also paged.

-michael

Re: [PATCH v4 4/8] of: property: Add fw_devlink support for optional properties

[Geert Uytterhoeven]

Hi Saravana,

CC iommu

On Tue, Feb 9, 2021 at 10:55 PM Saravana Kannan  wrote:
> On Tue, Feb 9, 2021 at 1:33 PM Rob Herring  wrote:
> > On Fri, Feb 05, 2021 at 02:26:40PM -0800, Saravana Kannan wrote:
> > > Not all DT bindings are mandatory bindings. Add support for optional DT
> > > bindings and mark iommus, iommu-map, dmas as optional DT bindings.
> >
> > I don't think we can say these are optional or not. It's got to be a
> > driver decision somehow.
>
> Right, so maybe the word "optional" isn't a good name for it. I can
> change that if you want.
>
> The point being, fw_devlink can't block the probe of this driver based
> on iommu property. We let the driver decide if it wants to
> -EPROBE_DEFER or not or however it wants to handle this.

The driver cannot make that decision, cfr. below.

> > For example, if IOMMU is optional, what happens with this sequence:
> >
> > driver probes without IOMMU
> > driver calls dma_map_?()
> > IOMMU driver probes
> > h/w accesses DMA buffer --> BOOM!

Does it really behave that way? Or does it continue without IOMMU?

> Right. But how is this really related to fw_devlink? AFAICT, this is
> an issue even today. If the driver needs the IOMMU, then it needs to
> make sure the IOMMU has probed? What am I missing?

Individual I/O (IOMMU slave) drivers are completely unaware of the
presence or absence of an IOMMU; they just use the DMA API, which is the
same regardless of an IOMMU being used or not.
While for GPIO/IRQ/CLK/DMA/... have request/get_{gpio,irq,clk,dma,...}
APIs for a driver to get a reference, which can return -EPROBE_DEFER, no
such thing exists for IOMMUs.  This is handled by the IOMMU core
instead.

Using the IOMMU or not is more like a system policy decision.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/5] ath10k: detect conf_mutex held ath10k_drain_tx() calls

[Kalle Valo]

Shuah Khan  writes:

> ath10k_drain_tx() must not be called with conf_mutex held as workers can
> use that also. Add check to detect conf_mutex held calls.
>
> Signed-off-by: Shuah Khan 

The commit log does not answer to "Why?". How did you find this? What
actual problem are you trying to solve?

> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 53f92945006f..3545ce7dce0a 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4566,6 +4566,7 @@ static void ath10k_mac_op_wake_tx_queue(struct 
> ieee80211_hw *hw,
>  /* Must not be called with conf_mutex held as workers can use that also. */
>  void ath10k_drain_tx(struct ath10k *ar)
>  {
> + WARN_ON(lockdep_is_held(&ar->conf_mutex));

Empty line after WARN_ON().

Shouldn't this check debug_locks similarly lockdep_assert_held() does?

#define lockdep_assert_held(l)  do {\
WARN_ON(debug_locks && !lockdep_is_held(l));\
} while (0)

And I suspect you need #ifdef CONFIG_LOCKDEP which should fix the kbuild
bot error.

But honestly I would prefer to have lockdep_assert_not_held() in
include/linux/lockdep.h, much cleaner that way. Also
i915_gem_object_lookup_rcu() could then use the same macro.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH 0/1] MHI fix for v5.12

[Manivannan Sadhasivam]

Hi Greg,

At the last moment we noticed a regression which existed since last release.
Since we are very late for v5.11 rc, please consider merging this patch for
v5.12.

Thanks,
Mani

Loic Poulain (1):
  mhi: Fix double dma free

 drivers/bus/mhi/core/init.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.25.1

[PATCH 1/1] mhi: Fix double dma free

[Manivannan Sadhasivam]

From: Loic Poulain 

mhi_deinit_chan_ctxt functionthat takes care of unitializing channel
resources, including unmapping coherent MHI areas, can be called
from different path in case of controller unregistering/removal:
 - From a client driver remove callback, via mhi_unprepare_channel
 - From mhi_driver_remove that unitialize all channels

mhi_driver_remove()
|-> driver->remove()
||-> mhi_unprepare_channel()
||-> mhi_deinit_chan_ctxt()
|...
|-> mhi_deinit_chan_ctxt()

This leads to double dma freeing...

Fix that by preventing deinit for already uninitialized channel.

Fixes: a7f422f2f89e ("bus: mhi: Fix channel close issue on driver remove")
Signed-off-by: Loic Poulain 
Reported-by: Kalle Valo 
Tested-by: Kalle Valo 
Reviewed-by: Manivannan Sadhasivam 
Link: 
https://lore.kernel.org/r/1612894264-15956-1-git-send-email-loic.poul...@linaro.org
Signed-off-by: Manivannan Sadhasivam 
---
 drivers/bus/mhi/core/init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index aa575d3fb3ae..be4eebb0971b 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -557,6 +557,9 @@ void mhi_deinit_chan_ctxt(struct mhi_controller *mhi_cntrl,
tre_ring = &mhi_chan->tre_ring;
chan_ctxt = &mhi_cntrl->mhi_ctxt->chan_ctxt[mhi_chan->chan];
 
+   if (!chan_ctxt->rbase) /* Already uninitialized */
+   return;
+
mhi_free_coherent(mhi_cntrl, tre_ring->alloc_size,
  tre_ring->pre_aligned, tre_ring->dma_handle);
vfree(buf_ring->base);
-- 
2.25.1

Re: [PATCH 5.4 00/65] 5.4.97-rc1 review

[Greg Kroah-Hartman]

On Mon, Feb 08, 2021 at 09:39:52AM -0800, Florian Fainelli wrote:
> On 2/8/21 7:00 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.97 release.
> > There are 65 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.97-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.4.y
> > and the diffstat can be found below.
> 
> Tested-by: Florian Fainelli 
> 
> On ARCH_BRCMSTB using 32-bit ARM and 64-bit ARM kernels, no regressions
> observed, thanks!

Thanks for testing and letting me know.

greg k-h

Re: [PATCH 5/5] ath10k: reduce invalid ht params rate message noise

[Kalle Valo]

Wen Gong  writes:

> On 2021-02-10 08:42, Shuah Khan wrote:
>> ath10k_mac_get_rate_flags_ht() floods dmesg with the following
>> messages,
>> when it fails to find a match for mcs=7 and rate=1440.
>>
>> supported_ht_mcs_rate_nss2:
>> {7,  {1300, 2700, 1444, 3000} }
>>
>> ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps nss 2
>> mcs 7
>>
>> dev_warn_ratelimited() isn't helping the noise. Use dev_warn_once()
>> instead.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 3545ce7dce0a..276321f0cfdd 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -8970,8 +8970,9 @@ static void ath10k_mac_get_rate_flags_ht(struct
>> ath10k *ar, u32 rate, u8 nss, u8
>>  *bw |= RATE_INFO_BW_40;
>>  *flags |= RATE_INFO_FLAGS_SHORT_GI;
>>  } else {
>> -ath10k_warn(ar, "invalid ht params rate %d 100kbps nss %d mcs 
>> %d",
>> -rate, nss, mcs);
>> +dev_warn_once(ar->dev,
>> +  "invalid ht params rate %d 100kbps nss %d mcs %d",
>> +  rate, nss, mcs);
>>  }
>>  }
>
> The {7,  {1300, 2700, 1444, 3000} } is a correct value.
> The 1440 is report from firmware, its a wrong value, it has fixed in
> firmware.

In what version?

> If change it to dev_warn_once, then it will have no chance to find the
> other wrong values which report by firmware, and it indicate
> a wrong value to mac80211/cfg80211 and lead "iw wlan0 station dump"
> get a wrong bitrate.

I agree, we should keep this warning. If the firmware still keeps
sending invalid rates we should add a specific check to ignore the known
invalid values, but not all of them.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 5.4 00/65] 5.4.97-rc1 review

[Greg Kroah-Hartman]

On Tue, Feb 09, 2021 at 08:00:00AM -0300, Igor Torrente wrote:
> On Mon, Feb 8, 2021 at 12:24 PM Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 5.4.97 release.
> > There are 65 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.97-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.4.y
> > and the diffstat can be found below.
> >
> 
> Compiled and booted on my machine(x86_64) without any dmesg regression.
> My compilation uses the default Debian 10 .config(From kernel
> 4.19.0-14-amd64), followed by olddefconfig.
> 
> Tested-by: Igor Matheus Andrade Torrente 

Thanks for testing and letting me know.

greg k-h

Re: [PATCH v5 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver

[Gwendal Grignou]

On Tue, Feb 9, 2021 at 6:51 PM Stephen Boyd  wrote:
>
> Add support for a ChromeOS EC proximity driver that exposes a "front"
> proximity sensor via the IIO subsystem. The EC decides when front
> proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
> notify the kernel of proximity. Similarly, when proximity detects
> something far away it sets the switch bit to 0. For now this driver
> exposes a single sensor, but it could be expanded in the future via more
> MKBP bits if desired.
>
> Cc: Dmitry Torokhov 
> Cc: Benson Leung 
> Cc: Guenter Roeck 
> Cc: Douglas Anderson 
> Cc: Gwendal Grignou 
> Reviewed-by: Enric Balletbo i Serra 
> Signed-off-by: Stephen Boyd 
> ---
>
> Changes from v4:
>  * Dropped of_match_ptr()
>
>  drivers/iio/proximity/Kconfig |  11 +
>  drivers/iio/proximity/Makefile|   1 +
>  .../iio/proximity/cros_ec_mkbp_proximity.c| 242 ++
>  3 files changed, 254 insertions(+)
>  create mode 100644 drivers/iio/proximity/cros_ec_mkbp_proximity.c
>
> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
> index 12672a0e89ed..7c7203ca3ac6 100644
> --- a/drivers/iio/proximity/Kconfig
> +++ b/drivers/iio/proximity/Kconfig
> @@ -21,6 +21,17 @@ endmenu
>
>  menu "Proximity and distance sensors"
>
> +config CROS_EC_MKBP_PROXIMITY
> +   tristate "ChromeOS EC MKBP Proximity sensor"
> +   depends on CROS_EC
> +   help
> + Say Y here to enable the proximity sensor implemented via the 
> ChromeOS EC MKBP
> + switches protocol. You must enable one bus option (CROS_EC_I2C or 
> CROS_EC_SPI)
> + to use this.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_ec_mkbp_proximity.
> +
>  config ISL29501
> tristate "Intersil ISL29501 Time Of Flight sensor"
> depends on I2C
> diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
> index 9c1aca1a8b79..cbdac09433eb 100644
> --- a/drivers/iio/proximity/Makefile
> +++ b/drivers/iio/proximity/Makefile
> @@ -5,6 +5,7 @@
>
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_AS3935)   += as3935.o
> +obj-$(CONFIG_CROS_EC_MKBP_PROXIMITY) += cros_ec_mkbp_proximity.o
>  obj-$(CONFIG_ISL29501) += isl29501.o
>  obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o
>  obj-$(CONFIG_MB1232)   += mb1232.o
> diff --git a/drivers/iio/proximity/cros_ec_mkbp_proximity.c 
> b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> new file mode 100644
> index ..2cdaf05c0ec2
> --- /dev/null
> +++ b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> @@ -0,0 +1,242 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for cros-ec proximity sensor exposed through MKBP switch
> + *
> + * Copyright 2021 Google LLC.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct cros_ec_mkbp_proximity_data {
> +   struct cros_ec_device *ec;
> +   struct iio_dev *indio_dev;
> +   struct mutex lock;
> +   struct notifier_block notifier;
> +   bool enabled;
> +};
> +
> +static const struct iio_event_spec cros_ec_mkbp_proximity_events[] = {
> +   {
> +   .type = IIO_EV_TYPE_THRESH,
> +   .dir = IIO_EV_DIR_EITHER,
> +   .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> +   },
> +};
> +
> +static const struct iio_chan_spec cros_ec_mkbp_proximity_chan_spec[] = {
> +   {
> +   .type = IIO_PROXIMITY,
> +   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> +   .event_spec = cros_ec_mkbp_proximity_events,
> +   .num_event_specs = ARRAY_SIZE(cros_ec_mkbp_proximity_events),
> +   },
> +};
> +
> +static int cros_ec_mkbp_proximity_parse_state(const void *data)
> +{
> +   u32 switches = get_unaligned_le32(data);
> +
> +   return !!(switches & BIT(EC_MKBP_FRONT_PROXIMITY));
> +}
> +
> +static int cros_ec_mkbp_proximity_query(struct cros_ec_device *ec_dev,
> +   int *state)
> +{
> +   struct {
> +   struct cros_ec_command msg;
> +   union {
> +   struct ec_params_mkbp_info params;
> +   u32 switches;
> +   };
> +   } __packed buf = { };
> +   struct ec_params_mkbp_info *params = &buf.params;
> +   struct cros_ec_command *msg = &buf.msg;
> +   u32 *switches = &buf.switches;
> +   size_t insize = sizeof(*switches);
> +   int ret;
> +
> +   msg->command = EC_CMD_MKBP_INFO;
> +   msg->version = 1;
> +   msg->outsize = sizeof(*params);
> +   msg->insize = insize;
> +
> +   params->info_type = EC_MKBP_INFO_CURRENT;
> +   params->event_type = EC_MKBP_EVENT_SWITCH;
> +
> +   ret = cros_ec_cmd_xfer_

Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

[Greg Kroah-Hartman]

On Tue, Feb 09, 2021 at 07:28:16PM -0600, Ross Schmidt wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> 
> Compiled and booted with no regressions on x86_64.
> 
> Tested-by: Ross Schmidt 

Thanks for testing and letting me know.

greg k-h

Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

[Greg Kroah-Hartman]

On Tue, Feb 09, 2021 at 10:14:44AM -0800, Guenter Roeck wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 154 pass: 154 fail: 0
> Qemu test results:
>   total: 427 pass: 427 fail: 0
> 
> Tested-by: Guenter Roeck 

Great, thanks for testing.

greg k-h

Re: [PATCH v2 1/2] pinctrl: use to octal permissions for debugfs files

[Joe Perches]

On Tue, 2021-02-09 at 23:49 -0800, Drew Fustini wrote:
> Switch over pinctrl debugfs files to use octal permissions as they are
> preferred over symbolic permissions. Refer to commit f90774e1fd27
> ("checkpatch: look for symbolic permissions and suggest octal instead").
> 
> Signed-off-by: Drew Fustini 
> ---
>  drivers/pinctrl/core.c| 6 +++---
>  drivers/pinctrl/pinconf.c | 4 ++--
>  drivers/pinctrl/pinmux.c  | 4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index 3663d87f51a0..c9c28f653799 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -1914,11 +1914,11 @@ static void pinctrl_init_debugfs(void)
>   return;
>   }
>  
> 
> - debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
> + debugfs_create_file("pinctrl-devices", 0400,
>   debugfs_root, NULL, &pinctrl_devices_fops);

NAK.  You've changed the permission levels.

S_IRUGO is 0444 not 0400.
And you have to keep the S_IFREG or'd along with the octal.

include/linux/stat.h:#define S_IRUGO(S_IRUSR|S_IRGRP|S_IROTH)

checkpatch does this conversion using this command line:

$ ./scripts/checkpatch.pl -f --show-types --terse drivers/pinctrl/*.[ch] 
--types=SYMBOLIC_PERMS --fix-inplace
drivers/pinctrl/core.c:1893: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
drivers/pinctrl/core.c:1895: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
drivers/pinctrl/core.c:1897: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
drivers/pinctrl/core.c:1919: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
drivers/pinctrl/core.c:1921: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
drivers/pinctrl/core.c:1923: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
total: 0 errors, 6 warnings, 2302 lines checked
drivers/pinctrl/pinconf.c:373: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
drivers/pinctrl/pinconf.c:375: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
total: 0 errors, 2 warnings, 379 lines checked
drivers/pinctrl/pinmux.c:679: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
drivers/pinctrl/pinmux.c:681: WARNING:SYMBOLIC_PERMS: Symbolic permissions 
'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
total: 0 errors, 2 warnings, 854 lines checked

$ git diff --stat -p drivers/pinctrl/
 drivers/pinctrl/core.c| 12 ++--
 drivers/pinctrl/pinconf.c |  4 ++--
 drivers/pinctrl/pinmux.c  |  4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 7d3370289938..6992b805ae41 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1890,11 +1890,11 @@ static void pinctrl_init_device_debugfs(struct 
pinctrl_dev *pctldev)
dev_name(pctldev->dev));
return;
}
-   debugfs_create_file("pins", S_IFREG | S_IRUGO,
+   debugfs_create_file("pins", S_IFREG | 0444,
device_root, pctldev, &pinctrl_pins_fops);
-   debugfs_create_file("pingroups", S_IFREG | S_IRUGO,
+   debugfs_create_file("pingroups", S_IFREG | 0444,
device_root, pctldev, &pinctrl_groups_fops);
-   debugfs_create_file("gpio-ranges", S_IFREG | S_IRUGO,
+   debugfs_create_file("gpio-ranges", S_IFREG | 0444,
device_root, pctldev, &pinctrl_gpioranges_fops);
if (pctldev->desc->pmxops)
pinmux_init_device_debugfs(device_root, pctldev);
@@ -1916,11 +1916,11 @@ static void pinctrl_init_debugfs(void)
return;
}
 
-   debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinctrl-devices", S_IFREG | 0444,
debugfs_root, NULL, &pinctrl_devices_fops);
-   debugfs_create_file("pinctrl-maps", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinctrl-maps", S_IFREG | 0444,
debugfs_root, NULL, &pinctrl_maps_fops);
-   debugfs_create_file("pinctrl-handles", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinctrl-handles", S_IFREG | 0444,
debugfs_root, NULL, &pinctrl_fops);
 }
 
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 02c075cc010b..f9ee12b50428 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ 

Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

[Greg Kroah-Hartman]

On Tue, Feb 09, 2021 at 07:42:34PM +0530, Naresh Kamboju wrote:
> On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.15-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.10.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and i386.
> 
> Tested-by: Linux Kernel Functional Testing 
> 

Thanks for testing them all and letting me know.

greg k-h

Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

[Greg Kroah-Hartman]

On Mon, Feb 08, 2021 at 05:22:07PM -0300, Davidson Francis wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> 
> Compiled and boot tested for x86_64, no dmesg regressions found.
> 
> Tested-by: Davidson Francis 

Thanks for testing!

greg k-h

Re: [PATCH] sign-file: add openssl engine support

[David Howells]

Yang Song  wrote:

> + "Usage: scripts/sign-file [-edp] []  
>[]\n");

Do you mean:

"Usage: scripts/sign-file [-dp] [-e ] []\n");

> + opt = getopt(argc, argv, "sedpk");

"se:dpk"?

> + if (use_engine) {
> + ossl_engine = argv[0];

use_engine ought to be a redundant variable.

David

Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

[Greg Kroah-Hartman]

On Mon, Feb 08, 2021 at 07:33:53PM +0100, Pavel Machek wrote:
> On Mon 2021-02-08 15:59:47, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +.
> > Anything received after that time might be too late.
> 
> CIP testing did not find any problems here:
> 
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
> 
> Tested-by: Pavel Machek (CIP) 

Thanks for testing some of them and letting me know.

greg k-h

Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

[Greg Kroah-Hartman]

On Mon, Feb 08, 2021 at 01:01:09PM -0700, Shuah Khan wrote:
> On 2/8/21 7:59 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.15-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.
> 
> Tested-by: Shuah Khan 

Thanks for testing them all and letting me know.

greg k-h

Re: [PATCH v2 1/2] pinctrl: use to octal permissions for debugfs files

[Geert Uytterhoeven]

Hi Drew,

On Wed, Feb 10, 2021 at 8:50 AM Drew Fustini  wrote:
> Switch over pinctrl debugfs files to use octal permissions as they are
> preferred over symbolic permissions. Refer to commit f90774e1fd27
> ("checkpatch: look for symbolic permissions and suggest octal instead").
>
> Signed-off-by: Drew Fustini 

Thanks for your patch!

> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -1914,11 +1914,11 @@ static void pinctrl_init_debugfs(void)
> return;
> }
>
> -   debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
> +   debugfs_create_file("pinctrl-devices", 0400,

What about the loss of S_IFREG?
S_IRUGO = 0444, not 0400.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v3 1/3] perf core: Factor out __perf_sw_event_sched

[Namhyung Kim]

In some cases, we need to check more than whether the software event
is enabled.  So split the condition check and the actual event
handling.  This is a preparation for the next change.

Suggested-by: Peter Zijlstra 
Signed-off-by: Namhyung Kim 
---
 include/linux/perf_event.h | 33 -
 1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index fab42cfbd350..2a1be6026a2f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1174,30 +1174,24 @@ DECLARE_PER_CPU(struct pt_regs, __perf_regs[4]);
  * which is guaranteed by us not actually scheduling inside other swevents
  * because those disable preemption.
  */
-static __always_inline void
-perf_sw_event_sched(u32 event_id, u64 nr, u64 addr)
+static __always_inline void __perf_sw_event_sched(u32 event_id, u64 nr, u64 
addr)
 {
-   if (static_key_false(&perf_swevent_enabled[event_id])) {
-   struct pt_regs *regs = this_cpu_ptr(&__perf_regs[0]);
+   struct pt_regs *regs = this_cpu_ptr(&__perf_regs[0]);
 
-   perf_fetch_caller_regs(regs);
-   ___perf_sw_event(event_id, nr, regs, addr);
-   }
+   perf_fetch_caller_regs(regs);
+   ___perf_sw_event(event_id, nr, regs, addr);
 }
 
 extern struct static_key_false perf_sched_events;
 
-static __always_inline bool
-perf_sw_migrate_enabled(void)
+static __always_inline bool __perf_sw_enabled(int swevt)
 {
-   if 
(static_key_false(&perf_swevent_enabled[PERF_COUNT_SW_CPU_MIGRATIONS]))
-   return true;
-   return false;
+   return static_key_false(&perf_swevent_enabled[swevt]);
 }
 
 static inline void perf_event_task_migrate(struct task_struct *task)
 {
-   if (perf_sw_migrate_enabled())
+   if (__perf_sw_enabled(PERF_COUNT_SW_CPU_MIGRATIONS))
task->sched_migrated = 1;
 }
 
@@ -1207,11 +1201,9 @@ static inline void perf_event_task_sched_in(struct 
task_struct *prev,
if (static_branch_unlikely(&perf_sched_events))
__perf_event_task_sched_in(prev, task);
 
-   if (perf_sw_migrate_enabled() && task->sched_migrated) {
-   struct pt_regs *regs = this_cpu_ptr(&__perf_regs[0]);
-
-   perf_fetch_caller_regs(regs);
-   ___perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, regs, 0);
+   if (__perf_sw_enabled(PERF_COUNT_SW_CPU_MIGRATIONS) &&
+   task->sched_migrated) {
+   __perf_sw_event_sched(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 0);
task->sched_migrated = 0;
}
 }
@@ -1219,7 +1211,8 @@ static inline void perf_event_task_sched_in(struct 
task_struct *prev,
 static inline void perf_event_task_sched_out(struct task_struct *prev,
 struct task_struct *next)
 {
-   perf_sw_event_sched(PERF_COUNT_SW_CONTEXT_SWITCHES, 1, 0);
+   if (__perf_sw_enabled(PERF_COUNT_SW_CONTEXT_SWITCHES))
+   __perf_sw_event_sched(PERF_COUNT_SW_CONTEXT_SWITCHES, 1, 0);
 
if (static_branch_unlikely(&perf_sched_events))
__perf_event_task_sched_out(prev, next);
@@ -1475,8 +1468,6 @@ static inline int perf_event_refresh(struct perf_event 
*event, int refresh)
 static inline void
 perf_sw_event(u32 event_id, u64 nr, struct pt_regs *regs, u64 addr){ }
 static inline void
-perf_sw_event_sched(u32 event_id, u64 nr, u64 addr){ }
-static inline void
 perf_bp_event(struct perf_event *event, void *data){ }
 
 static inline int perf_register_guest_info_callbacks
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH v2 2/2] pinctrl: pinmux: Add pinmux-select debugfs file

[Geert Uytterhoeven]

Hi Drew,

On Wed, Feb 10, 2021 at 8:50 AM Drew Fustini  wrote:
> Add "pinmux-select" to debugfs which will activate a function and group
> when 2 integers " " are written to
> the file. The write operation pinmux_select() handles this by checking
> if fsel and gsel are valid selectors and then calling ops->set_mux().

Thanks for your patch!

> The existing "pinmux-functions" debugfs file lists the pin functions
> registered for the pin controller. For example:
>
> function: pinmux-uart0, groups = [ pinmux-uart0-pins ]
> function: pinmux-mmc0, groups = [ pinmux-mmc0-pins ]
> function: pinmux-mmc1, groups = [ pinmux-mmc1-pins ]
> function: pinmux-i2c0, groups = [ pinmux-i2c0-pins ]
> function: pinmux-i2c1, groups = [ pinmux-i2c1-pins ]
> function: pinmux-spi1, groups = [ pinmux-spi1-pins ]
>
> To activate function pinmux-i2c1 (fsel 4) and group pinmux-i2c1-pins
> (gsel 4):
>
> echo '4 4' > pinmux-select

I think you forgot to update the example.

I assume

echo pinmux-i2c1 pinmux-i2c1-pins > mux-select

?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v3 3/3] perf tools: Add 'cgroup-switches' software event

[Namhyung Kim]

It counts how often cgroups are changed actually during the context
switches.

  # perf stat -a -e context-switches,cgroup-switches -a sleep 1

   Performance counter stats for 'system wide':

  11,267  context-switches
  10,950  cgroup-switches

 1.015634369 seconds time elapsed

Signed-off-by: Namhyung Kim 
---
 tools/include/uapi/linux/perf_event.h | 1 +
 tools/perf/util/parse-events.c| 4 
 tools/perf/util/parse-events.l| 1 +
 3 files changed, 6 insertions(+)

diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index b15e3447cd9f..16b9538ad89b 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -112,6 +112,7 @@ enum perf_sw_ids {
PERF_COUNT_SW_EMULATION_FAULTS  = 8,
PERF_COUNT_SW_DUMMY = 9,
PERF_COUNT_SW_BPF_OUTPUT= 10,
+   PERF_COUNT_SW_CGROUP_SWITCHES   = 11,
 
PERF_COUNT_SW_MAX,  /* non-ABI */
 };
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 42c84adeb2fb..09ff678519f3 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -145,6 +145,10 @@ struct event_symbol event_symbols_sw[PERF_COUNT_SW_MAX] = {
.symbol = "bpf-output",
.alias  = "",
},
+   [PERF_COUNT_SW_CGROUP_SWITCHES] = {
+   .symbol = "cgroup-switches",
+   .alias  = "",
+   },
 };
 
 #define __PERF_EVENT_FIELD(config, name) \
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 9db5097317f4..88f203bb6fab 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -347,6 +347,7 @@ emulation-faults{ return 
sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_EM
 dummy  { return sym(yyscanner, 
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_DUMMY); }
 duration_time  { return tool(yyscanner, 
PERF_TOOL_DURATION_TIME); }
 bpf-output { return sym(yyscanner, 
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_BPF_OUTPUT); }
+cgroup-switches{ return sym(yyscanner, 
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_CGROUP_SWITCHES); }
 
/*
 * We have to handle the kernel PMU event 
cycles-ct/cycles-t/mem-loads/mem-stores separately.
-- 
2.30.0.478.g8a0d178c01-goog

[PATCH v3 2/3] perf core: Add PERF_COUNT_SW_CGROUP_SWITCHES event

[Namhyung Kim]

This patch adds a new software event to count context switches
involving cgroup switches.  So it's counted only if cgroups of
previous and next tasks are different.  Note that it only checks the
cgroups in the perf_event subsystem.  For cgroup v2, it shouldn't
matter anyway.

One can argue that we can do this by using existing sched_switch event
with eBPF.  But some systems might not have eBPF for some reason so
I'd like to add this as a simple way.

Signed-off-by: Namhyung Kim 
---
 include/linux/perf_event.h  | 7 +++
 include/uapi/linux/perf_event.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 2a1be6026a2f..270dbe2ae0b2 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1214,6 +1214,13 @@ static inline void perf_event_task_sched_out(struct 
task_struct *prev,
if (__perf_sw_enabled(PERF_COUNT_SW_CONTEXT_SWITCHES))
__perf_sw_event_sched(PERF_COUNT_SW_CONTEXT_SWITCHES, 1, 0);
 
+#ifdef CONFIG_CGROUP_PERF
+   if (__perf_sw_enabled(PERF_COUNT_SW_CGROUP_SWITCHES) &&
+   perf_cgroup_from_task(prev, NULL) !=
+   perf_cgroup_from_task(next, NULL))
+   __perf_sw_event_sched(PERF_COUNT_SW_CGROUP_SWITCHES, 1, 0);
+#endif
+
if (static_branch_unlikely(&perf_sched_events))
__perf_event_task_sched_out(prev, next);
 }
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 7d292de51410..78445919a752 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -112,6 +112,7 @@ enum perf_sw_ids {
PERF_COUNT_SW_EMULATION_FAULTS  = 8,
PERF_COUNT_SW_DUMMY = 9,
PERF_COUNT_SW_BPF_OUTPUT= 10,
+   PERF_COUNT_SW_CGROUP_SWITCHES   = 11,
 
PERF_COUNT_SW_MAX,  /* non-ABI */
 };
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH v5 2/2] power: supply: bq25790: Introduce the BQ25790 charger driver

[Krzysztof Kozlowski]

On Tue, 2 Feb 2021 at 03:20, Ricardo Rivera-Matos  wrote:
>
> From: Dan Murphy 
>
> BQ25790 is a highly integrated switch-mode buck-boost charger
> for 1-4 cell Li-ion battery and Li-polymer battery.
>
> Signed-off-by: Ricardo Rivera-Matos 
> Signed-off-by: Dan Murphy 

Looks like wrong order of Sobs. Since Dan was the author, did you
really contribute here before him?

(...)

> +
> +static bool bq25790_state_changed(struct bq25790_device *bq,
> + struct bq25790_state *new_state)
> +{
> +   struct bq25790_state old_state;
> +
> +   mutex_lock(&bq->lock);
> +   old_state = bq->state;
> +   mutex_unlock(&bq->lock);
> +
> +   return memcmp(&old_state, new_state,
> +   sizeof(struct bq25790_state)) != 0;
> +}
> +
> +static irqreturn_t bq25790_irq_handler_thread(int irq, void *private)
> +{
> +   struct bq25790_device *bq = private;
> +   struct bq25790_state state;
> +   int ret;
> +
> +   ret = bq25790_get_state(bq, &state);
> +   if (ret < 0)
> +   goto irq_out;
> +
> +   if (!bq25790_state_changed(bq, &state))

You will be waking up user-space on every voltage or current change.
It was expressed on the lists that this is not desired and instead you
should notify only on change of important attributes (e.g. SoC, charge
status, cable status).


> +   goto irq_out;
> +
> +   mutex_lock(&bq->lock);
> +   bq->state = state;
> +   mutex_unlock(&bq->lock);
> +
> +   power_supply_changed(bq->charger);
> +
> +irq_out:
> +   return IRQ_HANDLED;
> +}
> +

(...)

> +
> +static int bq25790_parse_dt(struct bq25790_device *bq,
> +   struct power_supply_config *psy_cfg, struct device *dev)
> +{
> +   int ret = 0;
> +
> +   psy_cfg->drv_data = bq;
> +   psy_cfg->of_node = dev->of_node;

You parse here DT, so don't initialize power supply config in the same
time. It's mixing two things in the same function.

> +
> +   ret = device_property_read_u32(bq->dev, "ti,watchdog-timeout-ms",
> +  &bq->watchdog_timer);
> +   if (ret)
> +   bq->watchdog_timer = BQ25790_WATCHDOG_DIS;
> +
> +   if (bq->watchdog_timer > BQ25790_WATCHDOG_MAX ||
> +   bq->watchdog_timer < BQ25790_WATCHDOG_DIS)
> +   return -EINVAL;
> +
> +   ret = device_property_read_u32(bq->dev,
> +  "input-voltage-limit-microvolt",
> +  &bq->init_data.vlim);
> +   if (ret)
> +   bq->init_data.vlim = BQ25790_VINDPM_DEF_uV;
> +
> +   if (bq->init_data.vlim > BQ25790_VINDPM_V_MAX_uV ||
> +   bq->init_data.vlim < BQ25790_VINDPM_V_MIN_uV)
> +   return -EINVAL;
> +
> +   ret = device_property_read_u32(bq->dev,
> +  "input-current-limit-microamp",
> +  &bq->init_data.ilim);
> +   if (ret)
> +   bq->init_data.ilim = BQ25790_IINDPM_DEF_uA;
> +
> +   if (bq->init_data.ilim > BQ25790_IINDPM_I_MAX_uA ||
> +   bq->init_data.ilim < BQ25790_IINDPM_I_MIN_uA)
> +   return -EINVAL;
> +
> +   return 0;
> +}
> +
> +static int bq25790_probe(struct i2c_client *client,
> +const struct i2c_device_id *id)
> +{
> +   struct device *dev = &client->dev;
> +   struct bq25790_device *bq;
> +   struct power_supply_config psy_cfg = { };
> +
> +   int ret;
> +
> +   bq = devm_kzalloc(dev, sizeof(*bq), GFP_KERNEL);
> +   if (!bq)
> +   return -ENOMEM;
> +
> +   bq->client = client;
> +   bq->dev = dev;
> +
> +   mutex_init(&bq->lock);
> +
> +   strncpy(bq->model_name, id->name, I2C_NAME_SIZE);
> +
> +   bq->regmap = devm_regmap_init_i2c(client, &bq25790_regmap_config);
> +

Don't add blank line after every statement. All four blank lines above
should be removed.

> +   if (IS_ERR(bq->regmap)) {
> +   dev_err(dev, "Failed to allocate register map\n");
> +   return PTR_ERR(bq->regmap);
> +   }
> +
> +   i2c_set_clientdata(client, bq);
> +
> +   ret = bq25790_parse_dt(bq, &psy_cfg, dev);
> +   if (ret) {
> +   dev_err(dev, "Failed to read device tree properties%d\n", 
> ret);
> +   return ret;
> +   }
> +
> +   ret = devm_add_action_or_reset(dev, bq25790_charger_reset, bq);
> +   if (ret)
> +   return ret;
> +
> +   /* OTG reporting */
> +   bq->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> +   if (!IS_ERR_OR_NULL(bq->usb2_phy)) {
> +   INIT_WORK(&bq->usb_work, bq25790_usb_work);
> +   bq->usb_nb.notifier_call = bq25790_usb_notifier;
> +   usb_register_notifier(bq->usb2_phy, &bq->usb_nb);

Where is the error checking? Where is cleanup in remove()?

> +   }
> +
> +   bq->usb3_phy = devm_usb_get_ph

[PATCH] soc: ti: omap-prm: Fix reboot issue with invalid pcie reset map for dra7

[Tony Lindgren]

Yongqin Liu  reported an issue where reboot hangs
on beagleboard-x15. This started happening after commit 7078a5ba7a58
("soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1").

We now assert any 012 type resets on init to prevent unconfigured
accelerator MMUs getting enabled on init depending on the bootloader or
kexec configured state.

Turns out that we now also wrongly assert dra7 l3init domain PCIe reset
bits causing a hang during reboot. Let's fix the l3init reset bits to
use a 01 map instead of 012 map. There are only two rstctrl bits and not
three. This is documented in TRM "Table 3-1647. RM_PCIESS_RSTCTRL".

Fixes: 5a68c87afde0 ("soc: ti: omap-prm: dra7: add genpd support for remaining 
PRM instances")
Fixes: 7078a5ba7a58 ("soc: ti: omap-prm: Fix boot time errors for rst_map_012 
bits 0 and 1")
Cc: Kishon Vijay Abraham I 
Reported-by: Yongqin Liu 
Signed-off-by: Tony Lindgren 
---
 drivers/soc/ti/omap_prm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -332,7 +332,7 @@ static const struct omap_prm_data dra7_prm_data[] = {
{
.name = "l3init", .base = 0x4ae07300,
.pwrstctrl = 0x0, .pwrstst = 0x4, .dmap = &omap_prm_alwon,
-   .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_012,
+   .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01,
.clkdm_name = "pcie"
},
{
-- 
2.30.1

Linux 4.9.257

[Greg Kroah-Hartman]

I'm announcing the release of the 4.9.257 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.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  |   10 -
 arch/arm/mach-footbridge/dc21285.c|   12 -
 arch/x86/Makefile |3 
 arch/x86/include/asm/apic.h   |   10 -
 arch/x86/include/asm/barrier.h|   18 ++
 arch/x86/kernel/apic/apic.c   |4 
 arch/x86/kernel/apic/x2apic_cluster.c |6 
 arch/x86/kernel/apic/x2apic_phys.c|6 
 drivers/acpi/thermal.c|   55 --
 drivers/input/joystick/xpad.c |   17 +-
 drivers/input/serio/i8042-x86ia64io.h |2 
 drivers/iommu/intel-iommu.c   |6 
 drivers/mmc/core/sdio_cis.c   |6 
 drivers/net/dsa/bcm_sf2.c |8 
 drivers/net/ethernet/ibm/ibmvnic.c|6 
 drivers/scsi/ibmvscsi/ibmvfc.c|4 
 drivers/scsi/libfc/fc_exch.c  |   16 +
 drivers/usb/class/usblp.c |   19 +-
 drivers/usb/dwc2/gadget.c |8 
 drivers/usb/gadget/legacy/ether.c |4 
 drivers/usb/host/xhci-ring.c  |   31 ++-
 drivers/usb/serial/cp210x.c   |2 
 drivers/usb/serial/option.c   |6 
 fs/cifs/dir.c |   22 ++
 fs/hugetlbfs/inode.c  |3 
 include/linux/elfcore.h   |   22 ++
 include/linux/hugetlb.h   |3 
 kernel/Makefile   |1 
 kernel/elfcore.c  |   25 ---
 kernel/futex.c|  276 +++---
 kernel/kprobes.c  |4 
 kernel/locking/rtmutex-debug.c|9 -
 kernel/locking/rtmutex-debug.h|3 
 kernel/locking/rtmutex.c  |  127 +--
 kernel/locking/rtmutex.h  |2 
 kernel/locking/rtmutex_common.h   |   12 -
 mm/huge_memory.c  |   37 ++--
 mm/hugetlb.c  |9 -
 net/lapb/lapb_out.c   |3 
 net/mac80211/driver-ops.c |5 
 net/mac80211/rate.c   |3 
 net/mac80211/rx.c |2 
 net/sched/sch_api.c   |3 
 sound/pci/hda/patch_realtek.c |2 
 tools/objtool/elf.c   |7 
 45 files changed, 520 insertions(+), 319 deletions(-)

Alexey Dobriyan (1):
  Input: i8042 - unbreak Pegatron C15B

Arnd Bergmann (1):
  elfcore: fix building with clang

Aurelien Aptel (1):
  cifs: report error instead of invalid when revalidating a dentry fails

Benjamin Valentin (1):
  Input: xpad - sync supported devices with fork on GitHub

Brian King (1):
  scsi: ibmvfc: Set default timeout to avoid crash during migration

Chenxin Jin (1):
  USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000

Christoph Schemmel (1):
  USB: serial: option: Adding support for Cinterion MV31

Dan Carpenter (1):
  USB: gadget: legacy: fix an error code in eth_bind()

Dave Hansen (1):
  x86/apic: Add extra serialization for non-serializing MSRs

Eric Dumazet (1):
  net_sched: reject silly cell_log in qdisc_get_rtab()

Felix Fietkau (2):
  mac80211: fix fast-rx encryption check
  mac80211: fix station rate table updates on assoc

Fengnan Chang (1):
  mmc: core: Limit retries when analyse of SDIO tuples fails

Greg Kroah-Hartman (1):
  Linux 4.9.257

Heiko Stuebner (1):
  usb: dwc2: Fix endpoint direction check in ep_from_windex

Hugh Dickins (1):
  mm: thp: fix MADV_REMOVE deadlock on shmem THP

Javed Hasan (1):
  scsi: libfc: Avoid invoking response handler twice if ep is already 
completed

Jeremy Figgins (1):
  USB: usblp: don't call usb_set_interface if there's a single alt

Josh Poimboeuf (2):
  objtool: Don't fail on missing symbol table
  x86/build: Disable CET instrumentation in the kernel

Lijun Pan (1):
  ibmvnic: Ensure that CRQ entry read are correctly ordered

Mathias Nyman (1):
  xhci: fix bounce buffer usage for non-sg list case

Muchun Song (3):
  mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
  mm: hugetlb: fix a race between isolating and freeing page
  mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active

Nadav Amit (1):
  iommu/vt-d: Do not use flush-queue when caching-mode is on

Pan Bian (1):
  net: dsa: bcm_sf2: put device node before return

Peter Zijlstra (4):
  futex,rt_mutex: Provide futex specific rt_mutex API
  futex: Remove rt_mutex_deadlock_account_*()
  futex: Rework inconsistent rt_mutex/futex_q state
  futex: Avoid violating the 10th rule of futex

Pho Tran (1):
  U

Linux 4.4.257

[Greg Kroah-Hartman]

I'm announcing the release of the 4.4.257 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.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  |   10 -
 arch/arm/mach-footbridge/dc21285.c|   12 -
 arch/mips/Kconfig |1 
 arch/x86/Makefile |3 
 arch/x86/include/asm/apic.h   |   10 -
 arch/x86/include/asm/barrier.h|   18 ++
 arch/x86/kernel/apic/apic.c   |4 
 arch/x86/kernel/apic/x2apic_cluster.c |3 
 arch/x86/kernel/apic/x2apic_phys.c|3 
 drivers/acpi/thermal.c|   54 --
 drivers/input/joystick/xpad.c |   17 +-
 drivers/input/serio/i8042-x86ia64io.h |2 
 drivers/mmc/core/sdio_cis.c   |6 
 drivers/scsi/ibmvscsi/ibmvfc.c|4 
 drivers/scsi/libfc/fc_exch.c  |   16 +
 drivers/usb/class/usblp.c |   19 +-
 drivers/usb/dwc2/gadget.c |8 
 drivers/usb/gadget/legacy/ether.c |4 
 drivers/usb/gadget/udc/udc-core.c |   13 +
 drivers/usb/serial/cp210x.c   |2 
 drivers/usb/serial/option.c   |6 
 fs/Kconfig.binfmt |8 
 fs/cifs/dir.c |   22 ++
 fs/hugetlbfs/inode.c  |3 
 include/linux/elfcore.h   |   22 ++
 include/linux/hugetlb.h   |3 
 kernel/Makefile   |3 
 kernel/elfcore.c  |   25 ---
 kernel/futex.c|  278 +++---
 kernel/kprobes.c  |4 
 kernel/locking/rtmutex-debug.c|9 -
 kernel/locking/rtmutex-debug.h|3 
 kernel/locking/rtmutex.c  |  127 +--
 kernel/locking/rtmutex.h  |2 
 kernel/locking/rtmutex_common.h   |   12 -
 mm/hugetlb.c  |9 -
 net/lapb/lapb_out.c   |3 
 net/mac80211/driver-ops.c |5 
 net/mac80211/rate.c   |3 
 net/sched/sch_api.c   |3 
 sound/pci/hda/patch_realtek.c |2 
 41 files changed, 468 insertions(+), 293 deletions(-)

Alexey Dobriyan (1):
  Input: i8042 - unbreak Pegatron C15B

Arnd Bergmann (1):
  elfcore: fix building with clang

Aurelien Aptel (1):
  cifs: report error instead of invalid when revalidating a dentry fails

Benjamin Valentin (1):
  Input: xpad - sync supported devices with fork on GitHub

Brian King (1):
  scsi: ibmvfc: Set default timeout to avoid crash during migration

Chenxin Jin (1):
  USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000

Christoph Schemmel (1):
  USB: serial: option: Adding support for Cinterion MV31

Dan Carpenter (1):
  USB: gadget: legacy: fix an error code in eth_bind()

Dave Hansen (1):
  x86/apic: Add extra serialization for non-serializing MSRs

Eric Dumazet (1):
  net_sched: reject silly cell_log in qdisc_get_rtab()

Felix Fietkau (1):
  mac80211: fix station rate table updates on assoc

Fengnan Chang (1):
  mmc: core: Limit retries when analyse of SDIO tuples fails

Greg Kroah-Hartman (1):
  Linux 4.4.257

Heiko Stuebner (1):
  usb: dwc2: Fix endpoint direction check in ep_from_windex

Javed Hasan (1):
  scsi: libfc: Avoid invoking response handler twice if ep is already 
completed

Jeremy Figgins (1):
  USB: usblp: don't call usb_set_interface if there's a single alt

Josh Poimboeuf (1):
  x86/build: Disable CET instrumentation in the kernel

Lee Jones (10):
  futex,rt_mutex: Provide futex specific rt_mutex API
  futex: Remove rt_mutex_deadlock_account_*()
  futex: Rework inconsistent rt_mutex/futex_q state
  futex: Avoid violating the 10th rule of futex
  futex: Replace pointless printk in fixup_owner()
  futex: Provide and use pi_state_update_owner()
  rtmutex: Remove unused argument from rt_mutex_proxy_unlock()
  futex: Use pi_state_update_owner() in put_pi_state()
  futex: Simplify fixup_pi_state_owner()
  futex: Handle faults correctly for PI futexes

Muchun Song (3):
  mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
  mm: hugetlb: fix a race between isolating and freeing page
  mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active

Pho Tran (1):
  USB: serial: cp210x: add pid/vid for WSDA-200-USB

Rafael J. Wysocki (1):
  ACPI: thermal: Do not call acpi_thermal_check() directly

Ralf Baechle (1):
  ELF/MIPS build fix

Russell King (1):
  ARM: footbridge: fix dc21285 PCI configuration accessors

Sasha Levin (1):
  stable: clamp SUBLEVEL in 4.4 and 4.9

Shih-Yuan Lee (Fou

Re: Linux 4.4.257

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index 0057587d2cbe..8de8f9ac3279 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 256
+SUBLEVEL = 257
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
@@ -830,12 +830,6 @@ KBUILD_CFLAGS   += $(call 
cc-option,-Werror=strict-prototypes)
 # Prohibit date/time macros, which would make the build non-deterministic
 KBUILD_CFLAGS   += $(call cc-option,-Werror=date-time)
 
-# ensure -fcf-protection is disabled when using retpoline as it is
-# incompatible with -mindirect-branch=thunk-extern
-ifdef CONFIG_RETPOLINE
-KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
-endif
-
 # use the deterministic mode of AR if available
 KBUILD_ARFLAGS := $(call ar-option,D)
 
@@ -1068,7 +1062,7 @@ endef
 
 define filechk_version.h
(echo \#define LINUX_VERSION_CODE $(shell \
-   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
+   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255); \
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
 endef
 
diff --git a/arch/arm/mach-footbridge/dc21285.c 
b/arch/arm/mach-footbridge/dc21285.c
index 96a3d73ef4bf..fd6c9169fa78 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -69,15 +69,15 @@ dc21285_read_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("ldrb   %0, [%1, %2]"
+   asm volatile("ldrb  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 2:
-   asm("ldrh   %0, [%1, %2]"
+   asm volatile("ldrh  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 4:
-   asm("ldr%0, [%1, %2]"
+   asm volatile("ldr   %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
}
@@ -103,17 +103,17 @@ dc21285_write_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("strb   %0, [%1, %2]"
+   asm volatile("strb  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 2:
-   asm("strh   %0, [%1, %2]"
+   asm volatile("strh  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 4:
-   asm("str%0, [%1, %2]"
+   asm volatile("str   %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9d8bc19edc48..9f1376788820 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2990,6 +2990,7 @@ config MIPS32_N32
 config BINFMT_ELF32
bool
default y if MIPS32_O32 || MIPS32_N32
+   select ELFCORE
 
 endmenu
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 8b4d022ce0cb..e59dc138b24e 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -137,6 +137,9 @@ else
 KBUILD_CFLAGS += -mno-red-zone
 KBUILD_CFLAGS += -mcmodel=kernel
 
+   # Intel CET isn't enabled in the kernel
+   KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
+
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
 KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 3328a37ddc75..34f11bc42d9b 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -168,16 +168,6 @@ static inline void disable_local_APIC(void) { }
 #endif /* !CONFIG_X86_LOCAL_APIC */
 
 #ifdef CONFIG_X86_X2APIC
-/*
- * Make previous memory operations globally visible before
- * sending the IPI through x2apic wrmsr. We need a serializing instruction or
- * mfence for this.
- */
-static inline void x2apic_wrmsr_fence(void)
-{
-   asm volatile("mfence" : : : "memory");
-}
-
 static inline void native_apic_msr_write(u32 reg, u32 v)
 {
if (reg == APIC_DFR || reg == APIC_ID || reg == APIC_LDR ||
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index b2a5bef74282..134d7ffc662e 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -119,4 +119,22 @@ do { 

Re: Linux 4.9.257

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index 69af44d3dcd1..e53096154f81 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 256
+SUBLEVEL = 257
 EXTRAVERSION =
 NAME = Roaring Lionus
 
@@ -841,12 +841,6 @@ KBUILD_CFLAGS   += $(call 
cc-option,-Werror=designated-init)
 # change __FILE__ to the relative path from the srctree
 KBUILD_CFLAGS  += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
 
-# ensure -fcf-protection is disabled when using retpoline as it is
-# incompatible with -mindirect-branch=thunk-extern
-ifdef CONFIG_RETPOLINE
-KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
-endif
-
 # use the deterministic mode of AR if available
 KBUILD_ARFLAGS := $(call ar-option,D)
 
@@ -1141,7 +1135,7 @@ endef
 
 define filechk_version.h
(echo \#define LINUX_VERSION_CODE $(shell \
-   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
+   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255); \
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
 endef
 
diff --git a/arch/arm/mach-footbridge/dc21285.c 
b/arch/arm/mach-footbridge/dc21285.c
index 96a3d73ef4bf..fd6c9169fa78 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -69,15 +69,15 @@ dc21285_read_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("ldrb   %0, [%1, %2]"
+   asm volatile("ldrb  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 2:
-   asm("ldrh   %0, [%1, %2]"
+   asm volatile("ldrh  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 4:
-   asm("ldr%0, [%1, %2]"
+   asm volatile("ldr   %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
}
@@ -103,17 +103,17 @@ dc21285_write_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("strb   %0, [%1, %2]"
+   asm volatile("strb  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 2:
-   asm("strh   %0, [%1, %2]"
+   asm volatile("strh  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 4:
-   asm("str%0, [%1, %2]"
+   asm volatile("str   %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 940ed27a6212..a95d414663b1 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -137,6 +137,9 @@ else
 KBUILD_CFLAGS += -mno-red-zone
 KBUILD_CFLAGS += -mcmodel=kernel
 
+   # Intel CET isn't enabled in the kernel
+   KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
+
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
 KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f39fd349cef6..a6d034257b7b 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -176,16 +176,6 @@ static inline void lapic_update_tsc_freq(void) { }
 #endif /* !CONFIG_X86_LOCAL_APIC */
 
 #ifdef CONFIG_X86_X2APIC
-/*
- * Make previous memory operations globally visible before
- * sending the IPI through x2apic wrmsr. We need a serializing instruction or
- * mfence for this.
- */
-static inline void x2apic_wrmsr_fence(void)
-{
-   asm volatile("mfence" : : : "memory");
-}
-
 static inline void native_apic_msr_write(u32 reg, u32 v)
 {
if (reg == APIC_DFR || reg == APIC_ID || reg == APIC_LDR ||
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index a0f450b21d67..89b75edf24af 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -110,4 +110,22 @@ do {   
\
 
 #include 
 
+/*
+ * Make previous memory operations globally visible before
+ * a WRMSR.
+ *
+ * MFENCE makes writes visible, but only affects load/store
+ * instructions.  WRMSR is unfortunately not a load/store
+ * instruction and 

Re: [PATCH v5 1/2] dt-bindings: power: Add the bq25790 dt bindings

[Krzysztof Kozlowski]

On Tue, 2 Feb 2021 at 03:20, Ricardo Rivera-Matos  wrote:
>
> From: Dan Murphy 
>
> Add the bindings for the bq25790.
>
> Reviewed-by: Rob Herring 
> Signed-off-by: Ricardo Rivera-Matos 
> Signed-off-by: Dan Murphy 

Order of tags is entirely wrong. Did Rob review it before Dan write
it?  Your Sob should be after Dan's (unless you wrote it at first?).\

> ---
>  .../bindings/power/supply/bq25790.yaml| 95 +++
>  1 file changed, 95 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/supply/bq25790.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/supply/bq25790.yaml 
> b/Documentation/devicetree/bindings/power/supply/bq25790.yaml
> new file mode 100644
> index ..6d9178ce5a2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/bq25790.yaml
> @@ -0,0 +1,95 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/power/supply/bq25790.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: TI BQ25790 Switch Mode Buck-Boost Charger
> +
> +maintainers:
> +  - Dan Murphy 
> +
> +description: |
> +  BQ25790 is a highly integrated switch-mode buck-boost charger for 1-4 cell
> +  Li-ion batteries and Li-polymer batteries. The device charges a battery 
> from a
> +  wide range of input sources including legacy USB adapters to high voltage 
> USB
> +  PD adapters and traditional barrel adapters.
> +
> +allOf:
> +  - $ref: power-supply.yaml#
> +
> +properties:
> +  compatible:
> +enum:
> +  - ti,bq25790
> +  - ti,bq25792
> +
> +  reg:
> +maxItems: 1
> +
> +  ti,watchdog-timeout-ms:
> +default: 0
> +description: |
> +  Watchdog timer in milli seconds. 0 (default) disables the watchdog.
> +minimum: 0
> +maximum: 16

Why do you need minimum/maximum if you enumerate the values?

> +enum: [ 0, 500, 1000, 2000, 2, 4, 8, 16]
> +
> +  input-voltage-limit-microvolt:
> +description: |
> +  Minimum input voltage limit in micro volts with a 10 micro volt 
> step.
> +minimum: 360
> +maximum: 2200
> +
> +  input-current-limit-microamp:
> +description: |
> +  Maximum input current limit in micro amps with a 10 micro amp step.
> +minimum: 10
> +maximum: 330
> +
> +  monitored-battery:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: phandle to the battery node being monitored
> +
> +  interrupts:
> +maxItems: 1
> +description: |
> +  Interrupt sends an active low, 256 μs pulse to host to report the 
> charger
> +  device status and faults.
> +
> +required:
> +  - compatible
> +  - reg
> +  - monitored-battery
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +bat: battery {
> +  compatible = "simple-battery";
> +  constant-charge-current-max-microamp = <200>;
> +  constant-charge-voltage-max-microvolt = <420>;
> +  precharge-current-microamp = <16>;
> +  charge-term-current-microamp = <16>;
> +};
> +#include 
> +#include 

Includes go to the beginning of example (and to beginning of DTS).

Best regards,
Krzysztof

[PATCH RESEND] MAINTAINERS: replace non-matching patterns for loongson{2,3}

[Lukas Bulwahn]

Commit ffe1f9356fbe ("MAINTAINERS: Add Loongson-2/Loongson-3 maintainers")
adds quite generic file entries for drivers/*/*loongson{2,3}* and
drivers/*/*/*loongson{2,3}* to be informed on changes to all loongson{2,3}
files in drivers.

However, only the pattern 'drivers/*/*loongson2*' matches to one file in
the repository, i.e., drivers/cpufreq/loongson2_cpufreq.c; all other
patterns have no file matches.

Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:

  warning: no file matchesF:drivers/*/*/*loongson2*
  warning: no file matchesF:drivers/*/*/*loongson3*
  warning: no file matchesF:drivers/*/*loongson3*

As in the last two and half years, no further files and drivers have
showed up to match those patterns, just name the one file that matches
explicitly and delete the others without a match.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on current master and next-20210209

Keguang, Huacai, Jiaxun, please ack.

Thomas, please pick this minor non-urgent cleanup patch.

 MAINTAINERS | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e2ab01363df..4bdf2fdb0456 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11946,8 +11946,7 @@ L:  linux-m...@vger.kernel.org
 S: Maintained
 F: arch/mips/include/asm/mach-loongson2ef/
 F: arch/mips/loongson2ef/
-F: drivers/*/*/*loongson2*
-F: drivers/*/*loongson2*
+F: drivers/cpufreq/loongson2_cpufreq.c
 
 MIPS/LOONGSON64 ARCHITECTURE
 M: Huacai Chen 
@@ -11956,8 +11955,6 @@ L:  linux-m...@vger.kernel.org
 S: Maintained
 F: arch/mips/include/asm/mach-loongson64/
 F: arch/mips/loongson64/
-F: drivers/*/*/*loongson3*
-F: drivers/*/*loongson3*
 F: drivers/irqchip/irq-loongson*
 F: drivers/platform/mips/cpu_hwmon.c
 
-- 
2.17.1

[RFC][PATCH] objtool: WARN about ENDBR instructions

[Peter Zijlstra]

Given all the ENDBR fun we recently had, do we want the below? Until
someone comes and fixes up kprobes/ftrace/livepatch etc.. having them is
a giant pain and we'd better warn about it.

---
diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index 931cef78b857..e708731b10cd 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -91,7 +91,7 @@ int arch_decode_instruction(const struct elf *elf, const 
struct section *sec,
 {
struct insn insn;
int x86_64, sign;
-   unsigned char op1, op2, rex = 0, rex_b = 0, rex_r = 0, rex_w = 0,
+   unsigned char op1, op2, pfx = 0, rex = 0, rex_b = 0, rex_r = 0, rex_w = 
0,
  rex_x = 0, modrm = 0, modrm_mod = 0, modrm_rm = 0,
  modrm_reg = 0, sib = 0;
struct stack_op *op = NULL;
@@ -118,6 +118,9 @@ int arch_decode_instruction(const struct elf *elf, const 
struct section *sec,
op1 = insn.opcode.bytes[0];
op2 = insn.opcode.bytes[1];
 
+   if (insn.prefixes.nbytes)
+   pfx = insn.prefixes.bytes[0];
+
if (insn.rex_prefix.nbytes) {
rex = insn.rex_prefix.bytes[0];
rex_w = X86_REX_W(rex) >> 3;
@@ -444,6 +447,11 @@ int arch_decode_instruction(const struct elf *elf, const 
struct section *sec,
/* nopl/nopw */
*type = INSN_NOP;
 
+   } else if (op2 == 0x1e && pfx == 0xf3 && (modrm == 0xfa || 
modrm == 0xfb)) {
+
+   /* endbr32/endbr64 */
+   WARN("endbr32/64 instruction at %s:0x%lx", sec->name, 
offset);
+
} else if (op2 == 0xa0 || op2 == 0xa8) {
 
/* push fs/gs */

Re: [PATCH v10 7/7] at24: Support probing while off

[Sakari Ailus]

On Tue, Feb 09, 2021 at 05:58:12PM +0100, Rafael J. Wysocki wrote:
> On Tue, Feb 9, 2021 at 5:54 PM Sakari Ailus
>  wrote:
> >
> > On Tue, Feb 09, 2021 at 05:42:45PM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Feb 9, 2021 at 5:23 PM Sakari Ailus
> > >  wrote:
> > > >
> > > > Hi Bartosz, Rafael,
> > > >
> > > > On Tue, Feb 09, 2021 at 04:49:37PM +0100, Bartosz Golaszewski wrote:
> > > > > On Mon, Feb 8, 2021 at 5:54 PM Rafael J. Wysocki  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Feb 8, 2021 at 5:44 PM Bartosz Golaszewski
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, Feb 5, 2021 at 2:25 PM Sakari Ailus
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > In certain use cases (where the chip is part of a camera 
> > > > > > > > module, and the
> > > > > > > > camera module is wired together with a camera privacy LED), 
> > > > > > > > powering on
> > > > > > > > the device during probe is undesirable. Add support for the 
> > > > > > > > at24 to
> > > > > > > > execute probe while being powered off. For this to happen, a 
> > > > > > > > hint in form
> > > > > > > > of a device property is required from the firmware.
> > > > > > > >
> > > > > > > > Signed-off-by: Sakari Ailus 
> > > > > > > > Reviewed-by: Tomasz Figa 
> > > > > > > > ---
> > > > > > >
> > > > > > > I'll ack this but I still claim that the name
> > > > > > > acpi_dev_state_low_power() is super misleading for this use-case 
> > > > > > > and
> > > > > > > I've been saying that for 10 versions now with everyone just 
> > > > > > > ignoring
> > > > > > > my remarks. :/
> > > > > >
> > > > > > Well, the function in question simply checks if the current ACPI 
> > > > > > power
> > > > > > state of the device is different from "full power", so its name
> > > > > > appears to be quite adequate to me.
> > > > > >
> > > > > > If the way in which it is used is confusing, though, I guess
> > > > > > explaining what's going on would be welcome.
> > > > > >
> > > > >
> > > > > Yes, I have explained it multiple time already - last time at v9 of 
> > > > > this series:
> > > > >
> > > > > https://www.spinics.net/lists/kernel/msg3816807.html
> > > >
> > > > How about adding this to the description of acpi_dev_state_low_power():
> > > >
> > > > ---8<--
> > > >  * This function is intended to be used by drivers to tell whether the 
> > > > device
> > > >  * is in low power state (D1--D3cold) in driver's probe or remove 
> > > > function. See
> > > >  * Documentation/firmware-guide/acpi/low-power-probe.rst for more 
> > > > information.
> > > > ---8<--
> > >
> > > This information is already there in the kerneldoc description of that
> > > function AFAICS.
> >
> > Ok, the D states are mentioned already. But how to use it is not, nor
> > there's a reference to the ReST file. I think that wouldn't hurt.
> >
> > >
> > > I was thinking about adding an explanation comment to the caller.
> >
> > I think it'd be best if the function name would convey that without a
> > comment that should then be added to all callers. How about calling the
> > function e.g. acpi_dev_state_d0() and negating the return value? The D0
> > state is well defined and we could do this without adding new terms.
> 
> That would work for me.

Bartosz, would that work for you?

I'd call the temporary variable in the at24 driver e.g. "full_power".

-- 
Regards,

Sakari Ailus

Linux 4.14.221

[Greg Kroah-Hartman]

I'm announcing the release of the 4.14.221 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   |8 -
 arch/arm/mach-footbridge/dc21285.c |   12 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |2 -
 arch/x86/Makefile  |3 +
 arch/x86/include/asm/apic.h|   10 --
 arch/x86/include/asm/barrier.h |   18 +++
 arch/x86/kernel/apic/apic.c|4 ++
 arch/x86/kernel/apic/x2apic_cluster.c  |6 ++-
 arch/x86/kernel/apic/x2apic_phys.c |6 ++-
 drivers/input/joystick/xpad.c  |   17 ++-
 drivers/input/serio/i8042-x86ia64io.h  |2 +
 drivers/iommu/intel-iommu.c|6 +++
 drivers/mmc/core/sdio_cis.c|6 +++
 drivers/net/dsa/mv88e6xxx/chip.c   |6 +++
 drivers/nvme/host/pci.c|2 +
 drivers/usb/class/usblp.c  |   19 +++-
 drivers/usb/dwc2/gadget.c  |8 -
 drivers/usb/gadget/legacy/ether.c  |4 +-
 drivers/usb/host/xhci-ring.c   |   31 +---
 drivers/usb/serial/cp210x.c|2 +
 drivers/usb/serial/option.c|6 +++
 fs/cifs/dir.c  |   22 +-
 fs/cifs/smb2pdu.h  |2 -
 fs/hugetlbfs/inode.c   |3 +
 fs/overlayfs/dir.c |2 -
 include/linux/elfcore.h|   22 ++
 include/linux/hugetlb.h|3 +
 kernel/Makefile|1 
 kernel/elfcore.c   |   26 -
 kernel/kprobes.c   |4 ++
 mm/huge_memory.c   |   37 +++-
 mm/hugetlb.c   |9 ++---
 net/ipv4/route.c   |   38 -
 net/lapb/lapb_out.c|3 +
 net/mac80211/driver-ops.c  |5 ++-
 net/mac80211/rate.c|3 +
 tools/objtool/orc_gen.c|   33 +
 37 files changed, 254 insertions(+), 137 deletions(-)

Alexey Dobriyan (1):
  Input: i8042 - unbreak Pegatron C15B

Arnd Bergmann (1):
  elfcore: fix building with clang

Aurelien Aptel (1):
  cifs: report error instead of invalid when revalidating a dentry fails

Benjamin Valentin (1):
  Input: xpad - sync supported devices with fork on GitHub

Chenxin Jin (1):
  USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000

Christoph Schemmel (1):
  USB: serial: option: Adding support for Cinterion MV31

DENG Qingfang (1):
  net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add

Dan Carpenter (1):
  USB: gadget: legacy: fix an error code in eth_bind()

Dave Hansen (1):
  x86/apic: Add extra serialization for non-serializing MSRs

Felix Fietkau (1):
  mac80211: fix station rate table updates on assoc

Fengnan Chang (1):
  mmc: core: Limit retries when analyse of SDIO tuples fails

Greg Kroah-Hartman (1):
  Linux 4.14.221

Gustavo A. R. Silva (1):
  smb3: Fix out-of-bounds bug in SMB2_negotiate()

Heiko Stuebner (1):
  usb: dwc2: Fix endpoint direction check in ep_from_windex

Hugh Dickins (1):
  mm: thp: fix MADV_REMOVE deadlock on shmem THP

Jeremy Figgins (1):
  USB: usblp: don't call usb_set_interface if there's a single alt

Josh Poimboeuf (2):
  objtool: Support Clang non-section symbols in ORC generation
  x86/build: Disable CET instrumentation in the kernel

Liangyan (1):
  ovl: fix dentry leak in ovl_get_redirect

Mathias Nyman (1):
  xhci: fix bounce buffer usage for non-sg list case

Muchun Song (3):
  mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
  mm: hugetlb: fix a race between isolating and freeing page
  mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active

Nadav Amit (1):
  iommu/vt-d: Do not use flush-queue when caching-mode is on

Pho Tran (1):
  USB: serial: cp210x: add pid/vid for WSDA-200-USB

Russell King (1):
  ARM: footbridge: fix dc21285 PCI configuration accessors

Thorsten Leemhuis (1):
  nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs

Wang ShaoBo (1):
  kretprobe: Avoid re-registration of the same kretprobe earlier

Wei Wang (1):
 

[PATCH v6 3/2] powerpc/syscall: Avoid storing 'current' in another pointer

[Christophe Leroy]

By saving the pointer pointing to thread_info.flags, gcc copies r2
in a non-volatile register.

We know 'current' doesn't change, so avoid that intermediaite pointer.

Reduces null_syscall benchmark by 2 cycles (322 => 320 cycles)

On PPC64, gcc seems to know that 'current' is not changing, and it keeps
it in a non volatile register to avoid multiple read of 'current' in paca.

Signed-off-by: Christophe Leroy 
---
v5: Also in interrupt exit prepare
v6: Removed change related to booke current->thread.debug
v7: Rebased on top of "powerpc/32: Handle bookE debugging in C in syscall 
entry/exit"
---
 arch/powerpc/kernel/interrupt.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index f93664ad4a5e..398cd86b6ada 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -241,7 +241,6 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
   struct pt_regs *regs,
   long scv)
 {
-   unsigned long *ti_flagsp = ¤t_thread_info()->flags;
unsigned long ti_flags;
unsigned long ret = 0;
bool is_not_scv = !IS_ENABLED(CONFIG_PPC_BOOK3S_64) || !scv;
@@ -257,7 +256,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
/* Check whether the syscall is issued inside a restartable sequence */
rseq_syscall(regs);
 
-   ti_flags = *ti_flagsp;
+   ti_flags = current_thread_info()->flags;
 
if (unlikely(r3 >= (unsigned long)-MAX_ERRNO) && is_not_scv) {
if (likely(!(ti_flags & (_TIF_NOERROR | _TIF_RESTOREALL {
@@ -271,7 +270,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
ret = _TIF_RESTOREALL;
else
regs->gpr[3] = r3;
-   clear_bits(_TIF_PERSYSCALL_MASK, ti_flagsp);
+   clear_bits(_TIF_PERSYSCALL_MASK, ¤t_thread_info()->flags);
} else {
regs->gpr[3] = r3;
}
@@ -284,7 +283,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
local_irq_disable();
 
 again:
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
while (unlikely(ti_flags & (_TIF_USER_WORK_MASK & ~_TIF_RESTORE_TM))) {
local_irq_enable();
if (ti_flags & _TIF_NEED_RESCHED) {
@@ -300,7 +299,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
do_notify_resume(regs, ti_flags);
}
local_irq_disable();
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
}
 
if (IS_ENABLED(CONFIG_PPC_BOOK3S) && IS_ENABLED(CONFIG_PPC_FPU)) {
@@ -357,7 +356,6 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
 #ifndef CONFIG_PPC_BOOK3E_64 /* BOOK3E not yet using this */
 notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs, 
unsigned long msr)
 {
-   unsigned long *ti_flagsp = ¤t_thread_info()->flags;
unsigned long ti_flags;
unsigned long flags;
unsigned long ret = 0;
@@ -380,7 +378,7 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
local_irq_save(flags);
 
 again:
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
while (unlikely(ti_flags & (_TIF_USER_WORK_MASK & ~_TIF_RESTORE_TM))) {
local_irq_enable(); /* returning to user: may enable */
if (ti_flags & _TIF_NEED_RESCHED) {
@@ -391,7 +389,7 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
do_notify_resume(regs, ti_flags);
}
local_irq_disable();
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
}
 
if (IS_ENABLED(CONFIG_PPC_BOOK3S) && IS_ENABLED(CONFIG_PPC_FPU)) {
@@ -443,7 +441,6 @@ void preempt_schedule_irq(void);
 
 notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs, 
unsigned long msr)
 {
-   unsigned long *ti_flagsp = ¤t_thread_info()->flags;
unsigned long flags;
unsigned long ret = 0;
 #ifdef CONFIG_PPC64
@@ -466,8 +463,8 @@ notrace unsigned long interrupt_exit_kernel_prepare(struct 
pt_regs *regs, unsign
amr = kuap_get_and_check_amr();
 #endif
 
-   if (unlikely(*ti_flagsp & _TIF_EMULATE_STACK_STORE)) {
-   clear_bits(_TIF_EMULATE_STACK_STORE, ti_flagsp);
+   if (unlikely(current_thread_info()->flags & _TIF_EMULATE_STACK_STORE)) {
+   clear_bits(_TIF_EMULATE_STACK_STORE, 
¤t_thread_info()->flags);
ret = 1;
}
 
@@ -479,7 +476,7 @@ notrace unsigned long interrupt_exit_kernel_

Re: Linux 4.14.221

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index 088dc5383dcf..b25ce26c1cd7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 220
+SUBLEVEL = 221
 EXTRAVERSION =
 NAME = Petit Gorille
 
@@ -844,12 +844,6 @@ KBUILD_CFLAGS   += $(call 
cc-option,-Werror=designated-init)
 # change __FILE__ to the relative path from the srctree
 KBUILD_CFLAGS  += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
 
-# ensure -fcf-protection is disabled when using retpoline as it is
-# incompatible with -mindirect-branch=thunk-extern
-ifdef CONFIG_RETPOLINE
-KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
-endif
-
 # use the deterministic mode of AR if available
 KBUILD_ARFLAGS := $(call ar-option,D)
 
diff --git a/arch/arm/mach-footbridge/dc21285.c 
b/arch/arm/mach-footbridge/dc21285.c
index 96a3d73ef4bf..fd6c9169fa78 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -69,15 +69,15 @@ dc21285_read_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("ldrb   %0, [%1, %2]"
+   asm volatile("ldrb  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 2:
-   asm("ldrh   %0, [%1, %2]"
+   asm volatile("ldrh  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 4:
-   asm("ldr%0, [%1, %2]"
+   asm volatile("ldr   %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
}
@@ -103,17 +103,17 @@ dc21285_write_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("strb   %0, [%1, %2]"
+   asm volatile("strb  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 2:
-   asm("strh   %0, [%1, %2]"
+   asm volatile("strh  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 4:
-   asm("str%0, [%1, %2]"
+   asm volatile("str   %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index c8ff0baddf1d..cb49d21e317c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -304,7 +304,7 @@
 
dcfg: dcfg@1ee {
compatible = "fsl,ls1046a-dcfg", "syscon";
-   reg = <0x0 0x1ee 0x0 0x1>;
+   reg = <0x0 0x1ee 0x0 0x1000>;
big-endian;
};
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 3dc54d2f79c4..4c8e9f12b0c4 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -138,6 +138,9 @@ else
 KBUILD_CFLAGS += -mno-red-zone
 KBUILD_CFLAGS += -mcmodel=kernel
 
+   # Intel CET isn't enabled in the kernel
+   KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
+
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
 KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 25a5a5c6ae90..95f59f5dffb3 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -174,16 +174,6 @@ static inline void lapic_update_tsc_freq(void) { }
 #endif /* !CONFIG_X86_LOCAL_APIC */
 
 #ifdef CONFIG_X86_X2APIC
-/*
- * Make previous memory operations globally visible before
- * sending the IPI through x2apic wrmsr. We need a serializing instruction or
- * mfence for this.
- */
-static inline void x2apic_wrmsr_fence(void)
-{
-   asm volatile("mfence" : : : "memory");
-}
-
 static inline void native_apic_msr_write(u32 reg, u32 v)
 {
if (reg == APIC_DFR || reg == APIC_ID || reg == APIC_LDR ||
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index bc88797cfa61..3895a7b6952b 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -111,4 +111,22 @@ do {   
\
 
 #incl

[PATCH] arch: x86: entry: vdso: Fix the spelling postive to positive in the file vsgx.S

[Bhaskar Chowdhury]

s/postive/positive/

Signed-off-by: Bhaskar Chowdhury 
---
 arch/x86/entry/vdso/vsgx.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/vsgx.S b/arch/x86/entry/vdso/vsgx.S
index 86a0e94f68df..99dafac992e2 100644
--- a/arch/x86/entry/vdso/vsgx.S
+++ b/arch/x86/entry/vdso/vsgx.S
@@ -137,7 +137,7 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave)

/*
 * If the return from callback is zero or negative, return immediately,
-* else re-execute ENCLU with the postive return value interpreted as
+* else re-execute ENCLU with the positive return value interpreted as
 * the requested ENCLU function.
 */
cmp $0, %eax
--
2.30.0

Re: [PATCH v5 20/22] powerpc/syscall: Avoid storing 'current' in another pointer

[Christophe Leroy]

Le 10/02/2021 à 03:00, Nicholas Piggin a écrit :

Excerpts from Christophe Leroy's message of February 10, 2021 3:03 am:



Le 09/02/2021 à 15:31, David Laight a écrit :

From: Segher Boessenkool

Sent: 09 February 2021 13:51

On Tue, Feb 09, 2021 at 12:36:20PM +1000, Nicholas Piggin wrote:

What if you did this?



+static inline struct task_struct *get_current(void)
+{
+   register struct task_struct *task asm ("r2");
+
+   return task;
+}


Local register asm variables are *only* guaranteed to live in that
register as operands to an asm.  See

https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html#Local-Register-Variables
("The only supported use" etc.)

You can do something like

static inline struct task_struct *get_current(void)
{
register struct task_struct *task asm ("r2");

asm("" : "+r"(task));

return task;
}

which makes sure that "task" actually is in r2 at the point of that asm.


If "r2" always contains current (and is never assigned by the compiler)
why not use a global register variable for it?




The change proposed by Nick doesn't solve the issue.


It seemed to change code generation in a simple test case, oh well.



The problem is that at the begining of the function we have:

unsigned long *ti_flagsp = ¤t_thread_info()->flags;

When the function uses ti_flagsp for the first time, it does use 112(r2)

Then the function calls some other functions.

Most likely because the function could update 'current', GCC copies r2 into 
r30, so that if r2 get
changed by the called function, ti_flagsp is still based on the previous value 
of current.

Allthough we know r2 wont change, GCC doesn't know it. And in order to save r2 
into r30, it needs to
save r30 in the stack.


By using ¤t_thread_info()->flags directly instead of this intermediaite 
ti_flagsp pointer, GCC
uses r2 instead instead of doing a copy.


Nick, I don't understand the reason why you need that 'ti_flagsp' local var.


Just to save typing, I don't mind your patch I was just wondering if
current could be improved in general.



Thanks,

I'll post v6 of it as a follow-up of yesterday's two remaining follow-up 
patches.

Christophe

Re: [PATCH] mm/hugetlb: use some helper functions to cleanup code

[David Hildenbrand]

On 10.02.21 07:53, Miaohe Lin wrote:

We could use pages_per_huge_page to get the number of pages per hugepage,
use get_hstate_idx to calculate hstate index, and use hstate_is_gigantic
to check if a hstate is gigantic to make code more succinct.



Another suggestion, please collect and group your cleanups for a 
subsystem and send them in a single cleanup patch series where possible. 
Again, makes life easier for reviewers and maintainers.


Thanks!


--
Thanks,

David / dhildenb

Re: linux-next: build failure after merge of the modules tree

[Masahiro Yamada]

On Wed, Feb 10, 2021 at 5:06 PM Jessica Yu  wrote:
>
> +++ Stephen Rothwell [10/02/21 08:50 +1100]:
> >Hi Jessica,
> >
> >On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu  wrote:
> >>
> >> Hmm, these errors don't look like it's related to that particular commit. 
> >> I was
> >
> >I found this commit by bisection and then tested by reverting it.
> >
> >Before this commit, CONFIG_TRIM_UNUSED_KSYMS would not be set in the
> >allyesconfig build because CONFIG_UNUSED_SYMBOLS was set.  After this
> >commit, CONFIG_TRIM_UNUSED_KSYMS will be set in the allyesconfig build.
>
> Ah, that makes sense then. I would get the error on powerpc whenever
> CONFIG_TRIM_UNUSED_KSYMS was enabled.
>
> >> able to reproduce these weird autoksym errors even without any modules-next
> >> patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
> >> CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run 
> >> into
> >> these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler and 
> >> got
> >> the same compiler warnings. It seems to not compile on powerpc properly 
> >> because
> >> it looks like some symbols have an extra dot "." prefix, for example in
> >> kthread.o:
> >>
> >> 168: 031824 NOTYPE  GLOBAL DEFAULT6 
> >> kthread_create_worker
> >> 169: 1d90   104 FUNCGLOBAL DEFAULT1 
> >> .kthread_create_worker
> >> 170: 033024 NOTYPE  GLOBAL DEFAULT6 
> >> kthread_create_worker_on_cpu
> >> 171: 1e0088 FUNCGLOBAL DEFAULT1 
> >> .kthread_create_worker_on_cpu
> >> 172: 034824 NOTYPE  GLOBAL DEFAULT6 
> >> kthread_queue_work
> >> 173: 1e60   228 FUNCGLOBAL DEFAULT1 
> >> .kthread_queue_work
> >>
> >> So I suppose this dot prefix is specific to powerpc. From the ppc64 elf 
> >> abi docs:
> >>
> >>  Symbol names with a dot (.) prefix are reserved for holding entry 
> >> point
> >>  addresses. The value of a symbol named ".FN", if it exists, is the 
> >> entry point
> >>  of the function "FN".
> >>
> >> I guess the presence of the extra dot symbols is confusing
> >> scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which 
> >> the
> >> preprocessor doesn't like. I am wondering how this was never caught until 
> >> now
> >> and also now curious if this feature was ever functional on powerpc..
> >
> >Which feature?
>
> Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
> option was introduced around v4.7. If simply enabling it produces
> these compilation errors I was wondering if it ever built properly on
> powerpc.
>
> Thanks,
>
> Jessica


Thanks for the report.

I think the following will fix the issue,
but modpost needs fixing too.


diff --git a/scripts/gen_autoksyms.sh b/scripts/gen_autoksyms.sh
index 16c0b2ddaa4c..996a7109167b 100755
--- a/scripts/gen_autoksyms.sh
+++ b/scripts/gen_autoksyms.sh
@@ -44,7 +44,7 @@ sed 's/ko$/mod/' $modlist |
 xargs -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' -- |
 cat - "$ksym_wl" |
 sort -u |
-sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
+sed -e 's/^\.\{,1\}\(.*\)/#define __KSYM_\1 1/' >> "$output_file"

 # Special case for modversions (see modpost.c)
 if [ -n "$CONFIG_MODVERSIONS" ]; then
m




I will post two patches with some commit log
after some testing.
(one for gen_autoksyms.sh and the other for modpost).





-- 
Best Regards
Masahiro Yamada

Re: [PATCH 4/5] ARM: dts: stm32: enable the analog filter for all I2C nodes in stm32mp151

[Pierre Yves MORDRET]

Hello

Looks good to me

Reviewed-by: Pierre-Yves MORDRET 

Thx
Regards


On 2/5/21 9:51 AM, Alain Volmat wrote:
> Enable the analog filter for all I2C nodes of the stm32mp151.
> 
> Signed-off-by: Alain Volmat 
> ---
>  arch/arm/boot/dts/stm32mp151.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stm32mp151.dtsi 
> b/arch/arm/boot/dts/stm32mp151.dtsi
> index 3c75abacb374..558fc8fb38b6 100644
> --- a/arch/arm/boot/dts/stm32mp151.dtsi
> +++ b/arch/arm/boot/dts/stm32mp151.dtsi
> @@ -493,6 +493,7 @@
>   #size-cells = <0>;
>   st,syscfg-fmp = <&syscfg 0x4 0x1>;
>   wakeup-source;
> + i2c-analog-filter;
>   status = "disabled";
>   };
>  
> @@ -508,6 +509,7 @@
>   #size-cells = <0>;
>   st,syscfg-fmp = <&syscfg 0x4 0x2>;
>   wakeup-source;
> + i2c-analog-filter;
>   status = "disabled";
>   };
>  
> @@ -523,6 +525,7 @@
>   #size-cells = <0>;
>   st,syscfg-fmp = <&syscfg 0x4 0x4>;
>   wakeup-source;
> + i2c-analog-filter;
>   status = "disabled";
>   };
>  
> @@ -538,6 +541,7 @@
>   #size-cells = <0>;
>   st,syscfg-fmp = <&syscfg 0x4 0x10>;
>   wakeup-source;
> + i2c-analog-filter;
>   status = "disabled";
>   };
>  
> @@ -1533,6 +1537,7 @@
>   #size-cells = <0>;
>   st,syscfg-fmp = <&syscfg 0x4 0x8>;
>   wakeup-source;
> + i2c-analog-filter;
>   status = "disabled";
>   };
>  
> @@ -1570,6 +1575,7 @@
>   #size-cells = <0>;
>   st,syscfg-fmp = <&syscfg 0x4 0x20>;
>   wakeup-source;
> + i2c-analog-filter;
>   status = "disabled";
>   };
>  
> 

-- 
--
~ Py MORDRET
--

Re: [init/console] a91bd6223e: unixbench.score -5.9% regression

[Petr Mladek]

Hello,

just for record.

On Tue 2021-02-09 13:49:25, kernel test robot wrote:
> 
> Greeting,
> 
> FYI, we noticed a -5.9% regression of unixbench.score due to commit:
> 
> 
> commit: a91bd6223ecd46addc71ee6fcd432206d39365d2 ("Revert "init/console: Use 
> ttynull as a fallback when there is no console"")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> 
> in testcase: unixbench
> on test machine: 16 threads Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz with 32G 
> memory
> with following parameters:
> 
>   runtime: 300s
>   nr_task: 30%
>   test: dhry2reg
>   cpufreq_governor: performance
>   ucode: 0xde
> 
> test-description: UnixBench is the original BYTE UNIX benchmark suite aims to 
> test performance of Unix-like system.
> test-url: https://github.com/kdlucas/byte-unixbench
> 
> 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot 
> 
> 
> Details are as below:
> -->
> 
> 
> To reproduce:
> 
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp installjob.yaml  # job file is attached in 
> this email
> bin/lkp split-job --compatible job.yaml
> bin/lkp runcompatible-job.yaml
> 
> =
> compiler/cpufreq_governor/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase/ucode:
>   
> gcc-9/performance/x86_64-rhel-8.3/30%/debian-10.4-x86_64-20200603.cgz/300s/lkp-cfl-e1/dhry2reg/unixbench/0xde
> 
> commit: 
>   c4cc3b1de3 ("Merge tag 'gcc-plugins-v5.11-rc3' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux")
>   a91bd6223e ("Revert "init/console: Use ttynull as a fallback when there is 
> no console"")
> 
> c4cc3b1de31b76f4 a91bd6223ecd46addc71ee6fcd4 
>  --- 
>fail:runs  %reproductionfail:runs
>| | |
>   0:42%   0:4 
> perf-profile.children.cycles-pp.error_entry
>  %stddev %change %stddev
>  \  |\  
>  19487-5.9%  18336unixbench.score
>  8.875e+10-5.9%  8.351e+10unixbench.workload
>   0.50+0.10.61 ±  3%  mpstat.cpu.all.irq%
>  44280 ±  4% +15.9%  51322 ±  3%  softirqs.CPU0.SCHED
>  29624 ±  3%  +9.6%  32476vmstat.system.in

>   2207 ±1927%   +3559.5%  80796 ± 18%  
> sched_debug.cfs_rq:/.spread0.avg
> 135343 ± 38% +61.1% 218075 ± 16%  sched_debug.cfs_rq:/.spread0.max
>   0.01 ± 31% +78.3%   0.01 ± 22%  
> perf-sched.sch_delay.avg.ms.do_nanosleep.hrtimer_nanosleep.__x64_sys_nanosleep.do_syscall_64
>   0.01 ±  7% +22.8%   0.02 ±  2%  
> perf-sched.sch_delay.avg.ms.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group.do_syscall_64
>   0.02 ± 15% +27.1%   0.02 ± 11%  
> perf-sched.sch_delay.avg.ms.do_wait.kernel_wait4.__do_sys_wait4.do_syscall_64
>   0.02 ± 44%+113.3%   0.04 ± 12%  
> perf-sched.sch_delay.avg.ms.exit_to_user_mode_prepare.syscall_exit_to_user_mode.entry_SYSCALL_64_after_hwframe.[unknown]
>   0.02 ± 10% +56.1%   0.03 ± 25%  
> perf-sched.sch_delay.avg.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_select
>   0.02 ± 44%+113.3%   0.04 ± 12%  
> perf-sched.sch_delay.max.ms.exit_to_user_mode_prepare.syscall_exit_to_user_mode.entry_SYSCALL_64_after_hwframe.[unknown]
>   0.01 ± 11% +37.5%   0.01 ± 19%  
> perf-sched.total_sch_delay.average.ms
>   2001  +120.7%   4416 ± 33%  
> perf-sched.wait_and_delay.max.ms.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group.do_syscall_64
>   0.05 ± 54% +56.5%   0.08 ±  7%  
> perf-sched.wait_time.avg.ms.schedule_timeout.khugepaged.kthread.ret_from_fork
>   2001  +120.7%   4416 ± 33%  
> perf-sched.wait_time.max.ms.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group.do_syscall_64
>   0.05 ± 54% +56.5%   0.08 ±  7%  
> perf-sched.wait_time.max.ms.schedule_timeout.khugepaged.kthread.ret_from_fork

>   0.07 ±173%  +0.20.27 ± 21%  
> perf-profile.children.cycles-pp.io_serial_in
>   0.07 ±173%  +0.20.30 ± 21%  
> perf-profile.children.cycles-pp.serial8250_console_putchar
>   0.07 ±173%  +0.20.31 ± 20%  
> perf-profile.children.cycles-pp.wait_for_xmitr
>   0.08 ±173%  +0.20.32 ± 21%  
> perf-profile.children.cycles-pp.uart_console_write
>   0.08 ±173%  +0.20.33 ± 21%  
> perf-profile.children.cycles-pp.serial8250_console_write
>   0.09 ±173%  +0.20.33 ± 22%  
> perf-profile.children.cycles-pp.asm_sysvec_irq_work
>   0.09 ±173%  +0.2

Re: [PATCH] clk: at91: Fix the declaration of the clocks

[Geert Uytterhoeven]

Hi Saravana,

On Wed, Feb 10, 2021 at 1:57 AM Saravana Kannan  wrote:
> On Tue, Feb 9, 2021 at 4:54 PM Stephen Boyd  wrote:
> > Quoting tudor.amba...@microchip.com (2021-02-08 01:49:45)
> > > Do you plan to take this patch for v5.12?
> > > If fw_devlink will remain set to ON for v5.12, some of our boards will
> > > no longer boot without this patch.
> >
> > Is fw_devlink defaulted to on for v5.12?
>
> Yes.

Have all issues been identified and understood?
Have all issues been fixed, reviewed, and committed?
Have all fixes entered linux-next?
Have all fixes been migrated from submaintainers to maintainers?

We're already at v5.11-rc7.
Yes, we can get fixes into v5.12-rc7. Or v5.12-rc9...

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] mm/hugetlb: use some helper functions to cleanup code

[Miaohe Lin]

On 2021/2/10 16:35, David Hildenbrand wrote:
> On 10.02.21 07:53, Miaohe Lin wrote:
>> We could use pages_per_huge_page to get the number of pages per hugepage,
>> use get_hstate_idx to calculate hstate index, and use hstate_is_gigantic
>> to check if a hstate is gigantic to make code more succinct.
>>
> 
> Another suggestion, please collect and group your cleanups for a subsystem 
> and send them in a single cleanup patch series where possible. Again, makes 
> life easier for reviewers and maintainers.
> 

Many thanks for your suggestion again. I will keep it in mind. :)

> Thanks!
> 

Thanks a lot.

> 

[PATCH 2/2] checkpatch: Don't check for mutex_trylock_recursive()

[Sebastian Andrzej Siewior]

mutex_trylock_recursive() has been removed from the tree, there is no
need to check for it.

Remove traces of mutex_trylock_recursive()'s existence.

Signed-off-by: Sebastian Andrzej Siewior 
---
 scripts/checkpatch.pl | 6 --
 1 file changed, 6 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 1afe3af1cc097..4b2775fd31d9d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7062,12 +7062,6 @@ sub process {
}
}
 
-# check for mutex_trylock_recursive usage
-   if ($line =~ /mutex_trylock_recursive/) {
-   ERROR("LOCKING",
- "recursive locking is bad, do not use this 
ever.\n" . $herecurr);
-   }
-
 # check for lockdep_set_novalidate_class
if ($line =~ /^.\s*lockdep_set_novalidate_class\s*\(/ ||
$line =~ /__lockdep_no_validate__\s*\)/ ) {
-- 
2.30.0

[PATCH 1/2] locking/mutex: Kill mutex_trylock_recursive()

[Sebastian Andrzej Siewior]

There are not users of mutex_trylock_recursive() in tree as of
v5.11-rc7.

Remove it.

Signed-off-by: Sebastian Andrzej Siewior 
---
 include/linux/mutex.h  | 25 -
 kernel/locking/mutex.c | 10 --
 2 files changed, 35 deletions(-)

diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index dcd185cbfe793..0cd631a197276 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -199,29 +199,4 @@ extern void mutex_unlock(struct mutex *lock);
 
 extern int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);
 
-/*
- * These values are chosen such that FAIL and SUCCESS match the
- * values of the regular mutex_trylock().
- */
-enum mutex_trylock_recursive_enum {
-   MUTEX_TRYLOCK_FAILED= 0,
-   MUTEX_TRYLOCK_SUCCESS   = 1,
-   MUTEX_TRYLOCK_RECURSIVE,
-};
-
-/**
- * mutex_trylock_recursive - trylock variant that allows recursive locking
- * @lock: mutex to be locked
- *
- * This function should not be used, _ever_. It is purely for hysterical GEM
- * raisins, and once those are gone this will be removed.
- *
- * Returns:
- *  - MUTEX_TRYLOCK_FAILED- trylock failed,
- *  - MUTEX_TRYLOCK_SUCCESS   - lock acquired,
- *  - MUTEX_TRYLOCK_RECURSIVE - we already owned the lock.
- */
-extern /* __deprecated */ __must_check enum mutex_trylock_recursive_enum
-mutex_trylock_recursive(struct mutex *lock);
-
 #endif /* __LINUX_MUTEX_H */
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 5352ce50a97e3..adb9350907688 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -86,16 +86,6 @@ bool mutex_is_locked(struct mutex *lock)
 }
 EXPORT_SYMBOL(mutex_is_locked);
 
-__must_check enum mutex_trylock_recursive_enum
-mutex_trylock_recursive(struct mutex *lock)
-{
-   if (unlikely(__mutex_owner(lock) == current))
-   return MUTEX_TRYLOCK_RECURSIVE;
-
-   return mutex_trylock(lock);
-}
-EXPORT_SYMBOL(mutex_trylock_recursive);
-
 static inline unsigned long __owner_flags(unsigned long owner)
 {
return owner & MUTEX_FLAGS;
-- 
2.30.0

Linux 4.19.175

[Greg Kroah-Hartman]

I'm announcing the release of the 4.19.175 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   |8 
 arch/arm/mach-footbridge/dc21285.c |   12 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |2 -
 arch/x86/Makefile  |3 +
 arch/x86/include/asm/apic.h|   10 -
 arch/x86/include/asm/barrier.h |   18 +
 arch/x86/kernel/apic/apic.c|4 ++
 arch/x86/kernel/apic/x2apic_cluster.c  |6 ++-
 arch/x86/kernel/apic/x2apic_phys.c |6 ++-
 arch/x86/kvm/svm.c |5 ++
 drivers/input/joystick/xpad.c  |   17 
 drivers/input/serio/i8042-x86ia64io.h  |2 +
 drivers/iommu/intel-iommu.c|6 +++
 drivers/md/md.c|2 +
 drivers/mmc/core/sdio_cis.c|6 +++
 drivers/net/dsa/mv88e6xxx/chip.c   |6 ++-
 drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c |   10 ++---
 drivers/nvme/host/pci.c|2 +
 drivers/usb/class/usblp.c  |   19 +
 drivers/usb/dwc2/gadget.c  |8 
 drivers/usb/dwc3/core.c|2 -
 drivers/usb/gadget/legacy/ether.c  |4 +-
 drivers/usb/host/xhci-ring.c   |   31 ++-
 drivers/usb/renesas_usbhs/fifo.c   |1 
 drivers/usb/serial/cp210x.c|2 +
 drivers/usb/serial/option.c|6 +++
 fs/afs/main.c  |6 +--
 fs/cifs/dir.c  |   22 ++-
 fs/cifs/smb2pdu.h  |2 -
 fs/hugetlbfs/inode.c   |3 +
 fs/overlayfs/dir.c |2 -
 include/linux/elfcore.h|   22 +++
 include/linux/hugetlb.h|3 +
 include/linux/msi.h|6 +++
 kernel/Makefile|1 
 kernel/elfcore.c   |   26 -
 kernel/irq/msi.c   |   44 ++
 kernel/kprobes.c   |4 ++
 mm/huge_memory.c   |   37 +++---
 mm/hugetlb.c   |   48 +---
 mm/memblock.c  |   49 +++--
 net/ipv4/ip_tunnel.c   |   16 +++-
 net/lapb/lapb_out.c|3 +
 net/mac80211/driver-ops.c  |5 ++
 net/mac80211/rate.c|3 +
 net/rxrpc/af_rxrpc.c   |6 +--
 46 files changed, 307 insertions(+), 199 deletions(-)

Alexey Dobriyan (1):
  Input: i8042 - unbreak Pegatron C15B

Arnd Bergmann (1):
  elfcore: fix building with clang

Aurelien Aptel (1):
  cifs: report error instead of invalid when revalidating a dentry fails

Benjamin Valentin (1):
  Input: xpad - sync supported devices with fork on GitHub

Chenxin Jin (1):
  USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000

Christoph Schemmel (1):
  USB: serial: option: Adding support for Cinterion MV31

DENG Qingfang (1):
  net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add

Dan Carpenter (1):
  USB: gadget: legacy: fix an error code in eth_bind()

Dave Hansen (1):
  x86/apic: Add extra serialization for non-serializing MSRs

David Howells (1):
  rxrpc: Fix deadlock around release of dst cached on udp tunnel

Felix Fietkau (1):
  mac80211: fix station rate table updates on assoc

Fengnan Chang (1):
  mmc: core: Limit retries when analyse of SDIO tuples fails

Gary Bisson (1):
  usb: dwc3: fix clock issue during resume in OTG mode

Greg Kroah-Hartman (1):
  Linux 4.19.175

Gustavo A. R. Silva (1):
  smb3: Fix out-of-bounds bug in SMB2_negotiate()

Heiko Stuebner (1):
  usb: dwc2: Fix endpoint direction check in ep_from_windex

Hugh Dickins (1):
  mm: thp: fix MADV_REMOVE deadlock on shmem THP

Jeremy Figgins (1):
  USB: usblp: don't call usb_set_interface if there's a single alt

Josh Poimboeuf (1):
  x86/build: Disable CET instrumentation in the kernel

Liangyan (1):
  ovl: fix dentry leak in ovl_get_redirect

Marc Zyngier (1):
  genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set

Mathias Nyma

Re: Linux 4.19.175

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index 8f326d0652a7..db37b39fae69 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 19
-SUBLEVEL = 174
+SUBLEVEL = 175
 EXTRAVERSION =
 NAME = "People's Front"
 
@@ -859,12 +859,6 @@ KBUILD_CFLAGS   += $(call 
cc-option,-Werror=designated-init)
 # change __FILE__ to the relative path from the srctree
 KBUILD_CFLAGS  += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
 
-# ensure -fcf-protection is disabled when using retpoline as it is
-# incompatible with -mindirect-branch=thunk-extern
-ifdef CONFIG_RETPOLINE
-KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
-endif
-
 # use the deterministic mode of AR if available
 KBUILD_ARFLAGS := $(call ar-option,D)
 
diff --git a/arch/arm/mach-footbridge/dc21285.c 
b/arch/arm/mach-footbridge/dc21285.c
index 16d71bac0061..2d1f822700a1 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -69,15 +69,15 @@ dc21285_read_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("ldrb   %0, [%1, %2]"
+   asm volatile("ldrb  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 2:
-   asm("ldrh   %0, [%1, %2]"
+   asm volatile("ldrh  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 4:
-   asm("ldr%0, [%1, %2]"
+   asm volatile("ldr   %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
}
@@ -103,17 +103,17 @@ dc21285_write_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("strb   %0, [%1, %2]"
+   asm volatile("strb  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 2:
-   asm("strh   %0, [%1, %2]"
+   asm volatile("strh  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 4:
-   asm("str%0, [%1, %2]"
+   asm volatile("str   %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index de6af453a6e1..f4eb4d3b6cab 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -303,7 +303,7 @@
 
dcfg: dcfg@1ee {
compatible = "fsl,ls1046a-dcfg", "syscon";
-   reg = <0x0 0x1ee 0x0 0x1>;
+   reg = <0x0 0x1ee 0x0 0x1000>;
big-endian;
};
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 4833dd7e2cc0..0303a243b634 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -132,6 +132,9 @@ else
 KBUILD_CFLAGS += -mno-red-zone
 KBUILD_CFLAGS += -mcmodel=kernel
 
+   # Intel CET isn't enabled in the kernel
+   KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
+
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
 KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index cd2aa72e2123..b5354e216b07 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -190,16 +190,6 @@ static inline void lapic_assign_legacy_vector(unsigned int 
i, bool r) { }
 #endif /* !CONFIG_X86_LOCAL_APIC */
 
 #ifdef CONFIG_X86_X2APIC
-/*
- * Make previous memory operations globally visible before
- * sending the IPI through x2apic wrmsr. We need a serializing instruction or
- * mfence for this.
- */
-static inline void x2apic_wrmsr_fence(void)
-{
-   asm volatile("mfence" : : : "memory");
-}
-
 static inline void native_apic_msr_write(u32 reg, u32 v)
 {
if (reg == APIC_DFR || reg == APIC_ID || reg == APIC_LDR ||
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index 84f848c2541a..dd22cffc6b3f 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -85,4 +85,22 @@ do { 

Linux 5.4.97

[Greg Kroah-Hartman]

I'm announcing the release of the 5.4.97 kernel.

All users of the 5.4 kernel series must upgrade.

The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.4.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 |8 -
 arch/arm/boot/dts/sun7i-a20-bananapro.dts|2 
 arch/arm/mach-footbridge/dc21285.c   |   12 -
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi|2 
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi   |2 
 arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts |   10 -
 arch/arm64/boot/dts/rockchip/px30.dtsi   |2 
 arch/um/drivers/virtio_uml.c |3 
 arch/x86/Makefile|3 
 arch/x86/include/asm/apic.h  |   10 -
 arch/x86/include/asm/barrier.h   |   18 ++
 arch/x86/kernel/apic/apic.c  |4 
 arch/x86/kernel/apic/x2apic_cluster.c|6 
 arch/x86/kernel/apic/x2apic_phys.c   |9 -
 arch/x86/kvm/emulate.c   |2 
 arch/x86/kvm/svm.c   |5 
 arch/x86/mm/mem_encrypt.c|1 
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|2 
 drivers/input/joystick/xpad.c|   17 ++
 drivers/input/serio/i8042-x86ia64io.h|2 
 drivers/iommu/intel-iommu.c  |6 
 drivers/md/md.c  |2 
 drivers/mmc/core/sdio_cis.c  |6 
 drivers/net/dsa/mv88e6xxx/chip.c |6 
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c   |   13 -
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h   |1 
 drivers/net/ethernet/intel/igc/igc_ethtool.c |3 
 drivers/net/ethernet/intel/igc/igc_i225.c|3 
 drivers/net/ethernet/intel/igc/igc_mac.c |2 
 drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c   |   10 -
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c|5 
 drivers/net/ethernet/realtek/r8169_main.c|4 
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c  |9 +
 drivers/nvdimm/dimm_devs.c   |   18 ++
 drivers/nvme/host/pci.c  |2 
 drivers/nvme/target/tcp.c|3 
 drivers/usb/class/usblp.c|   19 +-
 drivers/usb/dwc2/gadget.c|8 -
 drivers/usb/dwc3/core.c  |2 
 drivers/usb/gadget/legacy/ether.c|4 
 drivers/usb/host/xhci-mtk-sch.c  |  130 +--
 drivers/usb/host/xhci-mtk.c  |2 
 drivers/usb/host/xhci-mtk.h  |   15 ++
 drivers/usb/host/xhci-mvebu.c|   42 ++
 drivers/usb/host/xhci-mvebu.h|6 
 drivers/usb/host/xhci-plat.c |   26 +++
 drivers/usb/host/xhci-plat.h |1 
 drivers/usb/host/xhci-ring.c |   31 ++--
 drivers/usb/host/xhci.c  |8 -
 drivers/usb/host/xhci.h  |5 
 drivers/usb/renesas_usbhs/fifo.c |1 
 drivers/usb/serial/cp210x.c  |2 
 drivers/usb/serial/option.c  |6 
 fs/afs/main.c|6 
 fs/cifs/dir.c|   22 ++-
 fs/cifs/smb2pdu.h|2 
 fs/cifs/transport.c  |   18 ++
 fs/hugetlbfs/inode.c |3 
 fs/overlayfs/dir.c   |2 
 include/linux/hugetlb.h  |2 
 include/linux/msi.h  |6 
 include/net/sch_generic.h|2 
 init/init_task.c |3 
 kernel/bpf/cgroup.c  |7 -
 kernel/irq/msi.c |   44 ++
 kernel/kprobes.c |4 
 kernel/trace/fgraph.c|2 
 mm/compaction.c  |3 
 mm/huge_memory.c |   37 +++--
 mm/hugetlb.c |   48 ++-
 mm/memblock.c|   49 ---
 net/core/neighbour.c |7 -
 net/ipv4/ip_tunnel.c  

Re: Linux 5.4.97

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index 7a47a2594f95..032751f6be0c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 5
 PATCHLEVEL = 4
-SUBLEVEL = 96
+SUBLEVEL = 97
 EXTRAVERSION =
 NAME = Kleptomaniac Octopus
 
@@ -920,12 +920,6 @@ KBUILD_CFLAGS   += $(call 
cc-option,-Werror=designated-init)
 # change __FILE__ to the relative path from the srctree
 KBUILD_CFLAGS  += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
 
-# ensure -fcf-protection is disabled when using retpoline as it is
-# incompatible with -mindirect-branch=thunk-extern
-ifdef CONFIG_RETPOLINE
-KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
-endif
-
 include scripts/Makefile.kasan
 include scripts/Makefile.extrawarn
 include scripts/Makefile.ubsan
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 01ccff756996..5740f9442705 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -110,7 +110,7 @@
pinctrl-names = "default";
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-supply = <®_gmac_3v3>;
status = "okay";
 };
diff --git a/arch/arm/mach-footbridge/dc21285.c 
b/arch/arm/mach-footbridge/dc21285.c
index 8b81a17f675d..e17ec92b90dd 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -66,15 +66,15 @@ dc21285_read_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("ldrb   %0, [%1, %2]"
+   asm volatile("ldrb  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 2:
-   asm("ldrh   %0, [%1, %2]"
+   asm volatile("ldrh  %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 4:
-   asm("ldr%0, [%1, %2]"
+   asm volatile("ldr   %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
}
@@ -100,17 +100,17 @@ dc21285_write_config(struct pci_bus *bus, unsigned int 
devfn, int where,
if (addr)
switch (size) {
case 1:
-   asm("strb   %0, [%1, %2]"
+   asm volatile("strb  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 2:
-   asm("strh   %0, [%1, %2]"
+   asm volatile("strh  %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 4:
-   asm("str%0, [%1, %2]"
+   asm volatile("str   %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 354ef2f3eac6..9533c85fb0a3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -2382,7 +2382,7 @@
interrupts = ;
dr_mode = "host";
snps,dis_u2_susphy_quirk;
-   snps,quirk-frame-length-adjustment;
+   snps,quirk-frame-length-adjustment = <0x20>;
snps,parkmode-disable-ss-quirk;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index d4c1da3d4bde..04d4b1b11a00 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -304,7 +304,7 @@
 
dcfg: dcfg@1ee {
compatible = "fsl,ls1046a-dcfg", "syscon";
-   reg = <0x0 0x1ee 0x0 0x1>;
+   reg = <0x0 0x1ee 0x0 0x1000>;
big-endian;
};
 
diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts 
b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index f539b3655f6b..e638f216dbfb 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -243,6 +243,8 @@
 &i2c3 {
status = "okay";
clock-frequency = 

Linux 5.10.15

[Greg Kroah-Hartman]

I'm announcing the release of the 5.10.15 kernel.

All users of the 5.10 kernel series must upgrade.

The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.10.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/filesystems/overlayfs.rst  |8 +
 Makefile |   12 -
 arch/arm/boot/dts/omap3-gta04.dtsi   |3 
 arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi   |   12 +
 arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi |3 
 arch/arm/boot/dts/sun7i-a20-bananapro.dts|2 
 arch/arm/include/debug/tegra.S   |   54 +++
 arch/arm/mach-footbridge/dc21285.c   |   12 -
 arch/arm/mach-omap1/board-osk.c  |2 
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi|2 
 arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts  |2 
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi   |2 
 arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts |   10 -
 arch/arm64/boot/dts/rockchip/px30.dtsi   |2 
 arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts |1 
 arch/riscv/Kconfig   |2 
 arch/um/drivers/virtio_uml.c |3 
 arch/x86/Makefile|3 
 arch/x86/include/asm/apic.h  |   10 -
 arch/x86/include/asm/barrier.h   |   18 ++
 arch/x86/kernel/apic/apic.c  |4 
 arch/x86/kernel/apic/x2apic_cluster.c|6 
 arch/x86/kernel/apic/x2apic_phys.c   |9 -
 arch/x86/kernel/hw_breakpoint.c  |   61 +---
 arch/x86/kvm/cpuid.c |2 
 arch/x86/kvm/emulate.c   |2 
 arch/x86/kvm/mmu/tdp_mmu.c   |6 
 arch/x86/kvm/svm/sev.c   |   17 +-
 arch/x86/kvm/svm/svm.c   |5 
 arch/x86/kvm/vmx/vmx.c   |   17 +-
 arch/x86/kvm/x86.c   |   27 ++-
 arch/x86/mm/mem_encrypt.c|1 
 drivers/gpio/gpiolib.c   |   10 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|2 
 drivers/gpu/drm/drm_dp_mst_topology.c|   24 ++-
 drivers/gpu/drm/i915/display/intel_ddi.c |   37 +++--
 drivers/gpu/drm/i915/display/intel_display.c |9 -
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |4 
 drivers/gpu/drm/i915/display/intel_overlay.c |4 
 drivers/gpu/drm/i915/display/intel_sprite.c  |   65 +
 drivers/gpu/drm/i915/gem/i915_gem_domain.c   |   45 --
 drivers/gpu/drm/i915/gem/i915_gem_object.h   |1 
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c  |6 
 drivers/input/joystick/xpad.c|   17 ++
 drivers/input/serio/i8042-x86ia64io.h|2 
 drivers/input/touchscreen/goodix.c   |2 
 drivers/input/touchscreen/ili210x.c  |   26 ++-
 drivers/md/md.c  |2 
 drivers/mmc/core/sdio_cis.c  |6 
 drivers/mmc/host/sdhci-pltfm.h   |7 -
 drivers/net/dsa/mv88e6xxx/chip.c |6 
 drivers/net/ethernet/ibm/ibmvnic.c   |5 
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c   |   13 -
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h   |1 
 drivers/net/ethernet/intel/igc/igc_ethtool.c |3 
 drivers/net/ethernet/intel/igc/igc_i225.c|3 
 drivers/net/ethernet/intel/igc/igc_mac.c |2 
 drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c   |   10 -
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c|6 
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c  |   16 +-
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c|5 
 drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c  |2 
 drivers/net/ethernet/realtek/r8169_main.c|   75 +-
 drivers/net/ipa/gsi.c|2 
 drivers/nvdimm/dimm_devs.c   |   18 ++
 drivers/nvdimm/namespace_devs.c  |   10 -
 drivers/nvme/host/pci.c  |2 
 drivers/nvme/target/tcp.c|3 
 drivers/thunderbolt/acpi.c   |2 
 drivers/usb/class/usblp.c|   19 +-
 drivers/usb/dwc2/gadget.c|8 -
 drivers/usb/dwc3/core.c  |2 
 drivers/usb/gadget/legacy/ether.

[PATCH v14 0/4] Adding the Sparx5 Serdes driver

[Steen Hegelund]

Adding the Sparx5 Serdes driver

This series of patches provides the serdes driver for the Microchip Sparx5
ethernet switch.

The serdes driver supports the 10G and 25G serdes instances available in the
Sparx5.

The Sparx5 serdes support several interface modes with several speeds and also
allows the client to change the mode and the speed according to changing in the
environment such as changing cables from DAC to fiber.

The serdes driver is to be used by the Sparx5 switchdev driver that
will follow in subsequent series.

Sparx5 Architecture:


Below is a diagram of the Ethernet transport part of the Sparx5 chip.

The diagram shows the switch core that sends/receives traffic via the Frame Bus
and passes to the Port Modules.
The Port Modules are able to talk to a SerDes via a Port Muxing configuration.
The SerDes instances (33 in all) then passes the traffic on its lanes to the
attached cuPHY or SFP module.

 +-+
 | |
 | Switch Core |
 | |
 +++
  |
 ---+--+--+---+--+-+   Frame Bus
|  |  |  |
 +--+-+ +--+-+ +--+-+ +--+-+
 |1G/2.G Port | |5G Port | |10G Port| |25GG Port   |
 |Modules | |Modules | |Modules | |Modules |
 |MAC, PCS| |MAC, PCS| |MAC, PCS| |MAC, PCS|
 +--+-+ +--+-+ +--+-+ +--+-+
|  |  |  |
 ---+-++---+--+--+---+-+  Port Muxing
  || |
+-++ +-++ +--+---+
|SerDes 5G | |SerDes 10G| |SerDes 25G|SerDes Driver
|Lane (13) | |Lane (12) | |Lane (8)  |Controls these
+-++ +-++ +-++
  |||
   to cuPHY to cuPHY to cuPHY
   or SFP   or SFP   or SFP

The 33 SerDes instances are handled internally by 2 SerDes macros types:

- A 10G SerDes macro that supports the following rates and modes:
  - 100 Mbps:
   - 100BASE-FX
  - 1.25 Gbps:
   - SGMII
   - 1000BASE-X
   - 1000BASE-KX
  - 3.125 Gbps:
   - 2.5GBASE-X
   - 2.5GBASE-KX
  - 5 Gbps:
   - QSGMII
   - USGMII
  - 5.15625 Gbps:
   - 5GBASE-KR
   - 5G-USXGMII
  - 10 Gbps:
   - 10G-USGMII
  - 10.3125 Gbps:
   - 10GBASE-R
   - 10GBASE-KR
   - USXGMII

- A 25G SerDes macro that supports the following rates and modes:
  - 1.25 Gbps:
   - SGMII
   - 1000BASE-X
   - 1000BASE-KX
  - 3.125 Gbps:
   - 2.5GBASE-X
   - 2.5GBASE-KX
  - 5 Gbps:
   - QSGMII
   - USGMII
  - 5.15625 Gbps:
   - 5GBASE-KR
   - 5G-USXGMII
  - 10 Gbps:
   - 10G-USGMII
  - 10.3125 Gbps:
   - 10GBASE-R
   - 10GBASE-KR
   - USXGMII
  - 10.3125 Gbps:
   - 10GBASE-R
   - 10GBASE-KR
   - USXGMII
  - 25.78125 Gbps:
   - 25GBASE-KR
   - 25GBASE-CR
   - 25GBASE-SR
   - 25GBASE-LR
   - 25GBASE-ER

The SerDes driver handles these SerDes instances and configures them based on
the selected mode, speed and media type.

In the current version of the SerDes driver only a subset of the above modes
are supported: the modes that can be tested on our current evaluation boards
(PCB134 and PCB35).

The first 13 10G SerDes macros are limited to 6G, and this gives the SerDes
instance architecture shown on the diagram above.

The Port Muxing allows a Port Module to use a specific SerDes instance, but not
all combinations are allowed.
This is functionality as well as the configuration of the Port Modules is
handled by the SwitchDev Driver.



History:

v13 -> v14:
Changed the 25g apply, 10g apply and the CMU configuration functions to
use a table based register update structure.
The table entries still need serdes indices/instances so the table must
be generated per serdes.

v12 -> v13:
Interface changes:
- Added set_media and set_speed interfaces on the generic phy
- Removed the ethernet SerDes configuration structure and its
  header file.
Implementation changes:
- Implemented the new media and speed interfaces in the Serdes driver
- Removed the configure interface function in the SerDes driver
- The existing configuration function is now only used internally

v11 -> v12:
Used bitfields for bools in configuration structures.
Removed vertical alignment in structures.
Removed CONFIG_DEBUG_KERNEL guard around warning checks

v10 -> v11:
Rebased on v

[PATCH 0/2] locking/mutex: Kill mutex_trylock_recursive()

[Sebastian Andrzej Siewior]

Remove mutex_trylock_recursive() from the API and tell checkpatch not to
check it for it anymore.

Sebastian

include/linux/compiler_types.h:338:38: error: call to '__compiletime_assert_603' declared with attribute error: must adapt SMC_WR_TX_SIZE to sizeof(struct smc_llc_msg); if not all smc_wr upper layer p

[kernel test robot]

Hi Will,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   e0756cfc7d7cd08c98a53b6009c091a3f6a50be6
commit: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move 
compiletime_assert() macros into compiler_types.h
date:   7 months ago
config: arm-randconfig-s032-20210209 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-215-g0fb77bb6-dirty
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from :
   net/smc/smc_llc.c: In function 'smc_llc_add_pending_send':
   include/linux/compiler_types.h:338:38: error: call to 
'__compiletime_assert_602' declared with attribute error: must increase 
SMC_WR_BUF_SIZE to at least sizeof(struct smc_llc_msg)
 338 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^
   include/linux/compiler_types.h:319:4: note: in definition of macro 
'__compiletime_assert'
 319 |prefix ## suffix();\
 |^~
   include/linux/compiler_types.h:338:2: note: in expansion of macro 
'_compiletime_assert'
 338 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
  39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 | ^~
   net/smc/smc_llc.c:348:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 348 |  BUILD_BUG_ON_MSG(
 |  ^~~~
>> include/linux/compiler_types.h:338:38: error: call to 
>> '__compiletime_assert_603' declared with attribute error: must adapt 
>> SMC_WR_TX_SIZE to sizeof(struct smc_llc_msg); if not all smc_wr upper layer 
>> protocols use the same message size any more, must start to set 
>> link->wr_tx_sges[i].length on each individual smc_wr_tx_send()
 338 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^
   include/linux/compiler_types.h:319:4: note: in definition of macro 
'__compiletime_assert'
 319 |prefix ## suffix();\
 |^~
   include/linux/compiler_types.h:338:2: note: in expansion of macro 
'_compiletime_assert'
 338 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
  39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 | ^~
   net/smc/smc_llc.c:351:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 351 |  BUILD_BUG_ON_MSG(
 |  ^~~~
--
   In file included from :
   In function 'smc_cdc_add_pending_send',
   inlined from 'smc_cdc_msg_send' at net/smc/smc_cdc.c:101:2:
>> include/linux/compiler_types.h:338:38: error: call to 
>> '__compiletime_assert_580' declared with attribute error: must increase 
>> SMC_WR_BUF_SIZE to at least sizeof(struct smc_cdc_msg)
 338 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^
   include/linux/compiler_types.h:319:4: note: in definition of macro 
'__compiletime_assert'
 319 |prefix ## suffix();\
 |^~
   include/linux/compiler_types.h:338:2: note: in expansion of macro 
'_compiletime_assert'
 338 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
  39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 | ^~
   net/smc/smc_cdc.c:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  78 |  BUILD_BUG_ON_MSG(
 |  ^~~~
>> include/linux/compiler_types.h:338:38: error: call to 
>> '__compiletime_assert_581' declared with attribute error: must adapt 
>> SMC_WR_TX_

Re: [PATCH] clk: at91: Fix the declaration of the clocks

[Greg Kroah-Hartman]

On Wed, Feb 10, 2021 at 09:51:14AM +0100, Geert Uytterhoeven wrote:
> Hi Saravana,
> 
> On Wed, Feb 10, 2021 at 1:57 AM Saravana Kannan  wrote:
> > On Tue, Feb 9, 2021 at 4:54 PM Stephen Boyd  wrote:
> > > Quoting tudor.amba...@microchip.com (2021-02-08 01:49:45)
> > > > Do you plan to take this patch for v5.12?
> > > > If fw_devlink will remain set to ON for v5.12, some of our boards will
> > > > no longer boot without this patch.
> > >
> > > Is fw_devlink defaulted to on for v5.12?
> >
> > Yes.
> 
> Have all issues been identified and understood?
> Have all issues been fixed, reviewed, and committed?
> Have all fixes entered linux-next?
> Have all fixes been migrated from submaintainers to maintainers?
> 
> We're already at v5.11-rc7.
> Yes, we can get fixes into v5.12-rc7. Or v5.12-rc9...

Yeah, I'm leaning toward not making it the default for 5.12-rc1 because
not everything seems to be working, let's see how the rest of the week
goes...

thanks,

greg k-h

[PATCH v14 1/4] dt-bindings: phy: Add sparx5-serdes bindings

[Steen Hegelund]

Document the Sparx5 ethernet serdes phy driver bindings.

Signed-off-by: Lars Povlsen 
Signed-off-by: Steen Hegelund 
Reviewed-by: Rob Herring 
Reviewed-by: Andrew Lunn 
Reviewed-by: Alexandre Belloni 
---
 .../bindings/phy/microchip,sparx5-serdes.yaml | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml

diff --git a/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml 
b/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
new file mode 100644
index ..bdbdb3bbddbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/microchip,sparx5-serdes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Sparx5 Serdes controller
+
+maintainers:
+  - Steen Hegelund 
+
+description: |
+  The Sparx5 SERDES interfaces share the same basic functionality, but
+  support different operating modes and line rates.
+
+  The following list lists the SERDES features:
+
+  * RX Adaptive Decision Feedback Equalizer (DFE)
+  * Programmable continuous time linear equalizer (CTLE)
+  * Rx variable gain control
+  * Rx built-in fault detector (loss-of-lock/loss-of-signal)
+  * Adjustable tx de-emphasis (FFE)
+  * Tx output amplitude control
+  * Supports rx eye monitor
+  * Multiple loopback modes
+  * Prbs generator and checker
+  * Polarity inversion control
+
+  SERDES6G:
+
+  The SERDES6G is a high-speed SERDES interface, which can operate at
+  the following data rates:
+
+  * 100 Mbps (100BASE-FX)
+  * 1.25 Gbps (SGMII/1000BASE-X/1000BASE-KX)
+  * 3.125 Gbps (2.5GBASE-X/2.5GBASE-KX)
+  * 5.15625 Gbps (5GBASE-KR/5G-USXGMII)
+
+  SERDES10G
+
+  The SERDES10G is a high-speed SERDES interface, which can operate at
+  the following data rates:
+
+  * 100 Mbps (100BASE-FX)
+  * 1.25 Gbps (SGMII/1000BASE-X/1000BASE-KX)
+  * 3.125 Gbps (2.5GBASE-X/2.5GBASE-KX)
+  * 5 Gbps (QSGMII/USGMII)
+  * 5.15625 Gbps (5GBASE-KR/5G-USXGMII)
+  * 10 Gbps (10G-USGMII)
+  * 10.3125 Gbps (10GBASE-R/10GBASE-KR/USXGMII)
+
+  SERDES25G
+
+  The SERDES25G is a high-speed SERDES interface, which can operate at
+  the following data rates:
+
+  * 1.25 Gbps (SGMII/1000BASE-X/1000BASE-KX)
+  * 3.125 Gbps (2.5GBASE-X/2.5GBASE-KX)
+  * 5 Gbps (QSGMII/USGMII)
+  * 5.15625 Gbps (5GBASE-KR/5G-USXGMII)
+  * 10 Gbps (10G-USGMII)
+  * 10.3125 Gbps (10GBASE-R/10GBASE-KR/USXGMII)
+  * 25.78125 Gbps (25GBASE-KR/25GBASE-CR/25GBASE-SR/25GBASE-LR/25GBASE-ER)
+
+properties:
+  $nodename:
+pattern: "^serdes@[0-9a-f]+$"
+
+  compatible:
+const: microchip,sparx5-serdes
+
+  reg:
+minItems: 1
+
+  '#phy-cells':
+const: 1
+description: |
+  - The main serdes input port
+
+  clocks:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - '#phy-cells'
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+serdes: serdes@10808000 {
+  compatible = "microchip,sparx5-serdes";
+  #phy-cells = <1>;
+  clocks = <&sys_clk>;
+  reg = <0x10808000 0x5d>;
+};
+
+...
-- 
2.30.0

[PATCH v14 2/4] phy: Add media type and speed serdes configuration interfaces

[Steen Hegelund]

Provide new phy configuration interfaces for media type and speed that
allows allows e.g. PHYs used for ethernet to be configured with this
information.

Signed-off-by: Lars Povlsen 
Signed-off-by: Steen Hegelund 
Reviewed-by: Andrew Lunn 
Reviewed-by: Alexandre Belloni 
---
 drivers/phy/phy-core.c  | 30 ++
 include/linux/phy/phy.h | 26 ++
 2 files changed, 56 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 71cb10826326..ccb575b13777 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -373,6 +373,36 @@ int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, 
int submode)
 }
 EXPORT_SYMBOL_GPL(phy_set_mode_ext);
 
+int phy_set_media(struct phy *phy, enum phy_media media)
+{
+   int ret;
+
+   if (!phy || !phy->ops->set_media)
+   return 0;
+
+   mutex_lock(&phy->mutex);
+   ret = phy->ops->set_media(phy, media);
+   mutex_unlock(&phy->mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_media);
+
+int phy_set_speed(struct phy *phy, int speed)
+{
+   int ret;
+
+   if (!phy || !phy->ops->set_speed)
+   return 0;
+
+   mutex_lock(&phy->mutex);
+   ret = phy->ops->set_speed(phy, speed);
+   mutex_unlock(&phy->mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_speed);
+
 int phy_reset(struct phy *phy)
 {
int ret;
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e435bdb0bab3..e4fd69a1faa7 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -44,6 +44,12 @@ enum phy_mode {
PHY_MODE_DP
 };
 
+enum phy_media {
+   PHY_MEDIA_DEFAULT,
+   PHY_MEDIA_SR,
+   PHY_MEDIA_DAC,
+};
+
 /**
  * union phy_configure_opts - Opaque generic phy configuration
  *
@@ -64,6 +70,8 @@ union phy_configure_opts {
  * @power_on: powering on the phy
  * @power_off: powering off the phy
  * @set_mode: set the mode of the phy
+ * @set_media: set the media type of the phy (optional)
+ * @set_speed: set the speed of the phy (optional)
  * @reset: resetting the phy
  * @calibrate: calibrate the phy
  * @release: ops to be performed while the consumer relinquishes the PHY
@@ -75,6 +83,8 @@ struct phy_ops {
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
int (*set_mode)(struct phy *phy, enum phy_mode mode, int submode);
+   int (*set_media)(struct phy *phy, enum phy_media media);
+   int (*set_speed)(struct phy *phy, int speed);
 
/**
 * @configure:
@@ -215,6 +225,8 @@ int phy_power_off(struct phy *phy);
 int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode);
 #define phy_set_mode(phy, mode) \
phy_set_mode_ext(phy, mode, 0)
+int phy_set_media(struct phy *phy, enum phy_media media);
+int phy_set_speed(struct phy *phy, int speed);
 int phy_configure(struct phy *phy, union phy_configure_opts *opts);
 int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
 union phy_configure_opts *opts);
@@ -344,6 +356,20 @@ static inline int phy_set_mode_ext(struct phy *phy, enum 
phy_mode mode,
 #define phy_set_mode(phy, mode) \
phy_set_mode_ext(phy, mode, 0)
 
+static inline int phy_set_media(struct phy *phy, enum phy_media media)
+{
+   if (!phy)
+   return 0;
+   return -ENOSYS;
+}
+
+static inline int phy_set_speed(struct phy *phy, int speed)
+{
+   if (!phy)
+   return 0;
+   return -ENOSYS;
+}
+
 static inline enum phy_mode phy_get_mode(struct phy *phy)
 {
return PHY_MODE_INVALID;
-- 
2.30.0

Re: [PATCH -next] mfd: arizona: Make some symbols static

[Hans de Goede]

Hi,

On 2/10/21 8:56 AM, Wei Yongjun wrote:
> The sparse tool complains as follows:
> 
> drivers/mfd/arizona-spi.c:28:31: warning:
>  symbol 'reset_gpios' was not declared. Should it be static?
> drivers/mfd/arizona-spi.c:29:31: warning:
>  symbol 'ldoena_gpios' was not declared. Should it be static?
> 
> Those symbols are not used outside of arizona-spi.c, so this
> commit marks them static.
> 
> Fixes: e933836744a2 ("mfd: arizona: Add support for ACPI enumeration of 
> WM5102 connected over SPI")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 

Thank you for catching this.

Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans

> ---
>  drivers/mfd/arizona-spi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> index 24a2c75d691a..aa1d6f94ae53 100644
> --- a/drivers/mfd/arizona-spi.c
> +++ b/drivers/mfd/arizona-spi.c
> @@ -25,8 +25,8 @@
>  #include "arizona.h"
>  
>  #ifdef CONFIG_ACPI
> -const struct acpi_gpio_params reset_gpios = { 1, 0, false };
> -const struct acpi_gpio_params ldoena_gpios = { 2, 0, false };
> +static const struct acpi_gpio_params reset_gpios = { 1, 0, false };
> +static const struct acpi_gpio_params ldoena_gpios = { 2, 0, false };
>  
>  static const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
>   { "reset-gpios", &reset_gpios, 1, },
> 

[PATCH v14 4/4] arm64: dts: sparx5: Add Sparx5 serdes driver node

[Steen Hegelund]

Add Sparx5 serdes driver node, and enable it generally for all
reference boards.

Signed-off-by: Lars Povlsen 
Signed-off-by: Steen Hegelund 
Reviewed-by: Andrew Lunn 
Reviewed-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi 
b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index 380281f312d8..29c606194bc7 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -383,5 +383,13 @@ tmon0: tmon@610508110 {
#thermal-sensor-cells = <0>;
clocks = <&ahb_clk>;
};
+
+   serdes: serdes@10808000 {
+   compatible = "microchip,sparx5-serdes";
+   #phy-cells = <1>;
+   clocks = <&sys_clk>;
+   reg = <0x6 0x10808000 0x5d>;
+   };
+
};
 };
-- 
2.30.0

Re: [PATCH v4 0/8] Make fw_devlink=on more forgiving

[Saravana Kannan]

On Wed, Feb 10, 2021 at 12:19 AM  wrote:
>
> Hi, Saravana,
>
> On 2/6/21 12:26 AM, Saravana Kannan wrote:
> > There are a lot of devices/drivers where they never have a struct device
> > created for them or the driver initializes the hardware without ever
> > binding to the struct device.
> >
> > This series is intended to avoid any boot regressions due to such
> > devices/drivers when fw_devlink=on and also address the handling of
> > optional suppliers.
> >
> > Patch 1 and 2 addresses the issue of firmware nodes that look like
> > they'll have struct devices created for them, but will never actually
> > have struct devices added for them. For example, DT nodes with a
> > compatible property that don't have devices added for them.
> >
> > Patch 3 and 4 allow for handling optional DT bindings.
> >
> > Patch 5 sets up a generic API to handle drivers that never bind with
> > their devices.
> >
> > Patch 6 through 8 update different frameworks to use the new API.
> >
> > Thanks,
> > Saravana
> >
> > Saravana Kannan (8):
> >   driver core: fw_devlink: Detect supplier devices that will never be
> > added
> >   of: property: Don't add links to absent suppliers
> >   driver core: Add fw_devlink.strict kernel param
> >   of: property: Add fw_devlink support for optional properties
> >   driver core: fw_devlink: Handle suppliers that don't use driver core
> >   irqdomain: Mark fwnodes when their irqdomain is added/removed
> >   PM: domains: Mark fwnodes when their powerdomain is added/removed
> >   clk: Mark fwnodes when their clock provider is added/removed
> >
> >  .../admin-guide/kernel-parameters.txt |  5 ++
> >  drivers/base/core.c   | 58 ++-
> >  drivers/base/power/domain.c   |  2 +
> >  drivers/clk/clk.c |  3 +
> >  drivers/of/property.c | 16 +++--
> >  include/linux/fwnode.h| 20 ++-
> >  kernel/irq/irqdomain.c|  2 +
> >  7 files changed, 98 insertions(+), 8 deletions(-)
> >
>
> Even with this patch set applied, sama5d2_xplained can not boot.
> Patch at [1] makes sama5d2_xplained boot again. Stephen applied it
> to clk-next.

I'm glad you won't actually have any boot issues in 5.12, but the fact
you need [1] with this series doesn't make a lot of sense to me
because:

1. The FWNODE_FLAG_INITIALIZED flag will be set for the clock fwnode
in question way before any consumer devices are added.
2. Any consumer device added after (1) will stop trying to link to the
clock device.

Are you somehow adding a consumer to the clock fwnode before (1)?

Can you try this patch without your clk fix? I was trying to avoid
looping through a list, but looks like your case might somehow need
it?

-Saravana

+++ b/drivers/base/core.c
@@ -943,6 +943,31 @@ static void device_links_missing_supplier(struct
device *dev)
}
 }

+static int fw_devlink_check_suppliers(struct device *dev)
+{
+   struct fwnode_link *link;
+   int ret = 0;
+
+   if (!dev->fwnode ||fw_devlink_is_permissive())
+   return 0;
+
+   /*
+* Device waiting for supplier to become available is not allowed to
+* probe.
+*/
+   mutex_lock(&fwnode_link_lock);
+   list_for_each_entry(link, &dev->fwnode->suppliers, c_hook) {
+   if (link->supplier->flags & FWNODE_FLAG_INITIALIZED)
+   continue;
+
+   ret = -EPROBE_DEFER;
+   break;
+   }
+   mutex_unlock(&fwnode_link_lock);
+
+   return ret;
+}
+
 /**
  * device_links_check_suppliers - Check presence of supplier drivers.
  * @dev: Consumer device.
@@ -964,21 +989,13 @@ int device_links_check_suppliers(struct device *dev)
struct device_link *link;
int ret = 0;

-   /*
-* Device waiting for supplier to become available is not allowed to
-* probe.
-*/
-   mutex_lock(&fwnode_link_lock);
-   if (dev->fwnode && !list_empty(&dev->fwnode->suppliers) &&
-   !fw_devlink_is_permissive()) {
+   if (fw_devlink_check_suppliers(dev)) {
dev_dbg(dev, "probe deferral - wait for supplier %pfwP\n",
list_first_entry(&dev->fwnode->suppliers,
struct fwnode_link,
c_hook)->supplier);
-   mutex_unlock(&fwnode_link_lock);
return -EPROBE_DEFER;
}
-   mutex_unlock(&fwnode_link_lock);

device_links_write_lock();



>
> Cheers,
> ta
>
> [1] 
> https://lore.kernel.org/lkml/20210203154332.470587-1-tudor.amba...@microchip.com/

Re: [RFC][PATCH 06/13] mm/migrate: update migration order during on hotplug events

[Oscar Salvador]

On Tue, Feb 09, 2021 at 03:45:55PM -0800, Dave Hansen wrote:
> On 2/2/21 3:42 AM, Oscar Salvador wrote:
> >> +static int __meminit migrate_on_reclaim_callback(struct notifier_block 
> >> *self,
> >> +   unsigned long action, void 
> >> *arg)
> >> +{
> >> +  switch (action) {
> >> +  case MEM_GOING_OFFLINE:
> >> +  /*
> >> +   * Make sure there are not transient states where
> >> +   * an offline node is a migration target.  This
> >> +   * will leave migration disabled until the offline
> >> +   * completes and the MEM_OFFLINE case below runs.
> >> +   */
> >> +  disable_all_migrate_targets();
> >> +  break;
> >> +  case MEM_OFFLINE:
> >> +  case MEM_ONLINE:
> >> +  /*
> >> +   * Recalculate the target nodes once the node
> >> +   * reaches its final state (online or offline).
> >> +   */
> >> +  __set_migration_target_nodes();
> >> +  break;
> >> +  case MEM_CANCEL_OFFLINE:
> >> +  /*
> >> +   * MEM_GOING_OFFLINE disabled all the migration
> >> +   * targets.  Reenable them.
> >> +   */
> >> +  __set_migration_target_nodes();
> >> +  break;
> >> +  case MEM_GOING_ONLINE:
> >> +  case MEM_CANCEL_ONLINE:
> >> +  break;
> >> +  }
> >> +
> >> +  return notifier_from_errno(0);
> >> +}
> > This looks good, and I kinda like it.
> > But in this case, all we care about is whether NUMA node does or does
> > not have memory, so we have to remove/added into the demotion list.
> > So, would make more sense to have a kinda helper in
> > node_states_{set,clear}_node that calls the respective functions
> > (disable_all_migrate_targets and __set_migration_target_nodes)?
> 
> Of, you're saying that we could do this in the hotplug code itself
> instead of from a notifier?  I agree, we *could*.  That would be more
> efficient.  But, I do like the idea of doing this from a notifier
> because it's a bit less brittle.
> 
> Do you feel strongly about this one?

Hi Dave,

No, I do not. I even had mixed feelings myself when suggesting this as well.
As you said, it would be more optimum, but it feels kinda wrong placing the
call directly in hotplug code.

So all in all, I think your approach is more neat and clean, and more than
enough for now.

I yet have to dive in the details, but I got one more question.
Can we have CONFIG_MEMORY_HOTPLUG && !CONFIG_HOTPLUG_CPU scenarios?
I wonder because I do not see a stub function in case CONFIG_HOTPLUG_CPU
is not enabled, so I guess we cannot.

I am asking this because migrate_on_reclaim_callback() is envolved
with CONFIG_MEMORY_HOTPLUG, but calls cpuhp_setup_state, and I was not
sure whether we would have some dependency here?

Thanks


-- 
Oscar Salvador
SUSE L3

[PATCH] drivers: iio: proximity: Fix a spelling postive to positive in the file sx9500.c

[Bhaskar Chowdhury]

s/postive/positive/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/iio/proximity/sx9500.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
index acb821cbad46..67353d33af94 100644
--- a/drivers/iio/proximity/sx9500.c
+++ b/drivers/iio/proximity/sx9500.c
@@ -758,7 +758,7 @@ static const struct sx9500_reg_default 
sx9500_default_regs[] = {
.reg = SX9500_REG_PROX_CTRL5,
/*
 * Debouncer off, lowest average negative filter,
-* highest average postive filter.
+* highest average positive filter.
 */
.def = 0x0f,
},
--
2.30.0

Re: [PATCH 4/6] MIPS: refactor the maybe coherent DMA indicators

[Christoph Hellwig]

On Tue, Feb 09, 2021 at 02:12:37PM +0100, Thomas Bogendoerfer wrote:
> > +#ifdef CONFIG_DMA_MAYBE_COHERENT
> > +extern bool dma_default_coherent;
> >  static inline bool dev_is_dma_coherent(struct device *dev)
> >  {
> > -   return coherentio == IO_COHERENCE_ENABLED ||
> > -   (coherentio == IO_COHERENCE_DEFAULT && hw_coherentio);
> > +   return dma_default_coherent;
> 
> this breaks overriding of coherentio via command line. plat_mem_setup/
> plat_setup_iocoherency is called before earlyparams are handled. So
> changing coherentio after that doesn't have any effect.

Hmm.  In that case a manual override does actually work for alchemy,
as that initializes coherentio from plat_mem_setup().  But the
elaborate sanity checking that malta performs in plat_setup_iocoherency
is rather pointless then, as coherentio will always be set to
IO_COHERENCE_DISABLED at this point.

Re: [PATCH] clk: at91: Fix the declaration of the clocks

[Saravana Kannan]

On Wed, Feb 10, 2021 at 12:51 AM Geert Uytterhoeven
 wrote:
>
> Hi Saravana,
>
> On Wed, Feb 10, 2021 at 1:57 AM Saravana Kannan  wrote:
> > On Tue, Feb 9, 2021 at 4:54 PM Stephen Boyd  wrote:
> > > Quoting tudor.amba...@microchip.com (2021-02-08 01:49:45)
> > > > Do you plan to take this patch for v5.12?
> > > > If fw_devlink will remain set to ON for v5.12, some of our boards will
> > > > no longer boot without this patch.
> > >
> > > Is fw_devlink defaulted to on for v5.12?
> >
> > Yes.
>
> Have all issues been identified and understood?
> Have all issues been fixed, reviewed, and committed?
> Have all fixes entered linux-next?
> Have all fixes been migrated from submaintainers to maintainers?

I'm hoping Tudor has reported and the fixes that have gone in so far
addressed all his issues. Otherwise, they need to be reported so we
can fix them.

As of now, there's no pending fix that hasn't landed in maintainer
trees. So that's good.

-Saravana

>
> We're already at v5.11-rc7.
> Yes, we can get fixes into v5.12-rc7. Or v5.12-rc9...
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH v2] staging: gdm724x: Fix DMA from stack

[Amey Narkhede]

On 21/02/10 09:06AM, Greg KH wrote:
> On Wed, Feb 10, 2021 at 01:31:34PM +0530, Amey Narkhede wrote:
> > Stack allocated buffers cannot be used for DMA
> > on all architectures so allocate hci_packet buffer
> > using kzalloc().
> >
> > Signed-off-by: Amey Narkhede 
> > ---
> > Changes in v2:
> > - Fixed build warning
> > - Fixed memory leak using kfree
> >
> >  drivers/staging/gdm724x/gdm_usb.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/gdm724x/gdm_usb.c 
> > b/drivers/staging/gdm724x/gdm_usb.c
> > index dc4da66c3..c4a9b90c5 100644
> > --- a/drivers/staging/gdm724x/gdm_usb.c
> > +++ b/drivers/staging/gdm724x/gdm_usb.c
> > @@ -56,11 +56,15 @@ static int gdm_usb_recv(void *priv_dev,
> >
> >  static int request_mac_address(struct lte_udev *udev)
> >  {
> > -   u8 buf[16] = {0,};
> > -   struct hci_packet *hci = (struct hci_packet *)buf;
> > +   u8 *buf;
> > +   struct hci_packet *hci;
> > struct usb_device *usbdev = udev->usbdev;
> > int actual;
> > int ret = -1;
> > +   buf = kzalloc(16, GFP_KERNEL);
>
> checkpatch did not complain about this?
No. checkpatch shows no errors and warnings.
>
> And why do you need 'buf' anymore now?  Why not just allocate hci and
> pass that to the request instead?  Saves you an extra cast and an extra
> pointer.
>
> thanks,
>
> greg k-h
Thanks. I'll send v3. I assume now we don't need kzalloc anymore as we 
initialize
the hci_packet so kmalloc(sizeof(struct hci_packet),..) will do.

Amey


signature.asc
Description: PGP signature

Re: [PATCH] mtd: rawnand: qcom: Update register macro name for 0x2c offset

[Manivannan Sadhasivam]

On Sun, Jan 31, 2021 at 01:37:16AM +0530, Md Sadre Alam wrote:
> This change will remove unused register name macro NAND_DEV1_ECC_CFG.
> Since this register was only available in QPIC version 1.4.20 ipq40xx
> and it was not used. In QPIC version 1.5 on wards this register got
> removed.In QPIC version 2.0 0x2c offset is updated with register
> NAND_AUTO_STATUS_EN So adding this register macro NAND_AUTO_STATUS_EN
> with offset 0x2c.
> 
> Signed-off-by: Md Sadre Alam 

Reviewed-by: Manivannan Sadhasivam 

Thanks,
Mani

> ---
>  drivers/mtd/nand/raw/qcom_nandc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
> b/drivers/mtd/nand/raw/qcom_nandc.c
> index 9484be8..c238a35 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -27,7 +27,7 @@
>  #define  NAND_DEV0_CFG0  0x20
>  #define  NAND_DEV0_CFG1  0x24
>  #define  NAND_DEV0_ECC_CFG   0x28
> -#define  NAND_DEV1_ECC_CFG   0x2c
> +#define  NAND_AUTO_STATUS_EN 0x2c
>  #define  NAND_DEV1_CFG0  0x30
>  #define  NAND_DEV1_CFG1  0x34
>  #define  NAND_READ_ID0x40
> -- 
> 2.7.4
>