[PATCH 3/3] bus: fsl-mc: probe the allocatable objects first
From: Grigore Popescu
Because the DPNIs are probed before DPMCPs and other objects that need
to be allocated, messages like "No more resources of type X left" are
printed by the fsl-mc bus driver. This patch resolves the issue by probing
the allocatable objects first and then any other object that may use
them.
Signed-off-by: Grigore Popescu
Signed-off-by: Ioana Ciornei
---
drivers/bus/fsl-mc/dprc-driver.c | 57 ++--
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/fsl-mc/dprc-driver.c b/drivers/bus/fsl-mc/dprc-driver.c
index c8b1c3842c1a..3512d1b95821 100644
--- a/drivers/bus/fsl-mc/dprc-driver.c
+++ b/drivers/bus/fsl-mc/dprc-driver.c
@@ -27,7 +27,16 @@ static bool fsl_mc_device_match(struct fsl_mc_device *mc_dev,
{
return mc_dev->obj_desc.id == obj_desc->id &&
strcmp(mc_dev->obj_desc.type, obj_desc->type) == 0;
+}
+static bool fsl_mc_obj_desc_is_allocatable(struct fsl_mc_obj_desc *obj)
+{
+ if (strcmp(obj->type, "dpmcp") == 0 ||
+ strcmp(obj->type, "dpcon") == 0 ||
+ strcmp(obj->type, "dpbp") == 0)
+ return true;
+ else
+ return false;
}
static int __fsl_mc_device_remove_if_not_in_mc(struct device *dev, void *data)
@@ -150,6 +159,27 @@ static void check_plugged_state_change(struct
fsl_mc_device *mc_dev,
}
}
+static void fsl_mc_obj_device_add(struct fsl_mc_device *mc_bus_dev,
+ struct fsl_mc_obj_desc *obj_desc)
+{
+ int error;
+ struct fsl_mc_device *child_dev;
+
+ /*
+* Check if device is already known to Linux:
+*/
+ child_dev = fsl_mc_device_lookup(obj_desc, mc_bus_dev);
+ if (child_dev) {
+ check_plugged_state_change(child_dev, obj_desc);
+ put_device(&child_dev->dev);
+ } else {
+ error = fsl_mc_device_add(obj_desc, NULL, &mc_bus_dev->dev,
+ &child_dev);
+ if (error < 0)
+ return;
+ }
+}
+
/**
* dprc_add_new_devices - Adds devices to the logical bus for a DPRC
*
@@ -166,30 +196,23 @@ static void dprc_add_new_devices(struct fsl_mc_device
*mc_bus_dev,
struct fsl_mc_obj_desc *obj_desc_array,
int num_child_objects_in_mc)
{
- int error;
int i;
+ /* probe the allocable objects first */
for (i = 0; i < num_child_objects_in_mc; i++) {
- struct fsl_mc_device *child_dev;
struct fsl_mc_obj_desc *obj_desc = &obj_desc_array[i];
- if (strlen(obj_desc->type) == 0)
- continue;
+ if (strlen(obj_desc->type) > 0 &&
+ fsl_mc_obj_desc_is_allocatable(obj_desc))
+ fsl_mc_obj_device_add(mc_bus_dev, obj_desc);
+ }
- /*
-* Check if device is already known to Linux:
-*/
- child_dev = fsl_mc_device_lookup(obj_desc, mc_bus_dev);
- if (child_dev) {
- check_plugged_state_change(child_dev, obj_desc);
- put_device(&child_dev->dev);
- continue;
- }
+ for (i = 0; i < num_child_objects_in_mc; i++) {
+ struct fsl_mc_obj_desc *obj_desc = &obj_desc_array[i];
- error = fsl_mc_device_add(obj_desc, NULL, &mc_bus_dev->dev,
- &child_dev);
- if (error < 0)
- continue;
+ if (strlen(obj_desc->type) > 0 &&
+ !fsl_mc_obj_desc_is_allocatable(obj_desc))
+ fsl_mc_obj_device_add(mc_bus_dev, obj_desc);
}
}
--
2.25.1
[GIT PULL] io_uring fix for 5.8-rc6
Hi Linus, Fix for a case where, with automatic buffer selection, we can leak the buffer descriptor for recvmsg. Please pull! The following changes since commit 16d598030a37853a7a6b4384cad19c9c0af2f021: io_uring: fix not initialised work->flags (2020-07-12 09:40:50 -0600) are available in the Git repository at: git://git.kernel.dk/linux-block.git tags/io_uring-5.8-2020-07-17 for you to fetch changes up to 681fda8d27a66f7e65ff7f2d200d7635e64a8d05: io_uring: fix recvmsg memory leak with buffer selection (2020-07-15 13:35:56 -0600) io_uring-5.8-2020-07-17 Pavel Begunkov (1): io_uring: fix recvmsg memory leak with buffer selection fs/io_uring.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) -- Jens Axboe
RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support
Hi Thanks to everyone for the clarifications Thanks, Avi > -Original Message- > From: Alim Akhtar > Sent: Thursday, July 16, 2020 7:45 PM > To: Avi Shchislowski ; 'Bart Van Assche' > ; daejun7.p...@samsung.com; Avri Altman > ; j...@linux.ibm.com; martin.peter...@oracle.com; > asuto...@codeaurora.org; bean...@micron.com; > stanley@mediatek.com; c...@codeaurora.org; tomas.wink...@intel.com > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; 'Sang-yoon Oh' > ; 'Sung-Jun Park' > ; 'yongmyung lee' > ; 'Jinyoung CHOI' young.c...@samsung.com>; 'Adel Choi' ; 'BoRam > Shin' > Subject: RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support > > CAUTION: This email originated from outside of Western Digital. Do not click > on > links or open attachments unless you recognize the sender and know that the > content is safe. > > > Hi Avi, > > > -Original Message- > > From: Avi Shchislowski > > Sent: 16 July 2020 15:31 > > To: Bart Van Assche ; daejun7.p...@samsung.com; > > Avri Altman ; j...@linux.ibm.com; > > martin.peter...@oracle.com; asuto...@codeaurora.org; > > bean...@micron.com; stanley@mediatek.com; c...@codeaurora.org; > > tomas.wink...@intel.com; ALIM AKHTAR > > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > > Sang-yoon Oh ; Sung-Jun Park > > ; yongmyung lee > > ; Jinyoung CHOI young.c...@samsung.com>; > > Adel Choi ; BoRam Shin > > > Subject: RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster > > Support > > > > > > > > > -Original Message- > > > From: Bart Van Assche > > > Sent: Thursday, July 16, 2020 4:42 AM > > > To: Avi Shchislowski ; > > > daejun7.p...@samsung.com; Avri Altman ; > > > j...@linux.ibm.com; martin.peter...@oracle.com; > > > asuto...@codeaurora.org; bean...@micron.com; > > stanley@mediatek.com; > > > c...@codeaurora.org; tomas.wink...@intel.com; ALIM AKHTAR > > > > > > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > Sang-yoon Oh ; Sung-Jun Park > > > ; yongmyung lee > > > ; Jinyoung CHOI > young.c...@samsung.com>; > > > Adel Choi ; BoRam Shin > > > > > Subject: Re: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster > > > Support > > > > > > CAUTION: This email originated from outside of Western Digital. Do > > > not click on links or open attachments unless you recognize the > > > sender and know that the content is safe. > > > > > > > > > On 2020-07-15 11:34, Avi Shchislowski wrote: > > > > My name is Avi Shchislowski, I am managing the WDC's Linux Host > > > > R&D team > > > in which Avri is a member of. > > > > As the review process of HPB is progressing very constructively, > > > > we are getting > > > more and more requests from OEMs, Inquiring about HPB in general, > > > and host control mode in particular. > > > > > > > > Their main concern is that HPB will make it to 5.9 merge window, > > > > but the host > > > control mode patches will not. > > > > Thus, because of recent Google's GKI, the next Android LTS might > > > > not include > > > HPB with host control mode. > > > > > > > > Aside of those requests, initial host control mode testing are > > > > showing > > > promising prospective with respect of performance gain. > > > > > > > > What would be, in your opinion, the best policy that host control > > > > mode is > > > included in next Android LTS? > > > > > > Hi Avi, > > > > > > Are you perhaps referring to the HPB patch series that has already > > > been > > posted? > > > Although I'm not sure of this, I think that the SCSI maintainer > > > expects more > > > Reviewed-by: and Tested-by: tags. Has anyone from WDC already taken > > > the time to review and/or test this patch series? > > > > > > Thanks, > > > > > > Bart. > > > > Yes, I am referring to the current proposal which I am replying to: > > [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support This > > proposal does not contains host mode, hence our customers concern. > > What would be, in your opinion, the best policy that host control mode > > is included in next Android LTS assuming it will be based on kernel v5.9 ? > > > This series has nothing to do with Host mode control, this series is targeted > for > device mode control. General consensus here is to land this series as it is > (unless > someone has more review comments) and lets add/enhance whatever need to > be done for adding Host mode controls as well as other HPB2.0 related changes. > > > Thanks, > > Avi
Re: [PATCH] power: supply: sc27xx: prevent adc * 1000 from overflow
Hi Chunyan, I love your patch! Yet something to improve: [auto build test ERROR on power-supply/for-next] [also build test ERROR on linux/master linus/master v5.8-rc5 next-20200716] [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/Chunyan-Zhang/power-supply-sc27xx-prevent-adc-1000-from-overflow/20200717-133835 base: https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git for-next config: m68k-allyesconfig (attached as .config) compiler: m68k-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 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=m68k If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): m68k-linux-ld: drivers/power/supply/sc27xx_fuel_gauge.o: in function `sc27xx_fgu_hw_init': sc27xx_fuel_gauge.c:(.text+0x13ec): undefined reference to `__divdi3' m68k-linux-ld: drivers/power/supply/sc27xx_fuel_gauge.o: in function `sc27xx_fgu_get_vbat_vol': sc27xx_fuel_gauge.c:(.text+0x1d8): undefined reference to `__divdi3' >> m68k-linux-ld: sc27xx_fuel_gauge.c:(.text+0x1f4): undefined reference to >> `__divdi3' m68k-linux-ld: drivers/power/supply/sc27xx_fuel_gauge.o: in function `sc27xx_fgu_get_current': sc27xx_fuel_gauge.c:(.text+0x2b8): undefined reference to `__divdi3' m68k-linux-ld: sc27xx_fuel_gauge.c:(.text+0x2d4): undefined reference to `__divdi3' m68k-linux-ld: drivers/power/supply/sc27xx_fuel_gauge.o:sc27xx_fuel_gauge.c:(.text+0x84e): more undefined references to `__divdi3' follow --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: linux-next: Fixes tags need some work in the arm-soc-fixes tree
On 7/17/20 10:46 AM, Arnd Bergmann wrote: > On Fri, Jul 17, 2020 at 5:36 PM Dinh Nguyen wrote: >> On 7/16/20 3:10 PM, Arnd Bergmann wrote: >>> On Wed, Jul 15, 2020 at 9:14 PM Dinh Nguyen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I apologize for this! I have an updated branch that fixes these tags. Let me know if I need to respin the pull request. >>> >>> I've recreated the branch from scratch now (this was one of only >>> two pull requests I got anyway), it should be fine now. >>> >> >> Thank you! > > I was about to send off the pull request to Linus now, but I now saw > that the tag I pulled was not updated and still has the broken lines. > > Could you make sure you upload a new tag and send the pull > request for that so I can pull it once more? > I just sent you an updated pull request for the tag socfpga_fixes_for_v5.8_v2. Thanks, Dinh
Re: [PATCH v5 4/5] iommu/uapi: Handle data and argsz filled by users
Hi Jacob,
On 7/16/20 8:45 PM, Jacob Pan wrote:
Could you share a branch? I was not able to apply this on either
iommu/next or master?
> IOMMU UAPI data has a user filled argsz field which indicates the data
> length comes with the API call.
s/ comes with the API call/ of the structure
User data is not trusted, argsz must be
> validated based on the current kernel data size, mandatory data size,
> and feature flags.
>
> User data may also be extended, results in possible argsz increase.
s/results/resulting
> Backward compatibility is ensured based on size and flags checking.
flags is missing in iommu_cache_invalidate_info.
>
> This patch adds sanity checks in the IOMMU layer. In addition to argsz,
> reserved/unused fields in padding, flags, and version are also checked.
> Details are documented in Documentation/userspace-api/iommu.rst
>
> Signed-off-by: Liu Yi L
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/iommu.c | 192
> --
> include/linux/iommu.h | 20 --
> 2 files changed, 200 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d43120eb1dc5..fe30a940d19e 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1950,36 +1950,214 @@ int iommu_attach_device(struct iommu_domain *domain,
> struct device *dev)
> }
> EXPORT_SYMBOL_GPL(iommu_attach_device);
>
> +/*
> + * Check flags and other user privided data for valid combinations. We also
s/privided/provided
> + * make sure no reserved fields or unused flags are not set. This is to
> ensure
s/not// ?
> + * not breaking userspace in the future when these fields or flags are used.
> + */
> +static int iommu_check_cache_invl_data(struct iommu_cache_invalidate_info
> *info)
> +{
> + u32 mask;
> +
> + if (info->version != IOMMU_CACHE_INVALIDATE_INFO_VERSION_1)
increased version number?
> + return -EINVAL;
> +
> + mask = (1 << IOMMU_CACHE_INV_TYPE_NR) - 1;
> + if (info->cache & ~mask)
> + return -EINVAL;
> +
> + if (info->granularity >= IOMMU_INV_GRANU_NR)
> + return -EINVAL;
> +
> + switch (info->granularity) {
> + case IOMMU_INV_GRANU_ADDR:
> + mask = IOMMU_INV_ADDR_FLAGS_PASID |
> + IOMMU_INV_ADDR_FLAGS_ARCHID |
> + IOMMU_INV_ADDR_FLAGS_LEAF;
> +
> + if (info->granu.addr_info.flags & ~mask)
> + return -EINVAL;
> + break;
> + case IOMMU_INV_GRANU_PASID:
> + mask = IOMMU_INV_PASID_FLAGS_PASID |
> + IOMMU_INV_PASID_FLAGS_ARCHID;
> + if (info->granu.pasid_info.flags & ~mask)
> + return -EINVAL;
> +
> + break;
> + case IOMMU_INV_GRANU_DOMAIN:
> + /* No flags to check */
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (info->padding[0] || info->padding[1])
padding has become "__u8padding[6];" in 2/5
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> int iommu_cache_invalidate(struct iommu_domain *domain, struct device *dev,
> -struct iommu_cache_invalidate_info *inv_info)
> +void __user *uinfo)
> {
> + struct iommu_cache_invalidate_info inv_info = { 0 };
> + u32 minsz, maxsz;
> + int ret = 0;
> +
> if (unlikely(!domain->ops->cache_invalidate))
> return -ENODEV;
>
> - return domain->ops->cache_invalidate(domain, dev, inv_info);
> + /* Current kernel data size is the max to be copied from user */
> + maxsz = sizeof(struct iommu_cache_invalidate_info);
> +
> + /*
> + * No new spaces can be added before the variable sized union, the
> + * minimum size is the offset to the union.
> + */
> + minsz = offsetof(struct iommu_cache_invalidate_info, granu);
> +
> + /* Copy minsz from user to get flags and argsz */
> + if (copy_from_user(&inv_info, uinfo, minsz))
> + return -EFAULT;
> +
> + /* Fields before variable size union is mandatory */
> + if (inv_info.argsz < minsz)
> + return -EINVAL;
> +
> + /* PASID and address granu requires additional info beyond minsz */
s/requires/require
> + if (inv_info.argsz == minsz &&
> + ((inv_info.granularity == IOMMU_INV_GRANU_PASID) ||
> + (inv_info.granularity == IOMMU_INV_GRANU_ADDR)))
> + return -EINVAL;
> + /*
> + * User might be using a newer UAPI header which has a larger data
> + * size, we shall support the existing flags within the current
> + * size. Copy the remaining user data _after_ minsz but not more
> + * than the current kernel supported size.
> + */
> + if (copy_from_user((void *)&inv_info + minsz, uinfo + minsz,
> + min(inv_info.argsz, maxsz) - minsz))
> + return -EFAULT;
> +
> +
[PATCH V2] genirq/affinity: Handle affinity setting on inactive interrupts correctly
Setting interrupt affinity on inactive interrupts is inconsistent when
hierarchical irq domains are enabled. The core code should just store the
affinity and not call into the irq chip driver for inactive interrupts
because the chip drivers may not be in a state to handle such requests.
X86 has a hacky workaround for that but all other irq chips have not which
causes problems e.g. on GIC V3 ITS.
Instead of adding more ugly hacks all over the place, solve the problem in
the core code. If the affinity is set on an inactive interrupt then:
- Store it in the irq descriptors affinity mask
- Update the effective affinity to reflect that so user space has
a consistent view
- Don't call into the irq chip driver
This is the core equivalent of the X86 workaround and works correctly
because the affinity setting is established in the irq chip when the
interrupt is activated later on.
Note, that this is only effective when hierarchical irq domains are enabled
by the architecture. Doing it unconditionally would break legacy irq chip
implementations.
For hierarchial irq domains this works correctly as none of the drivers can
have a dependency on affinity setting in inactive state by design.
Remove the X86 workaround as it is not longer required.
Fixes: 02edee152d6e ("x86/apic/vector: Ignore set_affinity call for inactive
interrupts")
Reported-by: Ali Saidi
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link: https://lore.kernel.org/r/20200529015501.15771-1-alisa...@amazon.com
---
V2: Fix the fallout for CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=n (0day)
---
arch/x86/kernel/apic/vector.c | 22 +-
kernel/irq/manage.c | 37 +++--
2 files changed, 40 insertions(+), 19 deletions(-)
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -446,12 +446,10 @@ static int x86_vector_activate(struct ir
trace_vector_activate(irqd->irq, apicd->is_managed,
apicd->can_reserve, reserve);
- /* Nothing to do for fixed assigned vectors */
- if (!apicd->can_reserve && !apicd->is_managed)
- return 0;
-
raw_spin_lock_irqsave(&vector_lock, flags);
- if (reserve || irqd_is_managed_and_shutdown(irqd))
+ if (!apicd->can_reserve && !apicd->is_managed)
+ assign_irq_vector_any_locked(irqd);
+ else if (reserve || irqd_is_managed_and_shutdown(irqd))
vector_assign_managed_shutdown(irqd);
else if (apicd->is_managed)
ret = activate_managed(irqd);
@@ -775,20 +773,10 @@ void lapic_offline(void)
static int apic_set_affinity(struct irq_data *irqd,
const struct cpumask *dest, bool force)
{
- struct apic_chip_data *apicd = apic_chip_data(irqd);
int err;
- /*
-* Core code can call here for inactive interrupts. For inactive
-* interrupts which use managed or reservation mode there is no
-* point in going through the vector assignment right now as the
-* activation will assign a vector which fits the destination
-* cpumask. Let the core code store the destination mask and be
-* done with it.
-*/
- if (!irqd_is_activated(irqd) &&
- (apicd->is_managed || apicd->can_reserve))
- return IRQ_SET_MASK_OK;
+ if (WARN_ON_ONCE(!irqd_is_activated(irqd)))
+ return -EIO;
raw_spin_lock(&vector_lock);
cpumask_and(vector_searchmask, dest, cpu_online_mask);
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -195,9 +195,9 @@ void irq_set_thread_affinity(struct irq_
set_bit(IRQTF_AFFINITY, &action->thread_flags);
}
+#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK
static void irq_validate_effective_affinity(struct irq_data *data)
{
-#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK
const struct cpumask *m = irq_data_get_effective_affinity_mask(data);
struct irq_chip *chip = irq_data_get_irq_chip(data);
@@ -205,9 +205,19 @@ static void irq_validate_effective_affin
return;
pr_warn_once("irq_chip %s did not update eff. affinity mask of irq
%u\n",
chip->name, data->irq);
-#endif
}
+static inline void irq_init_effective_affinity(struct irq_data *data,
+ const struct cpumask *mask)
+{
+ cpumask_copy(irq_data_get_effective_affinity_mask(data), mask);
+}
+#else
+static inline void irq_validate_effective_affinity(struct irq_data *data) { }
+static inline void irq_init_effective_affinity(struct irq_data *data,
+ const struct cpumask *mask) { }
+#endif
+
int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask,
bool force)
{
@@ -304,6 +314,26 @@ static int irq_try_set_affinity(struct i
return ret;
}
+static bool irq_set
[PATCH v2 1/8] ARM: dts: sunxi: libretech-all-h3-cc: Add regulator supply to all CPU cores
From: Chen-Yu Tsai
The device tree currently only assigns the a supply for the first CPU
core, when in reality the regulator supply is shared by all four cores.
This might cause an issue if the implementation does not realize the
sharing of the supply.
Assign the same regulator supply to the remaining CPU cores to address
this.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
b/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
index 19b3b23cfaa8..c44fd726945a 100644
--- a/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
+++ b/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
@@ -128,6 +128,18 @@ &cpu0 {
cpu-supply = <®_vdd_cpux>;
};
+&cpu1 {
+ cpu-supply = <®_vdd_cpux>;
+};
+
+&cpu2 {
+ cpu-supply = <®_vdd_cpux>;
+};
+
+&cpu3 {
+ cpu-supply = <®_vdd_cpux>;
+};
+
&de {
status = "okay";
};
--
2.27.0
[PATCH v2 4/8] arm64: dts: allwinner: h5: Add clock to CPU cores
From: Chen-Yu Tsai
The ARM CPU cores are fed by the CPU clock from the CCU. Add a
reference to the clock for each CPU core, along with the clock
transition latency.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index 4462a68c0681..09523f6011c5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -13,6 +13,8 @@ cpu0: cpu@0 {
device_type = "cpu";
reg = <0>;
enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
};
cpu1: cpu@1 {
@@ -20,6 +22,8 @@ cpu1: cpu@1 {
device_type = "cpu";
reg = <1>;
enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
};
cpu2: cpu@2 {
@@ -27,6 +31,8 @@ cpu2: cpu@2 {
device_type = "cpu";
reg = <2>;
enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
};
cpu3: cpu@3 {
@@ -34,6 +40,8 @@ cpu3: cpu@3 {
device_type = "cpu";
reg = <3>;
enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
};
};
--
2.27.0
[PATCH v2 5/8] arm64: dts: allwinner: h5: Add trip and cooling maps to CPU thermal zones
From: Chen-Yu Tsai
This enables passive cooling by down-regulating CPU voltage and frequency.
The trip points were copied from the H3.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 30
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index 09523f6011c5..6735e316a39c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -3,6 +3,8 @@
#include
+#include
+
/ {
cpus {
#address-cells = <1>;
@@ -15,6 +17,7 @@ cpu0: cpu@0 {
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -24,6 +27,7 @@ cpu1: cpu@1 {
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -33,6 +37,7 @@ cpu2: cpu@2 {
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -42,6 +47,7 @@ cpu3: cpu@3 {
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
+ #cooling-cells = <2>;
};
};
@@ -173,6 +179,30 @@ cpu_thermal: cpu-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = <&ths 0>;
+
+ trips {
+ cpu_hot_trip: cpu-hot {
+ temperature = <8>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_very_hot_trip: cpu-very-hot {
+ temperature = <10>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ cpu-hot-limit {
+ trip = <&cpu_hot_trip>;
+ cooling-device = <&cpu0
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<&cpu1
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<&cpu2
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<&cpu3
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpu_thermal {
--
2.27.0
[PATCH v2 3/8] ARM: dts: sunxi: bananapi-m2-plus-v1.2: Fix CPU supply voltages
From: Chen-Yu Tsai
The Bananapi M2+ uses a GPIO line to change the effective resistance of
the CPU supply regulator's feedback resistor network. The voltages
described in the device tree were given directly by the vendor. This
turns out to be slightly off compared to the real values.
The updated voltages are based on calculations of the feedback resistor
network, and verified down to three decimal places with a multi-meter.
Fixes: 6eeb4180d4b9 ("ARM: dts: sunxi: h3-h5: Add Bananapi M2+ v1.2 device
trees")
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
b/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
index a628b5ee72b6..235994a4a2eb 100644
--- a/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
+++ b/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
@@ -16,12 +16,12 @@ reg_vdd_cpux: vdd-cpux {
regulator-type = "voltage";
regulator-boot-on;
regulator-always-on;
- regulator-min-microvolt = <110>;
- regulator-max-microvolt = <130>;
+ regulator-min-microvolt = <1108475>;
+ regulator-max-microvolt = <1308475>;
regulator-ramp-delay = <50>; /* 4ms */
gpios = <&r_pio 0 1 GPIO_ACTIVE_HIGH>; /* PL1 */
gpios-states = <0x1>;
- states = <110 0>, <130 1>;
+ states = <1108475 0>, <1308475 1>;
};
};
--
2.27.0
[PATCH v2 7/8] arm64: dts: allwinner: h5: libretech-all-h3-cc: Tie in CPU OPPs
From: Chen-Yu Tsai
The Libre Computer ALL-H3-CC H5 variant can work with the standard H5
OPPs. Tie them in to enable CPU frequency scaling.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/allwinner/sun50i-h5-libretech-all-h3-cc.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-libretech-all-h3-cc.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h5-libretech-all-h3-cc.dts
index 64d35daf2023..d811df332824 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-libretech-all-h3-cc.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-libretech-all-h3-cc.dts
@@ -4,6 +4,7 @@
/dts-v1/;
#include "sun50i-h5.dtsi"
+#include "sun50i-h5-cpu-opp.dtsi"
#include
/ {
--
2.27.0
[PATCH v2 8/8] arm64: dts: allwinner: h5: bananapi-m2-plus-v1.2: Tie in CPU OPPs
From: Chen-Yu Tsai
The Bananapi M2 Plus H5 v1.2 can work with the standard H5 OPPs.
Tie them in to enable CPU frequency scaling.
The original Bananapi M2 Plus H5 is left out for now, as adding
the fixed regulator along with the enable pin seemed to cause some
glitching in Linux.
Signed-off-by: Chen-Yu Tsai
---
.../arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dts
index 2e2b14c0ae75..8857a3791593 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dts
@@ -3,6 +3,7 @@
/dts-v1/;
#include "sun50i-h5.dtsi"
+#include "sun50i-h5-cpu-opp.dtsi"
#include
/ {
--
2.27.0
[PATCH v2 2/8] ARM: dts: sunxi: bananapi-m2-plus-v1.2: Add regulator supply to all CPU cores
From: Chen-Yu Tsai
The device tree currently only assigns the a supply for the first CPU
core, when in reality the regulator supply is shared by all four cores.
This might cause an issue if the implementation does not realize the
sharing of the supply.
Assign the same regulator supply to the remaining CPU cores to address
this.
Fixes: 6eeb4180d4b9 ("ARM: dts: sunxi: h3-h5: Add Bananapi M2+ v1.2 device
trees")
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
b/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
index 22466afd38a3..a628b5ee72b6 100644
--- a/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
+++ b/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
@@ -28,3 +28,15 @@ reg_vdd_cpux: vdd-cpux {
&cpu0 {
cpu-supply = <®_vdd_cpux>;
};
+
+&cpu1 {
+ cpu-supply = <®_vdd_cpux>;
+};
+
+&cpu2 {
+ cpu-supply = <®_vdd_cpux>;
+};
+
+&cpu3 {
+ cpu-supply = <®_vdd_cpux>;
+};
--
2.27.0
[PATCH v2 6/8] arm64: dts: allwinner: h5: Add CPU Operating Performance Points table
From: Chen-Yu Tsai
Add an OPP (Operating Performance Points) table for the CPU cores for
boards to include to DVFS (Dynamic Voltage & Frequency Scaling) on the
H5. The table originates from Armbian, but the maximum voltage is raised
slightly to account for boards using slightly higher voltages.
The table and tie in to the CPU cores are put in a separate dtsi file
that board files can include to opt in. Or they can define their own
tables if the standard one does not fit.
This has been tested on the Libre Computer ALL-H3-CC-H5 and the Bananapi
M2+ v1.2 H5, both with adequate cooling. The former has a fixed 1.2V
regulator, while the latter has a GPIO controlled regulator switchable
between 1.1V and 1.3V.
Signed-off-by: Chen-Yu Tsai
---
Unfortunately I couldn't find the original source and author for the OPP
table. So for now I put my name on it. If someone wants to claim
authorship please do so.
---
.../boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi | 79 +++
1 file changed, 79 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi
new file mode 100644
index ..9d3a9fa78e2e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Chen-Yu Tsai
+
+/ {
+ cpu_opp_table: opp_table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@40800 {
+ opp-hz = /bits/ 64 <40800>;
+ opp-microvolt = <100 100 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@64800 {
+ opp-hz = /bits/ 64 <64800>;
+ opp-microvolt = <104 104 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@81600 {
+ opp-hz = /bits/ 64 <81600>;
+ opp-microvolt = <108 108 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@91200 {
+ opp-hz = /bits/ 64 <91200>;
+ opp-microvolt = <112 112 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@96000 {
+ opp-hz = /bits/ 64 <96000>;
+ opp-microvolt = <116 116 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@100800 {
+ opp-hz = /bits/ 64 <100800>;
+ opp-microvolt = <120 120 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@105600 {
+ opp-hz = /bits/ 64 <105600>;
+ opp-microvolt = <124 124 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@110400 {
+ opp-hz = /bits/ 64 <110400>;
+ opp-microvolt = <126 126 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp@115200 {
+ opp-hz = /bits/ 64 <115200>;
+ opp-microvolt = <130 130 131>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ };
+};
+
+&cpu0 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu1 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu2 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu3 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
--
2.27.0
[PATCH v2 0/8] arm64: dts: allwinner: h5: Enable CPU DVFS (cpufreq)
From: Chen-Yu Tsai Hi everyone, This is v2 of my Allwinner H5 SoC cpufreq support series from way back [1]. The series enables DVFS for the CPU cores (aka cpufreq) on the Allwinner H5 SoC. The OPP table was taken from Armbian, with minor tweaks to the maximum voltage to account for slightly increased voltage on some of the boards. In this version, the OPP table and tie in to the CPU cores has been split out into a separate file, like what was done for the H6. The patches adding CPU regulator supplies for all the boards that I don't have have been removed. The series now only enables cpufreq for Libre Computer ALL-H3-CC and ALL-H5-CC, and Bananapi M2+ v1.2. For the original Bananapi M2+, if I add the fixed regulator with the enable pin, it ends up causing some sort of glitch or lock up on the v1.2, which includes the original dts file. Since I haven't been able to sort it out yet, I've left it out for now. Patch 1 assigns the CPU regulator supply to all the CPU cores on the Libre Computer ALL-H3-CC. Patch 2 assigns the CPU regulator supply to all the CPU cores on the Bananapi M2+ v1.2. Patch 3 fixes the voltages specified for the GPIO-controlled regulator on the Bananapi M2+ v1.2. The voltages are slightly higher than what was originally written. Patch 4 ties the CPU clock to the CPU cores. Patch 5 adds trip points and cooling maps to the CPU thermal zones. Patch 6 adds the OPP table, based on the one from Armbian. Patch 7 hooks up the CPU regulator supply for the Libre Computer ALL-H3-CC H5 variant, and by extension, the ALL-H5-CC. Patch 8 hooks up the CPU regulator supply for the Bananapi M2+ v1.2. Changes since v1: - Re-ordered patches - Added patches to set regulator supply for all CPU cores - Added thermal trip points and cooling maps - OPP table and assignment split into separate file - Added patches to tie in OPP table file for the boards I have Please have a look. Regards ChenYu [1] https://patchwork.kernel.org/cover/10787869/ Chen-Yu Tsai (8): ARM: dts: sunxi: libretech-all-h3-cc: Add regulator supply to all CPU cores ARM: dts: sunxi: bananapi-m2-plus-v1.2: Add regulator supply to all CPU cores ARM: dts: sunxi: bananapi-m2-plus-v1.2: Fix CPU supply voltages arm64: dts: allwinner: h5: Add clock to CPU cores arm64: dts: allwinner: h5: Add trip and cooling maps to CPU thermal zones arm64: dts: allwinner: h5: Add CPU Operating Performance Points table arm64: dts: allwinner: h5: libretech-all-h3-cc: Tie in CPU OPPs arm64: dts: allwinner: h5: bananapi-m2-plus-v1.2: Tie in CPU OPPs .../boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 18 - .../boot/dts/sunxi-libretech-all-h3-cc.dtsi | 12 +++ .../sun50i-h5-bananapi-m2-plus-v1.2.dts | 1 + .../boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi | 79 +++ .../sun50i-h5-libretech-all-h3-cc.dts | 1 + arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 38 + 6 files changed, 146 insertions(+), 3 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi -- 2.27.0
Re: [PATCH 2/2] Input: elan_i2c - Modify the IAP related functio n for page sizes 128, 512 bytes.
Hi Jingle,
On Fri, Jul 17, 2020 at 04:31:58PM +0800, jingle wrote:
> Hi Dmitry:
>
> 1.
>
> In this function elan_get_fwinfo().
>
> +static int elan_get_fwinfo(u16 ic_type, u8 iap_version, u8 pattern,
> +u16 *validpage_count, u32 *signature_address,
> +u16 *page_size)
> {
> - switch (ic_type) {
> + u16 type = pattern >= 0x01 ? ic_type : iap_version;
> +
> + switch (type) {
>
> This iap_version in pattern0 is read from this command
> ETP_I2C_IAP_VERSION_CMD_OLD ,it is not from this command
> ETP_I2C_IAP_VERSION.
> So u16 type = pattern >= 0x01 ? ic_type : iap_version; <- wrong
>
> 2. In this "static int elan_i2c_prepare_fw_update(struct i2c_client *client,
> u16 ic_type, u8 iap_version)" function.
> The ic is old pattern must be modify correct ic_type. (cmd is
> ETP_I2C_IAP_VERSION)
I see. It looks like there is some confusion on my part between IAP
version, IC type, and the commands that we want to use. Please let me
know if I understand this correctly:
- For patterns >=1 (newer)
IAP version is retrieved with ETP_I2C_IAP_VERSION_CMD
IC type is fetched with ETP_I2C_IC_TYPE_CMD
Version comes from ETP_I2C_NSM_VERSION_CMD
- For pattern 0 (old)
Before your patches
IAP version was using ETP_I2C_IAP_VERSION_CMD (and you are saying
it is wrong)
Version comes from 1st byte of ETP_I2C_OSM_VERSION_CMD
IC type comes from 2nd byte of ETP_I2C_OSM_VERSION_CMD (and you are
saying it is some other bit of data - what is it then?)
After your patches
IAP version is retrieved with ETP_I2C_IAP_VERSION_CMD_OLD
Version comes from 1st byte of ETP_I2C_OSM_VERSION_CMD
IC type is retrieved with ETP_I2C_IAP_VERSION_CMD (should we rename
it then?)
So the difference is where the the IC type is coming from for old
patterns. However, as I mentioned, we have the following body of code:
static int elan_check_ASUS_special_fw(struct elan_tp_data *data)
{
if (data->ic_type == 0x0E) {
switch (data->product_id) {
case 0x05 ... 0x07:
case 0x09:
case 0x13:
return true;
}
} else if (data->ic_type == 0x08 && data->product_id == 0x26) {
/* ASUS EeeBook X205TA */
return true;
}
return false;
}
And before your patches ic_type here would be the 2nd byte of response
to ETP_I2C_OSM_VERSION_CMD for older devices and my concern that
replacing it with data from ETP_I2C_IAP_VERSION_CMD would break these
checks.
We need to reconcile what we have in this function with what you are
proposing for firmware update code.
Thanks,
Dmitry
Re: [PATCH v5 5/5] iommu/vt-d: Check UAPI data processed by IOMMU core
Hi Jacob, On 7/16/20 8:45 PM, Jacob Pan wrote: > IOMMU generic layer already does sanity checks UAPI data for version > match and argsz range under generic information. > Remove the redundant version check from VT-d driver and check for vendor > specific data size. > > Signed-off-by: Jacob Pan Reviewed-by: Eric Auger Thanks Eric > --- > drivers/iommu/intel/iommu.c | 3 +-- > drivers/iommu/intel/svm.c | 7 +-- > 2 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index f3a6ca88cf95..5e80484f0537 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -5383,8 +5383,7 @@ intel_iommu_sva_invalidate(struct iommu_domain *domain, > struct device *dev, > int ret = 0; > u64 size = 0; > > - if (!inv_info || !dmar_domain || > - inv_info->version != IOMMU_CACHE_INVALIDATE_INFO_VERSION_1) > + if (!inv_info || !dmar_domain) > return -EINVAL; > > if (!dev || !dev_is_pci(dev)) > diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c > index 713b3a218483..55ea11e9c0f5 100644 > --- a/drivers/iommu/intel/svm.c > +++ b/drivers/iommu/intel/svm.c > @@ -240,8 +240,11 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain, > struct device *dev, > if (WARN_ON(!iommu) || !data) > return -EINVAL; > > - if (data->version != IOMMU_GPASID_BIND_VERSION_1 || > - data->format != IOMMU_PASID_FORMAT_INTEL_VTD) > + if (data->format != IOMMU_PASID_FORMAT_INTEL_VTD) > + return -EINVAL; > + > + /* IOMMU core ensures argsz is more than the start of the union */ > + if (data->argsz < offsetofend(struct iommu_gpasid_bind_data, > vendor.vtd)) > return -EINVAL; > > if (!dev_is_pci(dev)) >
Re: [PATCH v4] coccinelle: api: add kzfree script
I dare to repeat previous patch review aspects once more. https://lore.kernel.org/cocci/a316f076-1686-25d8-18fe-1bbc0cf9a...@web.de/ … > +virtual context > +virtual patch > +virtual org > +virtual report +virtual context, patch, org, report Is such a SmPL code variant more succinct? … > +if (...) > + \(memset@ok\|memzero_explicit@ok\)(...); Would you like to tolerate any extra source code around such a function call in an if branch? … > +( > +* memset@m((T)E, 0, ...); > +| > +* memzero_explicit@m((T)E, ...); > +) … I suggest to move a semicolon. +( +*memset@m((T)E, 0, ...) +| +*memzero_explicit@m((T)E, ...) +); … > +- \(kfree\|vfree\|kvfree\)(E); > ++ kvfree_sensitive(E, size); … Would you like to increase the precision a bit for the change specification? +-\(kfree\|vfree\|kvfree\) ++kvfree_sensitive + (E ++ , size + ); … > +( > +- kfree(E); > ++ kzfree(E); > +| > +- \(vfree\|kvfree\)(E); > ++ kvfree_sensitive(E, size); > +) … +( +-kfree ++kzfree + (E) +| +-\(vfree\|kvfree\) ++kvfree_sensitive + (E ++ , size + ) +); … > +// TODO: uncomment when kfree_sensitive will be merged. > +// Only this case is commented out because developers > +// may not like patches like this since kzfree uses memset > +// internally (not memzero_explicit). Will this information trigger any further clarification? … > +coccilib.org.print_todo(p[0], > + "WARNING: opportunity for kzfree/kvfree_sensitive") I propose to align the second function parameter. +coccilib.org.print_todo(p[0], +"WARNING: opportunity for kzfree/kvfree_sensitive") Regards, Markus
Re: [PATCH 1/3] dt-bindings: gpio: sunxi：create a DT header for Allwinner pin controller
Hi! On Wed, Jul 15, 2020 at 07:54:12PM +0800, Frank Lee wrote: > From: Yangtao Li > > The sunxi gpio binding defines a few custom cells for its gpio specifier. > Provide bank name for those. > > Signed-off-by: Yangtao Li Thanks for working on this, I wanted to do it at some point but it kept getting pushed further into my todo list. > --- > include/dt-bindings/gpio/sunxi-gpio.h | 29 +++ > 1 file changed, 29 insertions(+) > create mode 100644 include/dt-bindings/gpio/sunxi-gpio.h > > diff --git a/include/dt-bindings/gpio/sunxi-gpio.h > b/include/dt-bindings/gpio/sunxi-gpio.h > new file mode 100644 > index ..c692b4360da6 > --- /dev/null > +++ b/include/dt-bindings/gpio/sunxi-gpio.h So generally we've been using the compatible name as the file name. You should follow that convention too, and since it was added with the A10, using the A10 compatible. > @@ -0,0 +1,29 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * GPIO definitions for Allwinner SoCs > + * > + * Copyright (C) 2020 Yangtao Li > + */ > + > +#ifndef _DT_BINDINGS_SUNXI_GPIO_H > +#define _DT_BINDINGS_SUNXI_GPIO_H > + > +#include > + > +/* pio */ > +#define PA 0 > +#define PB 1 > +#define PC 2 > +#define PD 3 > +#define PE 4 > +#define PF 5 > +#define PG 6 > +#define PH 7 > +#define PI 8 > + > +/* r-pio */ > +#define PL 0 > +#define PM 1 > +#define PN 2 > + > +#endif /* _DT_BINDINGS_SUNXI_GPIO_H */ Maybe we can go one step further and use a macro to have something like PIN(A, 12) ? Maxime signature.asc Description: PGP signature
Re: [PATCH 2/3] ARM: dts: allwinner: convert gpio.h to sunxi-gpio.h
On Wed, Jul 15, 2020 at 07:55:07PM +0800, Frank Lee wrote: > From: Yangtao Li > > Use names instead of numbers to describe GPIO. We clean arm64 first. > Since H5 uses the DTS file in arm directory, we need to modify the > header file in advance. > > Signed-off-by: Yangtao Li > > --- > arch/arm/boot/dts/sunxi-h3-h5-emlid-neutis.dtsi | 2 +- > arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5-emlid-neutis.dtsi > b/arch/arm/boot/dts/sunxi-h3-h5-emlid-neutis.dtsi > index fc67e30fe212..93f9653b43f4 100644 > --- a/arch/arm/boot/dts/sunxi-h3-h5-emlid-neutis.dtsi > +++ b/arch/arm/boot/dts/sunxi-h3-h5-emlid-neutis.dtsi > @@ -7,7 +7,7 @@ > > #include "sunxi-common-regulators.dtsi" > > -#include > +#include I think we should have both. The gpio.h header is supposed to be for the generic defines, while ours would be for the one specific to the allwinner SoCs (just like it's being done for the GIC vs generic interrupt flags) Maxime signature.asc Description: PGP signature
Re: [PATCH v16 15/22] mm/compaction: do page isolation first in compaction
On Thu, Jul 16, 2020 at 10:10 PM Alex Shi wrote:
>
>
> >> @@ -950,6 +951,21 @@ static bool too_many_isolated(pg_data_t *pgdat)
> >> if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page))
> >> goto isolate_fail;
> >>
> >> + /*
> >> +* Be careful not to clear PageLRU until after we're
> >> +* sure the page is not being freed elsewhere -- the
> >> +* page release code relies on it.
> >> +*/
> >> + if (unlikely(!get_page_unless_zero(page)))
> >> + goto isolate_fail;
> >> +
> >> + if (__isolate_lru_page_prepare(page, isolate_mode) != 0)
> >> + goto isolate_fail_put;
> >> +
> >> + /* Try isolate the page */
> >> + if (!TestClearPageLRU(page))
> >> + goto isolate_fail_put;
> >> +
> >> /* If we already hold the lock, we can skip some
> >> rechecking */
> >> if (!locked) {
> >> locked = compact_lock_irqsave(&pgdat->lru_lock,
> >
> > Why not do the __isolate_lru_page_prepare before getting the page?
> > That way you can avoid performing an extra atomic operation on non-LRU
> > pages.
> >
>
> This change come from Hugh Dickins as mentioned from commit log:
> >> trylock_page() is not safe to use at this time: its setting PG_locked
> >> can race with the page being freed or allocated ("Bad page"), and can
> >> also erase flags being set by one of those "sole owners" of a freshly
> >> allocated page who use non-atomic __SetPageFlag().
>
> Hi Hugh,
>
> would you like to show more details of the bug?
>
> ...
>
> >> +* sure the page is not being freed elsewhere --
> >> the
> >> +* page release code relies on it.
> >> +*/
> >> + if (unlikely(!get_page_unless_zero(page)))
> >> + goto busy;
> >> +
> >> + if (!TestClearPageLRU(page)) {
> >> + /*
> >> +* This page may in other isolation path,
> >> +* but we still hold lru_lock.
> >> +*/
> >> + put_page(page);
> >> + goto busy;
> >> + }
> >> +
> >
> > I wonder if it wouldn't make sense to combine these two atomic ops
> > with tests and the put_page into a single inline function? Then it
> > could be possible to just do one check and if succeeds you do the
> > block of code below, otherwise you just fall-through into the -EBUSY
> > case.
> >
>
> Uh, since get_page changes page->_refcount, TestClearPageLRU changes
> page->flags,
> So I don't know how to combine them, could you make it more clear with code?
Actually it is pretty straight forward. Something like this:
static inline bool get_page_unless_zero_or_nonlru(struct page *page)
{
if (get_page_unless_zero(page)) {
if (TestClearPageLRU(page))
return true;
put_page(page);
}
return false;
}
You can then add comments as necessary. The general idea is you are
having to do this in two different spots anyway so why not combine the
logic? Although it does assume you can change the ordering of the
other test above.
Re: [PATCH 3/3] arm64: dts: allwinner: Use GPIO bank name macro to describe GPIO
On Wed, Jul 15, 2020 at 07:55:29PM +0800, Frank Lee wrote:
> From: Yangtao Li
>
> Convert gpio.h to sunxi-gpio.h, and convert to use gpio bank name macro.
> This is done using the following command.
>
> sed -i 's/r_pio 0/r_pio PL/g' arch/arm64/boot/dts/allwinner/*
> sed -i 's/r_pio 1/r_pio PM/g' arch/arm64/boot/dts/allwinner/*
>
> sed -i 's/\&pio 0/\&pio PA/g' arch/arm64/boot/dts/allwinner/*
> sed -i 's/\&pio 2/\&pio PC/g' arch/arm64/boot/dts/allwinner/*
> sed -i 's/\&pio 3/\&pio PD/g' arch/arm64/boot/dts/allwinner/*
> sed -i 's/\&pio 4/\&pio PE/g' arch/arm64/boot/dts/allwinner/*
> sed -i 's/\&pio 5/\&pio PF/g' arch/arm64/boot/dts/allwinner/*
> sed -i 's/\&pio 6/\&pio PG/g' arch/arm64/boot/dts/allwinner/*
> sed -i 's/\&pio 7/\&pio PH/g' arch/arm64/boot/dts/allwinner/*
>
> sed -i 's/dt-bindings\/gpio\/gpio.h/dt-bindings\/gpio\/sunxi-gpio.h/g' \
> arch/arm64/boot/dts/allwinner/*
>
> Signed-off-by: Yangtao Li
>
> ---
> .../allwinner/sun50i-a64-amarula-relic.dts| 18 ++--
> .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 20 ++---
> .../dts/allwinner/sun50i-a64-nanopi-a64.dts | 8 +++---
> .../sun50i-a64-oceanic-5205-5inmfd.dts| 4 +--
> .../dts/allwinner/sun50i-a64-olinuxino.dts| 12
> .../dts/allwinner/sun50i-a64-orangepi-win.dts | 20 ++---
> .../boot/dts/allwinner/sun50i-a64-pine64.dts | 4 +--
> .../dts/allwinner/sun50i-a64-pinebook.dts | 16 +--
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 14 +-
> .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 28 +--
> .../boot/dts/allwinner/sun50i-a64-sopine.dtsi | 4 +--
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 20 ++---
> .../sun50i-h5-emlid-neutis-n5-devboard.dts| 2 +-
> .../sun50i-h5-libretech-all-h5-cc.dts | 2 +-
> .../allwinner/sun50i-h5-nanopi-neo-plus2.dts | 14 +-
> .../dts/allwinner/sun50i-h5-nanopi-neo2.dts | 14 +-
> .../dts/allwinner/sun50i-h5-orangepi-pc2.dts | 16 +--
> .../allwinner/sun50i-h5-orangepi-prime.dts| 18 ++--
> .../sun50i-h5-orangepi-zero-plus.dts | 13 +
> .../sun50i-h5-orangepi-zero-plus2.dts | 6 ++--
> .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 8 +++---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts| 20 ++---
> .../allwinner/sun50i-h6-orangepi-lite2.dts| 8 +++---
> .../allwinner/sun50i-h6-orangepi-one-plus.dts | 2 +-
> .../dts/allwinner/sun50i-h6-orangepi.dtsi | 12
> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 16 +--
> .../dts/allwinner/sun50i-h6-tanix-tx6.dts | 6 ++--
> 27 files changed, 163 insertions(+), 162 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> index c7bd73f35ed8..92f8caecf939 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> @@ -7,7 +7,7 @@
> #include "sun50i-a64.dtsi"
> #include "sun50i-a64-cpu-opp.dtsi"
>
> -#include
> +#include
>
> / {
> model = "Amarula A64-Relic";
> @@ -23,8 +23,8 @@ chosen {
>
> i2c {
> compatible = "i2c-gpio";
> - sda-gpios = <&pio 4 13 GPIO_ACTIVE_HIGH>;
> - scl-gpios = <&pio 4 12 GPIO_ACTIVE_HIGH>;
> + sda-gpios = <&pio PE 13 GPIO_ACTIVE_HIGH>;
> + scl-gpios = <&pio PE 12 GPIO_ACTIVE_HIGH>;
> i2c-gpio,delay-us = <5>;
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -40,8 +40,8 @@ ov5640: camera@3c {
> AVDD-supply = <®_aldo1>;
> DOVDD-supply = <®_dldo3>;
> DVDD-supply = <®_eldo3>;
> - reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /*
> CSI-RST-R: PE14 */
> - powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /*
> CSI-STBY-R: PE15 */
> + reset-gpios = <&pio PE 14 GPIO_ACTIVE_LOW>; /*
> CSI-RST-R: PE14 */
> + powerdown-gpios = <&pio PE 15 GPIO_ACTIVE_HIGH>; /*
> CSI-STBY-R: PE15 */
The pin name is fairly obvious now, I guess we can just remove the PE14
/ PE15 from the comment (and that applies to the other DT as well)
Maxime
signature.asc
Description: PGP signature
[PATCH v4 0/2] drivers: provide devm_platform_request_irq()
It will call devm_request_irq() after platform_get_irq() function in many drivers, And sometimes, the error handling of these two functions is incorrect in some drivers. So this function is provided to simplify the driver. the first patch will provide devm_platform_request_irq(), and the second patch will convert to devm_platform_request_irq() in some dirver of i2c bus. v3 -> v4: - The patch v3 sent on May 27 may be lost somewhere in the world, so resend it. - add Michal's Acked-by tag in the second patch. and Thanks for Michal's help. v2 -> v3: - add devm_platform_request_irq() to devres.rst by Grygorii's suggestion. - And also Thanks Michal, Wolfram and Linus's review and comments. v1 -> v2: - I give up this series of patches in v1 version. I resend this patches v2 by that discussion: https://patchwork.ozlabs.org/project/linux-i2c/patch/20200520144821.8069-1-zhengdej...@gmail.com/ The patch content has not changed. Dejin Zheng (2): drivers: provide devm_platform_request_irq() i2c: busses: convert to devm_platform_request_irq() .../driver-api/driver-model/devres.rst| 1 + drivers/base/platform.c | 33 +++ drivers/i2c/busses/i2c-bcm-kona.c | 16 ++--- drivers/i2c/busses/i2c-cadence.c | 10 ++ drivers/i2c/busses/i2c-digicolor.c| 10 ++ drivers/i2c/busses/i2c-emev2.c| 5 ++- drivers/i2c/busses/i2c-jz4780.c | 5 ++- drivers/i2c/busses/i2c-meson.c| 13 +++- drivers/i2c/busses/i2c-mxs.c | 9 ++--- drivers/i2c/busses/i2c-pnx.c | 9 ++--- drivers/i2c/busses/i2c-rcar.c | 9 ++--- drivers/i2c/busses/i2c-rk3x.c | 14 ++-- drivers/i2c/busses/i2c-sirf.c | 10 ++ drivers/i2c/busses/i2c-stu300.c | 4 +-- drivers/i2c/busses/i2c-synquacer.c| 12 ++- include/linux/platform_device.h | 4 +++ 16 files changed, 73 insertions(+), 91 deletions(-) -- 2.25.0
[PATCH v4 1/2] drivers: provide devm_platform_request_irq()
It will call devm_request_irq() after platform_get_irq() function
in many drivers, And sometimes, the error handling of these two functions
is incorrect in some drivers. So this function is provided to simplify
the driver.
Cc: Michal Simek
Cc: Wolfram Sang
Signed-off-by: Dejin Zheng
---
v3 -> v4:
- The patch v3 sent on May 27 may be lost somewhere in the
world, so resend it.
v2 -> v3:
- add devm_platform_request_irq() to devres.rst by Grygorii's
suggestion.
v1 -> v2:
- The patch content has not changed. just resend it by this discussion:
https://patchwork.ozlabs.org/project/linux-i2c/patch/20200520144821.8069-1-zhengdej...@gmail.com/
.../driver-api/driver-model/devres.rst| 1 +
drivers/base/platform.c | 33 +++
include/linux/platform_device.h | 4 +++
3 files changed, 38 insertions(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst
b/Documentation/driver-api/driver-model/devres.rst
index efc21134..9c75903bce7c 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -326,6 +326,7 @@ IRQ
devm_request_any_context_irq()
devm_request_irq()
devm_request_threaded_irq()
+ devm_platform_request_irq()
devm_irq_alloc_descs()
devm_irq_alloc_desc()
devm_irq_alloc_desc_at()
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e5d8a0503b4f..d4212d12bf60 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -275,6 +275,39 @@ int platform_irq_count(struct platform_device *dev)
}
EXPORT_SYMBOL_GPL(platform_irq_count);
+/**
+ * devm_platform_request_irq - get an irq and allocate an interrupt
+ * line for a managed device
+ * @pdev: platform device
+ * @num: IRQ number index
+ * @irq: get an IRQ for a device if irq != NULL
+ * @handler: function to be called when the IRQ occurs
+ * @irqflags: interrupt type flags
+ * @devname: an ascii name for the claiming device, dev_name(dev) if NULL
+ * @dev_id: a cookie passed back to the handler function
+ *
+ * Return: zero on success, negative error number on failure.
+ */
+int devm_platform_request_irq(struct platform_device *pdev, unsigned int num,
+ unsigned int *irq, irq_handler_t handler,
+ unsigned long irqflags, const char *devname, void *dev_id)
+{
+ int tmp_irq, ret;
+
+ tmp_irq = platform_get_irq(pdev, num);
+ if (tmp_irq < 0)
+ return tmp_irq;
+
+ ret = devm_request_irq(&pdev->dev, tmp_irq, handler, irqflags,
+ devname, dev_id);
+ if (ret < 0)
+ dev_err(&pdev->dev, "can't request IRQ\n");
+ else if (irq != NULL)
+ *irq = tmp_irq;
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devm_platform_request_irq);
+
/**
* platform_get_resource_byname - get a resource for a device by name
* @dev: platform device
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 77a2aada106d..d94652deea5c 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -11,6 +11,7 @@
#define _PLATFORM_DEVICE_H_
#include
+#include
#define PLATFORM_DEVID_NONE(-1)
#define PLATFORM_DEVID_AUTO(-2)
@@ -70,6 +71,9 @@ devm_platform_ioremap_resource_byname(struct platform_device
*pdev,
extern int platform_get_irq(struct platform_device *, unsigned int);
extern int platform_get_irq_optional(struct platform_device *, unsigned int);
extern int platform_irq_count(struct platform_device *);
+extern int devm_platform_request_irq(struct platform_device *pdev,
+ unsigned int num, unsigned int *irq, irq_handler_t handler,
+ unsigned long irqflags, const char *devname, void *dev_id);
extern struct resource *platform_get_resource_byname(struct platform_device *,
unsigned int,
const char *);
--
2.25.0
Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
> > I agree with Nick: A memory barrier is needed somewhere between the > > assignment at 6 and the return to user mode at 8. Otherwise you end up > > with the Store Buffer pattern having a memory barrier on only one side, > > and it is well known that this arrangement does not guarantee any > > ordering. > > Yes, I see this now. I'm still trying to wrap my head around why the memory > barrier at the end of membarrier() needs to be paired with a scheduler > barrier though. The memory barrier at the end of membarrier() on CPU0 is necessary in order to enforce the guarantee that any writes occurring on CPU1 before the membarrier() is executed will be visible to any code executing on CPU0 after the membarrier(). Ignoring the kthread issue, we can have: CPU0CPU1 x = 1 barrier() y = 1 r2 = y membarrier(): a: smp_mb() b: send IPI IPI-induced mb c: smp_mb() r1 = x The writes to x and y are unordered by the hardware, so it's possible to have r2 = 1 even though the write to x doesn't execute until b. If the memory barrier at c is omitted then "r1 = x" can be reordered before b (although not before a), so we get r1 = 0. This violates the guarantee that membarrier() is supposed to provide. The timing of the memory barrier at c has to ensure that it executes after the IPI-induced memory barrier on CPU1. If it happened before then we could still end up with r1 = 0. That's why the pairing matters. I hope this helps your head get properly wrapped. :-) Alan Stern
[PATCH v4 2/2] i2c: busses: convert to devm_platform_request_irq()
Use devm_platform_request_irq() to simplify code, and it contains
platform_get_irq() and devm_request_irq().
Cc: Michal Simek
Cc: Wolfram Sang
Signed-off-by: Dejin Zheng
Acked-by: Linus Walleij
Acked-by: Michal Simek
---
v3 -> v4:
- add Michal's Acked-by tag in the second patch. and Thanks
for Michal's help.
v2 -> v3:
- add Linus's Acked-by tag and Thanks linus's review.
v1 -> v2:
- The patch content has not changed. just resend it by this discussion:
https://patchwork.ozlabs.org/project/linux-i2c/patch/20200520144821.8069-1-zhengdej...@gmail.com/
drivers/i2c/busses/i2c-bcm-kona.c | 16 +++-
drivers/i2c/busses/i2c-cadence.c | 10 +++---
drivers/i2c/busses/i2c-digicolor.c | 10 +++---
drivers/i2c/busses/i2c-emev2.c | 5 ++---
drivers/i2c/busses/i2c-jz4780.c| 5 ++---
drivers/i2c/busses/i2c-meson.c | 13 -
drivers/i2c/busses/i2c-mxs.c | 9 +++--
drivers/i2c/busses/i2c-pnx.c | 9 ++---
drivers/i2c/busses/i2c-rcar.c | 9 +++--
drivers/i2c/busses/i2c-rk3x.c | 14 +++---
drivers/i2c/busses/i2c-sirf.c | 10 ++
drivers/i2c/busses/i2c-stu300.c| 4 ++--
drivers/i2c/busses/i2c-synquacer.c | 12 +++-
13 files changed, 35 insertions(+), 91 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-kona.c
b/drivers/i2c/busses/i2c-bcm-kona.c
index ed5e1275ae46..f45acb47552a 100644
--- a/drivers/i2c/busses/i2c-bcm-kona.c
+++ b/drivers/i2c/busses/i2c-bcm-kona.c
@@ -818,20 +818,10 @@ static int bcm_kona_i2c_probe(struct platform_device
*pdev)
ISR_NOACK_MASK,
dev->base + ISR_OFFSET);
- /* Get the interrupt number */
- dev->irq = platform_get_irq(pdev, 0);
- if (dev->irq < 0) {
- rc = dev->irq;
- goto probe_disable_clk;
- }
-
- /* register the ISR handler */
- rc = devm_request_irq(&pdev->dev, dev->irq, bcm_kona_i2c_isr,
- IRQF_SHARED, pdev->name, dev);
- if (rc) {
- dev_err(dev->device, "failed to request irq %i\n", dev->irq);
+ rc = devm_platform_request_irq(pdev, 0, &dev->irq, bcm_kona_i2c_isr,
+ IRQF_SHARED, pdev->name, dev);
+ if (rc)
goto probe_disable_clk;
- }
/* Enable the controller but leave it idle */
bcm_kona_i2c_send_cmd_to_ctrl(dev, BCM_CMD_NOACTION);
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 4b72398af505..9ffae4d231dc 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -1204,8 +1204,6 @@ static int cdns_i2c_probe(struct platform_device *pdev)
if (IS_ERR(id->membase))
return PTR_ERR(id->membase);
- id->irq = platform_get_irq(pdev, 0);
-
id->adap.owner = THIS_MODULE;
id->adap.dev.of_node = pdev->dev.of_node;
id->adap.algo = &cdns_i2c_algo;
@@ -1256,12 +1254,10 @@ static int cdns_i2c_probe(struct platform_device *pdev)
goto err_clk_dis;
}
- ret = devm_request_irq(&pdev->dev, id->irq, cdns_i2c_isr, 0,
-DRIVER_NAME, id);
- if (ret) {
- dev_err(&pdev->dev, "cannot get irq %d\n", id->irq);
+ ret = devm_platform_request_irq(pdev, 0, &id->irq, cdns_i2c_isr, 0,
+ DRIVER_NAME, id);
+ if (ret)
goto err_clk_dis;
- }
/*
* Cadence I2C controller has a bug wherein it generates
diff --git a/drivers/i2c/busses/i2c-digicolor.c
b/drivers/i2c/busses/i2c-digicolor.c
index 332f00437479..9ea965f41396 100644
--- a/drivers/i2c/busses/i2c-digicolor.c
+++ b/drivers/i2c/busses/i2c-digicolor.c
@@ -290,7 +290,7 @@ static int dc_i2c_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct dc_i2c *i2c;
- int ret = 0, irq;
+ int ret = 0;
i2c = devm_kzalloc(&pdev->dev, sizeof(struct dc_i2c), GFP_KERNEL);
if (!i2c)
@@ -314,12 +314,8 @@ static int dc_i2c_probe(struct platform_device *pdev)
if (IS_ERR(i2c->regs))
return PTR_ERR(i2c->regs);
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- return irq;
-
- ret = devm_request_irq(&pdev->dev, irq, dc_i2c_irq, 0,
- dev_name(&pdev->dev), i2c);
+ ret = devm_platform_request_irq(pdev, 0, NULL, dc_i2c_irq, 0,
+ dev_name(&pdev->dev), i2c);
if (ret < 0)
return ret;
diff --git a/drivers/i2c/busses/i2c-emev2.c b/drivers/i2c/busses/i2c-emev2.c
index a08554c1a570..1a605d7b56dc 100644
--- a/drivers/i2c/busses/i2c-emev2.c
+++ b/drivers/i2c/busses/i2c-emev2.c
@@ -395,9 +395,8 @@ static int em_i2c_probe(struct platform_device *pdev)
em_i2c_reset(&priv->adap);
- p
[ANNOUNCE] trace-cmd 2.9
I'm happy to announce that after over a year, we finally are able to release trace-cmd version 2.9! Features and user visible updates since 2.8: - git hash is now visible in trace-cmd --version output - Build: python-dir can be specified on the command line for python location. - Build: NO_UDIS86 on make command line to disable udisc86. - Build: All headers needed by kernelshark installed. - Added --proc-map to trace-cmd record. Records the /proc//maps of the traced file. Used for seeing where page_faults happen (trace-cruncher can use it) - Add --user to trace-cmd record, to allow to suid to another user to execute the command also on the command line. Useful as trace-cmd needs to be run as root to start the tracing, but when root should not be used as the application being traced. - Build: Install path of plugins have changed: ~/.traceevent/plugins/ --> ~/.local/lib/traceevent/plugins/ (install_prefix)/lib/trace-cmd/plugins --> (install_prefix)/lib/traceevent/plugins - trace-cmd reset will now clear the tracing_cpumask file. - ** NEW ** trace-cmd clear Clear the trace file. - ** NEW ** trace-cmd agent Can be run on a guest, which will listen on a vsock for commands. trace-cmd report -A Gust Will connect to the guest agent and have the agent run tracing commands sending the data back to the host. See man pages for more details. (note, the synchronization of time stamps is not yet available, that will be coming in the next release of trace-cmd). - ** NEW ** trace-cmd setup-guest Sets up fifos for a guest and host communications instead of vsocks. - Add --cmdline_size option to trace-cmd record. Changes the number of process names that are saved in the cache while tracing. - ** NEW ** trace-cmd dump Dumps out raw data of the trace.dat file. - Build: New: make test Builds and runs various unit tests. - More information from trace-cmd stat. - trace-cmd reset will now clear the error log. - Add option '-s' to trace-cmd list. This will list the available systems (not events). - Recording will now stop if -P is on the command line of trace-cmd record and those processes all exit. - trace-cmd start can now run commands. This is useful when -F and -c are specified on the command line. New "--fork" command line to have trace-cmd not wait for the command to finish before exiting. - ** New ** trace-cmd set command. Used to set or unset options without messing with other ftrace options. Plus many fixes and infrastructure improvements. Changes are also made to set up having libtraceevent, libtracefs and kernelshark be moved into their own git repositories. We plan on working more more aggressively on the libraries and the tool set, such that 3.0 wont take a year to be released. For more information please visit: https://trace-cmd.org If you would like to contribute, check out the above web site for where we do our development, and feel free to contact us on how to get involved. Enjoy, -- Steve
Re: [PATCH 4.14 105/136] usb/ehci-platform: Set PM runtime as active on resume
Hi Eugeniu
On 07/09/20 09:00, Eugeniu Rosca wrote:
> Hello everyone,
>
> Cc: linux-renesas-soc
> Cc: linux-pm
[...]
> After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform:
> Set PM runtime as active on resume") into downstream v4.14.x, we started
> to consistently experience below panic [1] on every second s2ram of
> R-Car H3 Salvator-X Renesas reference board.
>
> After some investigations, we concluded the following:
> - the issue does not exist in vanilla v5.8-rc4+
> - [bisecting shows that] the panic on v4.14.186 is caused by the lack
>of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device
>link support"). Getting evidence for that is easy. Reverting
>987351e1ea7772 in vanilla leads to a similar backtrace [2].
>
> Questions:
> - Backporting 987351e1ea7772 ("phy: core: Add consumer device
>link support") to v4.14.187 looks challenging enough, so probably not
>worth it. Anybody to contradict this?
> - Assuming no plans to backport the missing mainline commit to v4.14.x,
>should the following three v4.14.186 commits be reverted on v4.14.x?
>* baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
>* 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
>* 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")
Thanks for investigating this.
Alan, Greg, do you have any ideas?
Let me know if there's anything I can help with.
Thanks
--
Qais Yousef
Re: [PATCH v5 02/17] perf ftrace: add option '-F/--funcs' to list available functions
Em Fri, Jul 17, 2020 at 11:05:04AM -0400, Steven Rostedt escreveu:
> On Sat, 11 Jul 2020 20:40:20 +0800
> Changbin Du wrote:
>
> > This adds an option '-F/--funcs' to list all available functions to trace,
> > which is read from tracing file 'available_filter_functions'.
> >
> > $ sudo ./perf ftrace -F | head
> > trace_initcall_finish_cb
> > initcall_blacklisted
> > do_one_initcall
> > do_one_initcall
> > trace_initcall_start_cb
> > run_init_process
> > try_to_run_init_process
> > match_dev_by_label
> > match_dev_by_uuid
> > rootfs_init_fs_context
> >
> > Signed-off-by: Changbin Du
> >
> > ---
> > v2: option name '-l/--list-functions' -> '-F/--funcs'
> > ---
> > tools/perf/Documentation/perf-ftrace.txt | 4 +++
> > tools/perf/builtin-ftrace.c | 43
> > 2 files changed, 47 insertions(+)
> >
> > diff --git a/tools/perf/Documentation/perf-ftrace.txt
> > b/tools/perf/Documentation/perf-ftrace.txt
> > index 952e46669168..d79560dea19f 100644
> > --- a/tools/perf/Documentation/perf-ftrace.txt
> > +++ b/tools/perf/Documentation/perf-ftrace.txt
> > @@ -30,6 +30,10 @@ OPTIONS
> > --verbose=::
> > Verbosity level.
> >
> > +-F::
> > +--funcs::
> > +List all available functions to trace.
> > +
> > -p::
> > --pid=::
> > Trace on existing process id (comma separated list).
> > diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> > index 5f53da87040d..244cc8e6bd60 100644
> > --- a/tools/perf/builtin-ftrace.c
> > +++ b/tools/perf/builtin-ftrace.c
> > @@ -32,6 +32,7 @@ struct perf_ftrace {
> > struct evlist *evlist;
> > struct target target;
> > const char *tracer;
> > + boollist_avail_functions;
> > struct list_headfilters;
> > struct list_headnotrace;
> > struct list_headgraph_funcs;
> > @@ -127,6 +128,43 @@ static int append_tracing_file(const char *name, const
> > char *val)
> > return __write_tracing_file(name, val, true);
> > }
> > +static int read_tracing_file_to_stdout(const char *name)
> > +{
> All this is looking like its duplicating code that we are working on
> for libtracefs.
> Would you like to start contributing to that, and when we get the
> libtracefs.so packed in distributions, we can easily create the
> perf ftrace without having to rewrite the wheel 10 times?
Or we can use as soon as it is available, not preventing 'perf ftrace'
from having to wait for libtracefs.so?
Duplication is normal at some point, Changbin is moving 'perf ftrace'
forward, and has been doing this thru several patch series revisions, if
we continue putting new requirements, it gets tiresome at some point :-\
- Arnaldo
> -- Steve
>
>
> > + char buf[4096];
> > + char *file;
> > + int fd;
> > + int ret = -1;
> > +
> > + file = get_tracing_file(name);
> > + if (!file) {
> > + pr_debug("cannot get tracing file: %s\n", name);
> > + return -1;
> > + }
> > +
> > + fd = open(file, O_RDONLY);
> > + if (fd < 0) {
> > + pr_debug("cannot open tracing file: %s: %s\n",
> > +name, str_error_r(errno, buf, sizeof(buf)));
> > + goto out;
> > + }
> > +
> > + /* read contents to stdout */
> > + while (true) {
> > + int n = read(fd, buf, sizeof(buf));
> > + if (n <= 0)
> > + goto out_close;
> > + if (fwrite(buf, n, 1, stdout) != 1)
> > + goto out_close;
> > + }
> > + ret = 0;
> > +
> > +out_close:
> > + close(fd);
> > +out:
> > + put_tracing_file(file);
> > + return ret;
> > +}
> > +
> > static int reset_tracing_cpu(void);
> > static void reset_tracing_filters(void);
> >
> > @@ -301,6 +339,9 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int
> > argc, const char **argv)
> > signal(SIGCHLD, sig_handler);
> > signal(SIGPIPE, sig_handler);
> >
> > + if (ftrace->list_avail_functions)
> > + return
> > read_tracing_file_to_stdout("available_filter_functions");
> > +
> > if (reset_tracing_files(ftrace) < 0) {
> > pr_err("failed to reset ftrace\n");
> > goto out;
> > @@ -470,6 +511,8 @@ int cmd_ftrace(int argc, const char **argv)
> > const struct option ftrace_options[] = {
> > OPT_STRING('t', "tracer", &ftrace.tracer, "tracer",
> >"tracer to use: function or function_graph (This option is
> > deprecated)"),
> > + OPT_BOOLEAN('F', "funcs", &ftrace.list_avail_functions,
> > + "Show available functions to filter"),
> > OPT_STRING('p', "pid", &ftrace.target.pid, "pid",
> >"trace on existing process id"),
> > OPT_INCR('v', "verbose", &verbose,
>
--
- Arnaldo
Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
- On Jul 17, 2020, at 12:11 PM, Alan Stern st...@rowland.harvard.edu wrote: >> > I agree with Nick: A memory barrier is needed somewhere between the >> > assignment at 6 and the return to user mode at 8. Otherwise you end up >> > with the Store Buffer pattern having a memory barrier on only one side, >> > and it is well known that this arrangement does not guarantee any >> > ordering. >> >> Yes, I see this now. I'm still trying to wrap my head around why the memory >> barrier at the end of membarrier() needs to be paired with a scheduler >> barrier though. > > The memory barrier at the end of membarrier() on CPU0 is necessary in > order to enforce the guarantee that any writes occurring on CPU1 before > the membarrier() is executed will be visible to any code executing on > CPU0 after the membarrier(). Ignoring the kthread issue, we can have: > > CPU0CPU1 > x = 1 > barrier() > y = 1 > r2 = y > membarrier(): > a: smp_mb() > b: send IPI IPI-induced mb > c: smp_mb() > r1 = x > > The writes to x and y are unordered by the hardware, so it's possible to > have r2 = 1 even though the write to x doesn't execute until b. If the > memory barrier at c is omitted then "r1 = x" can be reordered before b > (although not before a), so we get r1 = 0. This violates the guarantee > that membarrier() is supposed to provide. > > The timing of the memory barrier at c has to ensure that it executes > after the IPI-induced memory barrier on CPU1. If it happened before > then we could still end up with r1 = 0. That's why the pairing matters. > > I hope this helps your head get properly wrapped. :-) It does help a bit! ;-) This explains this part of the comment near the smp_mb at the end of membarrier: * Memory barrier on the caller thread _after_ we finished * waiting for the last IPI. [...] However, it does not explain why it needs to be paired with a barrier in the scheduler, clearly for the case where the IPI is skipped. I wonder whether this part of the comment is factually correct: * [...] Matches memory barriers around rq->curr modification in scheduler. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH v5] x86/speculation/l1tf: Add KConfig for setting the L1D cache flush mode
Doug, Doug Anderson writes: > On Thu, Jul 9, 2020 at 3:51 AM Thomas Gleixner wrote: >> TBH, I don't see why this is a good idea. >> >> 1) I'm not following your argumentation that the command line option is >> a poor Kconfig replacement. The L1TF mode is a boot time (module >> load time) decision and the command line parameter is there to >> override the carefully chosen and sensible default behaviour. > > When you say that the default behavior is carefully chosen and > sensible, are you saying that (in your opinion) there would never be a > good reason for someone distributing a kernel to others to change the > default? Certainly I agree that having the kernel command line > parameter is nice to allow someone to override whatever the person > building the kernel chose, but IMO it's not a good way to change the > default built-in to the kernel. The problem is that you have to be careful about what you stick into Kconfig. It's L1TF on x86 today and tomorrow it's MDS and whatever and then you do the same thing on the other architectures as well. And we still need the command line options so that generic builds can be customized at boot time. > The current plan (as I understand it) is that we'd like to ship > Chromebook kernels with this option changed from the default that's > there now. In your opinion, is that a sane thing to do? If it's sane for you folks, then feel free to do so. Distros & al patch the kernel do death anyway, but that does not mean that mainline has to have everything these people chose to do. >> 2) You can add the desired mode to the compiled in (partial) kernel >> command line today. > > This might be easier on x86 than it is on ARM. ARM (and ARM64) > kernels only have two modes: kernel provides cmdline and bootloader > provides cmdline. There are out-of-mainline ANDROID patches to > address this but nothing in mainline. > > The patch we're discussing now is x86-only so it's not such a huge > deal, but the fact that combining the kernel and bootloader > commandline never landed in mainline for arm/arm64 means that this > isn't a super common/expected thing to do. Did you try to get that merged for arm/arm64? >> 3) Boot loaders are well capable of handling large kernel command lines >> and the extra time spend for reading the parameter does not matter >> at all. > > Long command lines can still be a bit of a chore for humans to deal > with. Many times I've needed to look at "/proc/cmdline" and make > sense of it. The longer the command line is and the more cruft > stuffed into it the more of a chore it is. Yes, this is just one > thing to put in the command line, but if 10 different drivers all have > their "one thing" to put there it gets really long. If 100 different > drivers all want their one config option there it gets really really > long. This will not go away when you want to support a gazillion of systems which need tweaks left and right due to creative hardware/BIOS with a generic kernel. And come on, parsing a long command line is not rocket science and it's not something you do every two minutes. > IMO the command line should be a last resort place to put > things and should just contain: > > 1. Legacy things that _have_ to be in the command line because they've > always been there. > > 2. Things that the bootloader/BIOS needs to communicate to the kernel > and has no better way to communicate. > > 3. Cases where the person running the kernel needs to override a > default set by the person compiling the kernel. Which is the case for a lot of things and it's widely used exactly for that reason. >> 4) It's just a tiny part of the whole speculation maze. If we go there >> for L1TF then we open the flood gates for a gazillion other config >> options. > > It seems like the only options that we'd need CONFIG option for would > be the ones where it would be sane to change the default compiled into > the kernel. Hopefully that's not too many things? That's what _you_ need. But accepting this we set a precedence and how do I argue that L1TF makes sense, but other things not? This stuff is horrible enough already, no need to add more ifdefs and options and whatever to it. > Obviously, like many design choices, the above is all subjective. > It's really your call and if these arguments don't convince you it > sounds like the way forward is just to use "CONFIG_CMDLINE" and take > advantage of the fact that on x86 this will get merged with the > bootloader's command line. I rather see the support for command line merging extended to arm/arm64 because that's of general usefulness beyond the problem at hand. Thanks, tglx
Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt wrote:
> On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
> >
> > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt wrote:
> >
> > > On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park wrote:
> > > >
> > > > From: SeongJae Park
> > > >
> > > > This commit introduces a reference implementation of the address space
> > > > specific low level primitives for the virtual address space, so that
> > > > users of DAMON can easily monitor the data accesses on virtual address
> > > > spaces of specific processes by simply configuring the implementation to
> > > > be used by DAMON.
> > > >
> > > > The low level primitives for the fundamental access monitoring are
> > > > defined in two parts:
> > > > 1. Identification of the monitoring target address range for the address
> > > > space.
> > > > 2. Access check of specific address range in the target space.
> > > >
> > > > The reference implementation for the virtual address space provided by
> > > > this commit is designed as below.
> > > >
> > > > PTE Accessed-bit Based Access Check
> > > > ---
> > > >
> > > > The implementation uses PTE Accessed-bit for basic access checks. That
> > > > is, it clears the bit for next sampling target page and checks whether
> > > > it set again after one sampling period. To avoid disturbing other
> > > > Accessed bit users such as the reclamation logic, the implementation
> > > > adjusts the ``PG_Idle`` and ``PG_Young`` appropriately, as same to the
> > > > 'Idle Page Tracking'.
> > > >
> > > > VMA-based Target Address Range Construction
> > > > ---
> > > >
> > > > Only small parts in the super-huge virtual address space of the
> > > > processes are mapped to physical memory and accessed. Thus, tracking
> > > > the unmapped address regions is just wasteful. However, because DAMON
> > > > can deal with some level of noise using the adaptive regions adjustment
> > > > mechanism, tracking every mapping is not strictly required but could
> > > > even incur a high overhead in some cases. That said, too huge unmapped
> > > > areas inside the monitoring target should be removed to not take the
> > > > time for the adaptive mechanism.
> > > >
> > > > For the reason, this implementation converts the complex mappings to
> > > > three distinct regions that cover every mapped area of the address
> > > > space. Also, the two gaps between the three regions are the two biggest
> > > > unmapped areas in the given address space. The two biggest unmapped
> > > > areas would be the gap between the heap and the uppermost mmap()-ed
> > > > region, and the gap between the lowermost mmap()-ed region and the stack
> > > > in most of the cases. Because these gaps are exceptionally huge in
> > > > usual address spacees, excluding these will be sufficient to make a
> > > > reasonable trade-off. Below shows this in detail::
> > > >
> > > >
> > > >
> > > >
> > > > (small mmap()-ed regions and munmap()-ed regions)
> > > >
> > > >
> > > >
> > > >
> > > > Signed-off-by: SeongJae Park
> > > > Reviewed-by: Leonard Foerster
> > > [snip]
> > > > +
> > > > +static void damon_mkold(struct mm_struct *mm, unsigned long addr)
> > > > +{
> > > > + pte_t *pte = NULL;
> > > > + pmd_t *pmd = NULL;
> > > > + spinlock_t *ptl;
> > > > +
> > > > + if (follow_pte_pmd(mm, addr, NULL, &pte, &pmd, &ptl))
> > > > + return;
> > > > +
> > > > + if (pte) {
> > > > + if (pte_young(*pte)) {
> > >
> > > Any reason for skipping mmu_notifier_clear_young()? Why exclude VMs as
> > > DAMON's target applications?
> >
> > Obviously my mistake, thank you for pointing this! I will add the function
> > call in the next spin.
> >
>
> Similarly mmu_notifier_test_young() for the damon_young().
Yes, indeed. Thanks for pointing this, either :)
> BTW I think we can combine ctx->prepare_access_checks() and
> ctx->check_accesses() into one i.e. get the young state for the previous
> cycle and mkold for the next cycle in a single step.
Yes, we could. But, I'm unsure what is the advantage of doing that. First of
all, if the combined implementation is required, peopld could simply implement
the two logics in the combined way in one of the callbacks and leave the other
one blank. Also, I'm worrying if combining those could make the code a little
bit hard to read. IMHO, I think separating those makes the 'kdamond_fn()' code
little bit easier to read. Actually, I started from the combined approach but
separated the two logics since v7 after Jonathan's comment[1].
[1] https://lore.kernel.org/linux-mm/20200310085721.0...@huawei.com/
>
> I am wondering if there is any advantage to having "Page Idle
> Tracking" beside DAMON. I think we can make them mutually exclusive.
> Once we have established that I think DAMON can steal the two page
> flag bits from it and can make use of t
Re: [PATCH v5 02/17] perf ftrace: add option '-F/--funcs' to list available functions
On Fri, 17 Jul 2020 13:21:16 -0300 Arnaldo Carvalho de Melo wrote: > > > Would you like to start contributing to that, and when we get the > > libtracefs.so packed in distributions, we can easily create the > > perf ftrace without having to rewrite the wheel 10 times? > > Or we can use as soon as it is available, not preventing 'perf ftrace' > from having to wait for libtracefs.so? > > Duplication is normal at some point, Changbin is moving 'perf ftrace' > forward, and has been doing this thru several patch series revisions, if > we continue putting new requirements, it gets tiresome at some point :-\ We're finally at the point to move libtracefs.so and libtraceevent.so into their own repository. My fear is that the two will become incompatible, and forked forever. -- Steve
Re: [PATCH v5 02/15] iommu: Report domain nesting info
Hi Yi,
On 7/12/20 1:20 PM, Liu Yi L wrote:
> IOMMUs that support nesting translation needs report the capability info
s/needs/need to report
> to userspace, e.g. the format of first level/stage paging structures.
It gives information about requirements the userspace needs to implement
plus other features characterizing the physical implementation.
>
> This patch reports nesting info by DOMAIN_ATTR_NESTING. Caller can get
> nesting info after setting DOMAIN_ATTR_NESTING.
I guess you meant after selecting VFIO_TYPE1_NESTING_IOMMU?
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Liu Yi L
> Signed-off-by: Jacob Pan
> ---
> v4 -> v5:
> *) address comments from Eric Auger.
>
> v3 -> v4:
> *) split the SMMU driver changes to be a separate patch
> *) move the @addr_width and @pasid_bits from vendor specific
>part to generic part.
> *) tweak the description for the @features field of struct
>iommu_nesting_info.
> *) add description on the @data[] field of struct iommu_nesting_info
>
> v2 -> v3:
> *) remvoe cap/ecap_mask in iommu_nesting_info.
> *) reuse DOMAIN_ATTR_NESTING to get nesting info.
> *) return an empty iommu_nesting_info for SMMU drivers per Jean'
>suggestion.
> ---
> include/uapi/linux/iommu.h | 77
> ++
> 1 file changed, 77 insertions(+)
>
> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
> index 1afc661..d2a47c4 100644
> --- a/include/uapi/linux/iommu.h
> +++ b/include/uapi/linux/iommu.h
> @@ -332,4 +332,81 @@ struct iommu_gpasid_bind_data {
> } vendor;
> };
>
> +/*
> + * struct iommu_nesting_info - Information for nesting-capable IOMMU.
> + * user space should check it before using
> + * nesting capability.
> + *
> + * @size:size of the whole structure
> + * @format: PASID table entry format, the same definition as struct
> + * iommu_gpasid_bind_data @format.
> + * @features:supported nesting features.
> + * @flags: currently reserved for future extension.
> + * @addr_width: The output addr width of first level/stage translation
> + * @pasid_bits: Maximum supported PASID bits, 0 represents no PASID
> + * support.
> + * @data:vendor specific cap info. data[] structure type can be deduced
> + * from @format field.
> + *
> + * +===+==+
> + * | feature | Notes |
> + * +===+==+
> + * | SYSWIDE_PASID | PASIDs are managed in system-wide, instead of per |
s/in system-wide/system-wide ?
> + * | | device. When a device is assigned to userspace or |
> + * | | VM, proper uAPI (userspace driver framework uAPI, |
> + * | | e.g. VFIO) must be used to allocate/free PASIDs for |
> + * | | the assigned device.
Isn't it possible to be more explicit, something like:
|
System-wide PASID management is mandated by the physical IOMMU. All
PASIDs allocation must be mediated through the TBD API.
> + * +---+--+
> + * | BIND_PGTBL| The owner of the first level/stage page table must |
> + * | | explicitly bind the page table to associated PASID |
> + * | | (either the one specified in bind request or the|
> + * | | default PASID of iommu domain), through userspace |
> + * | | driver framework uAPI (e.g. VFIO_IOMMU_NESTING_OP). |
As per your answer in https://lkml.org/lkml/2020/7/6/383, I now
understand ARM would not expose that BIND_PGTBL nesting feature, I still
think the above wording is a bit confusing. Maybe you may explicitly
talk about the PASID *entry* that needs to be passed from guest to host.
On ARM we directly pass the PASID table but when reading the above
description I fail to determine if this does not fit that description.
> + * +---+--+
> + * | CACHE_INVLD | The owner of the first level/stage page table must |
> + * | | explicitly invalidate the IOMMU cache through uAPI |
> + * | | provided by userspace driver framework (e.g. VFIO) |
> + * | | according to vendor-specific requirement when |
> + * | | changing the page table.|
> + * +---+--+
instead of using the "uAPI provided by userspace driver framework (e.g.
VFIO)", can't we use the so-called IOMMU UAPI terminology which now has
a userspace documentation?
> + *
> + * @data[] types defined for @format:
> + * +=
Re: [PATCH v7 2/7] lib: add zstd support to decompress
> On Jul 14, 2020, at 5:42 PM, Arvind Sankar wrote: > > On Wed, Jul 08, 2020 at 11:50:19AM -0700, Nick Terrell wrote: >> From: Nick Terrell >> >> * Add unzstd() and the zstd decompress interface. >> * Add zstd support to decompress_method(). >> >> The decompress_method() and unzstd() functions are used to decompress >> the initramfs and the initrd. The __decompress() function is used in >> the preboot environment to decompress a zstd compressed kernel. >> >> The zstd decompression function allows the input and output buffers to >> overlap because that is used by x86 kernel decompression. >> >> Reviewed-by: Kees Cook >> Tested-by: Sedat Dilek >> Signed-off-by: Nick Terrell >> + * >> + * __DISABLE_EXPORTS stops zstd and xxhash from declaring themselves >> + * as modules by disabling the EXPORT_SYMBOL macro. >> + */ > > Hi Nick, this doesn't actually work, because misc.c includes export.h > via > "misc.h" -> -> > and EXPORT_SYMBOL is already defined before __DISABLE_EXPORTS is defined > here. > > Adding -D__EXPORT_SYMBOLS to KBUILD_CFLAGS in > arch/x86/boot/compressed/Makefile > fixes that, and then you don't have to define it here. > > Also, __DISABLE_EXPORTS does not currently inhibit MODULE_INFO, so a > .modinfo section gets emitted into misc.o. I *think* this is harmless > and it will get discarded when building compressed/vmlinux, but thought > I'd point it out. Thanks for pointing that out! I’m surprised that the zstd compressed kernels built and ran successfully, I vaguely remember that failing in the past. I will put up a fix shortly. -Nick
Re: [PATCH v1] PCI: dwc: fix a warning about variable 'res' is uninitialized
On Fri, Jul 17, 2020 at 09:30:07PM +0800, Dejin Zheng wrote:
> The kernel test robot reported a compile warning,
>
> drivers/pci/controller/dwc/pci-keystone.c:1236:18: warning: variable 'res'
> is uninitialized when used here [-Wuninitialized]
>
> The commit c59a7d771134b5 ("PCI: dwc: Convert to
> devm_platform_ioremap_resource_byname()") did a wrong conversion for
> keystone driver. the commit use devm_platform_ioremap_resource_byname()
> to replace platform_get_resource_byname() and devm_ioremap_resource().
> but the subsequent code needs to use the variable 'res', which is got by
> platform_get_resource_byname() for resource "app". so revert it.
>
> Fixes: c59a7d771134b5 ("PCI: dwc: Convert to
> devm_platform_ioremap_resource_byname()")
> Reported-by: kernel test robot
> Signed-off-by: Dejin Zheng
> ---
> drivers/pci/controller/dwc/pci-keystone.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Squashed in the commit it is fixing, thanks.
Lorenzo
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c
> b/drivers/pci/controller/dwc/pci-keystone.c
> index 5ffc3b40c4f6..00279002102e 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> @@ -1228,8 +1228,8 @@ static int __init ks_pcie_probe(struct platform_device
> *pdev)
> if (!pci)
> return -ENOMEM;
>
> - ks_pcie->va_app_base =
> - devm_platform_ioremap_resource_byname(pdev, "app");
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
> + ks_pcie->va_app_base = devm_ioremap_resource(dev, res);
> if (IS_ERR(ks_pcie->va_app_base))
> return PTR_ERR(ks_pcie->va_app_base);
>
> --
> 2.25.0
>
Re: [RFC PATCH v3 00/18] Support for Tegra video capture from external sensor
On 7/17/20 3:54 AM, Hans Verkuil wrote: Hi Sowjanya, On 15/07/2020 06:20, Sowjanya Komatineni wrote: This series adds support for video capture from external camera sensor to Tegra video driver. Jetson TX1 has camera expansion connector and supports custom camera module designed as per TX1 design specification. This series also enables camera capture support for Jetson Nano which has Raspberry PI camera header. This series is tested with IMX219 camera sensor. This series include, VI I2C related fixes - Camera sensor programming happens through VI I2C which is on host1x bus. - These patches includes device tree and I2C driver fixes for VI I2C. Tegra video driver updates - TPG Vs Non-TPG based on Kconfig - Support for external sensor video capture based on device graph from DT. - Support for selection ioctl operations - Tegra MIPI CSI pads calibration - CSI T-CLK and T-HS settle time computation based on clock rates. Host1x driver updates - Adds API to allow creating mipi device for specific device node. - Splits MIPI pads calibrate start and waiting for calibration to be done. Device tree updates - Adds camera connector 2V8, 1V8, 1V2 regulator supplies to Jetson TX1 DT. - Enabled VI and CSI support in Jetson Nano DT. I'm doing a bit of stress testing with: while true; do v4l2-ctl --stream-mmap --stream-count=1; done and I see that the imx274 has often streaming failures: [ 172.025144] IMX274 8-001a: s_stream failed [ 179.025192] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 3132 = 870 (2 bytes) [ 179.033575] IMX274 8-001a: s_stream failed [ 226.525378] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 3130 = 878 (2 bytes) [ 226.533761] IMX274 8-001a: s_stream failed [ 227.029325] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f6 = 107 (2 bytes) [ 227.037758] IMX274 8-001a: s_stream failed [ 247.025218] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f6 = 107 (2 bytes) [ 247.033658] IMX274 8-001a: s_stream failed [ 293.025517] IMX274 8-001a: s_stream failed [ 309.024727] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30e0 = 0 (2 bytes) [ 309.032969] IMX274 8-001a: s_stream failed [ 309.529506] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f8 = 11d2 (3 bytes) [ 309.538103] IMX274 8-001a: imx274_set_frame_length error = -121 [ 309.544102] IMX274 8-001a: imx274_set_frame_interval error = -121 [ 309.550243] IMX274 8-001a: s_stream failed [ 314.025561] IMX274 8-001a: s_stream failed [ 329.025586] IMX274 8-001a: s_stream failed [ 340.529567] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 303a = f0c (2 bytes) [ 340.538009] IMX274 8-001a: s_stream failed [ 347.525627] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f6 = 107 (2 bytes) [ 347.534008] IMX274 8-001a: s_stream failed [ 365.033640] IMX274 8-001a: s_stream failed [ 437.525788] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 3038 = c (2 bytes) [ 437.533997] IMX274 8-001a: s_stream failed [ 456.029780] IMX274 8-001a: s_stream failed [ 472.025862] IMX274 8-001a: s_stream failed [ 498.025861] IMX274 8-001a: s_stream failed [ 500.025905] IMX274 8-001a: s_stream failed where v4l2-ctl returns: VIDIOC_STREAMON returned -1 (Remote I/O error) I don't see this with the imx219. I also see this occasionally: [Fri Jul 17 12:51:42 2020] video4linux video1: failed to run capture start kthread: -4 Something is not stable here. Regards, Hans Hi Hans, Running the same single frame continuous loop for more than 2 hours now and I don't see any failure. Above failure shows i2c bulk writes to IMX274 failure due to which s_stream also failed. Not sure if its due to i2c mux in the path to sensor on your module causing some issue when there is more i2c write traffic as we are doing single stream in continuous loop. Also IMX219 does not show on your side so something specific to IMX274 setup probably. Regarding kthread_run failure where kthread_run() returned -EINTR during capture start thread, I always see this happen at the point of stopping the continuous single stream while loop by pressing ctrl+c after few loops of execution. while true; do v4l2-ctl --stream-mmap --stream-count=1; done when we stop loop with ctrl+c, v4l2-ctl terminates but loop does not terminate immediately and probably SIGKILLed is seen prior to complete. Using below can help to terminate loop as well when we stop ctrl-c and with this I don't see any repro of EINTR error from kthread_run when run in infinite loop. while true; do ./v4l2-ctl --stream-mmap --stream-count=1 || break; done Delta between patch versions: [v3]: Includes v2 feedback - Uses separate helper function for retrieving remote csi subdevice and source subdevice. - Added check for presence of subdevice ops set/get_selection - dropped vb2_queue_release from driver and using
Re: [PATCH v2] driver core: Fix sleeping in invalid context during device link deletion
On Fri, Jul 17, 2020 at 12:13:04AM +0200, Marek Szyprowski wrote:
> Hi Saravana,
>
> On 16.07.2020 23:45, Saravana Kannan wrote:
> > Marek and Guenter reported that commit 287905e68dd2 ("driver core:
> > Expose device link details in sysfs") caused sleeping/scheduling while
> > atomic warnings.
> >
> > BUG: sleeping function called from invalid context at
> > kernel/locking/mutex.c:935
> > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12, name: kworker/0:1
> > 2 locks held by kworker/0:1/12:
> >#0: ee8074a8 ((wq_completion)rcu_gp){+.+.}-{0:0}, at:
> > process_one_work+0x174/0x7dc
> >#1: ee921f20 ((work_completion)(&sdp->work)){+.+.}-{0:0}, at:
> > process_one_work+0x174/0x7dc
> > Preemption disabled at:
> > [] srcu_invoke_callbacks+0xc0/0x154
> > - 8< - SNIP
> > [] (device_del) from [] (device_unregister+0x24/0x64)
> > [] (device_unregister) from []
> > (srcu_invoke_callbacks+0xcc/0x154)
> > [] (srcu_invoke_callbacks) from []
> > (process_one_work+0x234/0x7dc)
> > [] (process_one_work) from [] (worker_thread+0x44/0x51c)
> > [] (worker_thread) from [] (kthread+0x158/0x1a0)
> > [] (kthread) from [] (ret_from_fork+0x14/0x20)
> > Exception stack(0xee921fb0 to 0xee921ff8)
> >
> > This was caused by the device link device being released in the context
> > of srcu_invoke_callbacks(). There is no need to wait till the RCU
> > callback to release the device link device. So release the device
> > earlier and move the call_srcu() into the device release code. That way,
> > the memory will get freed only after the device is released AND the RCU
> > callback is called.
> >
> > Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
> > Reported-by: Marek Szyprowski
> > Reported-by: Guenter Roeck
> > Signed-off-by: Saravana Kannan
> > ---
> >
> > v1->v2:
> > - Better fix
> > - Changed subject
> > - v1 is this patch
> > https://lore.kernel.org/lkml/20200716050846.2047110-1-sarava...@google.com/
> >
> > Marek and Guenter,
> >
> > I reproduced the original issue and tested this fix. Seems to work for
> > me. Can you confirm?
>
> Confirmed, this one fixes the issue! :)
>
Same here.
Tested-by: Guenter Roeck
Guenter
> Tested-by: Marek Szyprowski
>
> > Thanks,
> > Saravana
> >
> > drivers/base/core.c | 45 +++--
> > 1 file changed, 27 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index 5373ddd029f6..ec16b97d45ed 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -306,10 +306,34 @@ static struct attribute *devlink_attrs[] = {
> > };
> > ATTRIBUTE_GROUPS(devlink);
> >
> > +static void device_link_free(struct device_link *link)
> > +{
> > + while (refcount_dec_not_one(&link->rpm_active))
> > + pm_runtime_put(link->supplier);
> > +
> > + put_device(link->consumer);
> > + put_device(link->supplier);
> > + kfree(link);
> > +}
> > +
> > +#ifdef CONFIG_SRCU
> > +static void __device_link_free_srcu(struct rcu_head *rhead)
> > +{
> > + device_link_free(container_of(rhead, struct device_link, rcu_head));
> > +}
> > +
> > static void devlink_dev_release(struct device *dev)
> > {
> > - kfree(to_devlink(dev));
> > + struct device_link *link = to_devlink(dev);
> > +
> > + call_srcu(&device_links_srcu, &link->rcu_head, __device_link_free_srcu);
> > }
> > +#else
> > +static void devlink_dev_release(struct device *dev)
> > +{
> > + device_link_free(to_devlink(dev));
> > +}
> > +#endif
> >
> > static struct class devlink_class = {
> > .name = "devlink",
> > @@ -730,22 +754,7 @@ static void
> > device_link_add_missing_supplier_links(void)
> > mutex_unlock(&wfs_lock);
> > }
> >
> > -static void device_link_free(struct device_link *link)
> > -{
> > - while (refcount_dec_not_one(&link->rpm_active))
> > - pm_runtime_put(link->supplier);
> > -
> > - put_device(link->consumer);
> > - put_device(link->supplier);
> > - device_unregister(&link->link_dev);
> > -}
> > -
> > #ifdef CONFIG_SRCU
> > -static void __device_link_free_srcu(struct rcu_head *rhead)
> > -{
> > - device_link_free(container_of(rhead, struct device_link, rcu_head));
> > -}
> > -
> > static void __device_link_del(struct kref *kref)
> > {
> > struct device_link *link = container_of(kref, struct device_link, kref);
> > @@ -758,7 +767,7 @@ static void __device_link_del(struct kref *kref)
> >
> > list_del_rcu(&link->s_node);
> > list_del_rcu(&link->c_node);
> > - call_srcu(&device_links_srcu, &link->rcu_head, __device_link_free_srcu);
> > + device_unregister(&link->link_dev);
> > }
> > #else /* !CONFIG_SRCU */
> > static void __device_link_del(struct kref *kref)
> > @@ -773,7 +782,7 @@ static void __device_link_del(struct kref *kref)
> >
> > list_del(&link->s_node);
> > list_del(&link->c_node);
> > - device_link_free(link);
> > + device_unregister(&link->link_dev);
> > }
> > #endif /* !C
Re: [PATCH net 3/3] net: bcmgenet: restore HFB filters on resume
On 7/16/2020 4:38 PM, Doug Berger wrote:
> The Hardware Filter Block RAM may not be preserved when the GENET
> block is reset during a deep sleep, so it is not sufficient to
> only backup and restore the enables.
>
> This commit clears out the HFB block and reprograms the rxnfc
> rules when the system resumes from a suspended state. To support
> this the bcmgenet_hfb_create_rxnfc_filter() function is modified
> to access the register space directly so that it can't fail due
> to memory allocation issues.
>
> Fixes: f50932cca632 ("net: bcmgenet: add WAKE_FILTER support")
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
--
Florian
[PATCH][next] watchdog: scx200_wdt: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7-rc7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva --- drivers/watchdog/scx200_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/scx200_wdt.c b/drivers/watchdog/scx200_wdt.c index c94098acb78f..7b5e18323f3f 100644 --- a/drivers/watchdog/scx200_wdt.c +++ b/drivers/watchdog/scx200_wdt.c @@ -186,7 +186,7 @@ static long scx200_wdt_ioctl(struct file *file, unsigned int cmd, margin = new_margin; scx200_wdt_update_margin(); scx200_wdt_ping(); - /* Fall through */ + fallthrough; case WDIOC_GETTIMEOUT: if (put_user(margin, p)) return -EFAULT; -- 2.27.0
Re: [PATCH v5 02/17] perf ftrace: add option '-F/--funcs' to list available functions
Em Fri, Jul 17, 2020 at 12:27:40PM -0400, Steven Rostedt escreveu: > On Fri, 17 Jul 2020 13:21:16 -0300 Arnaldo Carvalho de Melo > wrote: > > > Would you like to start contributing to that, and when we get the > > > libtracefs.so packed in distributions, we can easily create the > > > perf ftrace without having to rewrite the wheel 10 times? > > Or we can use as soon as it is available, not preventing 'perf ftrace' > > from having to wait for libtracefs.so? > > Duplication is normal at some point, Changbin is moving 'perf ftrace' > > forward, and has been doing this thru several patch series revisions, if > > we continue putting new requirements, it gets tiresome at some point :-\ > We're finally at the point to move libtracefs.so and libtraceevent.so > into their own repository. > My fear is that the two will become incompatible, and forked forever. I don't share this fear, and since libtracefs is not generally available, this will make perf progress to be slowed down, so its better to merge what he has so far, after some review issues that surfaced are solved, and when a better way of achieving that is available, consider using it. - Arnaldo
[PATCH 1/2] thermal: netlink: Improve the initcall ordering
The initcalls like to play joke. In our case, the thermal-netlink
initcall is called after the thermal-core initcall but this one sends
a notification before the former is initialzed. No issue was spotted,
but it could lead to a memory corruption, so instead of relying on the
core_initcall for the thermal-netlink, let's initialize directly from
the thermal-core init routine, so we have full control of the init
ordering.
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Signed-off-by: Daniel Lezcano
---
drivers/thermal/thermal_core.c| 4
drivers/thermal/thermal_netlink.c | 3 +--
drivers/thermal/thermal_netlink.h | 6 ++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 25ef29123f72..c2e7d7aaa354 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1581,6 +1581,10 @@ static int __init thermal_init(void)
{
int result;
+ result = thermal_netlink_init();
+ if (result)
+ goto error;
+
mutex_init(&poweroff_lock);
result = thermal_register_governors();
if (result)
diff --git a/drivers/thermal/thermal_netlink.c
b/drivers/thermal/thermal_netlink.c
index dd0a3b889674..42eace7401da 100644
--- a/drivers/thermal/thermal_netlink.c
+++ b/drivers/thermal/thermal_netlink.c
@@ -641,8 +641,7 @@ static struct genl_family thermal_gnl_family
__ro_after_init = {
.n_mcgrps = ARRAY_SIZE(thermal_genl_mcgrps),
};
-static int __init thermal_netlink_init(void)
+int __init thermal_netlink_init(void)
{
return genl_register_family(&thermal_gnl_family);
}
-core_initcall(thermal_netlink_init);
diff --git a/drivers/thermal/thermal_netlink.h
b/drivers/thermal/thermal_netlink.h
index 0ec28d105da5..828d1dddfa98 100644
--- a/drivers/thermal/thermal_netlink.h
+++ b/drivers/thermal/thermal_netlink.h
@@ -6,6 +6,7 @@
/* Netlink notification function */
#ifdef CONFIG_THERMAL_NETLINK
+int __init thermal_netlink_init(void);
int thermal_notify_tz_create(int tz_id, const char *name);
int thermal_notify_tz_delete(int tz_id);
int thermal_notify_tz_enable(int tz_id);
@@ -23,6 +24,11 @@ int thermal_notify_cdev_delete(int cdev_id);
int thermal_notify_tz_gov_change(int tz_id, const char *name);
int thermal_genl_sampling_temp(int id, int temp);
#else
+static inline int thermal_netlink_init(void)
+{
+ return 0;
+}
+
static inline int thermal_notify_tz_create(int tz_id, const char *name)
{
return 0;
--
2.17.1
[PATCH 2/2] thermal: core: Move initialization after core initcall
The generic netlink is initialized at subsys_initcall, so far after the thermal init routine and the thermal generic netlink family initialization. On ŝome platforms, that leads to a memory corruption. The fix was sent to netdev@ to move the genetlink framework initialization at core_initcall. Move the thermal core initialization to postcore level which is very close to core level. Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Daniel Lezcano --- drivers/thermal/thermal_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index c2e7d7aaa354..79551bb6cd4c 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -1617,4 +1617,4 @@ static int __init thermal_init(void) mutex_destroy(&poweroff_lock); return result; } -core_initcall(thermal_init); +postcore_initcall(thermal_init); -- 2.17.1
Re: [PATCH v1] PCI: dwc: fix a warning about variable 'res' is uninitialized
On Fri, Jul 17, 2020 at 05:31:11PM +0100, Lorenzo Pieralisi wrote:
> On Fri, Jul 17, 2020 at 09:30:07PM +0800, Dejin Zheng wrote:
> > The kernel test robot reported a compile warning,
> >
> > drivers/pci/controller/dwc/pci-keystone.c:1236:18: warning: variable 'res'
> > is uninitialized when used here [-Wuninitialized]
> >
> > The commit c59a7d771134b5 ("PCI: dwc: Convert to
> > devm_platform_ioremap_resource_byname()") did a wrong conversion for
> > keystone driver. the commit use devm_platform_ioremap_resource_byname()
> > to replace platform_get_resource_byname() and devm_ioremap_resource().
> > but the subsequent code needs to use the variable 'res', which is got by
> > platform_get_resource_byname() for resource "app". so revert it.
> >
> > Fixes: c59a7d771134b5 ("PCI: dwc: Convert to
> > devm_platform_ioremap_resource_byname()")
> > Reported-by: kernel test robot
> > Signed-off-by: Dejin Zheng
> > ---
> > drivers/pci/controller/dwc/pci-keystone.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Squashed in the commit it is fixing, thanks.
>
Lorenzo, Thanks a lot for your help.
BR,
Dejin
> Lorenzo
>
> > diff --git a/drivers/pci/controller/dwc/pci-keystone.c
> > b/drivers/pci/controller/dwc/pci-keystone.c
> > index 5ffc3b40c4f6..00279002102e 100644
> > --- a/drivers/pci/controller/dwc/pci-keystone.c
> > +++ b/drivers/pci/controller/dwc/pci-keystone.c
> > @@ -1228,8 +1228,8 @@ static int __init ks_pcie_probe(struct
> > platform_device *pdev)
> > if (!pci)
> > return -ENOMEM;
> >
> > - ks_pcie->va_app_base =
> > - devm_platform_ioremap_resource_byname(pdev, "app");
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
> > + ks_pcie->va_app_base = devm_ioremap_resource(dev, res);
> > if (IS_ERR(ks_pcie->va_app_base))
> > return PTR_ERR(ks_pcie->va_app_base);
> >
> > --
> > 2.25.0
> >
Re: [PATCH v5 03/17] perf ftrace: add option -t/--tid to filter by thread id
Em Fri, Jul 17, 2020 at 09:26:50PM +0800, Changbin Du escreveu: > On Thu, Jul 16, 2020 at 12:36:30PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Sat, Jul 11, 2020 at 08:40:21PM +0800, Changbin Du escreveu: > > > +++ b/tools/perf/Documentation/perf-ftrace.txt > > > @@ -38,6 +38,10 @@ OPTIONS > > > --pid=:: > > > Trace on existing process id (comma separated list). > > > +-t:: > > > +--tid=:: > > > + Trace on existing thread id (comma separated list). > > Humm, I just tried: > > [root@five ~]# yes > /dev/null & > > [1] 18265 > > [root@five ~]# perf ftrace --tid 18265 > > ^C[root@five ~]# > > After waiting for a while, nothing, what am I doing wrong? > I got it wrong. Currently ftrace only can filter by pid. If the pid is not > the main thread it won't work. > So this patch makes no sense. will drop this. I think you could alternatively keep it but inform the user that this target, available to other perf commands, isn't available for ftrace as it doesn't support it, this way when the user goes from: perf trace|top|record|script|report --tid 1234 to: perf ftrace --tid 1234 He gets a message like: ERROR: 'ftrace' doesn't support the --tid target, try with --pid And that would be more useful, provides an explanation as why that target can't be used and suggests an alternative. - Arnaldo
Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology
On Mon, Jul 13, 2020 at 1:02 AM Takashi Iwai wrote: > > On Wed, 08 Jul 2020 20:14:27 +0200, > Dan Williams wrote: > > > > +Recommended replacements for 'blacklist/whitelist' are: > > +'denylist / allowlist' > > +'blocklist / passlist' > > I started looking through the tree now and noticed there are lots of > patterns like "whitelisted" or "blacklisted". How can the words fit > for those? Actually, there are two cases like: > > - Foo is blacklisted > - Allow to load the non-whitelisted cards > > Currently I'm replacing the former with "Foo is in denylist", but not > sure about the latter case. I thought Kees mentioned about this, but > don't remember the proposal... Hmm. In these cases, we're trying to convey one of two things. A given device/platform/CPU/whatever could be known to be problematic and thus disallowed, or we could have a policy that we generally don't trust hardware but we have specific reason to believe that this particular hardware is okay. After doing a highly scientific sampling of a few cases, some of these are indeed lists and some are not. If we're going to look for new words for these concepts, perhaps we shouldn't focus on the *list* aspect -- after all, that's just a rather popular implementation detail, but it's not the core concept we're trying to express. As an example case, we have a horrible concept in which some Intel CPUs support a form of memory failure recovery, and there is no enumeration mechanism. Instead, there's a list (sigh). So we could say "your CPU is whitelisted for such-and-such," which at least gets the idea across, but saying "your CPU is allowlisted for such-and-such" seems like a stretch. It's not that we have a policy to allow things on the list -- it's that we think that CPUs not on the list simply don't have the relevant capability. Here are some brainstormed ideas: - Such-and-such feature is quirked off. (Or disabled due to a quirk.) - Your device is not on the known-good list. - Your device is not known-good. It might work anyway -- to try it, set such-and-such option. - Your device is known bad. - Your device is busted and we think you should pressure the manufacturer to fix it. - Your device is too old and no longer supported. - Seriously, you're trying to use an 80386 on a modern kernel? No thanks. We think it's neat that you still have one that works, though. - (Specifically for modules and not part of the Linux kernel tree) disable_autoload instead of blacklist, perhaps? Part of my point is that we use blacklist and whitelist to mean various things, and I don't think we should try to invent a couple of new catch-all terms to replace them. Perhaps replacing these words could be an opportunity to come up with better descriptions at the same time.
Re: linux-next: Tree for Jul 17 (drivers/rtc/rtc-ds1374.o)
On 7/17/20 4:40 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20200716:
>
> New tree: init
> Changed tree: dmi (from quilt to git)
>
> My fixes tree contains:
>
> dbf24e30ce2e ("device_cgroup: Fix RCU list debugging warning")
>
> I revreted 3 commits from the powerpc tree due to reported run time
> problems.
>
> The sound tree gained a semantic conflict against the dma-mapping tree.
>
> The security tree still had its build failure for which I applied a patch.
>
> The tip tree still had one build failure for which I reverted a commit.
> It also gained a conflict against the crypto tree
>
> The kvm tree gained a conflict and a semantic conflict against the
> tip tree.
>
> The dmaengine tree gained conflicts against the wireless-drivers-next
> and Linus' trees.
>
> The pinctrl tree gained a build failure so I used the version from
> next-20200716.
>
> The set_fs tree gained a conflict against the powerpc tree.
>
> The init tree gained a conflict against the block tre.
>
> The akpm-current tree gained conflicts against the crypto and tip trees.
> It also gained a build failure for which I applied a patch.
>
> Non-merge commits (relative to Linus' tree): 8001
> 8717 files changed, 441636 insertions(+), 169176 deletions(-)
>
>
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one. You should use "git fetch" and checkout or reset to the new
> master.
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source. There are also quilt-import.log and merge.log
> files in the Next directory. Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig and htmldocs. And finally, a simple boot test
> of the powerpc pseries_le_defconfig kernel in qemu (with and without
> kvm enabled).
>
> Below is a summary of the state of the merge.
>
> I am currently merging 325 trees (counting Linus' and 83 trees of bug
> fix patches pending for the current merge release).
>
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
>
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
>
> Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
> Gortmaker for triage and bug fixes.
>
on x86_64:
# CONFIG_WATCHDOG is not set
ld: drivers/rtc/rtc-ds1374.o: in function `ds1374_probe':
rtc-ds1374.c:(.text+0x736): undefined reference to `watchdog_init_timeout'
ld: rtc-ds1374.c:(.text+0x77e): undefined reference to
`devm_watchdog_register_device'
--
~Randy
Reported-by: Randy Dunlap
Re: [PATCH v3 08/12] ima: Shallow copy the args_p member of ima_rule_entry.lsm elements
On 2020-07-17 18:35:03, Konsta Karsisto wrote:
> Hi,
>
> Found one glitch with this change, see below:
>
> On Thu, Jul 9, 2020 at 9:22 AM Tyler Hicks
> wrote:
> >
> > The args_p member is a simple string that is allocated by
> > ima_rule_init(). Shallow copy it like other non-LSM references in
> > ima_rule_entry structs.
> >
> > There are no longer any necessary error path cleanups to do in
> > ima_lsm_copy_rule().
> >
> > Signed-off-by: Tyler Hicks
> > ---
> >
> > * v3
> > - No change
> > * v2
> > - Adjusted context to account for ima_lsm_copy_rule() directly calling
> > ima_lsm_free_rule() and the lack of explicit reference ownership
> > transfers
> > - Added comment to ima_lsm_copy_rule() to document the args_p
> > reference ownership transfer
> >
> > security/integrity/ima/ima_policy.c | 16 +++-
> > 1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/security/integrity/ima/ima_policy.c
> > b/security/integrity/ima/ima_policy.c
> > index 9842e2e0bc6d..b02e1ffd10c9 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > @@ -300,10 +300,13 @@ static struct ima_rule_entry
> > *ima_lsm_copy_rule(struct ima_rule_entry *entry)
> > continue;
> >
> > nentry->lsm[i].type = entry->lsm[i].type;
> > - nentry->lsm[i].args_p = kstrdup(entry->lsm[i].args_p,
> > - GFP_KERNEL);
> > - if (!nentry->lsm[i].args_p)
> > - goto out_err;
> > + nentry->lsm[i].args_p = entry->lsm[i].args_p;
> > + /*
> > +* Remove the reference from entry so that the associated
> > +* memory will not be freed during a later call to
> > +* ima_lsm_free_rule(entry).
> > +*/
> > + entry->lsm[i].args_p = NULL;
>
> This assignment necessitates a change in the code below...
>
> > security_filter_rule_init(nentry->lsm[i].type,
> > Audit_equal,
> > @@ -314,11 +317,6 @@ static struct ima_rule_entry *ima_lsm_copy_rule(struct
> > ima_rule_entry *entry)
> > (char *)entry->lsm[i].args_p);
>
> ... you should refer to nentry->lsm[i].args_p here!
>
> Other than that,
>
> Reviewed-by: Konsta Karsisto
Thank you, Konsta. You're exactly right about the required change.
Without it, the pr_warn() in the error path will always attempt to print
a NULL pointer.
Mimi, the following change (along with adding Konsta's Reviewed-by)
needs to be made to this patch in next-integrity-testing:
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index b02e1ffd10c9..330a4e216349 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -314,7 +314,7 @@ static struct ima_rule_entry *ima_lsm_copy_rule(struct
ima_rule_entry *entry)
&nentry->lsm[i].rule);
if (!nentry->lsm[i].rule)
pr_warn("rule for LSM \'%s\' is undefined\n",
- (char *)entry->lsm[i].args_p);
+ (char *)nentry->lsm[i].args_p);
}
return nentry;
}
It will then cause the next patch in the series to not apply but the
fixup is minor.
Let me know if you are alright with doing these changes yourself or if
you'd like me to submit a new series revision.
If you do this rebase work in next-integrity-testing yourself, I've
prepared a copy branch of next-integrity-testing with all of the
necessary changes for you to compare against:
https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/log/?h=next-integrity-testing-fixup
My apologies for the trouble.
Tyler
>
>
> Konsta
>
> > }
> > return nentry;
> > -
> > -out_err:
> > - ima_lsm_free_rule(nentry);
> > - kfree(nentry);
> > - return NULL;
> > }
> >
> > static int ima_lsm_update_rule(struct ima_rule_entry *entry)
> > --
> > 2.25.1
> >
Re: [PATCH 1/2] fpga: dfl: map feature mmio resources in their own feature drivers
Mostly little stuff.
Consider refactoring create_feature_instance.
Tom
> diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
> index e220bec..22dc025 100644
> --- a/drivers/fpga/dfl-pci.c
> +++ b/drivers/fpga/dfl-pci.c
> @@ -39,6 +39,11 @@ static void __iomem *cci_pci_ioremap_bar(struct pci_dev
> *pcidev, int bar)
> return pcim_iomap_table(pcidev)[bar];
> }
>
> +static void cci_pci_iounmap_bars(struct pci_dev *pcidev, int mapped_bars)
> +{
> + pcim_iounmap_regions(pcidev, mapped_bars);
> +}
A singleton, called only one place. Consider replacing with a direct call.
> +
> static int cci_pci_alloc_irq(struct pci_dev *pcidev)
> {
> int ret, nvec = pci_msix_vec_count(pcidev);
> @@ -123,7 +128,7 @@ static int *cci_pci_create_irq_table(struct pci_dev
> *pcidev, unsigned int nvec)
> static int cci_enumerate_feature_devs(struct pci_dev *pcidev)
> {
> struct cci_drvdata *drvdata = pci_get_drvdata(pcidev);
> - int port_num, bar, i, nvec, ret = 0;
> + int port_num, bar, i, nvec, mapped_bars, ret = 0;
Shouldn't mapped_bars be at least unsigned and maybe either uint32_t or
uint64_t ?
I see pcim_ioumap_regions has int as parameter. boo
> struct dfl_fpga_enum_info *info;
> struct dfl_fpga_cdev *cdev;
> resource_size_t start, len;
> @@ -163,6 +168,8 @@ static int cci_enumerate_feature_devs(struct pci_dev
> *pcidev)
> goto irq_free_exit;
> }
>
> + mapped_bars = BIT(0);
> +
> /*
>* PF device has FME and Ports/AFUs, and VF device only has one
>* Port/AFU. Check them and add related "Device Feature List" info
> @@ -172,7 +179,7 @@ static int cci_enumerate_feature_devs(struct pci_dev
> *pcidev)
> start = pci_resource_start(pcidev, 0);
> len = pci_resource_len(pcidev, 0);
>
> - dfl_fpga_enum_info_add_dfl(info, start, len, base);
> + dfl_fpga_enum_info_add_dfl(info, start, len);
>
> /*
>* find more Device Feature Lists (e.g. Ports) per information
> @@ -200,22 +207,26 @@ static int cci_enumerate_feature_devs(struct pci_dev
> *pcidev)
> if (!base)
> continue;
>
> + mapped_bars |= BIT(bar);
> +
> start = pci_resource_start(pcidev, bar) + offset;
> len = pci_resource_len(pcidev, bar) - offset;
>
> - dfl_fpga_enum_info_add_dfl(info, start, len,
> -base + offset);
> + dfl_fpga_enum_info_add_dfl(info, start, len);
> }
> } else if (dfl_feature_is_port(base)) {
> start = pci_resource_start(pcidev, 0);
> len = pci_resource_len(pcidev, 0);
>
> - dfl_fpga_enum_info_add_dfl(info, start, len, base);
> + dfl_fpga_enum_info_add_dfl(info, start, len);
> } else {
> ret = -ENODEV;
> goto irq_free_exit;
> }
>
> + /* release I/O mappings for next step enumeration */
> + cci_pci_iounmap_bars(pcidev, mapped_bars);
There is no iounmap_bars in error handling, likely need to add this.
> +
> /* start enumeration with prepared enumeration information */
> cdev = dfl_fpga_feature_devs_enumerate(info);
> if (IS_ERR(cdev)) {
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 649958a..7dc6411 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -250,6 +250,11 @@ int dfl_fpga_check_port_id(struct platform_device *pdev,
> void *pport_id)
> }
> EXPORT_SYMBOL_GPL(dfl_fpga_check_port_id);
>
> +static bool is_header_feature(struct dfl_feature *feature)
> +{
> + return feature->id == FEATURE_ID_FIU_HEADER;
Could this be a macro ?
> +}
> +
> /**
> * dfl_fpga_dev_feature_uinit - uinit for sub features of dfl feature device
> * @pdev: feature device.
> @@ -273,8 +278,20 @@ static int dfl_feature_instance_init(struct
> platform_device *pdev,
>struct dfl_feature *feature,
>struct dfl_feature_driver *drv)
> {
> + void __iomem *base;
> int ret = 0;
>
> + if (!is_header_feature(feature)) {
> + base = devm_platform_ioremap_resource(pdev,
> + feature->resource_index);
> + if (IS_ERR(base)) {
> + dev_err(&pdev->dev, "fail to get iomem resource!\n");
> + return PTR_ERR(base);
> + }
> +
> + feature->ioaddr = base;
> + }
> +
> if (drv->ops->init) {
> ret = drv->ops->init(pdev, feature);
> if (ret)
> @@ -427,7 +444,9 @@ EXPORT_SYMBOL_GPL(dfl_fpga_dev_ops_unregister);
> * @irq_table: Linux IRQ numbers for all irqs, indexed by local irq index of
> * this device.
> * @feature_dev: current feature device.
> - * @ioaddr:
Re: [PATCH] drm/v3d: Use platform_get_irq_optional() to get optional IRQs
On Thu, Jul 16, 2020 at 7:51 AM Nicolas Saenz Julienne
wrote:
>
> Aside from being more correct, the non optional version of the function
> prints an error when failing to find the IRQ.
>
> Fixes: eea9b97b4504 ("drm/v3d: Add support for V3D v4.2")
> Signed-off-by: Nicolas Saenz Julienne
> ---
> drivers/gpu/drm/v3d/v3d_irq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
> index c88686489b88..0be2eb7876be 100644
> --- a/drivers/gpu/drm/v3d/v3d_irq.c
> +++ b/drivers/gpu/drm/v3d/v3d_irq.c
> @@ -217,7 +217,7 @@ v3d_irq_init(struct v3d_dev *v3d)
> V3D_CORE_WRITE(core, V3D_CTL_INT_CLR, V3D_CORE_IRQS);
> V3D_WRITE(V3D_HUB_INT_CLR, V3D_HUB_IRQS);
>
> - irq1 = platform_get_irq(v3d_to_pdev(v3d), 1);
> + irq1 = platform_get_irq_optional(v3d_to_pdev(v3d), 1);
> if (irq1 == -EPROBE_DEFER)
> return irq1;
> if (irq1 > 0) {
> --
Reviewed-by: Eric Anholt
[PATCH 00/30] Second batch of W=1 fixes for IIO
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Only a couple left after this. I'll sort those next week. Lee Jones (30): iio: adc: ti_am335x_adc: Remove a couple of unused 'read' variables iio: adc: twl4030-madc: Remove set but unused variables 'len' iio: adc: twl4030-madc: Fix misnamed struct attribute iio: magnetometer: hmc5843: 'hmc5843_pm_ops' is unused in 1 of 3 files including hmc5843_core.h iio: adc: twl6030-gpadc: Fix some misdocumentation and formatting issues iio: dac: ltc2632: Fix formatting in kerneldoc struct header iio: light: si1145: Demote obvious misuse of kerneldoc to standard comment blocks iio: resolver: ad2s1200: Change ordering of compiler attribute macro iio: temperature: mlx90632: Function parameter descriptions must match exactly iio: light: us5182d: Fix formatting in kerneldoc function block iio: adc: ad799x: Demote seemingly unintentional kerneldoc header iio: dac: ad5504: Fix formatting errors and demote non-compliant kerneldoc iio: adc: at91_adc: Fix 'bad line' warning iio: adc: at91-sama5d2_adc: Struct kerneldoc titles need to start with 'struct ' iio: adc: cpcap-adc: Demote seemingly unintentional kerneldoc header iio: accel: sca3000: Fix 2 misspellings and demote nonconforming kerneldocs iio: gyro: adxrs450: Change ordering of compiler attribute macro iio: gyro: fxas21002c: Move 'fxas21002c_reg_fields' to the only file its used iio: imu: st_lsm6dsx: st_lsm6dsx: Reorder 'inline' declaration iio: adc: max1363: Fix kerneldoc attribute formatting for 'lock' iio: adc: max9611: Demote obvious misuse of kerneldoc to standard comment blocks iio: adc: mcp320x: Change ordering of compiler attribute macro iio: adc: palmas_gpadc: Demote non-conforming kerneldoc header iio: imu: inv_mpu6050: inv_mpu_core: Demote obvious misuse of kerneldoc to standard comment blocks iio: imu: inv_mpu6050: inv_mpu_ring: Demote seemingly unintentional kerneldoc header iio: adc: qcom-pm8xxx-xoadc: Demote standard comment block and supply missing description iio: magnetometer: ak8974: Add description for ak8974's 'scan' attribute iio: imu: st_lsm6dsx: st_lsm6dsx_shub: Demote obvious misuse of kerneldoc to standard comment blocks iio: imu: st_lsm6dsx: st_lsm6dsx: Mark 'st_lsm6dsx_accel_ext_info' as __maybe_unused iio: adc: rockchip_saradc: Demote Demote seemingly unintentional kerneldoc header drivers/iio/accel/sca3000.c | 12 ++-- drivers/iio/adc/ad799x.c | 2 +- drivers/iio/adc/at91-sama5d2_adc.c | 4 +- drivers/iio/adc/at91_adc.c | 2 +- drivers/iio/adc/cpcap-adc.c | 6 +- drivers/iio/adc/max1363.c| 2 +- drivers/iio/adc/max9611.c| 4 +- drivers/iio/adc/mcp320x.c| 2 +- drivers/iio/adc/palmas_gpadc.c | 3 +- drivers/iio/adc/qcom-pm8xxx-xoadc.c | 3 +- drivers/iio/adc/rockchip_saradc.c| 2 +- drivers/iio/adc/ti_am335x_adc.c | 8 +-- drivers/iio/adc/twl4030-madc.c | 14 ++--- drivers/iio/adc/twl6030-gpadc.c | 4 +- drivers/iio/dac/ad5504.c | 7 +-- drivers/iio/dac/ltc2632.c| 6 +- drivers/iio/gyro/adxrs450.c | 2 +- drivers/iio/gyro/fxas21002c.h| 66 drivers/iio/gyro/fxas21002c_core.c | 66 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 14 ++--- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 2 +- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 5 +- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c | 8 +-- drivers/iio/light/si1145.c | 6 +- drivers/iio/light/us5182d.c | 8 +-- drivers/iio/magnetometer/ak8974.c| 1 + drivers/iio/magnetometer/hmc5843.h | 6 +- drivers/iio/resolver/ad2s1200.c | 2 +- drivers/iio/temperature/mlx90632.c | 4 +- 29 files changed, 136 insertions(+), 135 deletions(-) -- 2.25.1
Re: [PATCH v4] clk: tegra: pll: Improve PLLM enable-state detection
On 09/07/2020 18:20, Dmitry Osipenko wrote:
> Power Management Controller (PMC) can override the PLLM clock settings,
> including the enable-state. Although PMC could only act as a second level
> gate, meaning that PLLM needs to be enabled by the Clock and Reset
> Controller (CaR) anyways if we want it to be enabled. Hence, when PLLM is
> overridden by PMC, it needs to be enabled by CaR and ungated by PMC in
> order to be functional. Please note that this patch doesn't fix any known
> problem, and thus, it's merely a minor improvement.
>
> Link:
> https://lore.kernel.org/linux-arm-kernel/20191210120909.GA2703785@ulmo/T/
> Signed-off-by: Dmitry Osipenko
> ---
>
> Changelog:
>
> v4: - Renamed pllm_pmc_clk_enabled() to pllm_clk_is_gated_by_pmc() as
> it was suggested by Jon Hunter in the review comment to v3.
>
> v3: - Dropped unintended code change that was accidentally added to v2.
>
> v2: - Added clarifying comment to the code.
>
> - Prettified the code.
>
> drivers/clk/tegra/clk-pll.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
> index b2d39a66f0fa..ff13b371e176 100644
> --- a/drivers/clk/tegra/clk-pll.c
> +++ b/drivers/clk/tegra/clk-pll.c
> @@ -327,16 +327,26 @@ int tegra_pll_wait_for_lock(struct tegra_clk_pll *pll)
> return clk_pll_wait_for_lock(pll);
> }
>
> +static bool pllm_clk_is_gated_by_pmc(struct tegra_clk_pll *pll)
> +{
> + u32 val = readl_relaxed(pll->pmc + PMC_PLLP_WB0_OVERRIDE);
> +
> + return (val & PMC_PLLP_WB0_OVERRIDE_PLLM_OVERRIDE) &&
> + !(val & PMC_PLLP_WB0_OVERRIDE_PLLM_ENABLE);
> +}
> +
> static int clk_pll_is_enabled(struct clk_hw *hw)
> {
> struct tegra_clk_pll *pll = to_clk_pll(hw);
> u32 val;
>
> - if (pll->params->flags & TEGRA_PLLM) {
> - val = readl_relaxed(pll->pmc + PMC_PLLP_WB0_OVERRIDE);
> - if (val & PMC_PLLP_WB0_OVERRIDE_PLLM_OVERRIDE)
> - return val & PMC_PLLP_WB0_OVERRIDE_PLLM_ENABLE ? 1 : 0;
> - }
> + /*
> + * Power Management Controller (PMC) can override the PLLM clock
> + * settings, including the enable-state. The PLLM is enabled when
> + * PLLM's CaR state is ON and when PLLM isn't gated by PMC.
> + */
> + if ((pll->params->flags & TEGRA_PLLM) && pllm_clk_is_gated_by_pmc(pll))
> + return 0;
>
> val = pll_readl_base(pll);
>
>
I have tested this on Jetson TK1 using u-boot to verify the behaviour
and it does indeed work as described here. I have also ran it through
the automated testing we have for Tegra and see no immediate issue.
Therefore ...
Reviewed-by: Jon Hunter
Tested-by: Jon Hunter
Thanks!
Jon
--
nvpublic
[PATCH 03/30] iio: adc: twl4030-madc: Fix misnamed struct attribute
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/twl4030-madc.c:170: warning: Function parameter or member
'usb3v1' not described in 'twl4030_madc_data'
Cc: J Keerthy
Cc: Mikko Ylinen
Cc: Amit Kucheria
Signed-off-by: Lee Jones
---
drivers/iio/adc/twl4030-madc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
index 826d8295e9b3c..882a678b44690 100644
--- a/drivers/iio/adc/twl4030-madc.c
+++ b/drivers/iio/adc/twl4030-madc.c
@@ -153,7 +153,7 @@ enum sample_type {
* struct twl4030_madc_data - a container for madc info
* @dev: Pointer to device structure for madc
* @lock: Mutex protecting this data structure
- * @regulator: Pointer to bias regulator for madc
+ * @usb3v1:Pointer to bias regulator for madc
* @requests: Array of request struct corresponding to SW1, SW2 and RT
* @use_second_irq:IRQ selection (main or co-processor)
* @imr: Interrupt mask register of MADC
@@ -161,7 +161,7 @@ enum sample_type {
*/
struct twl4030_madc_data {
struct device *dev;
- struct mutex lock; /* mutex protecting this data structure */
+ struct mutex lock;
struct regulator *usb3v1;
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
bool use_second_irq;
--
2.25.1
Re: [PATCH 2/7] usb: bdc: Add compatible string for new style USB DT nodes
On 7/17/2020 8:23 AM, Al Cooper wrote: > Add compatible string for some newer boards that only have this > as there match sting. > > Signed-off-by: Al Cooper This looks good to me, however you should also include it in the binding document. -- Florian
[PATCH 13/30] iio: adc: at91_adc: Fix 'bad line' warning
All lines should start with ' *'. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/at91_adc.c:160: warning: bad line: (Interruptions registers mostly) Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: Maxime Ripard Signed-off-by: Lee Jones --- drivers/iio/adc/at91_adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c index 0368b6dc6d60a..c5ea75cd88fa8 100644 --- a/drivers/iio/adc/at91_adc.c +++ b/drivers/iio/adc/at91_adc.c @@ -157,7 +157,7 @@ * struct at91_adc_reg_desc - Various informations relative to registers * @channel_base: Base offset for the channel data registers * @drdy_mask: Mask of the DRDY field in the relevant registers - (Interruptions registers mostly) + * (Interruptions registers mostly) * @status_register: Offset of the Interrupt Status Register * @trigger_register: Offset of the Trigger setup register * @mr_prescal_mask: Mask of the PRESCAL field in the adc MR register -- 2.25.1
[PATCH 01/30] iio: adc: ti_am335x_adc: Remove a couple of unused 'read' variables
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/ti_am335x_adc.c: In function ‘tiadc_buffer_preenable’:
drivers/iio/adc/ti_am335x_adc.c:297:21: warning: variable ‘read’ set but not
used [-Wunused-but-set-variable]
297 | int i, fifo1count, read;
| ^~~~
drivers/iio/adc/ti_am335x_adc.c: In function ‘tiadc_buffer_predisable’:
drivers/iio/adc/ti_am335x_adc.c:346:21: warning: variable ‘read’ set but not
used [-Wunused-but-set-variable]
346 | int fifo1count, i, read;
| ^~~~
Cc: Rachna Patil
Signed-off-by: Lee Jones
---
drivers/iio/adc/ti_am335x_adc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 9d984f2a8ba74..93b67bb165044 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -294,7 +294,7 @@ static int tiadc_start_dma(struct iio_dev *indio_dev)
static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
{
struct tiadc_device *adc_dev = iio_priv(indio_dev);
- int i, fifo1count, read;
+ int i, fifo1count;
tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
IRQENB_FIFO1OVRRUN |
@@ -303,7 +303,7 @@ static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
/* Flush FIFO. Needed in corner cases in simultaneous tsc/adc use */
fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
for (i = 0; i < fifo1count; i++)
- read = tiadc_readl(adc_dev, REG_FIFO1);
+ tiadc_readl(adc_dev, REG_FIFO1);
return 0;
}
@@ -343,7 +343,7 @@ static int tiadc_buffer_predisable(struct iio_dev
*indio_dev)
{
struct tiadc_device *adc_dev = iio_priv(indio_dev);
struct tiadc_dma *dma = &adc_dev->dma;
- int fifo1count, i, read;
+ int fifo1count, i;
tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW));
@@ -358,7 +358,7 @@ static int tiadc_buffer_predisable(struct iio_dev
*indio_dev)
/* Flush FIFO of leftover data in the time it takes to disable adc */
fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
for (i = 0; i < fifo1count; i++)
- read = tiadc_readl(adc_dev, REG_FIFO1);
+ tiadc_readl(adc_dev, REG_FIFO1);
return 0;
}
--
2.25.1
[PATCH 26/30] iio: adc: qcom-pm8xxx-xoadc: Demote standard comment block and supply missing description
Kerneldoc is only suitable for documenting functions and struct/enums.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter
'PM8XXX_CHANNEL_INTERNAL' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter
'PM8XXX_CHANNEL_125V' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter
'PM8XXX_CHANNEL_INTERNAL_2' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:133: warning: Excess function parameter
'PM8XXX_CHANNEL_MUXOFF' description in 'PM8XXX_CHANNEL_INTERNAL'
drivers/iio/adc/qcom-pm8xxx-xoadc.c:412: warning: Function parameter or member
'variant' not described in 'pm8xxx_xoadc'
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Linus Walleij
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/iio/adc/qcom-pm8xxx-xoadc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/qcom-pm8xxx-xoadc.c
b/drivers/iio/adc/qcom-pm8xxx-xoadc.c
index c599ffa45a04c..cd5fa30e77df4 100644
--- a/drivers/iio/adc/qcom-pm8xxx-xoadc.c
+++ b/drivers/iio/adc/qcom-pm8xxx-xoadc.c
@@ -120,7 +120,7 @@
#define ADC_ARB_USRP_DATA0 0x19D
#define ADC_ARB_USRP_DATA1 0x19C
-/**
+/*
* Physical channels which MUST exist on all PM variants in order to provide
* proper reference points for calibration.
*
@@ -388,6 +388,7 @@ struct pm8xxx_chan_info {
* struct pm8xxx_xoadc - state container for the XOADC
* @dev: pointer to device
* @map: regmap to access registers
+ * @variant: XOADC variant characteristics
* @vref: reference voltage regulator
* characteristics of the channels, and sensible default settings
* @nchans: number of channels, configured by the device tree
--
2.25.1
[PATCH 25/30] iio: imu: inv_mpu6050: inv_mpu_ring: Demote seemingly unintentional kerneldoc header
This is the only use of kerneldoc in the source file and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c:118: warning: Function parameter or member 'irq' not described in 'inv_mpu6050_read_fifo' drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c:118: warning: Function parameter or member 'p' not described in 'inv_mpu6050_read_fifo' Cc: Jean-Baptiste Maneyrol Signed-off-by: Lee Jones --- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c index 9511e4715e2c1..b533fa2dad0ab 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c @@ -111,7 +111,7 @@ static int inv_reset_fifo(struct iio_dev *indio_dev) return result; } -/** +/* * inv_mpu6050_read_fifo() - Transfer data from hardware FIFO to KFIFO. */ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p) -- 2.25.1
[PATCH 17/30] iio: gyro: adxrs450: Change ordering of compiler attribute macro
Kerneldoc gets confused if the variable does not follow the
type/attribute definitions.
Fixes the following W=1 kernel build warning(s):
drivers/iio/gyro/adxrs450.c:79: warning: Function parameter or member
'cacheline_aligned' not described in 'adxrs450_state'
Cc: Michael Hennerich
Signed-off-by: Lee Jones
---
drivers/iio/gyro/adxrs450.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/gyro/adxrs450.c b/drivers/iio/gyro/adxrs450.c
index b00c0eb442493..e00b97e30cf9d 100644
--- a/drivers/iio/gyro/adxrs450.c
+++ b/drivers/iio/gyro/adxrs450.c
@@ -73,7 +73,7 @@ enum {
struct adxrs450_state {
struct spi_device *us;
struct mutexbuf_lock;
- __be32 tx cacheline_aligned;
+ __be32 cacheline_aligned tx;
__be32 rx;
};
--
2.25.1
[PATCH 27/30] iio: magnetometer: ak8974: Add description for ak8974's 'scan' attribute
Fixes the following W=1 kernel build warning(s):
drivers/iio/magnetometer/ak8974.c:200: warning: Function parameter or member
'scan' not described in 'ak8974'
Cc: Linus Walleij
Cc: Samu Onkalo
Signed-off-by: Lee Jones
---
drivers/iio/magnetometer/ak8974.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/magnetometer/ak8974.c
b/drivers/iio/magnetometer/ak8974.c
index 91c39352fba26..4d6d8b699f037 100644
--- a/drivers/iio/magnetometer/ak8974.c
+++ b/drivers/iio/magnetometer/ak8974.c
@@ -180,6 +180,7 @@
* @drdy_irq: uses the DRDY IRQ line
* @drdy_complete: completion for DRDY
* @drdy_active_low: the DRDY IRQ is active low
+ * @scan: timestamps
*/
struct ak8974 {
struct i2c_client *i2c;
--
2.25.1
[PATCH 12/30] iio: dac: ad5504: Fix formatting errors and demote non-compliant kerneldoc
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ad5504.c:58: warning: Function parameter or member
'pwr_down_mask' not described in 'ad5504_state'
drivers/iio/dac/ad5504.c:58: warning: Function parameter or member
'pwr_down_mode' not described in 'ad5504_state'
drivers/iio/dac/ad5504.c:64: warning: cannot understand function prototype:
'enum ad5504_supported_device_ids '
Cc: Michael Hennerich
Signed-off-by: Lee Jones
---
drivers/iio/dac/ad5504.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/dac/ad5504.c b/drivers/iio/dac/ad5504.c
index c64e6898ff20a..7e4e422ddfefc 100644
--- a/drivers/iio/dac/ad5504.c
+++ b/drivers/iio/dac/ad5504.c
@@ -43,8 +43,8 @@
* @spi: spi_device
* @reg: supply regulator
* @vref_mv: actual reference voltage used
- * @pwr_down_mask power down mask
- * @pwr_down_mode current power down mode
+ * @pwr_down_mask: power down mask
+ * @pwr_down_mode: current power down mode
* @data: transfer buffer
*/
struct ad5504_state {
@@ -57,10 +57,9 @@ struct ad5504_state {
__be16 data[2] cacheline_aligned;
};
-/**
+/*
* ad5504_supported_device_ids:
*/
-
enum ad5504_supported_device_ids {
ID_AD5504,
ID_AD5501,
--
2.25.1
[PATCH 21/30] iio: adc: max9611: Demote obvious misuse of kerneldoc to standard comment blocks
No attempt has been made to document any of the demoted structs here.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/max9611.c:117: warning: cannot understand function prototype:
'const unsigned int max9611_mux_conf[][2] = '
drivers/iio/adc/max9611.c:145: warning: cannot understand function prototype:
'const unsigned int max9611_gain_conf[][2] = '
Cc: Jacopo Mondi
Cc: Geert Uytterhoeven
Signed-off-by: Lee Jones
---
drivers/iio/adc/max9611.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index 04d5ff7d2c8ec..3a361299a70f4 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -110,7 +110,7 @@ enum max9611_conf_ids {
CONF_TEMP,
};
-/**
+/*
* max9611_mux_conf - associate ADC mux configuration with register address
* where data shall be read from
*/
@@ -133,7 +133,7 @@ enum max9611_csa_gain_params {
CSA_GAIN_OFFS_RAW,
};
-/**
+/*
* max9611_csa_gain_conf - associate gain multiplier with LSB and
*offset values.
*
--
2.25.1
[PATCH 23/30] iio: adc: palmas_gpadc: Demote non-conforming kerneldoc header
Very few of the struct attributes have been documented here.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'dev' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'palmas' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'irq' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'irq_auto_0' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'irq_auto_1' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'adc_info' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'conv_completion' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'wakeup1_data' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'wakeup2_data' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'wakeup1_enable' not described in 'palmas_gpadc'
drivers/iio/adc/palmas_gpadc.c:114: warning: Function parameter or member
'wakeup2_enable' not described in 'palmas_gpadc'
Cc: Pradeep Goudagunta
Signed-off-by: Lee Jones
---
drivers/iio/adc/palmas_gpadc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
index 46e595eb889fa..81b0a76a767e8 100644
--- a/drivers/iio/adc/palmas_gpadc.c
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -76,7 +76,7 @@ static struct palmas_gpadc_info palmas_gpadc_info[] = {
PALMAS_ADC_INFO(IN15, 0, 0, 0, 0, INVALID, INVALID, true),
};
-/**
+/*
* struct palmas_gpadc - the palmas_gpadc structure
* @ch0_current: channel 0 current source setting
* 0: 0 uA
@@ -94,7 +94,6 @@ static struct palmas_gpadc_info palmas_gpadc_info[] = {
* This is the palmas_gpadc structure to store run-time information
* and pointers for this driver instance.
*/
-
struct palmas_gpadc {
struct device *dev;
struct palmas *palmas;
--
2.25.1
[PATCH 19/30] iio: imu: st_lsm6dsx: st_lsm6dsx: Reorder 'inline' declaration
Fixes the following W=1 kernel build warning(s):
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:487:1: warning: ‘inline’ is not at
beginning of declaration [-Wold-style-declaration]
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning:
‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
Cc: Lorenzo Bianconi
Cc: Denis Ciocca
Signed-off-by: Lee Jones
---
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
index b56df409ed0fa..3e47a9287938b 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
@@ -484,7 +484,7 @@ st_lsm6dsx_write_locked(struct st_lsm6dsx_hw *hw, unsigned
int addr,
return err;
}
-static const inline struct iio_mount_matrix *
+static inline const struct iio_mount_matrix *
st_lsm6dsx_get_mount_matrix(const struct iio_dev *iio_dev,
const struct iio_chan_spec *chan)
{
--
2.25.1
[PATCH 24/30] iio: imu: inv_mpu6050: inv_mpu_core: Demote obvious misuse of kerneldoc to standard comment blocks
No attempt has been made to document any of the demoted functions here.
Fixes the following W=1 kernel build warning(s):
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:444: warning: Function parameter or
member 'st' not described in 'inv_mpu6050_set_lpf_regs'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:444: warning: Function parameter or
member 'val' not described in 'inv_mpu6050_set_lpf_regs'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:480: warning: Function parameter or
member 'indio_dev' not described in 'inv_mpu6050_init_config'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:862: warning: Function parameter or
member 'st' not described in 'inv_mpu6050_set_lpf'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:862: warning: Function parameter or
member 'rate' not described in 'inv_mpu6050_set_lpf'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or
member 'dev' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or
member 'attr' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or
member 'buf' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:893: warning: Function parameter or
member 'count' not described in 'inv_mpu6050_fifo_rate_store'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:954: warning: Function parameter or
member 'dev' not described in 'inv_fifo_rate_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:954: warning: Function parameter or
member 'attr' not described in 'inv_fifo_rate_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:954: warning: Function parameter or
member 'buf' not described in 'inv_fifo_rate_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:975: warning: Function parameter or
member 'dev' not described in 'inv_attr_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:975: warning: Function parameter or
member 'attr' not described in 'inv_attr_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:975: warning: Function parameter or
member 'buf' not described in 'inv_attr_show'
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c:1282: warning: Function parameter
or member 'st' not described in 'inv_check_and_setup_chip'
Cc: Jean-Baptiste Maneyrol
Signed-off-by: Lee Jones
---
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index 4d604fe842e5d..f6b2b2e8f1010 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -433,7 +433,7 @@ static int inv_mpu6050_set_gyro_fsr(struct
inv_mpu6050_state *st,
return regmap_write(st->map, st->reg->gyro_config, data);
}
-/**
+/*
* inv_mpu6050_set_lpf_regs() - set low pass filter registers, chip dependent
*
* MPU60xx/MPU9150 use only 1 register for accelerometer + gyroscope
@@ -467,7 +467,7 @@ static int inv_mpu6050_set_lpf_regs(struct
inv_mpu6050_state *st,
return regmap_write(st->map, st->reg->accel_lpf, val);
}
-/**
+/*
* inv_mpu6050_init_config() - Initialize hardware, disable FIFO.
*
* Initial configuration:
@@ -847,7 +847,7 @@ static int inv_mpu6050_write_raw(struct iio_dev *indio_dev,
return result;
}
-/**
+/*
* inv_mpu6050_set_lpf() - set low pass filer based on fifo rate.
*
* Based on the Nyquist principle, the bandwidth of the low
@@ -884,7 +884,7 @@ static int inv_mpu6050_set_lpf(struct inv_mpu6050_state
*st, int rate)
return 0;
}
-/**
+/*
* inv_mpu6050_fifo_rate_store() - Set fifo rate.
*/
static ssize_t
@@ -945,7 +945,7 @@ inv_mpu6050_fifo_rate_store(struct device *dev, struct
device_attribute *attr,
return count;
}
-/**
+/*
* inv_fifo_rate_show() - Get the current sampling rate.
*/
static ssize_t
@@ -962,7 +962,7 @@ inv_fifo_rate_show(struct device *dev, struct
device_attribute *attr,
return scnprintf(buf, PAGE_SIZE, "%u\n", fifo_rate);
}
-/**
+/*
* inv_attr_show() - calling this function will show current
*parameters.
*
@@ -1275,7 +1275,7 @@ static const struct iio_info mpu_info = {
.debugfs_reg_access = &inv_mpu6050_reg_access,
};
-/**
+/*
* inv_check_and_setup_chip() - check and setup chip.
*/
static int inv_check_and_setup_chip(struct inv_mpu6050_state *st)
--
2.25.1
Re: [PATCH 3/7] bdc: Fix bug causing crash after multiple disconnects
On 7/17/2020 8:23 AM, Al Cooper wrote: > From: Sasi Kumar > > Multiple connects/disconnects can cause a crash on the second > disconnect. The driver had a problem where it would try to send > endpoint commands after it was disconnected which is not allowed > by the hardware. The fix is to only allow the endpoint commands > when the endpoint is connected. This will also fix issues that > showed up when using configfs to create gadgets. > > refs #SWLINUX-5477 This internal reference should be removed and maybe we should be providing a Fixes tag as well since this is a bug fix? -- Florian
Re: [PATCH next v2 0/6] soc: ti: k3-ringacc: updates
On 7/17/20 6:20 AM, Grygorii Strashko wrote: Hi Santosh, This series is a set of non critical updates for The TI K3 AM654x/J721E Ring Accelerator driver. Thanks. Will have a look and if all looks good, add it to next. Patch 1 - convert bindings to json-schema Patches 2,3,5 - code reworking Patch 4 - adds new API to request pair of rings k3_ringacc_request_rings_pair() Patch 6 - updates K3 UDMA to use new API Changes in v2: - fixed build warning with patch 6 - added "Reviewed-by:" and "Acked-by:" tags. v1: https://lore.kernel.org/patchwork/cover/1266231/ Grygorii Strashko (4): dt-bindings: soc: ti: k3-ringacc: convert bindings to json-schema soc: ti: k3-ringacc: add ring's flags to dump soc: ti: k3-ringacc: add request pair of rings api. soc: ti: k3-ringacc: separate soc specific initialization Peter Ujfalusi (2): soc: ti: k3-ringacc: Move state tracking variables under a struct dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair .../devicetree/bindings/soc/ti/k3-ringacc.txt | 59 -- .../bindings/soc/ti/k3-ringacc.yaml | 102 + drivers/dma/ti/k3-udma-glue.c | 42 ++-- drivers/dma/ti/k3-udma.c | 34 +-- drivers/soc/ti/k3-ringacc.c | 194 -- include/linux/soc/ti/k3-ringacc.h | 4 + 6 files changed, 261 insertions(+), 174 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
[PATCH 28/30] iio: imu: st_lsm6dsx: st_lsm6dsx_shub: Demote obvious misuse of kerneldoc to standard comment blocks
No attempt has been made to document any of the demoted functions here. Fixes the following W=1 kernel build warning(s): drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:174: warning: Function parameter or member 'hw' not described in 'st_lsm6dsx_shub_read_output' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:174: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_read_output' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:174: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_read_output' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'hw' not described in 'st_lsm6dsx_shub_write_reg' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'addr' not described in 'st_lsm6dsx_shub_write_reg' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_write_reg' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:205: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_write_reg' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'sensor' not described in 'st_lsm6dsx_shub_read' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'addr' not described in 'st_lsm6dsx_shub_read' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_read' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:285: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_read' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'sensor' not described in 'st_lsm6dsx_shub_write' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'addr' not described in 'st_lsm6dsx_shub_write' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'data' not described in 'st_lsm6dsx_shub_write' drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c:335: warning: Function parameter or member 'len' not described in 'st_lsm6dsx_shub_write' Cc: Lorenzo Bianconi Signed-off-by: Lee Jones --- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c index c1f83fe0d8dad..9a14dde4795da 100644 --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c @@ -163,7 +163,7 @@ static void st_lsm6dsx_shub_wait_complete(struct st_lsm6dsx_hw *hw) msleep((200U / odr) + 1); } -/** +/* * st_lsm6dsx_shub_read_output - read i2c controller register * * Read st_lsm6dsx i2c controller register @@ -195,7 +195,7 @@ st_lsm6dsx_shub_read_output(struct st_lsm6dsx_hw *hw, u8 *data, return err; } -/** +/* * st_lsm6dsx_shub_write_reg - write i2c controller register * * Write st_lsm6dsx i2c controller register @@ -273,7 +273,7 @@ static int st_lsm6dsx_shub_master_enable(struct st_lsm6dsx_sensor *sensor, return err; } -/** +/* * st_lsm6dsx_shub_read - read data from slave device register * * Read data from slave device register. SLV0 is used for @@ -323,7 +323,7 @@ st_lsm6dsx_shub_read(struct st_lsm6dsx_sensor *sensor, u8 addr, sizeof(config)); } -/** +/* * st_lsm6dsx_shub_write - write data to slave device register * * Write data from slave device register. SLV0 is used for -- 2.25.1
[PATCH 30/30] iio: adc: rockchip_saradc: Demote Demote seemingly unintentional kerneldoc header
This is the only use of kerneldoc in the source file and no
descriptions are provided.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/rockchip_saradc.c:190: warning: Function parameter or member
'reset' not described in 'rockchip_saradc_reset_controller'
Cc: Heiko Stuebner
Cc: Philipp Zabel
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Lee Jones
---
drivers/iio/adc/rockchip_saradc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/rockchip_saradc.c
b/drivers/iio/adc/rockchip_saradc.c
index 582ba047c4a67..cf4ec59c1dab0 100644
--- a/drivers/iio/adc/rockchip_saradc.c
+++ b/drivers/iio/adc/rockchip_saradc.c
@@ -183,7 +183,7 @@ static const struct of_device_id rockchip_saradc_match[] = {
};
MODULE_DEVICE_TABLE(of, rockchip_saradc_match);
-/**
+/*
* Reset SARADC Controller.
*/
static void rockchip_saradc_reset_controller(struct reset_control *reset)
--
2.25.1
[PATCH 29/30] iio: imu: st_lsm6dsx: st_lsm6dsx: Mark 'st_lsm6dsx_accel_ext_info' as __maybe_unused
It doesn't make sense to move it into '*core*' as it's co-located with
other, similar definitions which are used in multiple locations.
Fixes the following W=1 kernel build warning(s):
In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c:17:
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning:
‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
497 | static const struct iio_chan_spec_ext_info st_lsm6dsx_accel_ext_info[] =
{
| ^
In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.c:17:
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning:
‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
497 | static const struct iio_chan_spec_ext_info st_lsm6dsx_accel_ext_info[] =
{
| ^
In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i3c.c:16:
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h:497:44: warning:
‘st_lsm6dsx_accel_ext_info’ defined but not used [-Wunused-const-variable=]
497 | static const struct iio_chan_spec_ext_info st_lsm6dsx_accel_ext_info[] =
{
| ^
Cc: Lorenzo Bianconi
Cc: Denis Ciocca
Signed-off-by: Lee Jones
---
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
index 3e47a9287938b..d82ec6398222f 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
@@ -494,7 +494,8 @@ st_lsm6dsx_get_mount_matrix(const struct iio_dev *iio_dev,
return &hw->orientation;
}
-static const struct iio_chan_spec_ext_info st_lsm6dsx_accel_ext_info[] = {
+static const
+struct iio_chan_spec_ext_info __maybe_unused st_lsm6dsx_accel_ext_info[] = {
IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, st_lsm6dsx_get_mount_matrix),
{ }
};
--
2.25.1
[PATCH 14/30] iio: adc: at91-sama5d2_adc: Struct kerneldoc titles need to start with 'struct '
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/at91-sama5d2_adc.c:360: warning: cannot understand function
prototype: 'struct at91_adc_dma '
drivers/iio/adc/at91-sama5d2_adc.c:379: warning: cannot understand function
prototype: 'struct at91_adc_touch '
Cc: Ludovic Desroches
Cc: Eugen Hristev
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Signed-off-by: Lee Jones
---
drivers/iio/adc/at91-sama5d2_adc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c
b/drivers/iio/adc/at91-sama5d2_adc.c
index 9abbbdcc74200..c7fe749419b28 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -347,7 +347,7 @@ struct at91_adc_trigger {
};
/**
- * at91_adc_dma - at91-sama5d2 dma information struct
+ * struct at91_adc_dma - at91-sama5d2 dma information struct
* @dma_chan: the dma channel acquired
* @rx_buf:dma coherent allocated area
* @rx_dma_buf:dma handler for the buffer
@@ -369,7 +369,7 @@ struct at91_adc_dma {
};
/**
- * at91_adc_touch - at91-sama5d2 touchscreen information struct
+ * struct at91_adc_touch - at91-sama5d2 touchscreen information struct
* @sample_period_val: the value for periodic trigger interval
* @touching: is the pen touching the screen or not
* @x_pos: temporary placeholder for pressure computation
--
2.25.1
[PATCH 22/30] iio: adc: mcp320x: Change ordering of compiler attribute macro
Kerneldoc gets confused if the variable does not follow th
type/attribute definitions.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/mcp320x.c:96: warning: Function parameter or member
'cacheline_aligned' not described in 'mcp320x'
Cc: Oskar Andero
Cc: Bendorff Jensen
Cc: Soren Andersen
Signed-off-by: Lee Jones
---
drivers/iio/adc/mcp320x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/mcp320x.c b/drivers/iio/adc/mcp320x.c
index 2c0eb5de110ca..191a8f644ffe7 100644
--- a/drivers/iio/adc/mcp320x.c
+++ b/drivers/iio/adc/mcp320x.c
@@ -91,7 +91,7 @@ struct mcp320x {
struct mutex lock;
const struct mcp320x_chip_info *chip_info;
- u8 tx_buf cacheline_aligned;
+ u8 cacheline_aligned tx_buf;
u8 rx_buf[4];
};
--
2.25.1
[PATCH 20/30] iio: adc: max1363: Fix kerneldoc attribute formatting for 'lock'
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/max1363.c:190: warning: Function parameter or member 'lock'
not described in 'max1363_state'
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Rohit Sarkar
Signed-off-by: Lee Jones
---
drivers/iio/adc/max1363.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
index 9d92017c79b2d..0fe348a47fe01 100644
--- a/drivers/iio/adc/max1363.c
+++ b/drivers/iio/adc/max1363.c
@@ -150,7 +150,7 @@ struct max1363_chip_info {
* @current_mode: the scan mode of this chip
* @requestedmask: a valid requested set of channels
* @reg: supply regulator
- * @lock lock to ensure state is consistent
+ * @lock: lock to ensure state is consistent
* @monitor_on:whether monitor mode is enabled
* @monitor_speed: parameter corresponding to device monitor speed setting
* @mask_high: bitmask for enabled high thresholds
--
2.25.1
[PATCH 18/30] iio: gyro: fxas21002c: Move 'fxas21002c_reg_fields' to the only file its used
'fxas21002c_reg_fields' is only used in '*core*', meaning that '*i2c*'
and '*spi*' complain of a defined but not used const variable. Let's
move it into the source file.
Fixes the following W=1 kernel build warning(s):
In file included from drivers/iio/gyro/fxas21002c_i2c.c:14:
drivers/iio/gyro/fxas21002c.h:79:31: warning: ‘fxas21002c_reg_fields’ defined
but not used [-Wunused-const-variable=]
79 | static const struct reg_field fxas21002c_reg_fields[] = {
| ^
In file included from drivers/iio/gyro/fxas21002c_spi.c:14:
drivers/iio/gyro/fxas21002c.h:79:31: warning: ‘fxas21002c_reg_fields’ defined
but not used [-Wunused-const-variable=]
79 | static const struct reg_field fxas21002c_reg_fields[] = {
| ^
Cc: Rui Miguel Silva
Signed-off-by: Lee Jones
---
drivers/iio/gyro/fxas21002c.h | 66 --
drivers/iio/gyro/fxas21002c_core.c | 66 ++
2 files changed, 66 insertions(+), 66 deletions(-)
diff --git a/drivers/iio/gyro/fxas21002c.h b/drivers/iio/gyro/fxas21002c.h
index 566d92de26763..c81cecee121cb 100644
--- a/drivers/iio/gyro/fxas21002c.h
+++ b/drivers/iio/gyro/fxas21002c.h
@@ -76,72 +76,6 @@ enum fxas21002c_fields {
F_MAX_FIELDS,
};
-static const struct reg_field fxas21002c_reg_fields[] = {
- [F_DR_STATUS] = REG_FIELD(FXAS21002C_REG_STATUS, 0, 7),
- [F_OUT_X_MSB] = REG_FIELD(FXAS21002C_REG_OUT_X_MSB, 0, 7),
- [F_OUT_X_LSB] = REG_FIELD(FXAS21002C_REG_OUT_X_LSB, 0, 7),
- [F_OUT_Y_MSB] = REG_FIELD(FXAS21002C_REG_OUT_Y_MSB, 0, 7),
- [F_OUT_Y_LSB] = REG_FIELD(FXAS21002C_REG_OUT_Y_LSB, 0, 7),
- [F_OUT_Z_MSB] = REG_FIELD(FXAS21002C_REG_OUT_Z_MSB, 0, 7),
- [F_OUT_Z_LSB] = REG_FIELD(FXAS21002C_REG_OUT_Z_LSB, 0, 7),
- [F_ZYX_OW] = REG_FIELD(FXAS21002C_REG_DR_STATUS, 7, 7),
- [F_Z_OW]= REG_FIELD(FXAS21002C_REG_DR_STATUS, 6, 6),
- [F_Y_OW]= REG_FIELD(FXAS21002C_REG_DR_STATUS, 5, 5),
- [F_X_OW]= REG_FIELD(FXAS21002C_REG_DR_STATUS, 4, 4),
- [F_ZYX_DR] = REG_FIELD(FXAS21002C_REG_DR_STATUS, 3, 3),
- [F_Z_DR]= REG_FIELD(FXAS21002C_REG_DR_STATUS, 2, 2),
- [F_Y_DR]= REG_FIELD(FXAS21002C_REG_DR_STATUS, 1, 1),
- [F_X_DR]= REG_FIELD(FXAS21002C_REG_DR_STATUS, 0, 0),
- [F_OVF] = REG_FIELD(FXAS21002C_REG_F_STATUS, 7, 7),
- [F_WMKF]= REG_FIELD(FXAS21002C_REG_F_STATUS, 6, 6),
- [F_CNT] = REG_FIELD(FXAS21002C_REG_F_STATUS, 0, 5),
- [F_MODE]= REG_FIELD(FXAS21002C_REG_F_SETUP, 6, 7),
- [F_WMRK]= REG_FIELD(FXAS21002C_REG_F_SETUP, 0, 5),
- [F_EVENT] = REG_FIELD(FXAS21002C_REG_F_EVENT, 5, 5),
- [FE_TIME] = REG_FIELD(FXAS21002C_REG_F_EVENT, 0, 4),
- [F_BOOTEND] = REG_FIELD(FXAS21002C_REG_INT_SRC_FLAG, 3, 3),
- [F_SRC_FIFO]= REG_FIELD(FXAS21002C_REG_INT_SRC_FLAG, 2, 2),
- [F_SRC_RT] = REG_FIELD(FXAS21002C_REG_INT_SRC_FLAG, 1, 1),
- [F_SRC_DRDY]= REG_FIELD(FXAS21002C_REG_INT_SRC_FLAG, 0, 0),
- [F_WHO_AM_I]= REG_FIELD(FXAS21002C_REG_WHO_AM_I, 0, 7),
- [F_BW] = REG_FIELD(FXAS21002C_REG_CTRL0, 6, 7),
- [F_SPIW]= REG_FIELD(FXAS21002C_REG_CTRL0, 5, 5),
- [F_SEL] = REG_FIELD(FXAS21002C_REG_CTRL0, 3, 4),
- [F_HPF_EN] = REG_FIELD(FXAS21002C_REG_CTRL0, 2, 2),
- [F_FS] = REG_FIELD(FXAS21002C_REG_CTRL0, 0, 1),
- [F_ELE] = REG_FIELD(FXAS21002C_REG_RT_CFG, 3, 3),
- [F_ZTEFE] = REG_FIELD(FXAS21002C_REG_RT_CFG, 2, 2),
- [F_YTEFE] = REG_FIELD(FXAS21002C_REG_RT_CFG, 1, 1),
- [F_XTEFE] = REG_FIELD(FXAS21002C_REG_RT_CFG, 0, 0),
- [F_EA] = REG_FIELD(FXAS21002C_REG_RT_SRC, 6, 6),
- [F_ZRT] = REG_FIELD(FXAS21002C_REG_RT_SRC, 5, 5),
- [F_ZRT_POL] = REG_FIELD(FXAS21002C_REG_RT_SRC, 4, 4),
- [F_YRT] = REG_FIELD(FXAS21002C_REG_RT_SRC, 3, 3),
- [F_YRT_POL] = REG_FIELD(FXAS21002C_REG_RT_SRC, 2, 2),
- [F_XRT] = REG_FIELD(FXAS21002C_REG_RT_SRC, 1, 1),
- [F_XRT_POL] = REG_FIELD(FXAS21002C_REG_RT_SRC, 0, 0),
- [F_DBCNTM] = REG_FIELD(FXAS21002C_REG_RT_THS, 7, 7),
- [F_THS] = REG_FIELD(FXAS21002C_REG_RT_SRC, 0, 6),
- [F_RT_COUNT]= REG_FIELD(FXAS21002C_REG_RT_COUNT, 0, 7),
- [F_TEMP]= REG_FIELD(FXAS21002C_REG_TEMP, 0, 7),
- [F_RST] = REG_FIELD(FXAS21002C_REG_CTRL1, 6, 6),
- [F_ST] = REG_FIELD
[PATCH 16/30] iio: accel: sca3000: Fix 2 misspellings and demote nonconforming kerneldocs
Fixes the following W=1 kernel build warning(s):
drivers/iio/accel/sca3000.c:210: warning: Function parameter or member
'mot_det_mult_xz' not described in 'sca3000_chip_info'
drivers/iio/accel/sca3000.c:210: warning: Function parameter or member
'mot_det_mult_y' not described in 'sca3000_chip_info'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member
'indio_dev' not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'chan'
not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'type'
not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'dir'
not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'info'
not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'val'
not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:871: warning: Function parameter or member 'val2'
not described in 'sca3000_read_event_value'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member
'indio_dev' not described in 'sca3000_read_event_config'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member 'chan'
not described in 'sca3000_read_event_config'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member 'type'
not described in 'sca3000_read_event_config'
drivers/iio/accel/sca3000.c:1110: warning: Function parameter or member 'dir'
not described in 'sca3000_read_event_config'
Cc: Christophe JAILLET
Signed-off-by: Lee Jones
---
drivers/iio/accel/sca3000.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/accel/sca3000.c b/drivers/iio/accel/sca3000.c
index 6e429072e44a4..3952187166ffa 100644
--- a/drivers/iio/accel/sca3000.c
+++ b/drivers/iio/accel/sca3000.c
@@ -186,9 +186,9 @@ struct sca3000_state {
* @option_mode_2_freq:option mode 2 sampling frequency
* @option_mode_2_3db_freq:3db cutoff frequency of the low pass filter for
* the second option mode.
- * @mod_det_mult_xz: Bit wise multipliers to calculate the threshold
+ * @mot_det_mult_xz: Bit wise multipliers to calculate the threshold
* for motion detection in the x and z axis.
- * @mod_det_mult_y:Bit wise multipliers to calculate the threshold
+ * @mot_det_mult_y:Bit wise multipliers to calculate the threshold
* for motion detection in the y axis.
*
* This structure is used to hold information about the functionality of a
given
@@ -859,9 +859,9 @@ static ssize_t sca3000_read_av_freq(struct device *dev,
*/
static IIO_DEV_ATTR_SAMP_FREQ_AVAIL(sca3000_read_av_freq);
-/**
+/*
* sca3000_read_event_value() - query of a threshold or period
- **/
+ */
static int sca3000_read_event_value(struct iio_dev *indio_dev,
const struct iio_chan_spec *chan,
enum iio_event_type type,
@@ -1100,9 +1100,9 @@ static irqreturn_t sca3000_event_handler(int irq, void
*private)
return IRQ_HANDLED;
}
-/**
+/*
* sca3000_read_event_config() what events are enabled
- **/
+ */
static int sca3000_read_event_config(struct iio_dev *indio_dev,
const struct iio_chan_spec *chan,
enum iio_event_type type,
--
2.25.1
[PATCH 09/30] iio: temperature: mlx90632: Function parameter descriptions must match exactly
'*'s are not welcome in kerneldoc parameter names. Fixes the following W=1 kernel build warning(s): drivers/iio/temperature/mlx90632.c:175: warning: Function parameter or member 'data' not described in 'mlx90632_perform_measurement' Cc: Crt Mori Signed-off-by: Lee Jones --- drivers/iio/temperature/mlx90632.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/temperature/mlx90632.c b/drivers/iio/temperature/mlx90632.c index eaca6ba068646..b9a8089be3f63 100644 --- a/drivers/iio/temperature/mlx90632.c +++ b/drivers/iio/temperature/mlx90632.c @@ -164,8 +164,8 @@ static s32 mlx90632_pwr_continuous(struct regmap *regmap) } /** - * mlx90632_perform_measurement - Trigger and retrieve current measurement cycle - * @*data: pointer to mlx90632_data object containing regmap information + * mlx90632_perform_measurement() - Trigger and retrieve current measurement cycle + * @data: pointer to mlx90632_data object containing regmap information * * Perform a measurement and return latest measurement cycle position reported * by sensor. This is a blocking function for 500ms, as that is default sensor -- 2.25.1
[PATCH 10/30] iio: light: us5182d: Fix formatting in kerneldoc function block
Kerneldoc expects attributes/parameters to be in '@*.: ' format. Fixes the following W=1 kernel build warning(s): drivers/iio/light/us5182d.c:457: warning: Function parameter or member 'data' not described in 'us5182d_update_dark_th' drivers/iio/light/us5182d.c:457: warning: Function parameter or member 'index' not described in 'us5182d_update_dark_th' drivers/iio/light/us5182d.c:479: warning: Function parameter or member 'data' not described in 'us5182d_apply_scale' drivers/iio/light/us5182d.c:479: warning: Function parameter or member 'index' not described in 'us5182d_apply_scale' Cc: Adriana Reus Signed-off-by: Lee Jones --- drivers/iio/light/us5182d.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c index b995f21a33479..24843597beba5 100644 --- a/drivers/iio/light/us5182d.c +++ b/drivers/iio/light/us5182d.c @@ -446,8 +446,8 @@ static int us5182d_read_raw(struct iio_dev *indio_dev, /** * us5182d_update_dark_th - update Darh_Th registers - * @data us5182d_data structure - * @index index in us5182d_dark_ths array to use for the updated value + * @data: us5182d_data structure + * @index: index in us5182d_dark_ths array to use for the updated value * * Function needs to be called with a lock held because it needs two i2c write * byte operations as these registers (0x27 0x28) don't work in word mode @@ -469,8 +469,8 @@ static int us5182d_update_dark_th(struct us5182d_data *data, int index) /** * us5182d_apply_scale - update the ALS scale - * @data us5182d_data structure - * @index index in us5182d_scales array to use for the updated value + * @data: us5182d_data structure + * @index: index in us5182d_scales array to use for the updated value * * Function needs to be called with a lock held as we're having more than one * i2c operation. -- 2.25.1
Re: [PATCH 7/7] usb: bdc: Use devm_clk_get_optional()
On 7/17/2020 8:23 AM, Al Cooper wrote: > From: Florian Fainelli > > The BDC clock is optional and we may get an -EPROBE_DEFER error code > which would not be propagated correctly, fix this by using > devm_clk_get_optional(). > > Signed-off-by: Florian Fainelli Since you are carrying this patch on my behalf your Signed-off-by should also be present, if you don't mind, I would like my gmail.com address to be used here for consistency with all submissions done throughout my tenure at broadcom, thanks! -- Florian
[PATCH 02/30] iio: adc: twl4030-madc: Remove set but unused variables 'len'
Fixes the following W=1 kernel build warning(s): drivers/iio/adc/twl4030-madc.c: In function ‘twl4030_madc_threaded_irq_handler’: drivers/iio/adc/twl4030-madc.c:475:9: warning: variable ‘len’ set but not used [-Wunused-but-set-variable] 475 | int i, len, ret; | ^~~ Cc: Sebastian Reichel Cc: J Keerthy Cc: Mikko Ylinen Cc: Amit Kucheria Signed-off-by: Lee Jones --- drivers/iio/adc/twl4030-madc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c index 472b08f37feae..826d8295e9b3c 100644 --- a/drivers/iio/adc/twl4030-madc.c +++ b/drivers/iio/adc/twl4030-madc.c @@ -472,7 +472,7 @@ static irqreturn_t twl4030_madc_threaded_irq_handler(int irq, void *_madc) struct twl4030_madc_data *madc = _madc; const struct twl4030_madc_conversion_method *method; u8 isr_val, imr_val; - int i, len, ret; + int i, ret; struct twl4030_madc_request *r; mutex_lock(&madc->lock); @@ -504,8 +504,8 @@ static irqreturn_t twl4030_madc_threaded_irq_handler(int irq, void *_madc) continue; method = &twl4030_conversion_methods[r->method]; /* Read results */ - len = twl4030_madc_read_channels(madc, method->rbase, -r->channels, r->rbuf, r->raw); + twl4030_madc_read_channels(madc, method->rbase, + r->channels, r->rbuf, r->raw); /* Free request */ r->result_pending = false; r->active = false; @@ -525,8 +525,8 @@ static irqreturn_t twl4030_madc_threaded_irq_handler(int irq, void *_madc) continue; method = &twl4030_conversion_methods[r->method]; /* Read results */ - len = twl4030_madc_read_channels(madc, method->rbase, -r->channels, r->rbuf, r->raw); + twl4030_madc_read_channels(madc, method->rbase, + r->channels, r->rbuf, r->raw); /* Free request */ r->result_pending = false; r->active = false; -- 2.25.1
[PATCH 04/30] iio: magnetometer: hmc5843: 'hmc5843_pm_ops' is unused in 1 of 3 files including hmc5843_core.h
We know that it's okay for 'hmc5843_pm_ops' to be unused here.
Fixes the following W=1 kernel build warning(s):
In file included from include/linux/device.h:25,
from include/linux/iio/iio.h:10,
from drivers/iio/magnetometer/hmc5843_core.c:16:
drivers/iio/magnetometer/hmc5843.h:55:26: warning: ‘hmc5843_pm_ops’ defined
but not used [-Wunused-const-variable=]
55 | static SIMPLE_DEV_PM_OPS(hmc5843_pm_ops,
| ^~
include/linux/pm.h:354:25: note: in definition of macro ‘SIMPLE_DEV_PM_OPS’
354 | const struct dev_pm_ops name = { | ^~~~
Cc: Josef Gajdusek
Signed-off-by: Lee Jones
---
drivers/iio/magnetometer/hmc5843.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/magnetometer/hmc5843.h
b/drivers/iio/magnetometer/hmc5843.h
index b0dee87a8b20e..3f6c0b6629415 100644
--- a/drivers/iio/magnetometer/hmc5843.h
+++ b/drivers/iio/magnetometer/hmc5843.h
@@ -52,9 +52,9 @@ int hmc5843_common_suspend(struct device *dev);
int hmc5843_common_resume(struct device *dev);
#ifdef CONFIG_PM_SLEEP
-static SIMPLE_DEV_PM_OPS(hmc5843_pm_ops,
- hmc5843_common_suspend,
- hmc5843_common_resume);
+static __maybe_unused SIMPLE_DEV_PM_OPS(hmc5843_pm_ops,
+ hmc5843_common_suspend,
+ hmc5843_common_resume);
#define HMC5843_PM_OPS (&hmc5843_pm_ops)
#else
#define HMC5843_PM_OPS NULL
--
2.25.1
[PATCH 06/30] iio: dac: ltc2632: Fix formatting in kerneldoc struct header
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ltc2632.c:50: warning: Function parameter or member
'powerdown_cache_mask' not described in 'ltc2632_state'
drivers/iio/dac/ltc2632.c:50: warning: Function parameter or member 'vref_mv'
not described in 'ltc2632_state'
drivers/iio/dac/ltc2632.c:50: warning: Function parameter or member 'vref_reg'
not described in 'ltc2632_state'
Cc: Liam Girdwood
Cc: Mark Brown
Cc: "Uwe Kleine-König"
Cc: Silvan Murer
Cc: Maxime Roussin-Belanger
Signed-off-by: Lee Jones
---
drivers/iio/dac/ltc2632.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
index f891311f05cfe..733f13d3e5df4 100644
--- a/drivers/iio/dac/ltc2632.c
+++ b/drivers/iio/dac/ltc2632.c
@@ -38,9 +38,9 @@ struct ltc2632_chip_info {
/**
* struct ltc2632_state - driver instance specific data
* @spi_dev: pointer to the spi_device struct
- * @powerdown_cache_mask used to show current channel powerdown state
- * @vref_mvused reference voltage (internal or external)
- * @vref_reg regulator for the reference voltage
+ * @powerdown_cache_mask: used to show current channel powerdown state
+ * @vref_mv: used reference voltage (internal or external)
+ * @vref_reg: regulator for the reference voltage
*/
struct ltc2632_state {
struct spi_device *spi_dev;
--
2.25.1
[PATCH 08/30] iio: resolver: ad2s1200: Change ordering of compiler attribute macro
Kerneldoc gets confused if the variable does not follow the
type/attribute definitions.
Fixes the following W=1 kernel build warning(s):
drivers/iio/resolver/ad2s1200.c:44: warning: Function parameter or member
'cacheline_aligned' not described in 'ad2s1200_state'
Cc: Michael Hennerich
Cc: David Veenstra
Cc: Graff Yang
Signed-off-by: Lee Jones
---
drivers/iio/resolver/ad2s1200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/resolver/ad2s1200.c b/drivers/iio/resolver/ad2s1200.c
index a391f46ee06b7..29cfd57eff9e7 100644
--- a/drivers/iio/resolver/ad2s1200.c
+++ b/drivers/iio/resolver/ad2s1200.c
@@ -40,7 +40,7 @@ struct ad2s1200_state {
struct spi_device *sdev;
struct gpio_desc *sample;
struct gpio_desc *rdvel;
- __be16 rx cacheline_aligned;
+ __be16 cacheline_aligned rx;
};
static int ad2s1200_read_raw(struct iio_dev *indio_dev,
--
2.25.1
[PATCH 11/30] iio: adc: ad799x: Demote seemingly unintentional kerneldoc header
This is the only use of function related kerneldoc in the sourcefile and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/ad799x.c:192: warning: Function parameter or member 'irq' not described in 'ad799x_trigger_handler' drivers/iio/adc/ad799x.c:192: warning: Function parameter or member 'p' not described in 'ad799x_trigger_handler' Cc: Michael Hennerich Signed-off-by: Lee Jones --- drivers/iio/adc/ad799x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad799x.c b/drivers/iio/adc/ad799x.c index ef013af1aec07..007ec7ad94752 100644 --- a/drivers/iio/adc/ad799x.c +++ b/drivers/iio/adc/ad799x.c @@ -182,7 +182,7 @@ static int ad799x_update_config(struct ad799x_state *st, u16 config) return 0; } -/** +/* * ad799x_trigger_handler() bh of trigger launched polling to ring buffer * * Currently there is no option in this driver to disable the saving of -- 2.25.1
[PATCH 15/30] iio: adc: cpcap-adc: Demote seemingly unintentional kerneldoc header
None of the headers demoted here provide any descriptions.
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'ato_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'atox_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'adc_ps_factor_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'atox_ps_factor_in' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'ato_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'atox_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'adc_ps_factor_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:100: warning: Function parameter or member
'atox_ps_factor_out' not described in 'cpcap_adc_ato'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD0' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTP' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_VBUS' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD3' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BPLUS_AD4' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_CHG_ISENSE'
not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTI' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_USB_ID' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD8' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_AD9' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_LICELL' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_HV_BATTP' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSX1_AD12' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSX2_AD13' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSY1_AD14' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_TSY2_AD15' not
described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTP_PI16'
not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_BATTI_PI17'
not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:153: warning: Enum value 'CPCAP_ADC_CHANNEL_NUM'
not described in enum 'cpcap_adc_channel'
drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_IMM'
not described in enum 'cpcap_adc_timing'
drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_IN' not
described in enum 'cpcap_adc_timing'
drivers/iio/adc/cpcap-adc.c:165: warning: Enum value 'CPCAP_ADC_TIMING_OUT'
not described in enum 'cpcap_adc_timing'
Cc: Tony Lindgren
Signed-off-by: Lee Jones
---
drivers/iio/adc/cpcap-adc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/cpcap-adc.c b/drivers/iio/adc/cpcap-adc.c
index 5086a337f4c9a..be638fcec03f6 100644
--- a/drivers/iio/adc/cpcap-adc.c
+++ b/drivers/iio/adc/cpcap-adc.c
@@ -82,7 +82,7 @@
#define CPCAP_ADC_MAX_RETRIES 5 /* Calibration */
-/**
+/*
* struct cpcap_adc_ato - timing settings for cpcap adc
*
* Unfortunately no cpcap documentation available, please document when
@@ -121,7 +121,7 @@ struct cpcap_adc {
bool done;
};
-/**
+/*
* enum cpcap_adc_channel - cpcap adc channels
*/
enum cpcap_adc_channel {
@@ -152,7 +152,7 @@ enum cpcap_adc_channel {
CPCAP_ADC_CHANNEL_NUM,
};
-/**
+/*
* enum cpcap_adc_timing - cpcap adc timing options
*
* CPCAP_ADC_TIMING_IMM seems to be immediate with no timings.
--
2.25.1
[PATCH 07/30] iio: light: si1145: Demote obvious misuse of kerneldoc to standard comment blocks
No attempt has been made to document any of the demoted functions here
Fixes the following W=1 kernel build warning(s):
drivers/iio/light/si1145.c:192: warning: Function parameter or member 'data'
not described in '__si1145_command_reset'
drivers/iio/light/si1145.c:228: warning: Function parameter or member 'data'
not described in 'si1145_command'
drivers/iio/light/si1145.c:228: warning: Function parameter or member 'cmd'
not described in 'si1145_command'
drivers/iio/light/si1145.c:1186: warning: Function parameter or member 'trig'
not described in 'si1145_trigger_set_state'
drivers/iio/light/si1145.c:1186: warning: Function parameter or member 'state'
not described in 'si1145_trigger_set_state'
Cc: Chuhong Yuan
Cc: Dan Leonard
Signed-off-by: Lee Jones
---
drivers/iio/light/si1145.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/light/si1145.c b/drivers/iio/light/si1145.c
index 0476c2bc81384..37a6a59030929 100644
--- a/drivers/iio/light/si1145.c
+++ b/drivers/iio/light/si1145.c
@@ -181,7 +181,7 @@ struct si1145_data {
int meas_rate;
};
-/**
+/*
* __si1145_command_reset() - Send CMD_NOP and wait for response 0
*
* Does not modify data->rsp_seq
@@ -215,7 +215,7 @@ static int __si1145_command_reset(struct si1145_data *data)
}
}
-/**
+/*
* si1145_command() - Execute a command and poll the response register
*
* All conversion overflows are reported as -EOVERFLOW
@@ -1176,7 +1176,7 @@ static const struct iio_buffer_setup_ops
si1145_buffer_setup_ops = {
.validate_scan_mask = si1145_validate_scan_mask,
};
-/**
+/*
* si1145_trigger_set_state() - Set trigger state
*
* When not using triggers interrupts are disabled and measurement rate is
--
2.25.1
[PATCH 05/30] iio: adc: twl6030-gpadc: Fix some misdocumentation and formatting issues
Kerneldoc expects attributes/parameters to be in '@*.: ' format. Fixes the following W=1 kernel build warning(s): drivers/iio/adc/twl6030-gpadc.c:110: warning: Function parameter or member 'ideal' not described in 'twl6030_gpadc_platform_data' drivers/iio/adc/twl6030-gpadc.c:110: warning: Function parameter or member 'channel_to_reg' not described in 'twl6030_gpadc_platform_data' Cc: Stephen Boyd Cc: Nishant Kamat Cc: Balaji T K Cc: Graeme Gregory Cc: Girish S Ghongdemath Cc: Ambresh K Cc: Oleksandr Kozaruk Cc: Mikko Ylinen Signed-off-by: Lee Jones --- drivers/iio/adc/twl6030-gpadc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c index f24148bd15de4..a19a6ce65e390 100644 --- a/drivers/iio/adc/twl6030-gpadc.c +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -94,9 +94,9 @@ struct twl6030_gpadc_data; * struct twl6030_gpadc_platform_data - platform specific data * @nchannels: number of GPADC channels * @iio_channels: iio channels - * @twl6030_ideal: pointer to calibration parameters + * @ideal: pointer to calibration parameters * @start_conversion: pointer to ADC start conversion function - * @channel_to_reg pointer to ADC function to convert channel to + * @channel_to_reg:pointer to ADC function to convert channel to * register address for reading conversion result * @calibrate: pointer to calibration function */ -- 2.25.1
Re: [PATCH 5/7] usb: bdc: driver runs out of buffer descriptors on large ADB transfers
On 7/17/2020 8:23 AM, Al Cooper wrote: > Version v1.0.40 of the Android host ADB software increased maximum > transfer sizes from 256K to 1M. Since the STB ADB gadget driver > requests only 16K at a time, the BDC driver ran out of buffer > descriptors (BDs) if the queuing happens faster than the incoming > 16K transfers. This issue is fixed by doubling the number of BDs > that can be queued so that the entire 1M request can be queued > without running out of buffers. > > Signed-off-by: Al Cooper > Signed-off-by: Florian Fainelli You can certainly remove my SoB here, since you are carrying your own patch, thanks! -- Florian
[PATCH v7 0/5] Add support for the OST in Ingenic X1000.
v6->v7: 1.Remove "default MACH_INGENIC" and make option silent. 2.Enable the corresponding driver in the platform's Kconfig. 3.Update DT of X1000 and X1830, use SYSOST instead of TCU to provide clocksource and clockevent. 周琰杰 (Zhou Yanjie) (5): dt-bindings: timer: Add Ingenic X1000 OST bindings. clocksource: Ingenic: Add support for the Ingenic X1000 OST. MIPS: Ingenic: Let the Kconfig of platform enable the clocksource driver. MIPS: X1000: Use SYSOST instead of TCU to provide clocksource. MIPS: X1830: Use SYSOST instead of TCU to provide clocksource. .../devicetree/bindings/timer/ingenic,sysost.yaml | 63 +++ arch/mips/boot/dts/ingenic/cu1000-neo.dts | 9 +- arch/mips/boot/dts/ingenic/cu1830-neo.dts | 9 +- arch/mips/boot/dts/ingenic/x1000.dtsi | 16 + arch/mips/boot/dts/ingenic/x1830.dtsi | 16 + arch/mips/jz4740/Kconfig | 7 + drivers/clocksource/Kconfig| 15 +- drivers/clocksource/Makefile | 1 + drivers/clocksource/ingenic-sysost.c | 539 + include/dt-bindings/clock/ingenic,sysost.h | 12 + 10 files changed, 672 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/timer/ingenic,sysost.yaml create mode 100644 drivers/clocksource/ingenic-sysost.c create mode 100644 include/dt-bindings/clock/ingenic,sysost.h -- 2.11.0
[PATCH v7 3/5] MIPS: Ingenic: Let the Kconfig of platform enable the clocksource driver.
The previous clocksource patch in this series ([2/3]) has remove "default MACH_INGENIC" and make option silent, so we need to enable the corresponding driver in the platform's Kconfig. Suggested-by: Daniel Lezcano Tested-by: 周正 (Zhou Zheng) Signed-off-by: 周琰杰 (Zhou Yanjie) --- Notes: v7: New patch. arch/mips/jz4740/Kconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/mips/jz4740/Kconfig b/arch/mips/jz4740/Kconfig index 6c065dcaeff8..5ad60998702e 100644 --- a/arch/mips/jz4740/Kconfig +++ b/arch/mips/jz4740/Kconfig @@ -36,27 +36,34 @@ endchoice config MACH_JZ4740 bool select SYS_HAS_CPU_MIPS32_R1 +select INGENIC_TIMER config MACH_JZ4770 bool select MIPS_CPU_SCACHE select SYS_HAS_CPU_MIPS32_R2 select SYS_SUPPORTS_HIGHMEM +select INGENIC_TIMER +select INGENIC_OST config MACH_JZ4780 bool select MIPS_CPU_SCACHE select SYS_HAS_CPU_MIPS32_R2 select SYS_SUPPORTS_HIGHMEM +select INGENIC_TIMER +select INGENIC_OST config MACH_X1000 bool select MIPS_CPU_SCACHE select SYS_HAS_CPU_MIPS32_R2 select SYS_SUPPORTS_HIGHMEM +select INGENIC_SYSOST config MACH_X1830 bool select MIPS_CPU_SCACHE select SYS_HAS_CPU_MIPS32_R2 select SYS_SUPPORTS_HIGHMEM +select INGENIC_SYSOST -- 2.11.0
[PATCH v2 2/2] ARM: dts: r8a7742-iwg21d-q7: Enable HSUSB, USB2.0 and xHCI
Enable support for HSUSB, USB2.0 and xHCI on iWave RZ/G1H carrier board.
Signed-off-by: Lad Prabhakar
Reviewed-by: Marian-Cristian Rotariu
Reviewed-by: Biju Das
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 42 +
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index e90aaf1c94f0..f4910e709b87 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -131,6 +131,30 @@
};
};
+&hsusb {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&pci0 {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+ /* Disable hsusb to enable USB2.0 host mode support on J2 */
+ /* status = "okay"; */
+};
+
+&pci1 {
+ pinctrl-0 = <&usb1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&pci2 {
+ /* Disable xhci to enable USB2.0 host mode support on J23 bottom port */
+ /* status = "okay"; */
+};
+
&pfc {
avb_pins: avb {
groups = "avb_mdio", "avb_gmii";
@@ -168,6 +192,16 @@
groups = "ssi34_ctrl", "ssi3_data", "ssi4_data";
function = "ssi";
};
+
+ usb0_pins: usb0 {
+ groups = "usb0";
+ function = "usb0";
+ };
+
+ usb1_pins: usb1 {
+ groups = "usb1_pwen";
+ function = "usb1";
+ };
};
&rcar_sound {
@@ -222,3 +256,11 @@
&ssi4 {
shared-pin;
};
+
+&usbphy {
+ status = "okay";
+};
+
+&xhci {
+ status = "okay";
+};
--
2.17.1
[PATCH v2 1/2] pinctrl: sh-pfc: r8a7790: Add USB1 PWEN pin and group
Add USB1 PWEN pin and group for USB1 interface.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index f524401fec5f..39ba1e7cc1c3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -3611,6 +3611,13 @@ static const unsigned int usb1_pins[] = {
static const unsigned int usb1_mux[] = {
USB1_PWEN_MARK, USB1_OVC_MARK,
};
+static const unsigned int usb1_pwen_pins[] = {
+ /* PWEN */
+ RCAR_GP_PIN(5, 20),
+};
+static const unsigned int usb1_pwen_mux[] = {
+ USB1_PWEN_MARK,
+};
/* - USB2 ---
*/
static const unsigned int usb2_pins[] = {
/* PWEN, OVC */
@@ -3939,7 +3946,7 @@ static const unsigned int vin3_clk_mux[] = {
};
static const struct {
- struct sh_pfc_pin_group common[289];
+ struct sh_pfc_pin_group common[290];
struct sh_pfc_pin_group automotive[1];
} pinmux_groups = {
.common = {
@@ -4193,6 +4200,7 @@ static const struct {
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb0_ovc_vbus),
SH_PFC_PIN_GROUP(usb1),
+ SH_PFC_PIN_GROUP(usb1_pwen),
SH_PFC_PIN_GROUP(usb2),
VIN_DATA_PIN_GROUP(vin0_data, 24),
VIN_DATA_PIN_GROUP(vin0_data, 20),
@@ -4640,6 +4648,7 @@ static const char * const usb0_groups[] = {
static const char * const usb1_groups[] = {
"usb1",
+ "usb1_pwen",
};
static const char * const usb2_groups[] = {
--
2.17.1
[PATCH v2 0/2] Enable USB support on iW-RainboW-G21D-Q7 board
Hi All, This series enables support for following peripherals in iW-RainboW-G21D-Q7 development platform: * HSUSB * USB2.0 * xHCI Changes for v2: * Added USB1 pwen pin and group * Fixed pinmux pins for usb1 [v1] https://lkml.org/lkml/2020/5/27/1478 * Rest of the patches from v1 have been accepted Cheers, Prabhakar Lad Prabhakar (2): pinctrl: sh-pfc: r8a7790: Add USB1 PWEN pin and group ARM: dts: r8a7742-iwg21d-q7: Enable HSUSB, USB2.0 and xHCI arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 42 + drivers/pinctrl/sh-pfc/pfc-r8a7790.c| 11 ++- 2 files changed, 52 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH v7 5/5] MIPS: X1830: Use SYSOST instead of TCU to provide clocksource.
Before this series of patches, X1830 used TCU to provide
clocksource and clockevent, but because the timer of TCU
is only 16 bits, so the timing length is only 16 bits. In
actual use, it is easy to cause some problems such as data
loss during data transmission. The SYSOST driver is provided
in this series of patches, which can provide 32bit timing
length, so use SYSOST instead of TCU to provide clocksource
and clockevent to solve the aforementioned problems.
Tested-by: 周正 (Zhou Zheng)
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v7:
New patch.
arch/mips/boot/dts/ingenic/cu1830-neo.dts | 9 +++--
arch/mips/boot/dts/ingenic/x1830.dtsi | 16
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/cu1830-neo.dts
b/arch/mips/boot/dts/ingenic/cu1830-neo.dts
index 640f96c00d63..ac4c9fbf8bca 100644
--- a/arch/mips/boot/dts/ingenic/cu1830-neo.dts
+++ b/arch/mips/boot/dts/ingenic/cu1830-neo.dts
@@ -3,7 +3,7 @@
#include "x1830.dtsi"
#include
-#include
+#include
#include
/ {
@@ -43,13 +43,10 @@
clock-frequency = <2400>;
};
-&tcu {
+&ost {
/* 1500 kHz for the system timer and clocksource */
- assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER2>;
+ assigned-clocks = <&ost OST_CLK_PERCPU_TIMER>, <&ost
OST_CLK_GLOBAL_TIMER>;
assigned-clock-rates = <150>, <150>;
-
- /* Use channel #0 for the system timer channel #2 for the clocksource */
- ingenic,pwm-channels-mask = <0xfa>;
};
&uart1 {
diff --git a/arch/mips/boot/dts/ingenic/x1830.dtsi
b/arch/mips/boot/dts/ingenic/x1830.dtsi
index eb1214481a33..99eac297ee34 100644
--- a/arch/mips/boot/dts/ingenic/x1830.dtsi
+++ b/arch/mips/boot/dts/ingenic/x1830.dtsi
@@ -47,6 +47,22 @@
clock-names = "ext", "rtc";
};
+ ost: timer@1200 {
+ compatible = "ingenic,x1830-ost", "ingenic,x1000-ost";
+ reg = <0x1200 0x1000>;
+
+ #clock-cells = <1>;
+
+ clocks = <&cgu X1830_CLK_OST>;
+ clock-names = "ost";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <4>;
+ };
+
tcu: timer@10002000 {
compatible = "ingenic,x1830-tcu", "ingenic,x1000-tcu",
"simple-mfd";
reg = <0x10002000 0x1000>;
--
2.11.0
[PATCH v4 00/10] Function Granular KASLR
Function Granular Kernel Address Space Layout Randomization (fgkaslr) - This patch set is an implementation of finer grained kernel address space randomization. It rearranges your kernel code at load time on a per-function level granularity, with only around a second added to boot time. Changes in v4: - * dropped the patch to split out change to STATIC definition in x86/boot/compressed/misc.c and replaced with a patch authored by Kees Cook to avoid the duplicate malloc definitions * Added a section to Documentation/admin-guide/kernel-parameters.txt to document the fgkaslr boot option. * redesigned the patch to hide the new layout when reading /proc/kallsyms. The previous implementation utilized a dynamically allocated linked list to display the kernel and module symbols in alphabetical order. The new implementation uses a randomly shuffled index array to display the kernel and module symbols in a random order. Changes in v3: - * Makefile changes to accommodate CONFIG_LD_DEAD_CODE_DATA_ELIMINATION * removal of extraneous ALIGN_PAGE from _etext changes * changed variable names in x86/tools/relocs to be less confusing * split out change to STATIC definition in x86/boot/compressed/misc.c * Updates to Documentation to make it more clear what is preserved in .text * much more detailed commit message for function granular KASLR patch * minor tweaks and changes that make for more readable code * this cover letter updated slightly to add additional details Changes in v2: -- * Fix to address i386 build failure * Allow module reordering patch to be configured separately so that arm (or other non-x86_64 arches) can take advantage of module function reordering. This support has not be tested by me, but smoke tested by Ard Biesheuvel on arm. * Fix build issue when building on arm as reported by Ard Biesheuvel Patches to objtool are included because they are dependencies for this patchset, however they have been submitted by their maintainer separately. Background -- KASLR was merged into the kernel with the objective of increasing the difficulty of code reuse attacks. Code reuse attacks reused existing code snippets to get around existing memory protections. They exploit software bugs which expose addresses of useful code snippets to control the flow of execution for their own nefarious purposes. KASLR moves the entire kernel code text as a unit at boot time in order to make addresses less predictable. The order of the code within the segment is unchanged - only the base address is shifted. There are a few shortcomings to this algorithm. 1. Low Entropy - there are only so many locations the kernel can fit in. This means an attacker could guess without too much trouble. 2. Knowledge of a single address can reveal the offset of the base address, exposing all other locations for a published/known kernel image. 3. Info leaks abound. Finer grained ASLR has been proposed as a way to make ASLR more resistant to info leaks. It is not a new concept at all, and there are many variations possible. Function reordering is an implementation of finer grained ASLR which randomizes the layout of an address space on a function level granularity. We use the term "fgkaslr" in this document to refer to the technique of function reordering when used with KASLR, as well as finer grained KASLR in general. Proposed Improvement This patch set proposes adding function reordering on top of the existing KASLR base address randomization. The over-arching objective is incremental improvement over what we already have. It is designed to work in combination with the existing solution. The implementation is really pretty simple, and there are 2 main area where changes occur: * Build time GCC has had an option to place functions into individual .text sections for many years now. This option can be used to implement function reordering at load time. The final compiled vmlinux retains all the section headers, which can be used to help find the address ranges of each function. Using this information and an expanded table of relocation addresses, individual text sections can be suffled immediately after decompression. Some data tables inside the kernel that have assumptions about order require re-sorting after being updated when applying relocations. In order to modify these tables, a few key symbols are excluded from the objcopy symbol stripping process for use after shuffling the text segments. Some highlights from the build time changes to look for: The top level kernel Makefile was modified to add the gcc flag if it is supported. Currently, I am applying this flag to everything it is possible to randomize. Anything that is written in C and not present in a special input section is randomized. The final binary segment 0 retains a consolidated .text section, as well as all the in
Re: [PATCH v5 03/17] perf ftrace: add option -t/--tid to filter by thread id
On Fri, 17 Jul 2020 21:26:50 +0800 Changbin Du wrote: > On Thu, Jul 16, 2020 at 12:36:30PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Sat, Jul 11, 2020 at 08:40:21PM +0800, Changbin Du escreveu: > > > This allows us to trace single thread instead of the whole process. > > > > > > Signed-off-by: Changbin Du > > > --- > > > tools/perf/Documentation/perf-ftrace.txt | 4 > > > tools/perf/builtin-ftrace.c | 2 ++ > > > 2 files changed, 6 insertions(+) > > > > > > diff --git a/tools/perf/Documentation/perf-ftrace.txt > > > b/tools/perf/Documentation/perf-ftrace.txt > > > index d79560dea19f..e204bf6d50d8 100644 > > > --- a/tools/perf/Documentation/perf-ftrace.txt > > > +++ b/tools/perf/Documentation/perf-ftrace.txt > > > @@ -38,6 +38,10 @@ OPTIONS > > > --pid=:: > > > Trace on existing process id (comma separated list). > > > > > > +-t:: > > > +--tid=:: > > > + Trace on existing thread id (comma separated list). > > > + > > > > > > Humm, I just tried: > > > > [root@five ~]# yes > /dev/null & > > [1] 18265 > > [root@five ~]# perf ftrace --tid 18265 > > ^C[root@five ~]# > > > > After waiting for a while, nothing, what am I doing wrong? > > > I got it wrong. Currently ftrace only can filter by pid. If the pid is not > the main thread it won't work. Wait what? The "pid" for ftrace is really a "task id" which is a thread id. [root@bxtest ~]# yes > /dev/null & [1] 6799 [root@bxtest ~]# trace-cmd record -e all -P 6799 Hit Ctrl^C to stop recording ^CCPU 0: 3573031 events lost CPU0 data recorded at offset=0x838000 627675136 bytes in size CPU1 data recorded at offset=0x25ed1000 0 bytes in size CPU2 data recorded at offset=0x25ed1000 0 bytes in size CPU3 data recorded at offset=0x25ed1000 0 bytes in size CPU4 data recorded at offset=0x25ed1000 0 bytes in size CPU5 data recorded at offset=0x25ed1000 0 bytes in size CPU6 data recorded at offset=0x25ed1000 0 bytes in size CPU7 data recorded at offset=0x25ed1000 0 bytes in size [root@bxtest ~]# trace-cmd report | head CPU 1 is empty CPU 2 is empty CPU 3 is empty CPU 4 is empty CPU 5 is empty CPU 6 is empty CPU 7 is empty cpus=8 yes-6799 [000] 67825.580902: sys_exit: NR 1 = 8192 yes-6799 [000] 67825.580903: sys_exit_write: 0x2000 What's different about tid vs pid? -- Steve > > So this patch makes no sense. will drop this. >
[PATCH v7 2/5] clocksource: Ingenic: Add support for the Ingenic X1000 OST.
X1000 and SoCs after X1000 (such as X1500 and X1830) had a separate OST, it no longer belongs to TCU. This driver will register both a clocksource and a sched_clock to the system. Tested-by: 周正 (Zhou Zheng) Co-developed-by: 漆鹏振 (Qi Pengzhen) Signed-off-by: 漆鹏振 (Qi Pengzhen) Signed-off-by: 周琰杰 (Zhou Yanjie) Reviewed-by: Paul Cercueil --- Notes: v1->v2: Fix compile warnings. Reported-by: kernel test robot v2->v3: No change. v3->v4: 1.Rename "ost" to "sysost" 1.Remove unrelated changes. 2.Remove ost_clock_parent enum. 3.Remove ost->percpu_timer_channel/ost->global_timer_channel. 4.Set up independent .recalc_rate/.set_rate for percpu/global timer. 5.No longer call functions in variable declarations. v4->v5: Use "of_io_request_and_map()" instead "of_iomap()". Suggested-by: Paul Cercueil v5->v6: No change. v6->v7: Suggested-by: Daniel Lezcano Remove "default MACH_INGENIC" and make options silent. drivers/clocksource/Kconfig | 15 +- drivers/clocksource/Makefile | 1 + drivers/clocksource/ingenic-sysost.c | 539 +++ 3 files changed, 552 insertions(+), 3 deletions(-) create mode 100644 drivers/clocksource/ingenic-sysost.c diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 91418381fcd4..c963e22a73fc 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -686,8 +686,7 @@ config MILBEAUT_TIMER Enables the support for Milbeaut timer driver. config INGENIC_TIMER - bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" - default MACH_INGENIC + bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if COMPILE_TEST depends on MIPS || COMPILE_TEST depends on COMMON_CLK select MFD_SYSCON @@ -696,8 +695,18 @@ config INGENIC_TIMER help Support for the timer/counter unit of the Ingenic JZ SoCs. +config INGENIC_SYSOST + bool "Clocksource/timer using the SYSOST in Ingenic X SoCs" if COMPILE_TEST + depends on MIPS || COMPILE_TEST + depends on COMMON_CLK + select MFD_SYSCON + select TIMER_OF + select IRQ_DOMAIN + help + Support for the SYSOST of the Ingenic X Series SoCs. + config INGENIC_OST - bool "Clocksource for Ingenic OS Timer" + bool "Clocksource using the OST in Ingenic JZ SoCs" if COMPILE_TEST depends on MIPS || COMPILE_TEST depends on COMMON_CLK select MFD_SYSCON diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile index bdda1a2e4097..3994e221e262 100644 --- a/drivers/clocksource/Makefile +++ b/drivers/clocksource/Makefile @@ -82,6 +82,7 @@ obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o obj-$(CONFIG_INGENIC_OST) += ingenic-ost.o +obj-$(CONFIG_INGENIC_SYSOST) += ingenic-sysost.o obj-$(CONFIG_INGENIC_TIMER)+= ingenic-timer.o obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o obj-$(CONFIG_X86_NUMACHIP) += numachip.o diff --git a/drivers/clocksource/ingenic-sysost.c b/drivers/clocksource/ingenic-sysost.c new file mode 100644 index ..e77d58449005 --- /dev/null +++ b/drivers/clocksource/ingenic-sysost.c @@ -0,0 +1,539 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Ingenic XBurst SoCs SYSOST clocks driver + * Copyright (c) 2020 周琰杰 (Zhou Yanjie) + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* OST register offsets */ +#define OST_REG_OSTCCR 0x00 +#define OST_REG_OSTCR 0x08 +#define OST_REG_OSTFR 0x0c +#define OST_REG_OSTMR 0x10 +#define OST_REG_OST1DFR0x14 +#define OST_REG_OST1CNT0x18 +#define OST_REG_OST2CNTL 0x20 +#define OST_REG_OSTCNT2HBUF0x24 +#define OST_REG_OSTESR 0x34 +#define OST_REG_OSTECR 0x38 + +/* bits within the OSTCCR register */ +#define OSTCCR_PRESCALE1_MASK 0x3 +#define OSTCCR_PRESCALE2_MASK 0xc +#define OSTCCR_PRESCALE1_LSB 0 +#define OSTCCR_PRESCALE2_LSB 2 + +/* bits within the OSTCR register */ +#define OSTCR_OST1CLR BIT(0) +#define OSTCR_OST2CLR BIT(1) + +/* bits within the OSTFR register */ +#define OSTFR_FFLAGBIT(0) + +/* bits within the OSTMR register */ +#define OSTMR_FMASKBIT(0) + +/* bits within the OSTESR register */ +#define OSTESR_OST1ENS BIT(0) +#define OSTESR_OST2ENS BIT(1) + +/* bits within the OSTECR register */ +#define OSTECR_OST1ENC BIT(0) +#define OSTECR_OST2ENC
[PATCH v4 01/10] objtool: Do not assume order of parent/child functions
If a .cold function is examined prior to it's parent, the link to the parent/child function can be overwritten when the parent is examined. Only update pfunc and cfunc if they were previously nil to prevent this from happening. Signed-off-by: Kristen Carlson Accardi Acked-by: Josh Poimboeuf --- tools/objtool/elf.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 26d11d821941..c18f0f216740 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -434,7 +434,13 @@ static int read_symbols(struct elf *elf) size_t pnamelen; if (sym->type != STT_FUNC) continue; - sym->pfunc = sym->cfunc = sym; + + if (sym->pfunc == NULL) + sym->pfunc = sym; + + if (sym->cfunc == NULL) + sym->cfunc = sym; + coldstr = strstr(sym->name, ".cold"); if (!coldstr) continue; -- 2.20.1
[PATCH v4 10/10] module: Reorder functions
Introduce a new config option to allow modules to be re-ordered
by function. This option can be enabled independently of the
kernel text KASLR or FG_KASLR settings so that it can be used
by architectures that do not support either of these features.
This option will be selected by default if CONFIG_FG_KASLR is
selected.
If a module has functions split out into separate text sections
(i.e. compiled with the -ffunction-sections flag), reorder the
functions to provide some code diversification to modules.
Signed-off-by: Kristen Carlson Accardi
Reviewed-by: Kees Cook
Acked-by: Ard Biesheuvel
Tested-by: Ard Biesheuvel
Reviewed-by: Tony Luck
Tested-by: Tony Luck
---
arch/x86/Makefile | 5 +++
init/Kconfig | 12 +++
kernel/kallsyms.c | 2 +-
kernel/module.c | 81 +++
4 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 00e378de8bc0..0f2dbc46eb5c 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -51,6 +51,11 @@ ifdef CONFIG_X86_NEED_RELOCS
LDFLAGS_vmlinux := --emit-relocs --discard-none
endif
+ifndef CONFIG_FG_KASLR
+ ifdef CONFIG_MODULE_FG_KASLR
+ KBUILD_CFLAGS_MODULE += -ffunction-sections
+ endif
+endif
#
# Prevent GCC from generating any FP code by mistake.
#
diff --git a/init/Kconfig b/init/Kconfig
index 82f042a1062f..b4741838da40 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1994,6 +1994,7 @@ config FG_KASLR
bool "Function Granular Kernel Address Space Layout Randomization"
depends on $(cc-option, -ffunction-sections)
depends on ARCH_HAS_FG_KASLR
+ select MODULE_FG_KASLR
default n
help
This option improves the randomness of the kernel text
@@ -2278,6 +2279,17 @@ config UNUSED_KSYMS_WHITELIST
one per line. The path can be absolute, or relative to the kernel
source tree.
+config MODULE_FG_KASLR
+ depends on $(cc-option, -ffunction-sections)
+ bool "Module Function Granular Layout Randomization"
+ help
+ This option randomizes the module text section by reordering the text
+ section by function at module load time. In order to use this
+ feature, the module must have been compiled with the
+ -ffunction-sections compiler flag.
+
+ If unsure, say N.
+
endif # MODULES
config MODULES_TREE_LOOKUP
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 45d147f7f10e..e3f7d0fd3270 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -692,7 +692,7 @@ static int __kallsyms_open(struct inode *inode, struct file
*file)
* When function granular kaslr is enabled, we need to print out the symbols
* at random so we don't reveal the new layout.
*/
-#if defined(CONFIG_FG_KASLR)
+#if defined(CONFIG_FG_KASLR) || defined(CONFIG_MODULE_FG_KASLR)
static int update_random_pos(struct kallsyms_shuffled_iter *s_iter,
loff_t pos, loff_t *new_pos)
{
diff --git a/kernel/module.c b/kernel/module.c
index aa183c9ac0a2..0f4f4e567a42 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
#include "module-internal.h"
@@ -2391,6 +2392,83 @@ static long get_offset(struct module *mod, unsigned int
*size,
return ret;
}
+/*
+ * shuffle_text_list()
+ * Use a Fisher Yates algorithm to shuffle a list of text sections.
+ */
+static void shuffle_text_list(Elf_Shdr **list, int size)
+{
+ int i;
+ unsigned int j;
+ Elf_Shdr *temp;
+
+ for (i = size - 1; i > 0; i--) {
+ /*
+* pick a random index from 0 to i
+*/
+ get_random_bytes(&j, sizeof(j));
+ j = j % (i + 1);
+
+ temp = list[i];
+ list[i] = list[j];
+ list[j] = temp;
+ }
+}
+
+/*
+ * randomize_text()
+ * Look through the core section looking for executable code sections.
+ * Store sections in an array and then shuffle the sections
+ * to reorder the functions.
+ */
+static void randomize_text(struct module *mod, struct load_info *info)
+{
+ int i;
+ int num_text_sections = 0;
+ Elf_Shdr **text_list;
+ int size = 0;
+ int max_sections = info->hdr->e_shnum;
+ unsigned int sec = find_sec(info, ".text");
+
+ if (sec == 0)
+ return;
+
+ text_list = kmalloc_array(max_sections, sizeof(*text_list), GFP_KERNEL);
+ if (!text_list)
+ return;
+
+ for (i = 0; i < max_sections; i++) {
+ Elf_Shdr *shdr = &info->sechdrs[i];
+ const char *sname = info->secstrings + shdr->sh_name;
+
+ if (!(shdr->sh_flags & SHF_ALLOC) ||
+ !(shdr->sh_flags & SHF_EXECINSTR) ||
+ strstarts(sname, ".init"))
+ continue;
+
+ text_list[num_text_sections] = shdr;
+
[PATCH v4 09/10] kallsyms: Hide layout
This patch makes /proc/kallsyms display in a random order, rather
than sorted by address in order to hide the newly randomized address
layout.
Signed-off-by: Kristen Carlson Accardi
Reviewed-by: Tony Luck
Tested-by: Tony Luck
---
kernel/kallsyms.c | 163 +-
1 file changed, 162 insertions(+), 1 deletion(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index bb14e64f62a4..45d147f7f10e 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -446,6 +446,12 @@ struct kallsym_iter {
int show_value;
};
+struct kallsyms_shuffled_iter {
+ struct kallsym_iter iter;
+ loff_t total_syms;
+ loff_t shuffled_index[];
+};
+
int __weak arch_get_kallsym(unsigned int symnum, unsigned long *value,
char *type, char *name)
{
@@ -661,7 +667,7 @@ bool kallsyms_show_value(const struct cred *cred)
}
}
-static int kallsyms_open(struct inode *inode, struct file *file)
+static int __kallsyms_open(struct inode *inode, struct file *file)
{
/*
* We keep iterator in m->private, since normal case is to
@@ -682,6 +688,161 @@ static int kallsyms_open(struct inode *inode, struct file
*file)
return 0;
}
+/*
+ * When function granular kaslr is enabled, we need to print out the symbols
+ * at random so we don't reveal the new layout.
+ */
+#if defined(CONFIG_FG_KASLR)
+static int update_random_pos(struct kallsyms_shuffled_iter *s_iter,
+loff_t pos, loff_t *new_pos)
+{
+ loff_t new;
+
+ if (pos >= s_iter->total_syms)
+ return 0;
+
+ new = s_iter->shuffled_index[pos];
+
+ /*
+* normally this would be done as part of update_iter, however,
+* we want to avoid triggering this in the event that new is
+* zero since we don't want to blow away our pos end indicators.
+*/
+ if (new == 0) {
+ s_iter->iter.name[0] = '\0';
+ s_iter->iter.nameoff = get_symbol_offset(new);
+ s_iter->iter.pos = new;
+ }
+
+ *new_pos = new;
+ return 1;
+}
+
+static void *shuffled_start(struct seq_file *m, loff_t *pos)
+{
+ struct kallsyms_shuffled_iter *s_iter = m->private;
+ loff_t new_pos;
+
+ if (!update_random_pos(s_iter, *pos, &new_pos))
+ return NULL;
+
+ return s_start(m, &new_pos);
+}
+
+static void *shuffled_next(struct seq_file *m, void *p, loff_t *pos)
+{
+ struct kallsyms_shuffled_iter *s_iter = m->private;
+ loff_t new_pos;
+
+ (*pos)++;
+
+ if (!update_random_pos(s_iter, *pos, &new_pos))
+ return NULL;
+
+ if (!update_iter(m->private, new_pos))
+ return NULL;
+
+ return p;
+}
+
+/*
+ * shuffle_index_list()
+ * Use a Fisher Yates algorithm to shuffle a list of text sections.
+ */
+static void shuffle_index_list(loff_t *indexes, loff_t size)
+{
+ int i;
+ unsigned int j;
+ loff_t temp;
+
+ for (i = size - 1; i > 0; i--) {
+ /* pick a random index from 0 to i */
+ get_random_bytes(&j, sizeof(j));
+ j = j % (i + 1);
+
+ temp = indexes[i];
+ indexes[i] = indexes[j];
+ indexes[j] = temp;
+ }
+}
+
+static const struct seq_operations kallsyms_shuffled_op = {
+ .start = shuffled_start,
+ .next = shuffled_next,
+ .stop = s_stop,
+ .show = s_show
+};
+
+static int kallsyms_random_open(struct inode *inode, struct file *file)
+{
+ loff_t pos;
+ struct kallsyms_shuffled_iter *shuffled_iter;
+ struct kallsym_iter iter;
+ bool show_value;
+
+ /*
+* If privileged, go ahead and use the normal algorithm for
+* displaying symbols
+*/
+ show_value = kallsyms_show_value(file->f_cred);
+ if (show_value)
+ return __kallsyms_open(inode, file);
+
+ /*
+* we need to figure out how many extra symbols there are
+* to print out past kallsyms_num_syms
+*/
+ pos = kallsyms_num_syms;
+ reset_iter(&iter, 0);
+ do {
+ if (!update_iter(&iter, pos))
+ break;
+ pos++;
+ } while (1);
+
+ /*
+* add storage space for an array of loff_t equal to the size
+* of the total number of symbols we need to print
+*/
+ shuffled_iter = __seq_open_private(file, &kallsyms_shuffled_op,
+ sizeof(*shuffled_iter) +
+ (sizeof(pos) * pos));
+ if (!shuffled_iter)
+ return -ENOMEM;
+
+ reset_iter(&shuffled_iter->iter, 0);
+ shuffled_iter->iter.show_value = show_value;
+ shuffled_iter->total_syms = pos;
+
+ /*
+* the existing update_iter algorithm requires that we
+* are either moving along increasing pos sequentially,
+
