All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH AUTOSEL 4.19 219/252] ath10k: pci: Only dump ATH10K_MEM_REGION_TYPE_IOREG when safe
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Bryan O'Donoghue, Kalle Valo, Sasha Levin, ath10k,
	linux-wireless, netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

[ Upstream commit d239380196c4e27a26fa4bea73d2bf994c14ec2d ]

ath10k_pci_dump_memory_reg() will try to access memory of type
ATH10K_MEM_REGION_TYPE_IOREG however, if a hardware restart is in progress
this can crash a system.

Individual ioread32() time has been observed to jump from 15-20 ticks to >
80k ticks followed by a secure-watchdog bite and a system reset.

Work around this corner case by only issuing the read transaction when the
driver state is ATH10K_STATE_ON.

Tested-on: QCA9988 PCI 10.4-3.9.0.2-00044

Fixes: 219cc084c6706 ("ath10k: add memory dump support QCA9984")
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/ath/ath10k/pci.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 2a503aacf0c64..caece8339a50a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1613,11 +1613,22 @@ static int ath10k_pci_dump_memory_reg(struct ath10k *ar,
 {
 	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
 	u32 i;
+	int ret;
+
+	mutex_lock(&ar->conf_mutex);
+	if (ar->state != ATH10K_STATE_ON) {
+		ath10k_warn(ar, "Skipping pci_dump_memory_reg invalid state\n");
+		ret = -EIO;
+		goto done;
+	}
 
 	for (i = 0; i < region->len; i += 4)
 		*(u32 *)(buf + i) = ioread32(ar_pci->mem + region->start + i);
 
-	return region->len;
+	ret = region->len;
+done:
+	mutex_unlock(&ar->conf_mutex);
+	return ret;
 }
 
 /* if an error happened returns < 0, otherwise the length */
@@ -1713,7 +1724,11 @@ static void ath10k_pci_dump_memory(struct ath10k *ar,
 			count = ath10k_pci_dump_memory_sram(ar, current_region, buf);
 			break;
 		case ATH10K_MEM_REGION_TYPE_IOREG:
-			count = ath10k_pci_dump_memory_reg(ar, current_region, buf);
+			ret = ath10k_pci_dump_memory_reg(ar, current_region, buf);
+			if (ret < 0)
+				break;
+
+			count = ret;
 			break;
 		default:
 			ret = ath10k_pci_dump_memory_generic(ar, current_region, buf);
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 220/252] hostap: Adjust indentation in prism2_hostapd_add_sta
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Nathan Chancellor, Nick Desaulniers, Kalle Valo, Sasha Levin,
	linux-wireless, netdev, clang-built-linux
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Nathan Chancellor <natechancellor@gmail.com>

[ Upstream commit b61156fba74f659d0bc2de8f2dbf5bad9f4b8faf ]

Clang warns:

../drivers/net/wireless/intersil/hostap/hostap_ap.c:2511:3: warning:
misleading indentation; statement is not part of the previous 'if'
[-Wmisleading-indentation]
        if (sta->tx_supp_rates & WLAN_RATE_5M5)
        ^
../drivers/net/wireless/intersil/hostap/hostap_ap.c:2509:2: note:
previous statement is here
        if (sta->tx_supp_rates & WLAN_RATE_2M)
        ^
1 warning generated.

This warning occurs because there is a space before the tab on this
line. Remove it so that the indentation is consistent with the Linux
kernel coding style and clang no longer warns.

Fixes: ff1d2767d5a4 ("Add HostAP wireless driver.")
Link: https://github.com/ClangBuiltLinux/linux/issues/813
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/intersil/hostap/hostap_ap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ap.c b/drivers/net/wireless/intersil/hostap/hostap_ap.c
index 0094b1d2b5770..3ec46f48cfde1 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ap.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ap.c
@@ -2508,7 +2508,7 @@ static int prism2_hostapd_add_sta(struct ap_data *ap,
 		sta->supported_rates[0] = 2;
 	if (sta->tx_supp_rates & WLAN_RATE_2M)
 		sta->supported_rates[1] = 4;
- 	if (sta->tx_supp_rates & WLAN_RATE_5M5)
+	if (sta->tx_supp_rates & WLAN_RATE_5M5)
 		sta->supported_rates[2] = 11;
 	if (sta->tx_supp_rates & WLAN_RATE_11M)
 		sta->supported_rates[3] = 22;
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 113/252] drm/mediatek: handle events when enabling/disabling crtc
From: Sasha Levin @ 2020-02-14 16:09 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, dri-devel, linux-mediatek, Bibby Hsieh, CK Hu,
	linux-arm-kernel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Bibby Hsieh <bibby.hsieh@mediatek.com>

[ Upstream commit 411f5c1eacfebb1f6e40b653d29447cdfe7282aa ]

The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.

Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 92ecb9bf982cf..b86ee7d25af36 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -308,6 +308,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
 static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
 {
 	struct drm_device *drm = mtk_crtc->base.dev;
+	struct drm_crtc *crtc = &mtk_crtc->base;
 	int i;
 
 	DRM_DEBUG_DRIVER("%s\n", __func__);
@@ -329,6 +330,13 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
 	mtk_disp_mutex_unprepare(mtk_crtc->mutex);
 
 	pm_runtime_put(drm->dev);
+
+	if (crtc->state->event && !crtc->state->active) {
+		spin_lock_irq(&crtc->dev->event_lock);
+		drm_crtc_send_vblank_event(crtc, crtc->state->event);
+		crtc->state->event = NULL;
+		spin_unlock_irq(&crtc->dev->event_lock);
+	}
 }
 
 static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
-- 
2.20.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply related

* Re: [PATCH 1/2] rtc: sun6i: Make external 32k oscillator optional
From: Jernej Škrabec @ 2020-02-14 16:42 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: mark.rutland, a.zummo, alexandre.belloni, devicetree,
	linux-kernel, wens, robh+dt, linux-arm-kernel, linux-rtc
In-Reply-To: <20200214081443.ajz2sxh5ztk6qb2i@gilmour.lan>

Hi Maxime,

Dne petek, 14. februar 2020 ob 09:14:43 CET je Maxime Ripard napisal(a):
> Hi Jernej,
> 
> Thanks for taking care of this
> 
> On Thu, Feb 13, 2020 at 10:14:26PM +0100, Jernej Skrabec wrote:
> > Some boards, like OrangePi PC2 (H5), OrangePi Plus 2E (H3) and Tanix TX6
> > (H6) don't have external 32kHz oscillator. Till H6, it didn't really
> > matter if external oscillator was enabled because HW detected error and
> > fall back to internal one. H6 has same functionality but it's the first
> > SoC which have "auto switch bypass" bit documented and always enabled in
> > driver. This prevents RTC to work correctly if external crystal is not
> > present on board. There are other side effects - all peripherals which
> > depends on this clock also don't work (HDMI CEC for example).
> > 
> > Make clocks property optional. If it is present, select external
> > oscillator. If not, stay on internal.
> > 
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> > 
> >  drivers/rtc/rtc-sun6i.c | 14 ++++++--------
> >  1 file changed, 6 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index 852f5f3b3592..538cf7e19034 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -250,19 +250,17 @@ static void __init sun6i_rtc_clk_init(struct
> > device_node *node,> 
> >  		writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> >  	
> >  	}
> > 
> > -	/* Switch to the external, more precise, oscillator */
> > -	reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > -	if (rtc->data->has_losc_en)
> > -		reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > +	/* Switch to the external, more precise, oscillator, if present */
> > +	if (of_get_property(node, "clocks", NULL)) {
> > +		reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > +		if (rtc->data->has_losc_en)
> > +			reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > +	}
> > 
> >  	writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> >  	
> >  	/* Yes, I know, this is ugly. */
> >  	sun6i_rtc = rtc;
> > 
> > -	/* Deal with old DTs */
> > -	if (!of_get_property(node, "clocks", NULL))
> > -		goto err;
> > -
> 
> Doesn't that prevent the parents to be properly set if there's an
> external crystal?

No, why?

Check these two clk_summary:
http://ix.io/2bHY Tanix TX6 (no external crystal)
http://ix.io/2bI2 OrangePi 3 (external crystal present)

Please disregard ac200_clk in first case, it's part of another work.

Best regards,
Jernej




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH AUTOSEL 4.19 221/252] rtlwifi: rtl8821ae: remove unused variables
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
	netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: YueHaibing <yuehaibing@huawei.com>

[ Upstream commit cc071a6f26aae3321cf193dc2e8c35090709b8ab ]

drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:142:17:
 warning: cckswing_table_ch1ch13 defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:178:17:
 warning: cckswing_table_ch14 defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:96:18:
 warning: ofdmswing_table defined but not used [-Wunused-const-variable=]

These variable is never used, so remove them.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 .../wireless/realtek/rtlwifi/rtl8821ae/dm.c   | 118 ------------------
 1 file changed, 118 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
index 3be8c88971e2c..91b8c6babfcd0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
@@ -115,124 +115,6 @@ static const u32 rtl8821ae_txscaling_table[TXSCALE_TABLE_SIZE] = {
 	0x3FE  /* 36, +6.0dB */
 };
 
-static const u32 ofdmswing_table[] = {
-	0x0b40002d, /* 0, -15.0dB */
-	0x0c000030, /* 1, -14.5dB */
-	0x0cc00033, /* 2, -14.0dB */
-	0x0d800036, /* 3, -13.5dB */
-	0x0e400039, /* 4, -13.0dB */
-	0x0f00003c, /* 5, -12.5dB */
-	0x10000040, /* 6, -12.0dB */
-	0x11000044, /* 7, -11.5dB */
-	0x12000048, /* 8, -11.0dB */
-	0x1300004c, /* 9, -10.5dB */
-	0x14400051, /* 10, -10.0dB */
-	0x15800056, /* 11, -9.5dB */
-	0x16c0005b, /* 12, -9.0dB */
-	0x18000060, /* 13, -8.5dB */
-	0x19800066, /* 14, -8.0dB */
-	0x1b00006c, /* 15, -7.5dB */
-	0x1c800072, /* 16, -7.0dB */
-	0x1e400079, /* 17, -6.5dB */
-	0x20000080, /* 18, -6.0dB */
-	0x22000088, /* 19, -5.5dB */
-	0x24000090, /* 20, -5.0dB */
-	0x26000098, /* 21, -4.5dB */
-	0x288000a2, /* 22, -4.0dB */
-	0x2ac000ab, /* 23, -3.5dB */
-	0x2d4000b5, /* 24, -3.0dB */
-	0x300000c0, /* 25, -2.5dB */
-	0x32c000cb, /* 26, -2.0dB */
-	0x35c000d7, /* 27, -1.5dB */
-	0x390000e4, /* 28, -1.0dB */
-	0x3c8000f2, /* 29, -0.5dB */
-	0x40000100, /* 30, +0dB */
-	0x43c0010f, /* 31, +0.5dB */
-	0x47c0011f, /* 32, +1.0dB */
-	0x4c000130, /* 33, +1.5dB */
-	0x50800142, /* 34, +2.0dB */
-	0x55400155, /* 35, +2.5dB */
-	0x5a400169, /* 36, +3.0dB */
-	0x5fc0017f, /* 37, +3.5dB */
-	0x65400195, /* 38, +4.0dB */
-	0x6b8001ae, /* 39, +4.5dB */
-	0x71c001c7, /* 40, +5.0dB */
-	0x788001e2, /* 41, +5.5dB */
-	0x7f8001fe  /* 42, +6.0dB */
-};
-
-static const u8 cckswing_table_ch1ch13[CCK_TABLE_SIZE][8] = {
-	{0x09, 0x08, 0x07, 0x06, 0x04, 0x03, 0x01, 0x01}, /* 0, -16.0dB */
-	{0x09, 0x09, 0x08, 0x06, 0x05, 0x03, 0x01, 0x01}, /* 1, -15.5dB */
-	{0x0a, 0x09, 0x08, 0x07, 0x05, 0x03, 0x02, 0x01}, /* 2, -15.0dB */
-	{0x0a, 0x0a, 0x09, 0x07, 0x05, 0x03, 0x02, 0x01}, /* 3, -14.5dB */
-	{0x0b, 0x0a, 0x09, 0x08, 0x06, 0x04, 0x02, 0x01}, /* 4, -14.0dB */
-	{0x0b, 0x0b, 0x0a, 0x08, 0x06, 0x04, 0x02, 0x01}, /* 5, -13.5dB */
-	{0x0c, 0x0c, 0x0a, 0x09, 0x06, 0x04, 0x02, 0x01}, /* 6, -13.0dB */
-	{0x0d, 0x0c, 0x0b, 0x09, 0x07, 0x04, 0x02, 0x01}, /* 7, -12.5dB */
-	{0x0d, 0x0d, 0x0c, 0x0a, 0x07, 0x05, 0x02, 0x01}, /* 8, -12.0dB */
-	{0x0e, 0x0e, 0x0c, 0x0a, 0x08, 0x05, 0x02, 0x01}, /* 9, -11.5dB */
-	{0x0f, 0x0f, 0x0d, 0x0b, 0x08, 0x05, 0x03, 0x01}, /* 10, -11.0dB */
-	{0x10, 0x10, 0x0e, 0x0b, 0x08, 0x05, 0x03, 0x01}, /* 11, -10.5dB */
-	{0x11, 0x11, 0x0f, 0x0c, 0x09, 0x06, 0x03, 0x01}, /* 12, -10.0dB */
-	{0x12, 0x12, 0x0f, 0x0c, 0x09, 0x06, 0x03, 0x01}, /* 13, -9.5dB */
-	{0x13, 0x13, 0x10, 0x0d, 0x0a, 0x06, 0x03, 0x01}, /* 14, -9.0dB */
-	{0x14, 0x14, 0x11, 0x0e, 0x0b, 0x07, 0x03, 0x02}, /* 15, -8.5dB */
-	{0x16, 0x15, 0x12, 0x0f, 0x0b, 0x07, 0x04, 0x01}, /* 16, -8.0dB */
-	{0x17, 0x16, 0x13, 0x10, 0x0c, 0x08, 0x04, 0x02}, /* 17, -7.5dB */
-	{0x18, 0x17, 0x15, 0x11, 0x0c, 0x08, 0x04, 0x02}, /* 18, -7.0dB */
-	{0x1a, 0x19, 0x16, 0x12, 0x0d, 0x09, 0x04, 0x02}, /* 19, -6.5dB */
-	{0x1b, 0x1a, 0x17, 0x13, 0x0e, 0x09, 0x04, 0x02}, /* 20, -6.0dB */
-	{0x1d, 0x1c, 0x18, 0x14, 0x0f, 0x0a, 0x05, 0x02}, /* 21, -5.5dB */
-	{0x1f, 0x1e, 0x1a, 0x15, 0x10, 0x0a, 0x05, 0x02}, /* 22, -5.0dB */
-	{0x20, 0x20, 0x1b, 0x16, 0x11, 0x08, 0x05, 0x02}, /* 23, -4.5dB */
-	{0x22, 0x21, 0x1d, 0x18, 0x11, 0x0b, 0x06, 0x02}, /* 24, -4.0dB */
-	{0x24, 0x23, 0x1f, 0x19, 0x13, 0x0c, 0x06, 0x03}, /* 25, -3.5dB */
-	{0x26, 0x25, 0x21, 0x1b, 0x14, 0x0d, 0x06, 0x03}, /* 26, -3.0dB */
-	{0x28, 0x28, 0x22, 0x1c, 0x15, 0x0d, 0x07, 0x03}, /* 27, -2.5dB */
-	{0x2b, 0x2a, 0x25, 0x1e, 0x16, 0x0e, 0x07, 0x03}, /* 28, -2.0dB */
-	{0x2d, 0x2d, 0x27, 0x1f, 0x18, 0x0f, 0x08, 0x03}, /* 29, -1.5dB */
-	{0x30, 0x2f, 0x29, 0x21, 0x19, 0x10, 0x08, 0x03}, /* 30, -1.0dB */
-	{0x33, 0x32, 0x2b, 0x23, 0x1a, 0x11, 0x08, 0x04}, /* 31, -0.5dB */
-	{0x36, 0x35, 0x2e, 0x25, 0x1c, 0x12, 0x09, 0x04} /* 32, +0dB */
-};
-
-static const u8 cckswing_table_ch14[CCK_TABLE_SIZE][8] = {
-	{0x09, 0x08, 0x07, 0x04, 0x00, 0x00, 0x00, 0x00}, /* 0, -16.0dB */
-	{0x09, 0x09, 0x08, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 1, -15.5dB */
-	{0x0a, 0x09, 0x08, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 2, -15.0dB */
-	{0x0a, 0x0a, 0x09, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 3, -14.5dB */
-	{0x0b, 0x0a, 0x09, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 4, -14.0dB */
-	{0x0b, 0x0b, 0x0a, 0x06, 0x00, 0x00, 0x00, 0x00}, /* 5, -13.5dB */
-	{0x0c, 0x0c, 0x0a, 0x06, 0x00, 0x00, 0x00, 0x00}, /* 6, -13.0dB */
-	{0x0d, 0x0c, 0x0b, 0x06, 0x00, 0x00, 0x00, 0x00}, /* 7, -12.5dB */
-	{0x0d, 0x0d, 0x0c, 0x07, 0x00, 0x00, 0x00, 0x00}, /* 8, -12.0dB */
-	{0x0e, 0x0e, 0x0c, 0x07, 0x00, 0x00, 0x00, 0x00}, /* 9, -11.5dB */
-	{0x0f, 0x0f, 0x0d, 0x08, 0x00, 0x00, 0x00, 0x00}, /* 10, -11.0dB */
-	{0x10, 0x10, 0x0e, 0x08, 0x00, 0x00, 0x00, 0x00}, /* 11, -10.5dB */
-	{0x11, 0x11, 0x0f, 0x09, 0x00, 0x00, 0x00, 0x00}, /* 12, -10.0dB */
-	{0x12, 0x12, 0x0f, 0x09, 0x00, 0x00, 0x00, 0x00}, /* 13, -9.5dB */
-	{0x13, 0x13, 0x10, 0x0a, 0x00, 0x00, 0x00, 0x00}, /* 14, -9.0dB */
-	{0x14, 0x14, 0x11, 0x0a, 0x00, 0x00, 0x00, 0x00}, /* 15, -8.5dB */
-	{0x16, 0x15, 0x12, 0x0b, 0x00, 0x00, 0x00, 0x00}, /* 16, -8.0dB */
-	{0x17, 0x16, 0x13, 0x0b, 0x00, 0x00, 0x00, 0x00}, /* 17, -7.5dB */
-	{0x18, 0x17, 0x15, 0x0c, 0x00, 0x00, 0x00, 0x00}, /* 18, -7.0dB */
-	{0x1a, 0x19, 0x16, 0x0d, 0x00, 0x00, 0x00, 0x00}, /* 19, -6.5dB */
-	{0x1b, 0x1a, 0x17, 0x0e, 0x00, 0x00, 0x00, 0x00}, /* 20, -6.0dB */
-	{0x1d, 0x1c, 0x18, 0x0e, 0x00, 0x00, 0x00, 0x00}, /* 21, -5.5dB */
-	{0x1f, 0x1e, 0x1a, 0x0f, 0x00, 0x00, 0x00, 0x00}, /* 22, -5.0dB */
-	{0x20, 0x20, 0x1b, 0x10, 0x00, 0x00, 0x00, 0x00}, /* 23, -4.5dB */
-	{0x22, 0x21, 0x1d, 0x11, 0x00, 0x00, 0x00, 0x00}, /* 24, -4.0dB */
-	{0x24, 0x23, 0x1f, 0x12, 0x00, 0x00, 0x00, 0x00}, /* 25, -3.5dB */
-	{0x26, 0x25, 0x21, 0x13, 0x00, 0x00, 0x00, 0x00}, /* 26, -3.0dB */
-	{0x28, 0x28, 0x24, 0x14, 0x00, 0x00, 0x00, 0x00}, /* 27, -2.5dB */
-	{0x2b, 0x2a, 0x25, 0x15, 0x00, 0x00, 0x00, 0x00}, /* 28, -2.0dB */
-	{0x2d, 0x2d, 0x17, 0x17, 0x00, 0x00, 0x00, 0x00}, /* 29, -1.5dB */
-	{0x30, 0x2f, 0x29, 0x18, 0x00, 0x00, 0x00, 0x00}, /* 30, -1.0dB */
-	{0x33, 0x32, 0x2b, 0x19, 0x00, 0x00, 0x00, 0x00}, /* 31, -0.5dB */
-	{0x36, 0x35, 0x2e, 0x1b, 0x00, 0x00, 0x00, 0x00} /* 32, +0dB */
-};
-
 static const u32 edca_setting_dl[PEER_MAX] = {
 	0xa44f,		/* 0 UNKNOWN */
 	0x5ea44f,	/* 1 REALTEK_90 */
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 222/252] rtlwifi: rtl8192ee: remove unused variables
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
	netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: YueHaibing <yuehaibing@huawei.com>

[ Upstream commit 253e5aba937973fd29bd5c559d21e35d0642242e ]

drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:15:18:
 warning: ofdmswing_table defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:61:17:
 warning: cckswing_table_ch1ch13 defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:97:17:
 warning: cckswing_table_ch14 defined but not used [-Wunused-const-variable=]

These variable is never used, so remove them.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 .../wireless/realtek/rtlwifi/rtl8192ee/dm.c   | 118 ------------------
 1 file changed, 118 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index faed6e2dedf6e..2965a033549f8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -34,124 +34,6 @@
 #include "fw.h"
 #include "trx.h"
 
-static const u32 ofdmswing_table[OFDM_TABLE_SIZE] = {
-	0x7f8001fe,		/* 0, +6.0dB */
-	0x788001e2,		/* 1, +5.5dB */
-	0x71c001c7,		/* 2, +5.0dB */
-	0x6b8001ae,		/* 3, +4.5dB */
-	0x65400195,		/* 4, +4.0dB */
-	0x5fc0017f,		/* 5, +3.5dB */
-	0x5a400169,		/* 6, +3.0dB */
-	0x55400155,		/* 7, +2.5dB */
-	0x50800142,		/* 8, +2.0dB */
-	0x4c000130,		/* 9, +1.5dB */
-	0x47c0011f,		/* 10, +1.0dB */
-	0x43c0010f,		/* 11, +0.5dB */
-	0x40000100,		/* 12, +0dB */
-	0x3c8000f2,		/* 13, -0.5dB */
-	0x390000e4,		/* 14, -1.0dB */
-	0x35c000d7,		/* 15, -1.5dB */
-	0x32c000cb,		/* 16, -2.0dB */
-	0x300000c0,		/* 17, -2.5dB */
-	0x2d4000b5,		/* 18, -3.0dB */
-	0x2ac000ab,		/* 19, -3.5dB */
-	0x288000a2,		/* 20, -4.0dB */
-	0x26000098,		/* 21, -4.5dB */
-	0x24000090,		/* 22, -5.0dB */
-	0x22000088,		/* 23, -5.5dB */
-	0x20000080,		/* 24, -6.0dB */
-	0x1e400079,		/* 25, -6.5dB */
-	0x1c800072,		/* 26, -7.0dB */
-	0x1b00006c,		/* 27. -7.5dB */
-	0x19800066,		/* 28, -8.0dB */
-	0x18000060,		/* 29, -8.5dB */
-	0x16c0005b,		/* 30, -9.0dB */
-	0x15800056,		/* 31, -9.5dB */
-	0x14400051,		/* 32, -10.0dB */
-	0x1300004c,		/* 33, -10.5dB */
-	0x12000048,		/* 34, -11.0dB */
-	0x11000044,		/* 35, -11.5dB */
-	0x10000040,		/* 36, -12.0dB */
-	0x0f00003c,		/* 37, -12.5dB */
-	0x0e400039,		/* 38, -13.0dB */
-	0x0d800036,		/* 39, -13.5dB */
-	0x0cc00033,		/* 40, -14.0dB */
-	0x0c000030,		/* 41, -14.5dB */
-	0x0b40002d,		/* 42, -15.0dB */
-};
-
-static const u8 cckswing_table_ch1ch13[CCK_TABLE_SIZE][8] = {
-	{0x36, 0x35, 0x2e, 0x25, 0x1c, 0x12, 0x09, 0x04}, /* 0, +0dB */
-	{0x33, 0x32, 0x2b, 0x23, 0x1a, 0x11, 0x08, 0x04}, /* 1, -0.5dB */
-	{0x30, 0x2f, 0x29, 0x21, 0x19, 0x10, 0x08, 0x03}, /* 2, -1.0dB */
-	{0x2d, 0x2d, 0x27, 0x1f, 0x18, 0x0f, 0x08, 0x03}, /* 3, -1.5dB */
-	{0x2b, 0x2a, 0x25, 0x1e, 0x16, 0x0e, 0x07, 0x03}, /* 4, -2.0dB */
-	{0x28, 0x28, 0x22, 0x1c, 0x15, 0x0d, 0x07, 0x03}, /* 5, -2.5dB */
-	{0x26, 0x25, 0x21, 0x1b, 0x14, 0x0d, 0x06, 0x03}, /* 6, -3.0dB */
-	{0x24, 0x23, 0x1f, 0x19, 0x13, 0x0c, 0x06, 0x03}, /* 7, -3.5dB */
-	{0x22, 0x21, 0x1d, 0x18, 0x11, 0x0b, 0x06, 0x02}, /* 8, -4.0dB */
-	{0x20, 0x20, 0x1b, 0x16, 0x11, 0x08, 0x05, 0x02}, /* 9, -4.5dB */
-	{0x1f, 0x1e, 0x1a, 0x15, 0x10, 0x0a, 0x05, 0x02}, /* 10, -5.0dB */
-	{0x1d, 0x1c, 0x18, 0x14, 0x0f, 0x0a, 0x05, 0x02}, /* 11, -5.5dB */
-	{0x1b, 0x1a, 0x17, 0x13, 0x0e, 0x09, 0x04, 0x02}, /* 12, -6.0dB */
-	{0x1a, 0x19, 0x16, 0x12, 0x0d, 0x09, 0x04, 0x02}, /* 13, -6.5dB */
-	{0x18, 0x17, 0x15, 0x11, 0x0c, 0x08, 0x04, 0x02}, /* 14, -7.0dB */
-	{0x17, 0x16, 0x13, 0x10, 0x0c, 0x08, 0x04, 0x02}, /* 15, -7.5dB */
-	{0x16, 0x15, 0x12, 0x0f, 0x0b, 0x07, 0x04, 0x01}, /* 16, -8.0dB */
-	{0x14, 0x14, 0x11, 0x0e, 0x0b, 0x07, 0x03, 0x02}, /* 17, -8.5dB */
-	{0x13, 0x13, 0x10, 0x0d, 0x0a, 0x06, 0x03, 0x01}, /* 18, -9.0dB */
-	{0x12, 0x12, 0x0f, 0x0c, 0x09, 0x06, 0x03, 0x01}, /* 19, -9.5dB */
-	{0x11, 0x11, 0x0f, 0x0c, 0x09, 0x06, 0x03, 0x01}, /* 20, -10.0dB */
-	{0x10, 0x10, 0x0e, 0x0b, 0x08, 0x05, 0x03, 0x01}, /* 21, -10.5dB */
-	{0x0f, 0x0f, 0x0d, 0x0b, 0x08, 0x05, 0x03, 0x01}, /* 22, -11.0dB */
-	{0x0e, 0x0e, 0x0c, 0x0a, 0x08, 0x05, 0x02, 0x01}, /* 23, -11.5dB */
-	{0x0d, 0x0d, 0x0c, 0x0a, 0x07, 0x05, 0x02, 0x01}, /* 24, -12.0dB */
-	{0x0d, 0x0c, 0x0b, 0x09, 0x07, 0x04, 0x02, 0x01}, /* 25, -12.5dB */
-	{0x0c, 0x0c, 0x0a, 0x09, 0x06, 0x04, 0x02, 0x01}, /* 26, -13.0dB */
-	{0x0b, 0x0b, 0x0a, 0x08, 0x06, 0x04, 0x02, 0x01}, /* 27, -13.5dB */
-	{0x0b, 0x0a, 0x09, 0x08, 0x06, 0x04, 0x02, 0x01}, /* 28, -14.0dB */
-	{0x0a, 0x0a, 0x09, 0x07, 0x05, 0x03, 0x02, 0x01}, /* 29, -14.5dB */
-	{0x0a, 0x09, 0x08, 0x07, 0x05, 0x03, 0x02, 0x01}, /* 30, -15.0dB */
-	{0x09, 0x09, 0x08, 0x06, 0x05, 0x03, 0x01, 0x01}, /* 31, -15.5dB */
-	{0x09, 0x08, 0x07, 0x06, 0x04, 0x03, 0x01, 0x01}  /* 32, -16.0dB */
-};
-
-static const u8 cckswing_table_ch14[CCK_TABLE_SIZE][8] = {
-	{0x36, 0x35, 0x2e, 0x1b, 0x00, 0x00, 0x00, 0x00}, /* 0, +0dB */
-	{0x33, 0x32, 0x2b, 0x19, 0x00, 0x00, 0x00, 0x00}, /* 1, -0.5dB */
-	{0x30, 0x2f, 0x29, 0x18, 0x00, 0x00, 0x00, 0x00}, /* 2, -1.0dB */
-	{0x2d, 0x2d, 0x17, 0x17, 0x00, 0x00, 0x00, 0x00}, /* 3, -1.5dB */
-	{0x2b, 0x2a, 0x25, 0x15, 0x00, 0x00, 0x00, 0x00}, /* 4, -2.0dB */
-	{0x28, 0x28, 0x24, 0x14, 0x00, 0x00, 0x00, 0x00}, /* 5, -2.5dB */
-	{0x26, 0x25, 0x21, 0x13, 0x00, 0x00, 0x00, 0x00}, /* 6, -3.0dB */
-	{0x24, 0x23, 0x1f, 0x12, 0x00, 0x00, 0x00, 0x00}, /* 7, -3.5dB */
-	{0x22, 0x21, 0x1d, 0x11, 0x00, 0x00, 0x00, 0x00}, /* 8, -4.0dB */
-	{0x20, 0x20, 0x1b, 0x10, 0x00, 0x00, 0x00, 0x00}, /* 9, -4.5dB */
-	{0x1f, 0x1e, 0x1a, 0x0f, 0x00, 0x00, 0x00, 0x00}, /* 10, -5.0dB */
-	{0x1d, 0x1c, 0x18, 0x0e, 0x00, 0x00, 0x00, 0x00}, /* 11, -5.5dB */
-	{0x1b, 0x1a, 0x17, 0x0e, 0x00, 0x00, 0x00, 0x00}, /* 12, -6.0dB */
-	{0x1a, 0x19, 0x16, 0x0d, 0x00, 0x00, 0x00, 0x00}, /* 13, -6.5dB */
-	{0x18, 0x17, 0x15, 0x0c, 0x00, 0x00, 0x00, 0x00}, /* 14, -7.0dB */
-	{0x17, 0x16, 0x13, 0x0b, 0x00, 0x00, 0x00, 0x00}, /* 15, -7.5dB */
-	{0x16, 0x15, 0x12, 0x0b, 0x00, 0x00, 0x00, 0x00}, /* 16, -8.0dB */
-	{0x14, 0x14, 0x11, 0x0a, 0x00, 0x00, 0x00, 0x00}, /* 17, -8.5dB */
-	{0x13, 0x13, 0x10, 0x0a, 0x00, 0x00, 0x00, 0x00}, /* 18, -9.0dB */
-	{0x12, 0x12, 0x0f, 0x09, 0x00, 0x00, 0x00, 0x00}, /* 19, -9.5dB */
-	{0x11, 0x11, 0x0f, 0x09, 0x00, 0x00, 0x00, 0x00}, /* 20, -10.0dB */
-	{0x10, 0x10, 0x0e, 0x08, 0x00, 0x00, 0x00, 0x00}, /* 21, -10.5dB */
-	{0x0f, 0x0f, 0x0d, 0x08, 0x00, 0x00, 0x00, 0x00}, /* 22, -11.0dB */
-	{0x0e, 0x0e, 0x0c, 0x07, 0x00, 0x00, 0x00, 0x00}, /* 23, -11.5dB */
-	{0x0d, 0x0d, 0x0c, 0x07, 0x00, 0x00, 0x00, 0x00}, /* 24, -12.0dB */
-	{0x0d, 0x0c, 0x0b, 0x06, 0x00, 0x00, 0x00, 0x00}, /* 25, -12.5dB */
-	{0x0c, 0x0c, 0x0a, 0x06, 0x00, 0x00, 0x00, 0x00}, /* 26, -13.0dB */
-	{0x0b, 0x0b, 0x0a, 0x06, 0x00, 0x00, 0x00, 0x00}, /* 27, -13.5dB */
-	{0x0b, 0x0a, 0x09, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 28, -14.0dB */
-	{0x0a, 0x0a, 0x09, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 29, -14.5dB */
-	{0x0a, 0x09, 0x08, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 30, -15.0dB */
-	{0x09, 0x09, 0x08, 0x05, 0x00, 0x00, 0x00, 0x00}, /* 31, -15.5dB */
-	{0x09, 0x08, 0x07, 0x04, 0x00, 0x00, 0x00, 0x00}  /* 32, -16.0dB */
-};
-
 static void rtl92ee_dm_false_alarm_counter_statistics(struct ieee80211_hw *hw)
 {
 	u32 ret_value;
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 223/252] rtlwifi: rtl8723ae: remove unused variables
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
	netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: YueHaibing <yuehaibing@huawei.com>

[ Upstream commit c5f9852411098474ab21f5d7b1b84e5cdd59ca5a ]

drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c:16:18:
 warning: ofdmswing_table defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c:56:17:
 warning: cckswing_table_ch1ch13 defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c:92:17:
 warning: cckswing_table_ch14 defined but not used [-Wunused-const-variable=]

These variable is never used, so remove them.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 .../wireless/realtek/rtlwifi/rtl8723ae/dm.c   | 112 ------------------
 1 file changed, 112 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
index 42a6fba90ba91..ec41cfa8876e6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
@@ -35,118 +35,6 @@
 #include "fw.h"
 #include "hal_btc.h"
 
-static const u32 ofdmswing_table[OFDM_TABLE_SIZE] = {
-	0x7f8001fe,
-	0x788001e2,
-	0x71c001c7,
-	0x6b8001ae,
-	0x65400195,
-	0x5fc0017f,
-	0x5a400169,
-	0x55400155,
-	0x50800142,
-	0x4c000130,
-	0x47c0011f,
-	0x43c0010f,
-	0x40000100,
-	0x3c8000f2,
-	0x390000e4,
-	0x35c000d7,
-	0x32c000cb,
-	0x300000c0,
-	0x2d4000b5,
-	0x2ac000ab,
-	0x288000a2,
-	0x26000098,
-	0x24000090,
-	0x22000088,
-	0x20000080,
-	0x1e400079,
-	0x1c800072,
-	0x1b00006c,
-	0x19800066,
-	0x18000060,
-	0x16c0005b,
-	0x15800056,
-	0x14400051,
-	0x1300004c,
-	0x12000048,
-	0x11000044,
-	0x10000040,
-};
-
-static const u8 cckswing_table_ch1ch13[CCK_TABLE_SIZE][8] = {
-	{0x36, 0x35, 0x2e, 0x25, 0x1c, 0x12, 0x09, 0x04},
-	{0x33, 0x32, 0x2b, 0x23, 0x1a, 0x11, 0x08, 0x04},
-	{0x30, 0x2f, 0x29, 0x21, 0x19, 0x10, 0x08, 0x03},
-	{0x2d, 0x2d, 0x27, 0x1f, 0x18, 0x0f, 0x08, 0x03},
-	{0x2b, 0x2a, 0x25, 0x1e, 0x16, 0x0e, 0x07, 0x03},
-	{0x28, 0x28, 0x22, 0x1c, 0x15, 0x0d, 0x07, 0x03},
-	{0x26, 0x25, 0x21, 0x1b, 0x14, 0x0d, 0x06, 0x03},
-	{0x24, 0x23, 0x1f, 0x19, 0x13, 0x0c, 0x06, 0x03},
-	{0x22, 0x21, 0x1d, 0x18, 0x11, 0x0b, 0x06, 0x02},
-	{0x20, 0x20, 0x1b, 0x16, 0x11, 0x08, 0x05, 0x02},
-	{0x1f, 0x1e, 0x1a, 0x15, 0x10, 0x0a, 0x05, 0x02},
-	{0x1d, 0x1c, 0x18, 0x14, 0x0f, 0x0a, 0x05, 0x02},
-	{0x1b, 0x1a, 0x17, 0x13, 0x0e, 0x09, 0x04, 0x02},
-	{0x1a, 0x19, 0x16, 0x12, 0x0d, 0x09, 0x04, 0x02},
-	{0x18, 0x17, 0x15, 0x11, 0x0c, 0x08, 0x04, 0x02},
-	{0x17, 0x16, 0x13, 0x10, 0x0c, 0x08, 0x04, 0x02},
-	{0x16, 0x15, 0x12, 0x0f, 0x0b, 0x07, 0x04, 0x01},
-	{0x14, 0x14, 0x11, 0x0e, 0x0b, 0x07, 0x03, 0x02},
-	{0x13, 0x13, 0x10, 0x0d, 0x0a, 0x06, 0x03, 0x01},
-	{0x12, 0x12, 0x0f, 0x0c, 0x09, 0x06, 0x03, 0x01},
-	{0x11, 0x11, 0x0f, 0x0c, 0x09, 0x06, 0x03, 0x01},
-	{0x10, 0x10, 0x0e, 0x0b, 0x08, 0x05, 0x03, 0x01},
-	{0x0f, 0x0f, 0x0d, 0x0b, 0x08, 0x05, 0x03, 0x01},
-	{0x0e, 0x0e, 0x0c, 0x0a, 0x08, 0x05, 0x02, 0x01},
-	{0x0d, 0x0d, 0x0c, 0x0a, 0x07, 0x05, 0x02, 0x01},
-	{0x0d, 0x0c, 0x0b, 0x09, 0x07, 0x04, 0x02, 0x01},
-	{0x0c, 0x0c, 0x0a, 0x09, 0x06, 0x04, 0x02, 0x01},
-	{0x0b, 0x0b, 0x0a, 0x08, 0x06, 0x04, 0x02, 0x01},
-	{0x0b, 0x0a, 0x09, 0x08, 0x06, 0x04, 0x02, 0x01},
-	{0x0a, 0x0a, 0x09, 0x07, 0x05, 0x03, 0x02, 0x01},
-	{0x0a, 0x09, 0x08, 0x07, 0x05, 0x03, 0x02, 0x01},
-	{0x09, 0x09, 0x08, 0x06, 0x05, 0x03, 0x01, 0x01},
-	{0x09, 0x08, 0x07, 0x06, 0x04, 0x03, 0x01, 0x01}
-};
-
-static const u8 cckswing_table_ch14[CCK_TABLE_SIZE][8] = {
-	{0x36, 0x35, 0x2e, 0x1b, 0x00, 0x00, 0x00, 0x00},
-	{0x33, 0x32, 0x2b, 0x19, 0x00, 0x00, 0x00, 0x00},
-	{0x30, 0x2f, 0x29, 0x18, 0x00, 0x00, 0x00, 0x00},
-	{0x2d, 0x2d, 0x17, 0x17, 0x00, 0x00, 0x00, 0x00},
-	{0x2b, 0x2a, 0x25, 0x15, 0x00, 0x00, 0x00, 0x00},
-	{0x28, 0x28, 0x24, 0x14, 0x00, 0x00, 0x00, 0x00},
-	{0x26, 0x25, 0x21, 0x13, 0x00, 0x00, 0x00, 0x00},
-	{0x24, 0x23, 0x1f, 0x12, 0x00, 0x00, 0x00, 0x00},
-	{0x22, 0x21, 0x1d, 0x11, 0x00, 0x00, 0x00, 0x00},
-	{0x20, 0x20, 0x1b, 0x10, 0x00, 0x00, 0x00, 0x00},
-	{0x1f, 0x1e, 0x1a, 0x0f, 0x00, 0x00, 0x00, 0x00},
-	{0x1d, 0x1c, 0x18, 0x0e, 0x00, 0x00, 0x00, 0x00},
-	{0x1b, 0x1a, 0x17, 0x0e, 0x00, 0x00, 0x00, 0x00},
-	{0x1a, 0x19, 0x16, 0x0d, 0x00, 0x00, 0x00, 0x00},
-	{0x18, 0x17, 0x15, 0x0c, 0x00, 0x00, 0x00, 0x00},
-	{0x17, 0x16, 0x13, 0x0b, 0x00, 0x00, 0x00, 0x00},
-	{0x16, 0x15, 0x12, 0x0b, 0x00, 0x00, 0x00, 0x00},
-	{0x14, 0x14, 0x11, 0x0a, 0x00, 0x00, 0x00, 0x00},
-	{0x13, 0x13, 0x10, 0x0a, 0x00, 0x00, 0x00, 0x00},
-	{0x12, 0x12, 0x0f, 0x09, 0x00, 0x00, 0x00, 0x00},
-	{0x11, 0x11, 0x0f, 0x09, 0x00, 0x00, 0x00, 0x00},
-	{0x10, 0x10, 0x0e, 0x08, 0x00, 0x00, 0x00, 0x00},
-	{0x0f, 0x0f, 0x0d, 0x08, 0x00, 0x00, 0x00, 0x00},
-	{0x0e, 0x0e, 0x0c, 0x07, 0x00, 0x00, 0x00, 0x00},
-	{0x0d, 0x0d, 0x0c, 0x07, 0x00, 0x00, 0x00, 0x00},
-	{0x0d, 0x0c, 0x0b, 0x06, 0x00, 0x00, 0x00, 0x00},
-	{0x0c, 0x0c, 0x0a, 0x06, 0x00, 0x00, 0x00, 0x00},
-	{0x0b, 0x0b, 0x0a, 0x06, 0x00, 0x00, 0x00, 0x00},
-	{0x0b, 0x0a, 0x09, 0x05, 0x00, 0x00, 0x00, 0x00},
-	{0x0a, 0x0a, 0x09, 0x05, 0x00, 0x00, 0x00, 0x00},
-	{0x0a, 0x09, 0x08, 0x05, 0x00, 0x00, 0x00, 0x00},
-	{0x09, 0x09, 0x08, 0x05, 0x00, 0x00, 0x00, 0x00},
-	{0x09, 0x08, 0x07, 0x04, 0x00, 0x00, 0x00, 0x00}
-};
-
 static u8 rtl8723e_dm_initial_gain_min_pwdb(struct ieee80211_hw *hw)
 {
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
-- 
2.20.1


^ permalink raw reply related

* Re: yz/p4-py3, was Re: What's cooking in git.git (Feb 2020, #03; Wed, 12)
From: Junio C Hamano @ 2020-02-14 17:01 UTC (permalink / raw)
  To: Ben Keene
  Cc: Denton Liu, Yang Zhao, git, SZEDER Gábor,
	Johannes Schindelin, Emily Shaffer, Han-Wen Nienhuys
In-Reply-To: <7fc48fbe-4cf4-7a0a-22f6-eac9692abc9b@gmail.com>

Ben Keene <seraphire@gmail.com> writes:

> On 2/14/2020 12:15 AM, Denton Liu wrote:
>> This change comes from 'git-p4: restructure code in submit' in
>> 'bk/p4-pre-edit-changelist' which introduced the use of the `<>`
>> operator. In Python 2, this is valid but in Python 3, it was removed.
>>
>> We can simply replace the `<>` with `!=` which is the new way of
>> writing "not equals".
> Absolutely. I'm committing the change now.

Thanks.

I didn't mean that the use of <> was the only bug in 'pu' wrt Python
3.  I see you sent a new round out, but has it been tested under
Python 3 already?  Just checking to set my expectation right.


^ permalink raw reply

* Re: [PATCH] staging: Handle races between binaries and their libs
From: Peter Kjellerstedt @ 2020-02-14 17:01 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <20200214130238.20381-1-richard.purdie@linuxfoundation.org>

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org <openembedded-core-
> bounces@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 14 februari 2020 14:03
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] staging: Handle races between binaries and
> their libs
> 
> There is a long standing issue where a binary could be installed into the
> sysroot before its library dependencies. We've always argued nothing should
> use the binary until its been installed by a dependency but there are issues

Change "its" to "it has".

> around binaries which conflict with the host system, for example patch,
> python3, gzip and more.
> 
> With the recent patch changes we've see issues like:

Change "see" to "seen".

> ERROR: gdb-cross-canadian-powerpc-8.3.1-r0 do_patch: Command Error: 'quilt --quiltrc /home/pokybuild/yocto-worker/qemuppc/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-powerpc/8.3.1-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0  Output:
> Applying patch 0009-Change-order-of-CFLAGS.patch
> patch: /lib64/libattr.so.1: version `ATTR_1.3' not found (required by patch)
> Patch 0009-Change-order-of-CFLAGS.patch does not apply (enforce with -f)
> 
> which is a symptom of this issue (libattr-native is a dependency of patch-native).
> 
> There are other ways to fix this such as disabling libattr in patch, installing
> patch to a subdirectory and requiring PATH manipulation and so on.
> 
> We can simply fix the staging code to handle /bin/ after everything else so lets

Change "lets" to "let's".

> do that and avoid all these other complications.

Shouldn't /sbin/ be treated the same way as /bin/?

//Peter

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes/staging.bbclass | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
> index 4dd2ed01010..530e23b1853 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -470,6 +470,7 @@ python extend_recipe_sysroot() {
>          elif os.path.lexists(depdir + "/" + c):
>              os.unlink(depdir + "/" + c)
> 
> +    binfiles = {}
>      # Now handle installs
>      for dep in configuredeps:
>          c = setscenedeps[dep][0]
> @@ -562,7 +563,16 @@ python extend_recipe_sysroot() {
>                      if l.endswith("/"):
>                          staging_copydir(l, targetdir, dest, seendirs)
>                          continue
> -                    staging_copyfile(l, targetdir, dest, postinsts, seendirs)
> +                    if "/bin/" in l:
> +                        # defer /bin/* files until last in case they need libs
> +                        binfiles[l] = (targetdir, dest)
> +                    else:
> +                        staging_copyfile(l, targetdir, dest, postinsts, seendirs)
> +
> +    # Handle deferred binfiles
> +    for l in binfiles:
> +        (targetdir, dest) = binfiles[l]
> +        staging_copyfile(l, targetdir, dest, postinsts, seendirs)
> 
>      bb.note("Installed into sysroot: %s" % str(msg_adding))
>      bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
> --
> 2.20.1

//Peter



^ permalink raw reply

* [PATCH AUTOSEL 4.19 113/252] drm/mediatek: handle events when enabling/disabling crtc
From: Sasha Levin @ 2020-02-14 16:09 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, dri-devel, linux-mediatek, Bibby Hsieh, CK Hu,
	linux-arm-kernel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Bibby Hsieh <bibby.hsieh@mediatek.com>

[ Upstream commit 411f5c1eacfebb1f6e40b653d29447cdfe7282aa ]

The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.

Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 92ecb9bf982cf..b86ee7d25af36 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -308,6 +308,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
 static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
 {
 	struct drm_device *drm = mtk_crtc->base.dev;
+	struct drm_crtc *crtc = &mtk_crtc->base;
 	int i;
 
 	DRM_DEBUG_DRIVER("%s\n", __func__);
@@ -329,6 +330,13 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
 	mtk_disp_mutex_unprepare(mtk_crtc->mutex);
 
 	pm_runtime_put(drm->dev);
+
+	if (crtc->state->event && !crtc->state->active) {
+		spin_lock_irq(&crtc->dev->event_lock);
+		drm_crtc_send_vblank_event(crtc, crtc->state->event);
+		crtc->state->event = NULL;
+		spin_unlock_irq(&crtc->dev->event_lock);
+	}
 }
 
 static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH AUTOSEL 4.19 224/252] iwlegacy: ensure loop counter addr does not wrap and cause an infinite loop
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Colin Ian King, Stanislaw Gruszka, Kalle Valo, Sasha Levin,
	linux-wireless, netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Colin Ian King <colin.king@canonical.com>

[ Upstream commit c2f9a4e4a5abfc84c01b738496b3fd2d471e0b18 ]

The loop counter addr is a u16 where as the upper limit of the loop
is an int. In the unlikely event that the il->cfg->eeprom_size is
greater than 64K then we end up with an infinite loop since addr will
wrap around an never reach upper loop limit. Fix this by making addr
an int.

Addresses-Coverity: ("Infinite loop")
Fixes: be663ab67077 ("iwlwifi: split the drivers for agn and legacy devices 3945/4965")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/intel/iwlegacy/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c
index 6514baf799fef..e16f2597c2199 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -717,7 +717,7 @@ il_eeprom_init(struct il_priv *il)
 	u32 gp = _il_rd(il, CSR_EEPROM_GP);
 	int sz;
 	int ret;
-	u16 addr;
+	int addr;
 
 	/* allocate eeprom */
 	sz = il->cfg->eeprom_size;
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 225/252] cifs: fix NULL dereference in match_prepath
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Ronnie Sahlberg, Steve French, Sasha Levin, linux-cifs,
	samba-technical
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Ronnie Sahlberg <lsahlber@redhat.com>

[ Upstream commit fe1292686333d1dadaf84091f585ee903b9ddb84 ]

RHBZ: 1760879

Fix an oops in match_prepath() by making sure that the prepath string is not
NULL before we pass it into strcmp().

This is similar to other checks we make for example in cifs_root_iget()

Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/cifs/connect.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 576cf71576da1..6c62ce40608a1 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -3342,8 +3342,10 @@ match_prepath(struct super_block *sb, struct cifs_mnt_data *mnt_data)
 {
 	struct cifs_sb_info *old = CIFS_SB(sb);
 	struct cifs_sb_info *new = mnt_data->cifs_sb;
-	bool old_set = old->mnt_cifs_flags & CIFS_MOUNT_USE_PREFIX_PATH;
-	bool new_set = new->mnt_cifs_flags & CIFS_MOUNT_USE_PREFIX_PATH;
+	bool old_set = (old->mnt_cifs_flags & CIFS_MOUNT_USE_PREFIX_PATH) &&
+		old->prepath;
+	bool new_set = (new->mnt_cifs_flags & CIFS_MOUNT_USE_PREFIX_PATH) &&
+		new->prepath;
 
 	if (old_set && new_set && !strcmp(new->prepath, old->prepath))
 		return 1;
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 118/252] dmaengine: imx-sdma: Fix memory leak
From: Sasha Levin @ 2020-02-14 16:09 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, Sascha Hauer, Vinod Koul, dmaengine, Robin Gong,
	linux-arm-kernel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Sascha Hauer <s.hauer@pengutronix.de>

[ Upstream commit 02939cd167095f16328a1bd5cab5a90b550606df ]

The current descriptor is not on any list of the virtual DMA channel.
Once sdma_terminate_all() is called when a descriptor is currently
in flight then this one is forgotten to be freed. We have to call
vchan_terminate_vdesc() on this descriptor to re-add it to the lists.
Now that we also free the currently running descriptor we can (and
actually have to) remove the current descriptor from its list also
for the cyclic case.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Robin Gong <yibin.gong@nxp.com>
Tested-by: Robin Gong <yibin.gong@nxp.com>
Link: https://lore.kernel.org/r/20191216105328.15198-10-s.hauer@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/dma/imx-sdma.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ceb82e74f5b4e..d66a7fdff898e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -738,12 +738,8 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
 		return;
 	}
 	sdmac->desc = desc = to_sdma_desc(&vd->tx);
-	/*
-	 * Do not delete the node in desc_issued list in cyclic mode, otherwise
-	 * the desc allocated will never be freed in vchan_dma_desc_free_list
-	 */
-	if (!(sdmac->flags & IMX_DMA_SG_LOOP))
-		list_del(&vd->node);
+
+	list_del(&vd->node);
 
 	sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
 	sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
@@ -1044,7 +1040,6 @@ static void sdma_channel_terminate_work(struct work_struct *work)
 
 	spin_lock_irqsave(&sdmac->vc.lock, flags);
 	vchan_get_all_descriptors(&sdmac->vc, &head);
-	sdmac->desc = NULL;
 	spin_unlock_irqrestore(&sdmac->vc.lock, flags);
 	vchan_dma_desc_free_list(&sdmac->vc, &head);
 }
@@ -1052,11 +1047,19 @@ static void sdma_channel_terminate_work(struct work_struct *work)
 static int sdma_disable_channel_async(struct dma_chan *chan)
 {
 	struct sdma_channel *sdmac = to_sdma_chan(chan);
+	unsigned long flags;
+
+	spin_lock_irqsave(&sdmac->vc.lock, flags);
 
 	sdma_disable_channel(chan);
 
-	if (sdmac->desc)
+	if (sdmac->desc) {
+		vchan_terminate_vdesc(&sdmac->desc->vd);
+		sdmac->desc = NULL;
 		schedule_work(&sdmac->terminate_worker);
+	}
+
+	spin_unlock_irqrestore(&sdmac->vc.lock, flags);
 
 	return 0;
 }
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH AUTOSEL 4.19 227/252] mwifiex: Fix possible buffer overflows in mwifiex_ret_wmm_get_status()
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Qing Xu, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Qing Xu <m1s5p6688@gmail.com>

[ Upstream commit 3a9b153c5591548612c3955c9600a98150c81875 ]

mwifiex_ret_wmm_get_status() calls memcpy() without checking the
destination size.Since the source is given from remote AP which
contains illegal wmm elements , this may trigger a heap buffer
overflow.
Fix it by putting the length check before calling memcpy().

Signed-off-by: Qing Xu <m1s5p6688@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/marvell/mwifiex/wmm.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 64916ba15df5d..429ea2752e6aa 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -977,6 +977,10 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,
 				    "WMM Parameter Set Count: %d\n",
 				    wmm_param_ie->qos_info_bitmap & mask);
 
+			if (wmm_param_ie->vend_hdr.len + 2 >
+				sizeof(struct ieee_types_wmm_parameter))
+				break;
+
 			memcpy((u8 *) &priv->curr_bss_params.bss_descriptor.
 			       wmm_ie, wmm_param_ie,
 			       wmm_param_ie->vend_hdr.len + 2);
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 182/252] drm/amd/display: fixup DML dependencies
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Jun Lei, Anthony Koo, Harry Wentland, Rodrigo Siqueira,
	Alex Deucher, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Jun Lei <Jun.Lei@amd.com>

[ Upstream commit 34ad0230062c39cdcba564d16d122c0fb467a7d6 ]

[why]
Need to fix DML portability issues to enable SW unit testing around DML

[how]
Move calcs into dc include folder since multiple components reference it
Remove relative paths to external dependencies

Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.c          | 2 +-
 drivers/gpu/drm/amd/display/dc/dml/dml_inline_defs.h          | 2 +-
 drivers/gpu/drm/amd/display/dc/{calcs => inc}/dcn_calc_math.h | 0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename drivers/gpu/drm/amd/display/dc/{calcs => inc}/dcn_calc_math.h (100%)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.c b/drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.c
index b953b02a15121..723af0b2dda04 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.c
@@ -24,7 +24,7 @@
  */
 
 #include "dml_common_defs.h"
-#include "../calcs/dcn_calc_math.h"
+#include "dcn_calc_math.h"
 
 #include "dml_inline_defs.h"
 
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dml_inline_defs.h b/drivers/gpu/drm/amd/display/dc/dml/dml_inline_defs.h
index e8ce08567cd8e..e4f595a3038c4 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dml_inline_defs.h
+++ b/drivers/gpu/drm/amd/display/dc/dml/dml_inline_defs.h
@@ -27,7 +27,7 @@
 #define __DML_INLINE_DEFS_H__
 
 #include "dml_common_defs.h"
-#include "../calcs/dcn_calc_math.h"
+#include "dcn_calc_math.h"
 #include "dml_logger.h"
 
 static inline double dml_min(double a, double b)
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.h b/drivers/gpu/drm/amd/display/dc/inc/dcn_calc_math.h
similarity index 100%
rename from drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.h
rename to drivers/gpu/drm/amd/display/dc/inc/dcn_calc_math.h
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 140/252] ARM: dts: stm32: Add power-supply for DSI panel on stm32f469-disco
From: Sasha Levin @ 2020-02-14 16:09 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, devicetree, Benjamin Gaignard, linux-stm32,
	linux-arm-kernel, Alexandre Torgue
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Benjamin Gaignard <benjamin.gaignard@st.com>

[ Upstream commit 0ff15a86d0c5a3f004fee2e92d65b88e56a3bc58 ]

Add a fixed regulator and use it as power supply for DSI panel.

Fixes: 18c8866266 ("ARM: dts: stm32: Add display support on stm32f469-disco")

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm/boot/dts/stm32f469-disco.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 3ee768cb86fc9..eea979ef5512f 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -75,6 +75,13 @@
 		regulator-max-microvolt = <3300000>;
 	};
 
+	vdd_dsi: vdd-dsi {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_dsi";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
 	soc {
 		dma-ranges = <0xc0000000 0x0 0x10000000>;
 	};
@@ -154,6 +161,7 @@
 		compatible = "orisetech,otm8009a";
 		reg = <0>; /* dsi virtual channel (0..3) */
 		reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW>;
+		power-supply = <&vdd_dsi>;
 		status = "okay";
 
 		port {
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH AUTOSEL 4.19 228/252] mwifiex: Fix possible buffer overflows in mwifiex_cmd_append_vsie_tlv()
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Qing Xu, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Qing Xu <m1s5p6688@gmail.com>

[ Upstream commit b70261a288ea4d2f4ac7cd04be08a9f0f2de4f4d ]

mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking
the destination size may trigger a buffer overflower,
which a local user could use to cause denial of service
or the execution of arbitrary code.
Fix it by putting the length check before calling memcpy().

Signed-off-by: Qing Xu <m1s5p6688@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/wireless/marvell/mwifiex/scan.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index dd02bbd9544e7..85d6d5f3dce5b 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -2894,6 +2894,13 @@ mwifiex_cmd_append_vsie_tlv(struct mwifiex_private *priv,
 			vs_param_set->header.len =
 				cpu_to_le16((((u16) priv->vs_ie[id].ie[1])
 				& 0x00FF) + 2);
+			if (le16_to_cpu(vs_param_set->header.len) >
+				MWIFIEX_MAX_VSIE_LEN) {
+				mwifiex_dbg(priv->adapter, ERROR,
+					    "Invalid param length!\n");
+				break;
+			}
+
 			memcpy(vs_param_set->ie, priv->vs_ie[id].ie,
 			       le16_to_cpu(vs_param_set->header.len));
 			*buffer += le16_to_cpu(vs_param_set->header.len) +
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH 0/3] random: add random.rng_seed to bootconfig entry
From: Mark Salyzyn @ 2020-02-14 17:00 UTC (permalink / raw)
  To: Rob Herring, Masami Hiramatsu
  Cc: linux-kernel@vger.kernel.org, Android Kernel Team,
	Theodore Ts'o, Arnd Bergmann, Greg Kroah-Hartman,
	Richard Henderson, Mark Brown, Kees Cook, Hsin-Yi Wang,
	Vasily Gorbik, Andrew Morton, Steven Rostedt, Mike Rapoport,
	Arvind Sankar, Dominik Brodowski, Thomas Gleixner,
	Alexander Potapenko, Jonathan Corbet, Mauro Carvalho Chehab,
	Josh Poimboeuf, Pawan Gupta, Juergen Gross,
	Linux Doc Mailing List
In-Reply-To: <CAL_JsqJ_VwHdpQ_WnQHu5J-bfs1vRPd5HQwVekR+5kKdVi4sXw@mail.gmail.com>

On 2/14/20 5:49 AM, Rob Herring wrote:
> On Fri, Feb 14, 2020 at 12:10 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>> Hi,
>>
>> The following series is bootconfig based implementation of
>> the rng_seed option patch originally from Mark Salyzyn.
>> Note that I removed unrelated command line fixes from this
>> series.
> Why do we need this? There's already multiple other ways to pass
> random seed and this doesn't pass the "too complex for the command
> line" argument you had for needing bootconfig.
>
> Rob

Android is the use case I can vouch for. But also KVM.

Android Cuttlefish is an emulated device used extensively in the testing 
and development infrastructure for In-house, partner, and system and 
application developers for Android. There is no bootloader, per-se. 
Because of the Android GKI distribution, there is also no rng virtual 
driver built in, it is loaded later as a module, too late for many 
aspects of KASLR and networking. There is no Device Tree, it does 
however have access to the content of the initrd image, and to the 
command line for the kernel. The only convenient way to get early 
entropy is going to have to be one of those two places.

In addition, 2B Android devices on the planet, especially in light of 
the Android GKI distribution were everything that is vendor created is 
in a module, needs a way to collect early entropy prior to module load 
and pass it to the kernel. Yes, they do have access to the recently 
added Device Tree approach, and we expect them to use it, as I have an 
active backport for the mechanism into the Android 4.19 and 5.4 kernels. 
There may also be some benefit to allowing the 13000 different 
bootloaders an option to use bootconfig as a way of propagating the much 
needed entropy to their kernels. I could make a case to also allow them 
command line as another option to relieve their development stress to 
deliver product, but we can stop there. Regardless, this early entropy 
has the benefit of greatly improving security and precious boot time.

Sincerely -- Mark Salyzyn


^ permalink raw reply

* [PATCH AUTOSEL 4.19 232/252] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Ben Skeggs, Sasha Levin, dri-devel, nouveau
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Ben Skeggs <bskeggs@redhat.com>

[ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ]

The implementations for most channel types contains a map of methods to
priv registers in order to provide debugging info when a disp exception
has been raised.

This info is missing from the implementation of PIO channels as they're
rather simplistic already, however, if an exception is raised by one of
them, we'd end up triggering a NULL-pointer deref.  Not ideal...

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
index bcf32d92ee5a9..50e3539f33d22 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
 
 	if (debug > subdev->debug)
 		return;
+	if (!mthd)
+		return;
 
 	for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
 		u32 base = chan->head * mthd->addr;
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 234/252] ftrace: fpid_next() should increase position index
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Vasily Averin, Steven Rostedt, Sasha Levin
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Vasily Averin <vvs@virtuozzo.com>

[ Upstream commit e4075e8bdffd93a9b6d6e1d52fabedceeca5a91b ]

if seq_file .next fuction does not change position index,
read after some lseek can generate unexpected output.

Without patch:
 # dd bs=4 skip=1 if=/sys/kernel/tracing/set_ftrace_pid
 dd: /sys/kernel/tracing/set_ftrace_pid: cannot skip to specified offset
 id
 no pid
 2+1 records in
 2+1 records out
 10 bytes copied, 0.000213285 s, 46.9 kB/s

Notice the "id" followed by "no pid".

With the patch:
 # dd bs=4 skip=1 if=/sys/kernel/tracing/set_ftrace_pid
 dd: /sys/kernel/tracing/set_ftrace_pid: cannot skip to specified offset
 id
 0+1 records in
 0+1 records out
 3 bytes copied, 0.000202112 s, 14.8 kB/s

Notice that it only prints "id" and not the "no pid" afterward.

Link: http://lkml.kernel.org/r/4f87c6ad-f114-30bb-8506-c32274ce2992@virtuozzo.com

https://bugzilla.kernel.org/show_bug.cgi?id=206283
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 kernel/trace/ftrace.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 53795237e9751..0c379cd40bea3 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -6525,9 +6525,10 @@ static void *fpid_next(struct seq_file *m, void *v, loff_t *pos)
 	struct trace_array *tr = m->private;
 	struct trace_pid_list *pid_list = rcu_dereference_sched(tr->function_pids);
 
-	if (v == FTRACE_NO_PIDS)
+	if (v == FTRACE_NO_PIDS) {
+		(*pos)++;
 		return NULL;
-
+	}
 	return trace_pid_next(pid_list, v, pos);
 }
 
-- 
2.20.1


^ permalink raw reply related

* [PATCH AUTOSEL 4.19 237/252] ocfs2: fix a NULL pointer dereference when call ocfs2_update_inode_fsync_trans()
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: wangyan, Jun Piao, Mark Fasheh, Joel Becker, Junxiao Bi,
	Joseph Qi, Changwei Ge, Gang He, Andrew Morton, Linus Torvalds,
	Sasha Levin, ocfs2-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: wangyan <wangyan122@huawei.com>

[ Upstream commit 9f16ca48fc818a17de8be1f75d08e7f4addc4497 ]

I found a NULL pointer dereference in ocfs2_update_inode_fsync_trans(),
handle->h_transaction may be NULL in this situation:

ocfs2_file_write_iter
  ->__generic_file_write_iter
      ->generic_perform_write
        ->ocfs2_write_begin
          ->ocfs2_write_begin_nolock
            ->ocfs2_write_cluster_by_desc
              ->ocfs2_write_cluster
                ->ocfs2_mark_extent_written
                  ->ocfs2_change_extent_flag
                    ->ocfs2_split_extent
                      ->ocfs2_try_to_merge_extent
                        ->ocfs2_extend_rotate_transaction
                          ->ocfs2_extend_trans
                            ->jbd2_journal_restart
                              ->jbd2__journal_restart
                                // handle->h_transaction is NULL here
                                ->handle->h_transaction = NULL;
                                ->start_this_handle
                                  /* journal aborted due to storage
                                     network disconnection, return error */
                                  ->return -EROFS;
                         /* line 3806 in ocfs2_try_to_merge_extent (),
                            it will ignore ret error. */
                        ->ret = 0;
        ->...
        ->ocfs2_write_end
          ->ocfs2_write_end_nolock
            ->ocfs2_update_inode_fsync_trans
              // NULL pointer dereference
              ->oi->i_sync_tid = handle->h_transaction->t_tid;

The information of NULL pointer dereference as follows:
    JBD2: Detected IO errors while flushing file data on dm-11-45
    Aborting journal on device dm-11-45.
    JBD2: Error -5 detected when updating journal superblock for dm-11-45.
    (dd,22081,3):ocfs2_extend_trans:474 ERROR: status = -30
    (dd,22081,3):ocfs2_try_to_merge_extent:3877 ERROR: status = -30
    Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000008
    Mem abort info:
      ESR = 0x96000004
      Exception class = DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
    Data abort info:
      ISV = 0, ISS = 0x00000004
      CM = 0, WnR = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e74e1338
    [0000000000000008] pgd=0000000000000000
    Internal error: Oops: 96000004 [#1] SMP
    Process dd (pid: 22081, stack limit = 0x00000000584f35a9)
    CPU: 3 PID: 22081 Comm: dd Kdump: loaded
    Hardware name: Huawei TaiShan 2280 V2/BC82AMDD, BIOS 0.98 08/25/2019
    pstate: 60400009 (nZCv daif +PAN -UAO)
    pc : ocfs2_write_end_nolock+0x2b8/0x550 [ocfs2]
    lr : ocfs2_write_end_nolock+0x2a0/0x550 [ocfs2]
    sp : ffff0000459fba70
    x29: ffff0000459fba70 x28: 0000000000000000
    x27: ffff807ccf7f1000 x26: 0000000000000001
    x25: ffff807bdff57970 x24: ffff807caf1d4000
    x23: ffff807cc79e9000 x22: 0000000000001000
    x21: 000000006c6cd000 x20: ffff0000091d9000
    x19: ffff807ccb239db0 x18: ffffffffffffffff
    x17: 000000000000000e x16: 0000000000000007
    x15: ffff807c5e15bd78 x14: 0000000000000000
    x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000001
    x9 : 0000000000000228 x8 : 000000000000000c
    x7 : 0000000000000fff x6 : ffff807a308ed6b0
    x5 : ffff7e01f10967c0 x4 : 0000000000000018
    x3 : d0bc661572445600 x2 : 0000000000000000
    x1 : 000000001b2e0200 x0 : 0000000000000000
    Call trace:
     ocfs2_write_end_nolock+0x2b8/0x550 [ocfs2]
     ocfs2_write_end+0x4c/0x80 [ocfs2]
     generic_perform_write+0x108/0x1a8
     __generic_file_write_iter+0x158/0x1c8
     ocfs2_file_write_iter+0x668/0x950 [ocfs2]
     __vfs_write+0x11c/0x190
     vfs_write+0xac/0x1c0
     ksys_write+0x6c/0xd8
     __arm64_sys_write+0x24/0x30
     el0_svc_common+0x78/0x130
     el0_svc_handler+0x38/0x78
     el0_svc+0x8/0xc

To prevent NULL pointer dereference in this situation, we use
is_handle_aborted() before using handle->h_transaction->t_tid.

Link: http://lkml.kernel.org/r/03e750ab-9ade-83aa-b000-b9e81e34e539@huawei.com
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Reviewed-by: Jun Piao <piaojun@huawei.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joseph Qi <jiangqi903@gmail.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/ocfs2/journal.h | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/journal.h b/fs/ocfs2/journal.h
index 497a4171ef61f..bfb50fc51528f 100644
--- a/fs/ocfs2/journal.h
+++ b/fs/ocfs2/journal.h
@@ -637,9 +637,11 @@ static inline void ocfs2_update_inode_fsync_trans(handle_t *handle,
 {
 	struct ocfs2_inode_info *oi = OCFS2_I(inode);
 
-	oi->i_sync_tid = handle->h_transaction->t_tid;
-	if (datasync)
-		oi->i_datasync_tid = handle->h_transaction->t_tid;
+	if (!is_handle_aborted(handle)) {
+		oi->i_sync_tid = handle->h_transaction->t_tid;
+		if (datasync)
+			oi->i_datasync_tid = handle->h_transaction->t_tid;
+	}
 }
 
 #endif /* OCFS2_JOURNAL_H */
-- 
2.20.1


^ permalink raw reply related

* RE: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
From: Pankaj Bansal @ 2020-02-14 16:35 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Calvin Johnson, stuyoder@gmail.com, nleeder@codeaurora.org,
	Ioana Ciornei, Cristi Sovaiala, Hanjun Guo, Will Deacon,
	Marc Zyngier, jon@solid-run.com, Russell King,
	ACPI Devel Maling List, Len Brown, Jason Cooper, Andy Wang,
	Makarand Pawagi, Varun Sethi, Thomas Gleixner, linux-arm-kernel,
	Laurentiu Tudor, Paul Yang, Ard Biesheuvel,
	netdev@vger.kernel.org, Rafael J. Wysocki,
	Linux Kernel Mailing List, Shameerali Kolothum Thodi,
	Sudeep Holla, Robin Murphy
In-Reply-To: <20200214161957.GA27513@e121166-lin.cambridge.arm.com>



> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: Friday, February 14, 2020 9:50 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Marc Zyngier <maz@kernel.org>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; Makarand Pawagi <makarand.pawagi@nxp.com>;
> Calvin Johnson <calvin.johnson@nxp.com>; stuyoder@gmail.com;
> nleeder@codeaurora.org; Ioana Ciornei <ioana.ciornei@nxp.com>; Cristi
> Sovaiala <cristian.sovaiala@nxp.com>; Hanjun Guo <guohanjun@huawei.com>;
> Will Deacon <will@kernel.org>; jon@solid-run.com; Russell King
> <linux@armlinux.org.uk>; ACPI Devel Maling List <linux-acpi@vger.kernel.org>;
> Len Brown <lenb@kernel.org>; Jason Cooper <jason@lakedaemon.net>; Andy
> Wang <Andy.Wang@arm.com>; Varun Sethi <V.Sethi@nxp.com>; Thomas
> Gleixner <tglx@linutronix.de>; linux-arm-kernel <linux-arm-
> kernel@lists.infradead.org>; Laurentiu Tudor <laurentiu.tudor@nxp.com>; Paul
> Yang <Paul.Yang@arm.com>; netdev@vger.kernel.org; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>;
> Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> Sudeep Holla <sudeep.holla@arm.com>; Robin Murphy
> <robin.murphy@arm.com>
> Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
> 
> On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
> 
> [...]
> 
> > > Why should the device know about its own ID? That's a bus/interconnect
> thing.
> > > And nothing should be passed *to* IORT. IORT is the source.
> >
> > IORT is translation between Input IDs <-> Output IDs. The Input ID is still
> expected to be passed to parse IORT table.
> 
> Named components use an array of single mappings (as in entries with single
> mapping flag set) - Input ID is irrelevant.
> 
> Not sure what your named component is though and what you want to do with
> it, the fact that IORT allows mapping for named components do not necessarily
> mean that it can describe what your system really is, on that you need to
> elaborate for us to be able to help.

Details about MC bus can be read from here:
https://elixir.bootlin.com/linux/latest/source/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst#L324

As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can dynamically create/destroy these devices.
Now, we want to represent this BUS (not individual devices connected to bus) in IORT table.
The only possible way right now we see is that we describe it as Named components having a pool of ID mappings.
As and when devices are created and attached to bus, we sift through this pool to correctly determine the output ID for the device.
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.

> 
> Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 41/62] x86/sev-es: Handle MSR events
From: Dave Hansen @ 2020-02-14 16:59 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: x86, hpa, Andy Lutomirski, Dave Hansen, Peter Zijlstra,
	Thomas Hellstrom, Jiri Slaby, Dan Williams, Tom Lendacky,
	Juergen Gross, Kees Cook, linux-kernel, kvm, virtualization,
	Joerg Roedel
In-Reply-To: <20200214072324.GE22063@8bytes.org>

On 2/13/20 11:23 PM, Joerg Roedel wrote:
> Yes, investigating this is on the list for future optimizations (besides
> caching CPUID results). My idea is to use alternatives patching for
> this. But the exception handling is needed anyway because #VC
> exceptions happen very early already, basically the first thing after
> setting up a stack is calling verify_cpu(), which uses CPUID.

Ahh, bummer.  How does a guest know that it's running under SEV-ES?
What's the enumeration mechanism if CPUID doesn't "work"?

> The other reason is that things like MMIO and IOIO instructions can't be
> easily patched by alternatives. Those would work with the runtime
> checking you showed above, though.

Is there a reason we can't make a rule that you *must* do MMIO through
an accessor function so we *can* patch them?  I know random drivers
might break the rule, but are SEV-ES guests going to be running random
drivers?  I would think that they mostly if not all want to use virtio.

^ permalink raw reply

* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Jason Ekstrand @ 2020-02-14 16:59 UTC (permalink / raw)
  To: Kenny Ho
  Cc: juan.zuniga-anaya, Daniel Vetter, felix.kuehling, jsparks,
	amd-gfx mailing list, lkaplan, alexander.deucher, nirmoy.das,
	y2kenny, Maling list - DRI developers, joseph.greathouse, tj,
	cgroups, Christian König, damon.mcdougall
In-Reply-To: <CAOFGe96N5gG+08rQCRC+diHKDAfxPFYEnVxDS8_udvjcBYgsPg@mail.gmail.com>

On Fri, Feb 14, 2020 at 10:44 AM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> Pardon my ignorance but I'm a bit confused by this.  What is a "logical GPU"?  What are we subdividing?  Are we carving up memory?  Compute power?  Both?
>
> If it's carving up memory, why aren't we just measuring it in megabytes?
>
> If it's carving up compute power, what's actually being carved up?  Time?  Execution units/waves/threads?  Even if that's the case, what advantage does it give to have it in terms of a fixed set of lgpus where each cgroup gets to pick a fixed set.  Does affinity matter that much?  Why not just say how many waves the GPU supports and that they have to be allocated in chunks of 16 waves (pulling a number out of thin air) and let the cgroup specify how many waves it wants.

One more question:  If I'm a userspace driver, and there are 14 lgpus
allocated to my cgroup, does that mean I have 14 GPUs?  Or does that
mean I have one GPU with 14 units of compute power?

> Don't get me wrong here.  I'm all for the notion of being able to use cgroups to carve up GPU compute resources.  However, this sounds to me like the most AMD-specific solution possible.  We (Intel) could probably do some sort of carving up as well but we'd likely want to do it with preemption and time-slicing rather than handing out specific EUs.

Ok, so "most AMD-specific solution possible" probably wasn't fair.
However, it does seem like an unnecessarily rigid solution to me.
Maybe there's something I'm not getting?

--Jason

> --Jason
>
>
> On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho <Kenny.Ho@amd.com> wrote:
>>
>> drm.lgpu
>>       A read-write nested-keyed file which exists on all cgroups.
>>       Each entry is keyed by the DRM device's major:minor.
>>
>>       lgpu stands for logical GPU, it is an abstraction used to
>>       subdivide a physical DRM device for the purpose of resource
>>       management.  This file stores user configuration while the
>>       drm.lgpu.effective reflects the actual allocation after
>>       considering the relationship between the cgroups and their
>>       configurations.
>>
>>       The lgpu is a discrete quantity that is device specific (i.e.
>>       some DRM devices may have 64 lgpus while others may have 100
>>       lgpus.)  The lgpu is a single quantity that can be allocated
>>       in three different ways denoted by the following nested keys.
>>
>>         =====     ==============================================
>>         weight    Allocate by proportion in relationship with
>>                   active sibling cgroups
>>         count     Allocate by amount statically, treat lgpu as
>>                   anonymous resources
>>         list      Allocate statically, treat lgpu as named
>>                   resource
>>         =====     ==============================================
>>
>>       For example:
>>       226:0 weight=100 count=256 list=0-255
>>       226:1 weight=100 count=4 list=0,2,4,6
>>       226:2 weight=100 count=32 list=32-63
>>       226:3 weight=100 count=0 list=
>>       226:4 weight=500 count=0 list=
>>
>>       lgpu is represented by a bitmap and uses the bitmap_parselist
>>       kernel function so the list key input format is a
>>       comma-separated list of decimal numbers and ranges.
>>
>>       Consecutively set bits are shown as two hyphen-separated decimal
>>       numbers, the smallest and largest bit numbers set in the range.
>>       Optionally each range can be postfixed to denote that only parts
>>       of it should be set.  The range will divided to groups of
>>       specific size.
>>       Syntax: range:used_size/group_size
>>       Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
>>
>>       The count key is the hamming weight / hweight of the bitmap.
>>
>>       Weight, count and list accept the max and default keywords.
>>
>>       Some DRM devices may only support lgpu as anonymous resources.
>>       In such case, the significance of the position of the set bits
>>       in list will be ignored.
>>
>>       The weight quantity is only in effect when static allocation
>>       is not used (by setting count=0) for this cgroup.  The weight
>>       quantity distributes lgpus that are not statically allocated by
>>       the siblings.  For example, given siblings cgroupA, cgroupB and
>>       cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies
>>       0-63, no lgpu is available to be distributed by weight.
>>       Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63,
>>       cgroupC will be starved if it tries to allocate by weight.
>>
>>       On the other hand, if cgroupA has weight=100 count=0, cgroupB
>>       has list=16-47, and cgroupC has weight=100 count=0, then 32
>>       lgpus are available to be distributed evenly between cgroupA
>>       and cgroupC.  In drm.lgpu.effective, cgroupA will have
>>       list=0-15 and cgroupC will have list=48-63.
>>
>>       This lgpu resource supports the 'allocation' and 'weight'
>>       resource distribution model.
>>
>> drm.lgpu.effective
>>       A read-only nested-keyed file which exists on all cgroups.
>>       Each entry is keyed by the DRM device's major:minor.
>>
>>       lgpu stands for logical GPU, it is an abstraction used to
>>       subdivide a physical DRM device for the purpose of resource
>>       management.  This file reflects the actual allocation after
>>       considering the relationship between the cgroups and their
>>       configurations in drm.lgpu.
>>
>> Change-Id: Idde0ef9a331fd67bb9c7eb8ef9978439e6452488
>> Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
>> ---
>>  Documentation/admin-guide/cgroup-v2.rst |  80 ++++++
>>  include/drm/drm_cgroup.h                |   3 +
>>  include/linux/cgroup_drm.h              |  22 ++
>>  kernel/cgroup/drm.c                     | 324 +++++++++++++++++++++++-
>>  4 files changed, 427 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index ce5dc027366a..d8a41956e5c7 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -2120,6 +2120,86 @@ DRM Interface Files
>>         Set largest allocation for /dev/dri/card1 to 4MB
>>         echo "226:1 4m" > drm.buffer.peak.max
>>
>> +  drm.lgpu
>> +       A read-write nested-keyed file which exists on all cgroups.
>> +       Each entry is keyed by the DRM device's major:minor.
>> +
>> +       lgpu stands for logical GPU, it is an abstraction used to
>> +       subdivide a physical DRM device for the purpose of resource
>> +       management.  This file stores user configuration while the
>> +        drm.lgpu.effective reflects the actual allocation after
>> +        considering the relationship between the cgroups and their
>> +        configurations.
>> +
>> +       The lgpu is a discrete quantity that is device specific (i.e.
>> +       some DRM devices may have 64 lgpus while others may have 100
>> +       lgpus.)  The lgpu is a single quantity that can be allocated
>> +        in three different ways denoted by the following nested keys.
>> +
>> +         =====     ==============================================
>> +         weight    Allocate by proportion in relationship with
>> +                    active sibling cgroups
>> +         count     Allocate by amount statically, treat lgpu as
>> +                    anonymous resources
>> +         list      Allocate statically, treat lgpu as named
>> +                    resource
>> +         =====     ==============================================
>> +
>> +       For example:
>> +       226:0 weight=100 count=256 list=0-255
>> +       226:1 weight=100 count=4 list=0,2,4,6
>> +       226:2 weight=100 count=32 list=32-63
>> +       226:3 weight=100 count=0 list=
>> +       226:4 weight=500 count=0 list=
>> +
>> +       lgpu is represented by a bitmap and uses the bitmap_parselist
>> +       kernel function so the list key input format is a
>> +       comma-separated list of decimal numbers and ranges.
>> +
>> +       Consecutively set bits are shown as two hyphen-separated decimal
>> +       numbers, the smallest and largest bit numbers set in the range.
>> +       Optionally each range can be postfixed to denote that only parts
>> +       of it should be set.  The range will divided to groups of
>> +       specific size.
>> +       Syntax: range:used_size/group_size
>> +       Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
>> +
>> +       The count key is the hamming weight / hweight of the bitmap.
>> +
>> +       Weight, count and list accept the max and default keywords.
>> +
>> +       Some DRM devices may only support lgpu as anonymous resources.
>> +       In such case, the significance of the position of the set bits
>> +       in list will be ignored.
>> +
>> +       The weight quantity is only in effect when static allocation
>> +       is not used (by setting count=0) for this cgroup.  The weight
>> +       quantity distributes lgpus that are not statically allocated by
>> +       the siblings.  For example, given siblings cgroupA, cgroupB and
>> +       cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies
>> +       0-63, no lgpu is available to be distributed by weight.
>> +       Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63,
>> +       cgroupC will be starved if it tries to allocate by weight.
>> +
>> +       On the other hand, if cgroupA has weight=100 count=0, cgroupB
>> +       has list=16-47, and cgroupC has weight=100 count=0, then 32
>> +       lgpus are available to be distributed evenly between cgroupA
>> +       and cgroupC.  In drm.lgpu.effective, cgroupA will have
>> +       list=0-15 and cgroupC will have list=48-63.
>> +
>> +       This lgpu resource supports the 'allocation' and 'weight'
>> +       resource distribution model.
>> +
>> +  drm.lgpu.effective
>> +       A read-only nested-keyed file which exists on all cgroups.
>> +       Each entry is keyed by the DRM device's major:minor.
>> +
>> +       lgpu stands for logical GPU, it is an abstraction used to
>> +       subdivide a physical DRM device for the purpose of resource
>> +       management.  This file reflects the actual allocation after
>> +        considering the relationship between the cgroups and their
>> +        configurations in drm.lgpu.
>> +
>>  GEM Buffer Ownership
>>  ~~~~~~~~~~~~~~~~~~~~
>>
>> diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
>> index 2b41d4d22e33..619a110cc748 100644
>> --- a/include/drm/drm_cgroup.h
>> +++ b/include/drm/drm_cgroup.h
>> @@ -17,6 +17,9 @@ struct drmcg_props {
>>
>>         s64                     bo_limits_total_allocated_default;
>>         s64                     bo_limits_peak_allocated_default;
>> +
>> +       int                     lgpu_capacity;
>> +       DECLARE_BITMAP(lgpu_slots, MAX_DRMCG_LGPU_CAPACITY);
>>  };
>>
>>  void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
>> diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
>> index eae400f3d9b4..bb09704e7f71 100644
>> --- a/include/linux/cgroup_drm.h
>> +++ b/include/linux/cgroup_drm.h
>> @@ -11,10 +11,14 @@
>>  /* limit defined per the way drm_minor_alloc operates */
>>  #define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
>>
>> +#define MAX_DRMCG_LGPU_CAPACITY 256
>> +
>>  enum drmcg_res_type {
>>         DRMCG_TYPE_BO_TOTAL,
>>         DRMCG_TYPE_BO_PEAK,
>>         DRMCG_TYPE_BO_COUNT,
>> +       DRMCG_TYPE_LGPU,
>> +       DRMCG_TYPE_LGPU_EFF,
>>         __DRMCG_TYPE_LAST,
>>  };
>>
>> @@ -32,6 +36,24 @@ struct drmcg_device_resource {
>>         s64                     bo_limits_peak_allocated;
>>
>>         s64                     bo_stats_count_allocated;
>> +
>> +       /**
>> +        * Logical GPU
>> +        *
>> +        * *_cfg are properties configured by users
>> +        * *_eff are the effective properties being applied to the hardware
>> +         * *_stg is used to calculate _eff before applying to _eff
>> +        * after considering the entire hierarchy
>> +        */
>> +       DECLARE_BITMAP(lgpu_stg, MAX_DRMCG_LGPU_CAPACITY);
>> +       /* user configurations */
>> +       s64                     lgpu_weight_cfg;
>> +       DECLARE_BITMAP(lgpu_cfg, MAX_DRMCG_LGPU_CAPACITY);
>> +       /* effective lgpu for the cgroup after considering
>> +        * relationship with other cgroup
>> +        */
>> +       s64                     lgpu_count_eff;
>> +       DECLARE_BITMAP(lgpu_eff, MAX_DRMCG_LGPU_CAPACITY);
>>  };
>>
>>  /**
>> diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
>> index 5fcbbc13fa1c..a4e88a3704bb 100644
>> --- a/kernel/cgroup/drm.c
>> +++ b/kernel/cgroup/drm.c
>> @@ -9,6 +9,7 @@
>>  #include <linux/seq_file.h>
>>  #include <linux/mutex.h>
>>  #include <linux/kernel.h>
>> +#include <linux/bitmap.h>
>>  #include <linux/cgroup_drm.h>
>>  #include <drm/drm_file.h>
>>  #include <drm/drm_drv.h>
>> @@ -41,6 +42,10 @@ enum drmcg_file_type {
>>         DRMCG_FTYPE_DEFAULT,
>>  };
>>
>> +#define LGPU_LIMITS_NAME_LIST "list"
>> +#define LGPU_LIMITS_NAME_COUNT "count"
>> +#define LGPU_LIMITS_NAME_WEIGHT "weight"
>> +
>>  /**
>>   * drmcg_bind - Bind DRM subsystem to cgroup subsystem
>>   * @acq_dm: function pointer to the drm_minor_acquire function
>> @@ -98,6 +103,13 @@ static inline int init_drmcg_single(struct drmcg *drmcg, struct drm_device *dev)
>>         ddr->bo_limits_peak_allocated =
>>                 dev->drmcg_props.bo_limits_peak_allocated_default;
>>
>> +       bitmap_copy(ddr->lgpu_cfg, dev->drmcg_props.lgpu_slots,
>> +                       MAX_DRMCG_LGPU_CAPACITY);
>> +       bitmap_copy(ddr->lgpu_stg, dev->drmcg_props.lgpu_slots,
>> +                       MAX_DRMCG_LGPU_CAPACITY);
>> +
>> +       ddr->lgpu_weight_cfg = CGROUP_WEIGHT_DFL;
>> +
>>         return 0;
>>  }
>>
>> @@ -121,6 +133,120 @@ static inline void drmcg_update_cg_tree(struct drm_device *dev)
>>         mutex_unlock(&cgroup_mutex);
>>  }
>>
>> +static void drmcg_calculate_effective_lgpu(struct drm_device *dev,
>> +               const unsigned long *free_static,
>> +               const unsigned long *free_weighted,
>> +               struct drmcg *parent_drmcg)
>> +{
>> +       int capacity = dev->drmcg_props.lgpu_capacity;
>> +       DECLARE_BITMAP(lgpu_unused, MAX_DRMCG_LGPU_CAPACITY);
>> +       DECLARE_BITMAP(lgpu_by_weight, MAX_DRMCG_LGPU_CAPACITY);
>> +       struct drmcg_device_resource *parent_ddr;
>> +       struct drmcg_device_resource *ddr;
>> +       int minor = dev->primary->index;
>> +       struct cgroup_subsys_state *pos;
>> +       struct drmcg *child;
>> +       s64 weight_sum = 0;
>> +       s64 unused;
>> +
>> +       parent_ddr = parent_drmcg->dev_resources[minor];
>> +
>> +       if (bitmap_empty(parent_ddr->lgpu_cfg, capacity))
>> +               /* no static cfg, use weight for calculating the effective */
>> +               bitmap_copy(parent_ddr->lgpu_stg, free_weighted, capacity);
>> +       else
>> +               /* lgpu statically configured, use the overlap as effective */
>> +               bitmap_and(parent_ddr->lgpu_stg, free_static,
>> +                               parent_ddr->lgpu_cfg, capacity);
>> +
>> +       /* calculate lgpu available for distribution by weight for children */
>> +       bitmap_copy(lgpu_unused, parent_ddr->lgpu_stg, capacity);
>> +       css_for_each_child(pos, &parent_drmcg->css) {
>> +               child = css_to_drmcg(pos);
>> +               ddr = child->dev_resources[minor];
>> +
>> +               if (bitmap_empty(ddr->lgpu_cfg, capacity))
>> +                       /* no static allocation, participate in weight dist */
>> +                       weight_sum += ddr->lgpu_weight_cfg;
>> +               else
>> +                       /* take out statically allocated lgpu by siblings */
>> +                       bitmap_andnot(lgpu_unused, lgpu_unused, ddr->lgpu_cfg,
>> +                                       capacity);
>> +       }
>> +
>> +       unused = bitmap_weight(lgpu_unused, capacity);
>> +
>> +       css_for_each_child(pos, &parent_drmcg->css) {
>> +               child = css_to_drmcg(pos);
>> +               ddr = child->dev_resources[minor];
>> +
>> +               bitmap_zero(lgpu_by_weight, capacity);
>> +               /* no static allocation, participate in weight distribution */
>> +               if (bitmap_empty(ddr->lgpu_cfg, capacity)) {
>> +                       int c;
>> +                       int p = 0;
>> +
>> +                       for (c = ddr->lgpu_weight_cfg * unused / weight_sum;
>> +                                       c > 0; c--) {
>> +                               p = find_next_bit(lgpu_unused, capacity, p);
>> +                               if (p < capacity) {
>> +                                       clear_bit(p, lgpu_unused);
>> +                                       set_bit(p, lgpu_by_weight);
>> +                               }
>> +                       }
>> +
>> +               }
>> +
>> +               drmcg_calculate_effective_lgpu(dev, parent_ddr->lgpu_stg,
>> +                               lgpu_by_weight, child);
>> +       }
>> +}
>> +
>> +static void drmcg_apply_effective_lgpu(struct drm_device *dev)
>> +{
>> +       int capacity = dev->drmcg_props.lgpu_capacity;
>> +       int minor = dev->primary->index;
>> +       struct drmcg_device_resource *ddr;
>> +       struct cgroup_subsys_state *pos;
>> +       struct drmcg *drmcg;
>> +
>> +       if (root_drmcg == NULL) {
>> +               WARN_ON(root_drmcg == NULL);
>> +               return;
>> +       }
>> +
>> +       rcu_read_lock();
>> +
>> +       /* process the entire cgroup tree from root to simplify the algorithm */
>> +       drmcg_calculate_effective_lgpu(dev, dev->drmcg_props.lgpu_slots,
>> +                       dev->drmcg_props.lgpu_slots, root_drmcg);
>> +
>> +       /* apply changes to effective only if there is a change */
>> +       css_for_each_descendant_pre(pos, &root_drmcg->css) {
>> +               drmcg = css_to_drmcg(pos);
>> +               ddr = drmcg->dev_resources[minor];
>> +
>> +               if (!bitmap_equal(ddr->lgpu_stg, ddr->lgpu_eff, capacity)) {
>> +                       bitmap_copy(ddr->lgpu_eff, ddr->lgpu_stg, capacity);
>> +                       ddr->lgpu_count_eff =
>> +                               bitmap_weight(ddr->lgpu_eff, capacity);
>> +               }
>> +       }
>> +       rcu_read_unlock();
>> +}
>> +
>> +static void drmcg_apply_effective(enum drmcg_res_type type,
>> +               struct drm_device *dev, struct drmcg *changed_drmcg)
>> +{
>> +       switch (type) {
>> +       case DRMCG_TYPE_LGPU:
>> +               drmcg_apply_effective_lgpu(dev);
>> +               break;
>> +       default:
>> +               break;
>> +       }
>> +}
>> +
>>  /**
>>   * drmcg_register_dev - register a DRM device for usage in drm cgroup
>>   * @dev: DRM device
>> @@ -143,7 +269,13 @@ void drmcg_register_dev(struct drm_device *dev)
>>         {
>>                 dev->driver->drmcg_custom_init(dev, &dev->drmcg_props);
>>
>> +               WARN_ON(dev->drmcg_props.lgpu_capacity !=
>> +                               bitmap_weight(dev->drmcg_props.lgpu_slots,
>> +                                       MAX_DRMCG_LGPU_CAPACITY));
>> +
>>                 drmcg_update_cg_tree(dev);
>> +
>> +               drmcg_apply_effective(DRMCG_TYPE_LGPU, dev, root_drmcg);
>>         }
>>         mutex_unlock(&drmcg_mutex);
>>  }
>> @@ -297,7 +429,8 @@ static void drmcg_print_stats(struct drmcg_device_resource *ddr,
>>  }
>>
>>  static void drmcg_print_limits(struct drmcg_device_resource *ddr,
>> -               struct seq_file *sf, enum drmcg_res_type type)
>> +               struct seq_file *sf, enum drmcg_res_type type,
>> +               struct drm_device *dev)
>>  {
>>         if (ddr == NULL) {
>>                 seq_puts(sf, "\n");
>> @@ -311,6 +444,25 @@ static void drmcg_print_limits(struct drmcg_device_resource *ddr,
>>         case DRMCG_TYPE_BO_PEAK:
>>                 seq_printf(sf, "%lld\n", ddr->bo_limits_peak_allocated);
>>                 break;
>> +       case DRMCG_TYPE_LGPU:
>> +               seq_printf(sf, "%s=%lld %s=%d %s=%*pbl\n",
>> +                               LGPU_LIMITS_NAME_WEIGHT,
>> +                               ddr->lgpu_weight_cfg,
>> +                               LGPU_LIMITS_NAME_COUNT,
>> +                               bitmap_weight(ddr->lgpu_cfg,
>> +                                       dev->drmcg_props.lgpu_capacity),
>> +                               LGPU_LIMITS_NAME_LIST,
>> +                               dev->drmcg_props.lgpu_capacity,
>> +                               ddr->lgpu_cfg);
>> +               break;
>> +       case DRMCG_TYPE_LGPU_EFF:
>> +               seq_printf(sf, "%s=%lld %s=%*pbl\n",
>> +                               LGPU_LIMITS_NAME_COUNT,
>> +                               ddr->lgpu_count_eff,
>> +                               LGPU_LIMITS_NAME_LIST,
>> +                               dev->drmcg_props.lgpu_capacity,
>> +                               ddr->lgpu_eff);
>> +               break;
>>         default:
>>                 seq_puts(sf, "\n");
>>                 break;
>> @@ -329,6 +481,17 @@ static void drmcg_print_default(struct drmcg_props *props,
>>                 seq_printf(sf, "%lld\n",
>>                         props->bo_limits_peak_allocated_default);
>>                 break;
>> +       case DRMCG_TYPE_LGPU:
>> +               seq_printf(sf, "%s=%d %s=%d %s=%*pbl\n",
>> +                               LGPU_LIMITS_NAME_WEIGHT,
>> +                               CGROUP_WEIGHT_DFL,
>> +                               LGPU_LIMITS_NAME_COUNT,
>> +                               bitmap_weight(props->lgpu_slots,
>> +                                       props->lgpu_capacity),
>> +                               LGPU_LIMITS_NAME_LIST,
>> +                               props->lgpu_capacity,
>> +                               props->lgpu_slots);
>> +               break;
>>         default:
>>                 seq_puts(sf, "\n");
>>                 break;
>> @@ -358,7 +521,7 @@ static int drmcg_seq_show_fn(int id, void *ptr, void *data)
>>                 drmcg_print_stats(ddr, sf, type);
>>                 break;
>>         case DRMCG_FTYPE_LIMIT:
>> -               drmcg_print_limits(ddr, sf, type);
>> +               drmcg_print_limits(ddr, sf, type, minor->dev);
>>                 break;
>>         case DRMCG_FTYPE_DEFAULT:
>>                 drmcg_print_default(&minor->dev->drmcg_props, sf, type);
>> @@ -415,6 +578,115 @@ static int drmcg_process_limit_s64_val(char *sval, bool is_mem,
>>         return rc;
>>  }
>>
>> +static void drmcg_nested_limit_parse(struct kernfs_open_file *of,
>> +               struct drm_device *dev, char *attrs)
>> +{
>> +       DECLARE_BITMAP(tmp_bitmap, MAX_DRMCG_LGPU_CAPACITY);
>> +       DECLARE_BITMAP(chk_bitmap, MAX_DRMCG_LGPU_CAPACITY);
>> +       enum drmcg_res_type type =
>> +               DRMCG_CTF_PRIV2RESTYPE(of_cft(of)->private);
>> +       struct drmcg *drmcg = css_to_drmcg(of_css(of));
>> +       struct drmcg_props *props = &dev->drmcg_props;
>> +       char *cft_name = of_cft(of)->name;
>> +       int minor = dev->primary->index;
>> +       char *nested = strstrip(attrs);
>> +       struct drmcg_device_resource *ddr =
>> +               drmcg->dev_resources[minor];
>> +       char *attr;
>> +       char sname[256];
>> +       char sval[256];
>> +       s64 val;
>> +       int rc;
>> +
>> +       while (nested != NULL) {
>> +               attr = strsep(&nested, " ");
>> +
>> +               if (sscanf(attr, "%255[^=]=%255[^=]", sname, sval) != 2)
>> +                       continue;
>> +
>> +               switch (type) {
>> +               case DRMCG_TYPE_LGPU:
>> +                       if (strncmp(sname, LGPU_LIMITS_NAME_LIST, 256) &&
>> +                               strncmp(sname, LGPU_LIMITS_NAME_COUNT, 256) &&
>> +                               strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256))
>> +                               continue;
>> +
>> +                       if (strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256) &&
>> +                                       (!strcmp("max", sval) ||
>> +                                       !strcmp("default", sval))) {
>> +                               bitmap_copy(ddr->lgpu_cfg, props->lgpu_slots,
>> +                                               props->lgpu_capacity);
>> +
>> +                               continue;
>> +                       }
>> +
>> +                       if (strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256) == 0) {
>> +                               rc = drmcg_process_limit_s64_val(sval,
>> +                                       false, CGROUP_WEIGHT_DFL,
>> +                                       CGROUP_WEIGHT_MAX, &val);
>> +
>> +                               if (rc || val < CGROUP_WEIGHT_MIN ||
>> +                                               val > CGROUP_WEIGHT_MAX) {
>> +                                       drmcg_pr_cft_err(drmcg, rc, cft_name,
>> +                                                       minor);
>> +                                       continue;
>> +                               }
>> +
>> +                               ddr->lgpu_weight_cfg = val;
>> +                               continue;
>> +                       }
>> +
>> +                       if (strncmp(sname, LGPU_LIMITS_NAME_COUNT, 256) == 0) {
>> +                               rc = drmcg_process_limit_s64_val(sval,
>> +                                       false, props->lgpu_capacity,
>> +                                       props->lgpu_capacity, &val);
>> +
>> +                               if (rc || val < 0) {
>> +                                       drmcg_pr_cft_err(drmcg, rc, cft_name,
>> +                                                       minor);
>> +                                       continue;
>> +                               }
>> +
>> +                               bitmap_zero(tmp_bitmap,
>> +                                               MAX_DRMCG_LGPU_CAPACITY);
>> +                               bitmap_set(tmp_bitmap, 0, val);
>> +                       }
>> +
>> +                       if (strncmp(sname, LGPU_LIMITS_NAME_LIST, 256) == 0) {
>> +                               rc = bitmap_parselist(sval, tmp_bitmap,
>> +                                               MAX_DRMCG_LGPU_CAPACITY);
>> +
>> +                               if (rc) {
>> +                                       drmcg_pr_cft_err(drmcg, rc, cft_name,
>> +                                                       minor);
>> +                                       continue;
>> +                               }
>> +
>> +                               bitmap_andnot(chk_bitmap, tmp_bitmap,
>> +                                       props->lgpu_slots,
>> +                                       MAX_DRMCG_LGPU_CAPACITY);
>> +
>> +                               /* user setting does not intersect with
>> +                                * available lgpu */
>> +                               if (!bitmap_empty(chk_bitmap,
>> +                                               MAX_DRMCG_LGPU_CAPACITY)) {
>> +                                       drmcg_pr_cft_err(drmcg, 0, cft_name,
>> +                                                       minor);
>> +                                       continue;
>> +                               }
>> +                       }
>> +
>> +                       bitmap_copy(ddr->lgpu_cfg, tmp_bitmap,
>> +                                       props->lgpu_capacity);
>> +
>> +                       break; /* DRMCG_TYPE_LGPU */
>> +               default:
>> +                       break;
>> +               } /* switch (type) */
>> +       }
>> +}
>> +
>> +
>>  /**
>>   * drmcg_limit_write - parse cgroup interface files to obtain user config
>>   *
>> @@ -499,9 +771,15 @@ static ssize_t drmcg_limit_write(struct kernfs_open_file *of, char *buf,
>>
>>                         ddr->bo_limits_peak_allocated = val;
>>                         break;
>> +               case DRMCG_TYPE_LGPU:
>> +                       drmcg_nested_limit_parse(of, dm->dev, sattr);
>> +                       break;
>>                 default:
>>                         break;
>>                 }
>> +
>> +               drmcg_apply_effective(type, dm->dev, drmcg);
>> +
>>                 mutex_unlock(&dm->dev->drmcg_mutex);
>>
>>                 mutex_lock(&drmcg_mutex);
>> @@ -560,12 +838,51 @@ struct cftype files[] = {
>>                 .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_COUNT,
>>                                                 DRMCG_FTYPE_STATS),
>>         },
>> +       {
>> +               .name = "lgpu",
>> +               .seq_show = drmcg_seq_show,
>> +               .write = drmcg_limit_write,
>> +               .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
>> +                                               DRMCG_FTYPE_LIMIT),
>> +       },
>> +       {
>> +               .name = "lgpu.default",
>> +               .seq_show = drmcg_seq_show,
>> +               .flags = CFTYPE_ONLY_ON_ROOT,
>> +               .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
>> +                                               DRMCG_FTYPE_DEFAULT),
>> +       },
>> +       {
>> +               .name = "lgpu.effective",
>> +               .seq_show = drmcg_seq_show,
>> +               .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU_EFF,
>> +                                               DRMCG_FTYPE_LIMIT),
>> +       },
>>         { }     /* terminate */
>>  };
>>
>> +static int drmcg_online_fn(int id, void *ptr, void *data)
>> +{
>> +       struct drm_minor *minor = ptr;
>> +       struct drmcg *drmcg = data;
>> +
>> +       if (minor->type != DRM_MINOR_PRIMARY)
>> +               return 0;
>> +
>> +       drmcg_apply_effective(DRMCG_TYPE_LGPU, minor->dev, drmcg);
>> +
>> +       return 0;
>> +}
>> +
>> +static int drmcg_css_online(struct cgroup_subsys_state *css)
>> +{
>> +       return drm_minor_for_each(&drmcg_online_fn, css_to_drmcg(css));
>> +}
>> +
>>  struct cgroup_subsys drm_cgrp_subsys = {
>>         .css_alloc      = drmcg_css_alloc,
>>         .css_free       = drmcg_css_free,
>> +       .css_online     = drmcg_css_online,
>>         .early_init     = false,
>>         .legacy_cftypes = files,
>>         .dfl_cftypes    = files,
>> @@ -585,6 +902,9 @@ void drmcg_device_early_init(struct drm_device *dev)
>>         dev->drmcg_props.bo_limits_total_allocated_default = S64_MAX;
>>         dev->drmcg_props.bo_limits_peak_allocated_default = S64_MAX;
>>
>> +       dev->drmcg_props.lgpu_capacity = MAX_DRMCG_LGPU_CAPACITY;
>> +       bitmap_fill(dev->drmcg_props.lgpu_slots, MAX_DRMCG_LGPU_CAPACITY);
>> +
>>         drmcg_update_cg_tree(dev);
>>  }
>>  EXPORT_SYMBOL(drmcg_device_early_init);
>> --
>> 2.25.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply

* [PATCH AUTOSEL 4.19 243/252] microblaze: Prevent the overflow of the start
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Shubhrajyoti Datta, Michal Simek, Sasha Levin
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>

From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>

[ Upstream commit 061d2c1d593076424c910cb1b64ecdb5c9a6923f ]

In case the start + cache size is more than the max int the
start overflows.
Prevent the same.

Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/microblaze/kernel/cpu/cache.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/microblaze/kernel/cpu/cache.c b/arch/microblaze/kernel/cpu/cache.c
index 0bde47e4fa694..dcba53803fa5f 100644
--- a/arch/microblaze/kernel/cpu/cache.c
+++ b/arch/microblaze/kernel/cpu/cache.c
@@ -92,7 +92,8 @@ static inline void __disable_dcache_nomsr(void)
 #define CACHE_LOOP_LIMITS(start, end, cache_line_length, cache_size)	\
 do {									\
 	int align = ~(cache_line_length - 1);				\
-	end = min(start + cache_size, end);				\
+	if (start <  UINT_MAX - cache_size)				\
+		end = min(start + cache_size, end);			\
 	start &= align;							\
 } while (0)
 
-- 
2.20.1


^ permalink raw reply related


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.