From: Clément Péron <[email protected]>
[ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ]
When running dtbs_check thermal_zone warn about the
temperature declared.
thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000
It's indeed wrong the real value is 85°C and not 850°C.
Signed-off-by: Clément Péron <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index e0a9b371c248f..2265ca24c0c71 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -143,7 +143,7 @@ map0 {
trips {
cpu_alert0: cpu-alert0 {
/* milliCelsius */
- temperature = <850000>;
+ temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
--
2.27.0
From: Scott K Logan <[email protected]>
[ Upstream commit a1afbbb0285797e01313779c71287d936d069245 ]
This adds the missing perpheral clock for the RNG for Amlogic G12. As
stated in amlogic,meson-rng.yaml, this isn't always necessary for the
RNG to function, but is better to have in case the clock is disabled for
some reason prior to loading.
Signed-off-by: Scott K Logan <[email protected]>
Suggested-by: Neil Armstrong <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 1234bc7974294..354ef2f3eac67 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -167,6 +167,8 @@ apb_efuse: bus@30000 {
hwrng: rng@218 {
compatible = "amlogic,meson-rng";
reg = <0x0 0x218 0x0 0x4>;
+ clocks = <&clkc CLKID_RNG0>;
+ clock-names = "core";
};
};
--
2.27.0
From: Zhang Qilong <[email protected]>
[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ]
Initial value of rc is '-ENXIO', and we should
use the initial value to check it.
Signed-off-by: Zhang Qilong <[email protected]>
Reviewed-by: Pankaj Gupta <[email protected]>
Reviewed-by: Vishal Verma <[email protected]>
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 12d980aafc5ff..9d78f29cf9967 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1553,7 +1553,7 @@ static ssize_t format1_show(struct device *dev,
le16_to_cpu(nfit_dcr->dcr->code));
break;
}
- if (rc != ENXIO)
+ if (rc != -ENXIO)
break;
}
mutex_unlock(&acpi_desc->init_mutex);
--
2.27.0
From: zhenwei pi <[email protected]>
[ Upstream commit 25c1ca6ecaba3b751d3f7ff92d5cddff3b05f8d0 ]
Receiving a zero length message leads to the following warnings because
the CQE is processed twice:
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 0 at lib/refcount.c:28
RIP: 0010:refcount_warn_saturate+0xd9/0xe0
Call Trace:
<IRQ>
nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma]
__ib_process_cq+0x76/0x150 [ib_core]
...
Sanity check the received data length, to avoids this.
Thanks to Chao Leng & Sagi for suggestions.
Signed-off-by: zhenwei pi <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/nvme/host/rdma.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index abe4fe496d05c..cb5aecb018901 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1520,6 +1520,14 @@ static void nvme_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc)
return;
}
+ /* sanity checking for received data length */
+ if (unlikely(wc->byte_len < len)) {
+ dev_err(queue->ctrl->ctrl.device,
+ "Unexpected nvme completion length(%d)\n", wc->byte_len);
+ nvme_rdma_error_recovery(queue->ctrl);
+ return;
+ }
+
ib_dma_sync_single_for_cpu(ibdev, qe->dma, len, DMA_FROM_DEVICE);
/*
* AEN requests are special as they don't time out and can
--
2.27.0
From: Ming Lei <[email protected]>
[ Upstream commit 831e3405c2a344018a18fcc2665acc5a38c3a707 ]
The current scanning mechanism is supposed to fall back to a synchronous
host scan if an asynchronous scan is in progress. However, this rule isn't
strictly respected, scsi_prep_async_scan() doesn't hold scan_mutex when
checking shost->async_scan. When scsi_scan_host() is called concurrently,
two async scans on same host can be started and a hang in do_scan_async()
is observed.
Fixes this issue by checking & setting shost->async_scan atomically with
shost->scan_mutex.
Link: https://lore.kernel.org/r/[email protected]
Cc: Christoph Hellwig <[email protected]>
Cc: Ewan D. Milne <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Cc: Bart Van Assche <[email protected]>
Reviewed-by: Lee Duncan <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Ming Lei <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/scsi/scsi_scan.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 058079f915f18..79232cef1af16 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1715,15 +1715,16 @@ static void scsi_sysfs_add_devices(struct Scsi_Host *shost)
*/
static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
{
- struct async_scan_data *data;
+ struct async_scan_data *data = NULL;
unsigned long flags;
if (strncmp(scsi_scan_type, "sync", 4) == 0)
return NULL;
+ mutex_lock(&shost->scan_mutex);
if (shost->async_scan) {
shost_printk(KERN_DEBUG, shost, "%s called twice\n", __func__);
- return NULL;
+ goto err;
}
data = kmalloc(sizeof(*data), GFP_KERNEL);
@@ -1734,7 +1735,6 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
goto err;
init_completion(&data->prev_finished);
- mutex_lock(&shost->scan_mutex);
spin_lock_irqsave(shost->host_lock, flags);
shost->async_scan = 1;
spin_unlock_irqrestore(shost->host_lock, flags);
@@ -1749,6 +1749,7 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
return data;
err:
+ mutex_unlock(&shost->scan_mutex);
kfree(data);
return NULL;
}
--
2.27.0
From: Maxime Ripard <[email protected]>
[ Upstream commit 84c971b356379c621df595bd00c3114579dfa59f ]
The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.
The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.
Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.
Signed-off-by: Maxime Ripard <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++++++--------------------
drivers/gpu/drm/sun4i/sun4i_frontend.h | 6 +----
2 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b97..7462801b1fa8e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
* related to the scaler FIR filter phase parameters.
*/
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
- frontend->data->ch_phase[0].horzphase);
+ frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
- frontend->data->ch_phase[1].horzphase);
+ frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
- frontend->data->ch_phase[0].vertphase[0]);
+ frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
- frontend->data->ch_phase[1].vertphase[0]);
+ frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
- frontend->data->ch_phase[0].vertphase[1]);
+ frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
- frontend->data->ch_phase[1].vertphase[1]);
+ frontend->data->ch_phase[1]);
/*
* Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
};
static const struct sun4i_frontend_data sun4i_a10_frontend = {
- .ch_phase = {
- {
- .horzphase = 0,
- .vertphase = { 0, 0 },
- },
- {
- .horzphase = 0xfc000,
- .vertphase = { 0xfc000, 0xfc000 },
- },
- },
+ .ch_phase = { 0x000, 0xfc000 },
.has_coef_rdy = true,
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = {
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- },
+ .ch_phase = { 0x400, 0x400 },
.has_coef_access_ctrl = true,
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0fe..2e7b76e50c2ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
struct sun4i_frontend_data {
bool has_coef_access_ctrl;
bool has_coef_rdy;
-
- struct {
- u32 horzphase;
- u32 vertphase[2];
- } ch_phase[2];
+ u32 ch_phase[2];
};
struct sun4i_frontend {
--
2.27.0
From: Martin Blumenstingl <[email protected]>
[ Upstream commit 1fdc97ae450ede2b4911d6737a57e6fca63b5f4a ]
We have a dedicated "amlogic,meson-g12a-dwmac" compatible string for the
Ethernet controller since commit 3efdb92426bf4 ("dt-bindings: net:
dwmac-meson: Add a compatible string for G12A onwards").
Using the AXG compatible string worked fine so far because the
dwmac-meson8b driver doesn't handle the newly introduced register bits
for G12A. However, once that changes the driver must be probed with the
correct compatible string to manage these new register bits.
Signed-off-by: Martin Blumenstingl <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 354ef2f3eac67..a25fe33baebc2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -96,7 +96,7 @@ soc {
ranges;
ethmac: ethernet@ff3f0000 {
- compatible = "amlogic,meson-axg-dwmac",
+ compatible = "amlogic,meson-g12a-dwmac",
"snps,dwmac-3.70a",
"snps,dwmac";
reg = <0x0 0xff3f0000 0x0 0x10000>,
--
2.27.0
Hi Sasha,
On Tue, Nov 3, 2020 at 2:20 AM Sasha Levin <[email protected]> wrote:
>
> From: Martin Blumenstingl <[email protected]>
>
> [ Upstream commit 1fdc97ae450ede2b4911d6737a57e6fca63b5f4a ]
>
> We have a dedicated "amlogic,meson-g12a-dwmac" compatible string for the
> Ethernet controller since commit 3efdb92426bf4 ("dt-bindings: net:
> dwmac-meson: Add a compatible string for G12A onwards").
> Using the AXG compatible string worked fine so far because the
> dwmac-meson8b driver doesn't handle the newly introduced register bits
> for G12A. However, once that changes the driver must be probed with the
> correct compatible string to manage these new register bits.
>
> Signed-off-by: Martin Blumenstingl <[email protected]>
> Reviewed-by: Neil Armstrong <[email protected]>
> Signed-off-by: Kevin Hilman <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Sasha Levin <[email protected]>
if this patch will be included in 5.4-stable then please also backport
the following two commits:
- 3efdb92426bf4 ("dt-bindings: net: dwmac-meson: Add a compatible
string for G12A onwards")
- a4f63342d03d2d ("net: stmmac: dwmac-meson8b: add a compatible string
for G12A SoCs")
Without these above two commits we'll lose Ethernet connectivity
because there's no G12A compatible string in 5.4 yet
The quick solution would be to not backport this patch because the
driver in question doesn't do anything with the new compatible string
yet.
Best regards,
Martin
On Tue, Nov 03, 2020 at 06:53:17AM +0100, Martin Blumenstingl wrote:
>Hi Sasha,
>
>On Tue, Nov 3, 2020 at 2:20 AM Sasha Levin <[email protected]> wrote:
>>
>> From: Martin Blumenstingl <[email protected]>
>>
>> [ Upstream commit 1fdc97ae450ede2b4911d6737a57e6fca63b5f4a ]
>>
>> We have a dedicated "amlogic,meson-g12a-dwmac" compatible string for the
>> Ethernet controller since commit 3efdb92426bf4 ("dt-bindings: net:
>> dwmac-meson: Add a compatible string for G12A onwards").
>> Using the AXG compatible string worked fine so far because the
>> dwmac-meson8b driver doesn't handle the newly introduced register bits
>> for G12A. However, once that changes the driver must be probed with the
>> correct compatible string to manage these new register bits.
>>
>> Signed-off-by: Martin Blumenstingl <[email protected]>
>> Reviewed-by: Neil Armstrong <[email protected]>
>> Signed-off-by: Kevin Hilman <[email protected]>
>> Link: https://lore.kernel.org/r/[email protected]
>> Signed-off-by: Sasha Levin <[email protected]>
>if this patch will be included in 5.4-stable then please also backport
>the following two commits:
>- 3efdb92426bf4 ("dt-bindings: net: dwmac-meson: Add a compatible
>string for G12A onwards")
>- a4f63342d03d2d ("net: stmmac: dwmac-meson8b: add a compatible string
>for G12A SoCs")
>
>Without these above two commits we'll lose Ethernet connectivity
>because there's no G12A compatible string in 5.4 yet
>
>The quick solution would be to not backport this patch because the
>driver in question doesn't do anything with the new compatible string
>yet.
I'll drop it from older branches that don't have those commits, thanks!
--
Thanks,
Sasha