MHI changes for v5.13
Hi Greg, Here is the MHI Pull request for the v5.13 cycle. I stayed with the PR as the number patches got increased. Details are in the signed tag, please consider merging! Thanks, Mani --- The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git tags/mhi-for-v5.13 for you to fetch changes up to a503d1628c9c341dc5e1a26272e38182dca3e823: bus: mhi: fix typo in comments for struct mhi_channel_config (2021-04-09 18:48:22 +0530) MHI changes for v5.13 core: - Added support for Flash Programmer execution environment which allows the host machine (like x86) to flash the modem firmware to NAND or eMMC in the modem. The MHI bus will expose EDL channels (34, 35) and then the opensource QDL tool [1] can be used to flash the firmware from the host. - Added an internal helper for polling the MHI registers with a retry interval. This helper is used now to poll for the MHI ready state in MHI STATUS register. - Various fixes for issues found during the bringup of SDX24/SDX55 based Quectel and Telit modems. - Updates to the Execution environment handling for proper downloading of the AMSS image from SBL (Secondary Bootloader) mode. - Added support for sending STOP channel command to the MHI device and also made changes to the MHI core for proper handling of stop and restart. - Fixed the runtime_pm handling in the core by forcing the device to be in wake mode until TX completion and allowing it to suspend for RX. - Added sanity checks for values read from the device to avoid crash if those are corrupted somehow. - Fixed warnings generated by sparse (W=2) - Couple of kernel doc cleanups in mhi.h pci_generic: - Added support for runtime PM and generic PM - Added Firehose channels for flashing the firmware - Added support for modems such as Quectel EM1XXGR-L, SDX24, SDX65, Foxconn T99W175 exposing relevant channels. [1] https://git.linaro.org/landing-teams/working/qualcomm/qdl.git Bhaumik Bhatt (25): bus: mhi: core: Add missing checks for MMIO register entries bus: mhi: core: Destroy SBL devices when moving to mission mode bus: mhi: core: Download AMSS image from appropriate function bus: mhi: core: Process execution environment changes serially bus: mhi: core: Update debug prints to include local device state bus: mhi: Make firmware image optional for controller bus: mhi: core: Rely on accurate method to determine EDL mode bus: mhi: core: Wait for ready after an EDL firmware download bus: mhi: core: Handle EDL mode entry appropriately bus: mhi: core: Identify Flash Programmer as a mission mode use case bus: mhi: core: Wait for MHI READY state in most scenarios bus: mhi: core: Improve state strings for debug messages bus: mhi: core: Introduce internal register poll helper function bus: mhi: core: Move to polling method to wait for MHI ready bus: mhi: core: Remove pre_init flag used for power purposes bus: mhi: pci_generic: Add SDX65 based modem support bus: mhi: core: Allow sending the STOP channel command bus: mhi: core: Clear context for stopped channels from remove() bus: mhi: core: Improvements to the channel handling state machine bus: mhi: core: Update debug messages to use client device bus: mhi: core: Hold device wake for channel update commands bus: mhi: core: Clear configuration from channel context during reset bus: mhi: core: Check channel execution environment before issuing reset bus: mhi: core: Remove __ prefix for MHI channel unprepare function bus: mhi: Improve documentation on channel transfer setup APIs Carl Yin (1): bus: mhi: core: Add support for Flash Programmer execution environment Colin Ian King (1): bus: mhi: core: remove redundant initialization of variables state and ee Fan Wu (1): bus: mhi: core: Return EAGAIN if MHI ring is full Jarvis Jiang (2): bus: mhi: pci_generic: Introduce Foxconn T99W175 support bus: mhi: fix typo in comments for struct mhi_channel_config Jeffrey Hugo (3): bus: mhi: core: Fix check for syserr at power_up bus: mhi: core: Check state before processing power_down bus: mhi: core: Sanity check values from remote device before use Loic Poulain (14): bus: mhi: pci_generic: Parametrable element count for events bus: mhi: pci_generic: Introduce quectel EM1XXGR-L support bus: mhi: pci_generic: Add SDX24 based modem support bus: mhi: pci_generic: No-Op for device_wake operations bus: mhi: pci_generic: Use generic PCI power management bus: mhi: pci_generic: Add support for runtime PM bus: mhi: pci_generic: Remove
[PATCH RESEND] csky: change a Kconfig symbol name to fix e1000 build error
e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in arch/csky/Kconfig. The symbol in e1000 has been around longer, so change arch/csky/ to use DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000 is also a 2-line change) Now build-tested. Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Andrew Morton Cc: Jesse Brandeburg Cc: Tony Nguyen Cc: intel-wired-...@lists.osuosl.org Cc: Guo Ren Cc: Guo Ren Cc: linux-c...@vger.kernel.org Acked-by: Guo Ren --- Andrew, please merge. v2: Add Acked-by: Guo Ren Has now been build-tested. IMO "CONFIG_" namespace should belong to Kconfig files, not individual drivers, but e1000 isn't the only driver that uses CONFIG_ symbols. arch/csky/Kconfig|2 +- arch/csky/include/asm/page.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- linux-next-20210409.orig/arch/csky/include/asm/page.h +++ linux-next-20210409/arch/csky/include/asm/page.h @@ -28,7 +28,7 @@ #define SSEG_SIZE 0x2000 #define LOWMEM_LIMIT (SSEG_SIZE * 2) -#define PHYS_OFFSET_OFFSET (CONFIG_RAM_BASE & (SSEG_SIZE - 1)) +#define PHYS_OFFSET_OFFSET (CONFIG_DRAM_BASE & (SSEG_SIZE - 1)) #ifndef __ASSEMBLY__ --- linux-next-20210409.orig/arch/csky/Kconfig +++ linux-next-20210409/arch/csky/Kconfig @@ -314,7 +314,7 @@ config FORCE_MAX_ZONEORDER int "Maximum zone order" default "11" -config RAM_BASE +config DRAM_BASE hex "DRAM start addr (the same with memory-section in dts)" default 0x0
Re: arch/csky/mm/tcm.c:9:2: error: #error "You should define ITCM_RAM_BASE"
On 4/10/21 9:43 PM, kernel test robot wrote: > Hi Julian, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 52e44129fba5cfc4e351fdb5e45849afc74d9a53 > commit: 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 lib: fix kconfig dependency > on ARCH_WANT_FRAME_POINTERS > date: 31 hours ago > config: csky-randconfig-c003-20210411 (attached as .config) > compiler: csky-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=csky > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >>> arch/csky/mm/tcm.c:9:2: error: #error "You should define ITCM_RAM_BASE" >9 | #error "You should define ITCM_RAM_BASE" > | ^ >arch/csky/mm/tcm.c:109:7: warning: no previous prototype for 'tcm_alloc' > [-Wmissing-prototypes] > 109 | void *tcm_alloc(size_t len) > | ^ >arch/csky/mm/tcm.c:124:6: warning: no previous prototype for 'tcm_free' > [-Wmissing-prototypes] > 124 | void tcm_free(void *addr, size_t len) > | ^~~~ > > Kconfig warnings: (for reference only) >WARNING: unmet direct dependencies detected for LOCKDEP >Depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && (FRAME_POINTER || > MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86) >Selected by >- LOCK_STAT && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT >- DEBUG_LOCK_ALLOC && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT > > > vim +9 arch/csky/mm/tcm.c > > f525bb2c9e7cf1 Guo Ren 2019-11-27 7 > f525bb2c9e7cf1 Guo Ren 2019-11-27 8 #if (CONFIG_ITCM_RAM_BASE == > 0x) > f525bb2c9e7cf1 Guo Ren 2019-11-27 @9 #error "You should define > ITCM_RAM_BASE" > f525bb2c9e7cf1 Guo Ren 2019-11-27 10 #endif > f525bb2c9e7cf1 Guo Ren 2019-11-27 11 > > :: The code at line 9 was first introduced by commit > :: f525bb2c9e7cf1e3c43ab57704c9e1c836d30b34 csky: Tightly-Coupled Memory > or Sram support > > :: TO: Guo Ren > :: CC: Guo Ren Hi ktr/lkp, Do you have the ability to modify a (rand)config file before doing a build? To fix this kconfig problem, you can use: ./scripts/config --set-val ITCM_RAM_BASE 0xe000 or ./scripts/config --file csky-randconfig-c003-20210411 --set-val ITCM_RAM_BASE 0xe000 if you want to modify some file other than ".config". (0xe00 is an arbitrary value here -- just cannot be 0x.) Then run "make oldconfig" and "make all" or however you normally build a kernel. It looks like the Kconfig file's ITCM_RAM_BASE parameter is expected to be set/modified by the user. The default value of 0x is invalid. -- ~Randy
Re: [External] Re: [RFC PATCH v2 04/18] mm: memcontrol: simplify lruvec_holds_page_lru_lock
On Sat, Apr 10, 2021 at 12:00 AM Johannes Weiner wrote: > > On Fri, Apr 09, 2021 at 08:29:45PM +0800, Muchun Song wrote: > > We already have a helper lruvec_memcg() to get the memcg from lruvec, we > > do not need to do it ourselves in the lruvec_holds_page_lru_lock(). So use > > lruvec_memcg() instead. And if mem_cgroup_disabled() returns false, the > > page_memcg(page) (the LRU pages) cannot be NULL. So remove the odd logic > > of "memcg = page_memcg(page) ? : root_mem_cgroup". And use lruvec_pgdat > > to simplify the code. We can have a single definition for this function > > that works for !CONFIG_MEMCG, CONFIG_MEMCG + mem_cgroup_disabled() and > > CONFIG_MEMCG. > > > > Signed-off-by: Muchun Song > > Looks good to me. > > Acked-by: Johannes Weiner Thanks for your review. > > If you haven't done so yet, please make sure to explicitly test with > all three config combinations, just because the dummy abstractions for > memcg disabled or compiled out tend to be paper thin and don't always > behave the way you might expect when you do more complicated things. I have tested. There is no problem. Thanks :-) > > Something like > > boot > echo sparsefile >/dev/null (> ram size to fill memory and reclaim) > echo 1 >/proc/sys/vm/compact_memory > > should exercise this new function in a couple of important scenarios.
Re: drivers/parport/parport_cs.c:147 parport_config() warn: inconsistent indenting
On Sun, 2021-04-11 at 02:02 +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: d4961772226de3b48a395a26c076d450d7044c76 > commit: decf26f6ec25dac868782dc1751623a87d147831 parport: Convert > printk(KERN_ to pr_( > date: 12 months ago > config: x86_64-randconfig-m001-20210410 (attached as .config) > compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > smatch warnings: > drivers/parport/parport_cs.c:147 parport_config() warn: inconsistent indenting False positive. The whole thing is inconsistently indented.
arch/csky/mm/tcm.c:9:2: error: #error "You should define ITCM_RAM_BASE"
Hi Julian, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 52e44129fba5cfc4e351fdb5e45849afc74d9a53 commit: 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS date: 31 hours ago config: csky-randconfig-c003-20210411 (attached as .config) compiler: csky-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=csky If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> arch/csky/mm/tcm.c:9:2: error: #error "You should define ITCM_RAM_BASE" 9 | #error "You should define ITCM_RAM_BASE" | ^ arch/csky/mm/tcm.c:109:7: warning: no previous prototype for 'tcm_alloc' [-Wmissing-prototypes] 109 | void *tcm_alloc(size_t len) | ^ arch/csky/mm/tcm.c:124:6: warning: no previous prototype for 'tcm_free' [-Wmissing-prototypes] 124 | void tcm_free(void *addr, size_t len) | ^~~~ Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for LOCKDEP Depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && (FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86) Selected by - LOCK_STAT && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT - DEBUG_LOCK_ALLOC && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT vim +9 arch/csky/mm/tcm.c f525bb2c9e7cf1 Guo Ren 2019-11-27 7 f525bb2c9e7cf1 Guo Ren 2019-11-27 8 #if (CONFIG_ITCM_RAM_BASE == 0x) f525bb2c9e7cf1 Guo Ren 2019-11-27 @9 #error "You should define ITCM_RAM_BASE" f525bb2c9e7cf1 Guo Ren 2019-11-27 10 #endif f525bb2c9e7cf1 Guo Ren 2019-11-27 11 :: The code at line 9 was first introduced by commit :: f525bb2c9e7cf1e3c43ab57704c9e1c836d30b34 csky: Tightly-Coupled Memory or Sram support :: TO: Guo Ren :: CC: Guo Ren --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH v2 3/3] staging: rtl8192e: remove unncessary parentheses
Removed unnecessary parentheses because they must be used only when it
is necessary or they improve readability.
Reported by checkpatch.
Signed-off-by: Mitali Borkar
---
Changes from v1:- No changes.
drivers/staging/rtl8192e/rtl819x_HTProc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index 89d0e9ec188d..b1fa8e9a4f28 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -287,7 +287,7 @@ void HTConstructCapabilityElement(struct rtllib_device
*ieee, u8 *posHTCap,
u8 EWC11NHTCap[] = {0x00, 0x90, 0x4c, 0x33};
memcpy(posHTCap, EWC11NHTCap, sizeof(EWC11NHTCap));
- pCapELE = (struct ht_capab_ele *)&(posHTCap[4]);
+ pCapELE = (struct ht_capab_ele *)[4];
*len = 30 + 2;
} else {
pCapELE = (struct ht_capab_ele *)posHTCap;
@@ -646,13 +646,13 @@ void HTInitializeHTInfo(struct rtllib_device *ieee)
pHTInfo->CurrentMPDUDensity = pHTInfo->MPDU_Density;
pHTInfo->CurrentAMPDUFactor = pHTInfo->AMPDU_Factor;
- memset((void *)(&(pHTInfo->SelfHTCap)), 0,
+ memset((void *)(>SelfHTCap), 0,
sizeof(pHTInfo->SelfHTCap));
- memset((void *)(&(pHTInfo->SelfHTInfo)), 0,
+ memset((void *)(>SelfHTInfo), 0,
sizeof(pHTInfo->SelfHTInfo));
- memset((void *)(&(pHTInfo->PeerHTCapBuf)), 0,
+ memset((void *)(>PeerHTCapBuf), 0,
sizeof(pHTInfo->PeerHTCapBuf));
- memset((void *)(&(pHTInfo->PeerHTInfoBuf)), 0,
+ memset((void *)(>PeerHTInfoBuf), 0,
sizeof(pHTInfo->PeerHTInfoBuf));
pHTInfo->bSwBwInProgress = false;
@@ -668,7 +668,7 @@ void HTInitializeHTInfo(struct rtllib_device *ieee)
pHTInfo->IOTRaFunc = 0;
{
- u8 *RegHTSuppRateSets = &(ieee->RegHTSuppRateSet[0]);
+ u8 *RegHTSuppRateSets = >RegHTSuppRateSet[0];
RegHTSuppRateSets[0] = 0xFF;
RegHTSuppRateSets[1] = 0xFF;
--
2.30.2
[PATCH v2 2/3] staging: rtl8192e: remove unnecessary ftrace-like logging
Removed unncessary ftrace-like logging by simply deleting that statement
as we have other modes of logging like ftrace.
Reported by checkpatch.
Signed-off-by: Mitali Borkar
---
Changes from v1:- No changes made.
drivers/staging/rtl8192e/rtl819x_HTProc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index 0b1e92f17805..89d0e9ec188d 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -630,7 +630,6 @@ void HTInitializeHTInfo(struct rtllib_device *ieee)
{
struct rt_hi_throughput *pHTInfo = ieee->pHTInfo;
- netdev_vdbg(ieee->dev, "%s()\n", __func__);
pHTInfo->bCurrentHTSupport = false;
pHTInfo->bCurBW40MHz = false;
@@ -698,7 +697,6 @@ void HTResetSelfAndSavePeerSetting(struct rtllib_device
*ieee,
struct rt_hi_throughput *pHTInfo = ieee->pHTInfo;
u8 bIOTAction = 0;
- netdev_vdbg(ieee->dev, "%s()\n", __func__);
/* unmark bEnableHT flag here is the same reason why unmarked in
* function rtllib_softmac_new_net. WB 2008.09.10
*/
@@ -832,8 +830,6 @@ static void HTSetConnectBwModeCallback(struct rtllib_device
*ieee)
{
struct rt_hi_throughput *pHTInfo = ieee->pHTInfo;
- netdev_vdbg(ieee->dev, "%s()\n", __func__);
-
if (pHTInfo->bCurBW40MHz) {
if (pHTInfo->CurSTAExtChnlOffset == HT_EXTCHNL_OFFSET_UPPER)
ieee->set_chan(ieee->dev,
--
2.30.2
[PATCH v2 1/3] staging: rtl8192e: remove unnecessary parentheses
Removed unnecessary parentheses around '!xyz' as '!' has higher
precedance than '||'
Signed-off-by: Mitali Borkar
---
Changes from v1:- removed unnecessary parentheses around boolean
expression
drivers/staging/rtl8192e/rtl819x_HTProc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index b1fa8e9a4f28..431202927036 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -276,7 +276,7 @@ void HTConstructCapabilityElement(struct rtllib_device
*ieee, u8 *posHTCap,
struct rt_hi_throughput *pHT = ieee->pHTInfo;
struct ht_capab_ele *pCapELE = NULL;
- if ((!posHTCap) || (!pHT)) {
+ if (!posHTCap || !pHT) {
netdev_warn(ieee->dev,
"%s(): posHTCap and pHTInfo are null\n", __func__);
return;
--
2.30.2
[PATCH v2 0/3] staging: rtl8192e: remove unnecessary parentheses
This patch fixes style issues Changes from v1:- [Patch 1/3]:- Removed unnecessary parentheses around boolean expressions [Patch 2/3]:- No changes [Patch 3/3]:- No changes Mitali Borkar (3): staging: rtl8192e: remove unnecessary parentheses staging: rtl8192e: remove unnecessary ftrace-like logging staging: rtl8192e: remove unncessary parentheses drivers/staging/rtl8192e/rtl819x_HTProc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.30.2
Re: [PATCH] ext4: add a configurable parameter to prevent endless loop in ext4_mb_discard_group_p
On Sun, Apr 11, 2021 at 03:45:01AM +0800, Wen Yang wrote: > At this time, some logs are lost. It is suspected that the hard disk itself > is faulty. If you have a kernel crash dump, that means you can extract out the dmesg buffer, correct? Is there any I/O error messages in the kernel log? What is the basis of the suspicion that the hard drive is faulty? Kernel dmesg output? Error reporting from smartctl? > There are many hard disks on our server. Maybe we should not occupy 100% CPU > for a long time just because one hard disk fails. It depends on the nature of the hard drive failure. How is it failing? One thing which we do need to be careful about is when focusing on how to prevent a failure caused by some particular (potentially extreme) scenarios, that we don't cause problems on more common scenarios (for example a heavily loaded server, and/or a case where the file system is almost full where we have multiple files "fighting" over a small number of free blocks). In general, my attitude is that the best way to protect against hard drive failures is to have processes which are monitoring the health of the system, and if there is evidence of a failed drive, that we immediately kill all jobs which are relying on that drive (which we call "draining" a particular drive), and/or if a sufficiently large percentage of the drives have failed, or the machine can no longer do its job, to automatically move all of those jobs to other servers (e.g., "drain" the server), and then send the machine to some kind of data center repair service, where the failed hard drives can be replaced. I'm skeptical of attempts to try to make the file system to somehow continue to be able to "work" in the face of hard drive failures, since failures can be highly atypical, and what might work well in one failure scenario might be catastrophic in another. It's especially problematic if the HDD is not explcitly signalling an error condition, but rather being slow (because it's doing a huge number of retries), or the HDD is returning data which is simply different from what was previously written. The best we can do in that case is to detect that something is wrong (this is where metadata checksums would be very helpful), and then either remount the file system r/o, or panic the machine, and/or signal to userspace that some particular file system should be drained. Cheers, - Ted
Re: [PATCH v2 4/6] devres: handle zero size in devm_kmalloc()
Hi Bartosz, On Mon, Jun 29, 2020 at 1:56 PM Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > Make devm_kmalloc() behave similarly to non-managed kmalloc(): return > ZERO_SIZE_PTR when requested size is 0. Update devm_kfree() to handle > this case. This is wrong if you consider devm_krealloc API that you added. The premise of devm_krealloc() is that it does not disturb devres "stack", however in this case there is no entry in the stack. Consider: ptr = devm_kzalloc(dev, 0, GFP_KERNEL); ... more devm API calls ... /* This allocation will be on top of devm stack, not bottom ! */ ptr = devm_krealloc(dev, ptr, 16, GFP_KERNEL); And also: ptr = devm_kzalloc(dev, 16, GFP_KERNEL); ... more devm API calls ... /* Here we lose out position */ ptr = devm_krealloc(dev, ptr, 0, GFP_KERNEL); ... /* and now our memory allocation will be released first */ ptr = devm_krealloc(dev, ptr, 16, GFP_KERNEL); IMO special-casing 0-size allocations for managed memory allocations should not be done. Thanks. -- Dmitry
BUG: unable to handle kernel NULL pointer dereference in io_uring_cancel_task_requests
Hi When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz the Linux kernel, I found a null-ptr-deref bug in io_uring_cancel_task_requests under fault injection condition, but I'm not sure about this. Sorry, I do not have a reproducing program for this bug. I hope that the stack trace information in the crash log can help you locate the problem. Here is the details: commit: 3b9cdafb5358eb9f3790de2f728f765fef100731 version: linux 5.11 git tree:upstream Full log can be found in the attachment. Fault injection log: FAULT_INJECTION: forcing a failure. name fail_usercopy, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x137/0x194 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:52 [inline] should_fail+0x23e/0x250 lib/fault-inject.c:146 should_fail_usercopy+0x16/0x20 lib/fault-inject-usercopy.c:37 _copy_from_user+0x1c/0xd0 lib/usercopy.c:14 copy_from_user include/linux/uaccess.h:192 [inline] set_user_sigmask+0x4b/0x110 kernel/signal.c:3015 io_cqring_wait+0x2e3/0x8b0 fs/io_uring.c:7250 __do_sys_io_uring_enter fs/io_uring.c:9480 [inline] __se_sys_io_uring_enter+0x8fc/0xb70 fs/io_uring.c:9397 __x64_sys_io_uring_enter+0x74/0x80 fs/io_uring.c:9397 do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46a379 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f046fa19c58 EFLAGS: 0246 ORIG_RAX: 01aa RAX: ffda RBX: 0078c080 RCX: 0046a379 RDX: 66ab RSI: 0001 RDI: 0003 RBP: 7f046fa19c90 R08: 2040 R09: 0008 R10: 0003 R11: 0246 R12: R13: R14: 0078c080 R15: 7fff769deef0 Crash log: BUG: kernel NULL pointer dereference, address: 0040 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 49954067 P4D 49954067 PUD 45f92067 PMD 0 Oops: [#1] PREEMPT SMP CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:io_uring_cancel_task_requests+0x3f/0x990 fs/io_uring.c:9045 Code: 48 8b 04 25 28 00 00 00 48 89 44 24 68 e8 89 e6 c5 ff 65 4c 8b 34 25 00 6d 01 00 49 8d 7c 24 40 48 89 7c 24 30 e8 81 97 d6 ff <41> 8b 5c 24 40 89 de 83 e6 02 31 ff e8 70 ea c5 ff 83 e3 02 48 89 RSP: 0018:c90002a97b48 EFLAGS: 00010246 RAX: 88804b8e0d38 RBX: 88804b8ad700 RCX: 0764 RDX: 0040 RSI: 8880409d5140 RDI: 0040 RBP: 8880409d5140 R08: R09: 0043 R10: 0001 R11: 88804b8e0280 R12: R13: 8880409d5140 R14: 88804b8e0280 R15: 8880481c1800 FS: 7f046fa1a700() GS:88807ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0040 CR3: 479a5000 CR4: 00750ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: __io_uring_files_cancel+0x9b/0x200 fs/io_uring.c:9140 io_uring_files_cancel include/linux/io_uring.h:65 [inline] do_exit+0x1a8/0x16d0 kernel/exit.c:780 do_group_exit+0xc5/0x180 kernel/exit.c:922 get_signal+0xd90/0x1470 kernel/signal.c:2773 arch_do_signal_or_restart+0x2a/0x260 arch/x86/kernel/signal.c:811 handle_signal_work kernel/entry/common.c:147 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x109/0x1a0 kernel/entry/common.c:208 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:301 do_syscall_64+0x45/0x80 arch/x86/entry/common.c:56 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46a379 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f046fa19cd8 EFLAGS: 0246 ORIG_RAX: 00ca RAX: fe00 RBX: 0078c080 RCX: 0046a379 RDX: RSI: 0080 RDI: 0078c088 RBP: 0078c088 R08: R09: R10: R11: 0246 R12: 0078c08c R13: R14: 0078c080 R15: 7fff769deef0 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 0040 ---[ end trace
BUG: unable to handle kernel NULL pointer dereference in do_epoll_wait
Hi When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz the Linux kernel, I found a null-ptr-deref bug in do_epoll_wait, but I'm not sure about this. Sorry, I do not have a reproducing program for this bug. I hope that the stack trace information in the crash log can help you locate the problem. Here is the details: commit: 3b9cdafb5358eb9f3790de2f728f765fef100731 version: linux 5.11 git tree:upstream report: BUG: kernel NULL pointer dereference, address: 0048 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP CPU: 1 PID: 23043 Comm: systemd-udevd Not tainted 5.11.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:vfs_poll include/linux/poll.h:88 [inline] RIP: 0010:ep_item_poll fs/eventpoll.c:840 [inline] RIP: 0010:ep_send_events fs/eventpoll.c:1677 [inline] RIP: 0010:ep_poll fs/eventpoll.c:1792 [inline] RIP: 0010:do_epoll_wait+0x68d/0xf00 fs/eventpoll.c:2220 Code: 50 89 84 24 d0 00 00 00 48 8d 7b 28 e8 bc 0f d8 ff 48 8b 6b 28 48 c7 c0 e0 6e c6 85 48 39 c5 74 3c 48 8d 7d 48 e8 a3 0f d8 ff <4c> 8b 75 48 4d 85 f6 0f 84 3f 02 00 00 e8 f1 59 c7 ff 48 89 df 48 RSP: 0018:c9000769fdc8 EFLAGS: 00010246 RAX: 88800d87edb8 RBX: 888009b0e600 RCX: 03db RDX: 0048 RSI: RDI: 0048 RBP: R08: R09: 004f R10: 0001 R11: 88800d87e300 R12: 888041f93d18 R13: 888041f93d68 R14: 0004 R15: 888041f93d20 FS: 7f4f3e1fa8c0() GS:88807ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0048 CR3: 0e3c5000 CR4: 00750ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: __do_sys_epoll_wait fs/eventpoll.c:2232 [inline] __se_sys_epoll_wait fs/eventpoll.c:2227 [inline] __x64_sys_epoll_wait+0xf6/0x120 fs/eventpoll.c:2227 do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f4f3d07b2e3 Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 3d 29 54 2b 00 00 75 13 49 89 ca b8 e8 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 0b c2 00 00 48 89 04 24 RSP: 002b:7fff2e5db728 EFLAGS: 0246 ORIG_RAX: 00e8 RAX: ffda RBX: 7fff2e5db7f0 RCX: 7f4f3d07b2e3 RDX: 0004 RSI: 7fff2e5db7f0 RDI: 0004 RBP: 7fff2e5db8a0 R08: 5578feaa7410 R09: 5578fea9b855 R10: R11: 0246 R12: 7fff2e5db7f0 R13: 7fff2e5db7fc R14: 0003 R15: 000e Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 0048 ---[ end trace 201f1cc113e7b051 ]--- RIP: 0010:vfs_poll include/linux/poll.h:88 [inline] RIP: 0010:ep_item_poll fs/eventpoll.c:840 [inline] RIP: 0010:ep_send_events fs/eventpoll.c:1677 [inline] RIP: 0010:ep_poll fs/eventpoll.c:1792 [inline] RIP: 0010:do_epoll_wait+0x68d/0xf00 fs/eventpoll.c:2220 Code: 50 89 84 24 d0 00 00 00 48 8d 7b 28 e8 bc 0f d8 ff 48 8b 6b 28 48 c7 c0 e0 6e c6 85 48 39 c5 74 3c 48 8d 7d 48 e8 a3 0f d8 ff <4c> 8b 75 48 4d 85 f6 0f 84 3f 02 00 00 e8 f1 59 c7 ff 48 89 df 48 RSP: 0018:c9000769fdc8 EFLAGS: 00010246 RAX: 88800d87edb8 RBX: 888009b0e600 RCX: 03db RDX: 0048 RSI: RDI: 0048 RBP: R08: R09: 004f R10: 0001 R11: 88800d87e300 R12: 888041f93d18 R13: 888041f93d68 R14: 0004 R15: 888041f93d20 FS: 7f4f3e1fa8c0() GS:88807ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0048 CR3: 0e3c5000 CR4: 00750ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554
[PATCH 1/2] HID: hid-input: add mapping for emoji picker key
HUTRR101 added a new usage code for a key that is supposed to invoke and
dismiss an emoji picker widget to assist users to locate and enter emojis.
This patch adds a new key definition KEY_EMOJI_PICKER and maps 0x0c/0x0d9
usage code to this new keycode. Additionally hid-debug is adjusted to
recognize this new usage code as well.
Signed-off-by: Dmitry Torokhov
---
drivers/hid/hid-debug.c| 1 +
drivers/hid/hid-input.c| 3 +++
include/uapi/linux/input-event-codes.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index d7eaf9100370..982737827b87 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -929,6 +929,7 @@ static const char *keys[KEY_MAX + 1] = {
[KEY_APPSELECT] = "AppSelect",
[KEY_SCREENSAVER] = "ScreenSaver",
[KEY_VOICECOMMAND] = "VoiceCommand",
+ [KEY_EMOJI_PICKER] = "EmojiPicker",
[KEY_BRIGHTNESS_MIN] = "BrightnessMin",
[KEY_BRIGHTNESS_MAX] = "BrightnessMax",
[KEY_BRIGHTNESS_AUTO] = "BrightnessAuto",
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 236bccd37760..e982d8173c9c 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -963,6 +963,9 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
case 0x0cd: map_key_clear(KEY_PLAYPAUSE); break;
case 0x0cf: map_key_clear(KEY_VOICECOMMAND);break;
+
+ case 0x0d9: map_key_clear(KEY_EMOJI_PICKER);break;
+
case 0x0e0: map_abs_clear(ABS_VOLUME); break;
case 0x0e2: map_key_clear(KEY_MUTE);break;
case 0x0e5: map_key_clear(KEY_BASSBOOST); break;
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index ee93428ced9a..225ec87d4f22 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -611,6 +611,7 @@
#define KEY_VOICECOMMAND 0x246 /* Listening Voice Command */
#define KEY_ASSISTANT 0x247 /* AL Context-aware desktop assistant */
#define KEY_KBD_LAYOUT_NEXT0x248 /* AC Next Keyboard Layout Select */
+#define KEY_EMOJI_PICKER 0x249 /* Show/hide emoji picker (HUTRR101) */
#define KEY_BRIGHTNESS_MIN 0x250 /* Set Brightness to Minimum */
#define KEY_BRIGHTNESS_MAX 0x251 /* Set Brightness to Maximum */
--
2.31.1.295.g9ea45b61b8-goog
[PATCH 2/2] HID: hid-debug: recognize KEY_ASSISTANT and KEY_KBD_LAYOUT_NEXT
Add missing descriptions for KEY_ASSISTANT and KEY_KBD_LAYOUT_NEXT.
Signed-off-by: Dmitry Torokhov
---
drivers/hid/hid-debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 982737827b87..4d2b699daf8d 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -929,6 +929,8 @@ static const char *keys[KEY_MAX + 1] = {
[KEY_APPSELECT] = "AppSelect",
[KEY_SCREENSAVER] = "ScreenSaver",
[KEY_VOICECOMMAND] = "VoiceCommand",
+ [KEY_ASSISTANT] = "Assistant",
+ [KEY_KBD_LAYOUT_NEXT] = "KbdLayoutNext",
[KEY_EMOJI_PICKER] = "EmojiPicker",
[KEY_BRIGHTNESS_MIN] = "BrightnessMin",
[KEY_BRIGHTNESS_MAX] = "BrightnessMax",
--
2.31.1.295.g9ea45b61b8-goog
[PATCH net-next v3 1/1] net: stmmac: Add support for external trigger timestamping
From: Tan Tee Min
The Synopsis MAC controller supports auxiliary snapshot feature that
allows user to store a snapshot of the system time based on an external
event.
This patch add supports to the above mentioned feature. Users will be
able to triggered capturing the time snapshot from user-space using
application such as testptp or any other applications that uses the
PTP_EXTTS_REQUEST ioctl request.
Cc: Richard Cochran
Signed-off-by: Tan Tee Min
Co-developed-by: Wong Vee Khee
Signed-off-by: Wong Vee Khee
---
v2 -> v3:
- Flip ext_snapshot_en condition check for early return.
v1 -> v2:
- Changed from pr_info() to netdev_dbg().
.../net/ethernet/stmicro/stmmac/dwmac-intel.c | 11 +
drivers/net/ethernet/stmicro/stmmac/hwif.h| 5 +++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 ++
.../ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 41 +++
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +
.../net/ethernet/stmicro/stmmac/stmmac_ptp.c | 39 +-
.../net/ethernet/stmicro/stmmac/stmmac_ptp.h | 1 +
include/linux/stmmac.h| 2 +
8 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 60566598d644..60e17fd24aba 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -296,6 +296,13 @@ static int intel_crosststamp(ktime_t *device,
intel_priv = priv->plat->bsp_priv;
+ /* Both internal crosstimestamping and external triggered event
+* timestamping cannot be run concurrently.
+*/
+ if (priv->plat->ext_snapshot_en)
+ return -EBUSY;
+
+ mutex_lock(>aux_ts_lock);
/* Enable Internal snapshot trigger */
acr_value = readl(ptpaddr + PTP_ACR);
acr_value &= ~PTP_ACR_MASK;
@@ -321,6 +328,7 @@ static int intel_crosststamp(ktime_t *device,
acr_value = readl(ptpaddr + PTP_ACR);
acr_value |= PTP_ACR_ATSFC;
writel(acr_value, ptpaddr + PTP_ACR);
+ mutex_unlock(>aux_ts_lock);
/* Trigger Internal snapshot signal
* Create a rising edge by just toggle the GPO1 to low
@@ -355,6 +363,8 @@ static int intel_crosststamp(ktime_t *device,
*system = convert_art_to_tsc(art_time);
}
+ /* Release the mutex */
+ mutex_unlock(>aux_ts_lock);
system->cycles *= intel_priv->crossts_adj;
return 0;
@@ -520,6 +530,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
plat->int_snapshot_num = AUX_SNAPSHOT1;
+ plat->ext_snapshot_num = AUX_SNAPSHOT0;
plat->has_crossts = true;
plat->crosststamp = intel_crosststamp;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 2b5022ef1e52..2cc91759b91f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -504,6 +504,8 @@ struct stmmac_ops {
#define stmmac_fpe_irq_status(__priv, __args...) \
stmmac_do_callback(__priv, mac, fpe_irq_status, __args)
+struct stmmac_priv;
+
/* PTP and HW Timer helpers */
struct stmmac_hwtimestamp {
void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
@@ -515,6 +517,7 @@ struct stmmac_hwtimestamp {
int add_sub, int gmac4);
void (*get_systime) (void __iomem *ioaddr, u64 *systime);
void (*get_ptptime)(void __iomem *ioaddr, u64 *ptp_time);
+ void (*timestamp_interrupt)(struct stmmac_priv *priv);
};
#define stmmac_config_hw_tstamping(__priv, __args...) \
@@ -531,6 +534,8 @@ struct stmmac_hwtimestamp {
stmmac_do_void_callback(__priv, ptp, get_systime, __args)
#define stmmac_get_ptptime(__priv, __args...) \
stmmac_do_void_callback(__priv, ptp, get_ptptime, __args)
+#define stmmac_timestamp_interrupt(__priv, __args...) \
+ stmmac_do_void_callback(__priv, ptp, timestamp_interrupt, __args)
/* Helpers to manage the descriptors for chain and ring modes */
struct stmmac_mode_ops {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c49debb62b05..abadcd8cdc41 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -239,6 +239,9 @@ struct stmmac_priv {
int use_riwt;
int irq_wake;
spinlock_t ptp_lock;
+ /* Mutex lock for Auxiliary Snapshots */
+ struct mutex aux_ts_lock;
+
void __iomem *mmcaddr;
void __iomem *ptpaddr;
unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 113c51bcc0b5..f6bdd3cde824 100644
---
Re: [PATCH] phy: nxp-c45: add driver for tja1103
Hi "Radu, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.12-rc6 next-20210409] [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/Radu-Pirea-NXP-OSS/phy-nxp-c45-add-driver-for-tja1103/20210410-024203 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 17e7124aad766b3f158943acb51467f86220afe9 config: arm-allyesconfig (attached as .config) compiler: arm-linux-gnueabi-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/436e508ba7a4bbe24891acf430d7722ed1f5e128 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Radu-Pirea-NXP-OSS/phy-nxp-c45-add-driver-for-tja1103/20210410-024203 git checkout 436e508ba7a4bbe24891acf430d7722ed1f5e128 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arm-linux-gnueabi-ld: drivers/net/phy/nxp-c45.o: in function `nxp_c45_config_init': >> nxp-c45.c:(.text+0xe2c): undefined reference to `__aeabi_uldivmod' >> arm-linux-gnueabi-ld: nxp-c45.c:(.text+0xe64): undefined reference to >> `__aeabi_uldivmod' arm-linux-gnueabi-ld: nxp-c45.c:(.text+0xec0): undefined reference to `__aeabi_uldivmod' arm-linux-gnueabi-ld: nxp-c45.c:(.text+0xef8): undefined reference to `__aeabi_uldivmod' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH RESENDbis] ia64: remove duplicate entries in generic_defconfig
Fix ia64 generic_defconfig duplicate entries, as warned by:
+ arch/ia64/configs/generic_defconfig: warning: override: reassigning to
symbol ATA: => 58
+ arch/ia64/configs/generic_defconfig: warning: override: reassigning to
symbol ATA_PIIX: => 59
These 2 symbols still have the same value as in the removed lines.
Fixes: c331649e6371 ("ia64: Use libata instead of the legacy ide driver in
defconfigs")
Reported-by: Geert Uytterhoeven
Signed-off-by: Randy Dunlap
Cc: Andrew Morton
Cc: Christoph Hellwig
Cc: Tony Luck
Cc: linux-i...@vger.kernel.org
Reviewed-by: Christoph Hellwig
#Cc: Fenghua Yu
---
arch/ia64/configs/generic_defconfig |2 --
1 file changed, 2 deletions(-)
--- lnx-511-rc1.orig/arch/ia64/configs/generic_defconfig
+++ lnx-511-rc1/arch/ia64/configs/generic_defconfig
@@ -55,8 +55,6 @@ CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_QLOGIC_1280=y
-CONFIG_ATA=y
-CONFIG_ATA_PIIX=y
CONFIG_SATA_VITESSE=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
[PATCH net] ice: Re-organizes reqstd/avail {R,T}XQ check/code for efficiency+readability
If user has explicitly requested the number of {R,T}XQs, then it is unnecessary
to get the count of already available {R,T}XQs from the PF avail_{r,t}xqs
bitmap. This value will get overriden by user specified value in any case.
This patch does minor re-organization of the code for improving the flow and
readabiltiy. This scope of improvement was found during the review of the ICE
driver code.
FYI, I could not test this change due to unavailability of the hardware. It
would helpful if somebody can test this and provide Tested-by Tag. Many thanks!
Fixes: 11b7551e096d ("ice: Implement ethtool ops for channels")
Signed-off-by: Salil Mehta
---
drivers/net/ethernet/intel/ice/ice_lib.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c
b/drivers/net/ethernet/intel/ice/ice_lib.c
index d13c7fc8fb0a..161e8dfe548c 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -161,12 +161,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16
vf_id)
switch (vsi->type) {
case ICE_VSI_PF:
- vsi->alloc_txq = min3(pf->num_lan_msix,
- ice_get_avail_txq_count(pf),
- (u16)num_online_cpus());
if (vsi->req_txq) {
vsi->alloc_txq = vsi->req_txq;
vsi->num_txq = vsi->req_txq;
+ } else {
+ vsi->alloc_txq = min3(pf->num_lan_msix,
+ice_get_avail_txq_count(pf),
+(u16)num_online_cpus());
}
pf->num_lan_tx = vsi->alloc_txq;
@@ -175,12 +176,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16
vf_id)
if (!test_bit(ICE_FLAG_RSS_ENA, pf->flags)) {
vsi->alloc_rxq = 1;
} else {
- vsi->alloc_rxq = min3(pf->num_lan_msix,
- ice_get_avail_rxq_count(pf),
- (u16)num_online_cpus());
if (vsi->req_rxq) {
vsi->alloc_rxq = vsi->req_rxq;
vsi->num_rxq = vsi->req_rxq;
+ } else {
+ vsi->alloc_rxq = min3(pf->num_lan_msix,
+ice_get_avail_rxq_count(pf),
+(u16)num_online_cpus());
}
}
--
2.17.1
Re: [PATCH v4] platform/x86: add Gigabyte WMI temperature driver
On 4/10/21 11:18 AM, Thomas Weißschuh wrote:
> Changes since v3:
> * Completely hide unusable sensors
> * Expose force_load parameter read-only via sysfs
> * Naming
> * Style cleanups
>
> -- >8 --
>
> Tested with
> * X570 I Aorus Pro Wifi (rev 1.0)
> * B550M DS3H
> * B550 Gaming X V2 (rev.1.x)
> * Z390 I AORUS PRO WIFI (rev. 1.0)
>
> The mainboard contains an ITE IT8688E chip for management.
> This chips is also handled by drivers/hwmon/i87.c but as it is also used
> by the firmware itself it needs an ACPI driver.
>
> Unfortunately not all sensor registers are handled by the firmware and even
> less are exposed via WMI.
>
> Signed-off-by: Thomas Weißschuh
Good enough, though you may want to improve your description.
Reviewed-by: Guenter Roeck
FWIW, on B450 AORUS M:
gigabyte-wmi DEADBEEF-2001--00A0-C9062910: Forcing load on unknown
platform
gigabyte-wmi DEADBEEF-2001--00A0-C9062910: No temperature sensors usable
Wonder who came up with that GUID.
> ---
Change log and everything that is not supposed to show up in the git history
is supposed to go here.
Guenter
> MAINTAINERS | 6 +
> drivers/platform/x86/Kconfig| 11 ++
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/gigabyte-wmi.c | 195
> 4 files changed, 213 insertions(+)
> create mode 100644 drivers/platform/x86/gigabyte-wmi.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d92f85ca831d..9c10cfc00fe8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7543,6 +7543,12 @@ F: Documentation/filesystems/gfs2*
> F: fs/gfs2/
> F: include/uapi/linux/gfs2_ondisk.h
>
> +GIGABYTE WMI DRIVER
> +M: Thomas Weißschuh
> +L: platform-driver-...@vger.kernel.org
> +S: Maintained
> +F: drivers/platform/x86/gigabyte-wmi.c
> +
> GNSS SUBSYSTEM
> M: Johan Hovold
> S: Maintained
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index ad4e630e73e2..96622a2106f7 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -123,6 +123,17 @@ config XIAOMI_WMI
> To compile this driver as a module, choose M here: the module will
> be called xiaomi-wmi.
>
> +config GIGABYTE_WMI
> + tristate "Gigabyte WMI temperature driver"
> + depends on ACPI_WMI
> + depends on HWMON
> + help
> + Say Y here if you want to support WMI-based temperature reporting on
> + Gigabyte mainboards.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called gigabyte-wmi.
> +
> config ACERHDF
> tristate "Acer Aspire One temperature and fan driver"
> depends on ACPI && THERMAL
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 60d554073749..1621ebfd04fd 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_INTEL_WMI_THUNDERBOLT) +=
> intel-wmi-thunderbolt.o
> obj-$(CONFIG_MXM_WMI)+= mxm-wmi.o
> obj-$(CONFIG_PEAQ_WMI) += peaq-wmi.o
> obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
> +obj-$(CONFIG_GIGABYTE_WMI) += gigabyte-wmi.o
>
> # Acer
> obj-$(CONFIG_ACERHDF)+= acerhdf.o
> diff --git a/drivers/platform/x86/gigabyte-wmi.c
> b/drivers/platform/x86/gigabyte-wmi.c
> new file mode 100644
> index ..c17e51fcf000
> --- /dev/null
> +++ b/drivers/platform/x86/gigabyte-wmi.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2021 Thomas Weißschuh
> + */
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GIGABYTE_WMI_GUID"DEADBEEF-2001--00A0-C9062910"
> +#define NUM_TEMPERATURE_SENSORS 6
> +
> +static bool force_load;
> +module_param(force_load, bool, 0444);
> +MODULE_PARM_DESC(force_load, "Force loading on unknown platform");
> +
> +static u8 usable_sensors_mask;
> +
> +enum gigabyte_wmi_commandtype {
> + GIGABYTE_WMI_BUILD_DATE_QUERY = 0x1,
> + GIGABYTE_WMI_MAINBOARD_TYPE_QUERY = 0x2,
> + GIGABYTE_WMI_FIRMWARE_VERSION_QUERY = 0x4,
> + GIGABYTE_WMI_MAINBOARD_NAME_QUERY = 0x5,
> + GIGABYTE_WMI_TEMPERATURE_QUERY = 0x125,
> +};
> +
> +struct gigabyte_wmi_args {
> + u32 arg1;
> +};
> +
> +static int gigabyte_wmi_perform_query(struct wmi_device *wdev,
> + enum gigabyte_wmi_commandtype command,
> + struct gigabyte_wmi_args *args, struct
> acpi_buffer *out)
> +{
> + const struct acpi_buffer in = {
> + .length = sizeof(*args),
> + .pointer = args,
> + };
> +
> + acpi_status ret = wmidev_evaluate_method(wdev, 0x0, command, , out);
> +
> + if ACPI_FAILURE(ret)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int
[tip:x86/cleanups] BUILD SUCCESS 0d6c8e1e246586b81cb4e6ab1a93a6d4a08a0cf9
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cleanups branch HEAD: 0d6c8e1e246586b81cb4e6ab1a93a6d4a08a0cf9 x86/platform/intel/quark: Fix incorrect kernel-doc comment syntax in files elapsed time: 724m configs tested: 143 configs skipped: 50 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig powerpcklondike_defconfig mips rs90_defconfig powerpc taishan_defconfig armhisi_defconfig arm am200epdkit_defconfig mipsar7_defconfig arm spitz_defconfig m68kmvme147_defconfig xtensa iss_defconfig mipsgpr_defconfig microblaze defconfig powerpc pasemi_defconfig powerpc mpc8540_ads_defconfig armspear6xx_defconfig xtensa nommu_kc705_defconfig powerpc tqm8xx_defconfig s390 debug_defconfig powerpc ebony_defconfig sh secureedge5410_defconfig nios2 defconfig sh kfr2r09_defconfig m68k sun3x_defconfig arm pxa_defconfig arc defconfig powerpc walnut_defconfig mips loongson3_defconfig mips lemote2f_defconfig mips tb0219_defconfig m68k atari_defconfig arm mxs_defconfig mips jazz_defconfig openriscdefconfig sh alldefconfig mips loongson1b_defconfig armpleb_defconfig arm collie_defconfig powerpc mpc837x_rdb_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig arc allyesconfig nds32 allnoconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20210411 x86_64 randconfig-a002-20210411 x86_64 randconfig-a001-20210411 x86_64 randconfig-a005-20210411 x86_64 randconfig-a006-20210411 x86_64 randconfig-a004-20210411 i386 randconfig-a006-20210409 i386 randconfig-a003-20210409 i386 randconfig-a001-20210409 i386 randconfig-a004-20210409 i386 randconfig-a002-20210409 i386 randconfig-a005-20210409 i386 randconfig-a003-20210411 i386 randconfig-a001-20210411 i386 randconfig-a006-20210411 i386 randconfig-a005-20210411 i386 randconfig-a004-20210411 i386 randconfig-a002-20210411 x86_64 randconfig-a014-20210410 x86_64 randconfig-a015-20210410 x86_64 randconfig-a011-20210410 x86_64 randconfig-a013-20210410 x86_64 randconfig-a012-20210410 x86_64 randconfig-a016-20210410 i386 randconfig-a015
Re: about seg fault inside rseq critical section
- On Apr 10, 2021, at 6:49 PM, Mingyi Liu mingyi...@gatech.edu wrote:
> Hi Mathieu ,
> Thanks for your reply. From my current understanding of rseq, when flags
> enabled, any signal generated/happened inside the critical section would
> trigger the user-defined abort handler.
No, that's not how rseq works.
If a signal handler is executed on top of a rseq critical section, it will be
allowed
to run on top of the userspace thread, but the instruction pointer where the
signal
handler will return is modified by the kernel when it detects that it delivers
a signal
on top of a rseq critical section so the signal handler will return to the
abort ip.
See rseq_signal_deliver() for details.
Thanks,
Mathieu
> However, I tried to cause a segmentation fault like the following but it
> didn't
> go to the abort handler and was terminated by OS immediately.
> sigsegv_case.c
>> #define _GNU_SOURCE
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> static __thread volatile struct rseq __rseq_abi;
>> #define RSEQ_SIG 0x53053053
>> static int sys_rseq ( volatile struct rseq * rseq_abi , uint32_t rseq_len ,
>> int flags , uint32_t sig ) {
>> return syscall (__NR_rseq, rseq_abi, rseq_len, flags, sig);
>> }
>> static void register_thread ( void ) {
>> int rc;
>> rc = sys_rseq (&__rseq_abi, sizeof ( struct rseq), 0 , RSEQ_SIG);
>> if (rc) {
>> fprintf (stderr, "Failed to register rseq \n " );
>> exit ( 1 );
>> }
>> }
>> #define RSEQ_ACCESS_ONCE( x ) ( * (__volatile__ __typeof__ (x) * ) & (x))
>> int do_test ( void * addr , int cpu ) {
>> __asm__ __volatile__ goto (
>> ".pushsection __rseq_table, \" aw \"\n\t "
>> ".balign 32 \n\t "
>> "cs_obj: \n\t "
>> ".int 0, 0 \n\t "
>> /* start_ip, post_commit_offset, abort_ip */
>> ".quad 1f, 2f - 1f, 4f \n\t "
>> ".popsection \n\t "
>> "1: \n\t "
>> "leaq cs_obj(%%rip), %%rax \n\t "
>> "movq %%rax, % [rseq_cs] \n\t "
>> "cmpl % [cpu_id], % [current_cpu_id] \n\t "
>> "jnz 4f \n\t "
>> /* enable seg fault */
>> "jmp * % [_addr] \n\t " // seg falut
>> //
>> "jmp % l[committed] \n\t "
>> "2: \n\t "
>> /* Disassembler-friendly signature: nopl (%rip). */
>> ".byte 0x0f, 0x1f, 0x05 \n\t "
>> ".long 0x53053053 \n\t " /* RSEQ_SIG */
>> "4: \n\t "
>> "jmp % l[aborted] \n\t "
>> : /* no outputs */
>> : [cpu_id] "r" (cpu),
>> [current_cpu_id] "m" ( __rseq_abi . cpu_id ),
>> [rseq_cs] "m" ( __rseq_abi . rseq_cs ),
>> [_addr] "r" (addr)
>> : "memory" , "cc" , "rax"
>> : aborted, committed
>> );
>> committed:
>> printf ( "committed \n " );
>> return 0 ;
>> aborted:
>> printf ( "aborted \n " );
>> return - 1 ;
>> }
>> int main ( int argc , char ** argv ) {
>> int cpu, ret;
>> register_thread ();
>> cpu = RSEQ_ACCESS_ONCE ( __rseq_abi . cpu_id_start );
>> printf ( "ret = %d \n " , do_test (( void *) 0xdeadbeef , cpu));
>> return 0 ;
>> }
> Also, I've tried SIGINT inside the critical section as below, but the program
> didn't go to the abort handler, either.
> sigint_case.c
>> #define _GNU_SOURCE
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> static __thread volatile struct rseq __rseq_abi;
>> #define RSEQ_SIG 0x53053053
>> static int sys_rseq ( volatile struct rseq * rseq_abi , uint32_t rseq_len ,
>> int flags , uint32_t sig ) {
>> return syscall (__NR_rseq, rseq_abi, rseq_len, flags, sig);
>> }
>> static void register_thread ( void ) {
>> int rc;
>> rc = sys_rseq (&__rseq_abi, sizeof ( struct rseq), 0 , RSEQ_SIG);
>> if (rc) {
>> fprintf (stderr, "Failed to register rseq \n " );
>> exit ( 1 );
>> }
>> }
>> #define RSEQ_ACCESS_ONCE( x ) ( * (__volatile__ __typeof__ (x) * ) & (x))
>> int do_test ( int cpu ) {
>> __asm__ __volatile__ goto (
>> ".pushsection __rseq_table, \" aw \"\n\t "
>> ".balign 32 \n\t "
>> "cs_obj: \n\t "
>> ".int 0, 0 \n\t "
>> /* start_ip, post_commit_offset, abort_ip */
>> ".quad 1f, 2f - 1f, 4f \n\t "
>> ".popsection \n\t "
>> "1: \n\t "
>> "leaq cs_obj(%%rip), %%rax \n\t "
>> "movq %%rax, % [rseq_cs] \n\t "
>> "cmpl % [cpu_id], % [current_cpu_id] \n\t "
>> "jnz 4f \n\t "
>> /* enable signal testing */
>> "movq $5, %%rdi \n\t "
>> "call sleep@plt \n\t "
>> /*/
>> "jmp % l[committed] \n\t "
>> "2: \n\t "
>> /* Disassembler-friendly signature: nopl (%rip). */
>> ".byte 0x0f, 0x1f, 0x05 \n\t "
>> ".long 0x53053053 \n\t " /* RSEQ_SIG */
>> "4: \n\t "
>> "jmp % l[aborted] \n\t "
>> : /* no outputs */
>> : [cpu_id] "r" (cpu),
>> [current_cpu_id] "m" ( __rseq_abi . cpu_id ),
>> [rseq_cs] "m" ( __rseq_abi . rseq_cs )
>> : "memory" , "cc" , "rax"
>> : aborted, committed
>> );
>> committed:
>> printf ( "committed \n " );
>> return 0 ;
>> aborted:
>> printf ( "aborted \n " );
>> return - 1 ;
>> }
>> void signal_callback_handler ( int signum ) {
>> printf ( "Caught signal %d \n " , signum);
>> }
>> int main ( int argc , char ** argv ) {
>> signal (SIGINT,
Re: [PATCH v7 clocksource 5/5] clocksource: Do pairwise clock-desynchronization checking
On Sat, Apr 10, 2021 at 11:04:54AM +0200, Thomas Gleixner wrote: > On Fri, Apr 02 2021 at 15:49, paulmck wrote: > > From: "Paul E. McKenney" > > > > Although smp_call_function() has the advantage of simplicity, using > > it to check for cross-CPU clock desynchronization means that any CPU > > being slow reduces the sensitivity of the checking across all CPUs. > > And it is not uncommon for smp_call_function() latencies to be in the > > hundreds of microseconds. > > > > This commit therefore switches to smp_call_function_single(), so that > > delays from a given CPU affect only those measurements involving that > > particular CPU. > > Is there any reason I'm missing why this is not done right in patch 3/5 > which introduces this synchronization check? None at all. I will merge this into 3/5. Thanx, Paul
Re: [PATCH v7 clocksource 3/5] clocksource: Check per-CPU clock synchronization when marked unstable
On Sat, Apr 10, 2021 at 11:00:25AM +0200, Thomas Gleixner wrote:
> On Fri, Apr 02 2021 at 15:49, paulmck wrote:
> >
> > +static void clocksource_verify_percpu_wq(struct work_struct *unused)
> > +{
> > + int cpu;
> > + struct clocksource *cs;
> > + int64_t cs_nsec;
> > + u64 csnow_begin;
> > + u64 csnow_end;
> > + u64 delta;
>
> Please use reverse fir tree ordering and stick variables of the same
> type together:
>
> u64 csnow_begin, csnow_end, delta;
> struct clocksource *cs;
> s64 cs_nsec;
> int cpu;
Will do.
> > +
> > + cs = smp_load_acquire(_verify_work_cs); // pairs with
> > release
>
> Please don't use tail comments. They are a horrible distraction.
I will remove it.
> > + if (WARN_ON_ONCE(!cs))
> > + return;
> > + pr_warn("Checking clocksource %s synchronization from CPU %d.\n",
> > + cs->name, smp_processor_id());
> > + cpumask_clear(_ahead);
> > + cpumask_clear(_behind);
> > + csnow_begin = cs->read(cs);
>
> So this is invoked via work and the actual clocksource change is done
> via work too. Once the clocksource is not longer actively used for
> timekeeping it can go away. What's guaranteeing that this runs prior to
> the clocksource change and 'cs' is valid throughout this function?
>From what I can see, cs->read() doesn't care whether or not the
clocksource has been marked unstable. So it should be OK to call
cs->read() before, during, or after the call to __clocksource_unstable().
Also, this is only done on clocksources marked CLOCK_SOURCE_VERIFY_PERCPU,
so any clocksource that did not like cs->read() being invoked during
or after the call to __clocksource_unstable() should leave off the
CLOCK_SOURCE_VERIFY_PERCPU bit.
Or did I take a wrong turn somewhere in the pointers to functions?
> > + queue_work(system_highpri_wq, _verify_work);
>
> This does not guarantee anything. So why does this need an extra work
> function which is scheduled seperately?
Because I was concerned about doing smp_call_function() while holding
watchdog_lock, which is also acquired elsewhere using spin_lock_irqsave().
And it still looks like on x86 that spin_lock_irqsave() spins with irqs
disabled, which could result in deadlock. The smp_call_function_single()
would wait for the target CPU to enable interrupts, which would not
happen until after the smp_call_function_single() returned due to its
caller holding watchdog_lock.
Or is there something that I am missing that prevents this deadlock
from occurring?
Thanx, Paul
arch/csky/kernel/module.c:43:1: warning: 'inline' is not at beginning of declaration
Hi Julian,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 52e44129fba5cfc4e351fdb5e45849afc74d9a53
commit: 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 lib: fix kconfig dependency on
ARCH_WANT_FRAME_POINTERS
date: 26 hours ago
config: csky-randconfig-r013-20210411 (attached as .config)
compiler: csky-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=csky
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> arch/csky/kernel/module.c:43:1: warning: 'inline' is not at beginning of
>> declaration [-Wold-style-declaration]
43 | static void inline jsri_2_lrw_jsr(uint32_t *location)
| ^~
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for LOCKDEP
Depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && (FRAME_POINTER || MIPS
|| PPC || S390 || MICROBLAZE || ARM || ARC || X86)
Selected by
- LOCK_STAT && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
- DEBUG_LOCK_ALLOC && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
vim +/inline +43 arch/csky/kernel/module.c
f553aa1c13cbc2 Guo Ren 2019-01-08 27
f553aa1c13cbc2 Guo Ren 2019-01-08 28 static void jsri_2_lrw_jsr(uint32_t
*location)
f553aa1c13cbc2 Guo Ren 2019-01-08 29 {
70c25259537c07 Guo Ren 2019-01-10 30 uint16_t *location_tmp = (uint16_t
*)location;
f553aa1c13cbc2 Guo Ren 2019-01-08 31
f553aa1c13cbc2 Guo Ren 2019-01-08 32 if (IS_BSR32(*location_tmp,
*(location_tmp + 1)))
f553aa1c13cbc2 Guo Ren 2019-01-08 33 return;
f553aa1c13cbc2 Guo Ren 2019-01-08 34
f553aa1c13cbc2 Guo Ren 2019-01-08 35 if (IS_JSRI32(*location_tmp,
*(location_tmp + 1))) {
f553aa1c13cbc2 Guo Ren 2019-01-08 36 /* jsri 0x... --> lrw r26,
0x... */
f553aa1c13cbc2 Guo Ren 2019-01-08 37 CHANGE_JSRI_TO_LRW(location);
f553aa1c13cbc2 Guo Ren 2019-01-08 38 /* lsli r0, r0 --> jsr r26 */
f553aa1c13cbc2 Guo Ren 2019-01-08 39 SET_JSR32_R26(location + 1);
f553aa1c13cbc2 Guo Ren 2019-01-08 40 }
f553aa1c13cbc2 Guo Ren 2019-01-08 41 }
f553aa1c13cbc2 Guo Ren 2019-01-08 42 #else
f553aa1c13cbc2 Guo Ren 2019-01-08 @43 static void inline
jsri_2_lrw_jsr(uint32_t *location)
f553aa1c13cbc2 Guo Ren 2019-01-08 44 {
f553aa1c13cbc2 Guo Ren 2019-01-08 45 return;
f553aa1c13cbc2 Guo Ren 2019-01-08 46 }
9d056df0924edb Guo Ren 2018-09-05 47 #endif
9d056df0924edb Guo Ren 2018-09-05 48
:: The code at line 43 was first introduced by commit
:: f553aa1c13cbc29aaf420349a28fc33ca98440e5 csky: fixup relocation error
with 807 & 860
:: TO: Guo Ren
:: CC: Guo Ren
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
drivers/bus/mhi/core/pm.c:740:6: warning: stack frame size of 1408 bytes in function 'mhi_pm_st_worker'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 52e44129fba5cfc4e351fdb5e45849afc74d9a53
commit: 556bbb442bbb44f429dbaa9f8b48e0b4cda6e088 bus: mhi: core: Separate
system error and power down handling
date: 5 months ago
config: powerpc-randconfig-r024-20210411 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
dd453a1389b6a7e6d9214b449d3c54981b1a89b6)
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
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=556bbb442bbb44f429dbaa9f8b48e0b4cda6e088
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 556bbb442bbb44f429dbaa9f8b48e0b4cda6e088
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/bus/mhi/core/pm.c:740:6: warning: stack frame size of 1408 bytes in
>> function 'mhi_pm_st_worker' [-Wframe-larger-than=]
void mhi_pm_st_worker(struct work_struct *work)
^
1 warning generated.
vim +/mhi_pm_st_worker +740 drivers/bus/mhi/core/pm.c
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 738
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 739 /* Device State
Transition worker */
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 @740 void
mhi_pm_st_worker(struct work_struct *work)
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 741 {
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 742struct state_transition
*itr, *tmp;
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 743LIST_HEAD(head);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 744struct mhi_controller
*mhi_cntrl = container_of(work,
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 745
struct mhi_controller,
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 746
st_worker);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 747struct device *dev =
_cntrl->mhi_dev->dev;
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 748
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 749
spin_lock_irq(_cntrl->transition_lock);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 750
list_splice_tail_init(_cntrl->transition_list, );
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 751
spin_unlock_irq(_cntrl->transition_lock);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 752
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 753
list_for_each_entry_safe(itr, tmp, , node) {
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 754
list_del(>node);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 755dev_dbg(dev,
"Handling state transition: %s\n",
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 756
TO_DEV_STATE_TRANS_STR(itr->state));
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 757
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 758switch
(itr->state) {
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 759case
DEV_ST_TRANSITION_PBL:
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 760
write_lock_irq(_cntrl->pm_lock);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 761if
(MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state))
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 762
mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 763
write_unlock_irq(_cntrl->pm_lock);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 764if
(MHI_IN_PBL(mhi_cntrl->ee))
560e3a045961ed Bhaumik Bhatt 2020-05-21 765
mhi_fw_load_handler(mhi_cntrl);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 766break;
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 767case
DEV_ST_TRANSITION_SBL:
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 768
write_lock_irq(_cntrl->pm_lock);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 769
mhi_cntrl->ee = MHI_EE_SBL;
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 770
write_unlock_irq(_cntrl->pm_lock);
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 771/*
a6e2e3522f2914 Manivannan Sadhasivam 2020-02-20 772 * The
MHI devices are only created when the client
a6e2e3522f2914 Manivannan Sadhasivam
[PATCH] ia64: fix discontig.c section mismatches
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked
as __meminit because they are needed after init, on any memory
hotplug event. Also, early_nr_cpus_node() is called by
compute_pernodesize(), so early_nr_cpus_node() cannot be __meminit either.
WARNING: modpost: vmlinux.o(.text.unlikely+0x1612): Section mismatch in
reference from the function arch_alloc_nodedata() to the function
.meminit.text:compute_pernodesize()
The function arch_alloc_nodedata() references
the function __meminit compute_pernodesize().
This is often because arch_alloc_nodedata lacks a __meminit
annotation or the annotation of compute_pernodesize is wrong.
WARNING: modpost: vmlinux.o(.text.unlikely+0x1692): Section mismatch in
reference from the function arch_refresh_nodedata() to the function
.meminit.text:scatter_node_data()
The function arch_refresh_nodedata() references
the function __meminit scatter_node_data().
This is often because arch_refresh_nodedata lacks a __meminit
annotation or the annotation of scatter_node_data is wrong.
WARNING: modpost: vmlinux.o(.text.unlikely+0x1502): Section mismatch in
reference from the function compute_pernodesize() to the function
.meminit.text:early_nr_cpus_node()
The function compute_pernodesize() references
the function __meminit early_nr_cpus_node().
This is often because compute_pernodesize lacks a __meminit
annotation or the annotation of early_nr_cpus_node is wrong.
Signed-off-by: Randy Dunlap
Cc: Mike Rapoport
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-i...@vger.kernel.org
---
arch/ia64/mm/discontig.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-next-20210409.orig/arch/ia64/mm/discontig.c
+++ linux-next-20210409/arch/ia64/mm/discontig.c
@@ -95,7 +95,7 @@ static int __init build_node_maps(unsign
* acpi_boot_init() (which builds the node_to_cpu_mask array) hasn't been
* called yet. Note that node 0 will also count all non-existent cpus.
*/
-static int __meminit early_nr_cpus_node(int node)
+static int early_nr_cpus_node(int node)
{
int cpu, n = 0;
@@ -110,7 +110,7 @@ static int __meminit early_nr_cpus_node(
* compute_pernodesize - compute size of pernode data
* @node: the node id.
*/
-static unsigned long __meminit compute_pernodesize(int node)
+static unsigned long compute_pernodesize(int node)
{
unsigned long pernodesize = 0, cpus;
@@ -367,7 +367,7 @@ static void __init reserve_pernode_space
}
}
-static void __meminit scatter_node_data(void)
+static void scatter_node_data(void)
{
pg_data_t **dst;
int node;
Re: linux-next: Tree for Apr 9 (drivers/iommu/intel/pasid.c)
On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210408:
>
> New trees: iio, iio-fixes
>
on ia64: (not X86)
(from a 01.org kernel config file)
../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe':
../drivers/iommu/intel/pasid.c:554:22: error: implicit declaration of function
'read_cr0' [-Werror=implicit-function-declaration]
554 | unsigned long cr0 = read_cr0();
| ^~~~
In file included from ../include/linux/build_bug.h:5,
from ../include/linux/bits.h:22,
from ../include/linux/bitops.h:6,
from ../drivers/iommu/intel/pasid.c:12:
../drivers/iommu/intel/pasid.c:557:23: error: 'X86_CR0_WP' undeclared (first
use in this function)
557 | if (unlikely(!(cr0 & X86_CR0_WP))) {
| ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
../drivers/iommu/intel/pasid.c:557:23: note: each undeclared identifier is
reported only once for each function it appears in
557 | if (unlikely(!(cr0 & X86_CR0_WP))) {
| ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
--
~Randy
Reported-by: Randy Dunlap
Re: [PATCH v7 clocksource 2/5] clocksource: Retry clock read if long delays detected
On Sat, Apr 10, 2021 at 10:41:21AM +0200, Thomas Gleixner wrote:
> On Fri, Apr 02 2021 at 15:49, paulmck wrote:
> > This commit therefore re-reads the watchdog clock on either side of
>
> 'This commit' is not any better than 'This patch' and this sentence
> makes no sense. I might be missing something, but how exactly does "the
> commit" re-read the watchdog clock?
>
> git grep 'This patch' Documentation/process/
I will rework this.
> > the read from the clock under test. If the watchdog clock shows an
> > +retry:
> > local_irq_disable();
> > - csnow = cs->read(cs);
> > - clocksource_watchdog_inject_delay();
> > wdnow = watchdog->read(watchdog);
> > + clocksource_watchdog_inject_delay();
> > + csnow = cs->read(cs);
> > + wdagain = watchdog->read(watchdog);
> > local_irq_enable();
> > + delta = clocksource_delta(wdagain, wdnow, watchdog->mask);
> > + wdagain_nsec = clocksource_cyc2ns(delta, watchdog->mult,
> > watchdog->shift);
>
> That variable naming is confusing as hell. This is about the delta and
> not about the second readout of the watchdog.
How about wdagain_delta?
> > + if (wdagain_nsec < 0 || wdagain_nsec > WATCHDOG_MAX_SKEW) {
>
> How exactly is this going negative especially with clocksources which
> have a limited bitwidth? See clocksource_delta().
I thought that I had actually seen this happen, though it is of course
quite possible that it was due to a bug in an early version of my changes.
What I will do is to remove the less-than comparison and test with
a WARN_ON(). If that doesn't trigger, I will drop the WARN_ON().
If it does trigger, I will figure out why.
> > + wderr_nsec = wdagain_nsec;
> > + if (nretries++ < max_read_retries)
> > + goto retry;
> > + }
> > + if (nretries)
> > + pr_warn("timekeeping watchdog on CPU%d: %s read-back
> > delay of %lldns, attempt %d\n",
> > + smp_processor_id(), watchdog->name, wderr_nsec,
> > nretries);
>
> Lacks curly braces around the pr_warn() simply because it's not a single
> line. Breaks my parser :)
OK, will fix. ;-)
> But if this ever happens to exceed max_read_retries, then what's the
> point of continuing at all? The data is known to be crap already.
If there are four delays in four consecutive attempts to read out the
clocks -- with interrupts disabled -- then it is quite possible that the
delay is actually caused by the attempt to read the clock. In which case,
marking the clock bad due to skew is a reasonable choice.
On the other hand, if the four consecutive delays are caused by something
like an NMI storm, then as you say, you have worse problems.
Thanx, Paul
> > /* Clocksource initialized ? */
> > if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) ||
>
> Thanks,
>
> tglx
[tip:irq/core] BUILD SUCCESS 7c07012eb1be8b4a95d3502fd30795849007a40e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core branch HEAD: 7c07012eb1be8b4a95d3502fd30795849007a40e genirq: Reduce irqdebug cacheline bouncing elapsed time: 722m configs tested: 119 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig sh sh7724_generic_defconfig xtensaxip_kc705_defconfig powerpc ppc64e_defconfig armhisi_defconfig xtensa iss_defconfig powerpc tqm8xx_defconfig openrisc alldefconfig armmmp2_defconfig um i386_defconfig mipsworkpad_defconfig nds32 defconfig mips bmips_be_defconfig shshmin_defconfig armmulti_v7_defconfig armshmobile_defconfig arm s3c6400_defconfig arm s3c2410_defconfig ia64zx1_defconfig m68kstmark2_defconfig arm shannon_defconfig mipsmalta_kvm_guest_defconfig sh se7751_defconfig armmulti_v5_defconfig sh se7619_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20210411 x86_64 randconfig-a002-20210411 x86_64 randconfig-a001-20210411 x86_64 randconfig-a005-20210411 x86_64 randconfig-a006-20210411 x86_64 randconfig-a004-20210411 i386 randconfig-a003-20210411 i386 randconfig-a001-20210411 i386 randconfig-a006-20210411 i386 randconfig-a005-20210411 i386 randconfig-a004-20210411 i386 randconfig-a002-20210411 i386 randconfig-a006-20210409 i386 randconfig-a003-20210409 i386 randconfig-a001-20210409 i386 randconfig-a004-20210409 i386 randconfig-a002-20210409 i386 randconfig-a005-20210409 x86_64 randconfig-a014-20210410 x86_64 randconfig-a015-20210410 x86_64 randconfig-a011-20210410 x86_64 randconfig-a013-20210410 x86_64 randconfig-a012-20210410 x86_64 randconfig-a016-20210410 i386 randconfig-a015-20210410 i386 randconfig-a014-20210410 i386 randconfig-a013-20210410 i386 randconfig-a012-20210410 i386 randconfig-a016-20210410 i386 randconfig-a011-20210410 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um
Re: [PATCH 08/10] powerpc/signal32: Convert restore_[tm]_user_regs() to user access block
On Fri, Mar 19, 2021 at 11:06:57AM +, Christophe Leroy wrote:
> Convert restore_user_regs() and restore_tm_user_regs()
> to use user_access_read_begin/end blocks.
>
> Signed-off-by: Christophe Leroy
> ---
...
> static long restore_user_regs(struct pt_regs *regs,
> struct mcontext __user *sr, int sig)
> {
...
> @@ -567,19 +569,22 @@ static long restore_user_regs(struct pt_regs *regs,
> regs->msr &= ~MSR_SPE;
> if (msr & MSR_SPE) {
> /* restore spe registers from the stack */
> - if (__copy_from_user(current->thread.evr, >mc_vregs,
> - ELF_NEVRREG * sizeof(u32)))
> - return 1;
> + unsafe_copy_from_user(current->thread.evr, >mc_vregs,
> + ELF_NEVRREG * sizeof(u32));
arch/powerpc/kernel/signal_32.c: In function 'restore_user_regs':
arch/powerpc/kernel/signal_32.c:565:36: error: macro "unsafe_copy_from_user"
requires 4 arguments, but only 3 given
Guenter
Re: [PATCH] net: core: sk_buff: zero-fill skb->data in __alloc_skb function
On Sat, Apr 10, 2021 at 01:00:34PM +0200, Eric Dumazet wrote: > On Sat, Apr 10, 2021 at 12:12 PM Eric Dumazet wrote: > > > > On Sat, Apr 10, 2021 at 11:51 AM Phillip Potter > > wrote: > > > > > > Zero-fill skb->data in __alloc_skb function of net/core/skbuff.c, > > > up to start of struct skb_shared_info bytes. Fixes a KMSAN-found > > > uninit-value bug reported by syzbot at: > > > https://syzkaller.appspot.com/bug?id=abe95dc3e3e9667fc23b8d81f29ecad95c6f106f > > > > > > Reported-by: syzbot+2e406a9ac75bb71d4...@syzkaller.appspotmail.com > > > Signed-off-by: Phillip Potter > > > --- > > > net/core/skbuff.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > > > index 785daff48030..9ac26cdb5417 100644 > > > --- a/net/core/skbuff.c > > > +++ b/net/core/skbuff.c > > > @@ -215,6 +215,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t > > > gfp_mask, > > > * to allow max possible filling before reallocation. > > > */ > > > size = SKB_WITH_OVERHEAD(ksize(data)); > > > + memset(data, 0, size); > > > prefetchw(data + size); > > > > > > Certainly not. > > > > There is a difference between kmalloc() and kzalloc() > > > > Here you are basically silencing KMSAN and make it useless. > > > > Please fix the real issue, or stop using KMSAN if it bothers you. > > My understanding of the KMSAN bug (when I released it months ago) was > that it was triggered by some invalid assumptions in geneve_xmit() > > The syzbot repro sends a packet with a very small size (Ethernet > header only) and no IP/IPv6 header > > Fix for ipv4 part (sorry, not much time during week end to test all this) > > diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c > index > e3b2375ac5eb55f544bbc1f309886cc9be189fd1..0a72779bc74bc50c20c34c05b2c525cca829f33c > 100644 > --- a/drivers/net/geneve.c > +++ b/drivers/net/geneve.c > @@ -892,6 +892,9 @@ static int geneve_xmit_skb(struct sk_buff *skb, > struct net_device *dev, > __be16 sport; > int err; > > + if (!pskb_network_may_pull(skb, sizeof(struct iphdr)) > + return -EINVAL; > + > sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true); > rt = geneve_get_v4_rt(skb, dev, gs4, , info, > geneve->cfg.info.key.tp_dst, sport); Dear Eric, Thank you for your help/feedback. I have crafted a patch using your code above and the equivalent check for geneve6_xmit_skb, and this works for me on my local KMSAN build. I am also running it through syzbot to check there as well. I will send out with appropriate attribution assuming all is OK on the testing front. Regards, Phil
Re: [PATCH v7 clocksource] Do not mark clocks unstable due to delays for v5.13
On Sat, Apr 10, 2021 at 10:01:58AM +0200, Thomas Gleixner wrote: > On Fri, Apr 02 2021 at 15:48, Paul E. McKenney wrote: > > Hello! > > > > If there is a sufficient delay between reading the watchdog clock and the > > clock under test, the clock under test will be marked unstable through no > > fault of its own. This series checks for this, doing limited retries > > to get a good set of clock reads. If the clock is marked unstable > > and is marked as being per-CPU, cross-CPU synchronization is checked. > > This series also provides delay injection, which may be enabled via > > kernel boot parameters to test the checking for delays. > > > > Note that "sufficient delay" can be provided by SMIs, NMIs, and of course > > vCPU preemption. > > I buy the vCPU preemption part and TBH guests should not have that > watchdog thing active at all for exactly this reason. Agreed, one approch is to enable the the clocksource watchdog only in the hypervisor, and have some action on the guests triggered when the host detects clock skew. This works quite well, at least until something breaks in a way that messes up clock reads from the guest but not from the host. And I am sure that any number of hardware guys will tell me that this just isn't possible, but if failing hardware operated according to their expectations, that hardware wouldn't be considered to be failing. Or it wouldn't be hardware, firmware, or clock-driver bringup, as the case may be. > SMI, NMI injecting 62.5ms delay? If that happens then the performance of > the clocksource is the least of your worries. I was kind of hoping that you would tell me why the skew must be all the way up to 62.5ms before the clock is disabled. The watchdog currently is quite happy with more than 10% skew between clocks. 100HZ clocks or some such? Thanx, Paul
Re: [RFC] mm: activate access-more-than-once page via NUMA balancing
On Fri, Mar 26, 2021 at 12:21 AM Huang, Ying wrote: > > Mel Gorman writes: > > > On Thu, Mar 25, 2021 at 12:33:45PM +0800, Huang, Ying wrote: > >> > I caution against this patch. > >> > > >> > It's non-deterministic for a number of reasons. As it requires NUMA > >> > balancing to be enabled, the pageout behaviour of a system changes when > >> > NUMA balancing is active. If this led to pages being artificially and > >> > inappropriately preserved, NUMA balancing could be disabled for the > >> > wrong reasons. It only applies to pages that have no target node so > >> > memory policies affect which pages are activated differently. Similarly, > >> > NUMA balancing does not scan all VMAs and some pages may never trap a > >> > NUMA fault as a result. The timing of when an address space gets scanned > >> > is driven by the locality of pages and so the timing of page activation > >> > potentially becomes linked to whether pages are local or need to migrate > >> > (although not right now for this patch as it only affects pages with a > >> > target nid of NUMA_NO_NODE). In other words, changes in NUMA balancing > >> > that affect migration potentially affect the aging rate. Similarly, > >> > the activate rate of a process with a single thread and multiple threads > >> > potentially have different activation rates. > >> > > >> > Finally, the NUMA balancing scan algorithm is sub-optimal. It potentially > >> > scans the entire address space even though only a small number of pages > >> > are scanned. This is particularly problematic when a process has a lot > >> > of threads because threads are redundantly scanning the same regions. If > >> > NUMA balancing ever introduced range tracking of faulted pages to limit > >> > how much scanning it has to do, it would inadvertently cause a change in > >> > page activation rate. > >> > > >> > NUMA balancing is about page locality, it should not get conflated with > >> > page aging. > >> > >> I understand your concerns about binding the NUMA balancing and page > >> reclaiming. The requirement of the page locality and page aging is > >> different, so the policies need to be different. This is the wrong part > >> of the patch. > >> > >> From another point of view, it's still possible to share some underlying > >> mechanisms (and code) between them. That is, scanning the page tables > >> to make pages unaccessible and capture the page accesses via the page > >> fault. > > > > Potentially yes but not necessarily recommended for page aging. NUMA > > balancing has to be careful about the rate it scans pages to avoid > > excessive overhead so it's driven by locality. The scanning happens > > within a tasks context so during that time, the task is not executing > > its normal work and it incurs the overhead for faults. Generally, this > > is not too much overhead because pages get migrated locally, the scan > > rate drops and so does the overhead. > > > > However, if you want to drive page aging, that is constant so the rate > > could not be easily adapted in a way that would be deterministic. > > > >> Now these page accessing information is used for the page > >> locality. Do you think it's a good idea to use these information for > >> the page aging too (but with a different policy as you pointed out)? > >> > > > > I'm not completely opposed to it but I think the overhead it would > > introduce could be severe. Worse, if a workload fits in memory and there > > is limited to no memory pressure, it's all overhead for no gain. Early > > generations of NUMA balancing had to find a balance to sure the gains > > from locality exceeded the cost of measuring locality and doing the same > > for page aging in some ways is even more challenging. > > Yes. I will think more about it from the overhead vs. gain point of > view. Thanks a lot for your sharing on that. > > >> From yet another point of view :-), in current NUMA balancing > >> implementation, it's assumed that the node private pages can fit in the > >> accessing node. But this may be not always true. Is it a valid > >> optimization to migrate the hot private pages first? > >> > > > > I'm not sure how the hotness of pages could be ranked. At the time of a > > hinting fault, the page is by definition active now because it was been > > accessed. Prioritising what pages to migrate based on the number of faults > > that have been trapped would have to be stored somewhere. > > Yes. We need to store some information about that. In an old version > of the patchset which uses NUMA balancing to promote hot pages from the > PMEM to DRAM, we have designed a method to measure the hotness of the > pages. The basic idea is as follows, > > - When the page table of a process is scanned, the latest N scanning > address ranges and scan times are recorded in a ring buffer of > mm_struct. > > - In hint page fault handler, the ring buffer is search with the fault > address, to get the scan time. > > Then the hint page fault latency of
drivers/media/platform/omap/omap_vout.c:979:37: warning: cast to pointer from integer of different size
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 52e44129fba5cfc4e351fdb5e45849afc74d9a53
commit: a19f228b8dd9a67e8de4ebd4eac8a4c94ec39d1a media: Kconfig: not all V4L2
platform drivers are for camera
date: 12 months ago
config: arc-randconfig-r025-20210411 (attached as .config)
compiler: arceb-elf-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a19f228b8dd9a67e8de4ebd4eac8a4c94ec39d1a
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout a19f228b8dd9a67e8de4ebd4eac8a4c94ec39d1a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/media/platform/omap/omap_vout.c: In function 'omap_vout_vb2_prepare':
>> drivers/media/platform/omap/omap_vout.c:979:37: warning: cast to pointer
>> from integer of different size [-Wint-to-pointer-cast]
979 | vout->queued_buf_addr[vb->index] = (u8 *)buf_phy_addr;
| ^
drivers/media/platform/omap/omap_vout.c: In function
'omap_vout_create_video_devices':
drivers/media/platform/omap/omap_vout.c:1479:21: warning: cast to pointer
from integer of different size [-Wint-to-pointer-cast]
1479 | vout->fbuf.base = (void *)info.paddr;
| ^
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for VIDEO_OV7670
Depends on MEDIA_SUPPORT && MEDIA_CAMERA_SUPPORT && I2C && VIDEO_V4L2
Selected by
- VIDEO_CAFE_CCIC && MEDIA_SUPPORT && MEDIA_PLATFORM_SUPPORT &&
V4L_PLATFORM_DRIVERS && PCI && I2C && VIDEO_V4L2 && COMMON_CLK
- VIDEO_MMP_CAMERA && MEDIA_SUPPORT && MEDIA_PLATFORM_SUPPORT &&
V4L_PLATFORM_DRIVERS && I2C && VIDEO_V4L2 && (ARCH_MMP || COMPILE_TEST &&
COMMON_CLK
vim +979 drivers/media/platform/omap/omap_vout.c
5c7ab6348e7b3f drivers/media/video/omap/omap_vout.cVaibhav Hiremath
2010-04-11 961
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 962 static int omap_vout_vb2_prepare(struct vb2_buffer *vb)
5c7ab6348e7b3f drivers/media/video/omap/omap_vout.cVaibhav Hiremath
2010-04-11 963 {
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 964 struct omap_vout_device *vout =
vb2_get_drv_priv(vb->vb2_queue);
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 965 struct omapvideo_info *ovid = >vid_info;
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 966 struct omap_vout_buffer *voutbuf =
vb2_to_omap_vout_buffer(vb);
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 967 dma_addr_t buf_phy_addr =
vb2_dma_contig_plane_dma_addr(vb, 0);
5c7ab6348e7b3f drivers/media/video/omap/omap_vout.cVaibhav Hiremath
2010-04-11 968
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 969 if (vb2_plane_size(vb, 0) < vout->pix.sizeimage) {
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 970 v4l2_dbg(1, debug, >vid_dev->v4l2_dev,
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 971 "%s data will not fit into plane (%lu
< %u)\n",
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 972 __func__, vb2_plane_size(vb, 0),
vout->pix.sizeimage);
5c7ab6348e7b3f drivers/media/video/omap/omap_vout.cVaibhav Hiremath
2010-04-11 973 return -EINVAL;
5c7ab6348e7b3f drivers/media/video/omap/omap_vout.cVaibhav Hiremath
2010-04-11 974 }
5c7ab6348e7b3f drivers/media/video/omap/omap_vout.cVaibhav Hiremath
2010-04-11 975
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 976 vb2_set_plane_payload(vb, 0, vout->pix.sizeimage);
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 977 voutbuf->vbuf.field = V4L2_FIELD_NONE;
5c7ab6348e7b3f drivers/media/video/omap/omap_vout.cVaibhav Hiremath
2010-04-11 978
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 @979 vout->queued_buf_addr[vb->index] = (u8 *)buf_phy_addr;
256acbebdc3b2d drivers/media/platform/omap/omap_vout.c Hans Verkuil
2019-07-30 980 if (ovid->rotation_type == VOUT_ROT_VRFB)
256acbebdc3b2d
Re: [PATCH v4 08/11] pinctrl: Ingenic: Add pinctrl driver for JZ4750.
Hi "周琰杰,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pinctrl/devel]
[also build test ERROR on robh/for-next linus/master v5.12-rc6 next-20210409]
[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/Zhou-Yanjie/Fix-bugs-and-add-support-for-new-Ingenic-SoCs/20210411-025656
base:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: sh-allmodconfig (attached as .config)
compiler: sh4-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/76f684ad7bcc8b973c1a622beb0c12cf13e7ba10
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Zhou-Yanjie/Fix-bugs-and-add-support-for-new-Ingenic-SoCs/20210411-025656
git checkout 76f684ad7bcc8b973c1a622beb0c12cf13e7ba10
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Note: the
linux-review/Zhou-Yanjie/Fix-bugs-and-add-support-for-new-Ingenic-SoCs/20210411-025656
HEAD f620590a49d7d82d9e111928ccb3d435768a62e4 builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
>> drivers/pinctrl/pinctrl-ingenic.c:2882:3: error: field name not in record or
>> union initializer
2882 | .compatible = "ingenic,jz4760-pinctrl",
| ^
drivers/pinctrl/pinctrl-ingenic.c:2882:3: note: (near initialization for
'ingenic_pinctrl_of_match')
drivers/pinctrl/pinctrl-ingenic.c:2883:3: error: field name not in record or
union initializer
2883 | .data = IF_ENABLED(CONFIG_MACH_JZ4760, _chip_info)
| ^
drivers/pinctrl/pinctrl-ingenic.c:2883:3: note: (near initialization for
'ingenic_pinctrl_of_match')
In file included from :
>> include/linux/kconfig.h:79:33: warning: initialization of 'char' from 'const
>> struct ingenic_chip_info *' makes integer from pointer without a cast
>> [-Wint-conversion]
79 | #define IF_ENABLED(option, ptr) (IS_ENABLED(option) ? (ptr) : NULL)
| ^
drivers/pinctrl/pinctrl-ingenic.c:2883:11: note: in expansion of macro
'IF_ENABLED'
2883 | .data = IF_ENABLED(CONFIG_MACH_JZ4760, _chip_info)
| ^~
include/linux/kconfig.h:79:33: note: (near initialization for
'ingenic_pinctrl_of_match[5].name[0]')
79 | #define IF_ENABLED(option, ptr) (IS_ENABLED(option) ? (ptr) : NULL)
| ^
drivers/pinctrl/pinctrl-ingenic.c:2883:11: note: in expansion of macro
'IF_ENABLED'
2883 | .data = IF_ENABLED(CONFIG_MACH_JZ4760, _chip_info)
| ^~
>> drivers/pinctrl/pinctrl-ingenic.c:2865:63: warning: missing braces around
>> initializer [-Wmissing-braces]
2865 | static const struct of_device_id ingenic_pinctrl_of_match[] = {
| ^
>> drivers/pinctrl/pinctrl-ingenic.c:2885:2: error: expected identifier or '('
>> before '{' token
2885 | {
| ^
drivers/pinctrl/pinctrl-ingenic.c:2888:3: error: expected identifier or '('
before ',' token
2888 | },
| ^
drivers/pinctrl/pinctrl-ingenic.c:2892:3: error: expected identifier or '('
before ',' token
2892 | },
| ^
drivers/pinctrl/pinctrl-ingenic.c:2896:3: error: expected identifier or '('
before ',' token
2896 | },
| ^
drivers/pinctrl/pinctrl-ingenic.c:2900:3: error: expected identifier or '('
before ',' token
2900 | },
| ^
drivers/pinctrl/pinctrl-ingenic.c:2904:3: error: expected identifier or '('
before ',' token
2904 | },
| ^
drivers/pinctrl/pinctrl-ingenic.c:2908:3: error: expected identifier or '('
before ',' token
2908 | },
| ^
drivers/pinctrl/pinctrl-ingenic.c:2912:3: error: expected identifier or '('
before ',' token
2912 | },
| ^
drivers/pinctrl/pinctrl-ingenic.c:2913:20: error: expected identifier or '('
before ',' token
2913 | { /* sentinel */ },
|^
drivers/pinctrl/pinctrl-ingenic.c:1901:39: warning: 'x1830_chip_info'
defined but not used [-Wunused-const-variable=]
1901 | static const struct ingenic_chip_info x1830_chip_info = {
| ^~~
drivers/pinctrl/pinctrl-ingenic.c:1695:39: warning: 'x1500_chip_info'
defined but not used [-Wunused-const-variable=]
1695 | static const struct
Re: [PATCH v2] USB:ohci:fix ohci interruption problem
Hi Longfang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v5.12-rc6 next-20210409]
[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/Longfang-Liu/USB-ohci-fix-ohci-interruption-problem/20210409-155150
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: i386-randconfig-a012-20210411 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/fa57a31f84453b32378ba3d1410e7a549b5d397d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Longfang-Liu/USB-ohci-fix-ohci-interruption-problem/20210409-155150
git checkout fa57a31f84453b32378ba3d1410e7a549b5d397d
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/usb/core/hcd-pci.c:624:13: error: 'hcd_pci_freeze' undeclared here
>> (not in a function); did you mean 'hcd_pci_resume'?
624 | .freeze = hcd_pci_freeze,
| ^~
| hcd_pci_resume
vim +624 drivers/usb/core/hcd-pci.c
618
619 const struct dev_pm_ops usb_hcd_pci_pm_ops = {
620 .suspend= hcd_pci_suspend,
621 .suspend_noirq = hcd_pci_suspend_noirq,
622 .resume_noirq = hcd_pci_resume_noirq,
623 .resume = hcd_pci_resume,
> 624 .freeze = hcd_pci_freeze,
625 .freeze_noirq = check_root_hub_suspended,
626 .thaw_noirq = NULL,
627 .thaw = NULL,
628 .poweroff = hcd_pci_suspend,
629 .poweroff_noirq = hcd_pci_suspend_noirq,
630 .restore_noirq = hcd_pci_resume_noirq,
631 .restore= hcd_pci_restore,
632 .runtime_suspend = hcd_pci_runtime_suspend,
633 .runtime_resume = hcd_pci_runtime_resume,
634 };
635 EXPORT_SYMBOL_GPL(usb_hcd_pci_pm_ops);
636
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[tip:x86/core] BUILD SUCCESS 99cb64de36d5c9397a664808b92943e35bdce25e
-a012-20210409 x86_64 randconfig-a011-20210409 x86_64 randconfig-a013-20210409 x86_64 randconfig-a016-20210409 i386 randconfig-a015-20210411 i386 randconfig-a014-20210411 i386 randconfig-a013-20210411 i386 randconfig-a012-20210411 i386 randconfig-a016-20210411 i386 randconfig-a011-20210411 i386 randconfig-a015-20210410 i386 randconfig-a014-20210410 i386 randconfig-a012-20210410 i386 randconfig-a016-20210410 x86_64 randconfig-a003-20210411 x86_64 randconfig-a002-20210411 x86_64 randconfig-a001-20210411 x86_64 randconfig-a005-20210411 x86_64 randconfig-a006-20210411 x86_64 randconfig-a004-20210411 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a003-20210410 x86_64 randconfig-a002-20210410 x86_64 randconfig-a001-20210410 x86_64 randconfig-a005-20210410 x86_64 randconfig-a006-20210410 x86_64 randconfig-a004-20210410 x86_64 randconfig-a014-20210411 x86_64 randconfig-a015-20210411 x86_64 randconfig-a011-20210411 x86_64 randconfig-a013-20210411 x86_64 randconfig-a012-20210411 x86_64 randconfig-a016-20210411 x86_64 randconfig-a004-20210409 x86_64 randconfig-a005-20210409 x86_64 randconfig-a003-20210409 x86_64 randconfig-a001-20210409 x86_64 randconfig-a002-20210409 x86_64 randconfig-a006-20210409 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] iommu/amd: Fix extended features logging
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The second line is emitted via 'pr_cont', which causes it to have a
different ('warn') loglevel compared to the previous line ('info').
Commit 9a295ff0ffc9 attempted to rectify this by removing the newline
from the pci_info format string, but this doesn't work, as pci_info
calls implicitly append a newline anyway.
Restore the newline, and call pr_info with empty format string to set
the loglevel for subsequent pr_cont calls. The same solution is used in
EFI and uvesafb drivers.
Fixes: 9a295ff0ffc9 ("iommu/amd: Print extended features in one line to fix
divergent log levels")
Signed-off-by: Alexander Monakov
Cc: Paul Menzel
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Cc: io...@lists.linux-foundation.org
---
drivers/iommu/amd/init.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 596d0c413473..a25e241eff1c 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -1929,8 +1929,11 @@ static void print_iommu_info(void)
pci_info(pdev, "Found IOMMU cap 0x%hx\n", iommu->cap_ptr);
if (iommu->cap & (1 << IOMMU_CAP_EFR)) {
- pci_info(pdev, "Extended features (%#llx):",
+ pci_info(pdev, "Extended features (%#llx):\n",
iommu->features);
+
+ pr_info("");
+
for (i = 0; i < ARRAY_SIZE(feat_str); ++i) {
if (iommu_feature(iommu, (1ULL << i)))
pr_cont(" %s", feat_str[i]);
--
2.30.0
Re: [PATCH] dt-bindings: pinctrl: rockchip: add RK3568 SoC support
Am Samstag, 10. April 2021, 22:45:00 CEST schrieb Ezequiel Garcia: > Add RK3568/RK3566 SoC support to pinctrl. > > Signed-off-by: Ezequiel Garcia Reviewed-by: Heiko Stuebner > --- > Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt > index d3eae61a340d..91fab614c381 100644 > --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt > +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt > @@ -33,6 +33,7 @@ Required properties for iomux controller: > "rockchip,rk3328-pinctrl": for Rockchip RK3328 > "rockchip,rk3368-pinctrl": for Rockchip RK3368 > "rockchip,rk3399-pinctrl": for Rockchip RK3399 > + "rockchip,rk3568-pinctrl": for Rockchip RK3568 > >- rockchip,grf: phandle referencing a syscon providing the >"general register files" >
[PATCH 1/1] mm: Fix struct page layout on 32-bit systems
32-bit architectures which expect 8-byte alignment for 8-byte integers
and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
page inadvertently expanded in 2019. When the dma_addr_t was added,
it forced the alignment of the union to 8 bytes, which inserted a 4 byte
gap between 'flags' and the union.
We could fix this by telling the compiler to use a smaller alignment
for the dma_addr, but that seems a little fragile. Instead, move the
'flags' into the union. That causes dma_addr to shift into the same
bits as 'mapping', so it would have to be cleared on free. To avoid
this, insert three words of padding and use the same bits as ->index
and ->private, neither of which have to be cleared on free.
Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/mm_types.h | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6613b26a8894..45c563e9b50e 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -68,16 +68,22 @@ struct mem_cgroup;
#endif
struct page {
- unsigned long flags;/* Atomic flags, some possibly
-* updated asynchronously */
/*
-* Five words (20/40 bytes) are available in this union.
-* WARNING: bit 0 of the first word is used for PageTail(). That
-* means the other users of this union MUST NOT use the bit to
+* This union is six words (24 / 48 bytes) in size.
+* The first word is reserved for atomic flags, often updated
+* asynchronously. Use the PageFoo() macros to access it. Some
+* of the flags can be reused for your own purposes, but the
+* word as a whole often contains other information and overwriting
+* it will cause functions like page_zone() and page_node() to stop
+* working correctly.
+*
+* Bit 0 of the second word is used for PageTail(). That
+* means the other users of this union MUST leave the bit zero to
* avoid collision and false-positive PageTail().
*/
union {
struct {/* Page cache and anonymous pages */
+ unsigned long flags;
/**
* @lru: Pageout list, eg. active_list protected by
* lruvec->lru_lock. Sometimes used as a generic list
@@ -96,13 +102,14 @@ struct page {
unsigned long private;
};
struct {/* page_pool used by netstack */
- /**
-* @dma_addr: might require a 64-bit value even on
-* 32-bit architectures.
-*/
- dma_addr_t dma_addr;
+ unsigned long _pp_flags;
+ unsigned long pp_magic;
+ unsigned long xmi;
+ unsigned long _pp_mapping_pad;
+ dma_addr_t dma_addr;/* might be one or two words */
};
struct {/* slab, slob and slub */
+ unsigned long _slab_flags;
union {
struct list_head slab_list;
struct {/* Partial pages */
@@ -130,6 +137,7 @@ struct page {
};
};
struct {/* Tail pages of compound page */
+ unsigned long _t1_flags;
unsigned long compound_head;/* Bit zero is set */
/* First tail page only */
@@ -139,12 +147,14 @@ struct page {
unsigned int compound_nr; /* 1 << compound_order */
};
struct {/* Second tail page of compound page */
+ unsigned long _t2_flags;
unsigned long _compound_pad_1; /* compound_head */
atomic_t hpage_pinned_refcount;
/* For both global and memcg */
struct list_head deferred_list;
};
struct {/* Page table pages */
+ unsigned long _pt_flags;
unsigned long _pt_pad_1;/* compound_head */
pgtable_t pmd_huge_pte; /* protected by page->ptl */
unsigned long _pt_pad_2;/* mapping */
@@ -159,6 +169,7 @@ struct page {
#endif
};
struct {/* ZONE_DEVICE pages */
+ unsigned long _zd_flags;
/** @pgmap: Points to the hosting device page map. */
struct dev_pagemap *pgmap;
void *zone_device_data;
@@
[PATCH 0/1] Fix struct page layout on 32-bit systems
I'd really appreciate people testing this, particularly on arm32/mips32/ppc32 systems with a 64-bit dma_addr_t. Matthew Wilcox (Oracle) (1): mm: Fix struct page layout on 32-bit systems include/linux/mm_types.h | 38 ++ 1 file changed, 26 insertions(+), 12 deletions(-) -- 2.30.2
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
Op 10-04-2021 om 20:23 schreef Lukas Wunner: On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote: Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around? It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS? Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289 (CC Aaron Plattner) Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit. Thanks, Lukas
[PATCH] dt-bindings: pinctrl: rockchip: add RK3568 SoC support
Add RK3568/RK3566 SoC support to pinctrl. Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index d3eae61a340d..91fab614c381 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -33,6 +33,7 @@ Required properties for iomux controller: "rockchip,rk3328-pinctrl": for Rockchip RK3328 "rockchip,rk3368-pinctrl": for Rockchip RK3368 "rockchip,rk3399-pinctrl": for Rockchip RK3399 + "rockchip,rk3568-pinctrl": for Rockchip RK3568 - rockchip,grf: phandle referencing a syscon providing the "general register files" -- 2.30.0
Re: [PATCH RESEND 0/7] gpio-rockchip driver
Hi Jianqun, I tried applying this on top of "pinctrl: rockchip: add support for rk3568", but I got some conflicts. If you could add some information about how patches should be applied to the cover letter, that'd be really helpful :-) Also, I've noticed several of these GPIOs patches, is this the most up to date? You can add some information about superseeding patches in the cover letter as well. Thanks, Ezequiel On Wed, 24 Mar 2021 at 03:46, Jianqun Xu wrote: > > Separate gpio driver from pinctrl driver, and support v2 controller. > > Jianqun Xu (7): > pinctrl/rockchip: separate struct rockchip_pin_bank to a head file > pinctrl/pinctrl-rockchip.h: add pinctrl device to gpio bank struct > gpio: separate gpio driver from pinctrl-rockchip driver > gpio/rockchip: use struct rockchip_gpio_regs for gpio controller > gpio/rockchip: support next version gpio controller > gpio/rockchip: always enable clock for gpio controller > gpio/rockchip: drop irq_gc_lock/irq_gc_unlock for irq set type > > drivers/gpio/Kconfig | 8 + > drivers/gpio/Makefile | 1 + > drivers/gpio/gpio-rockchip.c | 758 > drivers/pinctrl/pinctrl-rockchip.c | 909 + > drivers/pinctrl/pinctrl-rockchip.h | 286 + > 5 files changed, 1072 insertions(+), 890 deletions(-) > create mode 100644 drivers/gpio/gpio-rockchip.c > create mode 100644 drivers/pinctrl/pinctrl-rockchip.h > > -- > 2.25.1 > > >
[PATCH] crypto: crc32-generic - Use SPDX-License-Identifier
Use SPDX-License-Identifier: GPL-2.0-only, instead of hand writing it. This also removes a reference to http://www.xyratex.com which seems to be down. Signed-off-by: Christophe JAILLET --- crypto/crc32_generic.c | 24 +--- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/crypto/crc32_generic.c b/crypto/crc32_generic.c index 0e103fb5dd77..a989cb44fd16 100644 --- a/crypto/crc32_generic.c +++ b/crypto/crc32_generic.c @@ -1,26 +1,4 @@ -/* GPL HEADER START - * - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 only, - * as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License version 2 for more details (a copy is included - * in the LICENSE file that accompanied this code). - * - * You should have received a copy of the GNU General Public License - * version 2 along with this program; If not, see http://www.gnu.org/licenses - * - * Please visit http://www.xyratex.com/contact if you need additional - * information or have any questions. - * - * GPL HEADER END - */ - +// SPDX-License-Identifier: GPL-2.0-only /* * Copyright 2012 Xyratex Technology Limited */ -- 2.27.0
[RFC] Tainting tasks after poking at them
I'm not a security guy, but
The idea is to irrevocably mark task as tainted after its registers
and/or memory have been changed by another task.
The list definitely includes
* ptrace PTRACE_POKEUSER, PTRACE_POKETEXT, PTRACE_POKEDATA,
PTRACE_SETREGS, PTRACE_SETFPREGS.
* process_vm_writev(2)
If an attacker gets an arbitrary code execution in context of task T,
then every task which can be attached to from T is compromised as well
via registers/memory manipulating system calls.
Tainted flag can be examined in kernel coredumps and maybe even help
with post mortem analysis (no idea if it is really true).
Note:
struct mm_struct should be tainted as well (i've noticed right before
sending this email).
---
arch/x86/kernel/process_64.c |2 ++
arch/x86/kernel/ptrace.c |7 +++
arch/x86/kernel/tls.c|2 ++
fs/proc/base.c | 10 ++
include/linux/sched.h| 14 ++
kernel/ptrace.c |3 +++
mm/process_vm_access.c |4
7 files changed, 42 insertions(+)
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -468,6 +468,7 @@ void x86_fsbase_write_task(struct task_struct *task,
unsigned long fsbase)
WARN_ON_ONCE(task == current);
task->thread.fsbase = fsbase;
+ task_set_tainted(task);
}
void x86_gsbase_write_task(struct task_struct *task, unsigned long gsbase)
@@ -475,6 +476,7 @@ void x86_gsbase_write_task(struct task_struct *task,
unsigned long gsbase)
WARN_ON_ONCE(task == current);
task->thread.gsbase = gsbase;
+ task_set_tainted(task);
}
static void
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -214,6 +214,8 @@ static int set_segment_reg(struct task_struct *task,
task_user_gs(task) = value;
}
+ task_set_tainted(task);
+
return 0;
}
@@ -315,6 +317,8 @@ static int set_segment_reg(struct task_struct *task,
break;
}
+ task_set_tainted(task);
+
return 0;
}
@@ -349,6 +353,8 @@ static int set_flags(struct task_struct *task, unsigned
long value)
regs->flags = (regs->flags & ~FLAG_MASK) | (value & FLAG_MASK);
+ task_set_tainted(task);
+
return 0;
}
@@ -382,6 +388,7 @@ static int putreg(struct task_struct *child,
}
*pt_regs_access(task_pt_regs(child), offset) = value;
+ task_set_tainted(child);
return 0;
}
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -106,6 +106,8 @@ static void set_tls_desc(struct task_struct *p, int idx,
load_TLS(t, cpu);
put_cpu();
+
+ task_set_tainted(p);
}
/*
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3149,6 +3149,14 @@ static int proc_stack_depth(struct seq_file *m, struct
pid_namespace *ns,
}
#endif /* CONFIG_STACKLEAK_METRICS */
+static int proc_pid_tainted(struct seq_file *m, struct pid_namespace *_,
+ struct pid *__, struct task_struct *tsk)
+{
+ seq_putc(m, '0' + task_is_tainted(tsk));
+ seq_putc(m, '\n');
+ return 0;
+}
+
/*
* Thread groups
*/
@@ -3265,6 +3273,7 @@ static const struct pid_entry tgid_base_stuff[] = {
#ifdef CONFIG_SECCOMP_CACHE_DEBUG
ONE("seccomp_cache", S_IRUSR, proc_pid_seccomp_cache),
#endif
+ ONE("tainted", S_IRUGO, proc_pid_tainted),
};
static int proc_tgid_base_readdir(struct file *file, struct dir_context *ctx)
@@ -3598,6 +3607,7 @@ static const struct pid_entry tid_base_stuff[] = {
#ifdef CONFIG_SECCOMP_CACHE_DEBUG
ONE("seccomp_cache", S_IRUSR, proc_pid_seccomp_cache),
#endif
+ ONE("tainted", S_IRUGO, proc_pid_tainted),
};
static int proc_tid_base_readdir(struct file *file, struct dir_context *ctx)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -668,6 +668,7 @@ struct task_struct {
/* Per task flags (PF_*), defined further below: */
unsigned intflags;
unsigned intptrace;
+ booltainted;
#ifdef CONFIG_SMP
int on_cpu;
@@ -2026,6 +2027,19 @@ extern long sched_getaffinity(pid_t pid, struct cpumask
*mask);
unsigned long sched_cpu_util(int cpu, unsigned long max);
#endif /* CONFIG_SMP */
+static inline bool task_is_tainted(const struct task_struct *tsk)
+{
+ return READ_ONCE(tsk->tainted);
+}
+
+static inline void task_set_tainted(struct task_struct *tsk)
+{
+ /* Self-flagellation is OK. */
+ if (tsk != current) {
+ WRITE_ONCE(tsk->tainted, true);
+ }
+}
+
#ifdef CONFIG_RSEQ
/*
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -1297,6 +1297,9 @@ int generic_ptrace_pokedata(struct task_struct *tsk,
unsigned long addr,
copied = ptrace_access_vm(tsk, addr, , sizeof(data),
FOLL_FORCE | FOLL_WRITE);
+ if (copied > 0) {
+ task_set_tainted(tsk);
+ }
[PATCH 3/3] nvme: remove single trailing whitespace
There is a single trailing whitespace in core.c. Since this is just a single whitespace, the chances of this affecting backports to stable should be quite low, so let's just remove it. Signed-off-by: Niklas Cassel --- drivers/nvme/host/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index c739e4c5b621..288ac47ff5b4 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2909,7 +2909,7 @@ int nvme_init_ctrl_finish(struct nvme_ctrl *ctrl) ret = nvme_configure_apst(ctrl); if (ret < 0) return ret; - + ret = nvme_configure_timestamp(ctrl); if (ret < 0) return ret; -- 2.30.2
Re: [PATCH v2 4/6] i2c: mpc: make interrupt mandatory and remove polling code
On Mon, Mar 29, 2021 at 02:52:04PM +1300, Chris Packham wrote: > All the in-tree dts files that use one of the compatible strings from > i2c-mpc.c provide an interrupt property. By making this mandatory we > can simplify the code. > > Signed-off-by: Chris Packham After I applied this patch, cppcheck reports: CPPCHECK drivers/i2c/busses/i2c-mpc.c:401:47: warning: Either the condition 'div?(int)div->fdr:-EINVAL' is redundant or there is possible null pointer dereference: div. [nullPointerRedundantCheck] *real_clk = fsl_get_sys_freq() / prescaler / div->divider; ^ drivers/i2c/busses/i2c-mpc.c:402:13: note: Assuming that condition 'div?(int)div->fdr:-EINVAL' is not redundant return div ? (int)div->fdr : -EINVAL; ^ drivers/i2c/busses/i2c-mpc.c:401:47: note: Null pointer dereference *real_clk = fsl_get_sys_freq() / prescaler / div->divider; ^ Can you check this? I'd think we can fix it incrementally... signature.asc Description: PGP signature
[PATCH 2/3] nvme-multipath: remove single trailing whitespace
There is a single trailing whitespace in multipath.c.
Since this is just a single whitespace, the chances of this affecting
backports to stable should be quite low, so let's just remove it.
Signed-off-by: Niklas Cassel
---
drivers/nvme/host/multipath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 2bbc1685799d..68918ea1d3d0 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -697,7 +697,7 @@ void nvme_mpath_add_disk(struct nvme_ns *ns, struct
nvme_id_ns *id)
queue_work(nvme_wq, >ctrl->ana_work);
}
} else {
- ns->ana_state = NVME_ANA_OPTIMIZED;
+ ns->ana_state = NVME_ANA_OPTIMIZED;
nvme_mpath_set_live(ns);
}
--
2.30.2
[PATCH 0/3] nvme trailing whitespace cleanup
Hello nvme peeps, This series removes all the trailing whitespace I could find using: git grep '[[:blank:]]$' drivers/nvme So this should remove all the existing trailing whitespace in drivers/nvme/* Kind regards, Niklas Niklas Cassel (3): nvme-pci: remove single trailing whitespace nvme-multipath: remove single trailing whitespace nvme: remove single trailing whitespace drivers/nvme/host/core.c | 2 +- drivers/nvme/host/multipath.c | 2 +- drivers/nvme/host/pci.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 2.30.2
[PATCH 1/3] nvme-pci: remove single trailing whitespace
There is a single trailing whitespace in pci.c.
Since this is just a single whitespace, the chances of this affecting
backports to stable should be quite low, so let's just remove it.
Signed-off-by: Niklas Cassel
---
drivers/nvme/host/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index b06e685d1250..09d4c5f99fc3 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2172,7 +2172,7 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
if (nr_io_queues == 0)
return 0;
-
+
clear_bit(NVMEQ_ENABLED, >flags);
if (dev->cmb_use_sqes) {
--
2.30.2
Re: [GIT PULL] percpu changes for v5.12-rc7
The pull request you sent on Sat, 10 Apr 2021 18:22:35 +: > git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu.git for-5.12-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/52e44129fba5cfc4e351fdb5e45849afc74d9a53 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SCSI fixes for 5.12-rc6
The pull request you sent on Sat, 10 Apr 2021 10:48:41 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/efc2da9241e643cb90897ac4ed3542daa3edf3bc Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v2 6/6] i2c: mpc: Interrupt driven transfer
On Mon, Mar 29, 2021 at 02:52:06PM +1300, Chris Packham wrote: > The fsl-i2c controller will generate an interrupt after every byte > transferred. Make use of this interrupt to drive a state machine which > allows the next part of a transfer to happen as soon as the interrupt is > received. This is particularly helpful with SMBUS devices like the LM81 > which will timeout if we take too long between bytes in a transfer. > > Signed-off-by: Chris Packham Okay, this change is too large and HW specific for a detailed review. But I trust you and hope you will be around to fix regressions if I apply it for 5.13? That kind of leads to the question if you want to step up as the maintainer for this driver? Only thing I noticed was a "BUG" and "BUG_ON" and wonder if we really need to halt the kernel in that case. Maybe WARN is enough? I'll apply the first five patches now, they look good to me. signature.asc Description: PGP signature
Re: [PATCH] mm/frontswap: fix frontswap_register_ops() race with swapon and swapoff
On Sat, Apr 10, 2021 at 5:01 AM Miaohe Lin wrote:
>
> On 2021/4/10 18:42, Yu Zhao wrote:
> > On Sat, Apr 10, 2021 at 1:30 AM Miaohe Lin wrote:
> >>
> >> Hi:
> >> On 2021/4/5 18:20, Miaohe Lin wrote:
> >>> frontswap_register_ops can race with swapon. Consider the following scene:
> >>
> >> Any comment or suggestion? Or is this race window too theoretical to fix?
> >> Thanks.
> >
> > Let me run a stress test and get back to you (within a day or so).
>
> That's very kind of you. Many thanks!
I'm still getting the following crash. Probably I should try the other
series you sent earlier too?
BUG: unable to handle page fault for address: aa7937d82000
RIP: 0010:scan_swap_map_slots+0x12b/0x7f0
Call Trace:
get_swap_pages+0x278/0x590
get_swap_page+0x1ab/0x280
add_to_swap+0x7d/0x130
shrink_page_list+0xf84/0x25f0
reclaim_pages+0x313/0x430
madvise_cold_or_pageout_pte_range+0x95c/0xaa0
walk_p4d_range+0x43f/0x790
walk_pgd_range+0xf1/0x150
__walk_page_range+0x6f/0x1b0
walk_page_range+0xbe/0x1e
do_madvise+0x271/0x720
> >>> CPU1 CPU2
> >>>
> >>> frontswap_register_ops
> >>> fill bitmap a
> >>> ops->init
> >>> sys_swapon
> >>> enable_swap_info
> >>> frontswap_init without new ops
> >>> add ops to frontswap_ops list
> >>> check if swap_active_head changed
> >>> add to swap_active_head
> >>>
> >>> So the frontswap_ops init is missed on the new swap device. Consider the
> >>> another scene:
> >>> CPU1CPU2
> >>>
> >>> frontswap_register_ops
> >>> fill bitmap a
> >>> ops->init
> >>> add ops to frontswap_ops list
> >>> sys_swapon
> >>> enable_swap_info
> >>> frontswap_init with new ops
> >>> add to swap_active_head
> >>> check if swap_active_head changed
> >>> ops->init for new swap device [twice!]
> >>>
> >>> The frontswap_ops init will be called two times on the new swap device
> >>> this
> >>> time. frontswap_register_ops can also race with swapoff. Consider the
> >>> following scene:
> >>>
> >>> CPU1CPU2
> >>>
> >>> sys_swapoff
> >>> removed from swap_active_head
> >>> frontswap_register_ops
> >>> fill bitmap a
> >>> ops->init without swap device
> >>> add ops to frontswap_ops list
> >>> invalidate_area with new ops
> >>> check if swap_active_head changed
> >>>
> >>> We could call invalidate_area on a swap device under swapoff with
> >>> frontswap
> >>> is uninitialized yet. Fix all these by using swapon_mutex to guard against
> >>> race with swapon and add swap_info_get_if_under_swapoff() to collect swap
> >>> devices under swapoff.
> >>>
> >>> Fixes: d1dc6f1bcf1e ("frontswap: allow multiple backends")
> >>> Signed-off-by: Miaohe Lin
> >>> ---
> >>> include/linux/swapfile.h | 2 ++
> >>> mm/frontswap.c | 40 +---
> >>> mm/swapfile.c| 13 -
> >>> 3 files changed, 31 insertions(+), 24 deletions(-)
> >>>
> >>> diff --git a/include/linux/swapfile.h b/include/linux/swapfile.h
> >>> index e06febf62978..7ae15d917828 100644
> >>> --- a/include/linux/swapfile.h
> >>> +++ b/include/linux/swapfile.h
> >>> @@ -9,8 +9,10 @@
> >>> extern spinlock_t swap_lock;
> >>> extern struct plist_head swap_active_head;
> >>> extern struct swap_info_struct *swap_info[];
> >>> +extern struct mutex swapon_mutex;
> >>> extern int try_to_unuse(unsigned int, bool, unsigned long);
> >>> extern unsigned long generic_max_swapfile_size(void);
> >>> extern unsigned long max_swapfile_size(void);
> >>> +extern struct swap_info_struct *swap_info_get_if_under_swapoff(int type);
> >>>
> >>> #endif /* _LINUX_SWAPFILE_H */
> >>> diff --git a/mm/frontswap.c b/mm/frontswap.c
> >>> index 130e301c5ac0..c16bfc7550b5 100644
> >>> --- a/mm/frontswap.c
> >>> +++ b/mm/frontswap.c
> >>> @@ -123,12 +123,26 @@ void frontswap_register_ops(struct frontswap_ops
> >>> *ops)
> >>>
> >>> bitmap_zero(a, MAX_SWAPFILES);
> >>> bitmap_zero(b, MAX_SWAPFILES);
> >>> -
> >>> + mutex_lock(_mutex);
> >>> spin_lock(_lock);
> >>> plist_for_each_entry(si, _active_head, list) {
> >>> if (!WARN_ON(!si->frontswap_map))
> >>> set_bit(si->type, a);
> >>> }
> >>> + /*
> >>> + * There might be some swap devices under swapoff, i.e. they are
> >>> + * removed from swap_active_head but
[git pull] habanalabs pull request for kernel 5.13
Hi Greg, This is habanalabs pull request for the merge window of kernel 5.13. It contains changes and new features, support for new firmware. Details are in the tag. Thanks, Oded The following changes since commit b195b20b7145bcae22ad261abc52d68336f5e913: Merge tag 'extcon-next-for-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next (2021-04-08 08:45:30 +0200) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git tags/misc-habanalabs-next-2021-04-10 for you to fetch changes up to b575a7673e3d0396992fc72fce850723d39264e3: habanalabs: print f/w boot unknown error (2021-04-09 14:10:32 +0300) This tag contains habanalabs driver changes for v5.13: - Add support to reset device after the user closes the file descriptor. Because we support a single user, we can reset the device (if needs to) after a user closes its file descriptor to make sure the device is in idle and clean state for the next user. - Add a new feature to allow the user to wait on interrupt. This is needed for future ASICs - Replace GFP_ATOMIC with GFP_KERNEL wherever possible and add code to support failure of allocating with GFP_ATOMIC. - Update code to support the latest firmware image: - More security features are done in the firmware - Remove hard-coded assumptions and replace them with values that are sent to the firmware on loading. - Print device unusable error - Reset device in case the communication between driver and firmware gets out of sync. - Support new PCI device ids for secured GAUDI. - Expose current power draw through the INFO IOCTL. - Support resetting the device upon a request from the BMC (through F/W). - Always use only a single MSI in GAUDI, due to H/W limitation. - Improve data-path code by taking out code from spinlock protection. - Allow user to specify custom timeout per Command Submission. - Some enhancements to debugfs. - Various minor changes and improvements. Alon Mizrahi (1): habanalabs: add custom timeout flag per cs Bharat Jauhari (1): habanalabs: move dram scrub to free sequence Koby Elbaz (2): habanalabs: improve utilization calculation habanalabs: support DEVICE_UNUSABLE error indication from FW Oded Gabbay (11): habanalabs: reset after device is actually released habanalabs: fail reset if device is not idle habanalabs: reset_upon_device_release is for bring-up habanalabs: print if device is used on FD close habanalabs: change default CS timeout to 30 seconds habanalabs: use correct define for 32-bit max value habanalabs/gaudi: always use single-msi mode habanalabs/gaudi: add debugfs to DMA from the device habanalabs: remove the store jobs array from CS IOCTL habanalabs: use strscpy instead of sprintf and strlcpy habanalabs: print f/w boot unknown error Ofir Bitton (13): habanalabs: add reset support when user closes FD habanalabs: enable all IRQs for user interrupt support habanalabs: wait for interrupt support habanalabs: use a single FW loading bringup flag habanalabs/gaudi: update extended async event header habanalabs: replace GFP_ATOMIC with GFP_KERNEL habanalabs: debugfs access to user mapped host addresses habanalabs/gaudi: reset device upon BMC request habanalabs/gaudi: unsecure TPC cfg status registers habanalabs/gaudi: Update async events header habanalabs: move relevant datapath work outside cs lock habanalabs/gaudi: derive security status from pci id habanalabs/gaudi: skip iATU if F/W security is enabled Ohad Sharabi (6): habanalabs: reset device in case of sync error habanalabs: skip DISABLE PCI packet to FW on heartbeat habanalabs: update hl_boot_if.h habanalabs: support legacy and new pll indexes habanalabs: send dynamic msi-x indexes to f/w habanalabs: update to latest F/W communication header Sagiv Ozeri (2): habanalabs: support HW blocks vm show habanalabs: return current power via INFO IOCTL Tomer Tayar (1): habanalabs/gaudi: clear QM errors only if not in stop_on_err mode Yang Li (1): habanalabs: Switch to using the new API kobj_to_dev() farah kassabri (3): habanalabs: set max asid to 2 habanalabs: avoid soft lockup bug upon mapping error habanalabs/gaudi: sync stream add protection to SOB reset flow .../ABI/testing/debugfs-driver-habanalabs | 70 +++- drivers/misc/habanalabs/common/command_buffer.c| 12 +- .../misc/habanalabs/common/command_submission.c| 368 + drivers/misc/habanalabs/common/context.c | 14 +- drivers/misc/habanalabs/common/debugfs.c | 224 +++--
Re: [PATCH] i2c: ensure timely release of driver-allocated resources
On Sun, Mar 21, 2021 at 06:38:32PM -0700, Dmitry Torokhov wrote: > More and more drivers rely on devres to manage their resources, however > if bus' probe() and release() methods are not trivial and control some > of resources as well (for example enable or disable clocks, or attach > device to a power domain), we need to make sure that driver-allocated > resources are released immediately after driver's remove() method > returns, and not postponed until driver core gets around to releasing > resources. To fix that we open a new devres group before calling > driver's probe() and explicitly release it when we return from driver's > remove(). > > Tested-by: Jeff LaBundy > Signed-off-by: Dmitry Torokhov Applied to for-next, thanks! signature.asc Description: PGP signature
[PATCH v2] staging: media: meson: vdec: declare u32 as const and static const
Declared 32 bit unsigned int as static constant inside a function and
replaced u32[] {x,y} as canvas1, canvas2 in codec_mpeg12.c
This indicates the value of canvas indexes will remain constant throughout
execution.
Replaced u32 reg_base and u32 reg_name with const u32 reg_base and const
u32 reg_name as it will contain data/registry bases to write static
const indexes declared above and will keep track of of contiguos
registers after each reg_base.
This makes code look better, neater. It improves readability.
Signed-off-by: Mitali Borkar
---
drivers/staging/media/meson/vdec/codec_mpeg12.c | 5 +++--
drivers/staging/media/meson/vdec/vdec_helpers.c | 2 +-
drivers/staging/media/meson/vdec/vdec_helpers.h | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/meson/vdec/codec_mpeg12.c
b/drivers/staging/media/meson/vdec/codec_mpeg12.c
index 21e93a13356c..861d8584f22f 100644
--- a/drivers/staging/media/meson/vdec/codec_mpeg12.c
+++ b/drivers/staging/media/meson/vdec/codec_mpeg12.c
@@ -65,6 +65,8 @@ static int codec_mpeg12_start(struct amvdec_session *sess)
struct amvdec_core *core = sess->core;
struct codec_mpeg12 *mpeg12;
int ret;
+ static const u32 canvas1[] = { AV_SCRATCH_0, 0 };
+ static const u32 canvas2[] = { 8, 0 }
mpeg12 = kzalloc(sizeof(*mpeg12), GFP_KERNEL);
if (!mpeg12)
@@ -80,8 +82,7 @@ static int codec_mpeg12_start(struct amvdec_session *sess)
goto free_mpeg12;
}
- ret = amvdec_set_canvases(sess, (u32[]){ AV_SCRATCH_0, 0 },
- (u32[]){ 8, 0 });
+ ret = amvdec_set_canvases(sess, canvas1, canvas2);
if (ret)
goto free_workspace;
diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.c
b/drivers/staging/media/meson/vdec/vdec_helpers.c
index 7f07a9175815..df5c27266c44 100644
--- a/drivers/staging/media/meson/vdec/vdec_helpers.c
+++ b/drivers/staging/media/meson/vdec/vdec_helpers.c
@@ -177,7 +177,7 @@ static int set_canvas_nv12m(struct amvdec_session *sess,
}
int amvdec_set_canvases(struct amvdec_session *sess,
- u32 reg_base[], u32 reg_num[])
+ const u32 reg_base[], const u32 reg_num[])
{
struct v4l2_m2m_buffer *buf;
u32 pixfmt = sess->pixfmt_cap;
diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.h
b/drivers/staging/media/meson/vdec/vdec_helpers.h
index cfaed52ab526..ace8897c34fe 100644
--- a/drivers/staging/media/meson/vdec/vdec_helpers.h
+++ b/drivers/staging/media/meson/vdec/vdec_helpers.h
@@ -17,7 +17,7 @@
* @reg_num: number of contiguous registers after each reg_base (including it)
*/
int amvdec_set_canvases(struct amvdec_session *sess,
- u32 reg_base[], u32 reg_num[]);
+ const u32 reg_base[], const u32 reg_num[]);
/* Helpers to read/write to the various IPs (DOS, PARSER) */
u32 amvdec_read_dos(struct amvdec_core *core, u32 reg);
--
2.30.2
[PATCH] ARM: dts: stm32: fix stm32mp157c-odyssey card detect pin
The microSD card detect pin is physically connected to the MPU pin PI3.
The Device Tree configuration of the card detect pin was wrong—it was
set to pin PB7 instead. If such configuration was used, the kernel would
hang on “Waiting for root device” when booting from a microSD card.
Signed-off-by: Grzegorz Szymaszek
---
arch/arm/boot/dts/stm32mp157c-odyssey.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp157c-odyssey.dts
b/arch/arm/boot/dts/stm32mp157c-odyssey.dts
index a7ffec8f1516..be1dd5e9e744 100644
--- a/arch/arm/boot/dts/stm32mp157c-odyssey.dts
+++ b/arch/arm/boot/dts/stm32mp157c-odyssey.dts
@@ -64,7 +64,7 @@ {
pinctrl-0 = <_b4_pins_a>;
pinctrl-1 = <_b4_od_pins_a>;
pinctrl-2 = <_b4_sleep_pins_a>;
- cd-gpios = < 7 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ cd-gpios = < 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
disable-wp;
st,neg-edge;
bus-width = <4>;
--
2.30.2
Re: [PATCH 00/12] i2c: Adding support for software nodes
On Mon, Mar 29, 2021 at 01:50:35PM +0300, Heikki Krogerus wrote: > Hi, > > The old device property API (device_add_properties()) is going to be > removed. These prepare the i2c subsystem and drivers for the change. > The change is fairly trivial in case of i2c. All we need to do is add > complete software nodes to the devices instead of only the device > properties in those nodes. > > thanks, > > Heikki Krogerus (12): > i2c: Add support for software nodes > ARM: davinci: Constify the software nodes > ARM: omap1: osk: Constify the software node > ARM: pxa: stargate2: Constify the software node > ARM: s3c: mini2440: Constify the software node > platform/x86: intel_cht_int33fe_microb: Constify the software node > i2c: cht-wc: Constify the software node > i2c: nvidia-gpu: Constify the software node > i2c: icy: Constify the software node > platform/chrome: chromeos_laptop - Prepare complete software nodes > Input: elantech - Prepare a complete software node for the device > i2c: Remove support for dangling device properties Merged the immutable branch (with added tag from Robert) to for-next now. Branch is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/software-nodes tag: Thank you, Heikki and all reviewers! signature.asc Description: PGP signature
collect2: error: ld returned 1 exit status
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 95c7b07551879c8ad4d6dca10c02de46ddbf55a8 commit: d71fa5c9763c24dd997a2fa4feb7a13a95bab42c bpf: Add kernel module with user mode driver that populates bpffs. date: 8 months ago config: i386-randconfig-m021-20210411 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d71fa5c9763c24dd997a2fa4feb7a13a95bab42c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout d71fa5c9763c24dd997a2fa4feb7a13a95bab42c # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libelf.so when searching for -lelf /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libelf.a when searching for -lelf /usr/bin/ld: cannot find -lelf /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libelf.so when searching for -lelf /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libz.so when searching for -lz /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libz.a when searching for -lz /usr/bin/ld: cannot find -lz /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libz.so when searching for -lz >> collect2: error: ld returned 1 exit status --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH 4/5] kconfig: nconf: remove unneeded default for menu prompt
The rootmenu always has a prompt even if the 'mainmenu' statement is
missing in the top Kconfig file.
conf_parse() calls menu_add_prompt(P_MENU, "Main menu", NULL) in this
case.
So, every 'menu' has a prompt.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/nconf.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index daeeb5f81445..b6fe7b18a103 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -1068,7 +1068,6 @@ static int do_match(int key, struct match_state *state,
int *ans)
static void conf(struct menu *menu)
{
struct menu *submenu = NULL;
- const char *prompt = menu_get_prompt(menu);
struct symbol *sym;
int res;
int current_index = 0;
@@ -1086,9 +1085,8 @@ static void conf(struct menu *menu)
if (!child_count)
break;
- show_menu(prompt ? prompt : "Main Menu",
- menu_instructions,
- current_index, _top_row);
+ show_menu(menu_get_prompt(menu), menu_instructions,
+ current_index, _top_row);
keypad((menu_win(curses_menu)), TRUE);
while (!global_exit) {
if (match_state.in_search) {
--
2.27.0
[PATCH 3/5] kconfig: nconf: get rid of (void) casts from wattrset() calls
This reverts commit 10175ba65fde ("nconfig: Silence unused return values
from wattrset").
With recent GCC versions used, I no longer see "value computed is not
used" warnings even without the (void) casts.
The wattrset() used to be a macro like this:
#define wattrset(win,at) \
(NCURSES_OK_ADDR(win) \
? ((win)->_attrs = NCURSES_CAST(attr_t, at), \
OK) \
: ERR)
The GCC bugzilla [1] reported a false-positive -Wunused-value warning
in a similar test case. It was fixed by GCC 4.4.1.
Let's revert that commit, and see if somebody will claim the issue.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39889
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/nconf.c | 14 +++---
scripts/kconfig/nconf.gui.c | 20 ++--
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index 232eb3011efe..daeeb5f81445 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -370,18 +370,18 @@ static void print_function_line(void)
int lines = getmaxy(stdscr);
for (i = 0; i < function_keys_num; i++) {
- (void) wattrset(main_window, attributes[FUNCTION_HIGHLIGHT]);
+ wattrset(main_window, attributes[FUNCTION_HIGHLIGHT]);
mvwprintw(main_window, lines-3, offset,
"%s",
function_keys[i].key_str);
- (void) wattrset(main_window, attributes[FUNCTION_TEXT]);
+ wattrset(main_window, attributes[FUNCTION_TEXT]);
offset += strlen(function_keys[i].key_str);
mvwprintw(main_window, lines-3,
offset, "%s",
function_keys[i].func);
offset += strlen(function_keys[i].func) + skip;
}
- (void) wattrset(main_window, attributes[NORMAL]);
+ wattrset(main_window, attributes[NORMAL]);
}
/* help */
@@ -956,16 +956,16 @@ static void show_menu(const char *prompt, const char
*instructions,
current_instructions = instructions;
clear();
- (void) wattrset(main_window, attributes[NORMAL]);
+ wattrset(main_window, attributes[NORMAL]);
print_in_middle(stdscr, 1, 0, getmaxx(stdscr),
menu_backtitle,
attributes[MAIN_HEADING]);
- (void) wattrset(main_window, attributes[MAIN_MENU_BOX]);
+ wattrset(main_window, attributes[MAIN_MENU_BOX]);
box(main_window, 0, 0);
- (void) wattrset(main_window, attributes[MAIN_MENU_HEADING]);
+ wattrset(main_window, attributes[MAIN_MENU_HEADING]);
mvwprintw(main_window, 0, 3, " %s ", prompt);
- (void) wattrset(main_window, attributes[NORMAL]);
+ wattrset(main_window, attributes[NORMAL]);
set_menu_items(curses_menu, curses_menu_items);
diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c
index a914f81092d7..180d3158d380 100644
--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -167,7 +167,7 @@ void print_in_middle(WINDOW *win,
length = strlen(string);
temp = (width - length) / 2;
x = startx + (int)temp;
- (void) wattrset(win, color);
+ wattrset(win, color);
mvwprintw(win, y, x, "%s", string);
refresh();
}
@@ -297,11 +297,11 @@ int btn_dialog(WINDOW *main_window, const char *msg, int
btn_num, ...)
set_menu_fore(menu, attributes[DIALOG_MENU_FORE]);
set_menu_back(menu, attributes[DIALOG_MENU_BACK]);
- (void) wattrset(win, attributes[DIALOG_BOX]);
+ wattrset(win, attributes[DIALOG_BOX]);
box(win, 0, 0);
/* print message */
- (void) wattrset(msg_win, attributes[DIALOG_TEXT]);
+ wattrset(msg_win, attributes[DIALOG_TEXT]);
fill_window(msg_win, msg);
set_menu_win(menu, win);
@@ -405,16 +405,16 @@ int dialog_inputbox(WINDOW *main_window,
form_win = derwin(win, 1, prompt_width, prompt_lines+3, 2);
keypad(form_win, TRUE);
- (void) wattrset(form_win, attributes[INPUT_FIELD]);
+ wattrset(form_win, attributes[INPUT_FIELD]);
- (void) wattrset(win, attributes[INPUT_BOX]);
+ wattrset(win, attributes[INPUT_BOX]);
box(win, 0, 0);
- (void) wattrset(win, attributes[INPUT_HEADING]);
+ wattrset(win, attributes[INPUT_HEADING]);
if (title)
mvwprintw(win, 0, 3, "%s", title);
/* print message */
- (void) wattrset(prompt_win, attributes[INPUT_TEXT]);
+ wattrset(prompt_win, attributes[INPUT_TEXT]);
fill_window(prompt_win, prompt);
mvwprintw(form_win, 0, 0, "%*s", prompt_width, " ");
@@ -576,7 +576,7 @@ void show_scroll_win(WINDOW *main_window,
/* create the pad */
pad = newpad(total_lines+10, total_cols+10);
- (void) wattrset(pad, attributes[SCROLLWIN_TEXT]);
+
[PATCH 5/5] kconfig: nconf: refactor attributes setup code
The current attributes setup code is strange; the array attribute[]
is set to values outside the range of the attribute_t enum.
At least,
attributes_t attributes[ATTR_MAX+1] = {0};
... should be
int attribute[ATTR_MAX+1] = {0};
Also, there is no need to hard-code the color-pair numbers in
attributes_t.
The current code is horribly screwed up. Rewrite it.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/nconf.c | 22 ++--
scripts/kconfig/nconf.gui.c | 253
scripts/kconfig/nconf.h | 44 +++
3 files changed, 144 insertions(+), 175 deletions(-)
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index b6fe7b18a103..c47051598e9a 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -370,18 +370,18 @@ static void print_function_line(void)
int lines = getmaxy(stdscr);
for (i = 0; i < function_keys_num; i++) {
- wattrset(main_window, attributes[FUNCTION_HIGHLIGHT]);
+ wattrset(main_window, attr_function_highlight);
mvwprintw(main_window, lines-3, offset,
"%s",
function_keys[i].key_str);
- wattrset(main_window, attributes[FUNCTION_TEXT]);
+ wattrset(main_window, attr_function_text);
offset += strlen(function_keys[i].key_str);
mvwprintw(main_window, lines-3,
offset, "%s",
function_keys[i].func);
offset += strlen(function_keys[i].func) + skip;
}
- wattrset(main_window, attributes[NORMAL]);
+ wattrset(main_window, attr_normal);
}
/* help */
@@ -956,16 +956,16 @@ static void show_menu(const char *prompt, const char
*instructions,
current_instructions = instructions;
clear();
- wattrset(main_window, attributes[NORMAL]);
+ wattrset(main_window, attr_normal);
print_in_middle(stdscr, 1, 0, getmaxx(stdscr),
menu_backtitle,
- attributes[MAIN_HEADING]);
+ attr_main_heading);
- wattrset(main_window, attributes[MAIN_MENU_BOX]);
+ wattrset(main_window, attr_main_menu_box);
box(main_window, 0, 0);
- wattrset(main_window, attributes[MAIN_MENU_HEADING]);
+ wattrset(main_window, attr_main_menu_heading);
mvwprintw(main_window, 0, 3, " %s ", prompt);
- wattrset(main_window, attributes[NORMAL]);
+ wattrset(main_window, attr_normal);
set_menu_items(curses_menu, curses_menu_items);
@@ -1521,9 +1521,9 @@ int main(int ac, char **av)
menu_opts_on(curses_menu, O_NONCYCLIC);
menu_opts_on(curses_menu, O_IGNORECASE);
set_menu_mark(curses_menu, " ");
- set_menu_fore(curses_menu, attributes[MAIN_MENU_FORE]);
- set_menu_back(curses_menu, attributes[MAIN_MENU_BACK]);
- set_menu_grey(curses_menu, attributes[MAIN_MENU_GREY]);
+ set_menu_fore(curses_menu, attr_main_menu_fore);
+ set_menu_back(curses_menu, attr_main_menu_back);
+ set_menu_grey(curses_menu, attr_main_menu_grey);
set_config_filename(conf_get_configname());
setup_windows();
diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c
index 180d3158d380..e747590cee17 100644
--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -7,141 +7,114 @@
#include "nconf.h"
#include "lkc.h"
-/* a list of all the different widgets we use */
-attributes_t attributes[ATTR_MAX+1] = {0};
-
-/* available colors:
- COLOR_BLACK 0
- COLOR_RED 1
- COLOR_GREEN 2
- COLOR_YELLOW 3
- COLOR_BLUE4
- COLOR_MAGENTA 5
- COLOR_CYAN6
- COLOR_WHITE 7
- */
-static void set_normal_colors(void)
-{
- init_pair(NORMAL, -1, -1);
- init_pair(MAIN_HEADING, COLOR_MAGENTA, -1);
-
- /* FORE is for the selected item */
- init_pair(MAIN_MENU_FORE, -1, -1);
- /* BACK for all the rest */
- init_pair(MAIN_MENU_BACK, -1, -1);
- init_pair(MAIN_MENU_GREY, -1, -1);
- init_pair(MAIN_MENU_HEADING, COLOR_GREEN, -1);
- init_pair(MAIN_MENU_BOX, COLOR_YELLOW, -1);
-
- init_pair(SCROLLWIN_TEXT, -1, -1);
- init_pair(SCROLLWIN_HEADING, COLOR_GREEN, -1);
- init_pair(SCROLLWIN_BOX, COLOR_YELLOW, -1);
-
- init_pair(DIALOG_TEXT, -1, -1);
- init_pair(DIALOG_BOX, COLOR_YELLOW, -1);
- init_pair(DIALOG_MENU_BACK, COLOR_YELLOW, -1);
- init_pair(DIALOG_MENU_FORE, COLOR_RED, -1);
-
- init_pair(INPUT_BOX, COLOR_YELLOW, -1);
- init_pair(INPUT_HEADING, COLOR_GREEN, -1);
- init_pair(INPUT_TEXT, -1, -1);
- init_pair(INPUT_FIELD, -1, -1);
-
- init_pair(FUNCTION_HIGHLIGHT, -1, -1);
- init_pair(FUNCTION_TEXT, COLOR_YELLOW, -1);
-}
-
-/* available attributes:
- A_NORMALNormal display (no highlight)
- A_STANDOUT Best highlighting mode
[PATCH 2/5] kconfig: nconf: fix NORMAL attributes
The lower 8-bit of attributes should be 0, but this code wrongly
sets it to NORMAL (=1). The correct one is A_NORMAL.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/nconf.gui.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c
index 77f525a8617c..a914f81092d7 100644
--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -70,7 +70,7 @@ static void normal_color_theme(void)
/* automatically add color... */
#define mkattr(name, attr) do { \
attributes[name] = attr | COLOR_PAIR(name); } while (0)
- mkattr(NORMAL, NORMAL);
+ mkattr(NORMAL, A_NORMAL);
mkattr(MAIN_HEADING, A_BOLD | A_UNDERLINE);
mkattr(MAIN_MENU_FORE, A_REVERSE);
@@ -102,7 +102,7 @@ static void no_colors_theme(void)
/* automatically add highlight, no color */
#define mkattrn(name, attr) { attributes[name] = attr; }
- mkattrn(NORMAL, NORMAL);
+ mkattrn(NORMAL, A_NORMAL);
mkattrn(MAIN_HEADING, A_BOLD | A_UNDERLINE);
mkattrn(MAIN_MENU_FORE, A_STANDOUT);
--
2.27.0
[PATCH 1/5] kconfig: mconf,nconf: remove unneeded '\0' termination after snprintf()
snprintf() always terminates the destination buffer with '\0' even if
the buffer is not long enough. (In this case, the last element of the
buffer becomes '\0'.)
The explicit termination is unneeded.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/mconf.c | 11 +++
scripts/kconfig/nconf.c | 12 +++-
2 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 4cfbe62938cd..9d3cf510562f 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -299,17 +299,12 @@ static char filename[PATH_MAX+1];
static void set_config_filename(const char *config_filename)
{
static char menu_backtitle[PATH_MAX+128];
- int size;
- size = snprintf(menu_backtitle, sizeof(menu_backtitle),
- "%s - %s", config_filename, rootmenu.prompt->text);
- if (size >= sizeof(menu_backtitle))
- menu_backtitle[sizeof(menu_backtitle)-1] = '\0';
+ snprintf(menu_backtitle, sizeof(menu_backtitle), "%s - %s",
+config_filename, rootmenu.prompt->text);
set_dialog_backtitle(menu_backtitle);
- size = snprintf(filename, sizeof(filename), "%s", config_filename);
- if (size >= sizeof(filename))
- filename[sizeof(filename)-1] = '\0';
+ snprintf(filename, sizeof(filename), "%s", config_filename);
}
struct subtitle_part {
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index 86ca42b5ab80..232eb3011efe 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -635,16 +635,10 @@ static char filename[PATH_MAX+1];
static char menu_backtitle[PATH_MAX+128];
static const char *set_config_filename(const char *config_filename)
{
- int size;
+ snprintf(menu_backtitle, sizeof(menu_backtitle), "%s - %s",
+config_filename, rootmenu.prompt->text);
- size = snprintf(menu_backtitle, sizeof(menu_backtitle),
- "%s - %s", config_filename, rootmenu.prompt->text);
- if (size >= sizeof(menu_backtitle))
- menu_backtitle[sizeof(menu_backtitle)-1] = '\0';
-
- size = snprintf(filename, sizeof(filename), "%s", config_filename);
- if (size >= sizeof(filename))
- filename[sizeof(filename)-1] = '\0';
+ snprintf(filename, sizeof(filename), "%s", config_filename);
return menu_backtitle;
}
--
2.27.0
Re: [PATCH] ext4: add a configurable parameter to prevent endless loop in ext4_mb_discard_group_p
在 2021/4/9 下午1:47, riteshh 写道:
On 21/04/09 02:50AM, Wen Yang wrote:
On Apr 7, 2021, at 5:16 AM, riteshh wrote:
On 21/04/07 03:01PM, Wen Yang wrote:
From: Wen Yang
The kworker has occupied 100% of the CPU for several days:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
68086 root 20 0 00 0 R 100.0 0.0 9718:18 kworker/u64:11
And the stack obtained through sysrq is as follows:
[20613144.850426] task: 8800b5e08000 task.stack: c9001342c000
[20613144.850438] Call Trace:
[20613144.850439] []ext4_mb_new_blocks+0x429/0x550
[ext4]
[20613144.850439] [] ext4_ext_map_blocks+0xb5e/0xf30
[ext4]
[20613144.850441] [] ext4_map_blocks+0x172/0x620
[ext4]
[20613144.850442] [] ext4_writepages+0x7e5/0xf00
[ext4]
[20613144.850443] [] do_writepages+0x1e/0x30
[20613144.850444] []
__writeback_single_inode+0x45/0x320
[20613144.850444] [] writeback_sb_inodes+0x272/0x600
[20613144.850445] [] __writeback_inodes_wb+0x92/0xc0
[20613144.850445] [] wb_writeback+0x268/0x300
[20613144.850446] [] wb_workfn+0xb4/0x380
[20613144.850447] [] process_one_work+0x189/0x420
[20613144.850447] [] worker_thread+0x4e/0x4b0
The cpu resources of the cloud server are precious, and the server
cannot be restarted after running for a long time, so a configuration
parameter is added to prevent this endless loop.
Strange, if there is a endless loop here. Then I would definitely see
if there is any accounting problem in pa->pa_count. Otherwise busy=1
should not be set everytime. ext4_mb_show_pa() function may help debug
this.
If yes, then that means there always exists either a file preallocation
or a group preallocation. Maybe it is possible, in some use case.
Others may know of such use case, if any.
If this code is broken, then it doesn't make sense to me that we would
leave it in the "run forever" state after the patch, and require a sysfs
tunable to be set to have a properly working system?
Is there anything particularly strange about the workload/system that
might cause this? Filesystem is very full, memory is very low, etc?
Hi Ritesh and Andreas,
Thank you for your reply. Since there is still a faulty machine, we have
analyzed it again and found it is indeed a very special case:
crash> struct ext4_group_info 8813bb5f72d0
struct ext4_group_info {
bb_state = 0,
bb_free_root = {
rb_node = 0x0
},
bb_first_free = 1681,
bb_free = 0,
Not related to this issue, but above two variables values doesn't looks
consistent.
bb_fragments = 0,
bb_largest_free_order = -1,
bb_prealloc_list = {
next = 0x880268291d78,
prev = 0x880268291d78 ---> *** The list is empty
},
Ok. So when you collected the dump this list was empty.
alloc_sem = {
count = {
counter = 0
},
wait_list = {
next = 0x8813bb5f7308,
prev = 0x8813bb5f7308
},
wait_lock = {
raw_lock = {
{
val = {
counter = 0
},
{
locked = 0 '\000',
pending = 0 '\000'
},
{
locked_pending = 0,
tail = 0
}
}
}
},
osq = {
tail = {
counter = 0
}
},
owner = 0x0
},
bb_counters = 0x8813bb5f7328
}
crash>
crash> list 0x880268291d78 -l ext4_prealloc_space.pa_group_list -s
No point of doing this I guess, since the list anyway is empty.
What you may be seeing below is some garbage data.
ext4_prealloc_space.pa_count
880268291d78
pa_count = {
counter = 1 ---> pa->pa_count
}
8813bb5f72f0
pa_count = {
counter = -30701
}
I guess, since list is empty and you are seeing garbage hence counter value
of above node looks weird.
crash> struct -xo ext4_prealloc_space
struct ext4_prealloc_space {
[0x0] struct list_head pa_inode_list;
[0x10] struct list_head pa_group_list;
union {
struct list_head pa_tmp_list;
struct callback_head pa_rcu;
[0x20] } u;
[0x30] spinlock_t pa_lock;
[0x34] atomic_t pa_count;
[0x38] unsigned int pa_deleted;
[0x40] ext4_fsblk_t pa_pstart;
[0x48] ext4_lblk_t pa_lstart;
[0x4c] ext4_grpblk_t pa_len;
[0x50] ext4_grpblk_t pa_free;
[0x54] unsigned short pa_type;
[0x58] spinlock_t *pa_obj_lock;
[0x60] struct inode *pa_inode;
}
SIZE: 0x68
crash> rd 0x880268291d68 20
880268291d68: 881822f8a4c8 881822f8a4c8 ..."..."
880268291d78: 8813bb5f72f0 8813bb5f72f0 .r_..r_.
880268291d88: 1000 880db2371000 ..7.
880268291d98: 00010001
880268291da8: 00029c39 00170c41 9...A...
880268291db8: 0016 881822f8a4d8 ..."
880268291dc8: 881822f8a268 880268291af8 h.."..)h
880268291dd8:
Re: [PATCH net-next v3 2/5] mm: add a signature in struct page
On Sat, Apr 10, 2021 at 09:27:31PM +0300, Ilias Apalodimas wrote: > > Can this page_pool be used for TCP RX zerocopy? If yes then PageType > > can not be used. > > Yes it can, since it's going to be used as your default allocator for > payloads, which might end up on an SKB. > So we have to keep the extra added field on struct page for our mark. > Matthew had an intersting idea. He suggested keeping it, but changing the > magic number, so it can't be a kernel address, but I'll let him follow > up on the details. Sure! So, given the misalignment problem I discovered yesterday [1], we probably want a page_pool page to look like: unsigned long flags; unsigned long pp_magic; unsigned long xmi; unsigned long _pp_mapping_pad; dma_addr_t dma_addr; /* might be one or two words */ The only real restriction here is that pp_magic should not be a valid pointer, and it must have the bottom bit clear. I'd recommend something like: #define PP_MAGIC(0x20 + POISON_POINTER_DELTA) This leaves page->mapping as NULL, so you don't have to worry about clearing it before free. [1] https://lore.kernel.org/linux-mm/20210410024313.gx2531...@casper.infradead.org/
[PATCH] Staging: rtl8192u: ieee80211: remove odd backslash.
From: Dmitrii Wolf
This backslash should be deleted - looks like leftover and not needed.
---
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 690b664df8fa..25ea8e1b6b65 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -2052,7 +2052,7 @@ void ieee80211_softmac_xmit(struct ieee80211_txb *txb,
struct ieee80211_device *
#else
if ((skb_queue_len(>skb_waitQ[queue_index]) != 0) ||
#endif
- (!ieee->check_nic_enough_desc(ieee->dev, queue_index)) || \
+ (!ieee->check_nic_enough_desc(ieee->dev, queue_index)) ||
(ieee->queue_stop)) {
/* insert the skb packet to the wait queue */
/* as for the completion function, it does not need
--
2.25.1
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote: > Can I ask someone with more > technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about > the possible challenges of nouveau taking matters into its own hand rather > than keeping this PCI quirk around? It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS? Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit. Thanks, Lukas
Re: [PATCH] staging: mt7621-pci: stop using of_pci_range_to_resource
Hi Ilya,
On Sat, Apr 10, 2021 at 7:33 PM Ilya Lipnitskiy
wrote:
>
> The logic here was already overriding the erroneous IO addresses
> returned from of_pci_range_to_resource, which is the bulk of the logic.
>
> So stop using it altogether and initialize the fields explicitly, as
> done in aeba3731b150 ("powerpc/pci: Fix IO space breakage after
> of_pci_range_to_resource() change").
>
> Signed-off-by: Ilya Lipnitskiy
> Cc: Sergio Paracuellos
> ---
> drivers/staging/mt7621-pci/pci-mt7621.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
Looks good to me, thanks! I have also tested this in gnubee pc1
platform with no regressions at all when io bars are assigned:
[ 16.378956] mt7621-pci 1e14.pcie: host bridge /pcie@1e14 ranges:
[ 16.392405] mt7621-pci 1e14.pcie: MEM
0x006000..0x006fff -> 0x00
[ 16.408796] mt7621-pci 1e14.pcie: IO
0x001e16..0x001e16 -> 0x00
[ 16.425264] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000
(dual port = 1)
[ 16.440452] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000
(dual port = 0)
[ 16.678713] mt7621-pci 1e14.pcie: PCIE0 enabled
[ 16.688435] mt7621-pci 1e14.pcie: PCIE1 enabled
[ 16.698160] mt7621-pci 1e14.pcie: PCIE2 enabled
[ 16.707886] mt7621-pci 1e14.pcie: PCI coherence region base:
0x6000, mask/settings: 0xf002
[ 16.726623] mt7621-pci 1e14.pcie: PCI host bridge to bus :00
[ 16.739309] pci_bus :00: root bus resource [io 0x1e16-0x1e16]
[ 16.753008] pci_bus :00: root bus resource [mem 0x6000-0x6fff]
[ 16.766709] pci_bus :00: root bus resource [bus 00-ff]
[ 16.777649] pci_bus :00: root bus resource [mem
0x6000-0x6fff] (bus address [0x-0x0fff])
[ 16.797986] pci :00:00.0: [0e8d:0801] type 01 class 0x060400
[ 16.809973] pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
[ 16.822467] pci :00:00.0: reg 0x14: initial BAR value 0x invalid
[ 16.836511] pci :00:00.0: reg 0x14: [mem size 0x0001]
[ 16.848048] pci :00:00.0: supports D1
[ 16.856051] pci :00:00.0: PME# supported from D0 D1 D3hot
[ 16.867943] pci :00:01.0: [0e8d:0801] type 01 class 0x060400
[ 16.879960] pci :00:01.0: reg 0x10: [mem 0x-0x7fff]
[ 16.892454] pci :00:01.0: reg 0x14: initial BAR value 0x invalid
[ 16.906497] pci :00:01.0: reg 0x14: [mem size 0x0001]
[ 16.918040] pci :00:01.0: supports D1
[ 16.926031] pci :00:01.0: PME# supported from D0 D1 D3hot
[ 16.937903] pci :00:02.0: [0e8d:0801] type 01 class 0x060400
[ 16.949915] pci :00:02.0: reg 0x10: [mem 0x-0x7fff]
[ 16.962412] pci :00:02.0: reg 0x14: initial BAR value 0x invalid
[ 16.976466] pci :00:02.0: reg 0x14: [mem size 0x0001]
[ 16.987991] pci :00:02.0: supports D1
[ 16.995986] pci :00:02.0: PME# supported from D0 D1 D3hot
[ 17.008716] pci :00:00.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[ 17.024695] pci :00:01.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[ 17.040654] pci :00:02.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[ 17.056868] pci :01:00.0: [1b21:0611] type 00 class 0x010185
[ 17.068882] pci :01:00.0: reg 0x10: [io 0x-0x0007]
[ 17.080003] pci :01:00.0: reg 0x14: [io 0x-0x0003]
[ 17.091115] pci :01:00.0: reg 0x18: [io 0x-0x0007]
[ 17.102238] pci :01:00.0: reg 0x1c: [io 0x-0x0003]
[ 17.113350] pci :01:00.0: reg 0x20: [io 0x-0x000f]
[ 17.124463] pci :01:00.0: reg 0x24: initial BAR value 0x invalid
[ 17.138508] pci :01:00.0: reg 0x24: [mem size 0x0200]
[ 17.150115] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at :00:00.0 (capable of 4.000
Gb/s with 5.0 GT/s PCIe x1 link)
[ 17.204594] pci :00:00.0: PCI bridge to [bus 01-ff]
[ 17.215109] pci :00:00.0: bridge window [io 0x-0x0fff]
[ 17.227257] pci :00:00.0: bridge window [mem 0x6000-0x600f]
[ 17.240785] pci :00:00.0: bridge window [mem
0x6000-0x600f pref]
[ 17.255183] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[ 17.268648] pci :02:00.0: [1b21:0611] type 00 class 0x010185
[ 17.280671] pci :02:00.0: reg 0x10: [io 0x-0x0007]
[ 17.291785] pci :02:00.0: reg 0x14: [io 0x-0x0003]
[ 17.302898] pci :02:00.0: reg 0x18: [io 0x-0x0007]
[ 17.314012] pci :02:00.0: reg 0x1c: [io 0x-0x0003]
[ 17.325127] pci :02:00.0: reg 0x20: [io 0x-0x000f]
[ 17.336241] pci :02:00.0: reg 0x24: initial BAR value 0x invalid
[ 17.350279] pci :02:00.0: reg 0x24: [mem size 0x0200]
[ 17.361893] pci :02:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at :00:01.0 (capable of 4.000
Gb/s with 5.0
[PATCH] Staging: media: atomisp: pci: fixed a curly bracket coding style issue.
From: Dmitrii Wolf
Fixed a coding style issue.
---
drivers/staging/media/atomisp/pci/atomisp_csi2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_csi2.c
b/drivers/staging/media/atomisp/pci/atomisp_csi2.c
index 060b8765ae96..200f16994f3a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_csi2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_csi2.c
@@ -29,7 +29,8 @@ static struct v4l2_mbus_framefmt *__csi2_get_format(struct
v4l2_subdev_pad_config *cfg,
enum
v4l2_subdev_format_whence
- which, unsigned int pad) {
+ which, unsigned int pad)
+{
if (which == V4L2_SUBDEV_FORMAT_TRY)
return v4l2_subdev_get_try_format(>subdev, cfg, pad);
else
--
2.25.1
Re: Bogus struct page layout on 32-bit
On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox wrote:
> + dma_addr_t dma_addr __packed;
> };
> struct {/* slab, slob and slub */
> union {
>
> but I don't know if GCC is smart enough to realise that dma_addr is now
> on an 8 byte boundary and it can use a normal instruction to access it,
> or whether it'll do something daft like use byte loads to access it.
>
> We could also do:
>
> + dma_addr_t dma_addr __packed __aligned(sizeof(void
> *));
>
> and I see pahole, at least sees this correctly:
>
> struct {
> long unsigned int _page_pool_pad; /* 4 4 */
> dma_addr_t dma_addr __attribute__((__aligned__(4)));
> /* 8 8 */
> } __attribute__((__packed__)) __attribute__((__aligned__(4)));
>
> This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
> / dma_addr_t. Advice, please?
I've tried out what gcc would make of this: https://godbolt.org/z/aTEbxxbG3
struct page {
short a;
struct {
short b;
long long c __attribute__((packed, aligned(2)));
} __attribute__((packed));
} __attribute__((aligned(8)));
In this structure, 'c' is clearly aligned to eight bytes, and gcc does
realize that
it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden on
struct members with less than 4 byte alignment. However, it also complains
that passing a pointer to 'c' into a function that expects a 'long long' is not
allowed because alignof(c) is only '2' here.
(I used 'short' here because I having a 64-bit member misaligned by four
bytes wouldn't make a difference to the instructions on Arm, or any other
32-bit architecture I can think of, regardless of the ABI requirements).
Arnd
[PATCH v4 11/11] pinctrl: Ingenic: Add pinctrl driver for X2000.
Add support for probing the pinctrl-ingenic driver on the
X2000 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Split lcd pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
3.Replace "lcd-rgb-xxx" with "lcd-tft-xxx" to avoid confusion.
drivers/pinctrl/pinctrl-ingenic.c | 512 +-
1 file changed, 503 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 9bf9100..c0e647b 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -57,6 +57,10 @@
#define X1830_GPIO_PEL 0x110
#define X1830_GPIO_PEH 0x120
+#define X2000_GPIO_EDG 0x70
+#define X2000_GPIO_PEPU0x80
+#define X2000_GPIO_PEPD0x90
+
#define REG_SET(x) ((x) + 0x4)
#define REG_CLEAR(x) ((x) + 0x8)
@@ -94,6 +98,7 @@ enum jz_version {
ID_X1000,
ID_X1500,
ID_X1830,
+ ID_X2000,
};
struct ingenic_chip_info {
@@ -2313,6 +2318,449 @@ static const struct ingenic_chip_info x1830_chip_info =
{
.pull_downs = x1830_pull_downs,
};
+static const u32 x2000_pull_ups[5] = {
+ 0x0003, 0x, 0x1ff0, 0xc7fe3f3f, 0x8fff003f,
+};
+
+static const u32 x2000_pull_downs[5] = {
+ 0x0003, 0x, 0x1ff0, 0x, 0x8fff003f,
+};
+
+static int x2000_uart0_data_pins[] = { 0x77, 0x78, };
+static int x2000_uart0_hwflow_pins[] = { 0x79, 0x7a, };
+static int x2000_uart1_data_pins[] = { 0x57, 0x58, };
+static int x2000_uart1_hwflow_pins[] = { 0x55, 0x56, };
+static int x2000_uart2_data_pins[] = { 0x7e, 0x7f, };
+static int x2000_uart3_data_c_pins[] = { 0x59, 0x5a, };
+static int x2000_uart3_data_d_pins[] = { 0x62, 0x63, };
+static int x2000_uart3_hwflow_c_pins[] = { 0x5b, 0x5c, };
+static int x2000_uart3_hwflow_d_pins[] = { 0x60, 0x61, };
+static int x2000_uart4_data_a_pins[] = { 0x02, 0x03, };
+static int x2000_uart4_data_c_pins[] = { 0x4b, 0x4c, };
+static int x2000_uart4_hwflow_a_pins[] = { 0x00, 0x01, };
+static int x2000_uart4_hwflow_c_pins[] = { 0x49, 0x4a, };
+static int x2000_uart5_data_a_pins[] = { 0x04, 0x05, };
+static int x2000_uart5_data_c_pins[] = { 0x45, 0x46, };
+static int x2000_uart6_data_a_pins[] = { 0x06, 0x07, };
+static int x2000_uart6_data_c_pins[] = { 0x47, 0x48, };
+static int x2000_uart7_data_a_pins[] = { 0x08, 0x09, };
+static int x2000_uart7_data_c_pins[] = { 0x41, 0x42, };
+static int x2000_uart8_data_pins[] = { 0x3c, 0x3d, };
+static int x2000_uart9_data_pins[] = { 0x3e, 0x3f, };
+static int x2000_sfc0_d_pins[] = { 0x73, 0x74, 0x75, 0x76, 0x71, 0x72, };
+static int x2000_sfc0_e_pins[] = { 0x92, 0x93, 0x94, 0x95, 0x90, 0x91, };
+static int x2000_sfc1_pins[] = { 0x77, 0x78, 0x79, 0x7a, };
+static int x2000_ssi0_dt_b_pins[] = { 0x3e, };
+static int x2000_ssi0_dt_d_pins[] = { 0x69, };
+static int x2000_ssi0_dr_b_pins[] = { 0x3d, };
+static int x2000_ssi0_dr_d_pins[] = { 0x6a, };
+static int x2000_ssi0_clk_b_pins[] = { 0x3f, };
+static int x2000_ssi0_clk_d_pins[] = { 0x68, };
+static int x2000_ssi0_ce0_b_pins[] = { 0x3c, };
+static int x2000_ssi0_ce0_d_pins[] = { 0x6d, };
+static int x2000_ssi1_dt_c_pins[] = { 0x4b, };
+static int x2000_ssi1_dt_d_pins[] = { 0x72, };
+static int x2000_ssi1_dt_e_pins[] = { 0x91, };
+static int x2000_ssi1_dr_c_pins[] = { 0x4a, };
+static int x2000_ssi1_dr_d_pins[] = { 0x73, };
+static int x2000_ssi1_dr_e_pins[] = { 0x92, };
+static int x2000_ssi1_clk_c_pins[] = { 0x4c, };
+static int x2000_ssi1_clk_d_pins[] = { 0x71, };
+static int x2000_ssi1_clk_e_pins[] = { 0x90, };
+static int x2000_ssi1_ce0_c_pins[] = { 0x49, };
+static int x2000_ssi1_ce0_d_pins[] = { 0x76, };
+static int x2000_ssi1_ce0_e_pins[] = { 0x95, };
+static int x2000_mmc0_1bit_pins[] = { 0x71, 0x72, 0x73, };
+static int x2000_mmc0_4bit_pins[] = { 0x74, 0x75, 0x75, };
+static int x2000_mmc0_8bit_pins[] = { 0x77, 0x78, 0x79, 0x7a, };
+static int x2000_mmc1_1bit_pins[] = { 0x68, 0x69, 0x6a, };
+static int x2000_mmc1_4bit_pins[] = { 0x6b, 0x6c, 0x6d, };
+static int x2000_mmc2_1bit_pins[] = { 0x80, 0x81, 0x82, };
+static int x2000_mmc2_4bit_pins[] = { 0x83, 0x84, 0x85, };
+static int x2000_emc_8bit_data_pins[] = {
+ 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+};
+static int x2000_emc_16bit_data_pins[] = {
+ 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
+};
+static int x2000_emc_addr_pins[] = {
+ 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
+ 0x28, 0x29, 0x2a, 0x2b, 0x2c,
+};
+static int x2000_emc_rd_we_pins[] = { 0x2d, 0x2e, };
+static int x2000_emc_wait_pins[] = { 0x2f, };
+static int x2000_emc_cs1_pins[] = { 0x57, };
+static int x2000_emc_cs2_pins[] = { 0x58, };
+static int x2000_i2c0_pins[] = { 0x4e,
[PATCH v4 10/11] pinctrl: Ingenic: Add pinctrl driver for JZ4775.
Add support for probing the pinctrl-ingenic driver on the
JZ4775 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Split lcd pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
drivers/pinctrl/pinctrl-ingenic.c | 275 ++
1 file changed, 275 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 3b649fb..9bf9100 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -89,6 +89,7 @@ enum jz_version {
ID_JZ4755,
ID_JZ4760,
ID_JZ4770,
+ ID_JZ4775,
ID_JZ4780,
ID_X1000,
ID_X1500,
@@ -1261,6 +1262,275 @@ static const struct ingenic_chip_info jz4770_chip_info
= {
.pull_downs = jz4770_pull_downs,
};
+static const u32 jz4775_pull_ups[7] = {
+ 0x28ff00ff, 0xf030f3fc, 0x0fff, 0xfffe4000, 0xf0fc, 0xf00f,
0xf3c0,
+};
+
+static const u32 jz4775_pull_downs[7] = {
+ 0x, 0x00030c03, 0x, 0x8000, 0x0403, 0x0ff0,
0x00030c00,
+};
+
+static int jz4775_uart0_data_pins[] = { 0xa0, 0xa3, };
+static int jz4775_uart0_hwflow_pins[] = { 0xa1, 0xa2, };
+static int jz4775_uart1_data_pins[] = { 0x7a, 0x7c, };
+static int jz4775_uart1_hwflow_pins[] = { 0x7b, 0x7d, };
+static int jz4775_uart2_data_c_pins[] = { 0x54, 0x4a, };
+static int jz4775_uart2_data_f_pins[] = { 0xa5, 0xa4, };
+static int jz4775_uart3_data_pins[] = { 0x1e, 0x1f, };
+static int jz4775_ssi_dt_a_pins[] = { 0x13, };
+static int jz4775_ssi_dt_d_pins[] = { 0x75, };
+static int jz4775_ssi_dr_a_pins[] = { 0x14, };
+static int jz4775_ssi_dr_d_pins[] = { 0x74, };
+static int jz4775_ssi_clk_a_pins[] = { 0x12, };
+static int jz4775_ssi_clk_d_pins[] = { 0x78, };
+static int jz4775_ssi_gpc_pins[] = { 0x76, };
+static int jz4775_ssi_ce0_a_pins[] = { 0x17, };
+static int jz4775_ssi_ce0_d_pins[] = { 0x79, };
+static int jz4775_ssi_ce1_pins[] = { 0x77, };
+static int jz4775_mmc0_1bit_a_pins[] = { 0x12, 0x13, 0x14, };
+static int jz4775_mmc0_4bit_a_pins[] = { 0x15, 0x16, 0x17, };
+static int jz4775_mmc0_8bit_a_pins[] = { 0x04, 0x05, 0x06, 0x07, };
+static int jz4775_mmc0_1bit_e_pins[] = { 0x9c, 0x9d, 0x94, };
+static int jz4775_mmc0_4bit_e_pins[] = { 0x95, 0x96, 0x97, };
+static int jz4775_mmc1_1bit_d_pins[] = { 0x78, 0x79, 0x74, };
+static int jz4775_mmc1_4bit_d_pins[] = { 0x75, 0x76, 0x77, };
+static int jz4775_mmc1_1bit_e_pins[] = { 0x9c, 0x9d, 0x94, };
+static int jz4775_mmc1_4bit_e_pins[] = { 0x95, 0x96, 0x97, };
+static int jz4775_mmc2_1bit_b_pins[] = { 0x3c, 0x3d, 0x34, };
+static int jz4775_mmc2_4bit_b_pins[] = { 0x35, 0x3e, 0x3f, };
+static int jz4775_mmc2_1bit_e_pins[] = { 0x9c, 0x9d, 0x94, };
+static int jz4775_mmc2_4bit_e_pins[] = { 0x95, 0x96, 0x97, };
+static int jz4775_nemc_8bit_data_pins[] = {
+ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+};
+static int jz4775_nemc_16bit_data_pins[] = {
+ 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd1,
+};
+static int jz4775_nemc_cle_ale_pins[] = { 0x20, 0x21, };
+static int jz4775_nemc_addr_pins[] = { 0x22, 0x23, 0x24, 0x25, };
+static int jz4775_nemc_rd_we_pins[] = { 0x10, 0x11, };
+static int jz4775_nemc_frd_fwe_pins[] = { 0x12, 0x13, };
+static int jz4775_nemc_wait_pins[] = { 0x1b, };
+static int jz4775_nemc_cs1_pins[] = { 0x15, };
+static int jz4775_nemc_cs2_pins[] = { 0x16, };
+static int jz4775_nemc_cs3_pins[] = { 0x17, };
+static int jz4775_i2c0_pins[] = { 0x7e, 0x7f, };
+static int jz4775_i2c1_pins[] = { 0x9e, 0x9f, };
+static int jz4775_i2c2_pins[] = { 0x80, 0x83, };
+static int jz4775_i2s_data_tx_pins[] = { 0xa3, };
+static int jz4775_i2s_data_rx_pins[] = { 0xa2, };
+static int jz4775_i2s_clk_txrx_pins[] = { 0xa0, 0xa1, };
+static int jz4775_i2s_sysclk_pins[] = { 0x83, };
+static int jz4775_cim_pins[] = {
+ 0x26, 0x27, 0x28, 0x29,
+ 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31,
+};
+static int jz4775_lcd_8bit_pins[] = {
+ 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x4c, 0x4d,
+ 0x48, 0x52, 0x53,
+};
+static int jz4775_lcd_16bit_pins[] = {
+ 0x4e, 0x4f, 0x50, 0x51, 0x56, 0x57, 0x58, 0x59,
+};
+static int jz4775_lcd_18bit_pins[] = {
+ 0x5a, 0x5b,
+};
+static int jz4775_lcd_24bit_pins[] = {
+ 0x40, 0x41, 0x4a, 0x4b, 0x54, 0x55,
+};
+static int jz4775_lcd_special_pins[] = { 0x54, 0x4a, 0x41, 0x40, };
+static int jz4775_lcd_generic_pins[] = { 0x49, };
+static int jz4775_pwm_pwm0_pins[] = { 0x80, };
+static int jz4775_pwm_pwm1_pins[] = { 0x81, };
+static int jz4775_pwm_pwm2_pins[] = { 0x82, };
+static int jz4775_pwm_pwm3_pins[] = { 0x83, };
+static int jz4775_mac_rmii_pins[] = {
+ 0xa9, 0xab, 0xaa, 0xac, 0xa5, 0xa4, 0xad, 0xae, 0xa6, 0xa8,
+};
+static int jz4775_mac_mii_pins[] = {
+ 0x7b, 0x7a, 0x7d, 0x7c, 0xa7, 0x24, 0xaf,
+};
+static int jz4775_mac_rgmii_pins[] = {
+ 0xa9, 0x7b, 0x7a, 0xab, 0xaa, 0xac, 0x7d,
[PATCH v4 09/11] pinctrl: Ingenic: Add pinctrl driver for JZ4755.
Add support for probing the pinctrl-ingenic driver on the
JZ4755 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Split lcd pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
drivers/pinctrl/pinctrl-ingenic.c | 139 ++
1 file changed, 139 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 02fe3bf..3b649fb 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -86,6 +86,7 @@ enum jz_version {
ID_JZ4740,
ID_JZ4725B,
ID_JZ4750,
+ ID_JZ4755,
ID_JZ4760,
ID_JZ4770,
ID_JZ4780,
@@ -562,6 +563,138 @@ static const struct ingenic_chip_info jz4750_chip_info = {
.pull_downs = jz4750_pull_downs,
};
+static const u32 jz4755_pull_ups[6] = {
+ 0x, 0x, 0x0fff, 0x, 0x33dc3fff, 0xfc00,
+};
+
+static const u32 jz4755_pull_downs[6] = {
+ 0x, 0x, 0x, 0x, 0x, 0x,
+};
+
+static int jz4755_uart0_data_pins[] = { 0x7c, 0x7d, };
+static int jz4755_uart0_hwflow_pins[] = { 0x7e, 0x7f, };
+static int jz4755_uart1_data_pins[] = { 0x97, 0x99, };
+static int jz4755_uart2_data_pins[] = { 0x9f, };
+static int jz4755_mmc0_1bit_pins[] = { 0x2f, 0x50, 0x5c, };
+static int jz4755_mmc0_4bit_pins[] = { 0x5d, 0x5b, 0x51, };
+static int jz4755_mmc1_1bit_pins[] = { 0x3a, 0x3d, 0x3c, };
+static int jz4755_mmc1_4bit_pins[] = { 0x3b, 0x3e, 0x3f, };
+static int jz4755_i2c_pins[] = { 0x8c, 0x8d, };
+static int jz4755_cim_pins[] = {
+ 0x89, 0x8b, 0x8a, 0x88,
+ 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+};
+static int jz4755_lcd_8bit_pins[] = {
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+ 0x72, 0x73, 0x74,
+};
+static int jz4755_lcd_16bit_pins[] = {
+ 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+};
+static int jz4755_lcd_18bit_pins[] = { 0x70, 0x71, };
+static int jz4755_lcd_24bit_pins[] = { 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, };
+static int jz4755_lcd_special_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4755_lcd_generic_pins[] = { 0x75, };
+static int jz4755_nand_cs1_pins[] = { 0x55, };
+static int jz4755_nand_cs2_pins[] = { 0x56, };
+static int jz4755_nand_cs3_pins[] = { 0x57, };
+static int jz4755_nand_cs4_pins[] = { 0x58, };
+static int jz4755_nand_fre_fwe_pins[] = { 0x5c, 0x5d, };
+static int jz4755_pwm_pwm0_pins[] = { 0x94, };
+static int jz4755_pwm_pwm1_pins[] = { 0xab, };
+static int jz4755_pwm_pwm2_pins[] = { 0x96, };
+static int jz4755_pwm_pwm3_pins[] = { 0x97, };
+static int jz4755_pwm_pwm4_pins[] = { 0x98, };
+static int jz4755_pwm_pwm5_pins[] = { 0x99, };
+
+static u8 jz4755_mmc0_1bit_funcs[] = { 2, 2, 1, };
+static u8 jz4755_mmc0_4bit_funcs[] = { 1, 0, 1, };
+static u8 jz4755_lcd_24bit_funcs[] = { 1, 1, 1, 1, 0, 0, };
+
+static const struct group_desc jz4755_groups[] = {
+ INGENIC_PIN_GROUP("uart0-data", jz4755_uart0_data, 0),
+ INGENIC_PIN_GROUP("uart0-hwflow", jz4755_uart0_hwflow, 0),
+ INGENIC_PIN_GROUP("uart1-data", jz4755_uart1_data, 0),
+ INGENIC_PIN_GROUP("uart2-data", jz4755_uart2_data, 1),
+ INGENIC_PIN_GROUP_FUNCS("mmc0-1bit", jz4755_mmc0_1bit,
+ jz4755_mmc0_1bit_funcs),
+ INGENIC_PIN_GROUP_FUNCS("mmc0-4bit", jz4755_mmc0_4bit,
+ jz4755_mmc0_4bit_funcs),
+ INGENIC_PIN_GROUP("mmc1-1bit", jz4755_mmc1_1bit, 1),
+ INGENIC_PIN_GROUP("mmc1-4bit", jz4755_mmc1_4bit, 1),
+ INGENIC_PIN_GROUP("i2c-data", jz4755_i2c, 0),
+ INGENIC_PIN_GROUP("cim-data", jz4755_cim, 0),
+ INGENIC_PIN_GROUP("lcd-8bit", jz4755_lcd_8bit, 0),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4755_lcd_16bit, 0),
+ INGENIC_PIN_GROUP("lcd-18bit", jz4755_lcd_18bit, 0),
+ INGENIC_PIN_GROUP_FUNCS("lcd-24bit", jz4755_lcd_24bit,
+ jz4755_lcd_24bit_funcs),
+ INGENIC_PIN_GROUP("lcd-special", jz4755_lcd_special, 0),
+ INGENIC_PIN_GROUP("lcd-generic", jz4755_lcd_generic, 0),
+ INGENIC_PIN_GROUP("nand-cs1", jz4755_nand_cs1, 0),
+ INGENIC_PIN_GROUP("nand-cs2", jz4755_nand_cs2, 0),
+ INGENIC_PIN_GROUP("nand-cs3", jz4755_nand_cs3, 0),
+ INGENIC_PIN_GROUP("nand-cs4", jz4755_nand_cs4, 0),
+ INGENIC_PIN_GROUP("nand-fre-fwe", jz4755_nand_fre_fwe, 0),
+ INGENIC_PIN_GROUP("pwm0", jz4755_pwm_pwm0, 0),
+ INGENIC_PIN_GROUP("pwm1", jz4755_pwm_pwm1, 1),
+ INGENIC_PIN_GROUP("pwm2", jz4755_pwm_pwm2, 0),
+ INGENIC_PIN_GROUP("pwm3", jz4755_pwm_pwm3, 0),
+ INGENIC_PIN_GROUP("pwm4", jz4755_pwm_pwm4, 0),
+ INGENIC_PIN_GROUP("pwm5", jz4755_pwm_pwm5, 0),
+};
+
+static const char *jz4755_uart0_groups[] = { "uart0-data", "uart0-hwflow", };
+static const char *jz4755_uart1_groups[] = { "uart1-data", };
+static const char
[PATCH v4 07/11] pinctrl: Ingenic: Add pinctrl driver for JZ4730.
Add support for probing the pinctrl-ingenic driver on the
JZ4730 SoC from Ingenic.
This driver is derived from Paul Boddie. It is worth to
noting that the JZ4730 SoC is special in having two control
registers (upper/lower), so add code to handle the JZ4730
specific register offsets and some register pairs which have
2 bits for each GPIO pin.
Tested-by: H. Nikolaus Schaller # on Letux400
Co-developed-by: Paul Boddie
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Use "lcd-special" and "lcd-generic" instead "lcd-16bit-tft".
2.Adjust function names to avoid confusion.
3.Improve the structure of some functions.
4.Modify the format of comment.
5.Simplify code using GENMASK.
6.Drop unnecessary mask.
drivers/pinctrl/pinctrl-ingenic.c | 232 +++---
1 file changed, 216 insertions(+), 16 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 009901b..4c48250 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -3,8 +3,8 @@
* Ingenic SoCs pinctrl driver
*
* Copyright (c) 2017 Paul Cercueil
- * Copyright (c) 2019 周琰杰 (Zhou Yanjie)
* Copyright (c) 2017, 2019 Paul Boddie
+ * Copyright (c) 2019, 2020 周琰杰 (Zhou Yanjie)
*/
#include
@@ -29,6 +29,17 @@
#define GPIO_PIN 0x00
#define GPIO_MSK 0x20
+#define JZ4730_GPIO_DATA 0x00
+#define JZ4730_GPIO_GPDIR 0x04
+#define JZ4730_GPIO_GPPUR 0x0c
+#define JZ4730_GPIO_GPALR 0x10
+#define JZ4730_GPIO_GPAUR 0x14
+#define JZ4730_GPIO_GPIDLR 0x18
+#define JZ4730_GPIO_GPIDUR 0x1c
+#define JZ4730_GPIO_GPIER 0x20
+#define JZ4730_GPIO_GPIMR 0x24
+#define JZ4730_GPIO_GPFR 0x28
+
#define JZ4740_GPIO_DATA 0x10
#define JZ4740_GPIO_PULL_DIS 0x30
#define JZ4740_GPIO_FUNC 0x40
@@ -57,6 +68,7 @@
#define GPIO_PULL_DOWN 2
#define PINS_PER_GPIO_CHIP 32
+#define JZ4730_PINS_PER_PAIRED_REG 16
#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs) \
{ \
@@ -70,6 +82,7 @@
INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
enum jz_version {
+ ID_JZ4730,
ID_JZ4740,
ID_JZ4725B,
ID_JZ4760,
@@ -110,6 +123,99 @@ struct ingenic_gpio_chip {
unsigned int irq, reg_base;
};
+static const u32 jz4730_pull_ups[4] = {
+ 0x3fa3320f, 0xf200, 0x, 0x,
+};
+
+static const u32 jz4730_pull_downs[4] = {
+ 0x0df0, 0x0dff, 0x, 0x,
+};
+
+static int jz4730_mmc_1bit_pins[] = { 0x27, 0x26, 0x22, };
+static int jz4730_mmc_4bit_pins[] = { 0x23, 0x24, 0x25, };
+static int jz4730_uart0_data_pins[] = { 0x7e, 0x7f, };
+static int jz4730_uart1_data_pins[] = { 0x18, 0x19, };
+static int jz4730_uart2_data_pins[] = { 0x6f, 0x7d, };
+static int jz4730_uart3_data_pins[] = { 0x10, 0x15, };
+static int jz4730_uart3_hwflow_pins[] = { 0x11, 0x17, };
+static int jz4730_lcd_8bit_pins[] = {
+ 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
+ 0x3a, 0x39, 0x38,
+};
+static int jz4730_lcd_16bit_pins[] = {
+ 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+};
+static int jz4730_lcd_special_pins[] = { 0x3d, 0x3c, 0x3e, 0x3f, };
+static int jz4730_lcd_generic_pins[] = { 0x3b, };
+static int jz4730_nand_cs1_pins[] = { 0x53, };
+static int jz4730_nand_cs2_pins[] = { 0x54, };
+static int jz4730_nand_cs3_pins[] = { 0x55, };
+static int jz4730_nand_cs4_pins[] = { 0x56, };
+static int jz4730_nand_cs5_pins[] = { 0x57, };
+static int jz4730_pwm_pwm0_pins[] = { 0x5e, };
+static int jz4730_pwm_pwm1_pins[] = { 0x5f, };
+
+static u8 jz4730_lcd_8bit_funcs[] = { 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, };
+
+static const struct group_desc jz4730_groups[] = {
+ INGENIC_PIN_GROUP("mmc-1bit", jz4730_mmc_1bit, 1),
+ INGENIC_PIN_GROUP("mmc-4bit", jz4730_mmc_4bit, 1),
+ INGENIC_PIN_GROUP("uart0-data", jz4730_uart0_data, 1),
+ INGENIC_PIN_GROUP("uart1-data", jz4730_uart1_data, 1),
+ INGENIC_PIN_GROUP("uart2-data", jz4730_uart2_data, 1),
+ INGENIC_PIN_GROUP("uart3-data", jz4730_uart3_data, 1),
+ INGENIC_PIN_GROUP("uart3-hwflow", jz4730_uart3_hwflow, 1),
+ INGENIC_PIN_GROUP_FUNCS("lcd-8bit", jz4730_lcd_8bit,
jz4730_lcd_8bit_funcs),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4730_lcd_16bit, 1),
+ INGENIC_PIN_GROUP("lcd-special", jz4730_lcd_special, 1),
+ INGENIC_PIN_GROUP("lcd-generic", jz4730_lcd_generic, 1),
+ INGENIC_PIN_GROUP("nand-cs1",
[PATCH v4 08/11] pinctrl: Ingenic: Add pinctrl driver for JZ4750.
Add support for probing the pinctrl-ingenic driver on the
JZ4750 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
---
Notes:
v3:
New patch.
v3->v4:
1.Use "lcd-special" and "lcd-generic" instead "lcd-18bit-tft".
2.Drop "lcd-no-pins" which is pointless.
drivers/pinctrl/pinctrl-ingenic.c | 139 ++
1 file changed, 139 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 4c48250..02fe3bf 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -85,6 +85,7 @@ enum jz_version {
ID_JZ4730,
ID_JZ4740,
ID_JZ4725B,
+ ID_JZ4750,
ID_JZ4760,
ID_JZ4770,
ID_JZ4780,
@@ -427,6 +428,140 @@ static const struct ingenic_chip_info jz4725b_chip_info =
{
.pull_downs = jz4740_pull_downs,
};
+static const u32 jz4750_pull_ups[6] = {
+ 0x, 0x, 0x3fff, 0x7fff, 0x1fff3fff, 0x00ff,
+};
+
+static const u32 jz4750_pull_downs[6] = {
+ 0x, 0x, 0x, 0x, 0x, 0x,
+};
+
+static int jz4750_uart0_data_pins[] = { 0xa4, 0xa5, };
+static int jz4750_uart0_hwflow_pins[] = { 0xa6, 0xa7, };
+static int jz4750_uart1_data_pins[] = { 0x90, 0x91, };
+static int jz4750_uart1_hwflow_pins[] = { 0x92, 0x93, };
+static int jz4750_uart2_data_pins[] = { 0x9b, 0x9a, };
+static int jz4750_uart3_data_pins[] = { 0xb0, 0xb1, };
+static int jz4750_uart3_hwflow_pins[] = { 0xb2, 0xb3, };
+static int jz4750_mmc0_1bit_pins[] = { 0xa8, 0xa9, 0xa0, };
+static int jz4750_mmc0_4bit_pins[] = { 0xa1, 0xa2, 0xa3, };
+static int jz4750_mmc0_8bit_pins[] = { 0xa4, 0xa5, 0xa6, 0xa7, };
+static int jz4750_mmc1_1bit_pins[] = { 0xae, 0xaf, 0xaa, };
+static int jz4750_mmc1_4bit_pins[] = { 0xab, 0xac, 0xad, };
+static int jz4750_i2c_pins[] = { 0x8c, 0x8d, };
+static int jz4750_cim_pins[] = {
+ 0x89, 0x8b, 0x8a, 0x88,
+ 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+};
+static int jz4750_lcd_8bit_pins[] = {
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+ 0x72, 0x73, 0x74,
+};
+static int jz4750_lcd_16bit_pins[] = {
+ 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+};
+static int jz4750_lcd_18bit_pins[] = { 0x70, 0x71, };
+static int jz4750_lcd_special_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4750_lcd_generic_pins[] = { 0x75, };
+static int jz4750_nand_cs1_pins[] = { 0x55, };
+static int jz4750_nand_cs2_pins[] = { 0x56, };
+static int jz4750_nand_cs3_pins[] = { 0x57, };
+static int jz4750_nand_cs4_pins[] = { 0x58, };
+static int jz4750_nand_fre_fwe_pins[] = { 0x5c, 0x5d, };
+static int jz4750_pwm_pwm0_pins[] = { 0x94, };
+static int jz4750_pwm_pwm1_pins[] = { 0x95, };
+static int jz4750_pwm_pwm2_pins[] = { 0x96, };
+static int jz4750_pwm_pwm3_pins[] = { 0x97, };
+static int jz4750_pwm_pwm4_pins[] = { 0x98, };
+static int jz4750_pwm_pwm5_pins[] = { 0x99, };
+
+static const struct group_desc jz4750_groups[] = {
+ INGENIC_PIN_GROUP("uart0-data", jz4750_uart0_data, 1),
+ INGENIC_PIN_GROUP("uart0-hwflow", jz4750_uart0_hwflow, 1),
+ INGENIC_PIN_GROUP("uart1-data", jz4750_uart1_data, 0),
+ INGENIC_PIN_GROUP("uart1-hwflow", jz4750_uart1_hwflow, 0),
+ INGENIC_PIN_GROUP("uart2-data", jz4750_uart2_data, 1),
+ INGENIC_PIN_GROUP("uart3-data", jz4750_uart3_data, 0),
+ INGENIC_PIN_GROUP("uart3-hwflow", jz4750_uart3_hwflow, 0),
+ INGENIC_PIN_GROUP("mmc0-1bit", jz4750_mmc0_1bit, 0),
+ INGENIC_PIN_GROUP("mmc0-4bit", jz4750_mmc0_4bit, 0),
+ INGENIC_PIN_GROUP("mmc0-8bit", jz4750_mmc0_8bit, 0),
+ INGENIC_PIN_GROUP("mmc1-1bit", jz4750_mmc1_1bit, 0),
+ INGENIC_PIN_GROUP("mmc1-4bit", jz4750_mmc1_4bit, 0),
+ INGENIC_PIN_GROUP("i2c-data", jz4750_i2c, 0),
+ INGENIC_PIN_GROUP("cim-data", jz4750_cim, 0),
+ INGENIC_PIN_GROUP("lcd-8bit", jz4750_lcd_8bit, 0),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4750_lcd_16bit, 0),
+ INGENIC_PIN_GROUP("lcd-18bit", jz4750_lcd_18bit, 0),
+ INGENIC_PIN_GROUP("lcd-special", jz4750_lcd_special, 0),
+ INGENIC_PIN_GROUP("lcd-generic", jz4750_lcd_generic, 0),
+ INGENIC_PIN_GROUP("nand-cs1", jz4750_nand_cs1, 0),
+ INGENIC_PIN_GROUP("nand-cs2", jz4750_nand_cs2, 0),
+ INGENIC_PIN_GROUP("nand-cs3", jz4750_nand_cs3, 0),
+ INGENIC_PIN_GROUP("nand-cs4", jz4750_nand_cs4, 0),
+ INGENIC_PIN_GROUP("nand-fre-fwe", jz4750_nand_fre_fwe, 0),
+ INGENIC_PIN_GROUP("pwm0", jz4750_pwm_pwm0, 0),
+ INGENIC_PIN_GROUP("pwm1", jz4750_pwm_pwm1, 0),
+ INGENIC_PIN_GROUP("pwm2", jz4750_pwm_pwm2, 0),
+ INGENIC_PIN_GROUP("pwm3", jz4750_pwm_pwm3, 0),
+ INGENIC_PIN_GROUP("pwm4", jz4750_pwm_pwm4, 0),
+ INGENIC_PIN_GROUP("pwm5", jz4750_pwm_pwm5, 0),
+};
+
+static const char *jz4750_uart0_groups[] = { "uart0-data", "uart0-hwflow", };
+static const char *jz4750_uart1_groups[] = {
[PATCH v4 06/11] dt-bindings: pinctrl: Add bindings for new Ingenic SoCs.
Add the pinctrl bindings for the JZ4730 SoC, the JZ4750 SoC, the JZ4755 SoC, the JZ4775 SoC and the X2000 SoC from Ingenic. Signed-off-by: 周琰杰 (Zhou Yanjie) Reviewed-by: Rob Herring --- Notes: v2: New patch. v2->v3: No change. v3->v4: 1.Add a description of JZ4725B. 2.Add Rob Herring's Reviewed-by. .../bindings/pinctrl/ingenic,pinctrl.yaml | 23 ++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index 44c04d1..a4846d78 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -17,10 +17,12 @@ description: > naming scheme "PxN" where x is a character identifying the GPIO port with which the pin is associated and N is an integer from 0 to 31 identifying the pin within that GPIO port. For example PA0 is the first pin in GPIO port A, - and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the X1830 - contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the - JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192 - pins. + and PB31 is the last pin in GPIO port B. The JZ4730, the JZ4740, the JZ4725B, + the X1000 and the X1830 contains 4 GPIO ports, PA to PD, for a total of 128 + pins. The X2000 contains 5 GPIO ports, PA to PE, for a total of 160 pins. + The JZ4750, the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains 6 GPIO + ports, PA to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO ports, + PA to PG, for a total of 224 pins. maintainers: - Paul Cercueil @@ -32,20 +34,28 @@ properties: compatible: oneOf: - enum: + - ingenic,jz4730-pinctrl - ingenic,jz4740-pinctrl - ingenic,jz4725b-pinctrl + - ingenic,jz4750-pinctrl + - ingenic,jz4755-pinctrl - ingenic,jz4760-pinctrl - ingenic,jz4770-pinctrl + - ingenic,jz4775-pinctrl - ingenic,jz4780-pinctrl - ingenic,x1000-pinctrl - ingenic,x1500-pinctrl - ingenic,x1830-pinctrl + - ingenic,x2000-pinctrl - items: - const: ingenic,jz4760b-pinctrl - const: ingenic,jz4760-pinctrl - items: - const: ingenic,x1000e-pinctrl - const: ingenic,x1000-pinctrl + - items: + - const: ingenic,x2000e-pinctrl + - const: ingenic,x2000-pinctrl reg: maxItems: 1 @@ -62,14 +72,19 @@ patternProperties: properties: compatible: enum: + - ingenic,jz4730-gpio - ingenic,jz4740-gpio - ingenic,jz4725b-gpio + - ingenic,jz4750-gpio + - ingenic,jz4755-gpio - ingenic,jz4760-gpio - ingenic,jz4770-gpio + - ingenic,jz4775-gpio - ingenic,jz4780-gpio - ingenic,x1000-gpio - ingenic,x1500-gpio - ingenic,x1830-gpio + - ingenic,x2000-gpio reg: items: -- 2.7.4
[PATCH v4 05/11] pinctrl: Ingenic: Reformat the code.
1.Move the "INGENIC_PIN_GROUP_FUNCS" to the macro definition section.
2.Add tabs before values to align the code in the macro definition section.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
Add Paul Cercueil's Reviewed-by.
v3->v4:
Add Andy Shevchenko's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 71 +++
1 file changed, 35 insertions(+), 36 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 8ed62a4..009901b 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -26,37 +26,48 @@
#include "pinconf.h"
#include "pinmux.h"
-#define GPIO_PIN 0x00
-#define GPIO_MSK 0x20
+#define GPIO_PIN 0x00
+#define GPIO_MSK 0x20
-#define JZ4740_GPIO_DATA 0x10
-#define JZ4740_GPIO_PULL_DIS 0x30
-#define JZ4740_GPIO_FUNC 0x40
-#define JZ4740_GPIO_SELECT 0x50
-#define JZ4740_GPIO_DIR0x60
-#define JZ4740_GPIO_TRIG 0x70
-#define JZ4740_GPIO_FLAG 0x80
+#define JZ4740_GPIO_DATA 0x10
+#define JZ4740_GPIO_PULL_DIS 0x30
+#define JZ4740_GPIO_FUNC 0x40
+#define JZ4740_GPIO_SELECT 0x50
+#define JZ4740_GPIO_DIR0x60
+#define JZ4740_GPIO_TRIG 0x70
+#define JZ4740_GPIO_FLAG 0x80
-#define JZ4770_GPIO_INT0x10
-#define JZ4770_GPIO_PAT1 0x30
-#define JZ4770_GPIO_PAT0 0x40
-#define JZ4770_GPIO_FLAG 0x50
-#define JZ4770_GPIO_PEN0x70
+#define JZ4770_GPIO_INT0x10
+#define JZ4770_GPIO_PAT1 0x30
+#define JZ4770_GPIO_PAT0 0x40
+#define JZ4770_GPIO_FLAG 0x50
+#define JZ4770_GPIO_PEN0x70
-#define X1830_GPIO_PEL 0x110
-#define X1830_GPIO_PEH 0x120
+#define X1830_GPIO_PEL 0x110
+#define X1830_GPIO_PEH 0x120
-#define REG_SET(x) ((x) + 0x4)
-#define REG_CLEAR(x) ((x) + 0x8)
+#define REG_SET(x) ((x) + 0x4)
+#define REG_CLEAR(x) ((x) + 0x8)
-#define REG_PZ_BASE(x) ((x) * 7)
-#define REG_PZ_GID2LD(x) ((x) * 7 + 0xf0)
+#define REG_PZ_BASE(x) ((x) * 7)
+#define REG_PZ_GID2LD(x) ((x) * 7 + 0xf0)
-#define GPIO_PULL_DIS 0
-#define GPIO_PULL_UP 1
-#define GPIO_PULL_DOWN 2
+#define GPIO_PULL_DIS 0
+#define GPIO_PULL_UP 1
+#define GPIO_PULL_DOWN 2
-#define PINS_PER_GPIO_CHIP 32
+#define PINS_PER_GPIO_CHIP 32
+
+#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs) \
+ { \
+ name, \
+ id##_pins, \
+ ARRAY_SIZE(id##_pins), \
+ funcs, \
+ }
+
+#define INGENIC_PIN_GROUP(name, id, func) \
+ INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
enum jz_version {
ID_JZ4740,
@@ -136,18 +147,6 @@ static int jz4740_pwm_pwm5_pins[] = { 0x7c, };
static int jz4740_pwm_pwm6_pins[] = { 0x7e, };
static int jz4740_pwm_pwm7_pins[] = { 0x7f, };
-
-#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs) \
- { \
- name, \
- id##_pins, \
- ARRAY_SIZE(id##_pins), \
- funcs, \
- }
-
-#define INGENIC_PIN_GROUP(name, id, func) \
- INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
-
static const struct group_desc jz4740_groups[] = {
INGENIC_PIN_GROUP("mmc-1bit", jz4740_mmc_1bit, 0),
INGENIC_PIN_GROUP("mmc-4bit", jz4740_mmc_4bit, 0),
--
2.7.4
[PATCH v4 04/11] pinctrl: Ingenic: Improve LCD pins related code.
1.In the JZ4740 part, remove pointless "lcd-no-pins", use "lcd-special"
and "lcd-generic" instead "lcd-18bit-tft". Currently, in the mainline,
no other devicetree out there is using the "lcd-18bit-tft" ABI, so we
should be able to replace it safely.
2.In the JZ4725B part, adjust the location of the LCD pins related code
to keep them consistent with the style of other parts.
3.In the JZ4760 part, add the missing comma and adjust element order in
"jz4760_lcd_special_pins[]", keep them in the order of CLS/SPL/PS/REV
like other "lcd_special_pins" arrays. And adjust the location of the
"jz4760_lcd_generic" related code to keep them consistent with the
style of other parts.
4.In the JZ4770 part, remove pointless "lcd-no-pins", add the missing
"lcd-16bit", "lcd-18bit", "lcd-special", "lcd-generic".
5.In the X1000 part and the X1500 part, remove pointless "lcd-no-pins".
6.In the X1830 part, replace "lcd-rgb-18bit" with "lcd-tft-8bit" and
"lcd-tft-24bit", because of the description of the TRANS_CONFIG.MODE
register bits in the PM manual of the X1830, shows that the X1830 only
supppots 24bit mode and 8bit mode for tft interface, only 18 pins in
the GPIO table are because of the data[17:16], the data[9:8], and the
data[1:0] has not been connected. And according to the description,
the two interfaces supported by X1830 are respectively referred to as
"TFT interface" and "SLCD interface", so the "lcd-rgb-xxx" is replaced
with "lcd-tft-xxx" to avoid confusion.
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v4:
New patch.
drivers/pinctrl/pinctrl-ingenic.c | 110 +-
1 file changed, 61 insertions(+), 49 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 72d9daa..8ed62a4 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -113,13 +113,15 @@ static int jz4740_uart0_data_pins[] = { 0x7a, 0x79, };
static int jz4740_uart0_hwflow_pins[] = { 0x7e, 0x7f, };
static int jz4740_uart1_data_pins[] = { 0x7e, 0x7f, };
static int jz4740_lcd_8bit_pins[] = {
- 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x52, 0x53, 0x54,
+ 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
+ 0x52, 0x53, 0x54,
};
static int jz4740_lcd_16bit_pins[] = {
- 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x55,
+ 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
};
static int jz4740_lcd_18bit_pins[] = { 0x50, 0x51, };
-static int jz4740_lcd_18bit_tft_pins[] = { 0x56, 0x57, 0x31, 0x32, };
+static int jz4740_lcd_special_pins[] = { 0x31, 0x32, 0x56, 0x57, };
+static int jz4740_lcd_generic_pins[] = { 0x55, };
static int jz4740_nand_cs1_pins[] = { 0x39, };
static int jz4740_nand_cs2_pins[] = { 0x3a, };
static int jz4740_nand_cs3_pins[] = { 0x3b, };
@@ -155,8 +157,8 @@ static const struct group_desc jz4740_groups[] = {
INGENIC_PIN_GROUP("lcd-8bit", jz4740_lcd_8bit, 0),
INGENIC_PIN_GROUP("lcd-16bit", jz4740_lcd_16bit, 0),
INGENIC_PIN_GROUP("lcd-18bit", jz4740_lcd_18bit, 0),
- INGENIC_PIN_GROUP("lcd-18bit-tft", jz4740_lcd_18bit_tft, 0),
- { "lcd-no-pins", },
+ INGENIC_PIN_GROUP("lcd-special", jz4740_lcd_special, 0),
+ INGENIC_PIN_GROUP("lcd-generic", jz4740_lcd_generic, 0),
INGENIC_PIN_GROUP("nand-cs1", jz4740_nand_cs1, 0),
INGENIC_PIN_GROUP("nand-cs2", jz4740_nand_cs2, 0),
INGENIC_PIN_GROUP("nand-cs3", jz4740_nand_cs3, 0),
@@ -176,7 +178,7 @@ static const char *jz4740_mmc_groups[] = { "mmc-1bit",
"mmc-4bit", };
static const char *jz4740_uart0_groups[] = { "uart0-data", "uart0-hwflow", };
static const char *jz4740_uart1_groups[] = { "uart1-data", };
static const char *jz4740_lcd_groups[] = {
- "lcd-8bit", "lcd-16bit", "lcd-18bit", "lcd-18bit-tft", "lcd-no-pins",
+ "lcd-8bit", "lcd-16bit", "lcd-18bit", "lcd-special", "lcd-generic",
};
static const char *jz4740_nand_groups[] = {
"nand-cs1", "nand-cs2", "nand-cs3", "nand-cs4", "nand-fre-fwe",
@@ -223,6 +225,17 @@ static int jz4725b_mmc0_4bit_pins[] = { 0x5d, 0x5b, 0x56,
};
static int jz4725b_mmc1_1bit_pins[] = { 0x7a, 0x7b, 0x7c, };
static int jz4725b_mmc1_4bit_pins[] = { 0x7d, 0x7e, 0x7f, };
static int jz4725b_uart_data_pins[] = { 0x4c, 0x4d, };
+static int jz4725b_lcd_8bit_pins[] = {
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+ 0x72, 0x73, 0x74,
+};
+static int jz4725b_lcd_16bit_pins[] = {
+ 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+};
+static int jz4725b_lcd_18bit_pins[] = { 0x70, 0x71, };
+static int jz4725b_lcd_24bit_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4725b_lcd_special_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4725b_lcd_generic_pins[] = { 0x75, };
static int jz4725b_nand_cs1_pins[] = { 0x55, };
static int jz4725b_nand_cs2_pins[] = { 0x56, };
static int jz4725b_nand_cs3_pins[] = { 0x57, };
@@ -235,19 +248,6 @@ static int jz4725b_pwm_pwm2_pins[] = {
[PATCH v4 03/11] pinctrl: Ingenic: Adjust the sequence of X1830 SSI pin groups.
Adjust the sequence of X1830's SSI related codes to make it consistent
with other Ingenic SoCs.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
Add Paul Cercueil's Reviewed-by.
v3->v4:
Add Andy Shevchenko's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 3de0f76..72d9daa 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -1473,16 +1473,16 @@ static int x1830_ssi0_gpc_pins[] = { 0x4d, };
static int x1830_ssi0_ce0_pins[] = { 0x50, };
static int x1830_ssi0_ce1_pins[] = { 0x4e, };
static int x1830_ssi1_dt_c_pins[] = { 0x53, };
-static int x1830_ssi1_dr_c_pins[] = { 0x54, };
-static int x1830_ssi1_clk_c_pins[] = { 0x57, };
-static int x1830_ssi1_gpc_c_pins[] = { 0x55, };
-static int x1830_ssi1_ce0_c_pins[] = { 0x58, };
-static int x1830_ssi1_ce1_c_pins[] = { 0x56, };
static int x1830_ssi1_dt_d_pins[] = { 0x62, };
+static int x1830_ssi1_dr_c_pins[] = { 0x54, };
static int x1830_ssi1_dr_d_pins[] = { 0x63, };
+static int x1830_ssi1_clk_c_pins[] = { 0x57, };
static int x1830_ssi1_clk_d_pins[] = { 0x66, };
+static int x1830_ssi1_gpc_c_pins[] = { 0x55, };
static int x1830_ssi1_gpc_d_pins[] = { 0x64, };
+static int x1830_ssi1_ce0_c_pins[] = { 0x58, };
static int x1830_ssi1_ce0_d_pins[] = { 0x67, };
+static int x1830_ssi1_ce1_c_pins[] = { 0x56, };
static int x1830_ssi1_ce1_d_pins[] = { 0x65, };
static int x1830_mmc0_1bit_pins[] = { 0x24, 0x25, 0x20, };
static int x1830_mmc0_4bit_pins[] = { 0x21, 0x22, 0x23, };
--
2.7.4
[PATCH v4 02/11] pinctrl: Ingenic: Add support for read the pin configuration of X1830.
Add X1830 support in "ingenic_pinconf_get()", so that it can read the
configuration of X1830 SoC correctly.
Fixes: d7da2a1e4e08 ("pinctrl: Ingenic: Add pinctrl driver for X1830.")
Cc:
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
1.Add fixes tag.
2.Adjust the code, simplify the ingenic_pinconf_get() function.
v3->v4:
1.Add parentheses around the '%' to make it more obvious.
2.Add Cc: .
3.Add Andy Shevchenko's Reviewed-by.
4.Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 40 ++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 05dfa0a..3de0f76 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -2109,26 +2109,48 @@ static int ingenic_pinconf_get(struct pinctrl_dev
*pctldev,
enum pin_config_param param = pinconf_to_config_param(*config);
unsigned int idx = pin % PINS_PER_GPIO_CHIP;
unsigned int offt = pin / PINS_PER_GPIO_CHIP;
- bool pull;
+ unsigned int bias;
+ bool pull, pullup, pulldown;
- if (jzpc->info->version >= ID_JZ4770)
- pull = !ingenic_get_pin_config(jzpc, pin, JZ4770_GPIO_PEN);
- else
- pull = !ingenic_get_pin_config(jzpc, pin, JZ4740_GPIO_PULL_DIS);
+ if (jzpc->info->version >= ID_X1830) {
+ unsigned int half = PINS_PER_GPIO_CHIP / 2;
+ unsigned int idxh = (pin % half) * 2;
+
+ if (idx < half)
+ regmap_read(jzpc->map, offt * jzpc->info->reg_offset +
+ X1830_GPIO_PEL, );
+ else
+ regmap_read(jzpc->map, offt * jzpc->info->reg_offset +
+ X1830_GPIO_PEH, );
+
+ bias = (bias >> idxh) & (GPIO_PULL_UP | GPIO_PULL_DOWN);
+
+ pullup = (bias == GPIO_PULL_UP) && (jzpc->info->pull_ups[offt]
& BIT(idx));
+ pulldown = (bias == GPIO_PULL_DOWN) &&
(jzpc->info->pull_downs[offt] & BIT(idx));
+
+ } else {
+ if (jzpc->info->version >= ID_JZ4770)
+ pull = !ingenic_get_pin_config(jzpc, pin,
JZ4770_GPIO_PEN);
+ else
+ pull = !ingenic_get_pin_config(jzpc, pin,
JZ4740_GPIO_PULL_DIS);
+
+ pullup = pull && (jzpc->info->pull_ups[offt] & BIT(idx));
+ pulldown = pull && (jzpc->info->pull_downs[offt] & BIT(idx));
+ }
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
- if (pull)
+ if (pullup || pulldown)
return -EINVAL;
break;
case PIN_CONFIG_BIAS_PULL_UP:
- if (!pull || !(jzpc->info->pull_ups[offt] & BIT(idx)))
+ if (!pullup)
return -EINVAL;
break;
case PIN_CONFIG_BIAS_PULL_DOWN:
- if (!pull || !(jzpc->info->pull_downs[offt] & BIT(idx)))
+ if (!pulldown)
return -EINVAL;
break;
@@ -2146,7 +2168,7 @@ static void ingenic_set_bias(struct ingenic_pinctrl *jzpc,
if (jzpc->info->version >= ID_X1830) {
unsigned int idx = pin % PINS_PER_GPIO_CHIP;
unsigned int half = PINS_PER_GPIO_CHIP / 2;
- unsigned int idxh = pin % half * 2;
+ unsigned int idxh = (pin % half) * 2;
unsigned int offt = pin / PINS_PER_GPIO_CHIP;
if (idx < half) {
--
2.7.4
[PATCH v4 01/11] pinctrl: Ingenic: Add missing pins to the JZ4770 MAC MII group.
The MII group of JZ4770's MAC should have 7 pins, add missing
pins to the MII group.
Fixes: 5de1a73e78ed ("Pinctrl: Ingenic: Add missing parts for JZ4770 and
JZ4780.")
Cc:
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
Add fixes tag.
v3->v4:
1.Add Cc: .
2.Add Andy Shevchenko's Reviewed-by.
3.Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index f274612..05dfa0a 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -667,7 +667,9 @@ static int jz4770_pwm_pwm7_pins[] = { 0x6b, };
static int jz4770_mac_rmii_pins[] = {
0xa9, 0xab, 0xaa, 0xac, 0xa5, 0xa4, 0xad, 0xae, 0xa6, 0xa8,
};
-static int jz4770_mac_mii_pins[] = { 0xa7, 0xaf, };
+static int jz4770_mac_mii_pins[] = {
+ 0x7b, 0x7a, 0x7d, 0x7c, 0xa7, 0x24, 0xaf,
+};
static const struct group_desc jz4770_groups[] = {
INGENIC_PIN_GROUP("uart0-data", jz4770_uart0_data, 0),
--
2.7.4
[PATCH v4 00/11] Fix bugs and add support for new Ingenic SoCs.
v1->v2: 1.Split [1/3] in v1 to [1/6] [2/6] [3/6] [4/6] in v2. 2.Fix the uninitialized warning. v2->v3: Split [6/6] in v2 to [6/10] [7/10] [8/10] [9/10] [10/10] in v3. v3->v4: 1.Modify the format of comment. 2.Split lcd pins into several groups. 3.Drop "lcd-no-pins" which is pointless. 4.Improve the structure of some functions. 5.Adjust function names to avoid confusion. 6.Use "lcd-special" and "lcd-generic" instead "lcd-xxbit-tft". 7.Replace "lcd-rgb-xxx" with "lcd-tft-xxx" to avoid confusion. 周琰杰 (Zhou Yanjie) (11): pinctrl: Ingenic: Add missing pins to the JZ4770 MAC MII group. pinctrl: Ingenic: Add support for read the pin configuration of X1830. pinctrl: Ingenic: Adjust the sequence of X1830 SSI pin groups. pinctrl: Ingenic: Improve LCD pins related code. pinctrl: Ingenic: Reformat the code. dt-bindings: pinctrl: Add bindings for new Ingenic SoCs. pinctrl: Ingenic: Add pinctrl driver for JZ4730. pinctrl: Ingenic: Add pinctrl driver for JZ4750. pinctrl: Ingenic: Add pinctrl driver for JZ4755. pinctrl: Ingenic: Add pinctrl driver for JZ4775. pinctrl: Ingenic: Add pinctrl driver for X2000. .../bindings/pinctrl/ingenic,pinctrl.yaml | 23 +- drivers/pinctrl/pinctrl-ingenic.c | 1538 ++-- 2 files changed, 1429 insertions(+), 132 deletions(-) -- 2.7.4
Re: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hello, one more comment: On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote: > +static inline struct visconti_pwm_chip *to_visconti_chip(struct pwm_chip > *chip) all functions but this one start have the common prefix "visconti_pwm_". I like the concept of a common prefix and so you could rename this function to visconti_pwm_from_chip or similar. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH] x86/msr: Block writes to certain MSRs unconditionally
Borislav Petkov writes: > From: Borislav Petkov > Date: Sat, 10 Apr 2021 14:08:13 +0200 > > There are a bunch of MSRs which luserspace has no business poking at, > whatsoever. Add a ban list and put the TSC-related MSRs in there. Issue > a big juicy splat to catch offenders. Have you ever seen any user programs actually write those MSRs? I don't see why they ever would, it's not that they have any motivation to do it (unlike SMM), and I don't know of any examples. The whole MSR blocking seems more like a tilting at windmills type effort. Root kits typically write from the kernel anyways. And the only results we have so far is various legitimate debug and benchmark utilities running much slower due to them flooding the kernel log with warnings. I can see that there are security reasons to lock down MSRs, but that is already handled fine with existing sandbox and lockdown mechanisms. But on a non locked down system fully accessible MSRs are really useful for all kind of debugging and tuning, and anything that prevents that is bad. -Andi
Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list
On Wed, Mar 24, 2021 at 12:58 AM Huang, Ying wrote: > > Yu Zhao writes: > > > On Mon, Mar 22, 2021 at 11:13:19AM +0800, Huang, Ying wrote: > >> Yu Zhao writes: > >> > >> > On Wed, Mar 17, 2021 at 11:37:38AM +0800, Huang, Ying wrote: > >> >> Yu Zhao writes: > >> >> > >> >> > On Tue, Mar 16, 2021 at 02:44:31PM +0800, Huang, Ying wrote: > >> >> > The scanning overhead is only one of the two major problems of the > >> >> > current page reclaim. The other problem is the granularity of the > >> >> > active/inactive (sizes). We stopped using them in making job > >> >> > scheduling decision a long time ago. I know another large internet > >> >> > company adopted a similar approach as ours, and I'm wondering how > >> >> > everybody else is coping with the discrepancy from those counters. > >> >> > >> >> From intuition, the scanning overhead of the full page table scanning > >> >> appears higher than that of the rmap scanning for a small portion of > >> >> system memory. But form your words, you think the reality is the > >> >> reverse? If others concern about the overhead too, finally, I think you > >> >> need to prove the overhead of the page table scanning isn't too higher, > >> >> or even lower with more data and theory. > >> > > >> > There is a misunderstanding here. I never said anything about full > >> > page table scanning. And this is not how it's done in this series > >> > either. I guess the misunderstanding has something to do with the cold > >> > memory tracking you are thinking about? > >> > >> If my understanding were correct, from the following code path in your > >> patch 10/14, > >> > >> age_active_anon > >> age_lru_gens > >> try_walk_mm_list > >> walk_mm_list > >> walk_mm > >> > >> So, in kswapd(), the page tables of many processes may be scanned > >> fully. If the number of processes that are active are high, the > >> overhead may be high too. > > > > That's correct. Just in case we have different definitions of what we > > call "full": > > > > I understand it as the full range of the address space of a process > > that was loaded by switch_mm() at least once since the last scan. > > This is not the case because we don't scan the full range -- we skip > > holes and VMAs that are unevictable, as well as PTE tables that have > > no accessed entries on x86_64, by should_skip_vma() and > > CONFIG_HAVE_ARCH_PARENT_PMD_YOUNG. > > > > If you are referring to the full range of PTE tables that have at > > least one accessed entry, i.e., other 511 are not none but have not > > been accessed either since the last scan on x86_64, then yes, you > > are right again :) This is the worse case scenario. > > OK. So there's no fundamental difference between us on this. > > >> > This series uses page tables to discover page accesses when a system > >> > has run out of inactive pages. Under such a situation, the system is > >> > very likely to have a lot of page accesses, and using the rmap is > >> > likely to cost a lot more because its poor memory locality compared > >> > with page tables. > >> > >> This is the theory. Can you verify this with more data? Including the > >> CPU cycles or time spent scanning page tables? > > > > Yes, I'll be happy to do so as I should, because page table scanning > > is counterintuitive. Let me add more theory in case it's still unclear > > to others. > > > > From my understanding, the two fundamental questions we need to > > consider in terms of page reclaim are: > > > > What are the sizes of hot clusters (spatial locality) should we > > expect under memory pressure? > > > > On smaller systems with 4GB memory, our observations are that the > > average size of hot clusters found during each scan is 32KB. On > > larger systems with hundreds of gigabytes of memory, it's well > > above this value -- 512KB or larger. These values vary under > > different workloads and with different memory allocators. Unless > > done deliberately by memory allocators, e.g., Scudo as I've > > mentioned earlier, it's safe to say if a PTE entry has been > > accessed, its neighbors are likely to have been accessed too. > > > > What's hot memory footprint (total size of hot clusters) should we > > expect when we have run out of inactive pages? > > > > Some numbers first: on large and heavily overcommitted systems, we > > have observed close to 90% during a scan. Those systems have > > millions of pages and using the rmap to find out which pages to > > reclaim will just blow kswapd. On smaller systems with less memory > > pressure (due to their weaker CPUs), this number is more reasonable, > > ~50%. Here is some kswapd profiles from a smaller systems running > > 5.11: > > > >the rmap page table scan > >- > >31.03% page_vma_mapped_walk 49.36% lzo1x_1_do_compress > >25.59% lzo1x_1_do_compress
Re: [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked
Feng,
On Sat, Apr 10 2021 at 22:38, Feng Tang wrote:
> On Sat, Apr 10, 2021 at 11:27:11AM +0200, Thomas Gleixner wrote:
>> > +static int __init start_sync_check_timer(void)
>> > +{
>> > + if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
>> > + return 0;
>> > +
>> > + timer_setup(_sync_check_timer, tsc_sync_check_timer_fn, 0);
>> > + tsc_sync_check_timer.expires = jiffies + SYNC_CHECK_INTERVAL;
>> > + add_timer(_sync_check_timer);
>> > +
>> > + return 0;
>> > +}
>> > +late_initcall(start_sync_check_timer);
>>
>> So right now, if someone adds 'tsc=reliable' on the kernel command line
>> then all of the watchdog checking, except for the idle enter TSC_ADJUST
>> check is disabled. The NOHZ full people are probably going to be pretty
>> unhappy about yet another unconditional timer they have to chase down.
>>
>> So this needs some more thought.
>
> 'tsc=reliable' in cmdline will set 'tsc_clocksource_reliable' to 1, so
> we can skip starting this timer if 'tsc_clocksource_reliable==1' ?
Then we can just ignore that patch alltogether because of 2/2 doing:
+ if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
+ boot_cpu_has(X86_FEATURE_NONSTOP_TSC) &&
+ boot_cpu_has(X86_FEATURE_TSC_ADJUST) &&
+ nr_online_nodes <= 2)
+ tsc_clocksource_reliable = 1;
I said for a reason:
>> So this needs some more thought.
Thanks,
tglx
Re: [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked
On Sat, Apr 10 2021 at 11:47, Borislav Petkov wrote: > On Sat, Apr 10, 2021 at 11:27:11AM +0200, Thomas Gleixner wrote: >> On Tue, Mar 30 2021 at 16:25, Feng Tang wrote: >> > Normally the tsc_sync will be checked every time system enters idle state, >> > but there is still caveat that a system won't enter idle, either because >> > it's too busy or configured purposely to not enter idle. Setup a periodic >> > timer to make sure the check is always on. >> >> Bah. I really hate the fact that we don't have a knob to disable writes >> to the TSC/TSC_ADJUST msrs. That would spare this business alltogether. > > We have the MSR filtering and I'd *love* to add those MSRs to a > permanent ban list of MSRs which will never ever be written to from > luserspace. That's good, but what I really want is a knob which prevents BIOS/SMM from writing to it. The only reason why BIOS ever needs to write is for physical hotplug and perhaps for 4+ socket machines on boot. After that every write is a bug. Thanks, tglx
Re: [PATCH] dm verity: fix unaligned block size
Sorry, this patch is totally wrong. Let me dig out more.
On 04/10, Jaegeuk Kim wrote:
> From: Jaegeuk Kim
>
> When f->roots is 2 and block size is 4096, it will gives unaligned block size
> length in the scsi command like below. Let's allocate dm_bufio to set the
> block
> size length to match IO chunk size.
>
> E sd 0: 0:0:0: [sda] tag#30 request not aligned to the logical block size
> E blk_update_request: I/O error, dev sda, sector 10368424 op 0x0:(READ) flags
> 0x0 phys_seg 1 prio class 0
> E device-mapper: verity-fec: 254:8: FEC 9244672: parity read failed (block
> 18056): -5
>
> Fixes: ce1cca17381f ("dm verity: fix FEC for RS roots unaligned to block
> size")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jaegeuk Kim
> ---
> drivers/md/dm-verity-fec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
> index 66f4c6398f67..656238131dd7 100644
> --- a/drivers/md/dm-verity-fec.c
> +++ b/drivers/md/dm-verity-fec.c
> @@ -743,7 +743,7 @@ int verity_fec_ctr(struct dm_verity *v)
> }
>
> f->bufio = dm_bufio_client_create(f->dev->bdev,
> - f->roots << SECTOR_SHIFT,
> + 1 << v->data_dev_block_bits,
> 1, 0, NULL, NULL);
> if (IS_ERR(f->bufio)) {
> ti->error = "Cannot initialize FEC bufio client";
> --
> 2.31.1.295.g9ea45b61b8-goog
Re: [PATCH net-next v3 2/5] mm: add a signature in struct page
Hi Shakeel, On Sat, Apr 10, 2021 at 10:42:30AM -0700, Shakeel Butt wrote: > On Sat, Apr 10, 2021 at 9:16 AM Ilias Apalodimas > wrote: > > > > Hi Matthew > > > > On Sat, Apr 10, 2021 at 04:48:24PM +0100, Matthew Wilcox wrote: > > > On Sat, Apr 10, 2021 at 12:37:58AM +0200, Matteo Croce wrote: > > > > This is needed by the page_pool to avoid recycling a page not allocated > > > > via page_pool. > > > > > > Is the PageType mechanism more appropriate to your needs? It wouldn't > > > be if you use page->_mapcount (ie mapping it to userspace). > > > > Interesting! > > Please keep in mind this was written ~2018 and was stale on my branches for > > quite some time. So back then I did try to use PageType, but had not free > > bits. Looking at it again though, it's cleaned up. So yes I think this can > > be much much cleaner. Should we go and define a new PG_pagepool? > > > > > > Can this page_pool be used for TCP RX zerocopy? If yes then PageType > can not be used. Yes it can, since it's going to be used as your default allocator for payloads, which might end up on an SKB. So we have to keep the extra added field on struct page for our mark. Matthew had an intersting idea. He suggested keeping it, but changing the magic number, so it can't be a kernel address, but I'll let him follow up on the details. > > There is a recent discussion [1] on memcg accounting of TCP RX > zerocopy and I am wondering if this work can somehow help in that > regard. I will take a look at the series. > I'll try having a look on this as well. The idea behind the patchset is to allow lower speed NICs that use the API already, gain recycling 'easily'. Using page_pool for the driver comes with a penalty to begin with. Allocating pages instead of SKBs has a measurable difference. By enabling them to recycle they'll get better performance, since you skip the reallocation/remapping and only care for syncing the buffers correctly. > [1] > https://lore.kernel.org/linux-mm/20210316013003.25271-1-arjunroy.k...@gmail.com/
Re: [PATCH -next] ALSA: virtio: use module_virtio_driver() to simplify the code
On 08.04.2021 14:54, Chen Huang wrote
module_virtio_driver() makes the code simpler by eliminating
boilerplate code.
Signed-off-by: Chen Huang
Thanks for the patch.
Reviewed-by: Anton Yakovlev
---
sound/virtio/virtio_card.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index ae9128063917..150ab3e37013 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -432,17 +432,7 @@ static struct virtio_driver virtsnd_driver = {
#endif
};
-static int __init init(void)
-{
- return register_virtio_driver(_driver);
-}
-module_init(init);
-
-static void __exit fini(void)
-{
- unregister_virtio_driver(_driver);
-}
-module_exit(fini);
+module_virtio_driver(virtsnd_driver);
MODULE_DEVICE_TABLE(virtio, id_table);
MODULE_DESCRIPTION("Virtio sound card driver");
--
2.17.1
[GIT PULL] percpu changes for v5.12-rc7
Hi Linus, This pull request contains a fix for sporadically failing atomic percpu allocations. I only caught it recently while I was reviewing a new series [1] and simultaneously saw reports by btrfs in xfstests [2] and [3]. In v5.9, memcg accounting was extended to percpu done by adding a second type of chunk. I missed an interaction with the free page float count used to ensure we can support atomic allocations. If 1 type of chunk has no free pages, but the other has enough to satisfy the free page float requirement, we will not repopulate the free pages for the former type of chunk. This led to sporadically failing atomic allocations. [1] https://lore.kernel.org/linux-mm/20210324190626.564297-1-g...@fb.com/ [2] https://lore.kernel.org/linux-mm/20210401185158.3275.40950...@e16-tech.com/ [3] https://lore.kernel.org/linux-mm/cal3q7h5rnbjci708gh7jnczaoe0blnact9c+obga-dx9jhb...@mail.gmail.com/ Thanks, Dennis The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120: Linux 5.12-rc6 (2021-04-04 14:15:36 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu.git for-5.12-fixes for you to fetch changes up to 0760fa3d8f7fceeea508b98899f1c826e10ffe78: percpu: make pcpu_nr_empty_pop_pages per chunk type (2021-04-09 13:58:38 +) Roman Gushchin (1): percpu: make pcpu_nr_empty_pop_pages per chunk type mm/percpu-internal.h | 2 +- mm/percpu-stats.c| 9 +++-- mm/percpu.c | 14 +++--- 3 files changed, 15 insertions(+), 10 deletions(-)
[PATCH v4] platform/x86: add Gigabyte WMI temperature driver
Changes since v3:
* Completely hide unusable sensors
* Expose force_load parameter read-only via sysfs
* Naming
* Style cleanups
-- >8 --
Tested with
* X570 I Aorus Pro Wifi (rev 1.0)
* B550M DS3H
* B550 Gaming X V2 (rev.1.x)
* Z390 I AORUS PRO WIFI (rev. 1.0)
The mainboard contains an ITE IT8688E chip for management.
This chips is also handled by drivers/hwmon/i87.c but as it is also used
by the firmware itself it needs an ACPI driver.
Unfortunately not all sensor registers are handled by the firmware and even
less are exposed via WMI.
Signed-off-by: Thomas Weißschuh
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig| 11 ++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/gigabyte-wmi.c | 195
4 files changed, 213 insertions(+)
create mode 100644 drivers/platform/x86/gigabyte-wmi.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..9c10cfc00fe8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7543,6 +7543,12 @@ F: Documentation/filesystems/gfs2*
F: fs/gfs2/
F: include/uapi/linux/gfs2_ondisk.h
+GIGABYTE WMI DRIVER
+M: Thomas Weißschuh
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/gigabyte-wmi.c
+
GNSS SUBSYSTEM
M: Johan Hovold
S: Maintained
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ad4e630e73e2..96622a2106f7 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -123,6 +123,17 @@ config XIAOMI_WMI
To compile this driver as a module, choose M here: the module will
be called xiaomi-wmi.
+config GIGABYTE_WMI
+ tristate "Gigabyte WMI temperature driver"
+ depends on ACPI_WMI
+ depends on HWMON
+ help
+ Say Y here if you want to support WMI-based temperature reporting on
+ Gigabyte mainboards.
+
+ To compile this driver as a module, choose M here: the module will
+ be called gigabyte-wmi.
+
config ACERHDF
tristate "Acer Aspire One temperature and fan driver"
depends on ACPI && THERMAL
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 60d554073749..1621ebfd04fd 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INTEL_WMI_THUNDERBOLT) +=
intel-wmi-thunderbolt.o
obj-$(CONFIG_MXM_WMI) += mxm-wmi.o
obj-$(CONFIG_PEAQ_WMI) += peaq-wmi.o
obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
+obj-$(CONFIG_GIGABYTE_WMI) += gigabyte-wmi.o
# Acer
obj-$(CONFIG_ACERHDF) += acerhdf.o
diff --git a/drivers/platform/x86/gigabyte-wmi.c
b/drivers/platform/x86/gigabyte-wmi.c
new file mode 100644
index ..c17e51fcf000
--- /dev/null
+++ b/drivers/platform/x86/gigabyte-wmi.c
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 Thomas Weißschuh
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+#define GIGABYTE_WMI_GUID "DEADBEEF-2001--00A0-C9062910"
+#define NUM_TEMPERATURE_SENSORS6
+
+static bool force_load;
+module_param(force_load, bool, 0444);
+MODULE_PARM_DESC(force_load, "Force loading on unknown platform");
+
+static u8 usable_sensors_mask;
+
+enum gigabyte_wmi_commandtype {
+ GIGABYTE_WMI_BUILD_DATE_QUERY = 0x1,
+ GIGABYTE_WMI_MAINBOARD_TYPE_QUERY = 0x2,
+ GIGABYTE_WMI_FIRMWARE_VERSION_QUERY = 0x4,
+ GIGABYTE_WMI_MAINBOARD_NAME_QUERY = 0x5,
+ GIGABYTE_WMI_TEMPERATURE_QUERY = 0x125,
+};
+
+struct gigabyte_wmi_args {
+ u32 arg1;
+};
+
+static int gigabyte_wmi_perform_query(struct wmi_device *wdev,
+ enum gigabyte_wmi_commandtype command,
+ struct gigabyte_wmi_args *args, struct
acpi_buffer *out)
+{
+ const struct acpi_buffer in = {
+ .length = sizeof(*args),
+ .pointer = args,
+ };
+
+ acpi_status ret = wmidev_evaluate_method(wdev, 0x0, command, , out);
+
+ if ACPI_FAILURE(ret)
+ return -EIO;
+
+ return 0;
+}
+
+static int gigabyte_wmi_query_integer(struct wmi_device *wdev,
+ enum gigabyte_wmi_commandtype command,
+ struct gigabyte_wmi_args *args, u64 *res)
+{
+ union acpi_object *obj;
+ struct acpi_buffer result = { ACPI_ALLOCATE_BUFFER, NULL };
+ int ret;
+
+ ret = gigabyte_wmi_perform_query(wdev, command, args, );
+ if (ret)
+ return ret;
+ obj = result.pointer;
+ if (obj && obj->type == ACPI_TYPE_INTEGER)
+ *res = obj->integer.value;
+ else
+ ret = -EIO;
+ kfree(result.pointer);
+ return ret;
+}
+
+static int gigabyte_wmi_temperature(struct
[PATCH v6 2/2] drm: bridge: cdns-mhdp8546: Enable HDCP
This patch enable HDCP in MHDP driver.
Signed-off-by: Parshuram Thombare
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/cadence/Makefile | 2 +-
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 128 +++-
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 22 +
.../drm/bridge/cadence/cdns-mhdp8546-hdcp.c | 570 ++
.../drm/bridge/cadence/cdns-mhdp8546-hdcp.h | 92 +++
5 files changed, 801 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.h
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 8f647991b374..4d2db8df1bc6 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
-cdns-mhdp8546-y := cdns-mhdp8546-core.o
+cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 989a05bc8197..01e95466502a 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -49,7 +50,7 @@
#include
#include "cdns-mhdp8546-core.h"
-
+#include "cdns-mhdp8546-hdcp.h"
#include "cdns-mhdp8546-j721e.h"
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
@@ -1614,10 +1615,51 @@ enum drm_mode_status cdns_mhdp_mode_valid(struct
drm_connector *conn,
return MODE_OK;
}
+static int cdns_mhdp_connector_atomic_check(struct drm_connector *conn,
+ struct drm_atomic_state *state)
+{
+ struct cdns_mhdp_device *mhdp = connector_to_mhdp(conn);
+ struct drm_connector_state *old_state, *new_state;
+ struct drm_crtc_state *crtc_state;
+ u64 old_cp, new_cp;
+
+ if (!mhdp->hdcp_supported)
+ return 0;
+
+ old_state = drm_atomic_get_old_connector_state(state, conn);
+ new_state = drm_atomic_get_new_connector_state(state, conn);
+ old_cp = old_state->content_protection;
+ new_cp = new_state->content_protection;
+
+ if (old_state->hdcp_content_type != new_state->hdcp_content_type &&
+ new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+ new_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ goto mode_changed;
+ }
+
+ if (!new_state->crtc) {
+ if (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ new_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return 0;
+ }
+
+ if (old_cp == new_cp ||
+ (old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED))
+ return 0;
+
+mode_changed:
+ crtc_state = drm_atomic_get_new_crtc_state(state, new_state->crtc);
+ crtc_state->mode_changed = true;
+
+ return 0;
+}
+
static const struct drm_connector_helper_funcs cdns_mhdp_conn_helper_funcs = {
.detect_ctx = cdns_mhdp_connector_detect,
.get_modes = cdns_mhdp_get_modes,
.mode_valid = cdns_mhdp_mode_valid,
+ .atomic_check = cdns_mhdp_connector_atomic_check,
};
static const struct drm_connector_funcs cdns_mhdp_conn_funcs = {
@@ -1662,7 +1704,10 @@ static int cdns_mhdp_connector_init(struct
cdns_mhdp_device *mhdp)
return ret;
}
- return 0;
+ if (mhdp->hdcp_supported)
+ ret = drm_connector_attach_content_protection_property(conn,
true);
+
+ return ret;
}
static int cdns_mhdp_attach(struct drm_bridge *bridge,
@@ -1957,6 +2002,15 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge
*bridge,
if (WARN_ON(!conn_state))
goto out;
+ if (mhdp->hdcp_supported &&
+ mhdp->hw_state == MHDP_HW_READY &&
+ conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED) {
+ mutex_unlock(>link_mutex);
+ cdns_mhdp_hdcp_enable(mhdp, conn_state->hdcp_content_type);
+ mutex_lock(>link_mutex);
+ }
+
crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
if (WARN_ON(!crtc_state))
goto out;
@@ -2000,6 +2054,9 @@ static void cdns_mhdp_atomic_disable(struct drm_bridge
*bridge,
mutex_lock(>link_mutex);
+ if (mhdp->hdcp_supported)
+ cdns_mhdp_hdcp_disable(mhdp);
+
mhdp->bridge_enabled = false;
cdns_mhdp_reg_read(mhdp, CDNS_DP_FRAMER_GLOBAL_CONFIG, );
resp &= ~CDNS_DP_FRAMER_EN;
@@ -2288,7
[PATCH v6 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding. Signed-off-by: Parshuram Thombare --- .../bindings/display/bridge/cdns,mhdp8546.yaml| 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index 63427878715e..2333fdbe9296 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -18,7 +18,7 @@ properties: reg: minItems: 1 -maxItems: 2 +maxItems: 3 items: - description: Register block of mhdptx apb registers up to PHY mapped area (AUX_CONFIG_P). @@ -26,13 +26,16 @@ properties: included in the associated PHY. - description: Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7 SoCs. + - description: + Register block of mhdptx sapb registers. reg-names: minItems: 1 -maxItems: 2 +maxItems: 3 items: - const: mhdptx - const: j721e-intg + - const: mhdptx-sapb clocks: maxItems: 1 @@ -99,14 +102,18 @@ allOf: properties: reg: minItems: 2 + maxItems: 3 reg-names: minItems: 2 + maxItems: 3 else: properties: reg: - maxItems: 1 + minItems: 1 + maxItems: 2 reg-names: - maxItems: 1 + minItems: 1 + maxItems: 2 required: - compatible -- 2.25.1
[PATCH v6 0/2] enable HDCP in Cadence MHDP bridge driver
This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver. Changes since v1: - Move sapb reg block right after apb reg block - Corresponding changes in binding and example Changes since v2: - Revert reg resource sequence in binding and use resource mapping by name - Remove hdcp_config from binding and use DRM HDCP Content Type property to select HDCP version Changes since v3: - Fix kernel test robot warning Changes since v4: - Fix binding issue Changes since v5: - Maintain backward compatibility of driver on platforms without SAPB port by allowing driver to continue without HDCP feature instead of returning error Parshuram Thombare (2): dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP drm: bridge: cdns-mhdp8546: Enable HDCP .../display/bridge/cdns,mhdp8546.yaml | 15 +- drivers/gpu/drm/bridge/cadence/Makefile | 2 +- .../drm/bridge/cadence/cdns-mhdp8546-core.c | 128 +++- .../drm/bridge/cadence/cdns-mhdp8546-core.h | 22 + .../drm/bridge/cadence/cdns-mhdp8546-hdcp.c | 570 ++ .../drm/bridge/cadence/cdns-mhdp8546-hdcp.h | 92 +++ 6 files changed, 812 insertions(+), 17 deletions(-) create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.h -- 2.25.1
