[PATCH v10 6/7] media: i2c: imx319: Support probe while the device is off
From: Rajmohan Mani
Tell ACPI device PM code that the driver supports the device being powered
off when the driver's probe function is entered.
Signed-off-by: Rajmohan Mani
Signed-off-by: Sakari Ailus
Reviewed-by: Tomasz Figa
Reviewed-by: Bingbu Cao
---
drivers/media/i2c/imx319.c | 72 +++---
1 file changed, 44 insertions(+), 28 deletions(-)
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 8473c0bbb35d6..e0b22e9318fed 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -140,6 +140,8 @@ struct imx319 {
/* Streaming on/off */
bool streaming;
+ /* True if the device has been identified */
+ bool identified;
};
static const struct imx319_reg imx319_global_regs[] = {
@@ -2084,6 +2086,31 @@ imx319_set_pad_format(struct v4l2_subdev *sd,
return 0;
}
+/* Verify chip ID */
+static int imx319_identify_module(struct imx319 *imx319)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(>sd);
+ int ret;
+ u32 val;
+
+ if (imx319->identified)
+ return 0;
+
+ ret = imx319_read_reg(imx319, IMX319_REG_CHIP_ID, 2, );
+ if (ret)
+ return ret;
+
+ if (val != IMX319_CHIP_ID) {
+ dev_err(>dev, "chip id mismatch: %x!=%x",
+ IMX319_CHIP_ID, val);
+ return -EIO;
+ }
+
+ imx319->identified = true;
+
+ return 0;
+}
+
/* Start streaming */
static int imx319_start_streaming(struct imx319 *imx319)
{
@@ -2091,6 +2118,10 @@ static int imx319_start_streaming(struct imx319 *imx319)
const struct imx319_reg_list *reg_list;
int ret;
+ ret = imx319_identify_module(imx319);
+ if (ret)
+ return ret;
+
/* Global Setting */
reg_list = _global_setting;
ret = imx319_write_regs(imx319, reg_list->regs, reg_list->num_of_regs);
@@ -2208,26 +2239,6 @@ static int __maybe_unused imx319_resume(struct device
*dev)
return ret;
}
-/* Verify chip ID */
-static int imx319_identify_module(struct imx319 *imx319)
-{
- struct i2c_client *client = v4l2_get_subdevdata(>sd);
- int ret;
- u32 val;
-
- ret = imx319_read_reg(imx319, IMX319_REG_CHIP_ID, 2, );
- if (ret)
- return ret;
-
- if (val != IMX319_CHIP_ID) {
- dev_err(>dev, "chip id mismatch: %x!=%x",
- IMX319_CHIP_ID, val);
- return -EIO;
- }
-
- return 0;
-}
-
static const struct v4l2_subdev_core_ops imx319_subdev_core_ops = {
.subscribe_event = v4l2_ctrl_subdev_subscribe_event,
.unsubscribe_event = v4l2_event_subdev_unsubscribe,
@@ -2422,6 +2433,7 @@ static struct imx319_hwcfg *imx319_get_hwcfg(struct
device *dev)
static int imx319_probe(struct i2c_client *client)
{
struct imx319 *imx319;
+ bool low_power;
int ret;
u32 i;
@@ -2434,11 +2446,14 @@ static int imx319_probe(struct i2c_client *client)
/* Initialize subdev */
v4l2_i2c_subdev_init(>sd, client, _subdev_ops);
- /* Check module identity */
- ret = imx319_identify_module(imx319);
- if (ret) {
- dev_err(>dev, "failed to find sensor: %d", ret);
- goto error_probe;
+ low_power = acpi_dev_state_low_power(>dev);
+ if (!low_power) {
+ /* Check module identity */
+ ret = imx319_identify_module(imx319);
+ if (ret) {
+ dev_err(>dev, "failed to find sensor: %d", ret);
+ goto error_probe;
+ }
}
imx319->hwcfg = imx319_get_hwcfg(>dev);
@@ -2491,10 +2506,10 @@ static int imx319_probe(struct i2c_client *client)
goto error_media_entity;
/*
-* Device is already turned on by i2c-core with ACPI domain PM.
-* Enable runtime PM and turn off the device.
+* Don't set the device's state to active if it's in a low power state.
*/
- pm_runtime_set_active(>dev);
+ if (!low_power)
+ pm_runtime_set_active(>dev);
pm_runtime_enable(>dev);
pm_runtime_idle(>dev);
@@ -2547,6 +2562,7 @@ static struct i2c_driver imx319_i2c_driver = {
},
.probe_new = imx319_probe,
.remove = imx319_remove,
+ .flags = I2C_DRV_FL_ALLOW_LOW_POWER_PROBE,
};
module_i2c_driver(imx319_i2c_driver);
--
2.20.1
Re: How can a userspace program tell if the system supports the ACPI S4 state (Suspend-to-Disk)?
On Sat, Dec 12, 2020 at 2:22 AM Dexuan Cui wrote: > > Hi all, > It looks like Linux can hibernate even if the system does not support the ACPI > S4 state, as long as the system can shut down, so "cat /sys/power/state" > always contains "disk", unless we specify the kernel parameter "nohibernate" > or we use LOCKDOWN_HIBERNATION. > > In some scenarios IMO it can still be useful if the userspace is able to > detect > if the ACPI S4 state is supported or not, e.g. when a Linux guest runs on > Hyper-V, Hyper-V uses the virtual ACPI S4 state as an indicator of the proper > support of the tool stack on the host, i.e. the guest is discouraged from > trying hibernation if the state is not supported. > > I know we can check the S4 state by 'dmesg': > > # dmesg |grep ACPI: | grep support > [3.034134] ACPI: (supports S0 S4 S5) > > But this method is unreliable because the kernel msg buffer can be filled > and overwritten. Is there any better method? If not, do you think if the > below patch is appropriate? Thanks! Sorry for the delay. If ACPI S4 is supported, /sys/power/disk will list "platform" as one of the options (and it will be the default one then). Otherwise, "platform" is not present in /sys/power/disk, because ACPI is the only user of hibernation_ops. HTH
Re: [PATCH net] net: gro: do not keep too many GRO packets in napi->rx_list
From: Eric Dumazet
Date: Thu, 4 Feb 2021 23:44:17 +0100
> On Thu, Feb 4, 2021 at 11:14 PM Saeed Mahameed wrote:
> >
> > On Thu, 2021-02-04 at 13:31 -0800, Eric Dumazet wrote:
> > > From: Eric Dumazet
> > >
> > > Commit c80794323e82 ("net: Fix packet reordering caused by GRO and
> > > listified RX cooperation") had the unfortunate effect of adding
> > > latencies in common workloads.
> > >
> > > Before the patch, GRO packets were immediately passed to
> > > upper stacks.
> > >
> > > After the patch, we can accumulate quite a lot of GRO
> > > packets (depdending on NAPI budget).
> > >
> >
> > Why napi budget ? looking at the code it seems to be more related to
> > MAX_GRO_SKBS * gro_normal_batch, since we are counting GRO SKBs as 1
>
>
> Simply because we call gro_normal_list() from napi_poll(),
>
> So we flush the napi rx_list every 64 packets under stress.(assuming
> NIC driver uses NAPI_POLL_WEIGHT),
> or more often if napi_complete_done() is called if the budget was not
> exhausted.
Saeed,
Eric means that if we have e.g. 8 GRO packets with 8 segs each, then
rx_list will be flushed only after processing of 64 ingress frames.
> GRO always has been able to keep MAX_GRO_SKBS in its layer, but no recent
> patch
> has changed this part.
>
>
> >
> >
> > but maybe i am missing some information about the actual issue you are
> > hitting.
>
>
> Well, the issue is precisely described in the changelog.
>
> >
> >
> > > My fix is counting in napi->rx_count number of segments
> > > instead of number of logical packets.
> > >
> > > Fixes: c80794323e82 ("net: Fix packet reordering caused by GRO and
> > > listified RX cooperation")
> > > Signed-off-by: Eric Dumazet
> > > Bisected-by: John Sperbeck
> > > Tested-by: Jian Yang
> > > Cc: Maxim Mikityanskiy
> > > Cc: Alexander Lobakin
It's strange why mailmap didn't pick up my active email at pm.me.
Anyways, this fix is correct for me. It restores the original Edward's
logics, but without spurious out-of-order deliveries.
Moreover, the pre-patch behaviour can easily be achieved by increasing
net.core.gro_normal_batch if needed.
Thanks!
Reviewed-by: Alexander Lobakin
> > > Cc: Saeed Mahameed
> > > Cc: Edward Cree
> > > ---
> > > net/core/dev.c | 11 ++-
> > > 1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index
> > > a979b86dbacda9dfe31dd8b269024f7f0f5a8ef1..449b45b843d40ece7dd1e2ed6a5
> > > 996ee1db9f591 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -5735,10 +5735,11 @@ static void gro_normal_list(struct
> > > napi_struct *napi)
> > > /* Queue one GRO_NORMAL SKB up for list processing. If batch size
> > > exceeded,
> > > * pass the whole batch up to the stack.
> > > */
> > > -static void gro_normal_one(struct napi_struct *napi, struct sk_buff
> > > *skb)
> > > +static void gro_normal_one(struct napi_struct *napi, struct sk_buff
> > > *skb, int segs)
> > > {
> > > list_add_tail(>list, >rx_list);
> > > - if (++napi->rx_count >= gro_normal_batch)
> > > + napi->rx_count += segs;
> > > + if (napi->rx_count >= gro_normal_batch)
> > > gro_normal_list(napi);
> > > }
> > >
> > > @@ -5777,7 +5778,7 @@ static int napi_gro_complete(struct napi_struct
> > > *napi, struct sk_buff *skb)
> > > }
> > >
> > > out:
> > > - gro_normal_one(napi, skb);
> > > + gro_normal_one(napi, skb, NAPI_GRO_CB(skb)->count);
> >
> > Seems correct to me,
> >
> > Reviewed-by: Saeed Mahameed
Al
Re: [PATCH v2 1/1] powerpc/kvm: Save Timebase Offset to fix sched_clock() while running guest code.
Leonardo Bras writes:
> Before guest entry, TBU40 register is changed to reflect guest timebase.
> After exitting guest, the register is reverted to it's original value.
>
> If one tries to get the timestamp from host between those changes, it
> will present an incorrect value.
>
> An example would be trying to add a tracepoint in
> kvmppc_guest_entry_inject_int(), which depending on last tracepoint
> acquired could actually cause the host to crash.
>
> Save the Timebase Offset to PACA and use it on sched_clock() to always
> get the correct timestamp.
>
> Signed-off-by: Leonardo Bras
> Suggested-by: Paul Mackerras
> ---
> Changes since v1:
> - Subtracts offset only when CONFIG_KVM_BOOK3S_HANDLER and
> CONFIG_PPC_BOOK3S_64 are defined.
> ---
> arch/powerpc/include/asm/kvm_book3s_asm.h | 1 +
> arch/powerpc/kernel/asm-offsets.c | 1 +
> arch/powerpc/kernel/time.c| 8 +++-
> arch/powerpc/kvm/book3s_hv.c | 2 ++
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 ++
> 5 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
> b/arch/powerpc/include/asm/kvm_book3s_asm.h
> index 078f4648ea27..e2c12a10eed2 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_asm.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
> @@ -131,6 +131,7 @@ struct kvmppc_host_state {
> u64 cfar;
> u64 ppr;
> u64 host_fscr;
> + u64 tb_offset; /* Timebase offset: keeps correct
> timebase while on guest */
Couldn't you use the vc->tb_offset_applied for this? We have a reference
for the vcore in the hstate already.
> #endif
> };
>
> diff --git a/arch/powerpc/kernel/asm-offsets.c
> b/arch/powerpc/kernel/asm-offsets.c
> index b12d7c049bfe..0beb8fdc6352 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -706,6 +706,7 @@ int main(void)
> HSTATE_FIELD(HSTATE_CFAR, cfar);
> HSTATE_FIELD(HSTATE_PPR, ppr);
> HSTATE_FIELD(HSTATE_HOST_FSCR, host_fscr);
> + HSTATE_FIELD(HSTATE_TB_OFFSET, tb_offset);
> #endif /* CONFIG_PPC_BOOK3S_64 */
>
> #else /* CONFIG_PPC_BOOK3S */
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 67feb3524460..f27f0163792b 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -699,7 +699,13 @@ EXPORT_SYMBOL_GPL(tb_to_ns);
> */
> notrace unsigned long long sched_clock(void)
> {
> - return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
> + u64 tb = get_tb() - boot_tb;
> +
> +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_KVM_BOOK3S_HANDLER)
> + tb -= local_paca->kvm_hstate.tb_offset;
> +#endif
> +
> + return mulhdu(tb, tb_to_ns_scale) << tb_to_ns_shift;
> }
>
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index b3731572295e..c08593c63353 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -3491,6 +3491,7 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
> *vcpu, u64 time_limit,
> if ((tb & 0xff) < (new_tb & 0xff))
> mtspr(SPRN_TBU40, new_tb + 0x100);
> vc->tb_offset_applied = vc->tb_offset;
> + local_paca->kvm_hstate.tb_offset = vc->tb_offset;
> }
>
> if (vc->pcr)
> @@ -3594,6 +3595,7 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
> *vcpu, u64 time_limit,
> if ((tb & 0xff) < (new_tb & 0xff))
> mtspr(SPRN_TBU40, new_tb + 0x100);
> vc->tb_offset_applied = 0;
> + local_paca->kvm_hstate.tb_offset = 0;
> }
>
> mtspr(SPRN_HDEC, 0x7fff);
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index b73140607875..8f7a9f7f4ee6 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -632,6 +632,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
> cmpdi r8,0
> beq 37f
> std r8, VCORE_TB_OFFSET_APPL(r5)
> + std r8, HSTATE_TB_OFFSET(r13)
> mftbr6 /* current host timebase */
> add r8,r8,r6
> mtspr SPRN_TBU40,r8 /* update upper 40 bits */
> @@ -1907,6 +1908,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> beq 17f
> li r0, 0
> std r0, VCORE_TB_OFFSET_APPL(r5)
> + std r0, HSTATE_TB_OFFSET(r13)
> mftbr6 /* current guest timebase */
> subfr8,r8,r6
> mtspr SPRN_TBU40,r8 /* update upper 40 bits */
[PATCH v10 2/7] i2c: Allow an ACPI driver to manage the device's power state during probe
Enable drivers to tell ACPI that there's no need to power on a device for
probe. Drivers should still perform this by themselves if there's a need
to. In some cases powering on the device during probe is undesirable, and
this change enables a driver to choose what fits best for it.
Add a field called "flags" into struct i2c_driver for driver flags, and a
flag I2C_DRV_FL_ALLOW_LOW_POWER_PROBE to tell a driver supports probe in
low power state.
Signed-off-by: Sakari Ailus
Reviewed-by: Tomasz Figa
---
drivers/i2c/i2c-core-acpi.c | 10 ++
drivers/i2c/i2c-core-base.c | 9 ++---
include/linux/i2c.h | 19 +++
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 8ceaa88dd78fb..7bab8b9126ee6 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -493,6 +493,16 @@ struct i2c_client *i2c_acpi_new_device(struct device *dev,
int index,
}
EXPORT_SYMBOL_GPL(i2c_acpi_new_device);
+bool i2c_acpi_allow_low_power_probe(struct device *dev)
+{
+ struct i2c_driver *driver = to_i2c_driver(dev->driver);
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+
+ return driver->flags & I2C_DRV_FL_ALLOW_LOW_POWER_PROBE &&
+ adev && adev->power.state_for_enumeration >= adev->power.state;
+}
+EXPORT_SYMBOL_GPL(i2c_acpi_allow_low_power_probe);
+
#ifdef CONFIG_ACPI_I2C_OPREGION
static int acpi_gsb_i2c_read_bytes(struct i2c_client *client,
u8 cmd, u8 *data, u8 data_len)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 63ebf722a4248..87b84eee01da6 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -514,7 +514,8 @@ static int i2c_device_probe(struct device *dev)
if (status < 0)
goto err_clear_wakeup_irq;
- status = dev_pm_domain_attach(>dev, true);
+ status = dev_pm_domain_attach(>dev,
+ !i2c_acpi_allow_low_power_probe(dev));
if (status)
goto err_clear_wakeup_irq;
@@ -536,7 +537,8 @@ static int i2c_device_probe(struct device *dev)
return 0;
err_detach_pm_domain:
- dev_pm_domain_detach(>dev, true);
+ dev_pm_domain_detach(>dev,
+!i2c_acpi_allow_low_power_probe(dev));
err_clear_wakeup_irq:
dev_pm_clear_wake_irq(>dev);
device_init_wakeup(>dev, false);
@@ -563,7 +565,8 @@ static int i2c_device_remove(struct device *dev)
dev_warn(dev, "remove failed (%pe), will be ignored\n",
ERR_PTR(status));
}
- dev_pm_domain_detach(>dev, true);
+ dev_pm_domain_detach(>dev,
+!i2c_acpi_allow_low_power_probe(dev));
dev_pm_clear_wake_irq(>dev);
device_init_wakeup(>dev, false);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 56622658b2158..1a103c5933d2f 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -11,6 +11,7 @@
#define _LINUX_I2C_H
#include /* for acpi_handle */
+#include
#include
#include /* for struct device */
#include/* for completion */
@@ -217,6 +218,16 @@ enum i2c_alert_protocol {
I2C_PROTOCOL_SMBUS_HOST_NOTIFY,
};
+/**
+ * enum i2c_driver_flags - Flags for an I2C device driver
+ *
+ * @I2C_DRV_FL_ALLOW_LOW_POWER_PROBE: Let the ACPI driver manage the device's
+ * power state during probe and remove
+ */
+enum i2c_driver_flags {
+ I2C_DRV_FL_ALLOW_LOW_POWER_PROBE = BIT(0),
+};
+
/**
* struct i2c_driver - represent an I2C device driver
* @class: What kind of i2c device we instantiate (for detect)
@@ -231,6 +242,7 @@ enum i2c_alert_protocol {
* @detect: Callback for device detection
* @address_list: The I2C addresses to probe (for detect)
* @clients: List of detected clients we created (for i2c-core use only)
+ * @flags: A bitmask of flags defined in i2c_driver_flags
*
* The driver.owner field should be set to the module owner of this driver.
* The driver.name field should be set to the name of this driver.
@@ -289,6 +301,8 @@ struct i2c_driver {
int (*detect)(struct i2c_client *client, struct i2c_board_info *info);
const unsigned short *address_list;
struct list_head clients;
+
+ u32 flags;
};
#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
@@ -996,6 +1010,7 @@ u32 i2c_acpi_find_bus_speed(struct device *dev);
struct i2c_client *i2c_acpi_new_device(struct device *dev, int index,
struct i2c_board_info *info);
struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle);
+bool i2c_acpi_allow_low_power_probe(struct device *dev);
#else
static inline bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
struct acpi_resource_i2c_serialbus
**i2c)
@@ -1015,6 +1030,10 @@ static
[PATCH v10 1/7] ACPI: scan: Obtain device's desired enumeration power state
Store a device's desired enumeration power state in struct
acpi_device_power during acpi_device object's initialisation.
Signed-off-by: Sakari Ailus
---
drivers/acpi/scan.c | 4
include/acpi/acpi_bus.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 1d7a02ee45e05..cdff32f297122 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -987,6 +987,7 @@ static void acpi_bus_init_power_state(struct acpi_device
*device, int state)
static void acpi_bus_get_power_flags(struct acpi_device *device)
{
+ unsigned long long dse = ACPI_STATE_D0;
u32 i;
/* Presence of _PS0|_PR0 indicates 'power manageable' */
@@ -1008,6 +1009,9 @@ static void acpi_bus_get_power_flags(struct acpi_device
*device)
if (acpi_has_method(device->handle, "_DSW"))
device->power.flags.dsw_present = 1;
+ acpi_evaluate_integer(device->handle, "_DSE", NULL, );
+ device->power.state_for_enumeration = dse;
+
/*
* Enumerate supported power management states
*/
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 02a716a0af5d4..becfc9f57002b 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -276,6 +276,7 @@ struct acpi_device_power {
int state; /* Current state */
struct acpi_device_power_flags flags;
struct acpi_device_power_state states[ACPI_D_STATE_COUNT]; /*
Power states (D0-D3Cold) */
+ u8 state_for_enumeration; /* Maximum power state for enumeration */
};
/* Performance Management */
--
2.20.1
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >
> > On 01/02/2021 23:13, Ville Syrjälä wrote:
> > > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > >> From: Hans Verkuil
> > >>
> > >> For adapters behind an MST hub use the correct AUX channel.
> > >>
> > >> Signed-off-by: Hans Verkuil
> > >> [sa...@chromium.org: rebased, removing redundant changes]
> > >> Signed-off-by: Sam McNally
> > >> ---
> > >>
> > >> (no changes since v1)
> > >>
> > >> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> > >> 1 file changed, 36 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> b/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> index 15b6cc39a754..0d753201adbd 100644
> > >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> > >> drm_dp_mst_topology_mgr *mgr,
> > >> drm_dp_mst_topology_put_port(port);
> > >> }
> > >>
> > >> +static ssize_t
> > >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> > >> *msg);
> > >> +
> > >> static struct drm_dp_mst_port *
> > >> drm_dp_mst_add_port(struct drm_device *dev,
> > >> struct drm_dp_mst_topology_mgr *mgr,
> > >> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> > >> port->port_num = port_number;
> > >> port->mgr = mgr;
> > >> port->aux.name = "DPMST";
> > >> +mutex_init(>aux.hw_mutex);
> > >> +mutex_init(>aux.cec.lock);
> > >> port->aux.dev = dev->dev;
> > >> port->aux.is_remote = true;
> > >>
> > >> +port->aux.transfer = drm_dp_mst_aux_transfer;
> > >> +
> > >
> > > This was supposed to be handled via higher levels checking for
> > > is_remote==true.
> >
> > Ah, I suspect this patch can be dropped entirely: it predates commit
> > 2f221a5efed4
> > ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
> >
> > It looks like that commit basically solved what this older patch attempts
> > to do
> > as well.
> >
> > Sam, can you test if it works without this patch?
>
> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
> to filter out non-DP connectors. Using aux.is_remote as another signal
> indicating a DP connector seems plausible. We can drop this patch.
Why would anyone even call this stuff on a non-DP connector?
And where did they even get the struct drm_dp_aux to do so?
> Thanks all!
> >
> > Regards,
> >
> > Hans
> >
> > >
> > >> /* initialize the MST downstream port's AUX crc work queue */
> > >> drm_dp_remote_aux_init(>aux);
> > >>
> > >> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> > >> drm_dp_mst_topology_mgr *mgr,
> > >> return 0;
> > >> }
> > >>
> > >> +static ssize_t
> > >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> > >> *msg)
> > >> +{
> > >> +struct drm_dp_mst_port *port =
> > >> +container_of(aux, struct drm_dp_mst_port, aux);
> > >> +int ret;
> > >> +
> > >> +switch (msg->request & ~DP_AUX_I2C_MOT) {
> > >> +case DP_AUX_NATIVE_WRITE:
> > >> +case DP_AUX_I2C_WRITE:
> > >> +case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> > >> +ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> > >> + msg->size, msg->buffer);
> > >
> > > That doesn't make sense to me. I2c writes and DPCD writes
> > > are definitely not the same thing.
> > >
> > > aux->transfer is a very low level thing. I don't think it's the
> > > correct level of abstraction for sideband.
> > >
> > >> +break;
> > >> +
> > >> +case DP_AUX_NATIVE_READ:
> > >> +case DP_AUX_I2C_READ:
> > >> +ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> > >> +msg->size, msg->buffer);
> > >> +break;
> > >> +
> > >> +default:
> > >> +ret = -EINVAL;
> > >> +break;
> > >> +}
> > >> +
> > >> +return ret;
> > >> +}
> > >> +
> > >> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> > >> {
> > >> if (dp_link_bw == 0 || dp_link_count == 0)
> > >> --
> > >> 2.28.0.681.g6f77f65b4e-goog
> > >>
> > >> ___
> > >> dri-devel mailing list
> > >> dri-de...@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> >
--
Ville Syrjälä
Intel
Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip
On 2/4/21 9:01 PM, James Bottomley wrote: On Thu, 2021-02-04 at 20:44 -0500, Stefan Berger wrote: To clarify: When I tested this I had *both* patches applied. Without the patches I got the null pointer exception in tpm2_del_space(). The 2nd patch alone solves that issue when using the steps above. Yes, I can't confirm the bug either. I only have lpc tis devices, so it could be something to do with spi, but when I do I can confirm this bug: insmod /usr/lib/modules/5.10.0+/extra/tpm.ko ; insmod /usr/lib/modules/5.10.0+/extra/tpm_vtpm_proxy.ko swtpm chardev --vtpm-proxy --tpm2 --tpmstate dir=./ & exec 100<>/dev/tpmrm0 kill -9 rmmod tpm_vtpm_proxy echo -en '\x80\x01\x00\x00\x00\x0c\x00\x00\x01\x44\x00\x00' >&100 [ 167.289390] [c00015d6fb60] [c07d3ac0] refcount_warn_saturate+0x210/0x230 (unreliable) [ 167.290392] [c00015d6fbc0] [c0831328] kobject_put+0x1b8/0x2e0 [ 167.291398] [c00015d6fc50] [c0955548] put_device+0x28/0x40 [ 167.292409] [c00015d6fc70] [c008008609a8] tpm_try_get_ops+0xb0/0x100 [tpm] [ 167.293417] [c00015d6fcb0] [c00800861864] tpm_common_write+0x15c/0x250 [tpm] [ 167.294429] [c00015d6fd20] [c04be190] vfs_write+0xf0/0x380 [ 167.295437] [c00015d6fd70] [c04be6c8] ksys_write+0x78/0x130 [ 167.296450] [c00015d6fdc0] [c003377c] system_call_exception+0x15c/0x270 [ 167.297461] [c00015d6fe20] [c000d960] system_call_common+0xf0/0x27c With this patch applied this error here is gone. Just have make sure to replace tpm.ko and tpm_vtpm_proxy.ko, not just the latter. So my Tested-By is good for both patches. Stefan
Re: [PATCH net-next 1/7] net: ipa: restructure a few functions
On 2/4/21 10:50 PM, Jakub Kicinski wrote:
> On Wed, 3 Feb 2021 09:28:49 -0600 Alex Elder wrote:
>> Make __gsi_channel_start() and __gsi_channel_stop() more structurally
>> and semantically similar to each other:
>> - Restructure __gsi_channel_start() to always return at the end of
>> the function, similar to the way __gsi_channel_stop() does.
>> - Move the mutex calls out of gsi_channel_stop_retry() and into
>> __gsi_channel_stop().
>>
>> Restructure gsi_channel_stop() to always return at the end of the
>> function, like gsi_channel_start() does.
>>
>> Signed-off-by: Alex Elder
>> ---
>> drivers/net/ipa/gsi.c | 45 +++
>> 1 file changed, 24 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
>> index 53640447bf123..2671b76ebcfe3 100644
>> --- a/drivers/net/ipa/gsi.c
>> +++ b/drivers/net/ipa/gsi.c
>> @@ -873,17 +873,17 @@ static void gsi_channel_deprogram(struct gsi_channel
>> *channel)
>>
>> static int __gsi_channel_start(struct gsi_channel *channel, bool start)
>> {
>> -struct gsi *gsi = channel->gsi;
>> -int ret;
>> +int ret = 0;
>>
>> -if (!start)
>> -return 0;
>> +if (start) {
>> +struct gsi *gsi = channel->gsi;
>>
>> -mutex_lock(>mutex);
>> +mutex_lock(>mutex);
>>
>> -ret = gsi_channel_start_command(channel);
>> +ret = gsi_channel_start_command(channel);
>>
>> -mutex_unlock(>mutex);
>> +mutex_unlock(>mutex);
>> +}
>
> nit: I thought just recently Willem pointed out that keeping main flow
> unindented is considered good style, maybe it doesn't apply here
> perfectly, but I'd think it still applies. Why have the entire
> body of the function indented?
I *like* keeping the main flow un-indented (the way
it was).
It's a little funny, because one of my motivations for
doing it this way was how I interpreted the comment
from Willem (and echoed by you). He said, "...easier
to parse when the normal control flow is linear and
the error path takes a branch (or goto, if reused)."
And now that I read it again, I see that's what he
was saying.
But the way I interpreted it was "don't return early
for the success case," because that's what the code
in question that elicited that comment was doing.
In any case I concur with your comment and prefer the
code the other way. I will post v2 that will fix this,
both here and in __gsi_channel_start().
Thanks.
-Alex
>
>> return ret;
>> }
>> @@ -910,11 +910,8 @@ int gsi_channel_start(struct gsi *gsi, u32 channel_id)
>> static int gsi_channel_stop_retry(struct gsi_channel *channel)
>> {
>> u32 retries = GSI_CHANNEL_STOP_RETRIES;
>> -struct gsi *gsi = channel->gsi;
>> int ret;
>>
>> -mutex_lock(>mutex);
>> -
>> do {
>> ret = gsi_channel_stop_command(channel);
>> if (ret != -EAGAIN)
>> @@ -922,19 +919,26 @@ static int gsi_channel_stop_retry(struct gsi_channel
>> *channel)
>> usleep_range(3 * USEC_PER_MSEC, 5 * USEC_PER_MSEC);
>> } while (retries--);
>>
>> -mutex_unlock(>mutex);
>> -
>> return ret;
>> }
>>
>> static int __gsi_channel_stop(struct gsi_channel *channel, bool stop)
>> {
>> -int ret;
>> +int ret = 0;
>>
>> /* Wait for any underway transactions to complete before stopping. */
>> gsi_channel_trans_quiesce(channel);
>>
>> -ret = stop ? gsi_channel_stop_retry(channel) : 0;
>> +if (stop) {
>> +struct gsi *gsi = channel->gsi;
>> +
>> +mutex_lock(>mutex);
>> +
>> +ret = gsi_channel_stop_retry(channel);
>> +
>> +mutex_unlock(>mutex);
>> +}
>> +
>> /* Finally, ensure NAPI polling has finished. */
>> if (!ret)
>> napi_synchronize(>napi);
>> @@ -948,15 +952,14 @@ int gsi_channel_stop(struct gsi *gsi, u32 channel_id)
>> struct gsi_channel *channel = >channel[channel_id];
>> int ret;
>>
>> -/* Only disable the completion interrupt if stop is successful */
>> ret = __gsi_channel_stop(channel, true);
>> -if (ret)
>> -return ret;
>> +if (ret) {
>
> This inverts the logic, right? Is it intentional?
>
>> +/* Disable the completion interrupt and NAPI if successful */
>> +gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id);
>> +napi_disable(>napi);
>> +}
>>
>> -gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id);
>> -napi_disable(>napi);
>> -
>> -return 0;
>> +return ret;
>> }
>>
>> /* Reset and reconfigure a channel, (possibly) enabling the doorbell engine
>> */
>
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On 05/02/2021 14:24, Ville Syrjälä wrote:
> On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
>> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
>>>
>>> On 01/02/2021 23:13, Ville Syrjälä wrote:
On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> From: Hans Verkuil
>
> For adapters behind an MST hub use the correct AUX channel.
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org: rebased, removing redundant changes]
> Signed-off-by: Sam McNally
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 15b6cc39a754..0d753201adbd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> drm_dp_mst_topology_mgr *mgr,
> drm_dp_mst_topology_put_port(port);
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> *msg);
> +
> static struct drm_dp_mst_port *
> drm_dp_mst_add_port(struct drm_device *dev,
> struct drm_dp_mst_topology_mgr *mgr,
> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> port->port_num = port_number;
> port->mgr = mgr;
> port->aux.name = "DPMST";
> +mutex_init(>aux.hw_mutex);
> +mutex_init(>aux.cec.lock);
> port->aux.dev = dev->dev;
> port->aux.is_remote = true;
>
> +port->aux.transfer = drm_dp_mst_aux_transfer;
> +
This was supposed to be handled via higher levels checking for
is_remote==true.
>>>
>>> Ah, I suspect this patch can be dropped entirely: it predates commit
>>> 2f221a5efed4
>>> ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
>>>
>>> It looks like that commit basically solved what this older patch attempts
>>> to do
>>> as well.
>>>
>>> Sam, can you test if it works without this patch?
>>
>> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
>> to filter out non-DP connectors. Using aux.is_remote as another signal
>> indicating a DP connector seems plausible. We can drop this patch.
>
> Why would anyone even call this stuff on a non-DP connector?
> And where did they even get the struct drm_dp_aux to do so?
This check came in with commit 5ce70c799ac2 ("drm_dp_cec: check that aux
has a transfer function"). It seems nouveau and amdgpu specific.
A better approach would be to fix those drivers to only call these cec
functions for DP outputs. I think I moved the test to drm_dp_cec.c primarily
for robustness (i.e. do nothing if called for a non-DP output). But that
might not be the right approach after all.
Regards,
Hans
>
>> Thanks all!
>>>
>>> Regards,
>>>
>>> Hans
>>>
> /* initialize the MST downstream port's AUX crc work queue */
> drm_dp_remote_aux_init(>aux);
>
> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> return 0;
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> *msg)
> +{
> +struct drm_dp_mst_port *port =
> +container_of(aux, struct drm_dp_mst_port, aux);
> +int ret;
> +
> +switch (msg->request & ~DP_AUX_I2C_MOT) {
> +case DP_AUX_NATIVE_WRITE:
> +case DP_AUX_I2C_WRITE:
> +case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> + msg->size, msg->buffer);
That doesn't make sense to me. I2c writes and DPCD writes
are definitely not the same thing.
aux->transfer is a very low level thing. I don't think it's the
correct level of abstraction for sideband.
> +break;
> +
> +case DP_AUX_NATIVE_READ:
> +case DP_AUX_I2C_READ:
> +ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> +msg->size, msg->buffer);
> +break;
> +
> +default:
> +ret = -EINVAL;
> +break;
> +}
> +
> +return ret;
> +}
> +
> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> {
> if (dp_link_bw == 0 || dp_link_count == 0)
> --
> 2.28.0.681.g6f77f65b4e-goog
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>
Re: [PATCH 1/8] spi: stm32: properly handle 0 byte transfer
On Fri, Feb 05, 2021 at 12:08:55PM +0100, Alain Volmat wrote:
> On 0 byte transfer request, return straight from the
> xfer function after finalizing the transfer.
> + if (transfer->len == 0) {
> + spi_finalize_current_transfer(master);
> + return 0;
The driver only needs to finalize the transfer if it returned a value
greater than 0, returning 0 indicates that the transfer is already done.
signature.asc
Description: PGP signature
[PATCH v10 3/7] Documentation: ACPI: Document _DSE object usage for enum power state
Document the use of the _DSE object for setting desirable power state
during probe.
Signed-off-by: Sakari Ailus
Reviewed-by: Tomasz Figa
---
Documentation/firmware-guide/acpi/index.rst | 1 +
.../firmware-guide/acpi/low-power-probe.rst | 69 +++
2 files changed, 70 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/low-power-probe.rst
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index f72b5f1769fb2..d02712acccbc0 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -25,5 +25,6 @@ ACPI Support
acpi-lid
lpit
video_extension
+ low-power-probe
extcon-intel-int3496
intel-pmc-mux
diff --git a/Documentation/firmware-guide/acpi/low-power-probe.rst
b/Documentation/firmware-guide/acpi/low-power-probe.rst
new file mode 100644
index 0..b96804d959a6c
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/low-power-probe.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Probing I²C devices in low power state
+==
+
+Introduction
+
+
+In some cases it may be preferred to leave certain devices powered off for the
+entire system bootup if powering on these devices has adverse side effects,
+beyond just powering on the said device.
+
+How it works
+
+
+The _DSE (Device State for Enumeration) object that evaluates to integer 0 may
+be used to tell Linux the highest allowed D state for a device during probe. If
+the driver indicates its support for this by setting the
+I2C_DRV_FL_ALLOW_LOW_POWER_PROBE flag in struct i2c_driver.flags field and the
+_DSE object evaluates to integer higher than the D state of the device, the
+device will not be powered on (put in D0 state) for probe.
+
+The D states and thus also the allowed values for _DSE are listed below. Refer
+to [1] for more information on device power states.
+
+.. code-block:: text
+
+ Number State Description
+ 0 D0 Device fully powered on
+ 1 D1
+ 2 D2
+ 3 D3hot
+ 4 D3cold Off
+
+The downside is that as the device is not powered on, even if there's a problem
+with the device, the driver likely probes just fine but the first user will
+find out the device doesn't work, instead of a failure at probe time. This
+feature should thus be used sparingly.
+
+References
+==
+
+[1]
https://uefi.org/specifications/ACPI/6.4/02_Definition_of_Terms/Definition_of_Terms.html#device-power-state-definitions
+
+Example
+===
+
+An ASL example describing an ACPI device using _DSE object to tell Operating
+System the device should remain powered off during probe looks like this. Some
+objects not relevant from the example point of view have been omitted.
+
+.. code-block:: text
+
+ Device (CAM0)
+{
+ Name (_HID, "SONY319A")
+ Name (_UID, Zero)
+ Name (_CRS, ResourceTemplate ()
+ {
+ I2cSerialBus(0x0020, ControllerInitiated, 0x00061A80,
+AddressingMode7Bit, "\\_SB.PCI0.I2C0",
+0x00, ResourceConsumer)
+ })
+ Name (_DSE, 0, NotSerialized)
+ {
+ Return (0x4)
+}
+ }
--
2.20.1
[PATCH] soc: renesas: rmobile-sysc: Set OF_POPULATED and absorb reset handling
Currently, there are two drivers binding to the R-Mobile System
Controller (SYSC):
- The rmobile-sysc driver registers PM domains from a core_initcall(),
and does not use a platform driver,
- The rmobile-reset driver registers a reset handler, and does use a
platform driver.
As fw_devlink only considers devices, it does not know that the
rmobile-sysc driver is ready. Hence if fw_devlink is enabled, probing
of on-chip devices that are part of the SYSC PM domain is deferred until
the optional rmobile-reset has been bound, which may happen too late
(for e.g. the system timer on SoCs lacking an ARM architectured or
global timer), or not at all, leading to complete system boot failures.
Fix this by:
1. Setting the OF_POPULATED flag for the SYSC device node after
successful initialization.
This will make of_link_to_phandle() ignore the SYSC device node as
a dependency, making consumer devices probe again.
2. Move reset handling from its own driver into the rmobile-sysc
driver.
This is needed because setting OF_POPULATED prevents the
rmobile-reset driver from binding against the same device.
Signed-off-by: Geert Uytterhoeven
---
To be queued in renesas-devel for v5.13.
Tested on:
- SH-Mobile AG5 (KZM-A9-GT),
- R-Mobile APE6 (APE6-EVM),
- R-Mobile A1 (Armadillo-800 EVA).
drivers/power/reset/Kconfig | 7 ---
drivers/power/reset/Makefile| 1 -
drivers/power/reset/rmobile-reset.c | 88 -
drivers/soc/renesas/rmobile-sysc.c | 65 -
4 files changed, 64 insertions(+), 97 deletions(-)
delete mode 100644 drivers/power/reset/rmobile-reset.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1737e227b16e5136..417b112be3f660de 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -251,13 +251,6 @@ config POWER_RESET_SYSCON_POWEROFF
help
Poweroff support for generic SYSCON mapped register poweroff.
-config POWER_RESET_RMOBILE
- tristate "Renesas R-Mobile reset driver"
- depends on ARCH_RMOBILE || COMPILE_TEST
- depends on HAS_IOMEM
- help
- Reboot support for Renesas R-Mobile and SH-Mobile SoCs.
-
config POWER_RESET_ZX
tristate "ZTE SoCs reset driver"
depends on ARCH_ZX || COMPILE_TEST
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index b4601c0a96ed26c7..77a57ca8e5300d60 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -29,7 +29,6 @@ obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
obj-$(CONFIG_POWER_RESET_SYSCON_POWEROFF) += syscon-poweroff.o
-obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
diff --git a/drivers/power/reset/rmobile-reset.c
b/drivers/power/reset/rmobile-reset.c
deleted file mode 100644
index bd3b396558e0df8c..
--- a/drivers/power/reset/rmobile-reset.c
+++ /dev/null
@@ -1,88 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Renesas R-Mobile Reset Driver
- *
- * Copyright (C) 2014 Glider bvba
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-/* SYSC Register Bank 2 */
-#define RESCNT20x20/* Reset Control Register 2 */
-
-/* Reset Control Register 2 */
-#define RESCNT2_PRES 0x8000 /* Soft power-on reset */
-
-static void __iomem *sysc_base2;
-
-static int rmobile_reset_handler(struct notifier_block *this,
-unsigned long mode, void *cmd)
-{
- pr_debug("%s %lu\n", __func__, mode);
-
- /* Let's assume we have acquired the HPB semaphore */
- writel(RESCNT2_PRES, sysc_base2 + RESCNT2);
-
- return NOTIFY_DONE;
-}
-
-static struct notifier_block rmobile_reset_nb = {
- .notifier_call = rmobile_reset_handler,
- .priority = 192,
-};
-
-static int rmobile_reset_probe(struct platform_device *pdev)
-{
- int error;
-
- sysc_base2 = of_iomap(pdev->dev.of_node, 1);
- if (!sysc_base2)
- return -ENODEV;
-
- error = register_restart_handler(_reset_nb);
- if (error) {
- dev_err(>dev,
- "cannot register restart handler (err=%d)\n", error);
- goto fail_unmap;
- }
-
- return 0;
-
-fail_unmap:
- iounmap(sysc_base2);
- return error;
-}
-
-static int rmobile_reset_remove(struct platform_device *pdev)
-{
- unregister_restart_handler(_reset_nb);
- iounmap(sysc_base2);
- return 0;
-}
-
-static const struct of_device_id rmobile_reset_of_match[] = {
- { .compatible = "renesas,sysc-rmobile", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, rmobile_reset_of_match);
-
-static
Re: [PATCH] drivers: mtd: Better word replace a not so good word in the file mtd_blkdevs.c
On 14:26 Fri 05 Feb 2021, Miquel Raynal wrote: Hi Bhaskar, Bhaskar Chowdhury wrote on Fri, 5 Feb 2021 18:11:51 +0530: s/fucking/invite/ Signed-off-by: Bhaskar Chowdhury --- drivers/mtd/mtd_blkdevs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index fb8e12d590a1..756a0995e474 100644 --- a/drivers/mtd/mtd_blkdevs.c +++ b/drivers/mtd/mtd_blkdevs.c @@ -523,7 +523,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *tr) int ret; /* Register the notifier if/when the first device type is - registered, to prevent the link/init ordering from fucking + registered, to prevent the link/init ordering from invite us over. */ invite us over? I'm not a native English speaker but this does not bring any value to my ears. Worse, I don't even get the point. Better rewrite the comment entirely than just swapping "fucking" with a random word, no? Got your point , and I do understand "fuck" and "fucking" is so strong word that it is really difficult to replace with something else. But..but you suggestion to rewrite the comments sounds good Miquel ...wish I could have that much time in hand to replace every sentence having that word ...all the patched sent with that word replaces...please step forward and make and send patches . Today I sent 10 patches replacing that word(weather that make sense or not) you can see those in the ML ...please pick up as you wish and send patches. I was simply replacing the word ..never bother about the meaning it conveys..doesn't matter really. so... Thanks. Thanks, Miquèl signature.asc Description: PGP signature
[PATCH] PCI: Also set up legacy files only after sysfs init
We are already doing this for all the regular sysfs files on PCI
devices, but not yet on the legacy io files on the PCI buses. Thus far
no problem, but in the next patch I want to wire up iomem revoke
support. That needs the vfs up and running already to make sure that
iomem_get_mapping() works.
Wire it up exactly like the existing code in
pci_create_sysfs_dev_files(). Note that pci_remove_legacy_files()
doesn't need a check since the one for pci_bus->legacy_io is
sufficient.
An alternative solution would be to implement a callback in sysfs to
set up the address space from iomem_get_mapping() when userspace calls
mmap(). This also works, but Greg didn't really like that just to work
around an ordering issue when the kernel loads initially.
v2: Improve commit message (Bjorn)
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/pci/pci-sysfs.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index fb072f4b3176..0c45b4f7b214 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
{
int error;
+ if (!sysfs_initialized)
+ return;
+
b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
GFP_ATOMIC);
if (!b->legacy_io)
@@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
static int __init pci_sysfs_init(void)
{
struct pci_dev *pdev = NULL;
+ struct pci_bus *pbus = NULL;
int retval;
sysfs_initialized = 1;
@@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
}
}
+ while ((pbus = pci_find_next_bus(pbus)))
+ pci_create_legacy_files(pbus);
+
return 0;
}
late_initcall(pci_sysfs_init);
--
2.30.0
Re: Old platforms: bring out your dead
From: Arnd Bergmann
Date: Fri, 8 Jan 2021 23:55:06 +0100
> After v5.10 was officially declared an LTS kernel, I had a look around
> the Arm platforms that look like they have not seen any patches from
> their maintainers or users that are actually running the hardware for
> at least five years (2015 or earlier). I made some statistics and lists
> for my lwn.net article last year [1], so I'd thought I'd share a summary
> here for discussion about what we should remove. As I found three
> years ago when I removed several CPU architectures, it makes sense
> to do this in bulk, to simplify a scripted search for device drivers, header
> files and Kconfig options that become unused in the process.
>
> This is probably a mix of platforms that are completely unused and
> those that just work, but I have no good way of knowing which one
> it is. Without hearing back about these, I'd propose removing all of
> these:
>
> * asm9260 -- added in 2014, no notable changes after 2015
> * axxia -- added in 2014, no notable changes after 2015
> * bcm/kona -- added in 2013, no notable changes after 2014
> * digicolor -- added in 2014, no notable changes after 2015
> * dove -- added in 2009, obsoleted by mach-mvebu in 2015
> * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
> * nspire -- added in 2013, no notable changes after 2015
> * picoxcell -- added in 2011, already queued for removal
> * prima2 -- added in 20111, no notable changes since 2015
> * spear -- added in 2010, no notable changes since 2015
> * tango -- added in 2015, sporadic changes until 2017, but abandoned
> * u300 -- added in 2009, no notable changes since 2013
> * vt8500 -- added in 2010, no notable changes since 2014
> * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
>
> If any of the above are not dead yet[2], please let me know,
> and we'll keep them.
>
> Then there are ARM platforms that are old but have still seen some work
> in the past years. If I hear nothing, these will all stay, but if maintainers
> may want to drop them anyway, I can help with that:
>
> * clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
> changes since
> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> * ep93xx -- added in 2006, LinusW still working on it, any users left?
> * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have
> one
> * gemini -- added in 2009, LinusW still working on it
> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
> * highbank -- added in 2011, no changes after 2015, but Andre still uses it
> * iop32x -- added in 2006, no notable changes other than my cleanup, but
> I think there are still users
> * ixp4xx -- prehistoric, but LinusW and I are still working on it
> * lpc18xx -- added in 2015, new dts in 2018, but few other changes
> * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
> * mmp -- added in 2009, DT support is active, but board files might go
> * moxart -- added in 2013, last Tested-by in 2017
> * mv78xx0 -- added in 2008, mostly stale but still users
> (https://github.com/101101000/Debian_on_Buffalo)
> * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
> * oxnas -- added in 2016, but already old then, few changes later
> * pxa -- prehistoric, but a few boards may still have users
> * rpc -- prehistoric, but I think Russell still uses his machine
> * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
>
> I also looked at non-ARM platforms while preparing for my article. Some of
> these look like they are no longer actively maintained or used, but I'm not
> doing anything about those unless the maintainers would like me to:
>
> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>or fixed in 2020 with no reply. This was killed before in 2013, added back
>in 2015 but has been mostly stale again since 2016
> * c6x: Added in 2011, this has seen very few updates since, but
> Mark still Acks patches when they come. Like most other DSP platforms,
> the model of running Linux on a DSP appears to have been obsoleted
> by using Linux on ARM with on-chip DSP cores running bare-metal code.
> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>is currently under review
> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove
> it.
>it's in my backlog but I will get to it. This is separate from PS3,
> which is actively
>maintained and used; spufs will move to ps3
> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
> * powerpc/amigaone: last updated in 2009
> * powerpc/maple: last updated in 2011
> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>seen updates in many years (atari/amiga/mac and coldfire are very much
>alive)
> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010
>
> There might be
Re: [PATCH] mtd: spi-nor: Get rid of duplicated argument in spi_nor_parse_sfdp()
On 04/02/21 07:45PM, Tudor Ambarus wrote:
> spi_nor_parse_sfdp(nor, nor->params);
> passes for the second argument a member within the first argument.
> Drop the second argument and obtain it directly from the first,
> and do it across all the children functions. This is a follow up for
> 'commit 69a8eed58cc0 ("mtd: spi-nor: Don't copy self-pointing struct around")'
>
> Signed-off-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/core.c | 10 ++--
> drivers/mtd/spi-nor/core.h | 6 +--
> drivers/mtd/spi-nor/issi.c | 3 +-
> drivers/mtd/spi-nor/macronix.c | 3 +-
> drivers/mtd/spi-nor/sfdp.c | 87 +-
> drivers/mtd/spi-nor/sfdp.h | 3 +-
> drivers/mtd/spi-nor/spansion.c | 12 ++---
> drivers/mtd/spi-nor/winbond.c | 3 +-
> 8 files changed, 49 insertions(+), 78 deletions(-)
>
[...]
> @@ -945,13 +935,11 @@ static int spi_nor_parse_smpt(struct spi_nor *nor,
> * @nor: pointer to a 'struct spi_nor'.
> * @param_header:pointer to the 'struct sfdp_parameter_header' describing
> * the 4-Byte Address Instruction Table length and version.
> - * @params: pointer to the 'struct spi_nor_flash_parameter' to be.
> *
> * Return: 0 on success, -errno otherwise.
> */
> static int spi_nor_parse_4bait(struct spi_nor *nor,
> -const struct sfdp_parameter_header *param_header,
> -struct spi_nor_flash_parameter *params)
> +const struct sfdp_parameter_header *param_header)
> {
> static const struct sfdp_4bait reads[] = {
> { SNOR_HWCAPS_READ, BIT(0) },
> @@ -975,8 +963,8 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
> { 0u /* not used */,BIT(11) },
> { 0u /* not used */,BIT(12) },
> };
> - struct spi_nor_pp_command *params_pp = params->page_programs;
> - struct spi_nor_erase_map *map = >erase_map;
> + struct spi_nor_pp_command *params_pp = nor->params->page_programs;
> + struct spi_nor_erase_map *map = >params->erase_map;
> struct spi_nor_erase_type *erase_type = map->erase_type;
> u32 *dwords;
> size_t len;
> @@ -1013,7 +1001,7 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
> const struct sfdp_4bait *read = [i];
>
> discard_hwcaps |= read->hwcaps;
> - if ((params->hwcaps.mask & read->hwcaps) &&
> + if ((nor->params->hwcaps.mask & read->hwcaps) &&
> (dwords[0] & read->supported_bit))
> read_hwcaps |= read->hwcaps;
> }
> @@ -1029,8 +1017,8 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
> /*
>* The 4 Byte Address Instruction (Optional) Table is the only
>* SFDP table that indicates support for Page Program Commands.
> - * Bypass the params->hwcaps.mask and consider 4BAIT the biggest
> - * authority for specifying Page Program support.
> + * Bypass the nor->params->hwcaps.mask and consider 4BAIT the
> + * biggest authority for specifying Page Program support.
>*/
> discard_hwcaps |= program->hwcaps;
> if (dwords[0] & program->supported_bit)
> @@ -1064,12 +1052,12 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
>* Discard all operations from the 4-byte instruction set which are
>* not supported by this memory.
>*/
> - params->hwcaps.mask &= ~discard_hwcaps;
> - params->hwcaps.mask |= (read_hwcaps | pp_hwcaps);
> + nor->params->hwcaps.mask &= ~discard_hwcaps;
> + nor->params->hwcaps.mask |= (read_hwcaps | pp_hwcaps);
>
> /* Use the 4-byte address instruction set. */
> for (i = 0; i < SNOR_CMD_READ_MAX; i++) {
> - struct spi_nor_read_command *read_cmd = >reads[i];
> + struct spi_nor_read_command *read_cmd = >params->reads[i];
Nitpick: 'nor->params' is used in multiple places in this function.
Might be worth it to make it a local variable.
Either way,
Reviewed-by: Pratyush Yadav
>
> read_cmd->opcode = spi_nor_convert_3to4_read(read_cmd->opcode);
> }
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
[PATCH 3/4] thermal: ti-soc-thermal: Simplify polling with iopoll
We can use iopoll for checking the EOCZ (end of conversion) bit. And with
this we now also want to handle the timeout errors properly.
For omap3, we need about 1.2ms for the single mode sampling to wait for
EOCZ down, so let's use 1.5ms timeout there. Waiting for sampling to start
is faster and we can use 1ms timeout.
Cc: Adam Ford
Cc: Carl Philipp Klemm
Cc: Eduardo Valentin
Cc: H. Nikolaus Schaller
Cc: Merlijn Wajer
Cc: Pavel Machek
Cc: Peter Ujfalusi
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 30 ++---
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -27,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -604,7 +604,9 @@ static int
ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
{
struct temp_sensor_registers *tsr = bgp->conf->sensors[id].registers;
- u32 counter;
+ void __iomem *temp_sensor_ctrl = bgp->base + tsr->temp_sensor_ctrl;
+ int error;
+ u32 val;
/* Select continuous or single conversion mode */
if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
@@ -619,26 +621,22 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int
id)
RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
/* Wait for EOCZ going up */
- counter = 1000;
- while (--counter) {
- if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
- tsr->bgap_eocz_mask)
- break;
- udelay(1);
- }
+ error = readl_poll_timeout_atomic(temp_sensor_ctrl, val,
+ val & tsr->bgap_eocz_mask,
+ 1, 1000);
+ if (error)
+ dev_warn(bgp->dev, "eocz timed out waiting high\n");
/* Clear Start of Conversion if available */
RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
}
/* Wait for EOCZ going down, always needed even if no bgap_soc_mask */
- counter = 1000;
- while (--counter) {
- if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
- tsr->bgap_eocz_mask))
- break;
- udelay(1);
- }
+ error = readl_poll_timeout_atomic(temp_sensor_ctrl, val,
+ !(val & tsr->bgap_eocz_mask),
+ 1, 1500);
+ if (error)
+ dev_warn(bgp->dev, "eocz timed out waiting low\n");
return 0;
}
--
2.30.0
[PATCH 4/4] thermal: ti-soc-thermal: Use non-inverted define for omap4
When we set bit 10 high we use continuous mode and not single
mode. Let's correct this to avoid confusion. No functional
changes here, the code does the right thing with bit 10.
Cc: Adam Ford
Cc: Carl Philipp Klemm
Cc: Eduardo Valentin
Cc: H. Nikolaus Schaller
Cc: Merlijn Wajer
Cc: Pavel Machek
Cc: Peter Ujfalusi
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 4 ++--
drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
--- a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
@@ -24,7 +24,7 @@ omap4430_mpu_temp_sensor_registers = {
.bgap_dtemp_mask = OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK,
.bgap_mode_ctrl = OMAP4430_TEMP_SENSOR_CTRL_OFFSET,
- .mode_ctrl_mask = OMAP4430_SINGLE_MODE_MASK,
+ .mode_ctrl_mask = OMAP4430_CONTINUOUS_MODE_MASK,
.bgap_efuse = OMAP4430_FUSE_OPP_BGAP,
};
@@ -97,7 +97,7 @@ omap4460_mpu_temp_sensor_registers = {
.mask_cold_mask = OMAP4460_MASK_COLD_MASK,
.bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
- .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK,
+ .mode_ctrl_mask = OMAP4460_CONTINUOUS_MODE_MASK,
.bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET,
.counter_mask = OMAP4460_COUNTER_MASK,
diff --git a/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h
b/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h
--- a/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h
@@ -40,7 +40,7 @@
/* OMAP4430.TEMP_SENSOR bits */
#define OMAP4430_BGAP_TEMPSOFF_MASKBIT(12)
#define OMAP4430_BGAP_TSHUT_MASK BIT(11)
-#define OMAP4430_SINGLE_MODE_MASK BIT(10)
+#define OMAP4430_CONTINUOUS_MODE_MASK BIT(10)
#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK BIT(9)
#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(8)
#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff << 0)
@@ -113,7 +113,7 @@
#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff << 0)
/* OMAP4460.BANDGAP_CTRL bits */
-#define OMAP4460_SINGLE_MODE_MASK BIT(31)
+#define OMAP4460_CONTINUOUS_MODE_MASK BIT(31)
#define OMAP4460_MASK_HOT_MASK BIT(1)
#define OMAP4460_MASK_COLD_MASKBIT(0)
--
2.30.0
MESSAGE
Hello My Dear Friend,
How are you and your family? I hope everybody is fine. I am happy to
inform you that I later by the grace of God completed the transaction
successfully with another partner.
The total fund was transferred to the new partner that I presented to
the bank. Now I am outside my country due to the urgency of my son's
kidney transplant and for an investment project with my partner.
However, I did not forget your past efforts and assistance to me to
see that the funds was approved with the bank, So, I have given to my
secretary an ATM CARD that contains the sum of usd $ 350,000.00
Please, accept this token of appreciation and God blessed you.
Below are the contact details of my secretary where I deposited your
compensation fund worth usd $ 350,000.00 contact Mrs. Chiquita Labello
immediately you receive my message to allow them to transfer it to
you.
Contact information.
Name: Chiquita Labello
Email Address: chiquitalabe...@yahoo.com
Telephone: +228 93 23 23 61
You should contact the bank at your earliest convenience so that the
fund can be sent to you, so that you can withdraw from your bank in
your country.
I wish you the best in all your future endeavors. I will also call you
at my earliest convenient.
Your partner,
NB: Remember to put this 10- lettered word ("GRACE-77113") as the
subject of your email so that the bank will know that you are the
rightful beneficiary of the compensation fund.
Mr. Alidou Alasane
[PATCH 1/4] thermal: ti-soc-thermal: Skip pointless register access for dra7
On dra7, there is no Start of Conversion (SOC) register bit and we have an
empty bgap_soc_mask in the configuration for the thermal driver. Let's not
do pointless reads and writes with the empty mask.
There's also no point waiting for End of Conversion bit (EOCZ) to go high
on dra7. We only care about it going down, and are now mostly timing out
waiting for EOCZ high while it has already gone down.
When we add checking for the timeout errors in a later patch, waiting for
EOCZ high would cause bogus time out errors.
Cc: Adam Ford
Cc: Carl Philipp Klemm
Cc: Eduardo Valentin
Cc: H. Nikolaus Schaller
Cc: Merlijn Wajer
Cc: Pavel Machek
Cc: Peter Ujfalusi
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -602,29 +602,30 @@ void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp,
int id)
static int
ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
{
- u32 counter = 1000;
- struct temp_sensor_registers *tsr;
+ struct temp_sensor_registers *tsr = bgp->conf->sensors[id].registers;
+ u32 counter;
/* Select single conversion mode */
if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0);
- /* Start of Conversion = 1 */
- RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
+ /* Set Start of Conversion if available */
+ if (tsr->bgap_soc_mask) {
+ RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
- /* Wait for EOCZ going up */
- tsr = bgp->conf->sensors[id].registers;
+ /* Wait for EOCZ going up */
+ counter = 1000;
+ while (--counter) {
+ if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
+ tsr->bgap_eocz_mask)
+ break;
+ }
- while (--counter) {
- if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
- tsr->bgap_eocz_mask)
- break;
+ /* Clear Start of Conversion if available */
+ RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
}
- /* Start of Conversion = 0 */
- RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
-
- /* Wait for EOCZ going down */
+ /* Wait for EOCZ going down, always needed even if no bgap_soc_mask */
counter = 1000;
while (--counter) {
if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
--
2.30.0
Re: [PATCH v2 2/7] coresight: etm-perf: Support PID tracing for kernel at EL2
On Tue, 2 Feb 2021 at 23:06, Suzuki K Poulose wrote: > > On 2/2/21 4:38 PM, Leo Yan wrote: > > From: Suzuki K Poulose > > > > When the kernel is running at EL2, the PID is stored in CONTEXTIDR_EL2. > > So, tracing CONTEXTIDR_EL1 doesn't give us the pid of the process. > > Thus we should trace the VMID with VMIDOPT set to trace CONTEXTIDR_EL2 > > instead of CONTEXTIDR_EL1. Given that we have an existing config > > option "contextid" and this will be useful for tracing virtual machines > > (when we get to support virtualization). > > > > So instead, this patch extends option CTXTID with an extra bit > > ETM_OPT_CTXTID2 (bit 15), thus on an EL2 kernel, we will have another > > bit available for the perf tool: ETM_OPT_CTXTID is for kernel running in > > EL1, ETM_OPT_CTXTID2 is used when kernel runs in EL2 with VHE enabled. > > > > The tool must be backward compatible for users, i.e, "contextid" today > > traces PID and that should remain the same; for this purpose, the perf > > tool is updated to automatically set corresponding bit for the > > "contextid" config, therefore, the user doesn't have to bother which EL > > the kernel is running. > > > >i.e, perf record -e cs_etm/contextid/u -- > > > > will always do the "pid" tracing, independent of the kernel EL. > > > > The driver parses the format "contextid", which traces CONTEXTIDR_EL1 > > for ETM_OPT_CTXTID (on EL1 kernel) and traces CONTEXTIDR_EL2 for > > ETM_OPT_CTXTID2 (on EL2 kernel). > > > > Besides the enhancement for format "contexid", extra two formats are > > introduced: "contextid1" and "contextid2". This considers to support > > tracing both CONTEXTIDR_EL1 and CONTEXTIDR_EL2 when the kernel is > > running at EL2. Finally, the PMU formats are defined as follow: > > > >"contextid1": Available on both EL1 kernel and EL2 kernel. When the > > kernel is running at EL1, "contextid1" enables the PID > > tracing; when the kernel is running at EL2, this enables > > tracing the PID of guest applications. > > > >"contextid2": Only usable when the kernel is running at EL2. When > > selected, enables PID tracing on EL2 kernel. > > > >"contextid": Will be an alias for the option that enables PID > > tracing. I.e, > > contextid == contextid1, on EL1 kernel. > > contextid == contextid2, on EL2 kernel. > > > > Cc: Mathieu Poirier > > Cc: Al Grant > > Cc: Mike Leach > > Cc: Leo Yan > > Signed-off-by: Suzuki K Poulose > > You may add the following line here : > > [ Added two config formats: contextid1, contextid2 ] > > > Signed-off-by: Leo Yan > > The patch as such looks good to me. > > Suzuki Reviewed-by: Mike Leach -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
Re: [patch 03/12] x86/irq/64: Adjust the per CPU irq stack pointer by 8
On Thu, Feb 04, 2021 at 09:49:06PM +0100, Thomas Gleixner wrote: > Move the definition > next to the inuse flag so they end up in the same cache line. > -DEFINE_PER_CPU(struct irq_stack *, hardirq_stack_ptr); > +DEFINE_PER_CPU(void *, hardirq_stack_ptr); > DEFINE_PER_CPU(bool, hardirq_stack_inuse); Not strictly guaranteed they end up in the same line. If you stick them in a struct and force alignment on the instance you'll have better guarantees.
Re: [PATCH v2 4/7] perf cs-etm: Support PID tracing in config
On Tue, 2 Feb 2021 at 16:39, Leo Yan wrote:
>
> From: Suzuki K Poulose
>
> If the kernel is running at EL2, the pid of a task is exposed via VMID
> instead of the CONTEXTID. Add support for this in the perf tool.
>
> This patch respects user setting if user has specified any configs
> from "contextid", "contextid1" or "contextid2"; otherwise, it
> dynamically sets config based on PMU format "contextid".
>
> Cc: Mike Leach
> Cc: Mathieu Poirier
> Cc: Al Grant
> Co-developed-by: Leo Yan
> Signed-off-by: Suzuki K Poulose
> Signed-off-by: Leo Yan
> ---
> tools/include/linux/coresight-pmu.h | 3 ++
> tools/perf/arch/arm/util/cs-etm.c | 61 +++--
> 2 files changed, 52 insertions(+), 12 deletions(-)
>
> diff --git a/tools/include/linux/coresight-pmu.h
> b/tools/include/linux/coresight-pmu.h
> index 5dc47cfdcf07..4ac5c081af93 100644
> --- a/tools/include/linux/coresight-pmu.h
> +++ b/tools/include/linux/coresight-pmu.h
> @@ -20,14 +20,17 @@
> */
> #define ETM_OPT_CYCACC 12
> #define ETM_OPT_CTXTID 14
> +#define ETM_OPT_CTXTID215
> #define ETM_OPT_TS 28
> #define ETM_OPT_RETSTK 29
>
> /* ETMv4 CONFIGR programming bits for the ETM OPTs */
> #define ETM4_CFG_BIT_CYCACC4
> #define ETM4_CFG_BIT_CTXTID6
> +#define ETM4_CFG_BIT_VMID 7
> #define ETM4_CFG_BIT_TS11
> #define ETM4_CFG_BIT_RETSTK12
> +#define ETM4_CFG_BIT_VMID_OPT 15
>
> static inline int coresight_get_trace_id(int cpu)
> {
> diff --git a/tools/perf/arch/arm/util/cs-etm.c
> b/tools/perf/arch/arm/util/cs-etm.c
> index c25c878fd06c..fa6f91a7c8a1 100644
> --- a/tools/perf/arch/arm/util/cs-etm.c
> +++ b/tools/perf/arch/arm/util/cs-etm.c
> @@ -67,6 +67,7 @@ static int cs_etm_set_context_id(struct auxtrace_record
> *itr,
> char path[PATH_MAX];
> int err = -EINVAL;
> u32 val;
> + u64 contextid;
>
> ptr = container_of(itr, struct cs_etm_recording, itr);
> cs_etm_pmu = ptr->cs_etm_pmu;
> @@ -86,25 +87,59 @@ static int cs_etm_set_context_id(struct auxtrace_record
> *itr,
> goto out;
> }
>
> + /* User has configured for PID tracing, respects it. */
> + contextid = evsel->core.attr.config &
> + (BIT(ETM_OPT_CTXTID) | BIT(ETM_OPT_CTXTID2));
> +
> /*
> -* TRCIDR2.CIDSIZE, bit [9-5], indicates whether contextID tracing
> -* is supported:
> -* 0b0 Context ID tracing is not supported.
> -* 0b00100 Maximum of 32-bit Context ID size.
> -* All other values are reserved.
> +* If user doesn't configure the contextid format, parse PMU format
> and
> +* enable PID tracing according to the "contextid" format bits:
> +*
> +* If bit ETM_OPT_CTXTID is set, trace CONTEXTIDR_EL1;
> +* If bit ETM_OPT_CTXTID2 is set, trace CONTEXTIDR_EL2.
> */
> - val = BMVAL(val, 5, 9);
> - if (!val || val != 0x4) {
> - err = -EINVAL;
> - goto out;
> + if (!contextid)
> + contextid = perf_pmu__format_bits(_etm_pmu->format,
> + "contextid");
> +
> + if (contextid & BIT(ETM_OPT_CTXTID)) {
> + /*
> +* TRCIDR2.CIDSIZE, bit [9-5], indicates whether contextID
> +* tracing is supported:
> +* 0b0 Context ID tracing is not supported.
> +* 0b00100 Maximum of 32-bit Context ID size.
> +* All other values are reserved.
> +*/
> + val = BMVAL(val, 5, 9);
> + if (!val || val != 0x4) {
> + pr_err("%s: CONTEXTIDR_EL1 isn't supported\n",
> + CORESIGHT_ETM_PMU_NAME);
> + err = -EINVAL;
> + goto out;
> + }
> + }
> +
> + if (contextid & BIT(ETM_OPT_CTXTID2)) {
> + /*
> +* TRCIDR2.VMIDOPT[30:29] != 0 and
> +* TRCIDR2.VMIDSIZE[14:10] == 0b00100 (32bit virtual
> contextid)
> +* We can't support CONTEXTIDR in VMID if the size of the
> +* virtual context id is < 32bit.
> +* Any value of VMIDSIZE >= 4 (i.e, > 32bit) is fine for us.
> +*/
> + if (!BMVAL(val, 29, 30) || BMVAL(val, 10, 14) < 4) {
> + pr_err("%s: CONTEXTIDR_EL2 isn't supported\n",
> + CORESIGHT_ETM_PMU_NAME);
> + err = -EINVAL;
> + goto out;
> + }
> }
>
> /* All good, let the kernel know */
> - evsel->core.attr.config |= (1 << ETM_OPT_CTXTID);
> + evsel->core.attr.config |= contextid;
> err = 0;
>
> out:
> -
> return err;
> }
>
> @@ -489,7 +524,9 @@ static u64
Re: [PATCH] drivers: mtd: Better word replace a not so good word in the file mtd_blkdevs.c
- Ursprüngliche Mail - > Von: "Bhaskar Chowdhury" > An: "Miquel Raynal" > CC: "richard" , "Vignesh Raghavendra" , > "linux-mtd" , > "linux-kernel" , "Randy Dunlap" > > Gesendet: Freitag, 5. Februar 2021 14:36:39 > Betreff: Re: [PATCH] drivers: mtd: Better word replace a not so good word in > the file mtd_blkdevs.c > On 14:26 Fri 05 Feb 2021, Miquel Raynal wrote: >>Hi Bhaskar, >> >>Bhaskar Chowdhury wrote on Fri, 5 Feb 2021 >>18:11:51 +0530: >> >>> s/fucking/invite/ If you are afraid of "fucking", please replace it with "f*cking" or such. "invite" makes no sense. Thanks, //richard
Re: [PATCH] drivers: mtd: Better word replace a not so good word in the file mtd_blkdevs.c
On 14:49 Fri 05 Feb 2021, Richard Weinberger wrote: - Ursprüngliche Mail - Von: "Bhaskar Chowdhury" An: "Miquel Raynal" CC: "richard" , "Vignesh Raghavendra" , "linux-mtd" , "linux-kernel" , "Randy Dunlap" Gesendet: Freitag, 5. Februar 2021 14:36:39 Betreff: Re: [PATCH] drivers: mtd: Better word replace a not so good word in the file mtd_blkdevs.c On 14:26 Fri 05 Feb 2021, Miquel Raynal wrote: Hi Bhaskar, Bhaskar Chowdhury wrote on Fri, 5 Feb 2021 18:11:51 +0530: s/fucking/invite/ If you are afraid of "fucking", please replace it with "f*cking" or such. "invite" makes no sense. I am NOT afraid of anything ,just replacing the bad words ..that's all ...never bother to evaluate already bad sentences with correct word. I know it is not make any sense ...still a better word ... Thanks, //richard signature.asc Description: PGP signature
[RFC/PATCH 00/11] Raspberry PI 4 V3D enablement
This series attempts to enable V3D on BCM2711, the SoC available on the Raspberry Pi 4 family of boards. Due to the lack of documentation some things are taken as it from testing/downstream implementation[1], which I'm hilighting here: - It's not clear that the following is 100% true, maybe someone can confirm: "In BCM2711 the new ARGON ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one." - Patch #6 I took as is from the downstream implementation, I can't really provide an exact explanation on what changed HW wise. Ultimately, I need confirmation from the Broadcom folks that they are alright with patch #7. With all this, I get a more or less stable experience using mesa 20.3.4 and X11/Gnome. Regards, Nicolas --- Nicolas Saenz Julienne (11): dt-bindings: soc: bcm: bcm2835-pm: Convert bindings to DT schema dt-bindings: soc: bcm: brcm,bcm2835-pm: Add support for bcm2711 ARM: dts: bcm2711: Use proper compatible in PM/Watchdog node mfd: bcm2835-pm: Add support for BCM2711 soc: bcm: bcm2835-power: Add support for BCM2711's ARSAN ASB soc: bcm: bcm2835-power: Bypass power_on/off() calls drm/v3d: Get rid of pm code drm/v3d: Add support for bcm2711 ARM: dts: bcm2711: Enable V3D ARM: configs: Enable DRM_V3D arm64: config: Enable DRM_V3D .../bindings/soc/bcm/brcm,bcm2835-pm.txt | 46 --- .../bindings/soc/bcm/brcm,bcm2835-pm.yaml | 80 +++ arch/arm/boot/dts/bcm2711.dtsi| 14 +++- arch/arm/configs/multi_v7_defconfig | 1 + arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/v3d/Kconfig | 2 +- drivers/gpu/drm/v3d/v3d_debugfs.c | 18 + drivers/gpu/drm/v3d/v3d_drv.c | 12 +-- drivers/gpu/drm/v3d/v3d_gem.c | 9 --- drivers/mfd/bcm2835-pm.c | 55 ++--- drivers/soc/bcm/bcm2835-power.c | 74 +++-- include/linux/mfd/bcm2835-pm.h| 1 + 12 files changed, 190 insertions(+), 123 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt create mode 100644 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml -- 2.30.0
Re: [PATCH] media: pwc: Fix the URB buffer allocation
On Fri, Feb 05, 2021 at 02:42:23PM +0100, Takashi Iwai wrote:
> On Fri, 05 Feb 2021 14:13:02 +0100,
> Andrew Lunn wrote:
> >
> > Hi Takashi
> >
> > > Indeed, looks so. In most cases, this doesn't matter since both point
> > > to the same device object. In some cases like xhci-plat HCD, they
> > > differ. And sysdev might be a better choice from the consistency
> > > POV.
> > >
> > > But this brought an interesting question, too. eg. USB chipidea
> > > HCD uses platform devices for both controller and sysdev, and I
> > > couldn't find any DMA mask setup. So, no matter what to use, the uwc
> > > driver would be broken on this... Maybe it's just not covered.
> >
> > Did you do a git bisect to see what actually broke it? "1161db6776bd:
> > media: usb: pwc: Don't use coherent DMA buffers for ISO transfer"
> > introduced the code, not the regression. If we understand the
> > regression, that might give us the answer about chipidea.
>
> It's the recent DMA core change, the commit f959dcd6ddfd ("dma-direct:
> Fix potential NULL pointer dereference"). But basically it's a right
> fix, and the driver hitting this "regression" has been already broken
> but casually worked without setting a proper DMA mask.
So for the chipidea, it also just 'casually worked'. But now it
probably does not. But that is a separate chipidea issue. None of my
ARM systems use the chipidea IP core, so i cannot test anything.
Andrew
[RFC/PATCH 06/11] soc: bcm: bcm2835-power: Bypass power_on/off() calls
Bypass power_on/power_off() when running on BCM2711 as they are not
needed.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/soc/bcm/bcm2835-power.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/bcm/bcm2835-power.c b/drivers/soc/bcm/bcm2835-power.c
index 17bc71fd243c..ea65f459161d 100644
--- a/drivers/soc/bcm/bcm2835-power.c
+++ b/drivers/soc/bcm/bcm2835-power.c
@@ -197,6 +197,10 @@ static int bcm2835_power_power_off(struct
bcm2835_power_domain *pd, u32 pm_reg)
{
struct bcm2835_power *power = pd->power;
+ /* We don't run this on BCM2711 */
+ if (power->arsan_asb)
+ return 0;
+
/* Enable functional isolation */
PM_WRITE(pm_reg, PM_READ(pm_reg) & ~PM_ISFUNC);
@@ -218,6 +222,10 @@ static int bcm2835_power_power_on(struct
bcm2835_power_domain *pd, u32 pm_reg)
int inrush;
bool powok;
+ /* We don't run this on BCM2711 */
+ if (power->arsan_asb)
+ return 0;
+
/* If it was already powered on by the fw, leave it that way. */
if (PM_READ(pm_reg) & PM_POWUP)
return 0;
--
2.30.0
[PATCH 1/2] mtd: spi-nor: core: Advance erase after the erase cmd has been completed
Wait for the erase cmd to complete and then advance the erase. Signed-off-by: Tudor Ambarus --- drivers/mtd/spi-nor/core.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 0522304f52fa..bcaa161bc7db 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1618,12 +1618,12 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len) if (ret) goto destroy_erase_cmd_list; - addr += cmd->size; - cmd->count--; - ret = spi_nor_wait_till_ready(nor); if (ret) goto destroy_erase_cmd_list; + + addr += cmd->size; + cmd->count--; } list_del(>list); kfree(cmd); @@ -1704,12 +1704,12 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) if (ret) goto erase_err; - addr += mtd->erasesize; - len -= mtd->erasesize; - ret = spi_nor_wait_till_ready(nor); if (ret) goto erase_err; + + addr += mtd->erasesize; + len -= mtd->erasesize; } /* erase multiple sectors */ -- 2.25.1
[PATCH 2/2] mtd: spi-nor: core: Add dbg msg for spi_nor_erase_multi_sectors()
Useful when debugging non-uniform erase. Signed-off-by: Tudor Ambarus --- drivers/mtd/spi-nor/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index bcaa161bc7db..7401c60b53e6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1622,6 +1622,9 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len) if (ret) goto destroy_erase_cmd_list; + dev_dbg(nor->dev, "erase_cmd->size = 0x%08x, erase_cmd->opcode = 0x%02x, erase_cmd->count = %d\n", + cmd->size, cmd->opcode, cmd->count); + addr += cmd->size; cmd->count--; } -- 2.25.1
[PATCH v6 0/2] pinctrl: qcom: Add SM8350 pinctrl support
This adds binding and driver for TLMM block found in SM8350 SoC The binding is dependent on TLMM common binding from Bjorn: https://lore.kernel.org/linux-arm-msm/20210126042650.1725176-1-bjorn.anders...@linaro.org Changes in v6: - Add rob and bjorn r-b - removed quotes around 'defs' and drop the phandle for binding Changes in v5: - rebase and revise binding based on Bjorn's qcom common TLMM binding Changes in v4: - rename to qcom,sm8350-tlmm along with binding and driver structs - fix some nits in binding pointer by Rob Vinod Koul (2): dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings pinctrl: qcom: Add SM8350 pinctrl driver .../bindings/pinctrl/qcom,sm8350-pinctrl.yaml | 145 ++ drivers/pinctrl/qcom/Kconfig |9 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-sm8350.c | 1649 + 4 files changed, 1804 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8350.c -- 2.26.2
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Fri, Feb 05, 2021 at 02:46:44PM +0100, Hans Verkuil wrote:
> On 05/02/2021 14:24, Ville Syrjälä wrote:
> > On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> >> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >>>
> >>> On 01/02/2021 23:13, Ville Syrjälä wrote:
> On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > From: Hans Verkuil
> >
> > For adapters behind an MST hub use the correct AUX channel.
> >
> > Signed-off-by: Hans Verkuil
> > [sa...@chromium.org: rebased, removing redundant changes]
> > Signed-off-by: Sam McNally
> > ---
> >
> > (no changes since v1)
> >
> > drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 15b6cc39a754..0d753201adbd 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> > drm_dp_mst_topology_mgr *mgr,
> > drm_dp_mst_topology_put_port(port);
> > }
> >
> > +static ssize_t
> > +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> > *msg);
> > +
> > static struct drm_dp_mst_port *
> > drm_dp_mst_add_port(struct drm_device *dev,
> > struct drm_dp_mst_topology_mgr *mgr,
> > @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> > port->port_num = port_number;
> > port->mgr = mgr;
> > port->aux.name = "DPMST";
> > +mutex_init(>aux.hw_mutex);
> > +mutex_init(>aux.cec.lock);
> > port->aux.dev = dev->dev;
> > port->aux.is_remote = true;
> >
> > +port->aux.transfer = drm_dp_mst_aux_transfer;
> > +
>
> This was supposed to be handled via higher levels checking for
> is_remote==true.
> >>>
> >>> Ah, I suspect this patch can be dropped entirely: it predates commit
> >>> 2f221a5efed4
> >>> ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
> >>>
> >>> It looks like that commit basically solved what this older patch attempts
> >>> to do
> >>> as well.
> >>>
> >>> Sam, can you test if it works without this patch?
> >>
> >> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
> >> to filter out non-DP connectors. Using aux.is_remote as another signal
> >> indicating a DP connector seems plausible. We can drop this patch.
> >
> > Why would anyone even call this stuff on a non-DP connector?
> > And where did they even get the struct drm_dp_aux to do so?
>
> This check came in with commit 5ce70c799ac2 ("drm_dp_cec: check that aux
> has a transfer function"). It seems nouveau and amdgpu specific.
I see.
>
> A better approach would be to fix those drivers to only call these cec
> functions for DP outputs. I think I moved the test to drm_dp_cec.c primarily
> for robustness (i.e. do nothing if called for a non-DP output). But that
> might not be the right approach after all.
Shrug. I guess just extending to check is_remote (or maybe there is
some other member that's always set?) is a good enough short term
solution. Someone may want to have a look at adjusting
amdgpu/nouveau to not need it, but who knows how much work that is.
--
Ville Syrjälä
Intel
[PATCH v6 1/2] dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings
Add device tree binding Documentation details for Qualcomm SM8350
pinctrl driver.
Reviewed-by: Bjorn Andersson
Reviewed-by: Rob Herring
Signed-off-by: Vinod Koul
---
.../bindings/pinctrl/qcom,sm8350-pinctrl.yaml | 145 ++
1 file changed, 145 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
new file mode 100644
index ..4f2667ea2805
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8350 TLMM block
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ This binding describes the Top Level Mode Multiplexer (TLMM) block found
+ in the SM8350 platform.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+const: qcom,sm8350-tlmm
+
+ reg:
+maxItems: 1
+
+ interrupts: true
+ interrupt-controller: true
+ '#interrupt-cells': true
+ gpio-controller: true
+ gpio-reserved-ranges: true
+ '#gpio-cells': true
+ gpio-ranges: true
+ wakeup-parent: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+patternProperties:
+ '-state$':
+oneOf:
+ - $ref: "#/$defs/qcom-sm8350-tlmm-state"
+ - patternProperties:
+ ".*":
+$ref: "#/$defs/qcom-sm8350-tlmm-state"
+
+$defs:
+ qcom-sm8350-tlmm-state:
+type: object
+description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+$ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
+
+properties:
+ pins:
+description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+items:
+ oneOf:
+- pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-3])$"
+- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
sdc2_data ]
+minItems: 1
+maxItems: 36
+
+ function:
+description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async,
+cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, cri_trng,
+cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
+ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
+gpio, ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync,
mdp_vsync0,
+mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1,
+mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck,
+mi2s1_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws,
+mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12,
+mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6,
+mss_grfc7, mss_grfc8, mss_grfc9, nav_gpio, pa_indicator,
+pcie0_clkreqn, pcie1_clkreqn, phase_flag, pll_bist, pll_clk,
+pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable,
+qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request,
+qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss, qspi0,
+qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10,
+qup11, qup12, qup13, qup14, qup15, qup16, qup17, qup18, qup19,
+qup2, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5,
+qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk,
+sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2,
+tgu_ch3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data,
+uim0_present, uim0_reset, uim1_clk, uim1_data, uim1_present,
+uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ]
+
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-strength: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+required:
+ - pins
+ - function
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+pinctrl@f10 {
+compatible = "qcom,sm8350-tlmm";
+reg = <0x0f10 0x30>;
+interrupts = ;
+gpio-controller;
+#gpio-cells = <2>;
+interrupt-controller;
+#interrupt-cells = <2>;
+gpio-ranges = < 0 0 203>;
+
+gpio-wo-subnode-state {
+pins =
Re: [PATCH net-next v1 1/6] lan743x: boost performance on cpu archs w/o dma cache snooping
Hi Christoph, On Fri, Feb 5, 2021 at 4:31 AM Christoph Hellwig wrote: > > This is a pattern we've seen in a few other net driver, so we should > be ok. It just is rather hairy and needs a good justification, which > seems to be given here. Thank you so much for taking the time to look into this. That is certainly good news !!
Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
On Fri, Feb 5, 2021 at 3:05 PM Daniel Vetter wrote: > On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson > wrote: > > > > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko > > wrote: > > > > > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko > > > wrote: > > > >> Today's linux-next merge of the drivers-x86 tree got a conflict in: > > > > > > > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an > > > > immutable tag I provided. I think they can pull and resolve conflicts > > > > themselves. Alternatively it would be easy to resolve by Linus by > > > > removing Kconfig lines along with mentioned files, > > > > > > Patrik, I have sent a PR again, so you may consider pulling it, thanks! > > > > Daniel, is this something you can pull into drm or ask one of the > > drm-misc maintainers to do? > > We've already created the conflict, and my understanding is that Linus > wants to have visibility into conflict-y stuff and doesn't mind at all > resolving conflicts. Hence for 5.12 I think we're fine as-is. Fine with me! -- With Best Regards, Andy Shevchenko
[RFC PATCH v8 5/5] KVM: arm64: ioctl to fetch/store tags in a guest
The VMM may not wish to have it's own mapping of guest memory mapped
with PROT_MTE because this causes problems if the VMM has tag checking
enabled (the guest controls the tags in physical RAM and it's unlikely
the tags are correct for the VMM).
Instead add a new ioctl which allows the VMM to easily read/write the
tags from guest memory, allowing the VMM's mapping to be non-PROT_MTE
while the VMM can still read/write the tags for the purpose of
migration.
Signed-off-by: Steven Price
---
arch/arm64/include/uapi/asm/kvm.h | 13 +++
arch/arm64/kvm/arm.c | 57 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 71 insertions(+)
diff --git a/arch/arm64/include/uapi/asm/kvm.h
b/arch/arm64/include/uapi/asm/kvm.h
index 24223adae150..5fc2534ac5df 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -184,6 +184,19 @@ struct kvm_vcpu_events {
__u32 reserved[12];
};
+struct kvm_arm_copy_mte_tags {
+ __u64 guest_ipa;
+ __u64 length;
+ union {
+ void __user *addr;
+ __u64 padding;
+ };
+ __u64 flags;
+};
+
+#define KVM_ARM_TAGS_TO_GUEST 0
+#define KVM_ARM_TAGS_FROM_GUEST1
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK0x0FFF
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index c55b7db8639c..0fbb5b9688ce 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1303,6 +1303,53 @@ static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
}
}
+static int kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm,
+ struct kvm_arm_copy_mte_tags *copy_tags)
+{
+ gpa_t guest_ipa = copy_tags->guest_ipa;
+ size_t length = copy_tags->length;
+ void __user *tags = copy_tags->addr;
+ gpa_t gfn;
+ bool write = !(copy_tags->flags & KVM_ARM_TAGS_FROM_GUEST);
+
+ if (copy_tags->flags & ~KVM_ARM_TAGS_FROM_GUEST)
+ return -EINVAL;
+
+ if (length & ~PAGE_MASK || guest_ipa & ~PAGE_MASK)
+ return -EINVAL;
+
+ gfn = gpa_to_gfn(guest_ipa);
+
+ while (length > 0) {
+ kvm_pfn_t pfn = gfn_to_pfn_prot(kvm, gfn, write, NULL);
+ void *maddr;
+ unsigned long num_tags = PAGE_SIZE / MTE_GRANULE_SIZE;
+
+ if (is_error_noslot_pfn(pfn))
+ return -ENOENT;
+
+ maddr = page_address(pfn_to_page(pfn));
+
+ if (!write) {
+ num_tags = mte_copy_tags_to_user(tags, maddr, num_tags);
+ kvm_release_pfn_clean(pfn);
+ } else {
+ num_tags = mte_copy_tags_from_user(maddr, tags,
+ num_tags);
+ kvm_release_pfn_dirty(pfn);
+ }
+
+ if (num_tags != PAGE_SIZE / MTE_GRANULE_SIZE)
+ return -EFAULT;
+
+ gfn++;
+ tags += num_tags;
+ length -= PAGE_SIZE;
+ }
+
+ return 0;
+}
+
long kvm_arch_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -1339,6 +1386,16 @@ long kvm_arch_vm_ioctl(struct file *filp,
return 0;
}
+ case KVM_ARM_MTE_COPY_TAGS: {
+ struct kvm_arm_copy_mte_tags copy_tags;
+
+ if (!kvm_has_mte(kvm))
+ return -EINVAL;
+
+ if (copy_from_user(_tags, argp, sizeof(copy_tags)))
+ return -EFAULT;
+ return kvm_vm_ioctl_mte_copy_tags(kvm, _tags);
+ }
default:
return -EINVAL;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index de737d5102ca..76fccb33d025 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1397,6 +1397,7 @@ struct kvm_s390_ucas_mapping {
/* Available with KVM_CAP_PMU_EVENT_FILTER */
#define KVM_SET_PMU_EVENT_FILTER _IOW(KVMIO, 0xb2, struct
kvm_pmu_event_filter)
#define KVM_PPC_SVM_OFF _IO(KVMIO, 0xb3)
+#define KVM_ARM_MTE_COPY_TAGS_IOR(KVMIO, 0xb4, struct
kvm_arm_copy_mte_tags)
/* ioctl for vm fd */
#define KVM_CREATE_DEVICE_IOWR(KVMIO, 0xe0, struct kvm_create_device)
--
2.20.1
[PATCH v6 2/2] pinctrl: qcom: Add SM8350 pinctrl driver
This adds pincontrol driver for tlmm block found in SM8350 SoC
This patch is based on initial code downstream by Raghavendra.
Reviewed-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/pinctrl/qcom/Kconfig |9 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-sm8350.c | 1649 +
3 files changed, 1659 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8350.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index a003776506d0..8f07f54c027e 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -265,6 +265,15 @@ config PINCTRL_SM8250
Qualcomm Technologies Inc TLMM block found on the Qualcomm
Technologies Inc SM8250 platform.
+config PINCTRL_SM8350
+ tristate "Qualcomm Technologies Inc SM8350 pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc TLMM block found on the Qualcomm
+ Technologies Inc SM8350 platform.
+
config PINCTRL_LPASS_LPI
tristate "Qualcomm Technologies Inc LPASS LPI pin controller driver"
select PINMUX
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 91875a3f5ac4..fe0060b87ce5 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -31,4 +31,5 @@ obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
obj-$(CONFIG_PINCTRL_SDX55) += pinctrl-sdx55.o
obj-$(CONFIG_PINCTRL_SM8150) += pinctrl-sm8150.o
obj-$(CONFIG_PINCTRL_SM8250) += pinctrl-sm8250.o
+obj-$(CONFIG_PINCTRL_SM8350) += pinctrl-sm8350.o
obj-$(CONFIG_PINCTRL_LPASS_LPI) += pinctrl-lpass-lpi.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sm8350.c
b/drivers/pinctrl/qcom/pinctrl-sm8350.c
new file mode 100644
index ..a406ed0ec7d3
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sm8350.c
@@ -0,0 +1,1649 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020-2021, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+#define FUNCTION(fname)\
+ [msm_mux_##fname] = { \
+ .name = #fname, \
+ .groups = fname##_groups, \
+ .ngroups = ARRAY_SIZE(fname##_groups), \
+ }
+
+#define REG_SIZE 0x1000
+
+#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9) \
+ { \
+ .name = "gpio" #id, \
+ .pins = gpio##id##_pins,\
+ .npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins), \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9\
+ }, \
+ .nfuncs = 10, \
+ .ctl_reg = REG_SIZE * id, \
+ .io_reg = REG_SIZE * id + 0x4, \
+ .intr_cfg_reg = REG_SIZE * id + 0x8,\
+ .intr_status_reg = REG_SIZE * id + 0xc, \
+ .intr_target_reg = REG_SIZE * id + 0x8, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9,\
+ .in_bit = 0,\
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+ .intr_target_bit = 5, \
+ .intr_target_kpss_val = 3, \
+ .intr_raw_status_bit = 4, \
+ .intr_polarity_bit = 1, \
+ .intr_detection_bit = 2,\
+ .intr_detection_width = 2, \
+ }
+
+#define SDC_PINGROUP(pg_name, ctl, pull, drv) \
+ { \
+ .name = #pg_name, \
+ .pins = pg_name##_pins, \
+ .npins = (unsigned int)ARRAY_SIZE(pg_name##_pins), \
+ .ctl_reg = ctl,
Re: [PATCH] drivers: mtd: Better word replace a not so good word in the file mtd_blkdevs.c
On 14:57 Fri 05 Feb 2021, Miquel Raynal wrote: Hi Bhaskar, Bhaskar Chowdhury wrote on Fri, 5 Feb 2021 19:06:39 +0530: On 14:26 Fri 05 Feb 2021, Miquel Raynal wrote: >Hi Bhaskar, > >Bhaskar Chowdhury wrote on Fri, 5 Feb 2021 >18:11:51 +0530: > >> s/fucking/invite/ >> >> >> Signed-off-by: Bhaskar Chowdhury >> --- >> drivers/mtd/mtd_blkdevs.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c >> index fb8e12d590a1..756a0995e474 100644 >> --- a/drivers/mtd/mtd_blkdevs.c >> +++ b/drivers/mtd/mtd_blkdevs.c >> @@ -523,7 +523,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *t r) >>int ret; >> >>/* Register the notifier if/when the first device type is >> - registered, to prevent the link/init ordering from fucking >> + registered, to prevent the link/init ordering from invite >> us over. */ > >invite us over? > >I'm not a native English speaker but this does not bring any value to >my ears. Worse, I don't even get the point. Better rewrite the comment >entirely than just swapping "fucking" with a random word, no? > Got your point , and I do understand "fuck" and "fucking" is so strong word that it is really difficult to replace with something else. But..but you suggestion to rewrite the comments sounds good Miquel ...wish I could have that much time in hand to replace every sentence having that word ...all the patched sent with that word replaces...please step forward and make and send patches . Today I sent 10 patches replacing that word(weather that make sense or not) you can see those in the ML ...please pick up as you wish and send patches. There are currently 21 uses of "fuck[ing]". It's not a mountain to climb. Nor a race. ✔ ~/git-linux/linux [master|✔] 19:28 $ search fuck | wc -l 15 I was simply replacing the word ..never bother about the meaning it conveys..doesn't matter really. Are you kidding? What is the purpose of a comment if no one understands it after a blind change? No I am not . But the sentences contains that word hardly have more meaning. But as you already said rewriting those comment would be a good idea...can you take up some of those?? so... signature.asc Description: PGP signature
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Fri, Feb 5, 2021 at 3:41 PM Sedat Dilek wrote: > > On Fri, Feb 5, 2021 at 3:37 PM Sedat Dilek wrote: > > > > Hi, > > > > when building with pahole v1.20 and binutils v2.35.2 plus Clang > > v12.0.0-rc1 and DWARF-v5 I see: > > ... > > + info BTF .btf.vmlinux.bin.o > > + [ != silent_ ] > > + printf %-7s %s\n BTF .btf.vmlinux.bin.o > > BTF .btf.vmlinux.bin.o > > + LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J > > .tmp_vmlinux.btf > > [115] INT DW_ATE_unsigned_1 Error emitting BTF type > > Encountered error while encoding BTF. > > Grepping the pahole sources: > > $ git grep DW_ATE > dwarf_loader.c: bt->is_bool = encoding == DW_ATE_boolean; > dwarf_loader.c: bt->is_signed = encoding == DW_ATE_signed; > > Missing DW_ATE_unsigned encoding? > Checked the LLVM sources: clang/lib/CodeGen/CGDebugInfo.cpp:Encoding = llvm::dwarf::DW_ATE_unsigned_char; clang/lib/CodeGen/CGDebugInfo.cpp:Encoding = llvm::dwarf::DW_ATE_unsigned; clang/lib/CodeGen/CGDebugInfo.cpp:Encoding = llvm::dwarf::DW_ATE_unsigned_fixed; clang/lib/CodeGen/CGDebugInfo.cpp: ? llvm::dwarf::DW_ATE_unsigned ... lld/test/wasm/debuginfo.test:CHECK-NEXT:DW_AT_encoding (DW_ATE_unsigned) So, I will switch from GNU ld.bfd v2.35.2 to LLD-12. - Sedat -
Re: [PATCH 1/2] HID: logitech-dj: add support for the new lightspeed receiver iteration
On Sat, 23 Jan 2021, Filipe Laíns wrote: > From: Filipe Laíns > > Tested with the G Pro X Superlight. libratbag sees the device, as > expected, and input events are passing trough. > > https://github.com/libratbag/libratbag/pull/1122 > > The receiver has a quirk where the moused interface doesn't have a > report ID, I am not sure why, perhaps they forgot. All other interfaces > have report IDs so I am left scratching my head. > Since this driver doesn't have a quirk system, I simply implemented it > as a different receiver type, which is true, it just wouldn't be the > prefered approach :P Benjamin, do you have any other idea how to accomplish this without this kind of spaghetti-style conditions? If not, I am tempted to apply the patch as is. Thanks, -- Jiri Kosina SUSE Labs
[PATCH v1] Bluetooth: hci_qca:Fixed issue during suspend
If BT SoC is running with ROM FW then just return in
qca_suspend function as ROM FW does not support
in-band sleep.
Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend")
Signed-off-by: Venkata Lakshmi Narayana Gubba
---
drivers/bluetooth/hci_qca.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index ff2fb68..de36af6 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -77,7 +77,8 @@ enum qca_flags {
QCA_MEMDUMP_COLLECTION,
QCA_HW_ERROR_EVENT,
QCA_SSR_TRIGGERED,
- QCA_BT_OFF
+ QCA_BT_OFF,
+ QCA_ROM_FW
};
enum qca_capabilities {
@@ -1664,6 +1665,7 @@ static int qca_setup(struct hci_uart *hu)
if (ret)
return ret;
+ clear_bit(QCA_ROM_FW, >flags);
/* Patch downloading has to be done without IBS mode */
set_bit(QCA_IBS_DISABLED, >flags);
@@ -1721,12 +1723,14 @@ static int qca_setup(struct hci_uart *hu)
hu->hdev->cmd_timeout = qca_cmd_timeout;
} else if (ret == -ENOENT) {
/* No patch/nvm-config found, run with original fw/config */
+ set_bit(QCA_ROM_FW, >flags);
ret = 0;
} else if (ret == -EAGAIN) {
/*
* Userspace firmware loader will return -EAGAIN in case no
* patch/nvm-config is found, so run with original fw/config.
*/
+ set_bit(QCA_ROM_FW, >flags);
ret = 0;
}
@@ -2103,6 +2107,12 @@ static int __maybe_unused qca_suspend(struct device *dev)
set_bit(QCA_SUSPENDING, >flags);
+ /* if BT SoC is running with default firmware then it does not
+* support in-band sleep
+*/
+ if (test_bit(QCA_ROM_FW, >flags))
+ return 0;
+
/* During SSR after memory dump collection, controller will be
* powered off and then powered on.If controller is powered off
* during SSR then we should wait until SSR is completed.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 7/7] mm: memcontrol: consolidate lruvec stat flushing
On Tue 02-02-21 13:47:46, Johannes Weiner wrote:
> There are two functions to flush the per-cpu data of an lruvec into
> the rest of the cgroup tree: when the cgroup is being freed, and when
> a CPU disappears during hotplug. The difference is whether all CPUs or
> just one is being collected, but the rest of the flushing code is the
> same. Merge them into one function and share the common code.
IIUC the only reason for the cpu == -1 special case is to avoid
zeroying, right? Is this optimization worth the special case? The code
would be slightly easier to follow without this.
> Signed-off-by: Johannes Weiner
Anyway the above is not really a fundamental objection. It is more important
to unify the flushing.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 88 +++--
> 1 file changed, 42 insertions(+), 46 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index b205b2413186..88e8afc49a46 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2410,39 +2410,56 @@ static void drain_all_stock(struct mem_cgroup
> *root_memcg)
> mutex_unlock(_charge_mutex);
> }
>
> -static int memcg_hotplug_cpu_dead(unsigned int cpu)
> +static void memcg_flush_lruvec_page_state(struct mem_cgroup *memcg, int cpu)
> {
> - struct memcg_stock_pcp *stock;
> - struct mem_cgroup *memcg;
> -
> - stock = _cpu(memcg_stock, cpu);
> - drain_stock(stock);
> + int nid;
>
> - for_each_mem_cgroup(memcg) {
> + for_each_node(nid) {
> + struct mem_cgroup_per_node *pn = memcg->nodeinfo[nid];
> + unsigned long stat[NR_VM_NODE_STAT_ITEMS] = { 0, };
> + struct batched_lruvec_stat *lstatc;
> int i;
>
> - for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++) {
> - int nid;
> -
> - for_each_node(nid) {
> - struct batched_lruvec_stat *lstatc;
> - struct mem_cgroup_per_node *pn;
> - long x;
> -
> - pn = memcg->nodeinfo[nid];
> + if (cpu == -1) {
> + int cpui;
> + /*
> + * The memcg is about to be freed, collect all
> + * CPUs, no need to zero anything out.
> + */
> + for_each_online_cpu(cpui) {
> + lstatc = per_cpu_ptr(pn->lruvec_stat_cpu, cpui);
> + for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
> + stat[i] += lstatc->count[i];
> + }
> + } else {
> + /*
> + * The CPU has gone away, collect and zero out
> + * its stats, it may come back later.
> + */
> + for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++) {
> lstatc = per_cpu_ptr(pn->lruvec_stat_cpu, cpu);
> -
> - x = lstatc->count[i];
> + stat[i] = lstatc->count[i];
> lstatc->count[i] = 0;
> -
> - if (x) {
> - do {
> - atomic_long_add(x,
> >lruvec_stat[i]);
> - } while ((pn = parent_nodeinfo(pn,
> nid)));
> - }
> }
> }
> +
> + do {
> + for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
> + atomic_long_add(stat[i], >lruvec_stat[i]);
> + } while ((pn = parent_nodeinfo(pn, nid)));
> }
> +}
> +
> +static int memcg_hotplug_cpu_dead(unsigned int cpu)
> +{
> + struct memcg_stock_pcp *stock;
> + struct mem_cgroup *memcg;
> +
> + stock = _cpu(memcg_stock, cpu);
> + drain_stock(stock);
> +
> + for_each_mem_cgroup(memcg)
> + memcg_flush_lruvec_page_state(memcg, cpu);
>
> return 0;
> }
> @@ -3636,27 +3653,6 @@ static u64 mem_cgroup_read_u64(struct
> cgroup_subsys_state *css,
> }
> }
>
> -static void memcg_flush_lruvec_page_state(struct mem_cgroup *memcg)
> -{
> - int node;
> -
> - for_each_node(node) {
> - struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
> - unsigned long stat[NR_VM_NODE_STAT_ITEMS] = {0, };
> - struct mem_cgroup_per_node *pi;
> - int cpu, i;
> -
> - for_each_online_cpu(cpu)
> - for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
> - stat[i] += per_cpu(
> - pn->lruvec_stat_cpu->count[i], cpu);
> -
> - for (pi = pn; pi; pi = parent_nodeinfo(pi, node))
> - for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
> -
Re: [PATCH] fs/btrfs: Fix raid6 qstripe kmap'ing
On Thu, Feb 04, 2021 at 07:52:36PM -0800, Ira Weiny wrote: > On Thu, Feb 04, 2021 at 04:26:08PM +0100, David Sterba wrote: > > On Wed, Feb 03, 2021 at 04:56:48PM +0100, David Sterba wrote: > > > On Wed, Jan 27, 2021 at 10:15:03PM -0800, ira.we...@intel.com wrote: > > > > From: Ira Weiny > > > Changelog is good, thanks. I've added stable tags as the missing unmap > > > is a potential problem. > > > > There are lots of tests faling, stack traces like below. I haven't seen > > anything obvious in the patch so that needs a closer look and for the > > time being I can't add the patch to for-next. > > :-( > > I think I may have been off by 1 on the raid6 kmap... > > Something like this should fix it... > > diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c > index b8a39dad0f00..dbf52f1a379d 100644 > --- a/fs/btrfs/raid56.c > +++ b/fs/btrfs/raid56.c > @@ -2370,7 +2370,7 @@ static noinline void finish_parity_scrub(struct > btrfs_raid_bio *rbio, > goto cleanup; > } > SetPageUptodate(q_page); > - pointers[rbio->real_stripes] = kmap(q_page); > + pointers[rbio->real_stripes - 1] = kmap(q_page); Oh right and tests agree it works. > } > > atomic_set(>error, 0); > > Let me roll a new version. No need to, I'll fold the fixup. Thanks.
Re: [PATCH v4 2/4] lib: vsprintf: Fix handling of number field widths in vsscanf
On Fri, Feb 5, 2021 at 5:23 PM David Laight wrote:
> From: Andy Shevchenko
> > Sent: 05 February 2021 12:51
> > On Fri, Feb 5, 2021 at 1:35 PM Richard Fitzgerald
> > wrote:
> > > On 04/02/2021 16:35, Petr Mladek wrote:
> > > > On Wed 2021-02-03 21:45:55, Andy Shevchenko wrote:
> > > >> On Wed, Feb 03, 2021 at 04:50:07PM +, Richard Fitzgerald wrote:
> >
> > ...
> >
> > > >>> + for (; max_chars > 0; max_chars--) {
> > > >>
> > > >> Less fragile is to write
> > > >>
> > > >> while (max_chars--)
> > > >
> > > > Except that the original was more obvious at least for me.
> > > > I always prefer more readable code when the compiler might do
> > > > the optimization easily. But this is my personal taste.
> > > > I am fine with both variants.
> >
> > I *slightly* prefer while-loop *in this case* due to less characters
> > to parse to understand the logic.
>
> The two loops are also have different values for 'max_chars'
> inside the loop body.
off-by-one to be precise.
> If 'max_chars' is known to be non-zero the do ... while (--max_chars);
> loop will probable generate better code.
What?! while (--x) and while(x--) are equivalent.
> But there is no accounting for just how odd some decisions gcc
> makes are.
Why should we care about the compiler bugs here?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] HID: logitech-dj: add support for keyboard events in eQUAD step 4 Gaming
On Fri, 2021-02-05 at 10:18 +0100, Jiri Kosina wrote: > On Sat, 30 Jan 2021, Filipe Laíns wrote: > > > From: Filipe Laíns > > > > In e400071a805d6229223a98899e9da8c6233704a1 I added support for the > > receiver that comes with the G602 device, but unfortunately I screwed up > > during testing and it seems the keyboard events were actually not being > > sent to userspace. > > This resulted in keyboard events being broken in userspace, please > > backport the fix. > > > > The receiver uses the normal 0x01 Logitech keyboard report descriptor, > > as expected, so it is just a matter of flagging it as supported. > > > > Reported in > > https://github.com/libratbag/libratbag/issues/1124 > > > > Signed-off-by: Filipe Laíns > > Given this is a regression, could you please add proper Fixes: and Cc: > stable tags? > > Thank you, > Done :) Sorry about that, I am not yet familiarized with all steps of the workflow. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
[PATCH v3] mfd: da9063: Support SMBus and I2C mode
From: Hubert Streidl
By default the PMIC DA9063 2-wire interface is SMBus compliant. This
means the PMIC will automatically reset the interface when the clock
signal ceases for more than the SMBus timeout of 35 ms.
If the I2C driver / device is not capable of creating atomic I2C
transactions, a context change can cause a ceasing of the clock signal.
This can happen if for example a real-time thread is scheduled. Then
the DA9063 in SMBus mode will reset the 2-wire interface. Subsequently
a write message could end up in the wrong register. This could cause
unpredictable system behavior.
The DA9063 PMIC also supports an I2C compliant mode for the 2-wire
interface. This mode does not reset the interface when the clock
signal ceases. Thus the problem depicted above does not occur.
This patch tests for the bus functionality "I2C_FUNC_I2C". It can
reasonably be assumed that the bus cannot obey SMBus timings if
this functionality is set. SMBus commands most probably are emulated
in this case which is prone to the latency issue described above.
This patch enables the I2C bus mode if I2C_FUNC_I2C is set or
otherwise enables the SMBus mode for a native SMBus controller
which doesn't have I2C_FUNC_I2C set.
Signed-off-by: Hubert Streidl
Signed-off-by: Mark Jonas
---
Changes in v3:
- busmode now contains the correct bit DA9063_TWOWIRE_TO
Changes in v2:
- Implement proposal by Adam Thomson and Wolfram Sang to check for
functionality I2C_FUNC_I2C instead of introducing a new DT property.
drivers/mfd/da9063-i2c.c | 15 +++
include/linux/mfd/da9063/registers.h | 3 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 3781d0bb7786..4c5e0f69942f 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -355,6 +355,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct da9063 *da9063;
+ unsigned int busmode;
int ret;
da9063 = devm_kzalloc(>dev, sizeof(struct da9063), GFP_KERNEL);
@@ -442,6 +443,20 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
return ret;
}
+ if (i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C)) {
+ dev_info(da9063->dev, "I2C mode");
+ busmode = 0;
+ } else {
+ dev_info(da9063->dev, "SMBus mode");
+ busmode = DA9063_TWOWIRE_TO;
+ }
+ ret = regmap_update_bits(da9063->regmap, DA9063_REG_CONFIG_J,
+ DA9063_TWOWIRE_TO, busmode);
+ if (ret < 0) {
+ dev_err(da9063->dev, "Failed to set 2-wire bus mode.\n");
+ return -EIO;
+ }
+
return da9063_device_init(da9063, i2c->irq);
}
diff --git a/include/linux/mfd/da9063/registers.h
b/include/linux/mfd/da9063/registers.h
index 1dbabf1b3cb8..6e0f66a2e727 100644
--- a/include/linux/mfd/da9063/registers.h
+++ b/include/linux/mfd/da9063/registers.h
@@ -1037,6 +1037,9 @@
#defineDA9063_NONKEY_PIN_AUTODOWN 0x02
#defineDA9063_NONKEY_PIN_AUTOFLPRT 0x03
+/* DA9063_REG_CONFIG_J (addr=0x10F) */
+#define DA9063_TWOWIRE_TO 0x40
+
/* DA9063_REG_MON_REG_5 (addr=0x116) */
#define DA9063_MON_A8_IDX_MASK 0x07
#defineDA9063_MON_A8_IDX_NONE 0x00
--
2.25.1
[QEMU] x86: Implement Linear Address Masking support
Linear Address Masking feature makes CPU ignore some bits of the virtual
address. These bits can be used to encode metadata.
The feature is enumerated with CPUID.(EAX=07H, ECX=01H):EAX.LAM[bit 26].
CR3.LAM_U57[bit 62] allows to encode 6 bits of metadata in bits 62:57 of
user pointers.
CR3.LAM_U48[bit 61] allows to encode 15 bits of metadata in bits 62:48
of user pointers.
CR4.LAM_SUP[bit 28] allows to encode metadata of supervisor pointers.
If 5-level paging is in use, 6 bits of metadata can be encoded in 62:57.
For 4-level paging, 15 bits of metadata can be encoded in bits 62:48.
QEMU strips address from the metadata bits and gets it to canonical
shape before handling memory access. It has to be done very early before
TLB lookup.
Signed-off-by: Kirill A. Shutemov
---
accel/tcg/cputlb.c| 54 +++
include/hw/core/cpu.h | 1 +
target/i386/cpu.c | 5 ++--
target/i386/cpu.h | 7 +
target/i386/excp_helper.c | 28 +++-
target/i386/helper.c | 2 +-
6 files changed, 71 insertions(+), 26 deletions(-)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 42ab79c1a582..f2d27134474f 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1271,6 +1271,17 @@ static inline ram_addr_t
qemu_ram_addr_from_host_nofail(void *ptr)
return ram_addr;
}
+static vaddr clean_addr(CPUState *cpu, vaddr addr)
+{
+CPUClass *cc = CPU_GET_CLASS(cpu);
+
+if (cc->do_clean_addr) {
+addr = cc->do_clean_addr(cpu, addr);
+}
+
+return addr;
+}
+
/*
* Note: tlb_fill() can trigger a resize of the TLB. This means that all of the
* caller's prior references to the TLB table (e.g. CPUTLBEntry pointers) must
@@ -1702,9 +1713,11 @@ bool tlb_plugin_lookup(CPUState *cpu, target_ulong addr,
int mmu_idx,
/* Probe for a read-modify-write atomic operation. Do not allow unaligned
* operations, or io operations to proceed. Return the host address. */
-static void *atomic_mmu_lookup(CPUArchState *env, target_ulong addr,
+static void *atomic_mmu_lookup(CPUArchState *env, target_ulong address,
TCGMemOpIdx oi, uintptr_t retaddr)
{
+CPUState *cpu = env_cpu(env);
+target_ulong addr = clean_addr(cpu, address);
size_t mmu_idx = get_mmuidx(oi);
uintptr_t index = tlb_index(env, mmu_idx, addr);
CPUTLBEntry *tlbe = tlb_entry(env, mmu_idx, addr);
@@ -1720,8 +1733,7 @@ static void *atomic_mmu_lookup(CPUArchState *env,
target_ulong addr,
/* Enforce guest required alignment. */
if (unlikely(a_bits > 0 && (addr & ((1 << a_bits) - 1 {
/* ??? Maybe indicate atomic op to cpu_unaligned_access */
-cpu_unaligned_access(env_cpu(env), addr, MMU_DATA_STORE,
- mmu_idx, retaddr);
+cpu_unaligned_access(cpu, addr, MMU_DATA_STORE, mmu_idx, retaddr);
}
/* Enforce qemu required alignment. */
@@ -1736,8 +1748,7 @@ static void *atomic_mmu_lookup(CPUArchState *env,
target_ulong addr,
/* Check TLB entry and enforce page permissions. */
if (!tlb_hit(tlb_addr, addr)) {
if (!VICTIM_TLB_HIT(addr_write, addr)) {
-tlb_fill(env_cpu(env), addr, 1 << s_bits, MMU_DATA_STORE,
- mmu_idx, retaddr);
+tlb_fill(cpu, addr, 1 << s_bits, MMU_DATA_STORE, mmu_idx, retaddr);
index = tlb_index(env, mmu_idx, addr);
tlbe = tlb_entry(env, mmu_idx, addr);
}
@@ -1753,8 +1764,7 @@ static void *atomic_mmu_lookup(CPUArchState *env,
target_ulong addr,
/* Let the guest notice RMW on a write-only page. */
if (unlikely(tlbe->addr_read != (tlb_addr & ~TLB_NOTDIRTY))) {
-tlb_fill(env_cpu(env), addr, 1 << s_bits, MMU_DATA_LOAD,
- mmu_idx, retaddr);
+tlb_fill(cpu, addr, 1 << s_bits, MMU_DATA_LOAD, mmu_idx, retaddr);
/* Since we don't support reads and writes to different addresses,
and we do have the proper page loaded for write, this shouldn't
ever return. But just in case, handle via stop-the-world. */
@@ -1764,14 +1774,14 @@ static void *atomic_mmu_lookup(CPUArchState *env,
target_ulong addr,
hostaddr = (void *)((uintptr_t)addr + tlbe->addend);
if (unlikely(tlb_addr & TLB_NOTDIRTY)) {
-notdirty_write(env_cpu(env), addr, 1 << s_bits,
+notdirty_write(cpu, addr, 1 << s_bits,
_tlb(env)->d[mmu_idx].iotlb[index], retaddr);
}
return hostaddr;
stop_the_world:
-cpu_loop_exit_atomic(env_cpu(env), retaddr);
+cpu_loop_exit_atomic(cpu, retaddr);
}
/*
@@ -1810,10 +1820,12 @@ load_memop(const void *haddr, MemOp op)
}
static inline uint64_t QEMU_ALWAYS_INLINE
-load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
+load_helper(CPUArchState *env, target_ulong address, TCGMemOpIdx oi,
uintptr_t retaddr, MemOp op, bool code_read,
FullLoadHelper *full_load)
{
+
Kindly Accept My Donation
Dearest One, I'm writing you this mail with the trust that only you can help me in this situation for your trusted and God-fearing personality. I'm sorry to intrude into your privacy. I saw your profile in the webinternational domain database) when I was looking for a reliable trustee to whom I should entrust my funds, I don't want to have my offer declined because I have prayed over it and I'm convinced beyond all doubts that you could be of help to me and carry out this offer successfully, please kindly accept it with an open and positive mind. I'm MRS CORNELIA PASCAL 66 years, from (Lhasa) FRANCE but based in Republic of Burkina Faso. I have been here for over 14 years and have been grappling with breast cancer disease. My doctor just confirmed to me that I have just a few time to live. I'm a business woman dealing on gold exportation before the sickness. I had an amount of fund that I want you to help me get into your bank account to set up a project to immortalize me if I eventually pass on. Now that I'm ending this Earthly race in this sad manner without any family members nor child, I deem it necessary to build an Orphanage home. I had instructed the bank to transfer $2 million US dollar personal fund in my account with the Africa Development Bank Burkina Faso to St, Andrews Missionary Home Burkina Faso but my mind is still not at rest. I'm writing you now through the help of a computer beside my sick bed in the hospital. My main reason of contacting you now is because of the sum of my $10.9 Million USD with the United Bank of Africa here in Burkina Faso. I had earlier instructed the bank to transfer the money to the bank account of the first foreigner been male or female that will apply to the claim of the Fund after my Death or Alive but you will assure me with the name of God the most high that you will take only 40% for yourself and use 60% to build an Orphanage Home with my name in your country just to immortalize my time on Earth and my mind to be at rest. I shall give you the Email Address of the Bank and my data's once I receive a positive response from you through this my private Email Address: mrscornel...@gmail.com Please, kindly Reply me with the details below for my confirmation so that I can forward the Bank Email Address to you to contact them as soon as possible. 1.Full name: 2.Your Age: 3.Sex: 4.Nationality: 5.Country of residence: 6.Telephone Number: 7.Marital status: 8.Occupation: 9.Send to me your picture 10.You have to assure me you will act as I have instructed you above if the money gets to your Bank Account/ Yours Sincerely. Mrs Cornelia Pascal.
RE: [PATCH v4 2/4] lib: vsprintf: Fix handling of number field widths in vsscanf
From: Andy Shevchenko
> Sent: 05 February 2021 12:51
>
> On Fri, Feb 5, 2021 at 1:35 PM Richard Fitzgerald
> wrote:
> > On 04/02/2021 16:35, Petr Mladek wrote:
> > > On Wed 2021-02-03 21:45:55, Andy Shevchenko wrote:
> > >> On Wed, Feb 03, 2021 at 04:50:07PM +, Richard Fitzgerald wrote:
>
> ...
>
> > >>> + for (; max_chars > 0; max_chars--) {
> > >>
> > >> Less fragile is to write
> > >>
> > >> while (max_chars--)
> > >
> > > Except that the original was more obvious at least for me.
> > > I always prefer more readable code when the compiler might do
> > > the optimization easily. But this is my personal taste.
> > > I am fine with both variants.
>
> I *slightly* prefer while-loop *in this case* due to less characters
> to parse to understand the logic.
The two loops are also have different values for 'max_chars'
inside the loop body.
If 'max_chars' is known to be non-zero the do ... while (--max_chars);
loop will probable generate better code.
But there is no accounting for just how odd some decisions gcc
makes are.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
[PATCH v2 10/12] arm64: kasan: simplify and inline MTE functions
This change provides a simpler implementation of mte_get_mem_tag(),
mte_get_random_tag(), and mte_set_mem_tag_range().
Simplifications include removing system_supports_mte() checks as these
functions are onlye called from KASAN runtime that had already checked
system_supports_mte(). Besides that, size and address alignment checks
are removed from mte_set_mem_tag_range(), as KASAN now does those.
This change also moves these functions into the asm/mte-kasan.h header
and implements mte_set_mem_tag_range() via inline assembly to avoid
unnecessary functions calls.
Reviewed-by: Catalin Marinas
Co-developed-by: Vincenzo Frascino
Signed-off-by: Vincenzo Frascino
Signed-off-by: Andrey Konovalov
---
arch/arm64/include/asm/cache.h | 1 -
arch/arm64/include/asm/kasan.h | 1 +
arch/arm64/include/asm/mte-def.h | 2 +
arch/arm64/include/asm/mte-kasan.h | 65 ++
arch/arm64/include/asm/mte.h | 2 -
arch/arm64/kernel/mte.c| 46 -
arch/arm64/lib/mte.S | 16
7 files changed, 60 insertions(+), 73 deletions(-)
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 77cbbe3625f2..a074459f8f2f 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -6,7 +6,6 @@
#define __ASM_CACHE_H
#include
-#include
#define CTR_L1IP_SHIFT 14
#define CTR_L1IP_MASK 3
diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index 0aaf9044cd6a..12d5f47f7dbe 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#define arch_kasan_set_tag(addr, tag) __tag_set(addr, tag)
diff --git a/arch/arm64/include/asm/mte-def.h b/arch/arm64/include/asm/mte-def.h
index 2d73a1612f09..cf241b0f0a42 100644
--- a/arch/arm64/include/asm/mte-def.h
+++ b/arch/arm64/include/asm/mte-def.h
@@ -11,4 +11,6 @@
#define MTE_TAG_SIZE 4
#define MTE_TAG_MASK GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)),
MTE_TAG_SHIFT)
+#define __MTE_PREAMBLE ARM64_ASM_PREAMBLE ".arch_extension memtag\n"
+
#endif /* __ASM_MTE_DEF_H */
diff --git a/arch/arm64/include/asm/mte-kasan.h
b/arch/arm64/include/asm/mte-kasan.h
index 8ad981069afb..13be3afc37ac 100644
--- a/arch/arm64/include/asm/mte-kasan.h
+++ b/arch/arm64/include/asm/mte-kasan.h
@@ -11,11 +11,14 @@
#include
+#ifdef CONFIG_ARM64_MTE
+
/*
- * The functions below are meant to be used only for the
- * KASAN_HW_TAGS interface defined in asm/memory.h.
+ * These functions are meant to be only used from KASAN runtime through
+ * the arch_*() interface defined in asm/memory.h.
+ * These functions don't include system_supports_mte() checks,
+ * as KASAN only calls them when MTE is supported and enabled.
*/
-#ifdef CONFIG_ARM64_MTE
static inline u8 mte_get_ptr_tag(void *ptr)
{
@@ -25,9 +28,54 @@ static inline u8 mte_get_ptr_tag(void *ptr)
return tag;
}
-u8 mte_get_mem_tag(void *addr);
-u8 mte_get_random_tag(void);
-void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag);
+/* Get allocation tag for the address. */
+static inline u8 mte_get_mem_tag(void *addr)
+{
+ asm(__MTE_PREAMBLE "ldg %0, [%0]"
+ : "+r" (addr));
+
+ return mte_get_ptr_tag(addr);
+}
+
+/* Generate a random tag. */
+static inline u8 mte_get_random_tag(void)
+{
+ void *addr;
+
+ asm(__MTE_PREAMBLE "irg %0, %0"
+ : "+r" (addr));
+
+ return mte_get_ptr_tag(addr);
+}
+
+/*
+ * Assign allocation tags for a region of memory based on the pointer tag.
+ * Note: The address must be non-NULL and MTE_GRANULE_SIZE aligned and
+ * size must be non-zero and MTE_GRANULE_SIZE aligned.
+ */
+static inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
+{
+ u64 curr, end;
+
+ if (!size)
+ return;
+
+ curr = (u64)__tag_set(addr, tag);
+ end = curr + size;
+
+ do {
+ /*
+* 'asm volatile' is required to prevent the compiler to move
+* the statement outside of the loop.
+*/
+ asm volatile(__MTE_PREAMBLE "stg %0, [%0]"
+:
+: "r" (curr)
+: "memory");
+
+ curr += MTE_GRANULE_SIZE;
+ } while (curr != end);
+}
void mte_enable_kernel_sync(void);
void mte_enable_kernel_async(void);
@@ -47,13 +95,14 @@ static inline u8 mte_get_mem_tag(void *addr)
{
return 0xFF;
}
+
static inline u8 mte_get_random_tag(void)
{
return 0xFF;
}
-static inline void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
+
+static inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
{
- return addr;
}
static inline void mte_enable_kernel_sync(void)
diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index
Re: [PATCH 2/9] perf tools: Support the auxiliary event
On 2/5/2021 10:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Feb 05, 2021 at 09:13:34AM -0500, Liang, Kan escreveu:
On 2/5/2021 5:52 AM, Namhyung Kim wrote:
On Wed, Feb 3, 2021 at 5:14 AM wrote:
From: Kan Liang
On the Intel Sapphire Rapids server, an auxiliary event has to be
enabled simultaneously with the load latency event to retrieve complete
Memory Info.
Add X86 specific perf_mem_events__name() to handle the auxiliary event.
- Users are only interested in the samples of the mem-loads event.
Sample read the auxiliary event.
- The auxiliary event must be in front of the load latency event in a
group. Assume the second event to sample if the auxiliary event is the
leader.
- Add a weak is_mem_loads_aux_event() to check the auxiliary event for
X86. For other ARCHs, it always return false.
Parse the unique event name, mem-loads-aux, for the auxiliary event.
Signed-off-by: Kan Liang
---
tools/perf/arch/x86/util/Build| 1 +
tools/perf/arch/x86/util/mem-events.c | 44
+++
tools/perf/util/evsel.c | 3 +++
tools/perf/util/mem-events.c | 5
tools/perf/util/mem-events.h | 2 ++
tools/perf/util/parse-events.l| 1 +
tools/perf/util/record.c | 5 +++-
7 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/arch/x86/util/mem-events.c
diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index 347c39b..d73f548 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -6,6 +6,7 @@ perf-y += perf_regs.o
perf-y += topdown.o
perf-y += machine.o
perf-y += event.o
+perf-y += mem-events.o
perf-$(CONFIG_DWARF) += dwarf-regs.o
perf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/mem-events.c
b/tools/perf/arch/x86/util/mem-events.c
new file mode 100644
index 000..11b8469
--- /dev/null
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "util/pmu.h"
+#include "map_symbol.h"
+#include "mem-events.h"
+
+static char mem_loads_name[100];
+static bool mem_loads_name__init;
+
+#define MEM_LOADS_AUX 0x8203
+#define MEM_LOADS_AUX_NAME
"{cpu/mem-loads-aux/,cpu/mem-loads,ldlat=%u/pp}:S"
+
+bool is_mem_loads_aux_event(struct evsel *leader)
+{
+ if (!pmu_have_event("cpu", "mem-loads-aux"))
+ return false;
+
+ return leader->core.attr.config == MEM_LOADS_AUX;
+}
+
+char *perf_mem_events__name(int i)
+{
+ struct perf_mem_event *e = perf_mem_events__ptr(i);
+
+ if (!e)
+ return NULL;
+
+ if (i == PERF_MEM_EVENTS__LOAD) {
+ if (mem_loads_name__init)
+ return mem_loads_name;
+
+ mem_loads_name__init = true;
+
+ if (pmu_have_event("cpu", "mem-loads-aux")) {
+ scnprintf(mem_loads_name, sizeof(MEM_LOADS_AUX_NAME),
+ MEM_LOADS_AUX_NAME,
perf_mem_events__loads_ldlat);
It changes "%u" to an actual latency value, right?
What if the value takes 3 or more digits?
I'm not sure scnprintf() will handle it properly.
Yes, you are right. We should use the sizeof(mem_loads_name) as below.
I will submit a patch to fix it.
diff --git a/tools/perf/arch/x86/util/mem-events.c
b/tools/perf/arch/x86/util/mem-events.c
index 11b8469..588110f 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -31,7 +31,7 @@ char *perf_mem_events__name(int i)
mem_loads_name__init = true;
if (pmu_have_event("cpu", "mem-loads-aux")) {
- scnprintf(mem_loads_name, sizeof(MEM_LOADS_AUX_NAME),
+ scnprintf(mem_loads_name, sizeof(mem_loads_name),
MEM_LOADS_AUX_NAME,
perf_mem_events__loads_ldlat);
} else {
scnprintf(mem_loads_name, sizeof(mem_loads_name),
I'll fold this in the relevant cset.
Thanks!
Kan
[PATCH v2 09/12] kasan: ensure poisoning size alignment
A previous changes d99f6a10c161 ("kasan: don't round_up too much")
attempted to simplify the code by adding a round_up(size) call into
kasan_poison(). While this allows to have less round_up() calls around
the code, this results in round_up() being called multiple times.
This patch removes round_up() of size from kasan_poison() and ensures
that all callers round_up() the size explicitly. This patch also adds
WARN_ON() alignment checks for address and size to kasan_poison() and
kasan_unpoison().
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
mm/kasan/common.c | 9 ++---
mm/kasan/kasan.h | 33 -
mm/kasan/shadow.c | 37 ++---
3 files changed, 48 insertions(+), 31 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index a8a67dca5e55..7ffb1e6de2ef 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -261,7 +261,8 @@ void __kasan_unpoison_object_data(struct kmem_cache *cache,
void *object)
void __kasan_poison_object_data(struct kmem_cache *cache, void *object)
{
- kasan_poison(object, cache->object_size, KASAN_KMALLOC_REDZONE);
+ kasan_poison(object, round_up(cache->object_size, KASAN_GRANULE_SIZE),
+ KASAN_KMALLOC_REDZONE);
}
/*
@@ -348,7 +349,8 @@ static bool kasan_slab_free(struct kmem_cache *cache,
void *object,
return true;
}
- kasan_poison(object, cache->object_size, KASAN_KMALLOC_FREE);
+ kasan_poison(object, round_up(cache->object_size, KASAN_GRANULE_SIZE),
+ KASAN_KMALLOC_FREE);
if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine))
return false;
@@ -490,7 +492,8 @@ static void *kasan_kmalloc(struct kmem_cache *cache,
const void *object,
/* Poison the aligned part of the redzone. */
redzone_start = round_up((unsigned long)(object + size),
KASAN_GRANULE_SIZE);
- redzone_end = (unsigned long)object + cache->object_size;
+ redzone_end = round_up((unsigned long)(object + cache->object_size),
+ KASAN_GRANULE_SIZE);
kasan_poison((void *)redzone_start, redzone_end - redzone_start,
KASAN_KMALLOC_REDZONE);
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 6a2882997f23..98f70ffc9e1c 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -321,30 +321,37 @@ static inline u8 kasan_random_tag(void) { return 0; }
#ifdef CONFIG_KASAN_HW_TAGS
-static inline void kasan_poison(const void *address, size_t size, u8 value)
+static inline void kasan_poison(const void *addr, size_t size, u8 value)
{
- address = kasan_reset_tag(address);
+ addr = kasan_reset_tag(addr);
/* Skip KFENCE memory if called explicitly outside of sl*b. */
- if (is_kfence_address(address))
+ if (is_kfence_address(addr))
return;
- hw_set_mem_tag_range((void *)address,
- round_up(size, KASAN_GRANULE_SIZE), value);
+ if (WARN_ON((unsigned long)addr & KASAN_GRANULE_MASK))
+ return;
+ if (WARN_ON(size & KASAN_GRANULE_MASK))
+ return;
+
+ hw_set_mem_tag_range((void *)addr, size, value);
}
-static inline void kasan_unpoison(const void *address, size_t size)
+static inline void kasan_unpoison(const void *addr, size_t size)
{
- u8 tag = get_tag(address);
+ u8 tag = get_tag(addr);
- address = kasan_reset_tag(address);
+ addr = kasan_reset_tag(addr);
/* Skip KFENCE memory if called explicitly outside of sl*b. */
- if (is_kfence_address(address))
+ if (is_kfence_address(addr))
return;
- hw_set_mem_tag_range((void *)address,
- round_up(size, KASAN_GRANULE_SIZE), tag);
+ if (WARN_ON((unsigned long)addr & KASAN_GRANULE_MASK))
+ return;
+ size = round_up(size, KASAN_GRANULE_SIZE);
+
+ hw_set_mem_tag_range((void *)addr, size, tag);
}
static inline bool kasan_byte_accessible(const void *addr)
@@ -361,7 +368,7 @@ static inline bool kasan_byte_accessible(const void *addr)
/**
* kasan_poison - mark the memory range as unaccessible
* @addr - range start address, must be aligned to KASAN_GRANULE_SIZE
- * @size - range size
+ * @size - range size, must be aligned to KASAN_GRANULE_SIZE
* @value - value that's written to metadata for the range
*
* The size gets aligned to KASAN_GRANULE_SIZE before marking the range.
@@ -371,7 +378,7 @@ void kasan_poison(const void *addr, size_t size, u8 value);
/**
* kasan_unpoison - mark the memory range as accessible
* @addr - range start address, must be aligned to KASAN_GRANULE_SIZE
- * @size - range size
+ * @size - range size, can be unaligned
*
* For the tag-based modes, the @size gets aligned to KASAN_GRANULE_SIZE before
* marking the range.
diff --git a/mm/kasan/shadow.c
[PATCH v2 00/12] kasan: optimizations and fixes for HW_TAGS
This patchset goes on top of: 1. Vincenzo's async support patches [1], and 2. "kasan: untag addresses for KFENCE" fix [2] (already in mm). [1] https://lore.kernel.org/linux-arm-kernel/20210130165225.54047-1-vincenzo.frasc...@arm.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=akpm=dec4728fab910da0c86cf9a97e980f4244ebae9f This patchset makes the HW_TAGS mode more efficient, mostly by reworking poisoning approaches and simplifying/inlining some internal helpers. With this change, the overhead of HW_TAGS annotations excluding setting and checking memory tags is ~3%. The performance impact caused by tags will be unknown until we have hardware that supports MTE. As a side-effect, this patchset speeds up generic KASAN by ~15%. Andrey Konovalov (12): kasan, mm: don't save alloc stacks twice kasan, mm: optimize kmalloc poisoning kasan: optimize large kmalloc poisoning kasan: clean up setting free info in kasan_slab_free kasan: unify large kfree checks kasan: rework krealloc tests kasan, mm: fail krealloc on freed objects kasan, mm: optimize krealloc poisoning kasan: ensure poisoning size alignment arm64: kasan: simplify and inline MTE functions kasan: inline HW_TAGS helper functions arm64: kasan: export MTE symbols for KASAN tests arch/arm64/include/asm/cache.h | 1 - arch/arm64/include/asm/kasan.h | 1 + arch/arm64/include/asm/mte-def.h | 2 + arch/arm64/include/asm/mte-kasan.h | 65 -- arch/arm64/include/asm/mte.h | 2 - arch/arm64/kernel/mte.c| 48 +--- arch/arm64/lib/mte.S | 16 --- include/linux/kasan.h | 25 ++-- lib/test_kasan.c | 111 +++-- mm/kasan/common.c | 187 - mm/kasan/kasan.h | 72 +-- mm/kasan/shadow.c | 53 mm/slab_common.c | 18 ++- mm/slub.c | 3 +- 14 files changed, 418 insertions(+), 186 deletions(-) -- 2.30.0.365.g02bc693789-goog
[PATCH v2 05/12] kasan: unify large kfree checks
Unify checks in kasan_kfree_large() and in kasan_slab_free_mempool()
for large allocations as it's done for small kfree() allocations.
With this change, kasan_slab_free_mempool() starts checking that the
first byte of the memory that's being freed is accessible.
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
include/linux/kasan.h | 16
mm/kasan/common.c | 36 ++--
2 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 2d5de4092185..d53ea3c047bc 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -200,6 +200,13 @@ static __always_inline bool kasan_slab_free(struct
kmem_cache *s, void *object)
return false;
}
+void __kasan_kfree_large(void *ptr, unsigned long ip);
+static __always_inline void kasan_kfree_large(void *ptr)
+{
+ if (kasan_enabled())
+ __kasan_kfree_large(ptr, _RET_IP_);
+}
+
void __kasan_slab_free_mempool(void *ptr, unsigned long ip);
static __always_inline void kasan_slab_free_mempool(void *ptr)
{
@@ -247,13 +254,6 @@ static __always_inline void * __must_check
kasan_krealloc(const void *object,
return (void *)object;
}
-void __kasan_kfree_large(void *ptr, unsigned long ip);
-static __always_inline void kasan_kfree_large(void *ptr)
-{
- if (kasan_enabled())
- __kasan_kfree_large(ptr, _RET_IP_);
-}
-
/*
* Unlike kasan_check_read/write(), kasan_check_byte() is performed even for
* the hardware tag-based mode that doesn't rely on compiler instrumentation.
@@ -302,6 +302,7 @@ static inline bool kasan_slab_free(struct kmem_cache *s,
void *object)
{
return false;
}
+static inline void kasan_kfree_large(void *ptr) {}
static inline void kasan_slab_free_mempool(void *ptr) {}
static inline void *kasan_slab_alloc(struct kmem_cache *s, void *object,
gfp_t flags)
@@ -322,7 +323,6 @@ static inline void *kasan_krealloc(const void *object,
size_t new_size,
{
return (void *)object;
}
-static inline void kasan_kfree_large(void *ptr) {}
static inline bool kasan_check_byte(const void *address)
{
return true;
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index da24b144d46c..7ea643f7e69c 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -364,6 +364,31 @@ bool __kasan_slab_free(struct kmem_cache *cache, void
*object, unsigned long ip)
return kasan_slab_free(cache, object, ip, true);
}
+static bool kasan_kfree_large(void *ptr, unsigned long ip)
+{
+ if (ptr != page_address(virt_to_head_page(ptr))) {
+ kasan_report_invalid_free(ptr, ip);
+ return true;
+ }
+
+ if (!kasan_byte_accessible(ptr)) {
+ kasan_report_invalid_free(ptr, ip);
+ return true;
+ }
+
+ /*
+* The object will be poisoned by kasan_free_pages() or
+* kasan_slab_free_mempool().
+*/
+
+ return false;
+}
+
+void __kasan_kfree_large(void *ptr, unsigned long ip)
+{
+ kasan_kfree_large(ptr, ip);
+}
+
void __kasan_slab_free_mempool(void *ptr, unsigned long ip)
{
struct page *page;
@@ -377,10 +402,8 @@ void __kasan_slab_free_mempool(void *ptr, unsigned long ip)
* KMALLOC_MAX_SIZE, and kmalloc falls back onto page_alloc.
*/
if (unlikely(!PageSlab(page))) {
- if (ptr != page_address(page)) {
- kasan_report_invalid_free(ptr, ip);
+ if (kasan_kfree_large(ptr, ip))
return;
- }
kasan_poison(ptr, page_size(page), KASAN_FREE_PAGE);
} else {
kasan_slab_free(page->slab_cache, ptr, ip, false);
@@ -539,13 +562,6 @@ void * __must_check __kasan_krealloc(const void *object,
size_t size, gfp_t flag
return kasan_kmalloc(page->slab_cache, object, size, flags);
}
-void __kasan_kfree_large(void *ptr, unsigned long ip)
-{
- if (ptr != page_address(virt_to_head_page(ptr)))
- kasan_report_invalid_free(ptr, ip);
- /* The object will be poisoned by kasan_free_pages(). */
-}
-
bool __kasan_check_byte(const void *address, unsigned long ip)
{
if (!kasan_byte_accessible(address)) {
--
2.30.0.365.g02bc693789-goog
[PATCH v2 07/12] kasan, mm: fail krealloc on freed objects
Currently, if krealloc() is called on a freed object with KASAN enabled,
it allocates and returns a new object, but doesn't copy any memory from
the old one as ksize() returns 0. This makes the caller believe that
krealloc() succeeded (KASAN report is printed though).
This patch adds an accessibility check into __do_krealloc(). If the check
fails, krealloc() returns NULL. This check duplicates the one in ksize();
this is fixed in the following patch.
This patch also adds a KASAN-KUnit test to check krealloc() behaviour
when it's called on a freed object.
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
lib/test_kasan.c | 20
mm/slab_common.c | 3 +++
2 files changed, 23 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 6e63ba62db09..791164ef191b 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -359,6 +359,25 @@ static void krealloc_pagealloc_less_oob(struct kunit *test)
KMALLOC_MAX_CACHE_SIZE + 201);
}
+/*
+ * Check that krealloc() detects a use-after-free, returns NULL,
+ * and doesn't unpoison the freed object.
+ */
+static void krealloc_uaf(struct kunit *test)
+{
+ char *ptr1, *ptr2;
+ int size1 = 201;
+ int size2 = 235;
+
+ ptr1 = kmalloc(size1, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr1);
+ kfree(ptr1);
+
+ KUNIT_EXPECT_KASAN_FAIL(test, ptr2 = krealloc(ptr1, size2, GFP_KERNEL));
+ KUNIT_ASSERT_PTR_EQ(test, (void *)ptr2, NULL);
+ KUNIT_EXPECT_KASAN_FAIL(test, *(volatile char *)ptr1);
+}
+
static void kmalloc_oob_16(struct kunit *test)
{
struct {
@@ -1056,6 +1075,7 @@ static struct kunit_case kasan_kunit_test_cases[] = {
KUNIT_CASE(krealloc_less_oob),
KUNIT_CASE(krealloc_pagealloc_more_oob),
KUNIT_CASE(krealloc_pagealloc_less_oob),
+ KUNIT_CASE(krealloc_uaf),
KUNIT_CASE(kmalloc_oob_16),
KUNIT_CASE(kmalloc_uaf_16),
KUNIT_CASE(kmalloc_oob_in_memset),
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 39d1a8ff9bb8..dad70239b54c 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1140,6 +1140,9 @@ static __always_inline void *__do_krealloc(const void *p,
size_t new_size,
void *ret;
size_t ks;
+ if (likely(!ZERO_OR_NULL_PTR(p)) && !kasan_check_byte(p))
+ return NULL;
+
ks = ksize(p);
if (ks >= new_size) {
--
2.30.0.365.g02bc693789-goog
[PATCH v2 03/12] kasan: optimize large kmalloc poisoning
Similarly to kasan_kmalloc(), kasan_kmalloc_large() doesn't need
to unpoison the object as it as already unpoisoned by alloc_pages()
(or by ksize() for krealloc()).
This patch changes kasan_kmalloc_large() to only poison the redzone.
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
mm/kasan/common.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 00edbc3eb32e..f2a6bae13053 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -494,7 +494,6 @@ EXPORT_SYMBOL(__kasan_kmalloc);
void * __must_check __kasan_kmalloc_large(const void *ptr, size_t size,
gfp_t flags)
{
- struct page *page;
unsigned long redzone_start;
unsigned long redzone_end;
@@ -504,12 +503,23 @@ void * __must_check __kasan_kmalloc_large(const void
*ptr, size_t size,
if (unlikely(ptr == NULL))
return NULL;
- page = virt_to_page(ptr);
+ /*
+* The object has already been unpoisoned by kasan_alloc_pages() for
+* alloc_pages() or by ksize() for krealloc().
+*/
+
+ /*
+* The redzone has byte-level precision for the generic mode.
+* Partially poison the last object granule to cover the unaligned
+* part of the redzone.
+*/
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+ kasan_poison_last_granule(ptr, size);
+
+ /* Poison the aligned part of the redzone. */
redzone_start = round_up((unsigned long)(ptr + size),
KASAN_GRANULE_SIZE);
- redzone_end = (unsigned long)ptr + page_size(page);
-
- kasan_unpoison(ptr, size);
+ redzone_end = (unsigned long)ptr + page_size(virt_to_page(ptr));
kasan_poison((void *)redzone_start, redzone_end - redzone_start,
KASAN_PAGE_REDZONE);
--
2.30.0.365.g02bc693789-goog
[PATCH v2 01/12] kasan, mm: don't save alloc stacks twice
Currently KASAN saves allocation stacks in both kasan_slab_alloc() and
kasan_kmalloc() annotations. This patch changes KASAN to save allocation
stacks for slab objects from kmalloc caches in kasan_kmalloc() only,
and stacks for other slab objects in kasan_slab_alloc() only.
This change requires kasan_kmalloc() knowing whether the object
belongs to a kmalloc cache. This is implemented by adding a flag field
to the kasan_info structure. That flag is only set for kmalloc caches
via a new kasan_cache_create_kmalloc() annotation.
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
include/linux/kasan.h | 9 +
mm/kasan/common.c | 18 ++
mm/slab_common.c | 1 +
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 6d8f3227c264..2d5de4092185 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -83,6 +83,7 @@ static inline void kasan_disable_current(void) {}
struct kasan_cache {
int alloc_meta_offset;
int free_meta_offset;
+ bool is_kmalloc;
};
#ifdef CONFIG_KASAN_HW_TAGS
@@ -143,6 +144,13 @@ static __always_inline void kasan_cache_create(struct
kmem_cache *cache,
__kasan_cache_create(cache, size, flags);
}
+void __kasan_cache_create_kmalloc(struct kmem_cache *cache);
+static __always_inline void kasan_cache_create_kmalloc(struct kmem_cache
*cache)
+{
+ if (kasan_enabled())
+ __kasan_cache_create_kmalloc(cache);
+}
+
size_t __kasan_metadata_size(struct kmem_cache *cache);
static __always_inline size_t kasan_metadata_size(struct kmem_cache *cache)
{
@@ -278,6 +286,7 @@ static inline void kasan_free_pages(struct page *page,
unsigned int order) {}
static inline void kasan_cache_create(struct kmem_cache *cache,
unsigned int *size,
slab_flags_t *flags) {}
+static inline void kasan_cache_create_kmalloc(struct kmem_cache *cache) {}
static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0;
}
static inline void kasan_poison_slab(struct page *page) {}
static inline void kasan_unpoison_object_data(struct kmem_cache *cache,
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index fe852f3cfa42..bfdf5464f4ef 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -210,6 +210,11 @@ void __kasan_cache_create(struct kmem_cache *cache,
unsigned int *size,
*size = optimal_size;
}
+void __kasan_cache_create_kmalloc(struct kmem_cache *cache)
+{
+ cache->kasan_info.is_kmalloc = true;
+}
+
size_t __kasan_metadata_size(struct kmem_cache *cache)
{
if (!kasan_stack_collection_enabled())
@@ -394,17 +399,22 @@ void __kasan_slab_free_mempool(void *ptr, unsigned long
ip)
}
}
-static void set_alloc_info(struct kmem_cache *cache, void *object, gfp_t flags)
+static void set_alloc_info(struct kmem_cache *cache, void *object,
+ gfp_t flags, bool is_kmalloc)
{
struct kasan_alloc_meta *alloc_meta;
+ /* Don't save alloc info for kmalloc caches in kasan_slab_alloc(). */
+ if (cache->kasan_info.is_kmalloc && !is_kmalloc)
+ return;
+
alloc_meta = kasan_get_alloc_meta(cache, object);
if (alloc_meta)
kasan_set_track(_meta->alloc_track, flags);
}
static void *kasan_kmalloc(struct kmem_cache *cache, const void *object,
- size_t size, gfp_t flags, bool keep_tag)
+ size_t size, gfp_t flags, bool is_kmalloc)
{
unsigned long redzone_start;
unsigned long redzone_end;
@@ -423,7 +433,7 @@ static void *kasan_kmalloc(struct kmem_cache *cache,
const void *object,
KASAN_GRANULE_SIZE);
redzone_end = round_up((unsigned long)object + cache->object_size,
KASAN_GRANULE_SIZE);
- tag = assign_tag(cache, object, false, keep_tag);
+ tag = assign_tag(cache, object, false, is_kmalloc);
/* Tag is ignored in set_tag without CONFIG_KASAN_SW/HW_TAGS */
kasan_unpoison(set_tag(object, tag), size);
@@ -431,7 +441,7 @@ static void *kasan_kmalloc(struct kmem_cache *cache,
const void *object,
KASAN_KMALLOC_REDZONE);
if (kasan_stack_collection_enabled())
- set_alloc_info(cache, (void *)object, flags);
+ set_alloc_info(cache, (void *)object, flags, is_kmalloc);
return set_tag(object, tag);
}
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 9aa3d2fe4c55..39d1a8ff9bb8 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -647,6 +647,7 @@ struct kmem_cache *__init create_kmalloc_cache(const char
*name,
panic("Out of memory when creating slab %s\n", name);
create_boot_cache(s, name, size, flags, useroffset, usersize);
+
Re: [PATCH v11 2/5] kasan: Add KASAN mode kernel parameter
On 2/5/21 3:49 PM, Andrey Konovalov wrote: > On Mon, Feb 1, 2021 at 9:04 PM Andrey Konovalov wrote: >> >> On Sat, Jan 30, 2021 at 5:52 PM Vincenzo Frascino >> wrote: >>> >>> @@ -45,6 +52,9 @@ static enum kasan_arg_fault kasan_arg_fault >>> __ro_after_init; >>> DEFINE_STATIC_KEY_FALSE(kasan_flag_enabled); >>> EXPORT_SYMBOL(kasan_flag_enabled); >>> >>> +/* Whether the asynchronous mode is enabled. */ >>> +bool kasan_flag_async __ro_after_init; >> >> Just noticed that we need EXPORT_SYMBOL(kasan_flag_async) here. > > Hi Vincenzo, > > If you post a new version of this series, please include > EXPORT_SYMBOL(kasan_flag_async). > I can do that, no problem. > Thanks! > >> >> There are also a few arm64 mte functions that need to be exported, but >> I've addressed that myself here: >> >> https://lore.kernel.org/linux-arm-kernel/cover.1612208222.git.andreyk...@google.com/T/#m4746d3c410c3f6baddb726fc9ea9dd1496a4a788 -- Regards, Vincenzo
Re: [External] Re: [PATCH] mm: memcontrol: fix missing wakeup oom task
On Fri, Feb 5, 2021 at 8:20 PM Michal Hocko wrote: > > On Fri 05-02-21 19:04:19, Muchun Song wrote: > > On Fri, Feb 5, 2021 at 6:21 PM Michal Hocko wrote: > > > > > > On Fri 05-02-21 17:55:10, Muchun Song wrote: > > > > On Fri, Feb 5, 2021 at 4:24 PM Michal Hocko wrote: > > > > > > > > > > On Fri 05-02-21 14:23:10, Muchun Song wrote: > > > > > > We call memcg_oom_recover() in the uncharge_batch() to wakeup OOM > > > > > > task > > > > > > when page uncharged, but for the slab pages, we do not do this when > > > > > > page > > > > > > uncharged. > > > > > > > > > > How does the patch deal with this? > > > > > > > > When we uncharge a slab page via __memcg_kmem_uncharge, > > > > actually, this path forgets to do this for us compared to > > > > uncharge_batch(). Right? > > > > > > Yes this was more more or less clear (still would have been nicer to be > > > explicit). But you still haven't replied to my question I believe. I > > > assume you rely on refill_stock doing draining but how does this address > > > the problem? Is it sufficient to do wakeups in the batched way? > > > > Sorry, the subject title may not be suitable. IIUC, memcg_oom_recover > > aims to wake up the OOM task when we uncharge the page. > > Yes, your understanding is correct. This is a way to pro-actively wake > up oom victims when the memcg oom handling is outsourced to the > userspace. Please note that I haven't objected to the problem statement. > > I was questioning the fix for the problem. > > > I see uncharge_batch always do this. I am confused why > > __memcg_kmem_uncharge does not. > > Very likely an omission. I haven't checked closely but I suspect this > has been introduced by the recent kmem accounting changes. > > Why didn't you simply do the same thing and call memcg_oom_recover > unconditionally and instead depend on the draining? I suspect this was > because you wanted to recover also when draining which is not necessary > as pointed out in other email. Thanks for your explanations. You are right. It is my fault to depend on the draining. I should call memcg_oom_recover directly in the __memcg_kmem_uncharge. Right? > > [...] > > > > > Does this lead to any code generation improvements? I would expect > > > > > compiler to be clever enough to inline static functions if that pays > > > > > off. If yes make this a patch on its own. > > > > > > > > I have disassembled the code, I see memcg_oom_recover is not > > > > inline. Maybe because memcg_oom_recover has a lot of callers. > > > > Just guess. > > > > > > > > (gdb) disassemble uncharge_batch > > > > [...] > > > > 0x81341c73 <+227>: callq 0x8133c420 > > > > > > > > 0x81341c78 <+232>: jmpq 0x81341bc0 > > > > > > > > 0x81341c7d <+237>: callq 0x8133e2c0 > > > > > > > > > > So does it really help to do the inlining? > > > > I just think memcg_oom_recover is very small, inline maybe > > a good choice. Maybe I am wrong. > > In general I am not overly keen on changes without a proper > justification. In this particular case I would understand that a > function call that will almost never do anything but the test (because > oom_disabled is a rarely used) is just waste of cycles in some hot > paths (e.g. kmem uncharge). Maybe this even has some visible performance > benefit. If this is really the case then would it make sense to guard > this test by the existing cgroup_subsys_on_dfl(memory_cgrp_subsys)? Agree. I think it can improve performance when this function is inline. Guarding the test should be also an improvement on cgroup v2. > -- > Michal Hocko > SUSE Labs
Re: [PATCH V3 18/19] virtio_vdpa: don't warn when fail to disable vq
On Mon, Jan 04, 2021 at 02:55:02PM +0800, Jason Wang wrote: > There's no guarantee that the device can disable a specific virtqueue > through set_vq_ready(). One example is the modern virtio-pci > device. So this patch removes the warning. > > Signed-off-by: Jason Wang Do we need the read as a kind of flush though? > --- > drivers/virtio/virtio_vdpa.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c > index 4a9ddb44b2a7..e28acf482e0c 100644 > --- a/drivers/virtio/virtio_vdpa.c > +++ b/drivers/virtio/virtio_vdpa.c > @@ -225,9 +225,8 @@ static void virtio_vdpa_del_vq(struct virtqueue *vq) > list_del(>node); > spin_unlock_irqrestore(_dev->lock, flags); > > - /* Select and deactivate the queue */ > + /* Select and deactivate the queue (best effort) */ > ops->set_vq_ready(vdpa, index, 0); > - WARN_ON(ops->get_vq_ready(vdpa, index)); > > vring_del_virtqueue(vq); > > -- > 2.25.1
Re: [PATCH v5 05/11] crypto: qce: skcipher: Return error for zero length messages
On 2/4/21 7:26 PM, Eric Biggers wrote: On Thu, Feb 04, 2021 at 07:09:53PM -0500, Thara Gopinath wrote: @@ -260,6 +261,10 @@ static int qce_skcipher_crypt(struct skcipher_request *req, int encrypt) rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT; keylen = IS_XTS(rctx->flags) ? ctx->enc_keylen >> 1 : ctx->enc_keylen; + /* CE does not handle 0 length messages */ + if (!req->cryptlen) + return -EOPNOTSUPP; + For the algorithms in question, the correct behavior is to return 0. What do you mean? The driver should return a 0 ? Ok. I will re-spin the series once more with this change.. Yes, there is nothing to do for empty inputs, so just return 0 (success). Aren't the tests catching that difference? I was anyways planning on sending an email to the list with these queries. But since you asked, these are my observations with fuzz testing which I have been doing quite a bit now (I am also working on adding a few qualcomm AEAD algorithms support in mainline). - if the generic algorithm supports 0 length messages and the transformation I am testing does not, the test framework throws an error and stops. - key support mismatch between the generic algorithm vs my algorithm /engine also does the same thing.For eg, Qualcomm CE engine does not support any three keys being same for triple des algorithms. Where as a two key 3des is a valid scenario for generic algorithm(k1=k3). Another example is hardware engine not supporting AES192. How are these scenarios usually handled ? Why not allow the test framework to proceed with the testing if the algorithm does not support a particular scenario ? Omitting support for certain inputs isn't allowed. Anyone in the kernel who wants to use a particular algorithm could get this driver for it, and if they happen to use inputs which the driver decided not to support, things will break. Ya sounds reasonable. The way that drivers handle this is to use a fallback cipher for inputs they don't support. Ok. So I will add this to my todo and make sure to have fallback ciphers for all the non-supported inputs. I will send this as a separate series and not this one. In this case, though not supporting 0 length messages for encryption is valid. I don't think I have to have a fallback for this. I could have sworn that the test framework throws up an error for this. But I have been testing a lot and may be I am just confused. I will double check this. - Eric -- Warm Regards Thara
Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip
On Fri, Feb 05, 2021 at 04:50:13PM +0100, Lino Sanfilippo wrote:
>
> On 05.02.21 16:15, Jason Gunthorpe wrote:
> >
> > No, the cdev layer holds the refcount on the device while open is
> > being called.
> >
> Yes, but the reference that is responsible for the chip deallocation is
> chip->dev
> which is linked to chip->cdev and represents /dev/tpm, not /dev/tpmrm.
> You are right, we dont have the issue with /dev/tpm for the reason you
> mentioned.
> But /dev/tpmrm is represented by chip->cdevs and keeping this ref held by the
> cdev
> layer wont protect us from the chip being freed (which is the reason why we
> need
> the chip->dev reference in the first place).
No, they are all chained together because they are all in the same
struct:
struct tpm_chip {
struct device dev;
struct device devs;
struct cdev cdev;
struct cdev cdevs;
dev holds the refcount on memory, when it goes 0 the whole thing is
kfreed.
The rule is dev's refcount can't go to zero while any other refcount
is != 0.
For instance devs holds a get on dev that is put back only when devs
goes to 0:
static void tpm_devs_release(struct device *dev)
{
struct tpm_chip *chip = container_of(dev, struct tpm_chip, devs);
/* release the master device reference */
put_device(>dev);
}
Both cdev elements do something similar inside the cdev layer.
The net result is during any open() the tpm_chip is guarenteed to have
a positive refcount.
Jason
Re: [PATCH v2] drm/qxl: do not run release if qxl failed to init
On Feb 5, 2021, at 2:43 AM, Gerd Hoffmann wrote: > > On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote: >> if qxl_device_init() fail, drm device will not be registered, >> in this case, do not run qxl_drm_release() > > How do you trigger this? > This can be triggered by changing the QXL VGA rom magic value. In the QEMU source code ./hw/display/qxl.c or change the QXL_ROM_MAGIC in spice header file - Tong > take care, > Gerd >
Re: [PATCH 03/18] ovl: stack miscattr
On Fri, Feb 5, 2021 at 12:49 AM Vivek Goyal wrote:
> > +int ovl_miscattr_set(struct dentry *dentry, struct miscattr *ma)
> > +{
> > + struct inode *inode = d_inode(dentry);
> > + struct dentry *upperdentry;
> > + const struct cred *old_cred;
> > + int err;
> > +
> > + err = ovl_want_write(dentry);
> > + if (err)
> > + goto out;
> > +
> > + err = ovl_copy_up(dentry);
> > + if (!err) {
> > + upperdentry = ovl_dentry_upper(dentry);
> > +
> > + old_cred = ovl_override_creds(inode->i_sb);
> > + /* err = security_file_ioctl(real.file, cmd, arg); */
>
> Is this an comment intended?
I don't remember, but I guess not. Will fix and test.
Thanks,
Miklos
Re: [PATCH v2] openrisc: use device tree to determine present cpus
On Mon, Feb 01, 2021 at 12:49:31PM +0100, Jan Henrik Weinstock wrote: > Use the device tree to determine the present cpus instead of assuming all > CONFIG_NRCPUS are actually present in the system. > > Signed-off-by: Jan Henrik Weinstock Hi Jan, I cannot apply this patch, it seems you somehow sent it signed as a multipart message via Thunderbird. This causes errors when trying to apply, even after I tried to manually fix the patch mail: Applying: openrisc: use device tree to determine present cpus error: sha1 information is lacking or useless (arch/openrisc/kernel/smp.c). error: could not build fake ancestor Patch failed at 0001 openrisc: use device tree to determine present cpus Can you send this using 'git send-email?' If not I can get it applied with some work, otherwise you can point me to a git repo which I can pull it from. -Stafford
Re: [PATCH] fs: notify: inotify: Replace a common bad word with better common word
On Fri, Feb 5, 2021 at 3:12 PM Bhaskar Chowdhury wrote:
>
> On 14:45 Fri 05 Feb 2021, Amir Goldstein wrote:
> >On Fri, Feb 5, 2021 at 2:20 PM Bhaskar Chowdhury
> >wrote:
> >>
> >>
> >>
> >> s/fucked/messed/
> >>
> >> Signed-off-by: Bhaskar Chowdhury
> >> ---
> >> fs/notify/inotify/inotify_user.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/fs/notify/inotify/inotify_user.c
> >> b/fs/notify/inotify/inotify_user.c
> >> index 59c177011a0f..0a9d1a81edf0 100644
> >> --- a/fs/notify/inotify/inotify_user.c
> >> +++ b/fs/notify/inotify/inotify_user.c
> >> @@ -455,7 +455,7 @@ static void inotify_remove_from_idr(struct
> >> fsnotify_group *group,
> >> /*
> >> * We found an mark in the idr at the right wd, but it's
> >> * not the mark we were told to remove. eparis seriously
> >> -* fucked up somewhere.
> >> +* messed up somewhere.
> >> */
> >> if (unlikely(found_i_mark != i_mark)) {
> >> WARN_ONCE(1, "%s: i_mark=%p i_mark->wd=%d i_mark->group=%p
> >> "
> >> --
> >> 2.30.0
> >>
> >
> >Same comment as the previous attempt:
> >
> >https://lore.kernel.org/linux-fsdevel/20181205094913.gc22...@quack2.suse.cz/
> >
> >Please remove the part of the comment that adds no valuable information
> >and fix grammar mistakes.
> >
> I am not sure Amir ..could you please pinpoint that.
>
/*
* We found a mark in the idr at the right wd, but it's
* not the mark we were told to remove.
*/
Thanks,
Amir.
Re: [PATCH 0/6] Support second Image Signal Processor on rk3399
Hi Sebastian, I did some tests myself today as well and can confirm your hdmi related finding - at least when plugged in on boot. I tried some combinations of camera vs. hdmi and it seems really only when hdmi is plugged in on boot (1) - boot - camera --> works (2) - boot - camera - hdmi plugged in - hdmi works - camera --> works (3) - hdmi plugged in - boot - hdmi works - camera --> camera doesn't work (4) - boot - hdmi plugged in - hdmi works - camera -> camera works With a bit of brute-force [0] it seems the camera also works again even with hdmi connected on boot. So conclusion would be that some clock is misbehaving. Now we'll "only" need to find out which one that is. Heiko [0] Don't disable any clock gates diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c index 070dc47e95a1..8daf1fc3388c 100644 --- a/drivers/clk/clk-gate.c +++ b/drivers/clk/clk-gate.c @@ -61,6 +61,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable) set ^= enable; +if (!enable) +return; + if (gate->lock) spin_lock_irqsave(gate->lock, flags); else Am Freitag, 5. Februar 2021, 09:15:47 CET schrieb Heiko Stübner: > Hi Sebastian, > > Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke: > > On 03.02.2021 20:54, Heiko Stübner wrote: > > >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke: > > >> I have tested your patch set on my nanoPC-T4, here is a complete log > > >> with: > > >> - relevant kernel log entries > > >> - system information > > >> - media ctl output > > >> - sysfs entry information > > >> > > >> https://paste.debian.net/1183874/ > > >> > > >> Additionally, to your patchset I have applied the following patches: > > >> https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup > > >> > > >> And just to not cause confusion the `media_dev` entries come from this > > >> unmerged series: > > >> https://patchwork.kernel.org/project/linux-media/list/?series=426269 > > >> > > >> I have actually been able to stream with both of my cameras at the same > > >> time using the libcamera cam command. > > >> I would like to thank you a lot for making this possible. > > > > > >Thanks for testing a dual camera setup. On my board I could only test > > >the second ISP. And really glad it works for you tool :-) . > > > > > >Out of curiosity, do you also see that green tint in the images the cameras > > >produce? > > > > Yes, I do. Actually, I currently have two forms of a green tint, on my > > OV13850 everything is quite dark and greenish, which is caused by the > > missing 3A algorithms. On my OV4689, I have big patches of the image > > with bright green color and flickering, I investigated if this is > > connected to the 2nd ISP instance, but that doesn't seem to be the case > > as I have the same results when I switch the CSI ports of the cameras. > > > > I have found another issue, while testing I discovered following > > issue: > > When I start the system with an HDMI monitor connected, then the camera > > on the 2nd port doesn't work. This is probably because the RX/TX is > > reserved as a TX. > > But it made me wonder because if the system has an RX, a TX, and > > an RX/TX, why isn't the pure TX used by the monitor and the > > cameras take RX and RX/TX? > > Or do you think that this is maybe a malfunction of this patch? > > I don't think it is an issue with this specific series, but still puzzling. > > I.e. the DPHYs are actually only relevant to the DSI controllers, > with TX0 being connected to DSI0 and TX1RX1 being connected > to DSI1. So having an hdmi display _in theory_ shouldn't matter at all. > > Out of curiosity what happens, when you boot without hdmi connected > turn on the cameras, connect the hdmi after this, try the cameras again? > > > Heiko > > > > > > > > >Thanks > > >Heiko > > > > Greetings, > > Sebastian > > > > > > > > > > >> If you like to you can add: > > >> Tested-by: Sebastian Fricke > > >> > > >> On 02.02.2021 15:56, Heiko Stuebner wrote: > > >> >The rk3399 has two ISPs and right now only the first one is usable. > > >> >The second ISP is connected to the TXRX dphy on the soc. > > >> > > > >> >The phy of ISP1 is only accessible through the DSI controller's > > >> >io-memory, so this series adds support for simply using the dsi > > >> >controller is a phy if needed. > > >> > > > >> >That solution is needed at least on rk3399 and rk3288 but no-one > > >> >has looked at camera support on rk3288 at all, so right now > > >> >only implement the rk3399 specifics. > > >> > > > >> > > > >> >Heiko Stuebner (6): > > >> > drm/rockchip: dsi: add own additional pclk handling > > >> > dt-bindings: display: rockchip-dsi: add optional #phy-cells property > > >> > drm/rockchip: dsi: add ability to work as a phy instead of full dsi > > >> > arm64: dts: rockchip: add #phy-cells to mipi-dsi1 > > >> > arm64: dts: rockchip: add cif clk-control pinctrl for rk3399 > > >> > arm64:
Re: [RFC] security: replace indirect calls with static calls
- On Feb 5, 2021, at 10:40 AM, Peter Zijlstra pet...@infradead.org wrote: > On Fri, Feb 05, 2021 at 10:09:26AM -0500, Mathieu Desnoyers wrote: >> Then we should be able to generate the following using static keys as a >> jump table and N static calls: >> >> jump >> label_N: >> stack setup >> call >> label_N-1: >> stack setup >> call >> label_N-2: >> stack setup >> call >> ... >> label_0: >> jump end >> label_fallback: >> >> end: >> >> So the static keys would be used to jump to the appropriate label (using >> a static branch, which has pretty much 0 overhead). Static calls would >> be used to implement each of the calls. >> >> Thoughts ? > > At some point I tried to extend the static_branch infra to do multiple > targets and while the low level plumbing is trivial, I ran into trouble > trying to get a sane C level API for it. Did you try doing an API for a variable number of targets, or was it for a specific number of targets ? It might be easier to just duplicate some of the API code for number of targets between 2 and 12, and let the users code choose the maximum number of targets they want to accelerate. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH 3/5] i2c: stm32f7: add support for DNF i2c-digital-filter binding
Hello all
Looks good to me
Signed-off-by: Pierre-Yves MORDRET
Regards
On 2/5/21 9:51 AM, Alain Volmat wrote:
> Add the support for the i2c-digital-filter binding, allowing to enable
> the digital filter via the device-tree and indicate its value in the DT.
>
> Signed-off-by: Alain Volmat
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c
> b/drivers/i2c/busses/i2c-stm32f7.c
> index 0c539fea2754..f77cd6512a86 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -222,7 +222,6 @@ struct stm32f7_i2c_spec {
> * @clock_src: I2C clock source frequency (Hz)
> * @rise_time: Rise time (ns)
> * @fall_time: Fall time (ns)
> - * @dnf: Digital filter coefficient (0-16)
> * @fmp_clr_offset: Fast Mode Plus clear register offset from set register
> */
> struct stm32f7_i2c_setup {
> @@ -230,7 +229,6 @@ struct stm32f7_i2c_setup {
> u32 clock_src;
> u32 rise_time;
> u32 fall_time;
> - u8 dnf;
> u32 fmp_clr_offset;
> };
>
> @@ -310,6 +308,8 @@ struct stm32f7_i2c_msg {
> * @smbus_mode: states that the controller is configured in SMBus mode
> * @host_notify_client: SMBus host-notify client
> * @analog_filter: boolean to indicate enabling of the analog filter
> + * @dnf_dt: value of digital filter requested via dt
> + * @dnf: value of digital filter to apply
> */
> struct stm32f7_i2c_dev {
> struct i2c_adapter adap;
> @@ -339,6 +339,8 @@ struct stm32f7_i2c_dev {
> bool smbus_mode;
> struct i2c_client *host_notify_client;
> bool analog_filter;
> + u32 dnf_dt;
> + u32 dnf;
> };
>
> /*
> @@ -384,13 +386,11 @@ static struct stm32f7_i2c_spec stm32f7_i2c_specs[] = {
> static const struct stm32f7_i2c_setup stm32f7_setup = {
> .rise_time = STM32F7_I2C_RISE_TIME_DEFAULT,
> .fall_time = STM32F7_I2C_FALL_TIME_DEFAULT,
> - .dnf = STM32F7_I2C_DNF_DEFAULT,
> };
>
> static const struct stm32f7_i2c_setup stm32mp15_setup = {
> .rise_time = STM32F7_I2C_RISE_TIME_DEFAULT,
> .fall_time = STM32F7_I2C_FALL_TIME_DEFAULT,
> - .dnf = STM32F7_I2C_DNF_DEFAULT,
> .fmp_clr_offset = 0x40,
> };
>
> @@ -459,10 +459,11 @@ static int stm32f7_i2c_compute_timing(struct
> stm32f7_i2c_dev *i2c_dev,
> return -EINVAL;
> }
>
> - if (setup->dnf > STM32F7_I2C_DNF_MAX) {
> + i2c_dev->dnf = DIV_ROUND_CLOSEST(i2c_dev->dnf_dt, i2cclk);
> + if (i2c_dev->dnf > STM32F7_I2C_DNF_MAX) {
> dev_err(i2c_dev->dev,
> "DNF out of bound %d/%d\n",
> - setup->dnf, STM32F7_I2C_DNF_MAX);
> + i2c_dev->dnf * i2cclk, STM32F7_I2C_DNF_MAX * i2cclk);
> return -EINVAL;
> }
>
> @@ -473,13 +474,13 @@ static int stm32f7_i2c_compute_timing(struct
> stm32f7_i2c_dev *i2c_dev,
> af_delay_max =
> (i2c_dev->analog_filter ?
>STM32F7_I2C_ANALOG_FILTER_DELAY_MAX : 0);
> - dnf_delay = setup->dnf * i2cclk;
> + dnf_delay = i2c_dev->dnf * i2cclk;
>
> sdadel_min = specs->hddat_min + setup->fall_time -
> - af_delay_min - (setup->dnf + 3) * i2cclk;
> + af_delay_min - (i2c_dev->dnf + 3) * i2cclk;
>
> sdadel_max = specs->vddat_max - setup->rise_time -
> - af_delay_max - (setup->dnf + 4) * i2cclk;
> + af_delay_max - (i2c_dev->dnf + 4) * i2cclk;
>
> scldel_min = setup->rise_time + specs->sudat_min;
>
> @@ -645,6 +646,7 @@ static int stm32f7_i2c_setup_timing(struct
> stm32f7_i2c_dev *i2c_dev,
> setup->speed_freq = t->bus_freq_hz;
> i2c_dev->setup.rise_time = t->scl_rise_ns;
> i2c_dev->setup.fall_time = t->scl_fall_ns;
> + i2c_dev->dnf_dt = t->digital_filter_width_ns;
> setup->clock_src = clk_get_rate(i2c_dev->clk);
>
> if (!setup->clock_src) {
> @@ -652,6 +654,9 @@ static int stm32f7_i2c_setup_timing(struct
> stm32f7_i2c_dev *i2c_dev,
> return -EINVAL;
> }
>
> + if (!of_property_read_bool(i2c_dev->dev->of_node, "i2c-digital-filter"))
> + i2c_dev->dnf_dt = STM32F7_I2C_DNF_DEFAULT;
> +
> do {
> ret = stm32f7_i2c_compute_timing(i2c_dev, setup,
>_dev->timing);
> @@ -681,7 +686,7 @@ static int stm32f7_i2c_setup_timing(struct
> stm32f7_i2c_dev *i2c_dev,
> dev_dbg(i2c_dev->dev, "I2C Rise(%i) and Fall(%i) Time\n",
> setup->rise_time, setup->fall_time);
> dev_dbg(i2c_dev->dev, "I2C Analog Filter(%s), DNF(%i)\n",
> - (i2c_dev->analog_filter ? "On" : "Off"), setup->dnf);
> + (i2c_dev->analog_filter ? "On" : "Off"), i2c_dev->dnf);
>
> i2c_dev->bus_rate = setup->speed_freq;
>
> @@ -732,7 +737,7 @@ static void stm32f7_i2c_hw_config(struct stm32f7_i2c_dev
> *i2c_dev)
>
Re: [PATCH 1/5] i2c: stm32f7: fix configuration of the digital filter
Hello all
Looks good to me
Signed-off-by: Pierre-Yves MORDRET
Regards
On 2/5/21 9:51 AM, Alain Volmat wrote:
> The digital filter related computation are present in the driver
> however the programming of the filter within the IP is missing.
> The maximum value for the DNF is wrong and should be 15 instead of 16.
>
> Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
>
> Signed-off-by: Alain Volmat
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c
> b/drivers/i2c/busses/i2c-stm32f7.c
> index 9aa8e65b511e..473fbe144b7e 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -57,6 +57,8 @@
> #define STM32F7_I2C_CR1_RXDMAEN BIT(15)
> #define STM32F7_I2C_CR1_TXDMAEN BIT(14)
> #define STM32F7_I2C_CR1_ANFOFF BIT(12)
> +#define STM32F7_I2C_CR1_DNF_MASK GENMASK(11, 8)
> +#define STM32F7_I2C_CR1_DNF(n) (((n) & 0xf) << 8)
> #define STM32F7_I2C_CR1_ERRIEBIT(7)
> #define STM32F7_I2C_CR1_TCIE BIT(6)
> #define STM32F7_I2C_CR1_STOPIE BIT(5)
> @@ -160,7 +162,7 @@ enum {
> };
>
> #define STM32F7_I2C_DNF_DEFAULT 0
> -#define STM32F7_I2C_DNF_MAX 16
> +#define STM32F7_I2C_DNF_MAX 15
>
> #define STM32F7_I2C_ANALOG_FILTER_ENABLE 1
> #define STM32F7_I2C_ANALOG_FILTER_DELAY_MIN 50 /* ns */
> @@ -725,6 +727,13 @@ static void stm32f7_i2c_hw_config(struct stm32f7_i2c_dev
> *i2c_dev)
> else
> stm32f7_i2c_set_bits(i2c_dev->base + STM32F7_I2C_CR1,
>STM32F7_I2C_CR1_ANFOFF);
> +
> + /* Program the Digital Filter */
> + stm32f7_i2c_clr_bits(i2c_dev->base + STM32F7_I2C_CR1,
> + STM32F7_I2C_CR1_DNF_MASK);
> + stm32f7_i2c_set_bits(i2c_dev->base + STM32F7_I2C_CR1,
> + STM32F7_I2C_CR1_DNF(i2c_dev->setup.dnf));
> +
> stm32f7_i2c_set_bits(i2c_dev->base + STM32F7_I2C_CR1,
>STM32F7_I2C_CR1_PE);
> }
>
--
--
~ Py MORDRET
--
Re: [PATCH V3 17/19] vdpa: set the virtqueue num during register
On Mon, Jan 04, 2021 at 02:55:01PM +0800, Jason Wang wrote:
> This patch delay the queue number setting to vDPA device
> registering. This allows us to probe the virtqueue numbers between
> device allocation and registering.
>
> Reviewed-by: Stefano Garzarella
> Signed-off-by: Jason Wang
Conflicts with other patches in the vhost tree.
Can you rebase please?
> ---
> drivers/vdpa/ifcvf/ifcvf_main.c | 5 ++---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 5 ++---
> drivers/vdpa/vdpa.c | 8
> drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++--
> include/linux/vdpa.h | 7 +++
> 5 files changed, 13 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
> index 8b4028556cb6..d65f3221d8ed 100644
> --- a/drivers/vdpa/ifcvf/ifcvf_main.c
> +++ b/drivers/vdpa/ifcvf/ifcvf_main.c
> @@ -438,8 +438,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
> }
>
> adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
> - dev, _vdpa_ops,
> - IFCVF_MAX_QUEUE_PAIRS * 2);
> + dev, _vdpa_ops);
> if (adapter == NULL) {
> IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
> return -ENOMEM;
> @@ -463,7 +462,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
> for (i = 0; i < IFCVF_MAX_QUEUE_PAIRS * 2; i++)
> vf->vring[i].irq = -EINVAL;
>
> - ret = vdpa_register_device(>vdpa);
> + ret = vdpa_register_device(>vdpa, IFCVF_MAX_QUEUE_PAIRS * 2);
> if (ret) {
> IFCVF_ERR(pdev, "Failed to register ifcvf to vdpa bus");
> goto err;
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index f1d54814db97..a1b9260bf04d 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1958,8 +1958,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
> max_vqs = MLX5_CAP_DEV_VDPA_EMULATION(mdev, max_num_virtio_queues);
> max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
>
> - ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev,
> mdev->device, _vdpa_ops,
> - 2 * mlx5_vdpa_max_qps(max_vqs));
> + ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev,
> mdev->device, _vdpa_ops);
> if (IS_ERR(ndev))
> return PTR_ERR(ndev);
>
> @@ -1986,7 +1985,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
> if (err)
> goto err_res;
>
> - err = vdpa_register_device(>vdev);
> + err = vdpa_register_device(>vdev, 2 *
> mlx5_vdpa_max_qps(max_vqs));
> if (err)
> goto err_reg;
>
> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> index a69ffc991e13..ba89238f9898 100644
> --- a/drivers/vdpa/vdpa.c
> +++ b/drivers/vdpa/vdpa.c
> @@ -61,7 +61,6 @@ static void vdpa_release_dev(struct device *d)
> * initialized but before registered.
> * @parent: the parent device
> * @config: the bus operations that is supported by this device
> - * @nvqs: number of virtqueues supported by this device
> * @size: size of the parent structure that contains private data
> *
> * Driver should use vdpa_alloc_device() wrapper macro instead of
> @@ -72,7 +71,6 @@ static void vdpa_release_dev(struct device *d)
> */
> struct vdpa_device *__vdpa_alloc_device(struct device *parent,
> const struct vdpa_config_ops *config,
> - int nvqs,
> size_t size)
> {
> struct vdpa_device *vdev;
> @@ -99,7 +97,6 @@ struct vdpa_device *__vdpa_alloc_device(struct device
> *parent,
> vdev->index = err;
> vdev->config = config;
> vdev->features_valid = false;
> - vdev->nvqs = nvqs;
>
> err = dev_set_name(>dev, "vdpa%u", vdev->index);
> if (err)
> @@ -122,11 +119,14 @@ EXPORT_SYMBOL_GPL(__vdpa_alloc_device);
> * vdpa_register_device - register a vDPA device
> * Callers must have a succeed call of vdpa_alloc_device() before.
> * @vdev: the vdpa device to be registered to vDPA bus
> + * @nvqs: number of virtqueues supported by this device
> *
> * Returns an error when fail to add to vDPA bus
> */
> -int vdpa_register_device(struct vdpa_device *vdev)
> +int vdpa_register_device(struct vdpa_device *vdev, int nvqs)
> {
> + vdev->nvqs = nvqs;
> +
> return device_add(>dev);
> }
> EXPORT_SYMBOL_GPL(vdpa_register_device);
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> index 6a90fdb9cbfc..b129cb4dd013 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> @@ -357,7 +357,7 @@ static struct vdpasim *vdpasim_create(void)
> else
> ops = _net_config_ops;
>
Re: [PATCH] tracepoints: Do not punish non static call users
Hi Steven, I love your patch! Perhaps something to improve: [auto build test WARNING on tip/perf/core] [also build test WARNING on linux/master linus/master v5.11-rc6 next-20210125] [cannot apply to hnaz-linux-mm/master] [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/Steven-Rostedt/tracepoints-Do-not-punish-non-static-call-users/20210205-032217 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 32451614da2a9cf4296f90d3606ac77814fb519d config: powerpc-randconfig-r023-20210205 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://github.com/0day-ci/linux/commit/6458987cbf8a57376cd608aa4a066a2e86850cc5 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Steven-Rostedt/tracepoints-Do-not-punish-non-static-call-users/20210205-032217 git checkout 6458987cbf8a57376cd608aa4a066a2e86850cc5 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :121:1: note: expanded from here __do_outl ^ arch/powerpc/include/asm/io.h:537:62: note: expanded from macro '__do_outl' #define __do_outl(val, port)writel(val,(PCI_IO_ADDR)_IO_BASE+port); ~^ In file included from drivers/mtd/devices/docg3.c:15: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :135:1: note: expanded from here __do_insb ^ arch/powerpc/include/asm/io.h:556:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/mtd/devices/docg3.c:15: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :137:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/mtd/devices/docg3.c:15: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :139:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file in
Re: [PATCH 5/5] i2c: stm32f7: indicate the address being accessed on errors
Hello all
Looks good to me
Signed-off-by: Pierre-Yves MORDRET
Regards
On 2/5/21 9:51 AM, Alain Volmat wrote:
> To help debugging issues, add the address of the slave being
> accessed when getting an error.
>
> Signed-off-by: Alain Volmat
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c
> b/drivers/i2c/busses/i2c-stm32f7.c
> index f77cd6512a86..ef642fe1eb2c 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -1602,7 +1602,8 @@ static irqreturn_t stm32f7_i2c_isr_error(int irq, void
> *data)
>
> /* Bus error */
> if (status & STM32F7_I2C_ISR_BERR) {
> - dev_err(dev, "<%s>: Bus error\n", __func__);
> + dev_err(dev, "<%s>: Bus error accessing addr 0x%x\n",
> + __func__, f7_msg->addr);
> writel_relaxed(STM32F7_I2C_ICR_BERRCF, base + STM32F7_I2C_ICR);
> stm32f7_i2c_release_bus(_dev->adap);
> f7_msg->result = -EIO;
> @@ -1610,13 +1611,15 @@ static irqreturn_t stm32f7_i2c_isr_error(int irq,
> void *data)
>
> /* Arbitration loss */
> if (status & STM32F7_I2C_ISR_ARLO) {
> - dev_dbg(dev, "<%s>: Arbitration loss\n", __func__);
> + dev_dbg(dev, "<%s>: Arbitration loss accessing addr 0x%x\n",
> + __func__, f7_msg->addr);
> writel_relaxed(STM32F7_I2C_ICR_ARLOCF, base + STM32F7_I2C_ICR);
> f7_msg->result = -EAGAIN;
> }
>
> if (status & STM32F7_I2C_ISR_PECERR) {
> - dev_err(dev, "<%s>: PEC error in reception\n", __func__);
> + dev_err(dev, "<%s>: PEC error in reception accessing addr
> 0x%x\n",
> + __func__, f7_msg->addr);
> writel_relaxed(STM32F7_I2C_ICR_PECCF, base + STM32F7_I2C_ICR);
> f7_msg->result = -EINVAL;
> }
>
--
--
~ Py MORDRET
--
Re: [PATCH net] net: gro: do not keep too many GRO packets in napi->rx_list
On Fri, Feb 5, 2021 at 2:03 PM Alexander Lobakin wrote: > > > It's strange why mailmap didn't pick up my active email at pm.me. I took the signatures from c80794323e82, I CCed all people involved in this recent patch. It is very rare I use scripts/get_maintainer.pl since it tends to be noisy. > > Anyways, this fix is correct for me. It restores the original Edward's > logics, but without spurious out-of-order deliveries. > Moreover, the pre-patch behaviour can easily be achieved by increasing > net.core.gro_normal_batch if needed. > > Thanks! > > Reviewed-by: Alexander Lobakin > Thanks.
Re: [RFC] security: replace indirect calls with static calls
On Fri, Feb 05, 2021 at 10:09:26AM -0500, Mathieu Desnoyers wrote: > Then we should be able to generate the following using static keys as a > jump table and N static calls: > > jump > label_N: > stack setup > call > label_N-1: > stack setup > call > label_N-2: > stack setup > call > ... > label_0: > jump end > label_fallback: > > end: > > So the static keys would be used to jump to the appropriate label (using > a static branch, which has pretty much 0 overhead). Static calls would > be used to implement each of the calls. > > Thoughts ? At some point I tried to extend the static_branch infra to do multiple targets and while the low level plumbing is trivial, I ran into trouble trying to get a sane C level API for it.
Re: [External] Re: [PATCH] mm: memcontrol: remove rcu_read_lock from get_mem_cgroup_from_page
+Cc Roman On Fri, Feb 5, 2021 at 2:49 AM Michal Hocko wrote: > [snip] > > > > Also, css_get is enough because page > > > > has a reference to the memcg. > > > > > > tryget used to be there to guard against offlined memcg but we have > > > concluded this is impossible in this path. tryget stayed there to catch > > > some unexpected cases IIRC. > > > > Yeah, it can catch some unexpected cases. But why is this path > > special so that we need a tryget? > > I do not remember details and the changelog of that change is not > explicit but I suspect it was just because this one could trigger as > there are external callers to memcg. Is this protection needed? I am not > sure, this is for you to justify if you want to remove it. > It used to be css_tryget_online() which was changed to css_tryget() and from the discussion at [1], it seemed css_get() would be enough but we took a safer route. Anyways, I think we can either take the page_memcg_rcu() route or put explicit restrictions with page lock or lock_page_memcg() to guarantee page and memcg binding. I don't have a strong opinion either way but I think removing restrictions in future for new use-cases will be much harder, so, page_memcg_rcu() approach seems more appropriate at least for now. [1] https://lore.kernel.org/linux-mm/CALvZod5pAv=u8l2tgk0hdy7xaiif2dvjc1omq5bsfzfu_2z...@mail.gmail.com/
Re: [PATCH v24 07/14] mm/damon: Implement a debugfs-based user space interface
On Fri, 5 Feb 2021 16:29:41 +0100 Greg KH wrote:
> On Thu, Feb 04, 2021 at 04:31:43PM +0100, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > DAMON is designed to be used by kernel space code such as the memory
> > management subsystems, and therefore it provides only kernel space API.
> > That said, letting the user space control DAMON could provide some
> > benefits to them. For example, it will allow user space to analyze
> > their specific workloads and make their own special optimizations.
> >
> > For such cases, this commit implements a simple DAMON application kernel
> > module, namely 'damon-dbgfs', which merely wraps the DAMON api and
> > exports those to the user space via the debugfs.
> >
> > 'damon-dbgfs' exports three files, ``attrs``, ``target_ids``, and
> > ``monitor_on`` under its debugfs directory, ``/damon/``.
[...]
> > ---
> > include/linux/damon.h | 3 +
> > mm/damon/Kconfig | 9 +
> > mm/damon/Makefile | 1 +
> > mm/damon/core.c | 47 +
> > mm/damon/dbgfs.c | 387 ++
> > 5 files changed, 447 insertions(+)
> > create mode 100644 mm/damon/dbgfs.c
[...]
> > diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c
> > new file mode 100644
> > index ..db15380737d1
> > --- /dev/null
> > +++ b/mm/damon/dbgfs.c
[...]
> > +
> > +static int dbgfs_fill_ctx_dir(struct dentry *dir, struct damon_ctx *ctx)
> > +{
> > + const char * const file_names[] = {"attrs", "target_ids"};
> > + const struct file_operations *fops[] = {_fops, _ids_fops};
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(file_names); i++) {
> > + if (!debugfs_create_file(file_names[i], 0600, dir,
> > + ctx, fops[i])) {
> > + pr_err("failed to create %s file\n", file_names[i]);
> > + return -ENOMEM;
>
> No need to check the return value of this function, just keep going and
> ignore it as there's nothing to do and kernel code should not do
> different things based on the output of any debugfs calls.
>
> Also, this check is totally wrong and doesn't do what you think it is
> doing...
Ok, I will drop the check.
>
> > +static int __init __damon_dbgfs_init(void)
> > +{
> > + struct dentry *dbgfs_root;
> > + const char * const file_names[] = {"monitor_on"};
> > + const struct file_operations *fops[] = {_on_fops};
> > + int i;
> > +
> > + dbgfs_root = debugfs_create_dir("damon", NULL);
> > + if (IS_ERR(dbgfs_root)) {
> > + pr_err("failed to create the dbgfs dir\n");
> > + return PTR_ERR(dbgfs_root);
>
> Again, no need to check anything, just pass the result of a debugfs call
> back into another one just fine.
Ok.
>
> > + }
> > +
> > + for (i = 0; i < ARRAY_SIZE(file_names); i++) {
> > + if (!debugfs_create_file(file_names[i], 0600, dbgfs_root,
> > + NULL, fops[i])) {
>
> Again, this isn't checking what you think it is, so please don't do it.
Got it.
I will fix those as you suggested in the next version.
Thanks,
SeongJae Park
>
> thanks,
>
> greg k-h
Re: [PATCH 03/18] ovl: stack miscattr
On Fri, Feb 5, 2021 at 4:25 PM Miklos Szeredi wrote:
>
> On Fri, Feb 5, 2021 at 12:49 AM Vivek Goyal wrote:
>
> > > +int ovl_miscattr_set(struct dentry *dentry, struct miscattr *ma)
> > > +{
> > > + struct inode *inode = d_inode(dentry);
> > > + struct dentry *upperdentry;
> > > + const struct cred *old_cred;
> > > + int err;
> > > +
> > > + err = ovl_want_write(dentry);
> > > + if (err)
> > > + goto out;
> > > +
> > > + err = ovl_copy_up(dentry);
> > > + if (!err) {
> > > + upperdentry = ovl_dentry_upper(dentry);
> > > +
> > > + old_cred = ovl_override_creds(inode->i_sb);
> > > + /* err = security_file_ioctl(real.file, cmd, arg); */
> >
> > Is this an comment intended?
>
> I don't remember, but I guess not. Will fix and test.
Sorry, yes, problem is that there's no file pointer available at this point.
Fix is probably to introduce security_inode_miscattr_perm() hook.
Thanks,
Miklos
Re: [PATCH v11 2/5] kasan: Add KASAN mode kernel parameter
On Mon, Feb 1, 2021 at 9:04 PM Andrey Konovalov wrote: > > On Sat, Jan 30, 2021 at 5:52 PM Vincenzo Frascino > wrote: > > > > @@ -45,6 +52,9 @@ static enum kasan_arg_fault kasan_arg_fault > > __ro_after_init; > > DEFINE_STATIC_KEY_FALSE(kasan_flag_enabled); > > EXPORT_SYMBOL(kasan_flag_enabled); > > > > +/* Whether the asynchronous mode is enabled. */ > > +bool kasan_flag_async __ro_after_init; > > Just noticed that we need EXPORT_SYMBOL(kasan_flag_async) here. Hi Vincenzo, If you post a new version of this series, please include EXPORT_SYMBOL(kasan_flag_async). Thanks! > > There are also a few arm64 mte functions that need to be exported, but > I've addressed that myself here: > > https://lore.kernel.org/linux-arm-kernel/cover.1612208222.git.andreyk...@google.com/T/#m4746d3c410c3f6baddb726fc9ea9dd1496a4a788
Re: [PATCH] hrtimer: Interrupt storm on clock_settime
On Thu, Jan 28 2021 at 15:02, Mikael Beckius wrote:
> During clock_settime absolute realtime timers may get updated to expire
> sooner in absolute monotonic time but if hrtimer_force_reprogram is
> called as part of a clock_settime and the next hard hrtimer expires
> before the next soft hrtimer softirq_expires_next will not be updated
> to reflect this change (assuming the realtime timer is a soft timer).
>
> This means that if the next soft hrtimer expires before
> softirq_expires_next but after now no soft hrtimer interrupt will be
> raised in hrtimer_interrupt which will instead retry tick_program_event
> three times before forcing a tick_program_event using a very short delay
> entering hrtimer_interrupt again almost immediately repeating the
> process over and over again until now exceeds softirq_expires_next and a
> soft hrtimer interrupt is finally raised.
Duh.
> This patch aims to solve this by always updating softirq_expires_next if
> a soft hrtimer exists.
git grep 'This patch' Documentation/process/
> Signed-off-by: Mikael Beckius
> ---
> kernel/time/hrtimer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 743c852e10f2..e4c233f404b1 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -633,7 +633,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base
> *cpu_base, int skip_equal)
>*/
> expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL);
>
> - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) {
> + if (cpu_base->softirq_next_timer) {
> /*
>* When the softirq is activated, hrtimer has to be
>* programmed with the first hard hrtimer because soft
> @@ -643,7 +643,8 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base
> *cpu_base, int skip_equal)
> expires_next = __hrtimer_get_next_event(cpu_base,
>
> HRTIMER_ACTIVE_HARD);
> else
> - cpu_base->softirq_expires_next = expires_next;
> + cpu_base->softirq_expires_next =
> __hrtimer_get_next_event(cpu_base,
> +
> HRTIMER_ACTIVE_SOFT);
That works, but we can spare the double scan completely and make the
code understandable. See below.
Thanks,
tglx
---
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -626,26 +626,25 @@ static inline int hrtimer_hres_active(vo
static void
hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal)
{
- ktime_t expires_next;
+ ktime_t expires_next, soft = KTIME_MAX;
/*
-* Find the current next expiration time.
+* If soft interrupt has already been activated, ignore the soft
+* base. It will be handled in the already raised soft interrupt.
*/
- expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL);
-
- if (cpu_base->next_timer && cpu_base->next_timer->is_soft) {
+ if (!cpu_base->softirq_activated) {
+ soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT);
/*
-* When the softirq is activated, hrtimer has to be
-* programmed with the first hard hrtimer because soft
-* timer interrupt could occur too late.
+* Update the soft expiry time. clock_settime() might have
+* affected it.
*/
- if (cpu_base->softirq_activated)
- expires_next = __hrtimer_get_next_event(cpu_base,
-
HRTIMER_ACTIVE_HARD);
- else
- cpu_base->softirq_expires_next = expires_next;
+ cpu_base->softirq_expires_next = soft;
}
+ expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD);
+ if (expires_next > soft)
+ expires_next = soft;
+
if (skip_equal && expires_next == cpu_base->expires_next)
return;
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Fri, Feb 5, 2021 at 4:28 PM Arnaldo Carvalho de Melo wrote: > > Em Fri, Feb 05, 2021 at 04:23:59PM +0100, Sedat Dilek escreveu: > > On Fri, Feb 5, 2021 at 3:41 PM Sedat Dilek wrote: > > > > > > On Fri, Feb 5, 2021 at 3:37 PM Sedat Dilek wrote: > > > > > > > > Hi, > > > > > > > > when building with pahole v1.20 and binutils v2.35.2 plus Clang > > > > v12.0.0-rc1 and DWARF-v5 I see: > > > > ... > > > > + info BTF .btf.vmlinux.bin.o > > > > + [ != silent_ ] > > > > + printf %-7s %s\n BTF .btf.vmlinux.bin.o > > > > BTF .btf.vmlinux.bin.o > > > > + LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J > > > > .tmp_vmlinux.btf > > > > [115] INT DW_ATE_unsigned_1 Error emitting BTF type > > > > Encountered error while encoding BTF. > > > > > > Grepping the pahole sources: > > > > > > $ git grep DW_ATE > > > dwarf_loader.c: bt->is_bool = encoding == DW_ATE_boolean; > > > dwarf_loader.c: bt->is_signed = encoding == DW_ATE_signed; > > > > > > Missing DW_ATE_unsigned encoding? > > > > > > > Checked the LLVM sources: > > > > clang/lib/CodeGen/CGDebugInfo.cpp:Encoding = > > llvm::dwarf::DW_ATE_unsigned_char; > > clang/lib/CodeGen/CGDebugInfo.cpp:Encoding = > > llvm::dwarf::DW_ATE_unsigned; > > clang/lib/CodeGen/CGDebugInfo.cpp:Encoding = > > llvm::dwarf::DW_ATE_unsigned_fixed; > > clang/lib/CodeGen/CGDebugInfo.cpp: > > ? llvm::dwarf::DW_ATE_unsigned > > ... > > lld/test/wasm/debuginfo.test:CHECK-NEXT:DW_AT_encoding > > (DW_ATE_unsigned) > > > > So, I will switch from GNU ld.bfd v2.35.2 to LLD-12. > > Thanks for the research, probably your conclusion is correct, can you go > the next step and add that part and check if the end result is the > expected one? > Started a new build: $ ps -ef | grep p[e]rf dileks529807 529775 0 16:32 pts/100:00:00 /usr/bin/perf_5.10 stat make V=1 -j4 LLVM=1 PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-12-amd64-clang12-llvm KBUIL D_VERBOSE=1 KBUILD_BUILD_HOST=iniza KBUILD_BUILD_USER=sedat.di...@gmail.com KBUILD_BUILD_TIMESTAMP=2021-02-05 bindeb-pkg KDEB_PKGVERSION=5.11.0~rc6-12~bullseye+dileks1 $ scripts/diffconfig /boot/config-5.11.0-rc6-10-amd64-clang12-bfd .config BUILD_SALT "5.11.0-rc6-10-amd64-clang12-bfd" -> "5.11.0-rc6-11-amd64-clang12-llvm" DEBUG_INFO_DWARF4 y -> n LD_VERSION 23502 -> 0 LLD_VERSION 0 -> 12 +DEBUG_INFO_DWARF5 y +LD_IS_LLD y +TOOLS_SUPPORT_RELR y Will take approx. 03:15 [hh:mm] and report later. - Sedat -
Re: [PATCH v19 3/3] scsi: ufs: Prepare HPB read for cached sub-region
On Fri, 2021-02-05 at 14:06 +, Avri Altman wrote: > > > > + put_unaligned_be64(ppn, [6]); > > > > > > You are assuming the HPB entries read out by "HPB Read Buffer" > > > cmd > > > are > > > in Little > > > Endian, which is why you are using put_unaligned_be64 here. > > > However, > > > this assumption > > > is not right for all the other flash vendors - HPB entries read > > > out > > > by > > > "HPB Read Buffer" > > > cmd may come in Big Endian, if so, their random read performance > > > are > > > screwed. > > > > For this question, it is very hard to make a correct format since > > the > > Spec doesn't give a clear definition. Should we have a default > > format, > > if there is conflict, and then add quirk or add a vendor-specific > > table? > > > > Hi Avri > > Do you have a good idea? > > I don't know. Better let Daejun answer this. > This was working for me for both Galaxy S20 (Exynos) as well as > Xiaomi Mi10 (8250). > Thanks, I tested Daejun's patchset before, it is also ok (I don't know which version patchset). maybe we can keep current implementation as default, then if there is conflict, and submit the quirk. Thanks, Bean > Thanks, > Avri
[PATCH v2 11/12] kasan: inline HW_TAGS helper functions
Mark all static functions in common.c and kasan.h that are used for
hardware tag-based KASAN as inline to avoid unnecessary function calls.
Signed-off-by: Andrey Konovalov
---
mm/kasan/common.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 7ffb1e6de2ef..7b53291dafa1 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -279,7 +279,8 @@ void __kasan_poison_object_data(struct kmem_cache *cache,
void *object)
*based on objects indexes, so that objects that are next to each other
*get different tags.
*/
-static u8 assign_tag(struct kmem_cache *cache, const void *object, bool init)
+static inline u8 assign_tag(struct kmem_cache *cache,
+ const void *object, bool init)
{
if (IS_ENABLED(CONFIG_KASAN_GENERIC))
return 0xff;
@@ -321,8 +322,8 @@ void * __must_check __kasan_init_slab_obj(struct kmem_cache
*cache,
return (void *)object;
}
-static bool kasan_slab_free(struct kmem_cache *cache, void *object,
- unsigned long ip, bool quarantine)
+static inline bool kasan_slab_free(struct kmem_cache *cache,
+ void *object, unsigned long ip, bool quarantine)
{
u8 tag;
void *tagged_object;
@@ -366,7 +367,7 @@ bool __kasan_slab_free(struct kmem_cache *cache, void
*object, unsigned long ip)
return kasan_slab_free(cache, object, ip, true);
}
-static bool kasan_kfree_large(void *ptr, unsigned long ip)
+static inline bool kasan_kfree_large(void *ptr, unsigned long ip)
{
if (ptr != page_address(virt_to_head_page(ptr))) {
kasan_report_invalid_free(ptr, ip);
@@ -461,8 +462,8 @@ void * __must_check __kasan_slab_alloc(struct kmem_cache
*cache,
return tagged_object;
}
-static void *kasan_kmalloc(struct kmem_cache *cache, const void *object,
- size_t size, gfp_t flags)
+static inline void *kasan_kmalloc(struct kmem_cache *cache,
+ const void *object, size_t size, gfp_t flags)
{
unsigned long redzone_start;
unsigned long redzone_end;
--
2.30.0.365.g02bc693789-goog
Re: [PATCH v6 05/21] arm64: Initialise as nVHE before switching to VHE
Hi Hector, On 2021-02-05 12:01, Hector Martin 'marcan' wrote: On 01/02/2021 20.56, Marc Zyngier wrote: As we are aiming to be able to control whether we enable VHE or not, let's always drop down to EL1 first, and only then upgrade to VHE if at all possible. This means that if the kernel is booted at EL2, we always start with a nVHE init, drop to EL1 to initialise the the kernel, and only then upgrade the kernel EL to EL2 if possible (the process is obviously shortened for secondary CPUs). Unfortunately, this is going to break on Apple SoCs, where it turns out HCR_EL2.E2H is hard-wired to 1 - there is no nVHE mode. :( #facepalm Thanks for the heads up. That's a blatant violation of the architecture, as the only fixed value allowed is 0. I guess it was tempting for them to ignore about half of the architecture... Oh well. Here's a terrible hack on top of this series. It really doesn't play nicely with the rest of the override stuff, but that's the least of your worries at this stage. I've boot-tested it in a model with E2H artificially forced, and nothing caught fire. YMMV. It also means that if/when we merge the support for this CPU, CONFIG_ARM64_VHE will becomes more or less mandatory... Please let me know if this helps. Thanks, M. diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 2e116ef255e1..bce66d6bda74 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -477,14 +477,13 @@ EXPORT_SYMBOL(kimage_vaddr) * booted in EL1 or EL2 respectively. */ SYM_FUNC_START(init_kernel_el) - mov_q x0, INIT_SCTLR_EL1_MMU_OFF - msr sctlr_el1, x0 - mrs x0, CurrentEL cmp x0, #CurrentEL_EL2 b.eqinit_el2 SYM_INNER_LABEL(init_el1, SYM_L_LOCAL) + mov_q x0, INIT_SCTLR_EL1_MMU_OFF + msr sctlr_el1, x0 isb mov_q x0, INIT_PSTATE_EL1 msr spsr_el1, x0 @@ -504,6 +503,34 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL) msr vbar_el2, x0 isb + /* +* Fruity CPUs seem to have HCR_EL2.E2H set to RES1, +* making it impossible to start in nVHE mode. Is that +* compliant with the architecture? Absolutely not! +*/ + mrs x0, hcr_el2 + and x0, x0, #HCR_E2H + cbz x0, 1f + + /* Switching to VHE requires a sane SCTLR_EL1 as a start */ + mov_q x0, INIT_SCTLR_EL1_MMU_OFF + msr_s SYS_SCTLR_EL12, x0 + + /* +* Force an eret into a helper "function", and let it return +* to our original caller... This makes sure that we have +* initialised the basic PSTATE state. +*/ + mov x0, #INIT_PSTATE_EL2 + msr spsr_el1, x0 + adr_l x0, stick_to_vhe + msr elr_el1, x0 + eret + +1: + mov_q x0, INIT_SCTLR_EL1_MMU_OFF + msr sctlr_el1, x0 + msr elr_el2, lr mov w0, #BOOT_CPU_MODE_EL2 eret diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index 3e08dcc924b5..109a555a1068 100644 --- a/arch/arm64/kernel/hyp-stub.S +++ b/arch/arm64/kernel/hyp-stub.S @@ -27,12 +27,12 @@ SYM_CODE_START(__hyp_stub_vectors) ventry el2_fiq_invalid // FIQ EL2t ventry el2_error_invalid // Error EL2t - ventry el2_sync_invalid// Synchronous EL2h + ventry elx_sync// Synchronous EL2h ventry el2_irq_invalid // IRQ EL2h ventry el2_fiq_invalid // FIQ EL2h ventry el2_error_invalid // Error EL2h - ventry el1_sync// Synchronous 64-bit EL1 + ventry elx_sync// Synchronous 64-bit EL1 ventry el1_irq_invalid // IRQ 64-bit EL1 ventry el1_fiq_invalid // FIQ 64-bit EL1 ventry el1_error_invalid // Error 64-bit EL1 @@ -45,7 +45,7 @@ SYM_CODE_END(__hyp_stub_vectors) .align 11 -SYM_CODE_START_LOCAL(el1_sync) +SYM_CODE_START_LOCAL(elx_sync) cmp x0, #HVC_SET_VECTORS b.ne1f msr vbar_el2, x1 @@ -71,7 +71,7 @@ SYM_CODE_START_LOCAL(el1_sync) 9: mov x0, xzr eret -SYM_CODE_END(el1_sync) +SYM_CODE_END(elx_sync) // nVHE? No way! Give me the real thing! SYM_CODE_START_LOCAL(mutate_to_vhe) @@ -227,3 +227,24 @@ SYM_FUNC_START(switch_to_vhe) #endif ret SYM_FUNC_END(switch_to_vhe) + +SYM_FUNC_START(stick_to_vhe) + /* +* Make sure the switch to VHE cannot fail, by overriding the +* override. This is hilarious. +*/ + adr_l x1, id_aa64mmfr1_override + add x1, x1, #FTR_OVR_MASK_OFFSET + dc civac, x1 + dsb sy + isb + ldr x0, [x1] + bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) + str x0, [x1] + + mov x0, #HVC_VHE_RESTART +
Re: [PATCH 1/8] sched/fair: Clean up active balance nr_balance_failed trickery
On 05/02/21 14:51, Vincent Guittot wrote:
> On Thu, 28 Jan 2021 at 19:32, Valentin Schneider
> wrote:
>>
>> When triggering an active load balance, sd->nr_balance_failed is set to
>> such a value that any further can_migrate_task() using said sd will ignore
>> the output of task_hot().
>>
>> This behaviour makes sense, as active load balance intentionally preempts a
>> rq's running task to migrate it right away, but this asynchronous write is
>> a bit shoddy, as the stopper thread might run active_load_balance_cpu_stop
>> before the sd->nr_balance_failed write either becomes visible to the
>> stopper's CPU or even happens on the CPU that appended the stopper work.
>>
>> Add a struct lb_env flag to denote active balancing, and use it in
>> can_migrate_task(). Remove the sd->nr_balance_failed write that served the
>> same purpose.
>>
>> Signed-off-by: Valentin Schneider
>> ---
>> kernel/sched/fair.c | 17 ++---
>> 1 file changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 197a51473e0c..0f6a4e58ce3c 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -7423,6 +7423,7 @@ enum migration_type {
>> #define LBF_SOME_PINNED0x08
>> #define LBF_NOHZ_STATS 0x10
>> #define LBF_NOHZ_AGAIN 0x20
>> +#define LBF_ACTIVE_LB 0x40
>>
>> struct lb_env {
>> struct sched_domain *sd;
>> @@ -7608,10 +7609,14 @@ int can_migrate_task(struct task_struct *p, struct
>> lb_env *env)
>>
>> /*
>> * Aggressive migration if:
>> -* 1) destination numa is preferred
>> -* 2) task is cache cold, or
>> -* 3) too many balance attempts have failed.
>> +* 1) active balance
>> +* 2) destination numa is preferred
>> +* 3) task is cache cold, or
>> +* 4) too many balance attempts have failed.
>> */
>> + if (env->flags & LBF_ACTIVE_LB)
>> + return 1;
>> +
>
> This changes the behavior for numa system because it skips
> migrate_degrades_locality() which can return 1 and prevent active
> migration whatever nr_balance_failed
>
> Is that intentional ?
>
If I read this right, the result of migrate_degrades_locality() is
(currently) ignored if
env->sd->nr_balance_failed > env->sd->cache_nice_tries
While on the load_balance() side, we have:
/* We've kicked active balancing, force task migration. */
sd->nr_balance_failed = sd->cache_nice_tries+1;
So we should currently be ignoring migrate_degrades_locality() in the
active balance case - what I wrote in the changelog for task_hot() still
applies to migrate_degrades_locality().
WARNING in mc1NUM_get_time
Hello, syzbot found the following issue on: HEAD commit:dd86e7fa Merge tag 'pci-v5.11-fixes-2' of git://git.kernel.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=147f29c4d0 kernel config: https://syzkaller.appspot.com/x/.config?x=e83e68d0a6aba5f6 dashboard link: https://syzkaller.appspot.com/bug?extid=975f176f83908ae98694 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+975f176f83908ae98...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 2 PID: 11674 at drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x665/0x860 drivers/rtc/rtc-mc146818-lib.c:25 Modules linked in: CPU: 2 PID: 11674 Comm: syz-executor.2 Not tainted 5.11.0-rc6-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:mc146818_get_time+0x665/0x860 drivers/rtc/rtc-mc146818-lib.c:25 Code: eb 4e e8 4e 49 c9 fb 4c 89 e6 48 c7 c7 e0 6b b9 8b e8 0f 4f 54 03 bf 58 89 41 00 e8 75 a9 33 fe e9 d5 f9 ff ff e8 2b 49 c9 fb <0f> 0b 48 c7 c7 e0 6b b9 8b 4c 89 e6 45 31 e4 e8 e7 4e 54 03 ba 24 RSP: 0018:c9560d68 EFLAGS: 00010046 RAX: 80010002 RBX: dc00 RCX: RDX: 88806feaa3c0 RSI: 85a98a65 RDI: 0003 RBP: c9560e00 R08: 0001 R09: 0022 R10: 85a98462 R11: R12: 0046 R13: 0022 R14: c9560f18 R15: 888010dd8000 FS: () GS:88802cc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 02c99708 CR3: 66e59000 CR4: 00150ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: hpet_rtc_interrupt+0x2b0/0x380 arch/x86/kernel/hpet.c:1358 __handle_irq_event_percpu+0x303/0x8f0 kernel/irq/handle.c:156 handle_irq_event_percpu kernel/irq/handle.c:196 [inline] handle_irq_event+0x102/0x290 kernel/irq/handle.c:213 handle_edge_irq+0x25f/0xd00 kernel/irq/chip.c:819 asm_call_irq_on_stack+0xf/0x20 __run_irq_on_irqstack arch/x86/include/asm/irq_stack.h:48 [inline] run_irq_on_irqstack_cond arch/x86/include/asm/irq_stack.h:101 [inline] handle_irq arch/x86/kernel/irq.c:230 [inline] __common_interrupt arch/x86/kernel/irq.c:249 [inline] common_interrupt+0x120/0x200 arch/x86/kernel/irq.c:239 asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:620 RIP: 0010:lock_release+0x3d5/0x710 kernel/locking/lockdep.c:5450 Code: 15 02 00 00 48 c7 c7 a0 aa 4b 89 e8 f5 ac a2 07 b8 ff ff ff ff 65 0f c1 05 78 2f a9 7e 83 f8 01 0f 85 67 01 00 00 ff 34 24 9d <48> b8 00 00 00 00 00 fc ff df 48 01 c5 48 c7 45 00 00 00 00 00 c7 RSP: 0018:c90001d076d0 EFLAGS: 0246 RAX: 0001 RBX: 07b81204c4a70325 RCX: c90001d07720 RDX: 11100dfd55a7 RSI: 0001 RDI: RBP: 1920003a0edc R08: R09: R10: 0001 R11: R12: 0001 R13: 0002 R14: 88806feaad40 R15: 88806feaa3c0 zap_pte_range mm/memory.c:1264 [inline] zap_pmd_range mm/memory.c:1368 [inline] zap_pud_range mm/memory.c:1397 [inline] zap_p4d_range mm/memory.c:1418 [inline] unmap_page_range+0xe30/0x2640 mm/memory.c:1439 unmap_single_vma+0x198/0x300 mm/memory.c:1484 unmap_vmas+0x168/0x2e0 mm/memory.c:1516 exit_mmap+0x2b1/0x5a0 mm/mmap.c:3220 __mmput+0x122/0x470 kernel/fork.c:1082 mmput+0x53/0x60 kernel/fork.c:1103 exit_mm kernel/exit.c:501 [inline] do_exit+0xb6a/0x2ae0 kernel/exit.c:812 do_group_exit+0x125/0x310 kernel/exit.c:922 get_signal+0x427/0x20f0 kernel/signal.c:2773 arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811 handle_signal_work kernel/entry/common.c:147 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x148/0x250 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x465b09 Code: Unable to access opcode bytes at RIP 0x465adf. RSP: 002b:7f665e7a5218 EFLAGS: 0246 ORIG_RAX: 00ca RAX: fe00 RBX: 0056bf68 RCX: 00465b09 RDX: RSI: 0080 RDI: 0056bf68 RBP: 0056bf60 R08: R09: R10: R11: 0246 R12: 0056bf6c R13: 7ffeb1baab0f R14: 7f665e7a5300 R15: 00022000 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate
Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
On Wed, Feb 03, 2021 at 06:54:56PM +0200, Vadym Kochan wrote:
> +static struct prestera_lag *prestera_lag_by_dev(struct prestera_switch *sw,
> + struct net_device *dev)
> +{
> + struct prestera_lag *lag;
> + u16 id;
> +
> + for (id = 0; id < sw->lag_max; id++) {
> + lag = >lags[id];
> + if (lag->dev == dev)
> + return lag;
> + }
> +
> + return NULL;
> +}
> +
> +static struct prestera_lag *prestera_lag_create(struct prestera_switch *sw,
> + struct net_device *lag_dev)
> +{
> + struct prestera_lag *lag;
You should initialize with NULL.
> + u16 id;
> +
> + for (id = 0; id < sw->lag_max; id++) {
> + lag = >lags[id];
> + if (!lag->dev)
> + break;
> + }
> + if (lag) {
> + INIT_LIST_HEAD(>members);
> + lag->dev = lag_dev;
> + }
> +
> + return lag;
> +}
> +
> +static void prestera_lag_destroy(struct prestera_switch *sw,
> + struct prestera_lag *lag)
> +{
> + WARN_ON(!list_empty(>members));
> + lag->member_count = 0;
> + lag->dev = NULL;
> +}
> +
> +static int prestera_lag_port_add(struct prestera_port *port,
> + struct net_device *lag_dev)
> +{
> + struct prestera_switch *sw = port->sw;
> + struct prestera_lag *lag;
> + int err;
> +
> + lag = prestera_lag_by_dev(sw, lag_dev);
> + if (!lag) {
> + lag = prestera_lag_create(sw, lag_dev);
> + if (!lag)
> + return -ENOMEM;
I think ENOMEM is reserved for dynamic memory allocation. I think
-ENOSPC may be a better error code (here and everywhere else).
Maybe you would also like to propagate the netlink extack from the
changeupper event and say what went wrong?
> + }
> +
> + if (lag->member_count >= sw->lag_member_max)
> + return -ENOMEM;
> +
> + err = prestera_hw_lag_member_add(port, lag->lag_id);
> + if (err) {
> + if (!lag->member_count)
> + prestera_lag_destroy(sw, lag);
> + return err;
> + }
> +
> + list_add(>lag_member, >members);
> + lag->member_count++;
> + port->lag = lag;
> +
> + return 0;
> +}
> +
> +static int prestera_lag_port_del(struct prestera_port *port)
> +{
> + struct prestera_switch *sw = port->sw;
> + struct prestera_lag *lag = port->lag;
> + int err;
> +
> + if (!lag || !lag->member_count)
> + return -EINVAL;
> +
> + err = prestera_hw_lag_member_del(port, lag->lag_id);
> + if (err)
> + return err;
> +
> + list_del(>lag_member);
> + lag->member_count--;
> + port->lag = NULL;
> +
> + if (netif_is_bridge_port(lag->dev)) {
> + struct netdev_notifier_changeupper_info br_info;
> +
> + br_info.upper_dev = netdev_master_upper_dev_get(lag->dev);
> + br_info.linking = false;
> +
> + prestera_bridge_port_event(lag->dev, port->dev,
> +NETDEV_CHANGEUPPER, _info);
> + }
I think it might be more intuitive if you just call
prestera_port_bridge_leave than simulate a notifier call.
> +
> + if (!lag->member_count)
> + prestera_lag_destroy(sw, lag);
> +
> + return 0;
> +}
> +
> +bool prestera_port_is_lag_member(const struct prestera_port *port)
> +{
> + return !!port->lag;
> +}
> +
> +u16 prestera_port_lag_id(const struct prestera_port *port)
> +{
> + return port->lag->lag_id;
> +}
> +
> +static int prestera_lag_init(struct prestera_switch *sw)
> +{
> + u16 id;
> +
> + sw->lags = kcalloc(sw->lag_max, sizeof(*sw->lags), GFP_KERNEL);
> + if (!sw->lags)
> + return -ENOMEM;
> +
> + for (id = 0; id < sw->lag_max; id++)
> + sw->lags[id].lag_id = id;
> +
> + return 0;
> +}
> +
> +static void prestera_lag_fini(struct prestera_switch *sw)
> +{
> + u8 idx;
> +
> + for (idx = 0; idx < sw->lag_max; idx++)
> + WARN_ON(sw->lags[idx].member_count);
> +
> + kfree(sw->lags);
> +}
> +
> bool prestera_netdev_check(const struct net_device *dev)
> {
> return dev->netdev_ops == _netdev_ops;
> @@ -507,19 +654,54 @@ struct prestera_port
> *prestera_port_dev_lower_find(struct net_device *dev)
> return port;
> }
>
> -static int prestera_netdev_port_event(struct net_device *dev,
> +static int prestera_netdev_port_lower_event(struct net_device *dev,
> + unsigned long event, void *ptr)
> +{
> + struct netdev_notifier_changelowerstate_info *info = ptr;
> + struct netdev_lag_lower_state_info *lower_state_info;
> + struct prestera_port *port = netdev_priv(dev);
> + bool enabled;
> +
> + if (!netif_is_lag_port(dev))
> + return 0;
> + if (!prestera_port_is_lag_member(port))
> +
Re: [PATCH v11 4/5] arm64: mte: Enable async tag check fault
On Sat, Jan 30, 2021 at 04:52:24PM +, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 92078e1eb627..7763ac1f2917 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -182,6 +182,37 @@ bool mte_report_once(void)
> return READ_ONCE(report_fault_once);
> }
>
> +#ifdef CONFIG_KASAN_HW_TAGS
> +void mte_check_tfsr_el1(void)
> +{
> + u64 tfsr_el1;
> +
> + if (!system_supports_mte())
> + return;
> +
> + tfsr_el1 = read_sysreg_s(SYS_TFSR_EL1);
> +
> + /*
> + * The kernel should never trigger an asynchronous fault on a
> + * TTBR0 address, so we should never see TF0 set.
> + * For futexes we disable checks via PSTATE.TCO.
> + */
> + WARN_ONCE(tfsr_el1 & SYS_TFSR_EL1_TF0,
> + "Kernel async tag fault on TTBR0 address");
Sorry, I got confused when I suggested this warning. If the user is
running in async mode, the TFSR_EL1.TF0 bit may be set by
copy_mount_options(), strncpy_from_user() which rely on an actual fault
happening (not the case with asynchronous where only a bit is set). With
the user MTE support, we never report asynchronous faults caused by the
kernel on user addresses as we can't easily track them. So this warning
may be triggered on correctly functioning kernel/user.
> +
> + if (unlikely(tfsr_el1 & SYS_TFSR_EL1_TF1)) {
> + /*
> + * Note: isb() is not required after this direct write
> + * because there is no indirect read subsequent to it
> + * (per ARM DDI 0487F.c table D13-1).
> + */
> + write_sysreg_s(0, SYS_TFSR_EL1);
Zeroing the whole register is still fine, we don't care about the TF0
bit anyway.
> +
> + kasan_report_async();
> + }
> +}
> +#endif
--
Catalin
Re: [RFC 0/9] Linear Address Masking enabling
On Fri, Feb 05, 2021 at 06:16:20PM +0300, Kirill A. Shutemov wrote: > The feature competes for bits with 5-level paging: LAM_U48 makes it > impossible to map anything about 47-bits. The patchset made these > capability mutually exclusive: whatever used first wins. LAM_U57 can be > combined with mappings above 47-bits. And I suppose we still can't switch between 4 and 5 level at runtime, using a CR3 bit?
Re: [PATCH v2 4/4] hugetlb: Do early cow when page pinned on src mm
On Thu, Feb 04, 2021 at 09:11:24PM -0800, Mike Kravetz wrote: [...] > >>> @@ -3787,7 +3803,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, > >>> struct mm_struct *src, > >>> dst_entry = huge_ptep_get(dst_pte); > >>> if ((dst_pte == src_pte) || !huge_pte_none(dst_entry)) > >>> continue; > >>> - > >>> +again: > >>> dst_ptl = huge_pte_lock(h, dst, dst_pte); > >>> src_ptl = huge_pte_lockptr(h, src, src_pte); > >>> spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); > > > > Side question: Mike, do you know why we need this lock_nested()? Could the > > src > > lock be taken due to any reason already? It confused me when I read the > > chunk. > > I see that it was added with commit 4647875819aa. That was when huge pages > used the single per-mm ptl. Lockdep seemed to complain about taking > >page_table_lock twice. Certainly, source and destination mm can not > be the same. Right? Right, at least that's my understanding.. > I do not have the full history, but it 'looks' like > lockdep might have been confused and this was added to keep it quiet. > > BTW - Copy page range for 'normal' pages has the same spin_lock_nested(). Yes. I'll need to take the same lock in v3, so I think I'll just follow. Thanks, -- Peter Xu
Re: [PATCH] drivers: nvmem: Fix voltage settings for QTI qfprom-efuse
Hi,
On Fri, Feb 5, 2021 at 3:29 AM Ravi Kumar Bokka wrote:
>
> QFPROM controller hardware requires 1.8V min for fuse blowing.
> So, this change sets the voltage to 1.8V, required to blow the fuse
> for qfprom-efuse controller.
>
> To disable fuse blowing, we set the voltage to 0V since this may
> be a shared rail and may be able to run at a lower rate when we're
> not blowing fuses.
>
> Fixes: 93b4e49f8c86 ("nvmem: qfprom: Add fuse blowing support")
> Reported-by: Douglas Anderson
> Suggested-by: Douglas Anderson
> Signed-off-by: Ravi Kumar Bokka
> ---
> drivers/nvmem/qfprom.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
> index 6cace24..100d69d 100644
> --- a/drivers/nvmem/qfprom.c
> +++ b/drivers/nvmem/qfprom.c
> @@ -127,6 +127,16 @@ static void qfprom_disable_fuse_blowing(const struct
> qfprom_priv *priv,
> {
> int ret;
>
> + /*
> +* This may be a shared rail and may be able to run at a lower rate
> +* when we're not blowing fuses. At the moment, the regulator
> framework
> +* applies voltage constraints even on disabled rails, so remove our
> +* constraints and allow the rail to be adjusted by other users.
Some year maybe I'll try to fix the regulator framework to not count
voltage constraints for disbled rails, or perhaps have it be optional.
;-) In theory it should be much easier after the patches we already
landed not to count current requests for disabled rails...
> +*/
> + ret = regulator_set_voltage(priv->vcc, 0, INT_MAX);
> + if (ret)
> + dev_warn(priv->dev, "Failed to set 0 voltage (ignoring)\n");
> +
> ret = regulator_disable(priv->vcc);
> if (ret)
> dev_warn(priv->dev, "Failed to disable regulator
> (ignoring)\n");
> @@ -172,6 +182,17 @@ static int qfprom_enable_fuse_blowing(const struct
> qfprom_priv *priv,
> goto err_clk_prepared;
> }
>
> + /*
> +* Hardware requires 1.8V min for fuse blowing; this may be
> +* a rail shared do don't specify a max--regulator constraints
> +* will handle.
> +*/
> + ret = regulator_set_voltage(priv->vcc, 180, INT_MAX);
> + if (ret) {
> + dev_err(priv->dev, "Failed to set 1.8 voltage\n");
> + goto err_clk_rate_set;
> + }
> +
Looks right to me. Assuming that this works.
Reviewed-by: Douglas Anderson
Re: [PATCH v14 0/8] Free some vmemmap pages of HugeTLB page
On 2/4/21 3:50 AM, Muchun Song wrote: > Hi all, > [...] > When a HugeTLB is freed to the buddy system, we should allocate 6 pages for > vmemmap pages and restore the previous mapping relationship. > > Apart from 2MB HugeTLB page, we also have 1GB HugeTLB page. It is similar > to the 2MB HugeTLB page. We also can use this approach to free the vmemmap > pages. > > In this case, for the 1GB HugeTLB page, we can save 4094 pages. This is a > very substantial gain. On our server, run some SPDK/QEMU applications which > will use 1024GB hugetlbpage. With this feature enabled, we can save ~16GB > (1G hugepage)/~12GB (2MB hugepage) memory. > > Because there are vmemmap page tables reconstruction on the freeing/allocating > path, it increases some overhead. Here are some overhead analysis. [...] > Although the overhead has increased, the overhead is not significant. Like > Mike > said, "However, remember that the majority of use cases create hugetlb pages > at > or shortly after boot time and add them to the pool. So, additional overhead > is > at pool creation time. There is no change to 'normal run time' operations of > getting a page from or returning a page to the pool (think page fault/unmap)". > Despite the overhead and in addition to the memory gains from this series ... there's an additional benefit there isn't talked here with your vmemmap page reuse trick. That is page (un)pinners will see an improvement and I presume because there are fewer memmap pages and thus the tail/head pages are staying in cache more often. Out of the box I saw (when comparing linux-next against linux-next + this series) with gup_test and pinning a 16G hugetlb file (with 1G pages): get_user_pages(): ~32k -> ~9k unpin_user_pages(): ~75k -> ~70k Usually any tight loop fetching compound_head(), or reading tail pages data (e.g. compound_head) benefit a lot. There's some unpinning inefficiencies I am fixing[0], but with that in added it shows even more: unpin_user_pages(): ~27k -> ~3.8k FWIW, I was also seeing that with devdax and the ZONE_DEVICE vmemmap page reuse equivalent series[1] but it was mixed with other numbers. Anyways, JFYI :) Joao [0] https://lore.kernel.org/linux-mm/20210204202500.26474-1-joao.m.mart...@oracle.com/ [1] https://lore.kernel.org/linux-mm/20201208172901.17384-1-joao.m.mart...@oracle.com/
Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
> >
> > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > sets them. It turns out that with pre-HDMI2 controllers seemingly there
> > is no issue if polarity is not set. However, with HDMI2 controllers
> > (H6) there often comes to de-synchronization due to phase shift. This
> > causes flickering screen. It's safe to assume that similar issues might
> > happen also with pre-HDMI2 controllers.
> >
> > Solve issue with setting vsync and hsync polarity. Note that display
> > stacks with tcon top have polarity bits actually in tcon0 polarity
> > register.
> >
> > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> > Tested-by: Andre Heider
> > Signed-off-by: Jernej Skrabec
> > ---
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index 6b9af4c08cd6..0d132dae58c0 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon
> > *tcon,
> > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> >
> > + /* Setup the polarity of sync signals */
> > + if (tcon->quirks->polarity_in_ch0) {
> > + val = 0;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > +
> > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> > + } else {
> > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
>
> I think a comment for the origin of this is warranted.
If it's anything like TCON0, it's the pixel clock polarity
Maxime
[PATCH v2 02/12] kasan, mm: optimize kmalloc poisoning
For allocations from kmalloc caches, kasan_kmalloc() always follows
kasan_slab_alloc(). Currenly, both of them unpoison the whole object,
which is unnecessary.
This patch provides separate implementations for both annotations:
kasan_slab_alloc() unpoisons the whole object, and kasan_kmalloc()
only poisons the redzone.
For generic KASAN, the redzone start might not be aligned to
KASAN_GRANULE_SIZE. Therefore, the poisoning is split in two parts:
kasan_poison_last_granule() poisons the unaligned part, and then
kasan_poison() poisons the rest.
This patch also clarifies alignment guarantees of each of the poisoning
functions and drops the unnecessary round_up() call for redzone_end.
With this change, the early SLUB cache annotation needs to be changed to
kasan_slab_alloc(), as kasan_kmalloc() doesn't unpoison objects now.
The number of poisoned bytes for objects in this cache stays the same, as
kmem_cache_node->object_size is equal to sizeof(struct kmem_cache_node).
Reviewed-by: Marco Elver
Signed-off-by: Andrey Konovalov
---
mm/kasan/common.c | 93 +++
mm/kasan/kasan.h | 43 +-
mm/kasan/shadow.c | 28 +++---
mm/slub.c | 3 +-
4 files changed, 119 insertions(+), 48 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index bfdf5464f4ef..00edbc3eb32e 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -278,21 +278,11 @@ void __kasan_poison_object_data(struct kmem_cache *cache,
void *object)
*based on objects indexes, so that objects that are next to each other
*get different tags.
*/
-static u8 assign_tag(struct kmem_cache *cache, const void *object,
- bool init, bool keep_tag)
+static u8 assign_tag(struct kmem_cache *cache, const void *object, bool init)
{
if (IS_ENABLED(CONFIG_KASAN_GENERIC))
return 0xff;
- /*
-* 1. When an object is kmalloc()'ed, two hooks are called:
-*kasan_slab_alloc() and kasan_kmalloc(). We assign the
-*tag only in the first one.
-* 2. We reuse the same tag for krealloc'ed objects.
-*/
- if (keep_tag)
- return get_tag(object);
-
/*
* If the cache neither has a constructor nor has SLAB_TYPESAFE_BY_RCU
* set, assign a tag when the object is being allocated (init == false).
@@ -325,7 +315,7 @@ void * __must_check __kasan_init_slab_obj(struct kmem_cache
*cache,
}
/* Tag is ignored in set_tag() without CONFIG_KASAN_SW/HW_TAGS */
- object = set_tag(object, assign_tag(cache, object, true, false));
+ object = set_tag(object, assign_tag(cache, object, true));
return (void *)object;
}
@@ -413,12 +403,46 @@ static void set_alloc_info(struct kmem_cache *cache, void
*object,
kasan_set_track(_meta->alloc_track, flags);
}
+void * __must_check __kasan_slab_alloc(struct kmem_cache *cache,
+ void *object, gfp_t flags)
+{
+ u8 tag;
+ void *tagged_object;
+
+ if (gfpflags_allow_blocking(flags))
+ kasan_quarantine_reduce();
+
+ if (unlikely(object == NULL))
+ return NULL;
+
+ if (is_kfence_address(object))
+ return (void *)object;
+
+ /*
+* Generate and assign random tag for tag-based modes.
+* Tag is ignored in set_tag() for the generic mode.
+*/
+ tag = assign_tag(cache, object, false);
+ tagged_object = set_tag(object, tag);
+
+ /*
+* Unpoison the whole object.
+* For kmalloc() allocations, kasan_kmalloc() will do precise poisoning.
+*/
+ kasan_unpoison(tagged_object, cache->object_size);
+
+ /* Save alloc info (if possible) for non-kmalloc() allocations. */
+ if (kasan_stack_collection_enabled())
+ set_alloc_info(cache, (void *)object, flags, false);
+
+ return tagged_object;
+}
+
static void *kasan_kmalloc(struct kmem_cache *cache, const void *object,
- size_t size, gfp_t flags, bool is_kmalloc)
+ size_t size, gfp_t flags)
{
unsigned long redzone_start;
unsigned long redzone_end;
- u8 tag;
if (gfpflags_allow_blocking(flags))
kasan_quarantine_reduce();
@@ -429,33 +453,41 @@ static void *kasan_kmalloc(struct kmem_cache *cache,
const void *object,
if (is_kfence_address(kasan_reset_tag(object)))
return (void *)object;
+ /*
+* The object has already been unpoisoned by kasan_slab_alloc() for
+* kmalloc() or by ksize() for krealloc().
+*/
+
+ /*
+* The redzone has byte-level precision for the generic mode.
+* Partially poison the last object granule to cover the unaligned
+* part of the redzone.
+*/
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC))
+
[git pull] IOMMU Fix for Linux v5.11-rc6
Hi Linus, The following changes since commit 1048ba83fb1c00cd24172e23e8263972f6b5d9ac: Linux 5.11-rc6 (2021-01-31 13:50:09 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.11-rc6 for you to fetch changes up to 4c9fb5d9140802db4db9f66c23887f43174e113c: iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it (2021-02-02 15:57:23 +0100) IOMMU Fix for Linux v5.11-rc6 - Fix a possible NULL-ptr dereference in dev_iommu_priv_get() which is too easy to accidentially trigger from IOMMU drivers. In the current case the AMD IOMMU driver triggered it on some machines in the IO-page-fault path, so fix it once and for all. Joerg Roedel (1): iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it include/linux/iommu.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Please pull. Thanks, Joerg
Re: [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM
On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov wrote: > > Provide prctl() interface to enabled LAM for user addresses. Depending > how many tag bits requested it may result in enabling LAM_U57 or > LAM_U48. I prefer the alternate kernel interface based on CET arch_prctl interface which is implemented in glibc on users/intel/lam/master branch: https://gitlab.com/x86-glibc/glibc/-/tree/users/intel/lam/master and in GCC on users/intel/lam/master branch: https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master -- H.J.
Re: [External] Re: [PATCH v14 3/8] mm: hugetlb: free the vmemmap pages associated with each HugeTLB page
On Fri, Feb 5, 2021 at 4:54 PM Oscar Salvador wrote:
>
> On Thu, Feb 04, 2021 at 11:50:38AM +0800, Muchun Song wrote:
> > Every HugeTLB has more than one struct page structure. We __know__ that
> > we only use the first 4(HUGETLB_CGROUP_MIN_ORDER) struct page structures
> > to store metadata associated with each HugeTLB.
> >
> > There are a lot of struct page structures associated with each HugeTLB
> > page. For tail pages, the value of compound_head is the same. So we can
> > reuse first page of tail page structures. We map the virtual addresses
> > of the remaining pages of tail page structures to the first tail page
> > struct, and then free these page frames. Therefore, we need to reserve
> > two pages as vmemmap areas.
> >
> > When we allocate a HugeTLB page from the buddy, we can free some vmemmap
> > pages associated with each HugeTLB page. It is more appropriate to do it
> > in the prep_new_huge_page().
> >
> > The free_vmemmap_pages_per_hpage(), which indicates how many vmemmap
> > pages associated with a HugeTLB page can be freed, returns zero for
> > now, which means the feature is disabled. We will enable it once all
> > the infrastructure is there.
> >
> > Signed-off-by: Muchun Song
> > ---
>
> [...]
>
> > +void free_huge_page_vmemmap(struct hstate *h, struct page *head)
> > +{
> > + unsigned long vmemmap_addr = (unsigned long)head;
> > + unsigned long vmemmap_end, vmemmap_reuse;
> > +
> > + if (!free_vmemmap_pages_per_hpage(h))
> > + return;
> > +
> > + vmemmap_addr += RESERVE_VMEMMAP_SIZE;
> > + vmemmap_end = vmemmap_addr + free_vmemmap_pages_size_per_hpage(h);
> > + vmemmap_reuse = vmemmap_addr - PAGE_SIZE;
> > +
> > + /*
> > + * Remap the vmemmap virtual address range [@vmemmap_addr,
> > @vmemmap_end)
> > + * to the page which @vmemmap_reuse is mapped to, then free the
> > vmemmap
> > + * pages which the range are mapped to.
>
> "then free the pages which the range [@vmemmap_addr, @vmemmap_end] is mapped
> to."
>
> I am not a native but sounds better to me.
Me too. But I believe you are right. :-)
>
> > + */
> > + vmemmap_remap_free(vmemmap_addr, vmemmap_end, vmemmap_reuse);
> > +}
> > diff --git a/mm/hugetlb_vmemmap.h b/mm/hugetlb_vmemmap.h
> > new file mode 100644
> > index ..6923f03534d5
> > --- /dev/null
> > +++ b/mm/hugetlb_vmemmap.h
>
> [...]
>
> > diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> > index 16183d85a7d5..50c1dc00b686 100644
> > --- a/mm/sparse-vmemmap.c
> > +++ b/mm/sparse-vmemmap.c
> > @@ -27,8 +27,215 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +
> > #include
> > #include
> > +#include
> > +
> > +/**
> > + * vmemmap_remap_walk - walk vmemmap page table
> > + *
> > + * @remap_pte: called for each non-empty PTE (lowest-level)
> > entry.
>
> Well, we BUG_ON on empty PTE, so not sure that pointing out here is worth.
> It sounds like we do nothing when it's empty.
> Maybe:
>
> "called for each lowest-level entry (PTE)"
Thanks. I will update this.
>
> > + * @reuse_page: the page which is reused for the tail vmemmap
> > pages.
> > + * @reuse_addr: the virtual address of the @reuse_page page.
> > + * @vmemmap_pages: the list head of the vmemmap pages that can be freed.
> > + */
> > +struct vmemmap_remap_walk {
> > + void (*remap_pte)(pte_t *pte, unsigned long addr,
> > + struct vmemmap_remap_walk *walk);
> > + struct page *reuse_page;
> > + unsigned long reuse_addr;
> > + struct list_head *vmemmap_pages;
> > +};
> > +
> > +static void vmemmap_pte_range(pmd_t *pmd, unsigned long addr,
> > + unsigned long end,
> > + struct vmemmap_remap_walk *walk)
> > +{
> > + pte_t *pte;
> > +
> > + pte = pte_offset_kernel(pmd, addr);
> > +
> > + /*
> > + * The reuse_page is found 'first' in table walk before we start
> > + * remapping (which is calling @walk->remap_pte).
> > + */
> > + if (!walk->reuse_page) {
> > + BUG_ON(pte_none(*pte) || walk->reuse_addr != addr);
>
> I would rather have them in separate lines:
> BUG_ON(pte_none(*pte));
> BUG_ON(walk->reuse_addr != addr));
>
> It helps when trying to figure out when we explode. One could dig in the
> registers, but let's make it easier to find out.
OK. Will do.
>
> > +
>
> [...]
>
>
> > +static void vmemmap_remap_range(unsigned long start, unsigned long end,
> > + struct vmemmap_remap_walk *walk)
> > +{
> > + unsigned long addr = start;
> > + unsigned long next;
> > + pgd_t *pgd;
> > +
> > + VM_BUG_ON(!IS_ALIGNED(start, PAGE_SIZE));
> > + VM_BUG_ON(!IS_ALIGNED(end, PAGE_SIZE));
> > +
> > + pgd = pgd_offset_k(addr);
> > + do {
> > + BUG_ON(pgd_none(*pgd));
> > +
> > + next = pgd_addr_end(addr, end);
> > + vmemmap_p4d_range(pgd, addr, next,
Re: [PATCH 0/3] fs/efs: Follow kernel style guide
On Fri, Feb 5, 2021 at 5:1 AM David Sterba wrote: > > On Thu, Feb 04, 2021 at 08:52:14PM -0800, Amy Parker wrote: > > As the EFS driver is old and non-maintained, > > Is anybody using EFS on current kernels? There's not much point updating > it to current coding style, deleting fs/efs is probably the best option. > Wouldn't be surprised if there's a few systems out there that haven't migrated at all. > The EFS name is common for several filesystems, not to be confused with > eg. Encrypted File System. In linux it's the IRIX version, check > Kconfig, and you could hardly find the utilities to create such > filesystem. Ah yep, good point. -Amy IP
Re: [PATCH v2] mm: memcontrol: replace the loop with a list_for_each_entry()
On Fri 05-02-21 00:30:55, Muchun Song wrote:
> The rule of list walk has gone since:
>
> commit a9d5adeeb4b2 ("mm/memcontrol: allow to uncharge page without using
> page->lru field")
>
> So remove the strange comment and replace the loop with a
> list_for_each_entry().
>
> There is only one caller of the uncharge_list(). So just fold it into
> mem_cgroup_uncharge_list() and remove it.
>
> Signed-off-by: Muchun Song
Acked-by: Michal Hocko
Thanks!
> ---
> v2:
> - Fold uncharge_list() to mem_cgroup_uncharge_list().
>
> mm/memcontrol.c | 35 ---
> 1 file changed, 8 insertions(+), 27 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ed5cc78a8dbf..8c035846c7a4 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6862,31 +6862,6 @@ static void uncharge_page(struct page *page, struct
> uncharge_gather *ug)
> css_put(>memcg->css);
> }
>
> -static void uncharge_list(struct list_head *page_list)
> -{
> - struct uncharge_gather ug;
> - struct list_head *next;
> -
> - uncharge_gather_clear();
> -
> - /*
> - * Note that the list can be a single page->lru; hence the
> - * do-while loop instead of a simple list_for_each_entry().
> - */
> - next = page_list->next;
> - do {
> - struct page *page;
> -
> - page = list_entry(next, struct page, lru);
> - next = page->lru.next;
> -
> - uncharge_page(page, );
> - } while (next != page_list);
> -
> - if (ug.memcg)
> - uncharge_batch();
> -}
> -
> /**
> * mem_cgroup_uncharge - uncharge a page
> * @page: page to uncharge
> @@ -6918,11 +6893,17 @@ void mem_cgroup_uncharge(struct page *page)
> */
> void mem_cgroup_uncharge_list(struct list_head *page_list)
> {
> + struct uncharge_gather ug;
> + struct page *page;
> +
> if (mem_cgroup_disabled())
> return;
>
> - if (!list_empty(page_list))
> - uncharge_list(page_list);
> + uncharge_gather_clear();
> + list_for_each_entry(page, page_list, lru)
> + uncharge_page(page, );
> + if (ug.memcg)
> + uncharge_batch();
> }
>
> /**
> --
> 2.11.0
--
Michal Hocko
SUSE Labs
