Re: [PATCH] Elantech Touchpad: Fix Elantech touchpad and trackpoint for Lenovo ThinkPad notebooks.
Hi Philipp,
On Sat, Dec 29, 2018 at 6:35 AM Philipp Kaelin wrote:
>
> Initial situation:
> - The touchpad of a Lenovo ThinkPad L580 doesn't work with newer kernel
> versions eg. 4.20
> - It used to work on earlier versions eg. 4.14
>
> Cause:
> - The elantech driver was adapted in to support SMBus wich not all firmware
> versions
> of the elantech firmware support. The SMBus is used as default.
>
> Solution:
> - Previously a blacklist was introduced for devices which doesn't support the
> access using SMBus.
> The ThinkPad P52 and P72 have already been fixed by adding it to such a
> blacklist in a prevois patch.
nitpick: you are using "prevois" instead of "previous" :)
> The exact same solution fixed also the issue on the mentioned ThinkPad L580.
>
> Change:
> 1) The firmware id of the ThinkPad L580 was added to this blacklist.
> 2) To not have a half baked solution the information which firmware versions
> are using the same driver
>and therefore most probably have all the same issue was extracted from the
> Lenovo Windows driver package.
>All these firmware versions are now also added to the blacklist.
>
> Risk assesment:
> As in prevois versions of the kernel eg. 4.14 none of the devices used to be
> accessed via SMBus
> (and they are reported to work at this time) it's quite safe that this
> blaklisting doesn't cause
> any harm on devices which have not been testes but included in the blacklist.
>
> Signed-off-by: Philipp Kaelin
> ---
> drivers/input/mouse/elantech.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 9fe075c137dc..e5fa8cfd8393 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1772,10 +1772,25 @@ static const char * const i2c_blacklist_pnp_ids[] = {
> * These are known to not be working properly as bits are missing
> * in elan_i2c.
> */
> - "LEN2131", /* ThinkPad P52 w/ NFC */
> - "LEN2132", /* ThinkPad P52 */
> - "LEN2133", /* ThinkPad P72 w/ NFC */
> - "LEN2134", /* ThinkPad P72 */
> + "LEN2131", /* Walter-3 w/ NFC ThinkPad P52 w/ NFC */
> + "LEN2132", /* Walter-3 w/o/ NFCThinkPad P52*/
> + "LEN2133", /* Chironw/ NFC ThinkPad P72 w/ NFC */
> + "LEN2134", /* Chironw/o/ NFCThinkPad P72*/
> + "LEN2037", /* Lando w/ NFC ThinkPad L580 w/ NFC*/
> + "LEN2038", /* Lando w/o/ NFCThinkPad L580 */
> + "LEN004F", /* Storm w/o/ NFC*/
> + "LEN005C", /* Storm w/ NFC */
> + "LEN2030", /* Carling */
> + "LEN2031", /* Bell */
> + "LEN2032", /* Bell-2*/
> + "LEN2033", /* Storm-2 */
> + "LEN2034", /* Storm-3 */
> + "LEN2035", /* Solo w/ NFC */
> + "LEN2036", /* Solo w/o/ NFC*/
> + "LEN2039", /* Leia */
> + "LEN2130", /* Kylo (Clamshell) */
> + "LEN008F", /* Kolar w/o/ NF */
> + "LEN0090", /* Kolar w/ NFC */
That is quite a list. My initial idea with this blacklist was to keep
it short and fix the initial issue to be able to remove it entirely
(or at least on the devices we can test).
So 2 questions:
- do you have the commercial names of the various PNPId you are adding?
- are you able to test all of those? Especially if we get the SMBus
driver fixed?
I am fine adding the patch as a fix for 4.21 and backport this to
stable, but I still intend to fix elan_i2c for the next cycle (4.22)
so I'd like to know if we can safely test those machine later on.
Cheers,
Benjamin
> NULL
> };
>
> --
> 2.19.2
>
Re: KMSAN: uninit-value in tipc_nl_compat_link_set (2)
syzbot has found a reproducer for the following crash on: HEAD commit:11587f6ee534 kmsan: remove pr_err git tree: kmsan console output: https://syzkaller.appspot.com/x/log.txt?x=114c539b40 kernel config: https://syzkaller.appspot.com/x/.config?x=c8a62a4eb8ea3e9f dashboard link: https://syzkaller.appspot.com/bug?extid=d78b8a29241a195aefb8 compiler: clang version 8.0.0 (trunk 350161) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=173b7180c0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1262adab40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d78b8a29241a195ae...@syzkaller.appspotmail.com == BUG: KMSAN: uninit-value in strlen+0x3b/0xa0 lib/string.c:486 CPU: 1 PID: 9306 Comm: syz-executor172 Not tainted 4.20.0-rc7+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313 strlen+0x3b/0xa0 lib/string.c:486 nla_put_string include/net/netlink.h:1154 [inline] __tipc_nl_compat_link_set net/tipc/netlink_compat.c:708 [inline] tipc_nl_compat_link_set+0x929/0x1220 net/tipc/netlink_compat.c:744 __tipc_nl_compat_doit net/tipc/netlink_compat.c:311 [inline] tipc_nl_compat_doit+0x3aa/0xaf0 net/tipc/netlink_compat.c:344 tipc_nl_compat_handle net/tipc/netlink_compat.c:1107 [inline] tipc_nl_compat_recv+0x14d7/0x2760 net/tipc/netlink_compat.c:1210 genl_family_rcv_msg net/netlink/genetlink.c:601 [inline] genl_rcv_msg+0x185f/0x1a60 net/netlink/genetlink.c:626 netlink_rcv_skb+0x444/0x640 net/netlink/af_netlink.c:2477 genl_rcv+0x63/0x80 net/netlink/genetlink.c:637 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0xf40/0x1020 net/netlink/af_netlink.c:1336 netlink_sendmsg+0x127f/0x1300 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg net/socket.c:631 [inline] ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2116 __sys_sendmsg net/socket.c:2154 [inline] __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2161 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x440e29 Code: e8 cc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff7fdb6888 EFLAGS: 0213 ORIG_RAX: 002e RAX: ffda RBX: RCX: 00440e29 RDX: RSI: 2140 RDI: 0003 RBP: R08: 004002c8 R09: 004002c8 R10: 01fb6880 R11: 0213 R12: 00012572 R13: 00401e00 R14: R15: Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline] kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158 kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176 kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185 slab_post_alloc_hook mm/slab.h:446 [inline] slab_alloc_node mm/slub.c:2759 [inline] __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383 __kmalloc_reserve net/core/skbuff.c:137 [inline] __alloc_skb+0x309/0xa20 net/core/skbuff.c:205 alloc_skb include/linux/skbuff.h:998 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline] netlink_sendmsg+0xb82/0x1300 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg net/socket.c:631 [inline] ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2116 __sys_sendmsg net/socket.c:2154 [inline] __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2161 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 ==
Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Add ADSP reserve-memory nodes
Thanks Bjorn for review.
On 1/4/2019 5:12 AM, Bjorn Andersson wrote:
On Thu 20 Dec 05:39 PST 2018, Rohit kumar wrote:
Add memory nodes required for remoteproc q6v5_adsp pil.
This range doesn't match the documented memory map. I would prefer to
see a "Specify all PIL regions as defined in V10" or similar.
Yes, Sibi will post it along with other PIL regions with update address
in next spin.
Regards,
Bjorn
Signed-off-by: Rohit kumar
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 23a253b..c0a012f 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -88,6 +88,11 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
+
+ pil_adsp_mem: memory@8b10 {
+ reg = <0 0x8b10 0 0x1a0>;
+ no-map;
+ };
};
cpus {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Regards,
Rohit
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH 8/8] spi: lpspi: add dma mode support
Add dma mode support for LPSPI. Any frame longer than half txfifosize will
be sent by dma mode.
For now, there are some notes:
1. The maximum transfer speed in master mode depends on the slave device,
at least 40MHz on i.MX8 series (tested by spi-nor on 8qm-lpddr4-arm2
base board);
2. The maximum transfer speed in slave mode is 15MHz(i.MX7ULP),
22MHz(i.MX8 series).
Signed-off-by: Clark Wang
---
drivers/spi/spi-fsl-lpspi.c | 318 ++--
1 file changed, 306 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 83e15366b739..85e4e36b71a3 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -19,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,6 +34,9 @@
#define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
+/* The maximum bytes that edma can transfer once.*/
+#define FSL_LPSPI_MAX_EDMA_BYTES ((1 << 15) - 1)
+
#define LPSPI_CS_ACTIVE1
#define LPSPI_CS_INACTIVE 0
#define LPSPI_CS_DELAY 100
@@ -68,6 +74,8 @@
#define IER_FCIE BIT(9)
#define IER_RDIE BIT(1)
#define IER_TDIE BIT(0)
+#define DER_RDDE BIT(1)
+#define DER_TDDE BIT(0)
#define CFGR1_PCSCFG BIT(27)
#define CFGR1_PINCFG (BIT(24)|BIT(25))
#define CFGR1_PCSPOL BIT(8)
@@ -95,6 +103,7 @@ struct lpspi_config {
struct fsl_lpspi_data {
struct device *dev;
void __iomem *base;
+ unsigned long base_phys;
struct clk *clk_ipg;
struct clk *clk_per;
bool is_slave;
@@ -105,6 +114,8 @@ struct fsl_lpspi_data {
void (*tx)(struct fsl_lpspi_data *);
void (*rx)(struct fsl_lpspi_data *);
+ u32 bytes_per_word;
+ u32 bits_per_word;
u32 remain;
u8 watermark;
u8 txfifosize;
@@ -115,6 +126,11 @@ struct fsl_lpspi_data {
bool slave_aborted;
+ /* DMA */
+ bool usedma;
+ struct completion dma_rx_completion;
+ struct completion dma_tx_completion;
+
int chipselect[4];
};
@@ -162,6 +178,35 @@ static void fsl_lpspi_intctrl(struct fsl_lpspi_data
*fsl_lpspi,
writel(enable, fsl_lpspi->base + IMX7ULP_IER);
}
+static int fsl_lpspi_bytes_per_word(const int bpw)
+{
+ return DIV_ROUND_UP(bpw, BITS_PER_BYTE);
+}
+
+static bool fsl_lpspi_can_dma(struct spi_controller *controller,
+ struct spi_device *spi,
+ struct spi_transfer *transfer)
+{
+ struct fsl_lpspi_data *fsl_lpspi =
+ spi_controller_get_devdata(controller);
+ unsigned int bytes_per_word;
+
+ if (!controller->dma_rx)
+ return false;
+
+ if (fsl_lpspi->is_slave)
+ return false;
+
+ bytes_per_word = fsl_lpspi_bytes_per_word(transfer->bits_per_word);
+ if (bytes_per_word != 1 && bytes_per_word != 2 && bytes_per_word != 4)
+ return false;
+
+ if (transfer->len < fsl_lpspi->txfifosize / 2)
+ return false;
+
+ return true;
+}
+
static int lpspi_prepare_xfer_hardware(struct spi_controller *controller)
{
struct fsl_lpspi_data *fsl_lpspi =
@@ -250,11 +295,13 @@ static void fsl_lpspi_set_cmd(struct fsl_lpspi_data
*fsl_lpspi,
* For the first transfer, clear TCR_CONTC to assert SS.
* For subsequent transfer, set TCR_CONTC to keep SS asserted.
*/
- temp |= TCR_CONT;
- if (is_first_xfer)
- temp &= ~TCR_CONTC;
- else
- temp |= TCR_CONTC;
+ if (!fsl_lpspi->usedma) {
+ temp |= TCR_CONT;
+ if (is_first_xfer)
+ temp &= ~TCR_CONTC;
+ else
+ temp |= TCR_CONTC;
+ }
}
writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
@@ -265,7 +312,11 @@ static void fsl_lpspi_set_watermark(struct fsl_lpspi_data
*fsl_lpspi)
{
u32 temp;
- temp = fsl_lpspi->watermark >> 1 | (fsl_lpspi->watermark >> 1) << 16;
+ if (!fsl_lpspi->usedma)
+ temp = fsl_lpspi->watermark >> 1 |
+ (fsl_lpspi->watermark >> 1) << 16;
+ else
+ temp = fsl_lpspi->txfifosize >> 1;
writel(temp, fsl_lpspi->base + IMX7ULP_FCR);
@@ -301,12 +352,59 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data
*fsl_lpspi)
writel(scldiv | (scldiv << 8) | ((scldiv >> 1) << 16),
fsl_lpspi->base + IMX7ULP_CCR);
- dev_dbg(fsl_lpspi->dev, "perclk=%d, speed=%d, prescale =%d,
scldiv=%d\n",
+ dev_dbg(fsl_lpspi->dev, "perclk=%d, speed=%d, prescale=%d, scldiv=%d\n",
perclk
[PATCH 6/8] spi: lpspi: add the error info of transfer speed setting
Add a error info when set a speed which greater than half of per-clk of
spi module.
The minimum SCK period is 2 cycles(CCR[SCKDIV]). So the maximum transfer
speed is half of spi per-clk.
Signed-off-by: Clark Wang
---
drivers/spi/spi-fsl-lpspi.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 84dcb9e176b8..69635cde0e22 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -255,6 +255,13 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data
*fsl_lpspi)
u8 prescale;
perclk_rate = clk_get_rate(fsl_lpspi->clk_per);
+
+ if (config.speed_hz > perclk_rate / 2) {
+ dev_err(fsl_lpspi->dev,
+ "per-clk should be at least two times of transfer speed");
+ return -EINVAL;
+ }
+
for (prescale = 0; prescale < 8; prescale++) {
scldiv = perclk_rate /
(clkdivs[prescale] * config.speed_hz) - 2;
@@ -304,7 +311,7 @@ static int fsl_lpspi_config(struct fsl_lpspi_data
*fsl_lpspi)
return 0;
}
-static void fsl_lpspi_setup_transfer(struct spi_device *spi,
+static int fsl_lpspi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
{
struct fsl_lpspi_data *fsl_lpspi =
@@ -337,7 +344,7 @@ static void fsl_lpspi_setup_transfer(struct spi_device *spi,
else
fsl_lpspi->watermark = fsl_lpspi->txfifosize;
- fsl_lpspi_config(fsl_lpspi);
+ return fsl_lpspi_config(fsl_lpspi);
}
static int fsl_lpspi_slave_abort(struct spi_controller *controller)
@@ -429,7 +436,10 @@ static int fsl_lpspi_transfer_one_msg(struct
spi_controller *controller,
msg->actual_length = 0;
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
- fsl_lpspi_setup_transfer(spi, xfer);
+ ret = fsl_lpspi_setup_transfer(spi, xfer);
+ if (ret < 0)
+ goto complete;
+
fsl_lpspi_set_cmd(fsl_lpspi, is_first_xfer);
is_first_xfer = false;
--
2.17.1
[PATCH 4/8] spi: lpspi: Fix wrong transmission when don't use CONT
Add judgment on SR_MBF and FSR_RXCOUNT.
In PIO mode, if don't use CONT to keep cs selected in one transfer, the
transfer will go wrong. FCIE will be set after one frame transfer
finish. If use CONT, the frame refer to the whole data in one transfer.
If don't use CONT, the frame refer to one byte of whole data. This will
cause the transfer ending early.
This patch add a register reading in isr function, it might lead to a
slight decrease in the max transmission speed in PIO mode.
Signed-off-by: Clark Wang
---
drivers/spi/spi-fsl-lpspi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index f32a2e0d7ae1..51c85cf0bd9f 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -52,6 +52,7 @@
#define CR_RTF BIT(8)
#define CR_RST BIT(1)
#define CR_MEN BIT(0)
+#define SR_MBF BIT(24)
#define SR_TCF BIT(10)
#define SR_FCF BIT(9)
#define SR_RDF BIT(1)
@@ -65,6 +66,7 @@
#define CFGR1_PCSPOL BIT(8)
#define CFGR1_NOSTALL BIT(3)
#define CFGR1_MASTER BIT(0)
+#define FSR_RXCOUNT(BIT(16)|BIT(17)|BIT(18))
#define RSR_RXEMPTYBIT(1)
#define TCR_CPOL BIT(31)
#define TCR_CPHA BIT(30)
@@ -446,6 +448,13 @@ static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+ if (temp_SR & SR_MBF ||
+ readl(fsl_lpspi->base + IMX7ULP_FSR) & FSR_RXCOUNT) {
+ writel(SR_FCF, fsl_lpspi->base + IMX7ULP_SR);
+ fsl_lpspi_intctrl(fsl_lpspi, IER_FCIE);
+ return IRQ_HANDLED;
+ }
+
if (temp_SR & SR_FCF && (temp_IER & IER_FCIE)) {
writel(SR_FCF, fsl_lpspi->base + IMX7ULP_SR);
complete(&fsl_lpspi->xfer_done);
--
2.17.1
[PATCH 1/8] spi: lpspi: Add i.MX8 boards support for lpspi
Add both ipg and per clock for lpspi to support i.MX8QM/QXP boards.
Signed-off-by: Clark Wang
---
drivers/spi/spi-fsl-lpspi.c | 52 +
1 file changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 08dcc3c22e88..5802f188051b 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -80,7 +80,8 @@ struct lpspi_config {
struct fsl_lpspi_data {
struct device *dev;
void __iomem *base;
- struct clk *clk;
+ struct clk *clk_ipg;
+ struct clk *clk_per;
bool is_slave;
void *rx_buf;
@@ -147,8 +148,19 @@ static int lpspi_prepare_xfer_hardware(struct
spi_controller *controller)
{
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
+ int ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_per);
+ if (ret) {
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
+ return ret;
+ }
- return clk_prepare_enable(fsl_lpspi->clk);
+ return 0;
}
static int lpspi_unprepare_xfer_hardware(struct spi_controller *controller)
@@ -156,7 +168,8 @@ static int lpspi_unprepare_xfer_hardware(struct
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_lpspi->clk);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
+ clk_disable_unprepare(fsl_lpspi->clk_per);
return 0;
}
@@ -249,7 +262,7 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data
*fsl_lpspi)
unsigned int perclk_rate, scldiv;
u8 prescale;
- perclk_rate = clk_get_rate(fsl_lpspi->clk);
+ perclk_rate = clk_get_rate(fsl_lpspi->clk_per);
for (prescale = 0; prescale < 8; prescale++) {
scldiv = perclk_rate /
(clkdivs[prescale] * config.speed_hz) - 2;
@@ -522,15 +535,30 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
- fsl_lpspi->clk = devm_clk_get(&pdev->dev, "ipg");
- if (IS_ERR(fsl_lpspi->clk)) {
- ret = PTR_ERR(fsl_lpspi->clk);
+ fsl_lpspi->clk_per = devm_clk_get(&pdev->dev, "per");
+ if (IS_ERR(fsl_lpspi->clk_per)) {
+ ret = PTR_ERR(fsl_lpspi->clk_per);
+ goto out_controller_put;
+ }
+
+ fsl_lpspi->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
+ if (IS_ERR(fsl_lpspi->clk_ipg)) {
+ ret = PTR_ERR(fsl_lpspi->clk_ipg);
+ goto out_controller_put;
+ }
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "can't enable lpspi ipg clock, ret=%d\n", ret);
goto out_controller_put;
}
- ret = clk_prepare_enable(fsl_lpspi->clk);
+ ret = clk_prepare_enable(fsl_lpspi->clk_per);
if (ret) {
- dev_err(&pdev->dev, "can't enable lpspi clock, ret=%d\n", ret);
+ dev_err(&pdev->dev,
+ "can't enable lpspi per clock, ret=%d\n", ret);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
goto out_controller_put;
}
@@ -538,7 +566,8 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
- clk_disable_unprepare(fsl_lpspi->clk);
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
ret = devm_spi_register_controller(&pdev->dev, controller);
if (ret < 0) {
@@ -560,7 +589,8 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_lpspi->clk);
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
return 0;
}
--
2.17.1
[PATCH 7/8] spi: lpspi: Add cs-gpio support
Add cs-gpio feature for LPSPI.
The cs line will be controlled in fsl_lpspi_transfe_one_msg() function.
Still support using the mode without cs-gpio. It depends on if attribute
cs-gpio has been configured in dts file.
Signed-off-by: Clark Wang
---
drivers/spi/spi-fsl-lpspi.c | 89 -
1 file changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 69635cde0e22..83e15366b739 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -16,7 +17,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -28,6 +31,10 @@
#define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
+#define LPSPI_CS_ACTIVE1
+#define LPSPI_CS_INACTIVE 0
+#define LPSPI_CS_DELAY 100
+
/* i.MX7ULP LPSPI registers */
#define IMX7ULP_VERID 0x0
#define IMX7ULP_PARAM 0x4
@@ -91,6 +98,7 @@ struct fsl_lpspi_data {
struct clk *clk_ipg;
struct clk *clk_per;
bool is_slave;
+ bool hascsgpio;
void *rx_buf;
const void *tx_buf;
@@ -106,6 +114,8 @@ struct fsl_lpspi_data {
struct completion xfer_done;
bool slave_aborted;
+
+ int chipselect[4];
};
static const struct of_device_id fsl_lpspi_dt_ids[] = {
@@ -178,6 +188,20 @@ static int lpspi_unprepare_xfer_hardware(struct
spi_controller *controller)
return 0;
}
+static void fsl_lpspi_chipselect(struct spi_device *spi, bool enable)
+{
+ struct fsl_lpspi_data *fsl_lpspi =
+ spi_controller_get_devdata(spi->controller);
+ int gpio = fsl_lpspi->chipselect[spi->chip_select];
+
+ enable = (!!(spi->mode & SPI_CS_HIGH) == enable);
+
+ if (!gpio_is_valid(gpio))
+ return;
+
+ gpio_set_value_cansleep(gpio, enable);
+}
+
static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data *fsl_lpspi)
{
u8 txfifo_cnt;
@@ -422,6 +446,25 @@ static int fsl_lpspi_transfer_one(struct spi_controller
*controller,
return 0;
}
+static int fsl_lpspi_setup(struct spi_device *spi)
+{
+ struct fsl_lpspi_data *fsl_lpspi =
+ spi_controller_get_devdata(spi->controller);
+ int gpio = fsl_lpspi->chipselect[spi->chip_select];
+
+ dev_dbg(&spi->dev, "%s: mode %d, %u bpw, %d hz\n", __func__,
+spi->mode, spi->bits_per_word, spi->max_speed_hz);
+
+ if (gpio_is_valid(gpio)) {
+ gpio_direction_output(gpio,
+ fsl_lpspi->config.mode & SPI_CS_HIGH ? 0 : 1);
+ }
+
+ fsl_lpspi_chipselect(spi, LPSPI_CS_INACTIVE);
+
+ return 0;
+}
+
static int fsl_lpspi_transfer_one_msg(struct spi_controller *controller,
struct spi_message *msg)
{
@@ -430,8 +473,12 @@ static int fsl_lpspi_transfer_one_msg(struct
spi_controller *controller,
struct spi_device *spi = msg->spi;
struct spi_transfer *xfer;
bool is_first_xfer = true;
+ bool keep_cs = false;
int ret = 0;
+ if (fsl_lpspi->hascsgpio)
+ fsl_lpspi_chipselect(spi, LPSPI_CS_ACTIVE);
+
msg->status = 0;
msg->actual_length = 0;
@@ -448,10 +495,24 @@ static int fsl_lpspi_transfer_one_msg(struct
spi_controller *controller,
if (ret < 0)
goto complete;
+ if (fsl_lpspi->hascsgpio && xfer->cs_change) {
+ if (list_is_last(&xfer->transfer_list,
+&msg->transfers)) {
+ keep_cs = true;
+ } else {
+ fsl_lpspi_chipselect(spi, LPSPI_CS_INACTIVE);
+ udelay(10);
+ fsl_lpspi_chipselect(spi, LPSPI_CS_ACTIVE);
+ }
+ }
+
msg->actual_length += xfer->len;
}
complete:
+ if (fsl_lpspi->hascsgpio && !keep_cs)
+ fsl_lpspi_chipselect(spi, LPSPI_CS_INACTIVE);
+
msg->status = ret;
spi_finalize_current_message(controller);
@@ -531,10 +592,13 @@ static int fsl_lpspi_init_rpm(struct fsl_lpspi_data
*fsl_lpspi)
static int fsl_lpspi_probe(struct platform_device *pdev)
{
+ struct device_node *np = pdev->dev.of_node;
struct fsl_lpspi_data *fsl_lpspi;
struct spi_controller *controller;
+ struct spi_imx_master *lpspi_platform_info =
+ dev_get_platdata(&pdev->dev);
struct resource *res;
- int ret, irq;
+ int i, ret, irq;
u32 temp;
if (of_property_read_bool((&pdev->dev)->of_node, "spi-slave"))
@@ -558,6 +622,29 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi->is_slave = of_property_read_bool((&
[PATCH 2/8] spi: lpspi: enable runtime pm for lpspi
From: Han Xu
Enable the runtime power management for lpspi module.
Do some adaptation work from kernel 4.9 to 4.14.
Signed-off-by: Clark Wang
Signed-off-by: Han Xu
Reviewed-by: Frank Li
---
drivers/spi/spi-fsl-lpspi.c | 117
1 file changed, 92 insertions(+), 25 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 5802f188051b..3e935db5ff02 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -16,7 +16,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -24,6 +26,8 @@
#define DRIVER_NAME "fsl_lpspi"
+#define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
+
/* i.MX7ULP LPSPI registers */
#define IMX7ULP_VERID 0x0
#define IMX7ULP_PARAM 0x4
@@ -150,13 +154,9 @@ static int lpspi_prepare_xfer_hardware(struct
spi_controller *controller)
spi_controller_get_devdata(controller);
int ret;
- ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(fsl_lpspi->clk_per);
- if (ret) {
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
+ ret = pm_runtime_get_sync(fsl_lpspi->dev);
+ if (ret < 0) {
+ dev_err(fsl_lpspi->dev, "failed to enable clock\n");
return ret;
}
@@ -168,8 +168,8 @@ static int lpspi_unprepare_xfer_hardware(struct
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
- clk_disable_unprepare(fsl_lpspi->clk_per);
+ pm_runtime_mark_last_busy(fsl_lpspi->dev);
+ pm_runtime_put_autosuspend(fsl_lpspi->dev);
return 0;
}
@@ -476,6 +476,45 @@ static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
return IRQ_NONE;
}
+int fsl_lpspi_runtime_resume(struct device *dev)
+{
+ struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_per);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+ if (ret) {
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ return ret;
+ }
+
+ return 0;
+}
+
+int fsl_lpspi_runtime_suspend(struct device *dev)
+{
+ struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
+
+ return 0;
+}
+
+static int fsl_lpspi_init_rpm(struct fsl_lpspi_data *fsl_lpspi)
+{
+ struct device *dev = fsl_lpspi->dev;
+
+ pm_runtime_enable(dev);
+ pm_runtime_set_autosuspend_delay(dev, FSL_LPSPI_RPM_TIMEOUT);
+ pm_runtime_use_autosuspend(dev);
+
+ return 0;
+}
+
static int fsl_lpspi_probe(struct platform_device *pdev)
{
struct fsl_lpspi_data *fsl_lpspi;
@@ -501,6 +540,7 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi = spi_controller_get_devdata(controller);
fsl_lpspi->dev = &pdev->dev;
+ dev_set_drvdata(&pdev->dev, fsl_lpspi);
fsl_lpspi->is_slave = of_property_read_bool((&pdev->dev)->of_node,
"spi-slave");
@@ -547,28 +587,21 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
- ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
- if (ret) {
- dev_err(&pdev->dev,
- "can't enable lpspi ipg clock, ret=%d\n", ret);
+ /* enable the clock */
+ ret = fsl_lpspi_init_rpm(fsl_lpspi);
+ if (ret)
goto out_controller_put;
- }
- ret = clk_prepare_enable(fsl_lpspi->clk_per);
- if (ret) {
- dev_err(&pdev->dev,
- "can't enable lpspi per clock, ret=%d\n", ret);
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
- goto out_controller_put;
+ ret = pm_runtime_get_sync(fsl_lpspi->dev);
+ if (ret < 0) {
+ dev_err(fsl_lpspi->dev, "failed to enable clock\n");
+ return ret;
}
temp = readl(fsl_lpspi->base + IMX7ULP_PARAM);
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
- clk_disable_unprepare(fsl_lpspi->clk_per);
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
-
ret = devm_spi_register_controller(&pdev->dev, controller);
if (ret < 0) {
dev_err(&pdev->dev, "spi_register_controller error.\n");
@@ -589,16 +622,50 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_
[PATCH 0/8] spi: lpspi: Fix bugs and Add some functions support
Hi Mark, As subject, these fucntions support, including: - Support i.MX8 series boards; - Support cs-gpio fucntion; - Support DMA mode for both master and salve mode. >From patch 3 to 6 are some bug-fix for PIO mode. In order to avoid data loss and improve data transmission stability. These are some notes about cs-gpio and DMA: - cs-gpio: Because LPSPI driver don't use default implementation of transfer_one_message(), I do the cs-gpio control way as same as the way used in spi core; - DMA: Any frame length longer than half txfifosize will be sent by DMA mode. For now, there are some limits: 1. The maximum transfer speed in master mode depends on the slave device, at least 40MHz on i.MX8 series (tested by spi-nor on 8qm-lpddr4-arm2 base board); 2. The maximum transfer speed in slave mode is 15MHz(i.MX7ULP), 22MHz(i.MX8 series). Clark Wang (8): spi: lpspi: Add i.MX8 boards support for lpspi spi: lpspi: enable runtime pm for lpspi spi: lpspi: Improve the stability of lpspi data transmission spi: lpspi: Fix wrong transmission when don't use CONT spi: lpspi: Fix CLK pin becomes low before one transfer spi: lpspi: add the error info of transfer speed setting spi: lpspi: Add cs-gpio support spi: lpspi: add dma mode support drivers/spi/spi-fsl-lpspi.c | 612 1 file changed, 552 insertions(+), 60 deletions(-) -- 2.17.1
[PATCH 3/8] spi: lpspi: Improve the stability of lpspi data transmission
Use SR_TDF to judge if need to send data, and SR_FCF is to judge if
transmission end and to replace the waiting after transmission end.
This waiting has no actual meaning, for module will set the FCF
flag at the real end.
The changes of interrupt flag and ISR function reduce the times of
calling ISR. The use of the FCF flag improves the stability of the
data transmission. These two points generally improve the data
transfer speed of lpspi, especially when it is set to slave mode
it can support higher transfer speed of the host.
After making these changes, there is no need to use
fsl_lpspi_txfifo_empty(), so remove it.
Signed-off-by: Clark Wang
---
drivers/spi/spi-fsl-lpspi.c | 61 -
1 file changed, 20 insertions(+), 41 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 3e935db5ff02..f32a2e0d7ae1 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -53,9 +53,11 @@
#define CR_RST BIT(1)
#define CR_MEN BIT(0)
#define SR_TCF BIT(10)
+#define SR_FCF BIT(9)
#define SR_RDF BIT(1)
#define SR_TDF BIT(0)
#define IER_TCIE BIT(10)
+#define IER_FCIE BIT(9)
#define IER_RDIE BIT(1)
#define IER_TDIE BIT(0)
#define CFGR1_PCSCFG BIT(27)
@@ -174,28 +176,10 @@ static int lpspi_unprepare_xfer_hardware(struct
spi_controller *controller)
return 0;
}
-static int fsl_lpspi_txfifo_empty(struct fsl_lpspi_data *fsl_lpspi)
-{
- u32 txcnt;
- unsigned long orig_jiffies = jiffies;
-
- do {
- txcnt = readl(fsl_lpspi->base + IMX7ULP_FSR) & 0xff;
-
- if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
- dev_dbg(fsl_lpspi->dev, "txfifo empty timeout\n");
- return -ETIMEDOUT;
- }
- cond_resched();
-
- } while (txcnt);
-
- return 0;
-}
-
static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data *fsl_lpspi)
{
u8 txfifo_cnt;
+ u32 temp;
txfifo_cnt = readl(fsl_lpspi->base + IMX7ULP_FSR) & 0xff;
@@ -206,9 +190,15 @@ static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data
*fsl_lpspi)
txfifo_cnt++;
}
- if (!fsl_lpspi->remain && (txfifo_cnt < fsl_lpspi->txfifosize))
- writel(0, fsl_lpspi->base + IMX7ULP_TDR);
- else
+ if (txfifo_cnt < fsl_lpspi->txfifosize) {
+ if (!fsl_lpspi->is_slave) {
+ temp = readl(fsl_lpspi->base + IMX7ULP_TCR);
+ temp &= ~TCR_CONTC;
+ writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
+ }
+
+ fsl_lpspi_intctrl(fsl_lpspi, IER_FCIE);
+ } else
fsl_lpspi_intctrl(fsl_lpspi, IER_TDIE);
}
@@ -404,12 +394,6 @@ static int fsl_lpspi_transfer_one(struct spi_controller
*controller,
if (ret)
return ret;
- ret = fsl_lpspi_txfifo_empty(fsl_lpspi);
- if (ret)
- return ret;
-
- fsl_lpspi_read_rx_fifo(fsl_lpspi);
-
return 0;
}
@@ -421,7 +405,6 @@ static int fsl_lpspi_transfer_one_msg(struct spi_controller
*controller,
struct spi_device *spi = msg->spi;
struct spi_transfer *xfer;
bool is_first_xfer = true;
- u32 temp;
int ret = 0;
msg->status = 0;
@@ -441,13 +424,6 @@ static int fsl_lpspi_transfer_one_msg(struct
spi_controller *controller,
}
complete:
- if (!fsl_lpspi->is_slave) {
- /* de-assert SS, then finalize current message */
- temp = readl(fsl_lpspi->base + IMX7ULP_TCR);
- temp &= ~TCR_CONTC;
- writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
- }
-
msg->status = ret;
spi_finalize_current_message(controller);
@@ -456,20 +432,23 @@ static int fsl_lpspi_transfer_one_msg(struct
spi_controller *controller,
static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
{
+ u32 temp_SR, temp_IER;
struct fsl_lpspi_data *fsl_lpspi = dev_id;
- u32 temp;
+ temp_IER = readl(fsl_lpspi->base + IMX7ULP_IER);
fsl_lpspi_intctrl(fsl_lpspi, 0);
- temp = readl(fsl_lpspi->base + IMX7ULP_SR);
+ temp_SR = readl(fsl_lpspi->base + IMX7ULP_SR);
fsl_lpspi_read_rx_fifo(fsl_lpspi);
- if (temp & SR_TDF) {
+ if ((temp_SR & SR_TDF) && (temp_IER & IER_TDIE)) {
fsl_lpspi_write_tx_fifo(fsl_lpspi);
+ return IRQ_HANDLED;
+ }
- if (!fsl_lpspi->remain)
+ if (temp_SR & SR_FCF && (temp_IER & IER_FCIE)) {
+ writel(SR_FCF, fsl_lpspi->base + IMX7ULP_SR);
complete(&fsl_lpspi->xfer_done);
-
return IRQ_HANDLED;
}
--
2.17.1
[PATCH 5/8] spi: lpspi: Fix CLK pin becomes low before one transfer
Remove Reset operation in fsl_lpspi_config(). This RST may cause both CLK
and CS pins go from high to low level under cs-gpio mode.
Add fsl_lpspi_reset() function after one message transfer to clear all
flags in use.
Signed-off-by: Clark Wang
Reviewed-by: Fugang Duan
---
drivers/spi/spi-fsl-lpspi.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 51c85cf0bd9f..84dcb9e176b8 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -281,10 +281,6 @@ static int fsl_lpspi_config(struct fsl_lpspi_data
*fsl_lpspi)
u32 temp;
int ret;
- temp = CR_RST;
- writel(temp, fsl_lpspi->base + IMX7ULP_CR);
- writel(0, fsl_lpspi->base + IMX7ULP_CR);
-
if (!fsl_lpspi->is_slave) {
ret = fsl_lpspi_set_bitrate(fsl_lpspi);
if (ret)
@@ -375,6 +371,24 @@ static int fsl_lpspi_wait_for_completion(struct
spi_controller *controller)
return 0;
}
+static int fsl_lpspi_reset(struct fsl_lpspi_data *fsl_lpspi)
+{
+ u32 temp;
+
+ /* Disable all interrupt */
+ fsl_lpspi_intctrl(fsl_lpspi, 0);
+
+ /* W1C for all flags in SR */
+ temp = 0x3F << 8;
+ writel(temp, fsl_lpspi->base + IMX7ULP_SR);
+
+ /* Clear FIFO and disable module */
+ temp = CR_RRF | CR_RTF;
+ writel(temp, fsl_lpspi->base + IMX7ULP_CR);
+
+ return 0;
+}
+
static int fsl_lpspi_transfer_one(struct spi_controller *controller,
struct spi_device *spi,
struct spi_transfer *t)
@@ -396,6 +410,8 @@ static int fsl_lpspi_transfer_one(struct spi_controller
*controller,
if (ret)
return ret;
+ fsl_lpspi_reset(fsl_lpspi);
+
return 0;
}
--
2.17.1
Re: WARNING in enqueue_task_dl
Hi, On 02/01/19 10:15, luca abeni wrote: > Hi all, > (and, happy new year to everyone!) > > this looks similar to a bug we have seen some time ago (a task > switching from SCHED_OTHER to SCHED_DEADLINE while inheriting a > deadline from a SCHED_DEADLINE task triggers the warning)... > > Juri, I think you found a fix for such a bug; has it been committed? Looks similar to the one I proposed this fix for: https://lore.kernel.org/lkml/20181119153201.GB2119@localhost.localdomain/ AFAIK it hasn't been reviewed/tested yet. Could you (or someone) please have a look? Best, - Juri
[PATCH] x86/boot: drop memset from copy.S
According to objdump output of setup, function memset is not used in
setup code. Currently, all usage of memset in setup come from macro
definition of string.h.
Signed-off-by: Cao jin
---
Compiled and booted under x86_64; compiled under i386.
Questions: now there is 2 definition of memcpy, one lies in copy.S,
another lies in string.h which is mapped to gcc builtin function. Do we
still need 2 definition? Could we move the content of copy.S to
boot/string.c?
At first glance, the usage of string.{c.h} of setup is kind of confusing,
they are also used in compressed/ and purgatory/
arch/x86/boot/copy.S | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/x86/boot/copy.S b/arch/x86/boot/copy.S
index 15d9f74b0008..5157d08b0ff2 100644
--- a/arch/x86/boot/copy.S
+++ b/arch/x86/boot/copy.S
@@ -33,21 +33,6 @@ GLOBAL(memcpy)
retl
ENDPROC(memcpy)
-GLOBAL(memset)
- pushw %di
- movw%ax, %di
- movzbl %dl, %eax
- imull $0x01010101,%eax
- pushw %cx
- shrw$2, %cx
- rep; stosl
- popw%cx
- andw$3, %cx
- rep; stosb
- popw%di
- retl
-ENDPROC(memset)
-
GLOBAL(copy_from_fs)
pushw %ds
pushw %fs
--
2.17.0
Re: [PATCH v1] cpufreq: qcom: Read voltage LUT and populate OPP
On 12/22/2018 3:15 AM, Stephen Boyd wrote: Quoting Taniya Das (2018-12-21 10:06:48) Add support to read the voltage look up table and populate OPP for all corresponding CPUS. Yes, but why? Please specify the motivations in the commit text. Sure, would update in the next patch. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. --
[PATCH v3 2/3] virtio-balloon: improve update_balloon_size_func
There is no need to update the balloon actual register when there is no ballooning request. This patch avoids update_balloon_size when diff is 0. Signed-off-by: Wei Wang Reviewed-by: Cornelia Huck Reviewed-by: Halil Pasic --- drivers/virtio/virtio_balloon.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index fb12fe2..e33dc8e 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -457,9 +457,12 @@ static void update_balloon_size_func(struct work_struct *work) update_balloon_size_work); diff = towards_target(vb); + if (!diff) + return; + if (diff > 0) diff -= fill_balloon(vb, diff); - else if (diff < 0) + else diff += leak_balloon(vb, -diff); update_balloon_size(vb); -- 2.7.4
[PATCH v3 3/3] virtio_balloon: remove the unnecessary 0-initialization
We've changed to kzalloc the vb struct, so no need to 0-initialize
this field one more time.
Signed-off-by: Wei Wang
---
drivers/virtio/virtio_balloon.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index e33dc8e..f19061b 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -925,7 +925,6 @@ static int virtballoon_probe(struct virtio_device *vdev)
VIRTIO_BALLOON_CMD_ID_STOP);
vb->cmd_id_stop = cpu_to_virtio32(vb->vdev,
VIRTIO_BALLOON_CMD_ID_STOP);
- vb->num_free_page_blocks = 0;
spin_lock_init(&vb->free_page_list_lock);
INIT_LIST_HEAD(&vb->free_page_list);
if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
--
2.7.4
[PATCH v3 1/3] virtio-balloon: tweak config_changed implementation
virtio-ccw has deadlock issues with reading the config space inside the
interrupt context, so we tweak the virtballoon_changed implementation
by moving the config read operations into the related workqueue contexts.
The config_read_bitmap is used as a flag to the workqueue callbacks
about the related config fields that need to be read.
The cmd_id_received is also renamed to cmd_id_received_cache, and
the value should be obtained via virtio_balloon_cmd_id_received.
Reported-by: Christian Borntraeger
Signed-off-by: Wei Wang
Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
---
drivers/virtio/virtio_balloon.c | 98 +++--
1 file changed, 65 insertions(+), 33 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 728ecd1..fb12fe2 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -61,6 +61,10 @@ enum virtio_balloon_vq {
VIRTIO_BALLOON_VQ_MAX
};
+enum virtio_balloon_config_read {
+ VIRTIO_BALLOON_CONFIG_READ_CMD_ID = 0,
+};
+
struct virtio_balloon {
struct virtio_device *vdev;
struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
@@ -77,14 +81,20 @@ struct virtio_balloon {
/* Prevent updating balloon when it is being canceled. */
spinlock_t stop_update_lock;
bool stop_update;
+ /* Bitmap to indicate if reading the related config fields are needed */
+ unsigned long config_read_bitmap;
/* The list of allocated free pages, waiting to be given back to mm */
struct list_head free_page_list;
spinlock_t free_page_list_lock;
/* The number of free page blocks on the above list */
unsigned long num_free_page_blocks;
- /* The cmd id received from host */
- u32 cmd_id_received;
+ /*
+* The cmd id received from host.
+* Read it via virtio_balloon_cmd_id_received to get the latest value
+* sent from host.
+*/
+ u32 cmd_id_received_cache;
/* The cmd id that is actively in use */
__virtio32 cmd_id_active;
/* Buffer to store the stop sign */
@@ -390,37 +400,31 @@ static unsigned long return_free_pages_to_mm(struct
virtio_balloon *vb,
return num_returned;
}
+static void virtio_balloon_queue_free_page_work(struct virtio_balloon *vb)
+{
+ if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
+ return;
+
+ /* No need to queue the work if the bit was already set. */
+ if (test_and_set_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID,
+&vb->config_read_bitmap))
+ return;
+
+ queue_work(vb->balloon_wq, &vb->report_free_page_work);
+}
+
static void virtballoon_changed(struct virtio_device *vdev)
{
struct virtio_balloon *vb = vdev->priv;
unsigned long flags;
- s64 diff = towards_target(vb);
-
- if (diff) {
- spin_lock_irqsave(&vb->stop_update_lock, flags);
- if (!vb->stop_update)
- queue_work(system_freezable_wq,
- &vb->update_balloon_size_work);
- spin_unlock_irqrestore(&vb->stop_update_lock, flags);
- }
- if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
- virtio_cread(vdev, struct virtio_balloon_config,
-free_page_report_cmd_id, &vb->cmd_id_received);
- if (vb->cmd_id_received == VIRTIO_BALLOON_CMD_ID_DONE) {
- /* Pass ULONG_MAX to give back all the free pages */
- return_free_pages_to_mm(vb, ULONG_MAX);
- } else if (vb->cmd_id_received != VIRTIO_BALLOON_CMD_ID_STOP &&
- vb->cmd_id_received !=
- virtio32_to_cpu(vdev, vb->cmd_id_active)) {
- spin_lock_irqsave(&vb->stop_update_lock, flags);
- if (!vb->stop_update) {
- queue_work(vb->balloon_wq,
- &vb->report_free_page_work);
- }
- spin_unlock_irqrestore(&vb->stop_update_lock, flags);
- }
+ spin_lock_irqsave(&vb->stop_update_lock, flags);
+ if (!vb->stop_update) {
+ queue_work(system_freezable_wq,
+ &vb->update_balloon_size_work);
+ virtio_balloon_queue_free_page_work(vb);
}
+ spin_unlock_irqrestore(&vb->stop_update_lock, flags);
}
static void update_balloon_size(struct virtio_balloon *vb)
@@ -527,6 +531,17 @@ static int init_vqs(struct virtio_balloon *vb)
return 0;
}
+static u32 virtio_balloon_cmd_id_received(struct virtio_balloon *vb)
+{
+ if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID,
+ &vb->config_read_bitmap))
+ virtio_cread(vb->
[PATCH v3 0/3] virtio-balloon: tweak config_changed
Since virtio-ccw doesn't work with accessing to the config space inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. v2->v3 ChangeLog: - rename cmd_id_received to cmd_id_received_cache, and have call sites read the latest value via virtio_balloon_cmd_id_received. (Still kept Cornelia and Halil's reviewed-by as it's a minor change) - remove zeroing vb->num_free_page_blocks in probe since vb is allocated via kzalloc. v1->v2 ChangeLog: - add config_read_bitmap to indicate to the workqueue callbacks about the necessity of reading the related config fields. Wei Wang (3): virtio-balloon: tweak config_changed implementation virtio-balloon: improve update_balloon_size_func virtio_balloon: remove the unnecessary 0-initialization drivers/virtio/virtio_balloon.c | 104 ++-- 1 file changed, 69 insertions(+), 35 deletions(-) -- 2.7.4
Re: linux-next: Tree for Jan 7
Hi Stephen, Michael,
Happy NY! Looking forward to lots of linux-next releases and build
logs in 2019 ;-)
On Mon, Jan 7, 2019 at 5:08 AM Stephen Rothwell wrote:
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /kisskb/.
Reason: Error reading from remote server
Apache/2.4.37 (Debian) Server at kisskb.ellerman.id.au Port 80
Oops...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
Hi Kai-Heng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kai-Heng-Feng/HID-i2c-hid-Ignore-input-report-if-there-s-no-data-present-on-Elan-touchpanels/20190107-142834
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/hid/i2c-hid/i2c-hid-core.c: In function 'i2c_hid_get_input':
drivers/hid/i2c-hid/i2c-hid-core.c:510:37: warning: missing terminating "
character
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^
drivers/hid/i2c-hid/i2c-hid-core.c:511:15: warning: missing terminating '
character
there's no data\n", __func__);
^
drivers/hid/i2c-hid/i2c-hid-core.c:1359: error: unterminated argument list
invoking macro "dev_warn_once"
MODULE_LICENSE("GPL");
>> drivers/hid/i2c-hid/i2c-hid-core.c:510:3: error: 'dev_warn_once' undeclared
>> (first use in this function); did you mean 'dev_fwnode'?
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^
dev_fwnode
drivers/hid/i2c-hid/i2c-hid-core.c:510:3: note: each undeclared identifier
is reported only once for each function it appears in
drivers/hid/i2c-hid/i2c-hid-core.c:510:16: error: expected ';' at end of
input
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^
;
drivers/hid/i2c-hid/i2c-hid-core.c:1359:
MODULE_LICENSE("GPL");
drivers/hid/i2c-hid/i2c-hid-core.c:510:3: error: expected declaration or
statement at end of input
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^
drivers/hid/i2c-hid/i2c-hid-core.c:510:3: error: expected declaration or
statement at end of input
At top level:
drivers/hid/i2c-hid/i2c-hid-core.c:481:13: warning: 'i2c_hid_get_input'
defined but not used [-Wunused-function]
static void i2c_hid_get_input(struct i2c_hid *ihid)
^
drivers/hid/i2c-hid/i2c-hid-core.c:441:12: warning: 'i2c_hid_hwreset'
defined but not used [-Wunused-function]
static int i2c_hid_hwreset(struct i2c_client *client)
^~~
drivers/hid/i2c-hid/i2c-hid-core.c:330:12: warning:
'i2c_hid_set_or_send_report' defined but not used [-Wunused-function]
static int i2c_hid_set_or_send_report(struct i2c_client *client, u8
reportType,
^~
drivers/hid/i2c-hid/i2c-hid-core.c:291:12: warning: 'i2c_hid_get_report'
defined but not used [-Wunused-function]
static int i2c_hid_get_report(struct i2c_client *client, u8 reportType,
^~
drivers/hid/i2c-hid/i2c-hid-core.c:195:12: warning: 'i2c_hid_lookup_quirk'
defined but not used [-Wunused-function]
static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16 idProduct)
^~~~
vim +510 drivers/hid/i2c-hid/i2c-hid-core.c
480
481 static void i2c_hid_get_input(struct i2c_hid *ihid)
482 {
483 int ret;
484 u32 ret_size;
485 int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
486
487 if (size > ihid->bufsize)
488 size = ihid->bufsize;
489
490 ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
491 if (ret != size) {
492 if (ret < 0)
493 return;
494
495 dev_err(&ihid->client->dev, "%s: got %d data instead of
%d\n",
496 __func__, ret, size);
497 return;
498 }
499
500 ret_size = ihid->inbuf[0] | ihid->inbuf[1] << 8;
501
502 if (!ret_size) {
503 /* host or device initiated RESET completed */
504 if (test_and_clear_bit(I2C_HID_RESET_PENDING,
&ihid->flags))
505 wake_up(&ihid->wait);
506 return;
507 }
508
509 if (ihid->quirks & I2C_HID_QUIRK_BOGUS_IRQ && ret_size ==
0x) {
> 510 dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
511there's no data\n", __func__);
512 return;
513 }
514
515 if ((ret_size > size) || (ret_size < 2)) {
516 dev_err(&ihid->client->dev, "%s: incomplete report
(%d/%d)\n",
[PATCH] USB: serial: simple: add Motorola Tetra driver for TPG2200
Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI
device
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0cad ProdID=9016 Rev=24.16
S: Manufacturer=Motorola Solutions, Inc.
S: Product=TETRA PEI interface
C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=usb_serial_simple
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=usb_serial_simple
Signed-off-by: Max Schulze
Tested-by: Max Schulze
---
drivers/usb/serial/usb-serial-simple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/usb-serial-simple.c
b/drivers/usb/serial/usb-serial-simple.c
index 4d0273508043..edbbb13d6de6 100644
--- a/drivers/usb/serial/usb-serial-simple.c
+++ b/drivers/usb/serial/usb-serial-simple.c
@@ -85,7 +85,8 @@ DEVICE(moto_modem, MOTO_IDS);
/* Motorola Tetra driver */
#define MOTOROLA_TETRA_IDS() \
{ USB_DEVICE(0x0cad, 0x9011) }, /* Motorola Solutions TETRA PEI */ \
- { USB_DEVICE(0x0cad, 0x9012) } /* MTP6550 */
+ { USB_DEVICE(0x0cad, 0x9012) }, /* MTP6550 */ \
+ { USB_DEVICE(0x0cad, 0x9016) } /* TPG2200 */
DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS);
/* Novatel Wireless GPS driver */
--
2.20.1
Re: mmotm 2018-12-21-15-28 uploaded
On 12/22/2018 04:58 AM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-12-21-15-28 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > > You will need quilt to apply these patches to the latest Linus release (4.x > or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > http://ozlabs.org/~akpm/mmotm/series > > The file broken-out.tar.gz contains two datestamp files: .DATE and > .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, > followed by the base kernel version against which this patch series is to > be applied. > > This tree is partially included in linux-next. To see which patches are > included in linux-next, consult the `series' file. Only the patches > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in > linux-next. > > A git tree which contains the memory management portion of this tree is > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.gi Hello Michal, I dont see the newer tags on this tree. Tried fetching all the tags from the tree but only see these right now for 2018. This release should have an equivalent tag (mmotm-2018-12-21-15-28) right ? mmotm-2018-01-04-16-19 mmotm-2018-01-12-16-53 mmotm-2018-01-18-16-31 mmotm-2018-01-25-16-20 mmotm-2018-01-31-16-51 mmotm-2018-02-06-16-41 mmotm-2018-02-21-14-48 mmotm-2018-03-13-15-15 mmotm-2018-03-14-16-24 mmotm-2018-03-22-16-18 mmotm-2018-03-28-16-05 mmotm-2018-04-05-16-59 mmotm-2018-04-10-17-02 mmotm-2018-04-13-17-28 mmotm-2018-05-03-15-54 mmotm-2018-05-10-16-34 mmotm-2018-05-18-16-44 mmotm-2018-05-25-14-52 - Anshuman
Re: [PATCH 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
On Fri, 2019-01-04 at 10:10 -0600, Rob Herring wrote: > On Thu, Jan 3, 2019 at 9:00 PM Min Guo wrote: > > > > On Thu, 2019-01-03 at 16:14 -0600, Rob Herring wrote: > > > On Thu, Dec 27, 2018 at 03:34:23PM +0800, min@mediatek.com wrote: > > > > From: Min Guo > > > > > > > > This adds support for MediaTek musb controller in > > > > host, peripheral and otg mode > > [...] > > > > > + - interrupts : interrupt used by musb controller > > > > + - interrupt-names : must be "mc" > > > > > > -names is pointless when there is only one. > > The MUSB core driver has two interrupts, one is for MAC, another for DMA, > > but on MTK platform, there is only a MAC interrupt, here following the > > binding > > of MUSB core driver. > > You should probably be listing the same interrupt number twice if 2 > interrupts are combined. If only one interrupt is regisetred in driver, dose still need list the same interrupt number twice in dtsi? > > > > +Optional properties: > > > > + - extcon : external connector for VBUS and IDPIN changes detection, > > > > + needed when supports dual-role mode. > > > > > > Don't use extcon for new bindings. The usb-connector binding should be > > > used instead. > > This is used to detect the changes of the IDPIN and VBUS, the change > > events are provided by other drivers, such as extcon-usb-gpio.c, and > > then switch MUSB controller to host or device mode, but the > > usb-connector can't detect these changes. > > To repeat, do not use extcon binding for new bindings. It is poorly > designed as it reflects extcon driver needs, not a description of the > hardware. If you have ID on GPIO, then that belongs in a usb-connector > node because that GPIO goes to the connector. For Vbus, you should > have a vbus-supply in the connector and use a gpio-regulator if it is > GPIO controlled. Sorry, I didn't find a common driver describing the usb-connector. Is there any driver that I can refer to, specially the way to switch MUSB controller between host and device mode? > > > > + - vbus-supply : reference to the VBUS regulator, needed when supports > > > > + dual-role mode. > > > > > > The controller is powered from Vbus? Probably not. This belongs in the > > > connector or maybe the phy (if the phy is powered from Vbus). > > The Vbus is used to provide 5V voltage to the connected device when the > > controller works as host mode. > > I know what Vbus is. Unless Vbus is providing power to the host > controller, putting the Vbus supply in the controller node is not a > accurate representation of the hardware. I will put vbus-supply in usb-connector after implement it. > Rob
Re: [PATCH] mm: kmemleak: Turn kmemleak_lock to spin lock and RCU primitives
On 1/5/19 2:37 AM, Catalin Marinas wrote:
> On Fri, Jan 04, 2019 at 10:29:13PM +0800, zhe...@windriver.com wrote:
>> It's not necessary to keep consistency between readers and writers of
>> kmemleak_lock. RCU is more proper for this case. And in order to gain better
>> performance, we turn the reader locks to RCU read locks and writer locks to
>> normal spin locks.
> This won't work.
>
>> @@ -515,9 +515,7 @@ static struct kmemleak_object
>> *find_and_get_object(unsigned long ptr, int alias)
>> struct kmemleak_object *object;
>>
>> rcu_read_lock();
>> -read_lock_irqsave(&kmemleak_lock, flags);
>> object = lookup_object(ptr, alias);
>> -read_unlock_irqrestore(&kmemleak_lock, flags);
> The comment on lookup_object() states that the kmemleak_lock must be
> held. That's because we don't have an RCU-like mechanism for removing
> removing objects from the object_tree_root:
>
>>
>> /* check whether the object is still available */
>> if (object && !get_object(object))
>> @@ -537,13 +535,13 @@ static struct kmemleak_object
>> *find_and_remove_object(unsigned long ptr, int ali
>> unsigned long flags;
>> struct kmemleak_object *object;
>>
>> -write_lock_irqsave(&kmemleak_lock, flags);
>> +spin_lock_irqsave(&kmemleak_lock, flags);
>> object = lookup_object(ptr, alias);
>> if (object) {
>> rb_erase(&object->rb_node, &object_tree_root);
>> list_del_rcu(&object->object_list);
>> }
>> -write_unlock_irqrestore(&kmemleak_lock, flags);
>> +spin_unlock_irqrestore(&kmemleak_lock, flags);
> So here, while list removal is RCU-safe, rb_erase() is not.
>
> If you have time to implement an rb_erase_rcu(), than we could reduce
> the locking in kmemleak.
Thanks, I really neglected that rb_erase is not RCU-safe here.
I'm not sure if it is practically possible to implement rb_erase_rcu. Here
is my concern:
In the code paths starting from rb_erase, the tree is tweaked at many
places, in both __rb_erase_augmented and rb_erase_color. To my
understanding, there are many intermediate versions of the tree
during the erasion. In some of the versions, the tree is incomplete, i.e.
some nodes(not the one to be deleted) are invisible to readers. I'm not
sure if this is acceptable as an RCU implementation. Does it mean we
need to form a rb_erase_rcu from scratch?
And are there any other concerns about this attempt?
Let me add RCU supporters Paul and Josh here. Your advice would be
highly appreciated.
Thanks,
Zhe
>
Re: [PATCH] vfio_pci: Add local source directory as include
On 05/01/2019 06:57, Laura Abbott wrote:
> Commit 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2]
> subdriver") introduced a trace.h file in the local directory but
> missed adding the local include path, resulting in compilation
> failures with tracepoints:
>
> In file included from drivers/vfio/pci/trace.h:102,
> from drivers/vfio/pci/vfio_pci_nvlink2.c:29:
> ./include/trace/define_trace.h:89:42: fatal error: ./trace.h: No such file or
> directory
> #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
>
> Fix this by adjusting the include path.
>
> Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2]
> subdriver")
> Signed-off-by: Laura Abbott
Reviewed-by: Alexey Kardashevskiy
> ---
> I'd still like to echo my sentiment that this should not be a def_bool.
> We hit this error on our internal testing and we couldn't even turn
> off the driver until we fixed this.
> ---
> drivers/vfio/pci/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
> index 9662c063a6b1..08d4676a8495 100644
> --- a/drivers/vfio/pci/Makefile
> +++ b/drivers/vfio/pci/Makefile
> @@ -1,3 +1,4 @@
> +ccflags-y += -I$(src)
>
> vfio-pci-y := vfio_pci.o vfio_pci_intrs.o vfio_pci_rdwr.o vfio_pci_config.o
> vfio-pci-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o
>
--
Alexey
Re: compilation failure with CONFIG_VFIO_PCI_NVLINK2
On 07/01/2019 13:58, Alexey Kardashevskiy wrote: > > > On 04/01/2019 02:08, Laura Abbott wrote: >> On 1/3/19 5:49 AM, Alexey Kardashevskiy wrote: >>> >>> >>> On 03/01/2019 03:37, Laura Abbott wrote: Hi, I got a compilation failure when building with CONFIG_VFIO_PCI_NVLINK2 enabled: + make -s 'HOSTCFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--build-id=uuid' ARCH=powerpc -j4 modules BUILDSTDERR: In file included from drivers/vfio/pci/trace.h:102, BUILDSTDERR: from drivers/vfio/pci/vfio_pci_nvlink2.c:29: BUILDSTDERR: ./include/trace/define_trace.h:89:42: fatal error: ./trace.h: No such file or directory BUILDSTDERR: #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) BUILDSTDERR: ^ BUILDSTDERR: compilation terminated. BUILDSTDERR: make[3]: *** [scripts/Makefile.build:277: drivers/vfio/pci/vfio_pci_nvlink2.o] Error 1 BUILDSTDERR: make[2]: *** [scripts/Makefile.build:492: drivers/vfio/pci] Error 2 BUILDSTDERR: make[1]: *** [scripts/Makefile.build:492: drivers/vfio] Error 2 BUILDSTDERR: make: *** [Makefile:1053: drivers] Error 2 BUILDSTDERR: make: *** Waiting for unfinished jobs I don't know enough about ftrace building to make a guess here. Config is attacked. >>> >>> What gcc is this and what is the exact sha1 of the tree? gcc8 prints >>> other error with your config in drivers/scsi/esas2r/esas2r_ioctl.c but >>> not this one so I am curious. >>> >> >> gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) >> >> sha 8e143b90e4d45cca3dc53760d3cfab988bc74571 > > > Your config and this sha1 still make "make oldconfig" ask few questions > and then it compiles just fine, are you sure about the config? > > These are questions on "make oldconfig": > > Kernel Live Patching (LIVEPATCH) [N/y/?] (NEW) > Stack Protector buffer overflow detection (STACKPROTECTOR) [Y/n/?] (NEW) > Strong Stack Protector (STACKPROTECTOR_STRONG) [Y/n/?] (NEW) > Do NOT protect notrace function from kprobe events > (KPROBE_EVENTS_ON_NOTRACE) [N/y/?] (NEW) Ok, I figured it out. This is because you compile in tree while I compile out of tree (with O=builddir) and the difference is that in my case gcc gets these additional -I$(src) statements and in your case you need to add them manually: yours V=1: gcc -Wp,-MD,drivers/vfio/pci/.vfio_pci_nvlink2.o.d -nostdinc -isystem /usr/lib/gcc/powerpc64le-linux-gnu/7/include -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ ... mine V=1 (has -I/home/aik/p/kernel/drivers/vfio/pci and -Idrivers/vfio/pci): /opt/cross/gcc-powerpc64le-linux-8.2.1-nolibc/bin/powerpc64le-linux-gcc -Wp,-MD,drivers/vfio/pci/.vfio_pci_nvlink2.o.d -nostdinc -isystem /opt/cross/gcc-powerpc64le-linux-8.2.1-nolibc/bin/../lib/gcc/powerpc64le-linux/8.2.1/include -I/home/aik/p/kernel/arch/powerpc/include -I./arch/powerpc/include/generated -I/home/aik/p/kernel/include -I./include -I/home/aik/p/kernel/arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I/home/aik/p/kernel/include/uapi -I./include/generated/uapi -include /home/aik/p/kernel/include/linux/kconfig.h -include /home/aik/p/kernel/include/linux/compiler_types.h -I/home/aik/p/kernel/drivers/vfio/pci -Idrivers/vfio/pci -D__KERNEL__ ... This is where it happens: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.lib#n143 I'd rather prefer to fix this in scripts/Makefile.lib#n143 than doing -I$(src) but this is what everybody does already and therefore I guess "[PATCH] vfio_pci: Add local source directory as include" from https://patchwork.kernel.org/patch/10748803/ is correct. > > > Also, would it be possible to switch this option from def_bool to bool? I can't turn it off directly when it's def_bool. >>> >>> Why? Honestly I'd rather fix the compile error. >>> >>> >> >> It's not just about this error, there may be other situations where >> it would be good to have this turned off. > > Oh well I think I misunderstood what "def_bool" actually does (it does > not make much sense without "if" conditions). I'll post a patch. I've had a quick discussion here, and the point is that the distros are going to enable this anyway and it is quite hard t
[PATCH v3] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
While using Elan touchpads, the message floods:
[ 136.138487] i2c_hid i2c-DELL08D6:00: i2c_hid_get_input: incomplete report
(14/65535)
Though the message flood is annoying, the device it self works without
any issue. I suspect that the device in question takes too much time to
pull the IRQ back to high after I2C host has done reading its data.
Since the host receives all useful data, let's ignore the input report
when there's no data.
Signed-off-by: Kai-Heng Feng
---
v3:
Fix compiler error/warnings.
v2:
Use dev_warn_once() to warn the user about the situation.
drivers/hid/i2c-hid/i2c-hid-core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 8555ce7e737b..2f940c1de616 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -50,6 +50,7 @@
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
#define I2C_HID_QUIRK_NO_RUNTIME_PMBIT(2)
#define I2C_HID_QUIRK_DELAY_AFTER_SLEEPBIT(3)
+#define I2C_HID_QUIRK_BOGUS_IRQBIT(4)
/* flags */
#define I2C_HID_STARTED0
@@ -179,6 +180,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
{ USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
I2C_HID_QUIRK_NO_RUNTIME_PM },
+ { USB_VENDOR_ID_ELAN, HID_ANY_ID,
+I2C_HID_QUIRK_BOGUS_IRQ },
{ 0, 0 }
};
@@ -503,6 +506,12 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
return;
}
+ if (ihid->quirks & I2C_HID_QUIRK_BOGUS_IRQ && ret_size == 0x) {
+ dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but "
+ "there's no data\n", __func__);
+ return;
+ }
+
if ((ret_size > size) || (ret_size < 2)) {
dev_err(&ihid->client->dev, "%s: incomplete report (%d/%d)\n",
__func__, size, ret_size);
--
2.17.1
Re: [PATCH v1] cpufreq: qcom: Read voltage LUT and populate OPP
On 12/27/2018 1:02 AM, Matthias Kaehlcke wrote:
Hi Taniya,
On Mon, Dec 24, 2018 at 12:29:18AM +0530, Taniya Das wrote:
Hello Matthias,
Thanks for your review comments.
On 12/22/2018 2:27 AM, Matthias Kaehlcke wrote:
Hi Taniya,
On Fri, Dec 21, 2018 at 11:36:48PM +0530, Taniya Das wrote:
Add support to read the voltage look up table and populate OPP for all
corresponding CPUS.
Signed-off-by: Taniya Das
---
drivers/cpufreq/qcom-cpufreq-hw.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d83939a..7559b87 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -10,18 +10,21 @@
#include
#include
#include
+#include
#include
#define LUT_MAX_ENTRIES 40U
#define LUT_SRC GENMASK(31, 30)
#define LUT_L_VALGENMASK(7, 0)
#define LUT_CORE_COUNT GENMASK(18, 16)
+#define LUT_VOLT GENMASK(11, 0)
#define LUT_ROW_SIZE 32
#define CLK_HW_DIV 2
/* Register offsets */
#define REG_ENABLE 0x0
-#define REG_LUT_TABLE 0x110
+#define REG_FREQ_LUT_TABLE 0x110
+#define REG_VOLT_LUT_TABLE 0x114
The new names suggest that there is a LUT for frequencies and another
one for voltages. I don't have access to hardware documentation, but
from the code and offsets in this driver it seems there is a single
table at offset 0x110, with a 'row' of 32 bytes per OPP. Within this
row the frequency (and other values) is located at offset 0, the
voltage at offset 4.
I'd suggest to keep REG_LUT_TABLE, add a define LUT_OFFSET_VOLTAGE/MV
(or similar) and adjust the math in qcom_cpufreq_hw_read_lut() to use
> > REG_LUT_TABLE as base offset.
These names are as per HW documentation and the math is kept as per the
documentation for reading the voltage.
The HW documentation is confusing then and I'm not convinced this
should be carried over 1:1 to the driver. In any case this
documentation is only available to a reduced audience, why make it
harder for everyone else?
I think something like this would be preferable (removed _TABLE suffix,
since that's already part of LUT):
#define OFFSET_LUT 0x110
#define REG_FREQ_LUT0x00
#define REG_VOLT_LUT0x04
Sorry :( ,This is not the correct interpretation as per the
Documentation. I would leave it as it is. Though I could update the
macro names.
freq = read(OFFSET_LUT + (LUT_ROW_SIZE * i) + REG_FREQ_LUT);
volt = read(OFFSET_LUT + (LUT_ROW_SIZE * i) + REG_VOLT_LUT);
or probably better:
row_addr = OFFSET_LUT + (LUT_ROW_SIZE * i);
freq = read(row_addr + REG_FREQ_LUT);
volt = read(row_addr + REG_VOLT_LUT);
#define REG_PERF_STATE 0x920
static unsigned long cpu_hw_rate, xo_rate;
@@ -75,19 +78,26 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
void __iomem *base)
{
u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, freq;
+ u32 volt;
unsigned int max_cores = cpumask_weight(policy->cpus);
struct cpufreq_frequency_table *table;
+ unsigned long cpu_r;
nit: why 'cpu_r' and not just 'cpu'?
(if it is needed at all, see my comment below)
Sure, will update it to 'cpu'.
table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
if (!table)
return -ENOMEM;
for (i = 0; i < LUT_MAX_ENTRIES; i++) {
- data = readl_relaxed(base + REG_LUT_TABLE + i * LUT_ROW_SIZE);
+ data = readl_relaxed(base + REG_FREQ_LUT_TABLE +
+ i * LUT_ROW_SIZE);
src = FIELD_GET(LUT_SRC, data);
lval = FIELD_GET(LUT_L_VAL, data);
core_count = FIELD_GET(LUT_CORE_COUNT, data);
+ data = readl_relaxed(base + REG_VOLT_LUT_TABLE +
+ i * LUT_ROW_SIZE);
+ volt = FIELD_GET(LUT_VOLT, data) * 1000;
+
if (src)
freq = xo_rate * lval / 1000;
else
@@ -123,6 +133,10 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
prev_cc = core_count;
prev_freq = freq;
+
+ freq *= 1000;
+ for_each_cpu(cpu_r, policy->cpus)
+ dev_pm_opp_add(get_cpu_device(cpu_r), freq, volt);
Are you sure we want to duplicate the OPP entries for all CPUs in the
cluster? IIUC the frequencies of the cores in a cluster can't be
changed individually, hence the cores should have a shared table. I
think dev_pm_opp_get_sharing_cpus() does what you need.
You currently also add OPPs for invalid frequencies. From my SDM845
device:
cat /sys/dev
Re: [RFC PATCH V3 0/5] Hi:
On Sun, Jan 6, 2019 at 8:17 PM Michael S. Tsirkin wrote: > > On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote: > > > > On 2019/1/7 上午11:28, Michael S. Tsirkin wrote: > > > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: > > > > On 2019/1/3 上午4:47, Michael S. Tsirkin wrote: > > > > > On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: > > > > > > This series tries to access virtqueue metadata through kernel > > > > > > virtual > > > > > > address instead of copy_user() friends since they had too much > > > > > > overheads like checks, spec barriers or even hardware feature > > > > > > toggling. > > > > > Will review, thanks! > > > > > One questions that comes to mind is whether it's all about bypassing > > > > > stac/clac. Could you please include a performance comparison with > > > > > nosmap? > > > > > > > > > On machine without SMAP (Sandy Bridge): > > > > > > > > Before: 4.8Mpps > > > > > > > > After: 5.2Mpps > > > OK so would you say it's really unsafe versus safe accesses? > > > Or would you say it's just a better written code? > > > > > > It's the effect of removing speculation barrier. > > > You mean __uaccess_begin_nospec introduced by > commit 304ec1b050310548db33063e567123fae8fd0301 > ? > > So fundamentally we do access_ok checks when supplying > the memory table to the kernel thread, and we should > do the spec barrier there. > > Then we can just create and use a variant of uaccess macros that does > not include the barrier? > > Or, how about moving the barrier into access_ok? > This way repeated accesses with a single access_ok get a bit faster. > CC Dan Williams on this idea. It would be interesting to see how expensive re-doing the address limit check is compared to the speculation barrier. I.e. just switch vhost_get_user() to use get_user() rather than __get_user(). That will sanitize the pointer in the speculative path without a barrier. I recall we had a convert access_ok() discussion with this result here: https://lkml.org/lkml/2018/1/17/929 ...but it sounds like you are proposing a smaller scope fixup for the vhost use case? Something like barrier_nospec() in the success path for all vhost access_ok() checks and then a get_user() variant that disables the barrier.
Re: [PATCH v2 1/5] spmi: pmic-arb: hardcode IRQ counts
Hi Brian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on pinctrl/devel]
[also build test WARNING on v5.0-rc1 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Brian-Masney/qcom-spmi-add-support-for-hierarchical-IRQ-chip/20190107-110503
base:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All warnings (new ones prefixed by >>):
drivers/pinctrl//qcom/pinctrl-spmi-gpio.c: In function 'pmic_gpio_probe':
>> drivers/pinctrl//qcom/pinctrl-spmi-gpio.c:974:10: warning: cast from pointer
>> to integer of different size [-Wpointer-to-int-cast]
npins = (int) of_id->data;
^
vim +974 drivers/pinctrl//qcom/pinctrl-spmi-gpio.c
952
953 static int pmic_gpio_probe(struct platform_device *pdev)
954 {
955 const struct of_device_id *of_id;
956 struct device *dev = &pdev->dev;
957 struct pinctrl_pin_desc *pindesc;
958 struct pinctrl_desc *pctrldesc;
959 struct pmic_gpio_pad *pad, *pads;
960 struct pmic_gpio_state *state;
961 int ret, npins, i;
962 u32 reg;
963
964 ret = of_property_read_u32(dev->of_node, "reg", ®);
965 if (ret < 0) {
966 dev_err(dev, "missing base address");
967 return ret;
968 }
969
970 of_id = of_match_device(pmic_gpio_of_match, &pdev->dev);
971 if (!of_id)
972 return -EINVAL;
973
> 974 npins = (int) of_id->data;
975
976 state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
977 if (!state)
978 return -ENOMEM;
979
980 platform_set_drvdata(pdev, state);
981
982 state->dev = &pdev->dev;
983 state->map = dev_get_regmap(dev->parent, NULL);
984
985 pindesc = devm_kcalloc(dev, npins, sizeof(*pindesc),
GFP_KERNEL);
986 if (!pindesc)
987 return -ENOMEM;
988
989 pads = devm_kcalloc(dev, npins, sizeof(*pads), GFP_KERNEL);
990 if (!pads)
991 return -ENOMEM;
992
993 pctrldesc = devm_kzalloc(dev, sizeof(*pctrldesc), GFP_KERNEL);
994 if (!pctrldesc)
995 return -ENOMEM;
996
997 pctrldesc->pctlops = &pmic_gpio_pinctrl_ops;
998 pctrldesc->pmxops = &pmic_gpio_pinmux_ops;
999 pctrldesc->confops = &pmic_gpio_pinconf_ops;
1000 pctrldesc->owner = THIS_MODULE;
1001 pctrldesc->name = dev_name(dev);
1002 pctrldesc->pins = pindesc;
1003 pctrldesc->npins = npins;
1004 pctrldesc->num_custom_params = ARRAY_SIZE(pmic_gpio_bindings);
1005 pctrldesc->custom_params = pmic_gpio_bindings;
1006 #ifdef CONFIG_DEBUG_FS
1007 pctrldesc->custom_conf_items = pmic_conf_items;
1008 #endif
1009
1010 for (i = 0; i < npins; i++, pindesc++) {
1011 pad = &pads[i];
1012 pindesc->drv_data = pad;
1013 pindesc->number = i;
1014 pindesc->name = pmic_gpio_groups[i];
1015
1016 pad->irq = platform_get_irq(pdev, i);
1017 if (pad->irq < 0)
1018 return pad->irq;
1019
1020 pad->base = reg + i * PMIC_GPIO_ADDRESS_RANGE;
1021
1022 ret = pmic_gpio_populate(state, pad);
1023 if (ret < 0)
1024 return ret;
1025 }
1026
1027 state->chip = pmic_gpio_gpio_template;
1028 state->chip.parent = dev;
1029 state->chip.base = -1;
1030 state->chip.ngpio = npins;
1031 state->chip.label = dev_name(dev);
1032 state->chip.of_gpio_n_cells = 2;
1033 state->chip.can_sleep = false;
1034
1035 state->ctrl = devm_pinctrl_register(dev, pctrldesc, state);
1036 if (IS_ERR(state->ctrl))
1037 return PTR_ERR(state->ctrl);
1038
1039 ret = gpiochip_add_data(&state->chip, state);
1040 if (ret) {
1041 dev_err(state->dev, "can't add gpio chip\n");
1042 return ret;
1043 }
1044
1045 /*
1046 * For DeviceTree-supported systems, the gpio core checks the
1
Re: [PATCH 2/2] remoteproc: q6v5_adsp: Remove voting for lpass_aon clock
On Thu 03 Jan 20:36 PST 2019, Rohit Kumar wrote:
> Hello Bjorn,
>
> Can you please review this patch series too.
>
> LPASS_AON clock support is already removed from lpass clock driver.
>
Applied the two patches.
Thanks,
Bjorn
>
> Thanks,
>
> Rohit
>
> On 11/30/2018 12:59 PM, Rohit kumar wrote:
> > Lpass_aon clock is on by default. Remove it from lpass
> > clock list to avoid voting for it.
> >
> > Signed-off-by: Rohit kumar
> > ---
> > drivers/remoteproc/qcom_q6v5_adsp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
> > b/drivers/remoteproc/qcom_q6v5_adsp.c
> > index 79374d1..4829173 100644
> > --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> > +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> > @@ -48,7 +48,7 @@
> > /* list of clocks required by ADSP PIL */
> > static const char * const adsp_clk_id[] = {
> > - "sway_cbcr", "lpass_aon", "lpass_ahbs_aon_cbcr", "lpass_ahbm_aon_cbcr",
> > + "sway_cbcr", "lpass_ahbs_aon_cbcr", "lpass_ahbm_aon_cbcr",
> > "qdsp6ss_xo", "qdsp6ss_sleep", "qdsp6ss_core",
> > };
>
> --
> Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
> of the Code Aurora Forum, hosted by the Linux Foundation.
>
Re: [RFC,5/5] mfd: cros_ec: add EC host command support using rpmsg.
On Fri, Jan 4, 2019 at 7:39 PM Enric Balletbo Serra wrote:
>
> Hi Peter,
>
> Missatge de Peter Shih del dia dv., 4 de gen.
> 2019 a les 8:58:
> >
> > Thanks for the review.
> > I would leave some formatting comment to v2, and reply others first.
> >
> > On Fri, Jan 4, 2019 at 12:05 AM Enric Balletbo Serra
> > wrote:
> > >
> > > Hi,
> > >
> > > Many thanks for sending this. Please, add Guenter and me for next
> > > versions, we are interested in it, thanks :)
> > >
> > > Missatge de Pi-Hsun Shih del dia dc., 26 de des.
> > > 2018 a les 8:57:
> > > >
> > > > Add EC host command support through rpmsg.
> > > >
> > > > Signed-off-by: Pi-Hsun Shih
> > > > ---
> > > > drivers/mfd/cros_ec_dev.c | 9 ++
> > > > drivers/platform/chrome/Kconfig | 8 ++
> > > > drivers/platform/chrome/Makefile| 1 +
> > > > drivers/platform/chrome/cros_ec_rpmsg.c | 164
> > > > include/linux/mfd/cros_ec.h | 1 +
> > > > include/linux/mfd/cros_ec_commands.h| 2 +
> > > > 6 files changed, 185 insertions(+)
> > > > create mode 100644 drivers/platform/chrome/cros_ec_rpmsg.c
> > > >
> > > > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> > > > index 2d0fee488c5aa8..67983853413d07 100644
> > > > --- a/drivers/mfd/cros_ec_dev.c
> > > > +++ b/drivers/mfd/cros_ec_dev.c
> > > > @@ -414,6 +414,15 @@ static int ec_device_probe(struct platform_device
> > > > *pdev)
> > > > device_initialize(&ec->class_dev);
> > > > cdev_init(&ec->cdev, &fops);
> > > >
> > > > + if (cros_ec_check_features(ec, EC_FEATURE_SCP)) {
> > > > + dev_info(dev, "SCP detected.\n");
> > > > + /*
> > > > +* Help userspace differentiating ECs from SCP,
> > > > +* regardless of the probing order.
> > > > +*/
> > > > + ec_platform->ec_name = CROS_EC_DEV_SCP_NAME;
> > > > + }
> > > > +
> > >
> > > Why userspace should know that this is an SCP? From the userspace
> > > point of view shouldn't be this transparent, we don't do distinctions
> > > when the transport layer is i2c, spi or lpc, and I think that the
> > > cros_ec_rpmsg driver is a cros-ec transport layer, like these. So, I
> > > think that this is not needed.
> > >
> >
> > Since both the EC and the SCP talk in EC host command format here, and they
> > can
> > both exist on the same system, if we don't do the distinction, both of them
> > would be registered as /dev/cros_ec, and cause an error.
> >
>
> Interesting, so this system will have two cros-ec, one connected via
> spi or i2c to the soc and another one using the M4 within the M8183?
>
> Actually, on some systems, we have chained EC's (ie cros_ec and
> cros_pd). The way we actually handle the name to access the different
> ECs is create a mfd cell with their specific platform data, I am
> wondering if we can do the same here (see drivers/mfd/cros_ec.c)
>
Yes there's two cros-ec as described (one throught spi / i2c to a EC, one
through rpmsg to the M4 within M8183).
I think that what transport layer used (rpmsg / spi / i2c) is independent to
what the cros-ec actually is (a normal EC, or a SCP), so we probably still need
some feature detection to check what the cros-ec is. It seems to be hard to do
that on cros_ec_register in drivers/mfd/cros_ec.c using different mfd cell,
since it knows nothing about the EC features.
Or should I just don't do feature detection, but write the information in the
device tree instead? (Via some "dev-name" property probably?)
> > This change is actually independent to the rpmsg change (EC through all
> > transport layer can report that they have feature EC_FEATURE_SCP, and would
> > then be seen from userspace as /dev/cros_scp), I'll move this to another
> > patch
> > in v2.
> >
> > > > /*
> > > > * Add the class device
> > > > * Link to the character device for creating the /dev entry
> > > > diff --git a/drivers/platform/chrome/Kconfig
> > > > b/drivers/platform/chrome/Kconfig
> > > > index 16b1615958aa2d..b03d68eb732177 100644
> > > > --- a/drivers/platform/chrome/Kconfig
> > > > +++ b/drivers/platform/chrome/Kconfig
> > > > @@ -72,6 +72,14 @@ config CROS_EC_SPI
> > > > response time cannot be guaranteed, we support ignoring
> > > > 'pre-amble' bytes before the response actually starts.
> > > >
> > > > +config CROS_EC_RPMSG
> > > > + tristate "ChromeOS Embedded Controller (rpmsg)"
> > > > + depends on MFD_CROS_EC && RPMSG
> > >
> > > I think that this driver is DT-only, && OF ?
> >
> > Would add this in v2.
> >
> > >
> > > > + help
> > > > + If you say Y here, you get support for talking to the
> > > > ChromeOS EC
> > > > + through rpmsg. This uses a simple byte-level protocol with a
> > > > + checksum.
> > > > +
> > > > config CROS_EC_LPC
> > > > tristate "ChromeOS Embedded Controller (LPC)"
> > > > d
Re: r8152: data corruption in various scenarios
On 2019-01-07 1:46 a.m., Kai Heng Feng wrote: > > Do you happen to use a Dell system? We can do some test here. Yes. It is a Dell XPS 13 9360 i7-8550U notebook, with the Dell WD15 USB-C dock. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com
Re: [PATCH v7 21/22] ptrace: add PTRACE_GET_SYSCALL_INFO request
Hi Elvira,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc1]
[cannot apply to next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dmitry-V-Levin/asm-generic-syscall-h-prepare-for-inclusion-by-other-files/20190107-115241
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=alpha
All errors (new ones prefixed by >>):
kernel/ptrace.c: In function 'ptrace_get_syscall_info':
>> kernel/ptrace.c:944:20: error: implicit declaration of function
>> 'user_stack_pointer'; did you mean 'xa_tag_pointer'?
>> [-Werror=implicit-function-declaration]
.stack_pointer = user_stack_pointer(regs),
^~
xa_tag_pointer
In file included from arch/alpha/include/asm/syscall.h:6:0,
from include/linux/audit.h:214,
from kernel/ptrace.c:24:
kernel/ptrace.c: At top level:
include/asm-generic/syscall.h:61:1: warning: 'syscall_rollback' declared
'static' but never defined [-Wunused-function]
syscall_rollback(struct task_struct *task, struct pt_regs *regs);
^~~~
include/asm-generic/syscall.h:106:1: warning: 'syscall_set_return_value'
declared 'static' but never defined [-Wunused-function]
syscall_set_return_value(struct task_struct *task, struct pt_regs *regs,
^~~~
include/asm-generic/syscall.h:174:1: warning: '__syscall_set_arguments' used
but never defined
__syscall_set_arguments(struct task_struct *task, struct pt_regs *regs,
^~~
cc1: some warnings being treated as errors
vim +944 kernel/ptrace.c
934
935 static int
936 ptrace_get_syscall_info(struct task_struct *child, unsigned long
user_size,
937 void __user *datavp)
938 {
939 struct pt_regs *regs = task_pt_regs(child);
940 struct ptrace_syscall_info info = {
941 .op = PTRACE_SYSCALL_INFO_NONE,
942 .arch = syscall_get_arch(child),
943 .instruction_pointer = instruction_pointer(regs),
> 944 .stack_pointer = user_stack_pointer(regs),
945 };
946 unsigned long actual_size = offsetof(struct
ptrace_syscall_info, entry);
947 unsigned long write_size;
948
949 /*
950 * This does not need lock_task_sighand() to access
951 * child->last_siginfo because ptrace_freeze_traced()
952 * called earlier by ptrace_check_attach() ensures that
953 * the tracee cannot go away and clear its last_siginfo.
954 */
955 switch (child->last_siginfo ? child->last_siginfo->si_code : 0)
{
956 case SIGTRAP | 0x80:
957 switch (child->ptrace_message) {
958 case PTRACE_EVENTMSG_SYSCALL_ENTRY:
959 actual_size =
ptrace_get_syscall_info_entry(child, regs,
960
&info);
961 break;
962 case PTRACE_EVENTMSG_SYSCALL_EXIT:
963 actual_size =
ptrace_get_syscall_info_exit(child, regs,
964
&info);
965 break;
966 }
967 break;
968 case SIGTRAP | (PTRACE_EVENT_SECCOMP << 8):
969 actual_size = ptrace_get_syscall_info_seccomp(child,
regs,
970&info);
971 break;
972 }
973
974 write_size = min(actual_size, user_size);
975 return copy_to_user(datavp, &info, write_size) ? -EFAULT :
actual_size;
976 }
977
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC PATCH V3 1/5] vhost: generalize adding used elem
On 2019/1/5 上午8:33, Sean Christopherson wrote: On Fri, Jan 04, 2019 at 04:29:34PM -0500, Michael S. Tsirkin wrote: On Sat, Dec 29, 2018 at 08:46:52PM +0800, Jason Wang wrote: Use one generic vhost_copy_to_user() instead of two dedicated accessor. This will simplify the conversion to fine grain accessors. About 2% improvement of PPS were seen during vitio-user txonly test. Signed-off-by: Jason Wang I don't hve a problem with this patch but do you have any idea how come removing what's supposed to be an optimization speeds things up? With SMAP, the 2x vhost_put_user() will also mean an extra STAC/CLAC pair, which is probably slower than the overhead of CALL+RET to whatever flavor of copy_user_generic() gets used. CALL+RET is really the only overhead since all variants of copy_user_generic() unroll accesses smaller than 64 bytes, e.g. on a 64-bit system, __copy_to_user() will write all 8 bytes in a single MOV. Removing the special casing also eliminates a few hundred bytes of code as well as the need for hardware to predict count==1 vs. count>1. Yes, I don't measure, but STAC/CALC is pretty expensive when we are do very small copies based on the result of nosmap PPS. Thanks
[PATCH] cpufreq: Don't update new_policy on failures
The local variable "new_policy" isn't getting used in the error path
since the commit f9f41e3ef99a ("cpufreq: Remove policy create/remove
notifiers"). Don't update it in error path.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 7aa3dcad2175..9a5f82ef40e8 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1305,8 +1305,6 @@ static int cpufreq_online(unsigned int cpu)
if (ret) {
pr_err("%s: Failed to initialize policy for cpu: %d (%d)\n",
__func__, cpu, ret);
- /* cpufreq_policy_free() will notify based on this */
- new_policy = false;
goto out_destroy_policy;
}
--
2.19.1.568.g152ad8e3369a
Re: [RFC PATCH V3 0/5] Hi:
On 2019/1/5 上午5:41, Michael S. Tsirkin wrote: On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: This series tries to access virtqueue metadata through kernel virtual address instead of copy_user() friends since they had too much overheads like checks, spec barriers or even hardware feature toggling. I think it's a reasonable approach. However I need to look at whether and which mmu notifiers are invoked before writeback. Do you know? I don't know but just looking at the MMU notifier ops definition, there's no such callback if my understanding is correct. Thanks Test shows about 24% improvement on TX PPS. It should benefit other cases as well. Changes from V2: - fix buggy range overlapping check - tear down MMU notifier during vhost ioctl to make sure invalidation request can read metadata userspace address and vq size without holding vq mutex. Changes from V1: - instead of pinning pages, use MMU notifier to invalidate vmaps and remap duing metadata prefetch - fix build warning on MIPS Jason Wang (5): vhost: generalize adding used elem vhost: fine grain userspace memory accessors vhost: rename vq_iotlb_prefetch() to vq_meta_prefetch() vhost: introduce helpers to get the size of metadata area vhost: access vq metadata through kernel virtual address drivers/vhost/net.c | 4 +- drivers/vhost/vhost.c | 416 +- drivers/vhost/vhost.h | 15 +- 3 files changed, 384 insertions(+), 51 deletions(-) -- 2.17.1
Re: linux-next: manual merge of the csky tree with Linus' tree
On Mon, Jan 07, 2019 at 10:27:27AM +1100, Stephen Rothwell wrote: > You want to add "select ARCH_NO_SG_CHAIN" to your Kconfig somewhere > (see the commit from Linus' tree above). No, csky should not select it. There is no code directly poking into scatterlists internals in csky, so it can safely enable chained sglists.
Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency
On 2019/1/7 下午12:23, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
It's not uncommon to have two access two unrelated memory locations in a
specific order. At the moment one has to use a memory barrier for this.
However, if the first access was a read and the second used an address
depending on the first one we would have a data dependency and no
barrier would be necessary.
This adds a new interface: dependent_ptr_mb which does exactly this: it
returns a pointer with a data dependency on the supplied value.
Signed-off-by: Michael S. Tsirkin
---
Documentation/memory-barriers.txt | 20
arch/alpha/include/asm/barrier.h | 1 +
include/asm-generic/barrier.h | 18 ++
include/linux/compiler.h | 4
4 files changed, 43 insertions(+)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index c1d913944ad8..9dbaa2e1dbf6 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -691,6 +691,18 @@ case what's actually required is:
p = READ_ONCE(b);
}
+Alternatively, a control dependency can be converted to a data dependency,
+e.g.:
+
+ q = READ_ONCE(a);
+ if (q) {
+ b = dependent_ptr_mb(b, q);
+ p = READ_ONCE(b);
+ }
+
+Note how the result of dependent_ptr_mb must be used with the following
+accesses in order to have an effect.
+
However, stores are not speculated. This means that ordering -is- provided
for load-store control dependencies, as in the following example:
@@ -836,6 +848,12 @@ out-guess your code. More generally, although READ_ONCE()
does force
the compiler to actually emit code for a given load, it does not force
the compiler to use the results.
+Converting to a data dependency helps with this too:
+
+ q = READ_ONCE(a);
+ b = dependent_ptr_mb(b, q);
+ WRITE_ONCE(b, 1);
+
In addition, control dependencies apply only to the then-clause and
else-clause of the if-statement in question. In particular, it does
not necessarily apply to code following the if-statement:
@@ -875,6 +893,8 @@ to the CPU containing it. See the section on "Multicopy
atomicity"
for more information.
+
+
In summary:
(*) Control dependencies can order prior loads against later stores.
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index 92ec486a4f9e..b4934e8c551b 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -59,6 +59,7 @@
* as Alpha, "y" could be set to 3 and "x" to 0. Use rmb()
* in cases like this where there are no data dependencies.
*/
+#define ARCH_NEEDS_READ_BARRIER_DEPENDS 1
#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
#ifdef CONFIG_SMP
diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 2cafdbb9ae4c..fa2e2ef72b68 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -70,6 +70,24 @@
#define __smp_read_barrier_depends() read_barrier_depends()
#endif
+#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \
+ !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS)
+
+#define dependent_ptr_mb(ptr, val) ({ \
+ long dependent_ptr_mb_val = (long)(val);\
+ long dependent_ptr_mb_ptr = (long)(ptr) - dependent_ptr_mb_val; \
+ \
+ BUILD_BUG_ON(sizeof(val) > sizeof(long));\
+ OPTIMIZER_HIDE_VAR(dependent_ptr_mb_val); \
+ (typeof(ptr))(dependent_ptr_mb_ptr + dependent_ptr_mb_val); \
+})
+
+#else
+
+#define dependent_ptr_mb(ptr, val) ({ mb(); (ptr); })
So for the example of patch 4, we'd better fall back to rmb() or need a
dependent_ptr_rmb()?
Thanks
You mean for strongly ordered architectures like Intel?
Yes, maybe it makes sense to have dependent_ptr_smp_rmb,
dependent_ptr_dma_rmb and dependent_ptr_virt_rmb.
mb variant is unused right now so I'll remove it.
Yes.
Thanks
Re: [RFC PATCH V3 0/5] Hi:
On 2019/1/7 下午12:17, Michael S. Tsirkin wrote: On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote: On 2019/1/7 上午11:28, Michael S. Tsirkin wrote: On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: On 2019/1/3 上午4:47, Michael S. Tsirkin wrote: On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: This series tries to access virtqueue metadata through kernel virtual address instead of copy_user() friends since they had too much overheads like checks, spec barriers or even hardware feature toggling. Will review, thanks! One questions that comes to mind is whether it's all about bypassing stac/clac. Could you please include a performance comparison with nosmap? On machine without SMAP (Sandy Bridge): Before: 4.8Mpps After: 5.2Mpps OK so would you say it's really unsafe versus safe accesses? Or would you say it's just a better written code? It's the effect of removing speculation barrier. You mean __uaccess_begin_nospec introduced by commit 304ec1b050310548db33063e567123fae8fd0301 ? Yes. So fundamentally we do access_ok checks when supplying the memory table to the kernel thread, and we should do the spec barrier there. Then we can just create and use a variant of uaccess macros that does not include the barrier? The unsafe ones? Or, how about moving the barrier into access_ok? This way repeated accesses with a single access_ok get a bit faster. CC Dan Williams on this idea. The problem is, e.g for vhost control path. During mem table validation, we don't even want to access them there. So the spec barrier is not needed. On machine with SMAP (Broadwell): Before: 5.0Mpps After: 6.1Mpps No smap: 7.5Mpps Thanks no smap being before or after? Let me clarify: Before (SMAP on): 5.0Mpps Before (SMAP off): 7.5Mpps After (SMAP on): 6.1Mpps Thanks How about after + smap off? After (SMAP off): 8.0Mpps And maybe we want a module option just for the vhost thread to keep smap off generally since almost all it does is copy stuff from userspace into kernel anyway. Because what above numbers should is that we really really want a solution that isn't limited to just meta-data access, and I really do not see how any such solution can not also be used to make meta-data access fast. As we've discussed in another thread of previous version. This requires lots of changes, the main issues is SMAP state was not saved/restored on explicit schedule(). Even if it did, since vhost will call lots of net/block codes, any kind of uaccess in those codes needs understand this special request from vhost e.g you provably need to invent a new kinds of iov iterator that does not touch SMAP at all. And I'm not sure this is the only thing we need to deal with. So I still prefer to: 1) speedup the metadata access through vmap + MMU notifier 2) speedup the datacopy with batched copy (unsafe ones or other new interfaces) Thanks
Re: r8152: data corruption in various scenarios
> On Jan 7, 2019, at 12:13, Mark Lord wrote:
>
> On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>>
>>
>>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>>
>>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
PM, Mark Lord
wrote:
..
>> There is even now a special hack in the upstream r8152.c to attempt to
>> detect
>> a Dell TB16 dock and disable RX Aggregation in the driver to prevent
>> such issues.
>>
>> Well.. I have a WD15 dock, not a TB16, and that same hack also catches
>> my dock
>> in its net:
>>
>> [5.794641] usb 4-1.2: Dell TB16 Dock, disable RX aggregation
>
> The serial should be unique according to Dell.
>
>> So one issue is that the code is not correctly identifying the dock,
>> and the WD15 is claimed to be immune from the r8152 issues.
>
> The WD15 I tested didn't use that serial number though...
What info do you need from me about the WD15 so this can be corrected?
>> xhci_hcd :39:00.0: ERROR Transfer event TRB DMA ptr not part of
>> current TD ep_index 13
>> comp_code 1
>
> This is probably an xHC bug. A similar issue is fixed by commit
> 9da5a1092b13
> ("xhci: Bad Ethernet performance plugged in ASM1042A host”).
>
>> I just got that exact message above, with the r8152 in my 1-day old WD15
>> dock,
>> with the TB16 "workaround" enabled in Linux kernel 4.20.0.
>
> Is the xHC WD15 connected an ASMedia one?
I don't know. I *think* it identifies as a DSL6340 (see below).
Here is lspci and lsusb:
$ lspci -vt
-[:00]-+-00.0 Intel Corporation Xeon E3-1200 v6/7th Gen Core
Processor Host Bridge/DRAM Registers
+-02.0 Intel Corporation UHD Graphics 620
+-04.0 Intel Corporation Skylake Processor Thermal Subsystem
+-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller
+-14.2 Intel Corporation Sunrise Point-LP Thermal subsystem
+-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C
Controller #0
+-15.1 Intel Corporation Sunrise Point-LP Serial IO I2C
Controller #1
+-16.0 Intel Corporation Sunrise Point-LP CSME HECI #1
+-1c.0-[01-39]00.0-[02-39]--+-00.0-[03]--
| +-01.0-[04-38]--
| \-02.0-[39]00.0 Intel
Corporation DSL6340 USB 3.1
Controller [Alpine Ridge]
+-1c.4-[3a]00.0 Qualcomm Atheros QCA6174 802.11ac Wireless
Network Adapter
+-1d.0-[3b]00.0 Samsung Electronics Co Ltd Device a808
+-1f.0 Intel Corporation Device 9d4e
+-1f.2 Intel Corporation Sunrise Point-LP PMC
+-1f.3 Intel Corporation Sunrise Point-LP HD Audio
\-1f.4 Intel Corporation Sunrise Point-LP SMBus
>>>
>>>
>>> Mmm.. lspci -vt isn't as verbose as I thought, so here is plain lspci to
>>> fill in the blanks:
>>>
>>> $ lspci
>>> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core
>>> Processor Host Bridge/DRAM
>>> Registers (rev 08)
>>> 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev
>>> 07)
>>>
>>> 00:04.0 Signal processing controller: Intel Corporation Skylake Processor
>>> Thermal Subsystem (rev 08)
>>>
>>> 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
>>> Controller (rev 21)
>>>
>>> 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP
>>> Thermal subsystem (rev 21)
>>>
>>> 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP
>>> Serial IO I2C Controller #0
>>> (rev 21)
>>> 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP
>>> Serial IO I2C Controller #1
>>> (rev 21)
>>> 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME
>>> HECI #1 (rev 21)
>>>
>>> 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
>>> Port (rev f1)
>>>
>>> 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
>>> Port #5 (rev f1)
>>>
>>> 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
>>> Port #9 (rev f1)
>>>
>>> 00:1f.0 ISA bridge: Intel Corporation Device 9d4e (rev 21)
>>>
>>> 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
>>>
>>> 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
>>>
>>> 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
>>>
>>> 01:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
>>> Ridge 2C 2015]
>>>
>>> 02:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
>>> Ridge 2C 2015]
>>>
>>> 02:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpin
[PATCH 12/15] PCI: cadence: Remove pci_epf_linkup from Cadence EP driver
pci_epf_linkup is intended to be invoked if the EPC supports linkup notification. Now that pci-epf-test uses get_features callback, which indicates Cadence EP driver doesn't support linkup notification, remove pci_epf_linkup from Cadence EP driver. Signed-off-by: Kishon Vijay Abraham I --- drivers/pci/controller/pcie-cadence-ep.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/pci/controller/pcie-cadence-ep.c b/drivers/pci/controller/pcie-cadence-ep.c index 14c2545bb17e..def7820cb824 100644 --- a/drivers/pci/controller/pcie-cadence-ep.c +++ b/drivers/pci/controller/pcie-cadence-ep.c @@ -396,18 +396,6 @@ static int cdns_pcie_ep_start(struct pci_epc *epc) cfg |= BIT(epf->func_no); cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, cfg); - /* -* The PCIe links are automatically established by the controller -* once for all at powerup: the software can neither start nor stop -* those links later at runtime. -* -* Then we only have to notify the EP core that our links are already -* established. However we don't call directly pci_epc_linkup() because -* we've already locked the epc->lock. -*/ - list_for_each_entry(epf, &epc->pci_epf, list) - pci_epf_linkup(epf); - return 0; } -- 2.17.1
[PATCH 07/15] PCI: endpoint: Add helper to get first unreserved BAR
Add a helper function pci_epc_get_first_free_bar(), to get the first
unreserved BAR that can be used for endpoint function.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/endpoint/pci-epc-core.c | 22 ++
include/linux/pci-epc.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/pci/endpoint/pci-epc-core.c
b/drivers/pci/endpoint/pci-epc-core.c
index 5a099479d9ab..b1632f91e33e 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -83,6 +83,28 @@ struct pci_epc *pci_epc_get(const char *epc_name)
}
EXPORT_SYMBOL_GPL(pci_epc_get);
+/**
+ * pci_epc_get_first_free_bar() - helper to get first unreserved BAR
+ * @epc_features: pci_epc_features structure that holds the reserved bar bitmap
+ *
+ * Invoke to get the first unreserved BAR that can be used for endpoint
+ * function.
+ */
+int pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features)
+{
+ int free_bar;
+
+ if (!epc_features)
+ return 0;
+
+ free_bar = ffz(epc_features->reserved_bar);
+ if (free_bar <= 0 || free_bar > 6)
+ return -EINVAL;
+
+ return free_bar;
+}
+EXPORT_SYMBOL_GPL(pci_epc_get_first_free_bar);
+
/**
* pci_epc_get_features() - get the features supported by EPC
* @epc: the features supported by *this* EPC device will be returned
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 79fbcf94e14d..dc3513a2f88a 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -180,6 +180,7 @@ int pci_epc_start(struct pci_epc *epc);
void pci_epc_stop(struct pci_epc *epc);
const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
u8 func_no);
+int pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features);
struct pci_epc *pci_epc_get(const char *epc_name);
void pci_epc_put(struct pci_epc *epc);
--
2.17.1
[PATCH 08/15] PCI: endpoint: Fix pci_epf_alloc_space to set correct MEM TYPE flags
pci_epf_alloc_space() sets the MEM TYPE flags to indicate a 32-bit Base Address Register irrespective of the size. Fix it here to indicate 64-bit BAR if the size is > 2GB. Signed-off-by: Kishon Vijay Abraham I --- drivers/pci/endpoint/pci-epf-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c index 825fa24427a3..cd395cb7dfd9 100644 --- a/drivers/pci/endpoint/pci-epf-core.c +++ b/drivers/pci/endpoint/pci-epf-core.c @@ -132,6 +132,9 @@ void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar) epf->bar[bar].size = size; epf->bar[bar].barno = bar; epf->bar[bar].flags = PCI_BASE_ADDRESS_SPACE_MEMORY; + epf->bar[bar].flags |= upper_32_bits(size) ? + PCI_BASE_ADDRESS_MEM_TYPE_64 : + PCI_BASE_ADDRESS_MEM_TYPE_32; return space; } -- 2.17.1
[PATCH 10/15] PCI: pci-epf-test: Do not allocate next BARs memory if current BAR is 64Bit
It's useless to allocate memory for next BAR if the current BAR is a
64Bit BAR. Stop allocating memory for the next BAR, if the current
BARs flag indicates this is a 64Bit BAR.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/endpoint/functions/pci-epf-test.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 44cc31343a80..ade296180383 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -429,6 +429,7 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
{
struct pci_epf_test *epf_test = epf_get_drvdata(epf);
struct device *dev = &epf->dev;
+ struct pci_epf_bar *epf_bar;
void *base;
int bar;
enum pci_barno test_reg_bar = epf_test->test_reg_bar;
@@ -442,6 +443,7 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
epf_test->reg[test_reg_bar] = base;
for (bar = BAR_0; bar <= BAR_5; bar++) {
+ epf_bar = &epf->bar[bar];
if (bar == test_reg_bar)
continue;
base = pci_epf_alloc_space(epf, bar_size[bar], bar);
@@ -449,6 +451,8 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
dev_err(dev, "Failed to allocate space for BAR%d\n",
bar);
epf_test->reg[bar] = base;
+ if (epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
+ bar++;
}
return 0;
--
2.17.1
[PATCH 11/15] PCI: pci-epf-test: Use pci_epc_get_features to get EPC features
Use pci_epc_get_features to get EPC features such as linkup
notifier support, MSI/MSIX capable, BAR configuration etc and use it
for configuring pci-epf-test. Since these features are now obtained
directly from EPC driver, remove pci_epf_test_data which was initially
added to have EPC features in endpoint function driver.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/endpoint/functions/pci-epf-test.c | 72 ++-
1 file changed, 39 insertions(+), 33 deletions(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
b/drivers/pci/endpoint/functions/pci-epf-test.c
index ade296180383..a26f6ccaa322 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -47,8 +47,6 @@ struct pci_epf_test {
void*reg[6];
struct pci_epf *epf;
enum pci_barno test_reg_bar;
- boollinkup_notifier;
- boolmsix_available;
struct delayed_work cmd_handler;
};
@@ -71,11 +69,6 @@ static struct pci_epf_header test_header = {
.interrupt_pin = PCI_INTERRUPT_INTA,
};
-struct pci_epf_test_data {
- enum pci_barno test_reg_bar;
- boollinkup_notifier;
-};
-
static size_t bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
static int pci_epf_test_copy(struct pci_epf_test *epf_test)
@@ -458,25 +451,49 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
return 0;
}
+static void pci_epf_configure_bar(struct pci_epf *epf,
+ const struct pci_epc_features *epc_features)
+{
+ struct pci_epf_bar *epf_bar;
+ bool bar_fixed_64bit;
+ int i;
+
+ for (i = BAR_0; i <= BAR_5; i++) {
+ epf_bar = &epf->bar[i];
+ bar_fixed_64bit = !!(epc_features->bar_fixed_64bit & (1 << i));
+ if (bar_fixed_64bit)
+ epf_bar->flags |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+ if (epc_features->bar_fixed_size[i])
+ bar_size[i] = epc_features->bar_fixed_size[i];
+ }
+}
+
static int pci_epf_test_bind(struct pci_epf *epf)
{
int ret;
struct pci_epf_test *epf_test = epf_get_drvdata(epf);
struct pci_epf_header *header = epf->header;
+ const struct pci_epc_features *epc_features;
+ enum pci_barno test_reg_bar = BAR_0;
struct pci_epc *epc = epf->epc;
struct device *dev = &epf->dev;
+ bool linkup_notifier = false;
+ bool msix_capable = false;
+ bool msi_capable = true;
if (WARN_ON_ONCE(!epc))
return -EINVAL;
- if (epc->features & EPC_FEATURE_NO_LINKUP_NOTIFIER)
- epf_test->linkup_notifier = false;
- else
- epf_test->linkup_notifier = true;
-
- epf_test->msix_available = epc->features & EPC_FEATURE_MSIX_AVAILABLE;
+ epc_features = pci_epc_get_features(epc, epf->func_no);
+ if (!epc_features) {
+ linkup_notifier = epc_features->linkup_notifier;
+ msix_capable = epc_features->msix_capable;
+ msi_capable = epc_features->msi_capable;
+ test_reg_bar = pci_epc_get_first_free_bar(epc_features);
+ pci_epf_configure_bar(epf, epc_features);
+ }
- epf_test->test_reg_bar = EPC_FEATURE_GET_BAR(epc->features);
+ epf_test->test_reg_bar = test_reg_bar;
ret = pci_epc_write_header(epc, epf->func_no, header);
if (ret) {
@@ -492,13 +509,15 @@ static int pci_epf_test_bind(struct pci_epf *epf)
if (ret)
return ret;
- ret = pci_epc_set_msi(epc, epf->func_no, epf->msi_interrupts);
- if (ret) {
- dev_err(dev, "MSI configuration failed\n");
- return ret;
+ if (msi_capable) {
+ ret = pci_epc_set_msi(epc, epf->func_no, epf->msi_interrupts);
+ if (ret) {
+ dev_err(dev, "MSI configuration failed\n");
+ return ret;
+ }
}
- if (epf_test->msix_available) {
+ if (msix_capable) {
ret = pci_epc_set_msix(epc, epf->func_no, epf->msix_interrupts);
if (ret) {
dev_err(dev, "MSI-X configuration failed\n");
@@ -506,7 +525,7 @@ static int pci_epf_test_bind(struct pci_epf *epf)
}
}
- if (!epf_test->linkup_notifier)
+ if (!linkup_notifier)
queue_work(kpcitest_workqueue, &epf_test->cmd_handler.work);
return 0;
@@ -523,17 +542,6 @@ static int pci_epf_test_probe(struct pci_epf *epf)
{
struct pci_epf_test *epf_test;
struct device *dev = &epf->dev;
- const struct pci_epf_device_id *match;
- struct pci_epf_test_data *data;
- enum pci_barno test_reg_bar = BAR_0;
- bool linkup_notifier = true;
-
- match = pci_epf_match_d
[PATCH 14/15] PCI: designware-plat: Remove setting epc->features in Designware plat EP driver
Now that pci-epf-test uses get_features callback and
dw_plat_pcie_epc_features in Designware plat EP driver already indicates
it doesn't support linkup notification and is MSIX capable, remove setting
epc->features which is not used anymore by the endpoint function driver.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/dwc/pcie-designware-plat.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-plat.c
b/drivers/pci/controller/dwc/pcie-designware-plat.c
index bd0516afc86f..3be87126aef3 100644
--- a/drivers/pci/controller/dwc/pcie-designware-plat.c
+++ b/drivers/pci/controller/dwc/pcie-designware-plat.c
@@ -70,14 +70,10 @@ static const struct dw_pcie_ops dw_pcie_ops = {
static void dw_plat_pcie_ep_init(struct dw_pcie_ep *ep)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
- struct pci_epc *epc = ep->epc;
enum pci_barno bar;
for (bar = BAR_0; bar <= BAR_5; bar++)
dw_pcie_ep_reset_bar(pci, bar);
-
- epc->features |= EPC_FEATURE_NO_LINKUP_NOTIFIER;
- epc->features |= EPC_FEATURE_MSIX_AVAILABLE;
}
static int dw_plat_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
--
2.17.1
[PATCH 13/15] PCI: rockchip: Remove pci_epf_linkup from Rockchip EP driver
pci_epf_linkup is intended to be invoked if the EPC supports linkup notification. Now that pci-epf-test uses get_features callback, which indicates Rockchip EP driver doesn't support linkup notification, remove pci_epf_linkup from Rockchip EP driver. Signed-off-by: Kishon Vijay Abraham I --- drivers/pci/controller/pcie-rockchip-ep.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/pci/controller/pcie-rockchip-ep.c b/drivers/pci/controller/pcie-rockchip-ep.c index 9b60ad323ac7..a5d799e2dff2 100644 --- a/drivers/pci/controller/pcie-rockchip-ep.c +++ b/drivers/pci/controller/pcie-rockchip-ep.c @@ -499,9 +499,6 @@ static int rockchip_pcie_ep_start(struct pci_epc *epc) rockchip_pcie_write(rockchip, cfg, PCIE_CORE_PHY_FUNC_CFG); - list_for_each_entry(epf, &epc->pci_epf, list) - pci_epf_linkup(epf); - return 0; } -- 2.17.1
[PATCH 06/15] PCI: cadence: Populate ->get_features() cdns_pcie_epc_ops
Populate ->get_features() dw_pcie_ep_ops to return the EPC features
supported by Cadence PCIe endpoint controller.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/pcie-cadence-ep.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pci/controller/pcie-cadence-ep.c
b/drivers/pci/controller/pcie-cadence-ep.c
index c3a088910f48..14c2545bb17e 100644
--- a/drivers/pci/controller/pcie-cadence-ep.c
+++ b/drivers/pci/controller/pcie-cadence-ep.c
@@ -411,6 +411,18 @@ static int cdns_pcie_ep_start(struct pci_epc *epc)
return 0;
}
+static const struct pci_epc_features cdns_pcie_epc_features = {
+ .linkup_notifier = false,
+ .msi_capable = true,
+ .msix_capable = false,
+};
+
+static const struct pci_epc_features*
+cdns_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+{
+ return &cdns_pcie_epc_features;
+}
+
static const struct pci_epc_ops cdns_pcie_epc_ops = {
.write_header = cdns_pcie_ep_write_header,
.set_bar= cdns_pcie_ep_set_bar,
@@ -421,6 +433,7 @@ static const struct pci_epc_ops cdns_pcie_epc_ops = {
.get_msi= cdns_pcie_ep_get_msi,
.raise_irq = cdns_pcie_ep_raise_irq,
.start = cdns_pcie_ep_start,
+ .get_features = cdns_pcie_ep_get_features,
};
static const struct of_device_id cdns_pcie_ep_of_match[] = {
--
2.17.1
[PATCH 15/15] PCI: endpoint: Remove features member in struct pci_epc
Since EPC features are now implemented using pci_epc_features and
all the EPC drivers are moved to using pci_epc_features, remove
features member in struct pci_epc and all the helper macros for
configuring the features.
Signed-off-by: Kishon Vijay Abraham I
---
include/linux/pci-epc.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index dc3513a2f88a..4870ad5a6ca2 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -99,7 +99,6 @@ struct pci_epc {
struct config_group *group;
/* spinlock to protect against concurrent access of EP controller */
spinlock_t lock;
- unsigned intfeatures;
};
/**
@@ -120,14 +119,6 @@ struct pci_epc_features {
u64 bar_fixed_size[BAR_5 + 1];
};
-#define EPC_FEATURE_NO_LINKUP_NOTIFIER BIT(0)
-#define EPC_FEATURE_BAR_MASK (BIT(1) | BIT(2) | BIT(3))
-#define EPC_FEATURE_MSIX_AVAILABLE BIT(4)
-#define EPC_FEATURE_SET_BAR(features, bar) \
- (features |= (EPC_FEATURE_BAR_MASK & (bar << 1)))
-#define EPC_FEATURE_GET_BAR(features) \
- ((features & EPC_FEATURE_BAR_MASK) >> 1)
-
#define to_pci_epc(device) container_of((device), struct pci_epc, dev)
#define pci_epc_create(dev, ops)\
--
2.17.1
[PATCH 05/15] PCI: rockchip: Populate ->get_features() dw_pcie_ep_ops
Populate ->get_features() dw_pcie_ep_ops to return the EPC features
supported by Rockchip PCIe endpoint controller.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/pcie-rockchip-ep.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c
b/drivers/pci/controller/pcie-rockchip-ep.c
index b8163c56a142..9b60ad323ac7 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -505,6 +505,18 @@ static int rockchip_pcie_ep_start(struct pci_epc *epc)
return 0;
}
+static const struct pci_epc_features rockchip_pcie_epc_features = {
+ .linkup_notifier = false,
+ .msi_capable = true,
+ .msix_capable = false,
+};
+
+static const struct pci_epc_features*
+rockchip_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+{
+ return &rockchip_pcie_epc_features;
+}
+
static const struct pci_epc_ops rockchip_pcie_epc_ops = {
.write_header = rockchip_pcie_ep_write_header,
.set_bar= rockchip_pcie_ep_set_bar,
@@ -515,6 +527,7 @@ static const struct pci_epc_ops rockchip_pcie_epc_ops = {
.get_msi= rockchip_pcie_ep_get_msi,
.raise_irq = rockchip_pcie_ep_raise_irq,
.start = rockchip_pcie_ep_start,
+ .get_features = rockchip_pcie_ep_get_features,
};
static int rockchip_pcie_parse_ep_dt(struct rockchip_pcie *rockchip,
--
2.17.1
[PATCH 09/15] PCI: pci-epf-test: Remove setting epf_bar flags in function driver
Now that pci_epf_alloc_space() sets BAR MEM TYPE flags as 64Bit or
32Bit based on size, remove setting it in function driver.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/endpoint/functions/pci-epf-test.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 3e86fa3c7da3..44cc31343a80 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -406,10 +406,6 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
for (bar = BAR_0; bar <= BAR_5; bar++) {
epf_bar = &epf->bar[bar];
- epf_bar->flags |= upper_32_bits(epf_bar->size) ?
- PCI_BASE_ADDRESS_MEM_TYPE_64 :
- PCI_BASE_ADDRESS_MEM_TYPE_32;
-
ret = pci_epc_set_bar(epc, epf->func_no, epf_bar);
if (ret) {
pci_epf_free_space(epf, epf_test->reg[bar], bar);
--
2.17.1
[PATCH 04/15] PCI: pci-dra7xx: Populate ->get_features() dw_pcie_ep_ops
Populate ->get_features() dw_pcie_ep_ops to return the EPC features
supported by DRA7xx PCIe endpoint controller.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/dwc/pci-dra7xx.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c
b/drivers/pci/controller/dwc/pci-dra7xx.c
index a32d6dde7a57..15620cfa617b 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -389,9 +389,22 @@ static int dra7xx_pcie_raise_irq(struct dw_pcie_ep *ep, u8
func_no,
return 0;
}
+static const struct pci_epc_features dra7xx_pcie_epc_features = {
+ .linkup_notifier = true,
+ .msi_capable = true,
+ .msix_capable = false,
+};
+
+static const struct pci_epc_features*
+dra7xx_pcie_get_features(struct dw_pcie_ep *ep)
+{
+ return &dra7xx_pcie_epc_features;
+}
+
static struct dw_pcie_ep_ops pcie_ep_ops = {
.ep_init = dra7xx_pcie_ep_init,
.raise_irq = dra7xx_pcie_raise_irq,
+ .get_features = dra7xx_pcie_get_features,
};
static int __init dra7xx_add_pcie_ep(struct dra7xx_pcie *dra7xx,
--
2.17.1
[PATCH 03/15] PCI: designware-plat: Populate ->get_features() dw_pcie_ep_ops
Populate ->get_features() dw_pcie_ep_ops to return the EPC features
supported by Designware PCIe endpoint controller.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/dwc/pcie-designware-plat.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-plat.c
b/drivers/pci/controller/dwc/pcie-designware-plat.c
index c12bf794d69c..bd0516afc86f 100644
--- a/drivers/pci/controller/dwc/pcie-designware-plat.c
+++ b/drivers/pci/controller/dwc/pcie-designware-plat.c
@@ -100,9 +100,22 @@ static int dw_plat_pcie_ep_raise_irq(struct dw_pcie_ep
*ep, u8 func_no,
return 0;
}
+static const struct pci_epc_features dw_plat_pcie_epc_features = {
+ .linkup_notifier = false,
+ .msi_capable = true,
+ .msix_capable = true,
+};
+
+static const struct pci_epc_features*
+dw_plat_pcie_get_features(struct dw_pcie_ep *ep)
+{
+ return &dw_plat_pcie_epc_features;
+}
+
static struct dw_pcie_ep_ops pcie_ep_ops = {
.ep_init = dw_plat_pcie_ep_init,
.raise_irq = dw_plat_pcie_ep_raise_irq,
+ .get_features = dw_plat_pcie_get_features,
};
static int dw_plat_add_pcie_port(struct dw_plat_pcie *dw_plat_pcie,
--
2.17.1
[PATCH 02/15] PCI: dwc: Add ->get_features() callback function in dw_pcie_ep_ops
Each platform using Designware PCIe core can support different set of
endpoint features. Add a new callback function ->get_features() in
dw_pcie_ep_ops so that each platform using Designware PCIe core can
advertise its supported features to the endpoint function driver.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 12
drivers/pci/controller/dwc/pcie-designware.h| 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index a543c45c7224..7a2925a16ab8 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -355,6 +355,17 @@ static int dw_pcie_ep_start(struct pci_epc *epc)
return pci->ops->start_link(pci);
}
+static const struct pci_epc_features*
+dw_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+{
+ struct dw_pcie_ep *ep = epc_get_drvdata(epc);
+
+ if (!ep->ops->get_features)
+ return NULL;
+
+ return ep->ops->get_features(ep);
+}
+
static const struct pci_epc_ops epc_ops = {
.write_header = dw_pcie_ep_write_header,
.set_bar= dw_pcie_ep_set_bar,
@@ -368,6 +379,7 @@ static const struct pci_epc_ops epc_ops = {
.raise_irq = dw_pcie_ep_raise_irq,
.start = dw_pcie_ep_start,
.stop = dw_pcie_ep_stop,
+ .get_features = dw_pcie_ep_get_features,
};
int dw_pcie_ep_raise_legacy_irq(struct dw_pcie_ep *ep, u8 func_no)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 9943d8c68335..1f56e6ae34ff 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -192,6 +192,7 @@ struct dw_pcie_ep_ops {
void(*ep_init)(struct dw_pcie_ep *ep);
int (*raise_irq)(struct dw_pcie_ep *ep, u8 func_no,
enum pci_epc_irq_type type, u16 interrupt_num);
+ const struct pci_epc_features* (*get_features)(struct dw_pcie_ep *ep);
};
struct dw_pcie_ep {
--
2.17.1
[PATCH 00/15] PCI: endpoint: Cleanup EPC features
Hi Lorenzo, The Endpoint controller driver uses features member in 'struct pci_epc' to advertise the list of supported features to the endpoint function driver. There are a few shortcomings with this approach. *) Certain endpoint controllers support fixed size BAR (e.g. TI's AM654 uses Designware configuration with fixed size BAR). The size of each BARs cannot be passed to the endpoint function driver. *) Too many macros for handling EPC features. (EPC_FEATURE_NO_LINKUP_NOTIFIER, EPC_FEATURE_BAR_MASK, EPC_FEATURE_MSIX_AVAILABLE, EPC_FEATURE_SET_BAR, EPC_FEATURE_GET_BAR) *) Endpoint controllers are directly modifying struct pci_epc members. (I have plans to move struct pci_epc to drivers/pci/endpoint so that pci_epc members are referenced only by endpoint core). To overcome the above shortcomings, introduced pci_epc_get_features() API, pci_epc_features structure and a ->get_features() callback. Also added a patch to set BAR flags in pci_epf_alloc_space and remove it from pci-epf-test function driver. Tested on TI's DRA7xx platform. Thanks Kishon Kishon Vijay Abraham I (15): PCI: endpoint: Add new pci_epc_ops to get EPC features PCI: dwc: Add ->get_features() callback function in dw_pcie_ep_ops PCI: designware-plat: Populate ->get_features() dw_pcie_ep_ops PCI: pci-dra7xx: Populate ->get_features() dw_pcie_ep_ops PCI: rockchip: Populate ->get_features() dw_pcie_ep_ops PCI: cadence: Populate ->get_features() cdns_pcie_epc_ops PCI: endpoint: Add helper to get first unreserved BAR PCI: endpoint: Fix pci_epf_alloc_space to set correct MEM TYPE flags PCI: pci-epf-test: Remove setting epf_bar flags in function driver PCI: pci-epf-test: Do not allocate next BARs memory if current BAR is 64Bit PCI: pci-epf-test: Use pci_epc_get_features to get EPC features PCI: cadence: Remove pci_epf_linkup from Cadence EP driver PCI: rockchip: Remove pci_epf_linkup from Rockchip EP driver PCI: designware-plat: Remove setting epc->features in Designware plat EP driver PCI: endpoint: Remove features member in struct pci_epc drivers/pci/controller/dwc/pci-dra7xx.c | 13 +++ .../pci/controller/dwc/pcie-designware-ep.c | 12 +++ .../pci/controller/dwc/pcie-designware-plat.c | 17 +++- drivers/pci/controller/dwc/pcie-designware.h | 1 + drivers/pci/controller/pcie-cadence-ep.c | 25 +++--- drivers/pci/controller/pcie-rockchip-ep.c | 16 +++- drivers/pci/endpoint/functions/pci-epf-test.c | 80 ++- drivers/pci/endpoint/pci-epc-core.c | 52 drivers/pci/endpoint/pci-epf-core.c | 3 + include/linux/pci-epc.h | 30 +-- 10 files changed, 185 insertions(+), 64 deletions(-) -- 2.17.1
[PATCH 01/15] PCI: endpoint: Add new pci_epc_ops to get EPC features
Add a new pci_epc_ops ->get_features() to get the features
supported by EPC. Since EPC can provide different features to
different functions, the ->get_features() ops takes _func_no_ as
an argument.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/endpoint/pci-epc-core.c | 30 +
include/linux/pci-epc.h | 22 +
2 files changed, 52 insertions(+)
diff --git a/drivers/pci/endpoint/pci-epc-core.c
b/drivers/pci/endpoint/pci-epc-core.c
index 094dcc3203b8..5a099479d9ab 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -83,6 +83,36 @@ struct pci_epc *pci_epc_get(const char *epc_name)
}
EXPORT_SYMBOL_GPL(pci_epc_get);
+/**
+ * pci_epc_get_features() - get the features supported by EPC
+ * @epc: the features supported by *this* EPC device will be returned
+ * @func_no: the features supported by the EPC device specific to the
+ * endpoint function with func_no will be returned
+ *
+ * Invoke to get the features provided by the EPC which may be
+ * specific to an endpoint function. Returns pci_epc_features on success
+ * and NULL for any failures.
+ */
+const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
+ u8 func_no)
+{
+ const struct pci_epc_features *epc_features;
+ unsigned long flags;
+
+ if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
+ return NULL;
+
+ if (!epc->ops->get_features)
+ return NULL;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ epc_features = epc->ops->get_features(epc, func_no);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return epc_features;
+}
+EXPORT_SYMBOL_GPL(pci_epc_get_features);
+
/**
* pci_epc_stop() - stop the PCI link
* @epc: the link of the EPC device that has to be stopped
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 37dab8116901..79fbcf94e14d 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -59,6 +59,8 @@ struct pci_epc_ops {
enum pci_epc_irq_type type, u16 interrupt_num);
int (*start)(struct pci_epc *epc);
void(*stop)(struct pci_epc *epc);
+ const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
+ u8 func_no);
struct module *owner;
};
@@ -100,6 +102,24 @@ struct pci_epc {
unsigned intfeatures;
};
+/**
+ * struct pci_epc_features - features supported by a EPC device per function
+ * @linkup_notifier: indicate if the EPC device can notify EPF driver on link
up
+ * @msi_capable: indicate if the endpoint function has MSI capability
+ * @msix_capable: indicate if the endpoint function has MSI-X capability
+ * @reserved_bar: bitmap to indicate reserved BAR unavailable to function
driver
+ * @bar_fixed_64bit: bitmap to indicate fixed 64bit BARs
+ * @bar_fixed_size: Array specifying the size supported by each BAR
+ */
+struct pci_epc_features {
+ unsigned intlinkup_notifier : 1;
+ unsigned intmsi_capable : 1;
+ unsigned intmsix_capable : 1;
+ u8 reserved_bar;
+ u8 bar_fixed_64bit;
+ u64 bar_fixed_size[BAR_5 + 1];
+};
+
#define EPC_FEATURE_NO_LINKUP_NOTIFIER BIT(0)
#define EPC_FEATURE_BAR_MASK (BIT(1) | BIT(2) | BIT(3))
#define EPC_FEATURE_MSIX_AVAILABLE BIT(4)
@@ -158,6 +178,8 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
enum pci_epc_irq_type type, u16 interrupt_num);
int pci_epc_start(struct pci_epc *epc);
void pci_epc_stop(struct pci_epc *epc);
+const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
+ u8 func_no);
struct pci_epc *pci_epc_get(const char *epc_name);
void pci_epc_put(struct pci_epc *epc);
--
2.17.1
Re: [PATCH v4] USB: Don't enable LPM if it's already enabled
Hi,
> On Dec 3, 2018, at 18:26, Kai-Heng Feng wrote:
>
> USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working
> after S3:
> [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_0302.bin
> [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110)
>
> After some experiments, I found that disabling LPM can workaround the
> issue.
>
> On some platforms, the USB power is cut during S3, so the driver uses
> reset-resume to resume the device. During port resume, LPM gets enabled
> twice, by usb_reset_and_verify_device() and usb_port_resume().
>
> So let's enable LPM for just once, as this solves the issue for the
> device in question.
>
> Also consolidate USB2 LPM functions to usb_enable_usb2_hardware_lpm()
> and usb_disable_usb2_hardware_lpm().
Please review my new approach, hopefully this can be included in Linux v5.0.
>
> Signed-off-by: Kai-Heng Feng
> ---
> v4:
> - Use usb_enable_usb2_hardware_lpm() and
> usb_disable_usb2_hardware_lpm() to control USB2 LPM.
> v3:
> - Consolidate udev->usb2_hw_lpm_capable and udev->usb2_hw_lpm_enabled
> check to usb_set_usb2_hardware_lpm().
> v2:
> - Check udev->usb2_hw_lpm_enabled before calling usb_port_resume().
>
> drivers/usb/core/driver.c | 23 +++
> drivers/usb/core/hub.c | 16 ++--
> drivers/usb/core/message.c | 3 +--
> drivers/usb/core/sysfs.c | 5 -
> drivers/usb/core/usb.h | 10 --
> 5 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
> index 53564386ed57..8987cec9549d 100644
> --- a/drivers/usb/core/driver.c
> +++ b/drivers/usb/core/driver.c
> @@ -1896,14 +1896,11 @@ int usb_runtime_idle(struct device *dev)
> return -EBUSY;
> }
>
> -int usb_set_usb2_hardware_lpm(struct usb_device *udev, int enable)
> +static int usb_set_usb2_hardware_lpm(struct usb_device *udev, int enable)
> {
> struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> int ret = -EPERM;
>
> - if (enable && !udev->usb2_hw_lpm_allowed)
> - return 0;
> -
> if (hcd->driver->set_usb2_hw_lpm) {
> ret = hcd->driver->set_usb2_hw_lpm(hcd, udev, enable);
> if (!ret)
> @@ -1913,6 +1910,24 @@ int usb_set_usb2_hardware_lpm(struct usb_device *udev,
> int enable)
> return ret;
> }
>
> +int usb_enable_usb2_hardware_lpm(struct usb_device *udev)
> +{
> + if (!udev->usb2_hw_lpm_capable ||
> + !udev->usb2_hw_lpm_allowed ||
> + udev->usb2_hw_lpm_enabled)
> + return 0;
> +
> + return usb_set_usb2_hardware_lpm(udev, 1);
> +}
> +
> +int usb_disable_usb2_hardware_lpm(struct usb_device *udev)
> +{
> + if (!udev->usb2_hw_lpm_enabled)
> + return 0;
> +
> + return usb_set_usb2_hardware_lpm(udev, 0);
> +}
> +
> #endif /* CONFIG_PM */
>
> struct bus_type usb_bus_type = {
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 0f9381b69a3b..b4439ee2d144 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -3210,8 +3210,7 @@ int usb_port_suspend(struct usb_device *udev,
> pm_message_t msg)
> }
>
> /* disable USB2 hardware LPM */
> - if (udev->usb2_hw_lpm_enabled == 1)
> - usb_set_usb2_hardware_lpm(udev, 0);
> + usb_disable_usb2_hardware_lpm(udev);
>
> if (usb_disable_ltm(udev)) {
> dev_err(&udev->dev, "Failed to disable LTM before suspend\n");
> @@ -3249,8 +3248,7 @@ int usb_port_suspend(struct usb_device *udev,
> pm_message_t msg)
> usb_enable_ltm(udev);
> err_ltm:
> /* Try to enable USB2 hardware LPM again */
> - if (udev->usb2_hw_lpm_capable == 1)
> - usb_set_usb2_hardware_lpm(udev, 1);
> + usb_enable_usb2_hardware_lpm(udev);
>
> if (udev->do_remote_wakeup)
> (void) usb_disable_remote_wakeup(udev);
> @@ -3533,8 +3531,7 @@ int usb_port_resume(struct usb_device *udev,
> pm_message_t msg)
> hub_port_logical_disconnect(hub, port1);
> } else {
> /* Try to enable USB2 hardware LPM */
> - if (udev->usb2_hw_lpm_capable == 1)
> - usb_set_usb2_hardware_lpm(udev, 1);
> + usb_enable_usb2_hardware_lpm(udev);
>
> /* Try to enable USB3 LTM */
> usb_enable_ltm(udev);
> @@ -4425,7 +4422,7 @@ static void hub_set_initial_usb2_lpm_policy(struct
> usb_device *udev)
> if ((udev->bos->ext_cap->bmAttributes & cpu_to_le32(USB_BESL_SUPPORT))
> ||
> connect_type == USB_PORT_CONNECT_TYPE_HARD_WIRED) {
> udev->usb2_hw_lpm_allowed = 1;
> - usb_set_usb2_hardware_lpm(udev, 1);
> + usb_enable_usb2_hardware_lpm(udev);
> }
> }
>
> @@ -5638,8 +5635,7 @@ static int usb_reset_and_verify_device(struct
> usb_device *udev)
> /* Disable USB2 hardware LPM.
>* It will be re-ena
Re: [PATCH 4/4] pmbus (dps650ab): add power supply driver
On 1/6/19 10:25 PM, Liu, Xiaoting wrote:
Hi Guenter Roeck,
Thanks for your apply, we will drop this patch and add the
structpmbus_device_info in PMBus.c.
NP. Make sure though that the auto-detection finds all properties.
If it does, there is really no reason to have an extra driver.
Thanks,
Guenter
Thanks,
Xiaoting.
On 2019/1/6 1:08, Guenter Roeck wrote:
On Fri, Jan 04, 2019 at 05:05:27PM +0800, Xiaoting Liu wrote:
The Delta dps650ab provides main power and standby power to server.
dps650ab can be detected by MFR_ID and MFR_MODEL referring to
manufacturer's feedback. This patch adds driver to moniter power
supply status.
Another comment: The subject should be something like
hwmon: (pmbus) Add driver for DPS650AB power supply
Additional comments inline below.
Thanks,
Guenter
Signed-off-by: Xiaoting Liu
---
drivers/hwmon/pmbus/Kconfig| 10 +
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/dps650ab.c | 100 +
drivers/hwmon/pmbus/pmbus.c| 3 ++
4 files changed, 114 insertions(+)
--
1.8.3.1
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 629cb45f8557..de4638396592 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -184,4 +184,14 @@ config SENSORS_ZL6100
This driver can also be built as a module. If so, the module will
be called zl6100.
+config SENSORS_DPS650AB
+ tristate "Delta DPS650AB"
+ default n
+ help
+ If you say yes here you get hardware monitoring support for the
+ Delta DPS650AB controller.
+
+ This driver can also be built as a module. If so, the module will
+ be called dps650ab.
+
Ahplabetic order, please.
endif # PMBUS
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index ea0e39518c21..414818230a26 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_SENSORS_TPS53679)+= tps53679.o
obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
obj-$(CONFIG_SENSORS_UCD9200) += ucd9200.o
obj-$(CONFIG_SENSORS_ZL6100) += zl6100.o
+obj-$(CONFIG_SENSORS_DPS650AB) += dps650ab.o
Alphabetic order, please.
diff --git a/drivers/hwmon/pmbus/dps650ab.c b/drivers/hwmon/pmbus/dps650ab.c
new file mode 100644
index ..3c300e621f5a
--- /dev/null
+++ b/drivers/hwmon/pmbus/dps650ab.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hardware monitoring driver for DELTA DPS650AB
+ *
+ * Copyright (c) 2018 Huaxintong Semiconductor Technology Co., Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "pmbus.h"
+
+#define DPS650AB_MFR_ID"DELTA"
+#define DPS650AB_MFR_MODEL "DPS-650AB-16 A"
+
+static int dps650ab_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct pmbus_driver_info *info;
+ u8 buf[I2C_SMBUS_BLOCK_MAX];
+ int ret;
+
+ memset(buf, 0, I2C_SMBUS_BLOCK_MAX);
+
+ if (!i2c_check_functionality(client->adapter,
+I2C_FUNC_SMBUS_READ_BYTE_DATA
+ | I2C_FUNC_SMBUS_READ_WORD_DATA
+ | I2C_FUNC_SMBUS_READ_BLOCK_DATA))
+ return -ENODEV;
+
+ ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to read PMBUS_MFR_ID\n");
+ return ret;
+ }
+
+ if (strncmp(buf, DPS650AB_MFR_ID, strlen(DPS650AB_MFR_ID))) {
+ dev_err(&client->dev, "DPS650AB_MFR_ID unrecognised\n");
+ return -ENODEV;
+ }
+
+ ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, buf);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to read PMBUS_MFR_MODEL\n");
+ return ret;
+ }
+
+ if (strncmp(buf, DPS650AB_MFR_MODEL, strlen(DPS650AB_MFR_MODEL))) {
+ dev_err(&client->dev, "DPS650AB_MFR_MODEL unrecognised\n");
+ return -ENODEV;
+ }
+
+ info = devm_kzalloc(&client->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info->pages = 1;
+ info->format[PSC_VOLTAGE_IN] = linear;
+ info->format[PSC_VOLTAGE_OUT] = linear;
+ info->format[PSC_CURRENT_IN] = linear;
+ info->format[PSC_CURRENT_OUT] = linear;
+ info->format[PSC_POWER] = linear;
+ info->format[PSC_TEMPERATURE] = linear;
+
+ info->func[0] = PMBUS_HAVE_VIN
+ | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN
+ | PMBUS_HAVE_STATUS_INPUT
+ | PMBUS_HAVE_POUT | PMBUS_HAVE_FAN12
+ | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
+ | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT
+ | PMBUS_HAVE_TEMP | PMBUS_HAVE_TEMP2
+ | PMBUS_HAVE_STATUS_TEMP;
+ info->func
Re: [PATCH RFC 1/2] virtio-net: bql support
On 2019/1/7 下午12:01, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 11:51:55AM +0800, Jason Wang wrote:
On 2019/1/7 上午11:17, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 10:14:37AM +0800, Jason Wang wrote:
On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
On Wed, Jan 02, 2019 at 11:28:43AM +0800, Jason Wang wrote:
On 2018/12/31 上午2:45, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 06:00:36PM +0800, Jason Wang wrote:
On 2018/12/26 下午11:19, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:
On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:
When use_napi is set, let's enable BQLs. Note: some of the issues are
similar to wifi. It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.
I've played a similar patch several days before. The tricky part is the mode
switching between napi and no napi. We should make sure when the packet is
sent and trakced by BQL, it should be consumed by BQL as well. I did it by
tracking it through skb->cb. And deal with the freeze by reset the BQL
status. Patch attached.
But when testing with vhost-net, I don't very a stable performance,
So how about increasing TSQ pacing shift then?
I can test this. But changing default TCP value is much more than a
virtio-net specific thing.
Well same logic as wifi applies. Unpredictable latencies related
to radio in one case, to host scheduler in the other.
it was
probably because we batch the used ring updating so tx interrupt may come
randomly. We probably need to implement time bounded coalescing mechanism
which could be configured from userspace.
I don't think it's reasonable to expect userspace to be that smart ...
Why do we need time bounded? used ring is always updated when ring
becomes empty.
We don't add used when means BQL may not see the consumed packet in time.
And the delay varies based on the workload since we count packets not bytes
or time before doing the batched updating.
Thanks
Sorry I still don't get it.
When nothing is outstanding then we do update the used.
So if BQL stops userspace from sending packets then
we get an interrupt and packets start flowing again.
Yes, but how about the cases of multiple flows. That's where I see unstable
results.
It might be suboptimal, we might need to tune it but I doubt running
timers is a solution, timer interrupts cause VM exits.
Probably not a timer but a time counter (or event byte counter) in vhost to
add used and signal guest if it exceeds a value instead of waiting the
number of packets.
Thanks
Well we already have VHOST_NET_WEIGHT - is it too big then?
I'm not sure, it might be too big.
And maybe we should expose the "MORE" flag in the descriptor -
do you think that will help?
I don't know. But how a "more" flag can help here?
Thanks
It sounds like we should be a bit more aggressive in updating used ring.
But if we just do it naively we will harm performance for sure as that
is how we are doing batching right now.
I agree but the problem is to balance the PPS and throughput. More batching
helps for PPS but may damage TCP throughput.
That is what more flag is supposed to be I think - it is only set if
there's a socket that actually needs the skb freed in order to go on.
I'm not quite sure I get, but is this something similar to what you want?
https://lists.linuxfoundation.org/pipermail/virtualization/2014-October/027667.html
Which enables tx interrupt for TCP packets, and you want to add used
more aggressively for those sockets?
Thanks
Instead we could make guest
control batching using the more flag - if that's not set we write out
the used ring.
It's under the control of guest, so I'm afraid we still need some more guard
(e.g time/bytes counters) on host.
Thanks
Point is if guest does not care about the skb being freed, then there is no
rush host side to mark buffer used.
[PATCH v2] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
While using Elan touchpads, the message floods:
[ 136.138487] i2c_hid i2c-DELL08D6:00: i2c_hid_get_input: incomplete report
(14/65535)
Though the message flood is annoying, the device it self works without
any issue. I suspect that the device in question takes too much time to
pull the IRQ back to high after I2C host has done reading its data.
Since the host receives all useful data, let's ignore the input report
when there's no data.
Signed-off-by: Kai-Heng Feng
---
v2:
Use dev_warn_once() to warn the user about the situation.
drivers/hid/i2c-hid/i2c-hid-core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 8555ce7e737b..fd3b0ddace27 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -50,6 +50,7 @@
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
#define I2C_HID_QUIRK_NO_RUNTIME_PMBIT(2)
#define I2C_HID_QUIRK_DELAY_AFTER_SLEEPBIT(3)
+#define I2C_HID_QUIRK_BOGUS_IRQBIT(4)
/* flags */
#define I2C_HID_STARTED0
@@ -179,6 +180,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
{ USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
I2C_HID_QUIRK_NO_RUNTIME_PM },
+ { USB_VENDOR_ID_ELAN, HID_ANY_ID,
+I2C_HID_QUIRK_BOGUS_IRQ },
{ 0, 0 }
};
@@ -503,6 +506,12 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
return;
}
+ if (ihid->quirks & I2C_HID_QUIRK_BOGUS_IRQ && ret_size == 0x) {
+ dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
+ there's no data\n", __func__);
+ return;
+ }
+
if ((ret_size > size) || (ret_size < 2)) {
dev_err(&ihid->client->dev, "%s: incomplete report (%d/%d)\n",
__func__, size, ret_size);
--
2.17.1
Re: [PATCH 2/8 v2] Documentation: bindings: k3dma: Add binding for dma-avail-chan
On 05-01-19, 19:38, Manivannan Sadhasivam wrote: > Hi Vinod, > > On Sat, Jan 05, 2019 at 07:16:10PM +0530, Vinod Koul wrote: > > On 05-01-19, 10:23, Manivannan Sadhasivam wrote: > > > On Fri, Jan 04, 2019 at 08:39:34PM -0800, John Stultz wrote: > > > > On Fri, Jan 4, 2019 at 8:00 PM Manivannan Sadhasivam > > > > wrote: > > > > > > > > > > Hi John, > > > > > > > > > > On Fri, Jan 04, 2019 at 12:56:22PM -0800, John Stultz wrote: > > > > > > Some dma channels can be reserved for secure mode or other > > > > > > hardware on the SoC, so provide a binding for a bitmask > > > > > > listing the available channels for the kernel to use. > > > > > > > > > > > > Cc: Vinod Koul > > > > > > Cc: Rob Herring > > > > > > Cc: Mark Rutland > > > > > > Cc: Tanglei Han > > > > > > Cc: Zhuangluan Su > > > > > > Cc: Ryan Grachek > > > > > > Cc: Manivannan Sadhasivam > > > > > > Cc: dmaeng...@vger.kernel.org > > > > > > Cc: devicet...@vger.kernel.org > > > > > > Signed-off-by: John Stultz > > > > > > --- > > > > > > Documentation/devicetree/bindings/dma/k3dma.txt | 3 +++ > > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt > > > > > > b/Documentation/devicetree/bindings/dma/k3dma.txt > > > > > > index 10a2f15..1c466c1 100644 > > > > > > --- a/Documentation/devicetree/bindings/dma/k3dma.txt > > > > > > +++ b/Documentation/devicetree/bindings/dma/k3dma.txt > > > > > > @@ -14,6 +14,9 @@ Required properties: > > > > > > have specific request line > > > > > > - clocks: clock required > > > > > > > > > > > > +Optional properties: > > > > > > +- dma-avail-chan: Bitmask of available physical channels > > > > > > + > > > > > > > > > > This property looks too generic. Since this is specific to HiSi SoCs, > > > > > this could be "hisi-dma-avail-chan"? > > > > > > > > I'm fine to change it, but I'm not sure I fully understand the > > > > rational. Can you help me understand? > > > > Are device node-binding names supposed to have global scope? I assumed > > > > the node property names are basically scoped to the entry? > > > > > > IIUC properties documented in subsystem binding (dma.txt in this case) > > > will have global scope. Those which are not documented in this binding > > > are specific to vendor IPs and should be prefixed with the vendor > > > prefix (hisi in this case). > > > > > > > Further, having some dma channels be reserved doesn't seem to be too > > > > unique a concept, so I'm not sure what we gain long term by prefixing > > > > it? > > > > > > > > > > Right, but this brings up the point of having this functionality in > > > generic DMA engine so that the DMA controller drivers need not handle. > > > So either we should move this available channel check to DMA Engine > > > and document the property in dma.txt so that other IPs can also use it > > > or keep the functionality in K3 driver and use HiSi prefix for the > > > property. > > > > > > But I'd like to hear Vinod/Rob's opinion on this! > > > > So there are two parts, first is if this new property of using 'some' > > channels of controller is generic enough, the answer is unfortunately > > yes, so we should move this to dma.txt as a generic property > > > > But I don't agree the dmaengine core should handle it, we may add > > helpers, but controllers registers N channels and they would do so, core > > should not do filtering > > > > Okay. But won't it create ambiguity? What if a new driver developer > assmes that he can use this property to filter the channels for his own > DMA controller? Since we are _explicitly_ stating that these channels > should be filtered, why the dmaengine core can't handle it? > > If the property is generic, then it makes sense to keep the > functionality also generic. Core doesnt have a view of channels to be filtered, it looks at N channels getting registered and works on those. Till now folks do not create channels for 'filtered' ones and register the ones kernel can use.. -- ~Vinod
Re: [PATCH v1] clk: qcom: lpass: Add CLK_IGNORE_UNUSED for lpass clocks
Hello Stephen,
On 12/21/2018 2:34 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-12-20 03:46:25)
The LPASS clocks has a dependency on the GCC lpass clocks to be enabled
before accessing them and that was the reason to mark the gcc lpass clocks
as critical. But in the case where the lpass subsystem would require a
restart, toggling the lpass reset would from HW clear the SW enable bits
of the GCC lpass clocks. Thus the next time bringing up the lpass subsystem
out of reset would fail.
Allow the lpass clock driver to enable/disable the gcc lpass clocks and
mark the lpass clocks not be accessed during late_init if no client vote.
You need to add more details here. It feels like you wrote the beginning
of a paragraph and then stopped abruptly, leaving the reader hanging for
the whole story. Why is late_init important? Why do we need to leave
them on from the bootloader? What if the bootloader doesn't leave them
enabled? This is all rather hacky so I'm deeply confused. Does the lpass
driver need to get these gcc clks and enable/prepare them during probe?
But then it needs to also allow a reset happen and change the clk state?
I suspect this situation is circling a larger problem where a reset is
toggled and that changes some clk state without the clk framework
knowing. There's not much we can do about that besides having some
mechanism for the clks to know that their state is now out of sync. If
that can be done on the provider driver side then we should have an
easier time not needing to write a bunch of framework code to handle
this. OMAP folks are dealing with the same problems from what I recall.
Hmm, if I mark the CLK_IS_CRITICAL, I don't see a way to handle it in
provider. Please suggest if you think provider could handle it.
Signed-off-by: Taniya Das
@@ -77,6 +81,7 @@
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "lpass_qdsp6ss_sleep_clk",
+ .flags = CLK_IGNORE_UNUSED,
All uses of CLK_IGNORE_UNUSED and CLK_IS_CRITICAL need comments about
why they're there. It's never obvious why these things are being done.
Sure, would add comments.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH v3] mm: Create the new vm_fault_t type
On Fri, Dec 14, 2018 at 10:35 AM Souptick Joarder wrote:
>
> Hi Andrew,
>
> On Sat, Nov 24, 2018 at 10:16 AM Souptick Joarder
> wrote:
> >
> > On Thu, Nov 15, 2018 at 7:17 AM Mike Rapoport wrote:
> > >
> > > On Tue, Nov 06, 2018 at 05:36:42PM +0530, Souptick Joarder wrote:
> > > > Page fault handlers are supposed to return VM_FAULT codes,
> > > > but some drivers/file systems mistakenly return error
> > > > numbers. Now that all drivers/file systems have been converted
> > > > to use the vm_fault_t return type, change the type definition
> > > > to no longer be compatible with 'int'. By making it an unsigned
> > > > int, the function prototype becomes incompatible with a function
> > > > which returns int. Sparse will detect any attempts to return a
> > > > value which is not a VM_FAULT code.
> > > >
> > > > VM_FAULT_SET_HINDEX and VM_FAULT_GET_HINDEX values are changed
> > > > to avoid conflict with other VM_FAULT codes.
> > > >
> > > > Signed-off-by: Souptick Joarder
> > >
> > > For the docs part
> > > Reviewed-by: Mike Rapoport
> > >
> > > > ---
> > > > v2: Updated the change log and corrected the document part.
> > > > name added to the enum that kernel-doc able to parse it.
> > > >
> > > > v3: Corrected the documentation.
> >
> > If no further comment, can we get this patch in queue for 4.21 ?
>
> Do I need to make any further improvement for this patch ?
If no further comment, can we get this patch in queue for 5.0-rcX ?
> >
> > > >
> > > > include/linux/mm.h | 46 --
> > > > include/linux/mm_types.h | 73
> > > > +++-
> > > > 2 files changed, 72 insertions(+), 47 deletions(-)
> > > >
> > > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > > index fcf9cc9..511a3ce 100644
> > > > --- a/include/linux/mm.h
> > > > +++ b/include/linux/mm.h
> > > > @@ -1267,52 +1267,6 @@ static inline void clear_page_pfmemalloc(struct
> > > > page *page)
> > > > }
> > > >
> > > > /*
> > > > - * Different kinds of faults, as returned by handle_mm_fault().
> > > > - * Used to decide whether a process gets delivered SIGBUS or
> > > > - * just gets major/minor fault counters bumped up.
> > > > - */
> > > > -
> > > > -#define VM_FAULT_OOM 0x0001
> > > > -#define VM_FAULT_SIGBUS 0x0002
> > > > -#define VM_FAULT_MAJOR 0x0004
> > > > -#define VM_FAULT_WRITE 0x0008 /* Special case for
> > > > get_user_pages */
> > > > -#define VM_FAULT_HWPOISON 0x0010 /* Hit poisoned small page */
> > > > -#define VM_FAULT_HWPOISON_LARGE 0x0020 /* Hit poisoned large page.
> > > > Index encoded in upper bits */
> > > > -#define VM_FAULT_SIGSEGV 0x0040
> > > > -
> > > > -#define VM_FAULT_NOPAGE 0x0100 /* ->fault installed the pte, not
> > > > return page */
> > > > -#define VM_FAULT_LOCKED 0x0200 /* ->fault locked the returned
> > > > page */
> > > > -#define VM_FAULT_RETRY 0x0400 /* ->fault blocked, must retry */
> > > > -#define VM_FAULT_FALLBACK 0x0800 /* huge page fault failed, fall
> > > > back to small */
> > > > -#define VM_FAULT_DONE_COW 0x1000 /* ->fault has fully handled COW
> > > > */
> > > > -#define VM_FAULT_NEEDDSYNC 0x2000 /* ->fault did not modify page
> > > > tables
> > > > - * and needs fsync() to complete
> > > > (for
> > > > - * synchronous page faults in
> > > > DAX) */
> > > > -
> > > > -#define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS |
> > > > VM_FAULT_SIGSEGV | \
> > > > - VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE | \
> > > > - VM_FAULT_FALLBACK)
> > > > -
> > > > -#define VM_FAULT_RESULT_TRACE \
> > > > - { VM_FAULT_OOM, "OOM" }, \
> > > > - { VM_FAULT_SIGBUS, "SIGBUS" }, \
> > > > - { VM_FAULT_MAJOR, "MAJOR" }, \
> > > > - { VM_FAULT_WRITE, "WRITE" }, \
> > > > - { VM_FAULT_HWPOISON,"HWPOISON" }, \
> > > > - { VM_FAULT_HWPOISON_LARGE, "HWPOISON_LARGE" }, \
> > > > - { VM_FAULT_SIGSEGV, "SIGSEGV" }, \
> > > > - { VM_FAULT_NOPAGE, "NOPAGE" }, \
> > > > - { VM_FAULT_LOCKED, "LOCKED" }, \
> > > > - { VM_FAULT_RETRY, "RETRY" }, \
> > > > - { VM_FAULT_FALLBACK,"FALLBACK" }, \
> > > > - { VM_FAULT_DONE_COW,"DONE_COW" }, \
> > > > - { VM_FAULT_NEEDDSYNC, "NEEDDSYNC" }
> > > > -
> > > > -/* Encode hstate index for a hwpoisoned large page */
> > > > -#define VM_FAULT_SET_HINDEX(x) ((x) << 12)
> > > > -#define VM_FAULT_GET_HINDEX(x) (((x) >> 12) & 0xf)
> > > > -
> > > > -/*
> > > > * Can be called by the pagefault handler when it gets a VM_FAULT_OOM.
> > > > */
> > > > extern void pagefault_out_of_memory(void);
> > > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > > index 5ed8f62..cb25016 100644
> > > >
Re: [PATCH v2] staging: wilc1000: fix cast to restricted __le32
Hi Julius, On 1/6/2019 12:48 PM, Július Milan wrote: >> Before you send V3, are you sure this is the correct fix? As "frame_type" is >> input as u16, it seems to me that the frame_type member of struct >> wilc_reg_frame >> should be __le16, not __le32. > > Yes, I am confident about it. > The frame_type member of struct wilc_reg_frame contains in some cases > 32 bit value > as you can see in function wilc_wlan_cfg_set_wid. > Cast to 32 bits is also safe, due to resultant endianness. Thanks for submitting your patch. But as Larry pointed we need to change the 'frame_type' type to '__le16' in 'wilc_reg_frame' struct. The correct fix for this issue is to change the datatype from ‘__le32’ to ‘__le16’, as the firmware expects it to be a 16bit value. As wilc_wlan_cfg_set_wid(), is a generic function to pack different types of WID's e.g char u8 (0x0xxx), short (u16) (0x1xxx), int (u32) (0x2xxx), byte-string (0x3xxx) and binary data(0x4xxx). And based on the WID type the specific pack format is used. To frame register, WID_REGISTER_FRAME(0x3085) WID value is used and it's of byte-string type. So the packed struct value is transmitted as an array of u8 data. IMO there is no endianness issue provided firmware extracts members information in the correct structure order. Please resubmit the patch by changing 'frame_type' type to '__le16' in 'wilc_reg_frame' struct. Regards, Ajay
Re: [PATCH] ASoC: AMD: Add delay before starting to capture
On 1/4/2019 5:57 PM, Mark Brown wrote: > On Thu, Jan 03, 2019 at 10:18:13AM +, Agrawal, Akshu wrote: >> On capture through dmic we observe a glitch at the start of record. >> This is because we start capturing even before dmic is ready to send >> out data. The glitch seen last for ~20msec. >> > >> +/* >> + * On some platforms, it takes ~20 msec for PDM DMICs and ADAU7002 >> + * to settle and start producing proper audio data. >> + */ >> +msleep(ADAU7002_DELAY_MS); > > If the delay is required for external components to start up the delay > should be going in the drivers for those components rather than in the > driver for the CPU side, that way other systems using those components > get the benefit and non-affected boards don't pay the cost. There's > already some support for this in the DMIC driver at least. > Agreed, we can use the similar to wakeup_delay in dmic driver in our codec driver. Will post the patch on same lines. Thanks, Akshu
[PATCH v4 1/2] xen/blkback: add stack variable 'blkif' in connect_ring()
As 'be->blkif' is used for many times in connect_ring(), the stack variable
'blkif' is added to substitute 'be-blkif'.
Suggested-by: Paul Durrant
Signed-off-by: Dongli Zhang
---
drivers/block/xen-blkback/xenbus.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index a4bc74e..a4aadac 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -1023,6 +1023,7 @@ static int read_per_ring_refs(struct xen_blkif_ring
*ring, const char *dir)
static int connect_ring(struct backend_info *be)
{
struct xenbus_device *dev = be->dev;
+ struct xen_blkif *blkif = be->blkif;
unsigned int pers_grants;
char protocol[64] = "";
int err, i;
@@ -1033,25 +1034,25 @@ static int connect_ring(struct backend_info *be)
pr_debug("%s %s\n", __func__, dev->otherend);
- be->blkif->blk_protocol = BLKIF_PROTOCOL_DEFAULT;
+ blkif->blk_protocol = BLKIF_PROTOCOL_DEFAULT;
err = xenbus_scanf(XBT_NIL, dev->otherend, "protocol",
"%63s", protocol);
if (err <= 0)
strcpy(protocol, "unspecified, assuming default");
else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_NATIVE))
- be->blkif->blk_protocol = BLKIF_PROTOCOL_NATIVE;
+ blkif->blk_protocol = BLKIF_PROTOCOL_NATIVE;
else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_X86_32))
- be->blkif->blk_protocol = BLKIF_PROTOCOL_X86_32;
+ blkif->blk_protocol = BLKIF_PROTOCOL_X86_32;
else if (0 == strcmp(protocol, XEN_IO_PROTO_ABI_X86_64))
- be->blkif->blk_protocol = BLKIF_PROTOCOL_X86_64;
+ blkif->blk_protocol = BLKIF_PROTOCOL_X86_64;
else {
xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
return -ENOSYS;
}
pers_grants = xenbus_read_unsigned(dev->otherend, "feature-persistent",
0);
- be->blkif->vbd.feature_gnt_persistent = pers_grants;
- be->blkif->vbd.overflow_max_grants = 0;
+ blkif->vbd.feature_gnt_persistent = pers_grants;
+ blkif->vbd.overflow_max_grants = 0;
/*
* Read the number of hardware queues from frontend.
@@ -1067,16 +1068,16 @@ static int connect_ring(struct backend_info *be)
requested_num_queues, xenblk_max_queues);
return -ENOSYS;
}
- be->blkif->nr_rings = requested_num_queues;
- if (xen_blkif_alloc_rings(be->blkif))
+ blkif->nr_rings = requested_num_queues;
+ if (xen_blkif_alloc_rings(blkif))
return -ENOMEM;
pr_info("%s: using %d queues, protocol %d (%s) %s\n", dev->nodename,
-be->blkif->nr_rings, be->blkif->blk_protocol, protocol,
+blkif->nr_rings, blkif->blk_protocol, protocol,
pers_grants ? "persistent grants" : "");
- if (be->blkif->nr_rings == 1)
- return read_per_ring_refs(&be->blkif->rings[0], dev->otherend);
+ if (blkif->nr_rings == 1)
+ return read_per_ring_refs(&blkif->rings[0], dev->otherend);
else {
xspathsize = strlen(dev->otherend) + xenstore_path_ext_size;
xspath = kmalloc(xspathsize, GFP_KERNEL);
@@ -1085,10 +1086,10 @@ static int connect_ring(struct backend_info *be)
return -ENOMEM;
}
- for (i = 0; i < be->blkif->nr_rings; i++) {
+ for (i = 0; i < blkif->nr_rings; i++) {
memset(xspath, 0, xspathsize);
snprintf(xspath, xspathsize, "%s/queue-%u",
dev->otherend, i);
- err = read_per_ring_refs(&be->blkif->rings[i], xspath);
+ err = read_per_ring_refs(&blkif->rings[i], xspath);
if (err) {
kfree(xspath);
return err;
--
2.7.4
[PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront
The xenstore 'ring-page-order' is used globally for each blkback queue and
therefore should be read from xenstore only once. However, it is obtained
in read_per_ring_refs() which might be called multiple times during the
initialization of each blkback queue.
If the blkfront is malicious and the 'ring-page-order' is set in different
value by blkfront every time before blkback reads it, this may end up at
the "WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));" in
xen_blkif_disconnect() when frontend is destroyed.
This patch reworks connect_ring() to read xenstore 'ring-page-order' only
once.
Signed-off-by: Dongli Zhang
---
Changed since v1:
* change the order of xenstore read in read_per_ring_refs
* use xenbus_read_unsigned() in connect_ring()
Changed since v2:
* simplify the condition check as "(err != 1 && nr_grefs > 1)"
* avoid setting err as -EINVAL to remove extra one line of code
Changed since v3:
* exit at the beginning if !nr_grefs
* change the if statements to avoid test (err != 1) twice
* initialize a 'blkif' stack variable (refer to PATCH 1/2)
drivers/block/xen-blkback/xenbus.c | 76 +-
1 file changed, 43 insertions(+), 33 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index a4aadac..a2acbc9 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -926,7 +926,7 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring,
const char *dir)
int err, i, j;
struct xen_blkif *blkif = ring->blkif;
struct xenbus_device *dev = blkif->be->dev;
- unsigned int ring_page_order, nr_grefs, evtchn;
+ unsigned int nr_grefs, evtchn;
err = xenbus_scanf(XBT_NIL, dir, "event-channel", "%u",
&evtchn);
@@ -936,43 +936,38 @@ static int read_per_ring_refs(struct xen_blkif_ring
*ring, const char *dir)
return err;
}
- err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u",
- &ring_page_order);
- if (err != 1) {
- err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u",
&ring_ref[0]);
+ nr_grefs = blkif->nr_ring_pages;
+
+ if (unlikely(!nr_grefs))
+ return -EINVAL;
+
+ for (i = 0; i < nr_grefs; i++) {
+ char ring_ref_name[RINGREF_NAME_LEN];
+
+ snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", i);
+ err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
+ "%u", &ring_ref[i]);
+
if (err != 1) {
- err = -EINVAL;
- xenbus_dev_fatal(dev, err, "reading %s/ring-ref", dir);
- return err;
- }
- nr_grefs = 1;
- } else {
- unsigned int i;
-
- if (ring_page_order > xen_blkif_max_ring_order) {
- err = -EINVAL;
- xenbus_dev_fatal(dev, err, "%s/request %d ring page
order exceed max:%d",
-dir, ring_page_order,
-xen_blkif_max_ring_order);
- return err;
+ if (nr_grefs == 1)
+ break;
+
+ xenbus_dev_fatal(dev, err, "reading %s/%s",
+dir, ring_ref_name);
+ return -EINVAL;
}
+ }
- nr_grefs = 1 << ring_page_order;
- for (i = 0; i < nr_grefs; i++) {
- char ring_ref_name[RINGREF_NAME_LEN];
-
- snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u",
i);
- err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
- "%u", &ring_ref[i]);
- if (err != 1) {
- err = -EINVAL;
- xenbus_dev_fatal(dev, err, "reading %s/%s",
-dir, ring_ref_name);
- return err;
- }
+ if (err != 1) {
+ WARN_ON(nr_grefs != 1);
+
+ err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u",
+ &ring_ref[0]);
+ if (err != 1) {
+ xenbus_dev_fatal(dev, err, "reading %s/ring-ref", dir);
+ return -EINVAL;
}
}
- blkif->nr_ring_pages = nr_grefs;
for (i = 0; i < nr_grefs * XEN_BLKIF_REQS_PER_PAGE; i++) {
req = kzalloc(sizeof(*req), GFP_KERNEL);
@@ -1031,6 +1026,7 @@ static int connect_ring(struct backend_info *be)
size_t xspathsize;
const size_t xenstore_path_ext_size = 11; /* sufficient for
"/queue-NNN" */
unsigned int requested_num_qu
Re: [PATCH v2] nvme-pci: fix dbbuf_sq_db point to freed memory
Thanks for replying to my email, my description in the last email was not clear enough, so here's a supplementary note. The NVME device I used support DBBUF, but the nvme_admin_dbbuf request returned a failure that eventually led to the kernel crash. The problem occurs as follows: 1, Device support NVME_CTRL_OACS_DBBUF_SUPP，so reset worker alloc memory for dev->dbbuf_dbs。 2, In nvme_setup_io_queues process, the nvme_dbbuf_init function is called to assign values to pointers such as nvmeq->dbbuf_sq_db. 3, In nvme_dev_add function, the nvme_admin_dbbuf request is sent to the device, but the device returns failed, so the memory that dev->dbbuf_dbs points to is released. Then, the driver issued IO requests, in the nvme_write_sq_db process, nvme_dbbuf_update_and_check_event function judgment to Nvmeq->dbbuf_sq_db pointer is not NULL, write to the memory it points to, causing memory confusion and kernel crash. On 2019/1/5 2:07, Christoph Hellwig wrote: > On Fri, Dec 21, 2018 at 01:07:25AM +, Lulina (A) wrote: >> The case is that nvme device support NVME_CTRL_OACS_DBBUF_SUPP, and >> return failed when the driver sent nvme_admin_dbbuf. The nvmeq->dbbuf_sq_db >> point to freed memory, as nvme_dbbuf_set is called after nvme_dbbuf_init. > > But we never use those pointers in that state, do we? Can you explain > the problem in a little more detail? > >
Re: [PATCH 6/11] KVM/MMU: Flush tlb with range list in sync_page()
On Sat, Jan 5, 2019 at 12:30 AM Sean Christopherson
wrote:
>
> On Fri, Jan 04, 2019 at 04:54:00PM +0800, lantianyu1...@gmail.com wrote:
> > From: Lan Tianyu
> >
> > This patch is to flush tlb via flush list function.
>
> More explanation of why this is beneficial would be nice. Without the
> context of the overall series it's not immediately obvious what
> kvm_flush_remote_tlbs_with_list() does without a bit of digging.
>
> >
> > Signed-off-by: Lan Tianyu
> > ---
> > arch/x86/kvm/paging_tmpl.h | 16 ++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
> > index 833e8855bbc9..866ccdea762e 100644
> > --- a/arch/x86/kvm/paging_tmpl.h
> > +++ b/arch/x86/kvm/paging_tmpl.h
> > @@ -973,6 +973,7 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu,
> > struct kvm_mmu_page *sp)
> > bool host_writable;
> > gpa_t first_pte_gpa;
> > int set_spte_ret = 0;
> > + LIST_HEAD(flush_list);
> >
> > /* direct kvm_mmu_page can not be unsync. */
> > BUG_ON(sp->role.direct);
> > @@ -980,6 +981,7 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu,
> > struct kvm_mmu_page *sp)
> > first_pte_gpa = FNAME(get_level1_sp_gpa)(sp);
> >
> > for (i = 0; i < PT64_ENT_PER_PAGE; i++) {
> > + int tmp_spte_ret = 0;
> > unsigned pte_access;
> > pt_element_t gpte;
> > gpa_t pte_gpa;
> > @@ -1029,14 +1031,24 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu,
> > struct kvm_mmu_page *sp)
> >
> > host_writable = sp->spt[i] & SPTE_HOST_WRITEABLE;
> >
> > - set_spte_ret |= set_spte(vcpu, &sp->spt[i],
> > + tmp_spte_ret = set_spte(vcpu, &sp->spt[i],
> >pte_access, PT_PAGE_TABLE_LEVEL,
> >gfn, spte_to_pfn(sp->spt[i]),
> >true, false, host_writable);
> > +
> > + if (kvm_available_flush_tlb_with_range()
> > + && (tmp_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)) {
> > + struct kvm_mmu_page *leaf_sp = page_header(sp->spt[i]
> > + & PT64_BASE_ADDR_MASK);
> > + list_add(&leaf_sp->flush_link, &flush_list);
> > + }
> > +
> > + set_spte_ret |= tmp_spte_ret;
> > +
> > }
> >
> > if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)
> > - kvm_flush_remote_tlbs(vcpu->kvm);
> > + kvm_flush_remote_tlbs_with_list(vcpu->kvm, &flush_list);
>
> This is a bit confusing and potentially fragile. It's not obvious that
> kvm_flush_remote_tlbs_with_list() is guaranteed to call
> kvm_flush_remote_tlbs() when kvm_available_flush_tlb_with_range() is
> false, and you're relying on the kvm_flush_remote_tlbs_with_list() call
> chain to never optimize away the empty list case. Rechecking
> kvm_available_flush_tlb_with_range() isn't expensive.
That makes sense. Will update. Thanks.
>
> >
> > return nr_present;
> > }
> > --
> > 2.14.4
> >
--
Best regards
Tianyu Lan
Re: [PATCH 1/2 v8] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED'
在 2018年12月07日 04:11, Borislav Petkov 写道: > On Fri, Nov 30, 2018 at 03:04:44PM +0800, lijiang wrote: >> I have noticed the changes on x86, but for IA64, i'm not sure whether it >> should do the same >> thing, so keep it as before. >> >> If IA64 people would like to give any comment, that will be appreciated. > > I think you should not touch ia64 and not make Tony unnecessarily power > up the old rust. > Ok, i will get rid of previous changes to IA64 in next post. Thanks. > :-) >
linux-next: stats (was: Linux 5.0-rc1)
Hi all, As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20181224 was the last linux-next before the merge window opened.) Commits in v5.0-rc1 (relative to v4.20): 10843 Commits in next-20181224: 10867 Commits with the same SHA1:10044 Commits with the same patch_id: 301 (1) Commits with the same subject line: 52 (1) (1) not counting those in the lines above. So commits in -rc1 that were in next-20181224: 10397 95% Some breakdown of the list of extra commits (relative to next-20181224) in -rc1: Top ten first word of commit summary: 49 drm 26 cifs 24 perf 19 net 16 um 16 thermal 16 dt-bindings 16 csky 11 arm64 9 pci Top ten authors: 20 yamada.masah...@socionext.com 15 ren_...@c-sky.com 12 torva...@linux-foundation.org 12 palcant...@suse.de 11 anton.iva...@cambridgegreys.com 11 a...@redhat.com 10 v...@virtuozzo.com 10 h...@lst.de 9 julia.law...@lip6.fr 9 dan...@iogearbox.net Top ten commiters: 51 da...@davemloft.net 46 alexander.deuc...@amd.com 29 a...@redhat.com 28 stfre...@microsoft.com 23 torva...@linux-foundation.org 22 edubez...@gmail.com 19 yamada.masah...@socionext.com 19 ren_...@c-sky.com 17 rich...@nod.at 14 ax...@kernel.dk There are also 470 commits in next-20181224 that didn't make it into v5.0-rc1. Top ten first word of commit summary: 43 asoc 37 mm 23 mfd 23 arm 19 vfs 18 leaking_addresses 15 xtensa 13 nios2 11 nfc 11 dt-bindings Top ten authors: 34 dhowe...@redhat.com 32 a...@linux-foundation.org 18 m...@tobin.cc 17 kuninori.morimoto...@renesas.com 13 o...@lixom.net 13 jcmvb...@gmail.com 13 ebigg...@google.com 11 npig...@gmail.com 10 da...@redhat.com 9 dan.carpen...@oracle.com Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 125 s...@canb.auug.org.au 45 broo...@kernel.org 36 dhowe...@redhat.com 26 lee.jo...@linaro.org 25 ty...@mit.edu 18 m...@tobin.cc 16 jcmvb...@gmail.com 13 p.za...@pengutronix.de 13 o...@lixom.net 13 ley.foon@intel.com Those commits by me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwell pgpqPiz2xBT5J.pgp Description: OpenPGP digital signature
Re: [PATCH v6] arm64: implement ftrace with regs
On Fri, Jan 4, 2019 at 8:05 PM Torsten Duwe wrote: > > Use -fpatchable-function-entry (gcc8) to add 2 NOPs at the beginning > of each function. Replace the first NOP thus generated with a quick LR > saver (move it to scratch reg x9), so the 2nd replacement insn, the call > to ftrace, does not clobber the value. Ftrace will then generate the > standard stack frames. > > Note that patchable-function-entry in GCC disables IPA-RA, which means > ABI register calling conventions are obeyed *and* scratch registers > such as x9 are available. > > Introduce and handle an ftrace_regs_trampoline for module PLTs, right > after ftrace_trampoline, and double the size of this special section. > > Signed-off-by: Torsten Duwe > > --- > > This patch applies on 4.20 with the additional changes > bdb85cd1d20669dfae813555dddb745ad09323ba > (arm64/module: switch to ADRP/ADD sequences for PLT entries) > and > 7dc48bf96aa0fc8aa5b38cc3e5c36ac03171e680 > (arm64: ftrace: always pass instrumented pc in x0) > along with their respective series, or alternatively on Linus' master, > which already has these. > > changes since v5: > > * fix mentioned pc in x0 to hold the start address of the call site, > not the return address or the branch address. > This resolves the problem found by Amit. Function graph tracer display works fine with this version. From my side, Tested by: Amit Daniel Kachhap // Amit > > --- > arch/arm64/Kconfig|2 > arch/arm64/Makefile |4 + > arch/arm64/include/asm/assembler.h|1 > arch/arm64/include/asm/ftrace.h | 13 +++ > arch/arm64/include/asm/module.h |3 > arch/arm64/kernel/Makefile|6 - > arch/arm64/kernel/entry-ftrace.S | 131 > ++ > arch/arm64/kernel/ftrace.c| 125 > arch/arm64/kernel/module-plts.c |3 > arch/arm64/kernel/module.c|2 > drivers/firmware/efi/libstub/Makefile |3 > include/asm-generic/vmlinux.lds.h |1 > include/linux/compiler_types.h|4 + > 13 files changed, 262 insertions(+), 36 deletions(-) > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -131,6 +131,8 @@ config ARM64 > select HAVE_DEBUG_KMEMLEAK > select HAVE_DMA_CONTIGUOUS > select HAVE_DYNAMIC_FTRACE > + select HAVE_DYNAMIC_FTRACE_WITH_REGS \ > + if $(cc-option,-fpatchable-function-entry=2) > select HAVE_EFFICIENT_UNALIGNED_ACCESS > select HAVE_FTRACE_MCOUNT_RECORD > select HAVE_FUNCTION_TRACER > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -79,6 +79,10 @@ ifeq ($(CONFIG_ARM64_MODULE_PLTS),y) > KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds > endif > > +ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y) > + CC_FLAGS_FTRACE := -fpatchable-function-entry=2 > +endif > + > # Default value > head-y := arch/arm64/kernel/head.o > > --- a/arch/arm64/include/asm/ftrace.h > +++ b/arch/arm64/include/asm/ftrace.h > @@ -17,6 +17,19 @@ > #define MCOUNT_ADDR((unsigned long)_mcount) > #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE > > +/* > + * DYNAMIC_FTRACE_WITH_REGS is implemented by adding 2 NOPs at the beginning > + * of each function, with the second NOP actually calling ftrace. In contrary > + * to a classic _mcount call, the call instruction to be modified is thus > + * the second one, and not the only one. > + */ > +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS > +#define ARCH_SUPPORTS_FTRACE_OPS 1 > +#define REC_IP_BRANCH_OFFSET AARCH64_INSN_SIZE > +#else > +#define REC_IP_BRANCH_OFFSET 0 > +#endif > + > #ifndef __ASSEMBLY__ > #include > > --- a/arch/arm64/kernel/Makefile > +++ b/arch/arm64/kernel/Makefile > @@ -7,9 +7,9 @@ CPPFLAGS_vmlinux.lds:= -DTEXT_OFFSET=$( > AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) > CFLAGS_armv8_deprecated.o := -I$(src) > > -CFLAGS_REMOVE_ftrace.o = -pg > -CFLAGS_REMOVE_insn.o = -pg > -CFLAGS_REMOVE_return_address.o = -pg > +CFLAGS_REMOVE_ftrace.o = -pg $(CC_FLAGS_FTRACE) > +CFLAGS_REMOVE_insn.o = -pg $(CC_FLAGS_FTRACE) > +CFLAGS_REMOVE_return_address.o = -pg $(CC_FLAGS_FTRACE) > > # Object file lists. > arm64-obj-y:= debug-monitors.o entry.o irq.o fpsimd.o > \ > --- a/drivers/firmware/efi/libstub/Makefile > +++ b/drivers/firmware/efi/libstub/Makefile > @@ -13,7 +13,8 @@ cflags-$(CONFIG_X86) += -m$(BITS) -D__K > > # arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly > # disable the stackleak plugin > -cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie \ > +cflags-$(CONFIG_ARM64) := $(filter-out -pg $(CC_FLAGS_FTRACE)\ > + ,$(KBUILD_CFLAGS)) -fpie \ >$(DISABLE_STACKLEAK_PLUGIN) > cflags-$(CONFIG_ARM) := $(subst -pg,,$(KBUILD_CFLAGS)) \ >-fno-builtin -
ERROR: "ieee80211_hdrlen" [drivers/net/wireless/intel/iwlwifi/iwlwifi.ko] undefined!
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 574823bfab82d9d8fa47f422778043fbb4b4f50e commit: aca432f06b8a60a92b27fb46e6518a19b28ca93f iwlwifi: make MVM and DVM depend on MAC80211 date: 3 weeks ago config: x86_64-randconfig-i1-01061720 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout aca432f06b8a60a92b27fb46e6518a19b28ca93f # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> ERROR: "ieee80211_hdrlen" [drivers/net/wireless/intel/iwlwifi/iwlwifi.ko] >> undefined! >> ERROR: "ieee80211_channel_to_frequency" >> [drivers/net/wireless/intel/iwlwifi/iwlwifi.ko] undefined! >> ERROR: "reg_query_regdb_wmm" [drivers/net/wireless/intel/iwlwifi/iwlwifi.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v8 24/25] powerpc: Adopt nvram module for PPC64
On Mon, 7 Jan 2019, Michael Ellerman wrote:
> Arnd Bergmann writes:
> > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
> > wrote:
> >
> >> +static ssize_t ppc_nvram_get_size(void)
> >> +{
> >> + if (ppc_md.nvram_size)
> >> + return ppc_md.nvram_size();
> >> + return -ENODEV;
> >> +}
> >
> >> +const struct nvram_ops arch_nvram_ops = {
> >> + .read = ppc_nvram_read,
> >> + .write = ppc_nvram_write,
> >> + .get_size = ppc_nvram_get_size,
> >> + .sync = ppc_nvram_sync,
> >> +};
> >
> > Coming back to this after my comment on the m68k side, I notice that
> > there is now a double indirection through function pointers. Have you
> > considered completely removing the operations from ppc_md instead
> > by having multiple copies of nvram_ops?
> >
> > With the current method, it does seem odd to have a single
> > per-architecture instance of the exported structure containing
> > function pointers. This doesn't give us the flexibility of having
> > multiple copies in the kernel the way that ppc_md does, but it adds
> > overhead compared to simply exporting the functions directly.
>
> Yeah TBH I'm not convinced the arch ops is the best solution.
>
> Why can't each arch just implement the required ops functions? On ppc
> we'd still use ppc_md but that would be a ppc detail.
>
> Optional ops are fairly easy to support by providing a default
> implementation, eg. instead of:
>
> + if (arch_nvram_ops.get_size == NULL)
> + return -ENODEV;
> +
> + nvram_size = arch_nvram_ops.get_size();
> + if (nvram_size < 0)
> + return nvram_size;
>
>
> We do in some header:
>
> #ifndef arch_nvram_get_size
> static inline int arch_nvram_get_size(void)
> {
> return -ENODEV;
> }
> #endif
>
> And then:
>
> nvram_size = arch_nvram_get_size();
> if (nvram_size < 0)
> return nvram_size;
>
>
> But I haven't digested the whole series so maybe I'm missing something?
>
The reason why that doesn't work boils down to introspection. (This was
mentioned elsewhere in this email thread.) For example, we presently have
code like this,
ssize_t nvram_get_size(void)
{
if (ppc_md.nvram_size)
return ppc_md.nvram_size();
return -1;
}
EXPORT_SYMBOL(nvram_get_size);
This construction means we get to decide at run-time which of the NVRAM
functions should be used. (Whereas your example makes a build-time decision.)
The purpose of arch_nvram_ops is much the same. That is, it does for m68k
and x86 what ppc_md already does for ppc32 and ppc64. (And once these
platforms share an API like this, they can share more driver code, and
reduce duplicated code.)
The approach taken in this series was to push the arch_nvram_ops approach
as far as possible, because by making everything fit into that regime it
immediately became apparent where architectures and platforms have
diverged, creating weird inconsistencies like the differences in sync
ioctl behaviour between ppc32 and ppc64 for core99. (Early revisions of
this series exposed more issues like bugs and dead code that got addressed
elsewhere.)
Problem is, as Arnd pointed out, powerpc doesn't need both kinds of ops
struct. So I'm rewriting this series in such a way that powerpc doesn't
have to implement both. This rewrite is going to look totally different
for powerpc (though not for x86 or m68k) so you might want to wait for me
to post v9 before spending more time on code review.
Thanks.
--
> cheers
>
Re: [PATCH v6 1/3] dt-bindings: thermal: Add binding document for SR thermal
Hi Rob, Thank you for the note. I will take care from next time onward. Thanks & Regards, Srinath. On Thu, Jan 3, 2019 at 10:31 PM Rob Herring wrote: > > On Thu, 3 Jan 2019 14:25:32 +0530, Srinath Mannam wrote: > > From: Pramod Kumar > > > > Add binding document for supported thermal implementation > > in Stingray. > > > > Signed-off-by: Pramod Kumar > > Signed-off-by: Srinath Mannam > > Reviewed-by: Ray Jui > > Reviewed-by: Scott Branden > > --- > > .../bindings/thermal/brcm,sr-thermal.txt | 105 > > + > > 1 file changed, 105 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed.
Re: [GIT PULL 2/4] Kbuild updates for v4.21 part2
(+CC Changbin Du, Arnd Bergmann) On Sun, Dec 30, 2018 at 6:01 AM Linus Torvalds wrote: > > On Fri, Dec 28, 2018 at 8:00 AM Masahiro Yamada > wrote: > > > > Introduce a new option CONFIG_NO_AUTO_INLINE as well. With this option, > > only functions explicitly marked with "inline" will be inlined. This > > will allow the function tracer to trace more functions. > > Ugh. This causes new and bogus warnings, because gcc doesn't see some > of the checks. > > For example, the x86 emulate_vsyscall() function now warns that > > warning: ‘syscall_nr’ may be used uninitialized in this function > > because addr_to_vsyscall_nr() isn't inlined any more, so gcc doesn't > see that the return value is always smaller than three (and then it > doesn't see that we handle all the cases in the switch statement > later). > > So honestly, these "debugging improvements" have a rather nasty side > effect. I'm not at all convinced that we should do this. It is *not* > worth causing extra development pain with a totally pointless option > that changes code generation radically like this. It's going to cause > lots of extra churn. Sorry for late reply. I know this series was rejected, but I felt guilty about being completely silent. So, here is just my two cents. For addr_to_vsyscall_nr(), we can fix it by marking it as 'inline' (or __always_inline). IMHO, it is not so bad to tell the compiler what we want. In most cases, it is just a matter of 'inline' marker, although I admit this process is kind of painful... > This branch already added a couple of extra inline markers just to > make code work reasonably. How many tens (or hundreds) got missed just > because the build still works, but the lack of inlining means that we > generate completely garbage code? I do not have the exact number, but my impression was "not so many". Changbin and Arnd might have better insight. They were trying to eliminate potential problems beforehand. For example, 7e17916b 412dd15c 08813e0e > I'm going to skip this pull request. > > We have basically always required a certain level of competence from > the compiler, and this basically says that the compiler can do stupid > things and we'd have to fix those stupidities by hand. > > Linus -- Best Regards Masahiro Yamada
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
Linus Torvalds wrote on Sat, Jan 05, 2019: > But I think my patch to just rip out all that page lookup, and just > base it on the page table state has the fundamental advantage that it > gets rid of code. Maybe I should jst commit it, and see if anything > breaks? We do have options in case things break, and then we'd at > least know who cares (and perhaps a lot more information of _why_ they > care). There actually are many tools like fincore which depend on mincore to try to tell whether a file is "loaded in cache" or not (I personally use vmtouch[1], but I know of at least nocache[2] uses it as well to only try to evict used pages) [1] https://hoytech.com/vmtouch/ [2] https://github.com/Feh/nocache I mostly use these to either fadvise(POSIX_FADV_DONTNEED) or prefetch/lock whole files so my "production" use-cases don't actually rely on the mincore part of them; but when playing with these actions it's actually fairly useful to be able to visualize which part of a file ended in cache or monitor how a file's content evolve in cache... There are various non-obvious behaviours where being able to poke around is enlightening (e.g. fadvise dontneed is actually a hint, so even if nothing uses the file linux sometimes keep the data around if it thinks that would be useful and nocache has a mode to call fadvise multiple times and things like that...) Anyway, I agree the use of mincore for this is rather ugly, and frankly some "cache management API" might be better in the long run if only for performance reason (don't try these tools on a hundred TB sparse file...), but until that pipe dream comes true I think mincore as it was is useful for system admins. Linus Torvalds wrote on Sun, Jan 06, 2019: > I decided to just apply that patch. It is *not* marked for stable, > very intentionally, because I expect that we will need to wait and see > if there are issues with it, and whether we might have to do something > entirely different (more like the traditional behavior with some extra > "only for owner" logic). FWIW I personally don't care much about "only for owner" or depending on mmap options; I don't understand much of the security implications honestly so I'm not sure how these limitations actually help. On the other hand, a simple CAP_SYS_ADMIN check making the call take either behaviour should be safe and would cover what I described above. (by the way, while we are discussing permissions, a regular user can use fadvise dontneed on files it doesn't own as well as long as it can open them for reading; I'm not sure if that would need restricting as well in the context of the security issue. Frankly even with mincore someone could likely tell the difference through timing, if they just do it a few times. Do magic, probe, flush out, repeat until satisfied.) Thanks, -- Dominique Martinet | Asmadeus
Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency
On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
>
> On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
> > It's not uncommon to have two access two unrelated memory locations in a
> > specific order. At the moment one has to use a memory barrier for this.
> >
> > However, if the first access was a read and the second used an address
> > depending on the first one we would have a data dependency and no
> > barrier would be necessary.
> >
> > This adds a new interface: dependent_ptr_mb which does exactly this: it
> > returns a pointer with a data dependency on the supplied value.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > Documentation/memory-barriers.txt | 20
> > arch/alpha/include/asm/barrier.h | 1 +
> > include/asm-generic/barrier.h | 18 ++
> > include/linux/compiler.h | 4
> > 4 files changed, 43 insertions(+)
> >
> > diff --git a/Documentation/memory-barriers.txt
> > b/Documentation/memory-barriers.txt
> > index c1d913944ad8..9dbaa2e1dbf6 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -691,6 +691,18 @@ case what's actually required is:
> > p = READ_ONCE(b);
> > }
> > +Alternatively, a control dependency can be converted to a data dependency,
> > +e.g.:
> > +
> > + q = READ_ONCE(a);
> > + if (q) {
> > + b = dependent_ptr_mb(b, q);
> > + p = READ_ONCE(b);
> > + }
> > +
> > +Note how the result of dependent_ptr_mb must be used with the following
> > +accesses in order to have an effect.
> > +
> > However, stores are not speculated. This means that ordering -is-
> > provided
> > for load-store control dependencies, as in the following example:
> > @@ -836,6 +848,12 @@ out-guess your code. More generally, although
> > READ_ONCE() does force
> > the compiler to actually emit code for a given load, it does not force
> > the compiler to use the results.
> > +Converting to a data dependency helps with this too:
> > +
> > + q = READ_ONCE(a);
> > + b = dependent_ptr_mb(b, q);
> > + WRITE_ONCE(b, 1);
> > +
> > In addition, control dependencies apply only to the then-clause and
> > else-clause of the if-statement in question. In particular, it does
> > not necessarily apply to code following the if-statement:
> > @@ -875,6 +893,8 @@ to the CPU containing it. See the section on
> > "Multicopy atomicity"
> > for more information.
> > +
> > +
> > In summary:
> > (*) Control dependencies can order prior loads against later stores.
> > diff --git a/arch/alpha/include/asm/barrier.h
> > b/arch/alpha/include/asm/barrier.h
> > index 92ec486a4f9e..b4934e8c551b 100644
> > --- a/arch/alpha/include/asm/barrier.h
> > +++ b/arch/alpha/include/asm/barrier.h
> > @@ -59,6 +59,7 @@
> >* as Alpha, "y" could be set to 3 and "x" to 0. Use rmb()
> >* in cases like this where there are no data dependencies.
> >*/
> > +#define ARCH_NEEDS_READ_BARRIER_DEPENDS 1
> > #define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
> > #ifdef CONFIG_SMP
> > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> > index 2cafdbb9ae4c..fa2e2ef72b68 100644
> > --- a/include/asm-generic/barrier.h
> > +++ b/include/asm-generic/barrier.h
> > @@ -70,6 +70,24 @@
> > #define __smp_read_barrier_depends() read_barrier_depends()
> > #endif
> > +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \
> > + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS)
> > +
> > +#define dependent_ptr_mb(ptr, val) ({
> > \
> > + long dependent_ptr_mb_val = (long)(val);\
> > + long dependent_ptr_mb_ptr = (long)(ptr) - dependent_ptr_mb_val; \
> > + \
> > + BUILD_BUG_ON(sizeof(val) > sizeof(long)); \
> > + OPTIMIZER_HIDE_VAR(dependent_ptr_mb_val); \
> > + (typeof(ptr))(dependent_ptr_mb_ptr + dependent_ptr_mb_val); \
> > +})
> > +
> > +#else
> > +
> > +#define dependent_ptr_mb(ptr, val) ({ mb(); (ptr); })
>
>
> So for the example of patch 4, we'd better fall back to rmb() or need a
> dependent_ptr_rmb()?
>
> Thanks
You mean for strongly ordered architectures like Intel?
Yes, maybe it makes sense to have dependent_ptr_smp_rmb,
dependent_ptr_dma_rmb and dependent_ptr_virt_rmb.
mb variant is unused right now so I'll remove it.
>
> > +
> > +#endif
> > +
> > #ifdef CONFIG_SMP
> > #ifndef smp_mb
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 6601d39e8c48..f599c30f1b28 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -152,9 +152,13 @@ void ftrace_likely_update(struct ftrace_likely_data
> > *f, int val,
> > #endif
> > #ifndef OPTIMIZER_HIDE_VAR
> > +
> > /* Make the optimizer believe the variable can be manipulated
> > arbitrarily. */
> > #define OPTI
Re: [RFC PATCH V3 0/5] Hi:
On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote: > > On 2019/1/7 上午11:28, Michael S. Tsirkin wrote: > > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: > > > On 2019/1/3 上午4:47, Michael S. Tsirkin wrote: > > > > On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: > > > > > This series tries to access virtqueue metadata through kernel virtual > > > > > address instead of copy_user() friends since they had too much > > > > > overheads like checks, spec barriers or even hardware feature > > > > > toggling. > > > > Will review, thanks! > > > > One questions that comes to mind is whether it's all about bypassing > > > > stac/clac. Could you please include a performance comparison with > > > > nosmap? > > > > > > > On machine without SMAP (Sandy Bridge): > > > > > > Before: 4.8Mpps > > > > > > After: 5.2Mpps > > OK so would you say it's really unsafe versus safe accesses? > > Or would you say it's just a better written code? > > > It's the effect of removing speculation barrier. You mean __uaccess_begin_nospec introduced by commit 304ec1b050310548db33063e567123fae8fd0301 ? So fundamentally we do access_ok checks when supplying the memory table to the kernel thread, and we should do the spec barrier there. Then we can just create and use a variant of uaccess macros that does not include the barrier? Or, how about moving the barrier into access_ok? This way repeated accesses with a single access_ok get a bit faster. CC Dan Williams on this idea. > > > > > > On machine with SMAP (Broadwell): > > > > > > Before: 5.0Mpps > > > > > > After: 6.1Mpps > > > > > > No smap: 7.5Mpps > > > > > > > > > Thanks > > > > no smap being before or after? > > > > Let me clarify: > > > Before (SMAP on): 5.0Mpps > > Before (SMAP off): 7.5Mpps > > After (SMAP on): 6.1Mpps > > > Thanks How about after + smap off? And maybe we want a module option just for the vhost thread to keep smap off generally since almost all it does is copy stuff from userspace into kernel anyway. Because what above numbers should is that we really really want a solution that isn't limited to just meta-data access, and I really do not see how any such solution can not also be used to make meta-data access fast. -- MST
Re: r8152: data corruption in various scenarios
On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>
>
>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>
>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
>>> PM, Mark Lord
>>> wrote:
>>> ..
> There is even now a special hack in the upstream r8152.c to attempt to
> detect
> a Dell TB16 dock and disable RX Aggregation in the driver to prevent such
> issues.
>
> Well.. I have a WD15 dock, not a TB16, and that same hack also catches my
> dock
> in its net:
>
> [5.794641] usb 4-1.2: Dell TB16 Dock, disable RX aggregation
The serial should be unique according to Dell.
> So one issue is that the code is not correctly identifying the dock,
> and the WD15 is claimed to be immune from the r8152 issues.
The WD15 I tested didn't use that serial number though...
>>>
>>> What info do you need from me about the WD15 so this can be corrected?
>>>
> xhci_hcd :39:00.0: ERROR Transfer event TRB DMA ptr not part of
> current TD ep_index 13
> comp_code 1
This is probably an xHC bug. A similar issue is fixed by commit
9da5a1092b13
("xhci: Bad Ethernet performance plugged in ASM1042A host”).
> I just got that exact message above, with the r8152 in my 1-day old WD15
> dock,
> with the TB16 "workaround" enabled in Linux kernel 4.20.0.
Is the xHC WD15 connected an ASMedia one?
>>>
>>> I don't know. I *think* it identifies as a DSL6340 (see below).
>>>
>>> Here is lspci and lsusb:
>>>
>>> $ lspci -vt
>>> -[:00]-+-00.0 Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor
>>> Host Bridge/DRAM Registers
>>> +-02.0 Intel Corporation UHD Graphics 620
>>> +-04.0 Intel Corporation Skylake Processor Thermal Subsystem
>>> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller
>>> +-14.2 Intel Corporation Sunrise Point-LP Thermal subsystem
>>> +-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C
>>> Controller #0
>>> +-15.1 Intel Corporation Sunrise Point-LP Serial IO I2C
>>> Controller #1
>>> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI #1
>>> +-1c.0-[01-39]00.0-[02-39]--+-00.0-[03]--
>>> | +-01.0-[04-38]--
>>> | \-02.0-[39]00.0 Intel
>>> Corporation DSL6340 USB 3.1
>>> Controller [Alpine Ridge]
>>> +-1c.4-[3a]00.0 Qualcomm Atheros QCA6174 802.11ac Wireless
>>> Network Adapter
>>> +-1d.0-[3b]00.0 Samsung Electronics Co Ltd Device a808
>>> +-1f.0 Intel Corporation Device 9d4e
>>> +-1f.2 Intel Corporation Sunrise Point-LP PMC
>>> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio
>>> \-1f.4 Intel Corporation Sunrise Point-LP SMBus
>>
>>
>> Mmm.. lspci -vt isn't as verbose as I thought, so here is plain lspci to
>> fill in the blanks:
>>
>> $ lspci
>> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core
>> Processor Host Bridge/DRAM
>> Registers (rev 08)
>> 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev
>> 07)
>>
>> 00:04.0 Signal processing controller: Intel Corporation Skylake Processor
>> Thermal Subsystem (rev 08)
>>
>> 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
>> Controller (rev 21)
>>
>> 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP
>> Thermal subsystem (rev 21)
>>
>> 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP
>> Serial IO I2C Controller #0
>> (rev 21)
>> 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP
>> Serial IO I2C Controller #1
>> (rev 21)
>> 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME
>> HECI #1 (rev 21)
>>
>> 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port
>> (rev f1)
>>
>> 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port
>> #5 (rev f1)
>>
>> 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port
>> #9 (rev f1)
>>
>> 00:1f.0 ISA bridge: Intel Corporation Device 9d4e (rev 21)
>>
>> 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
>>
>> 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
>>
>> 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
>>
>> 01:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
>> Ridge 2C 2015]
>>
>> 02:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
>> Ridge 2C 2015]
>>
>> 02:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
>> Ridge 2C 2015]
>>
>> 02:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
>> Ridge 2C 2015]
>>
>> 39:00.0 USB controller: Intel Corporation DSL6340 USB 3.1 Control
Re: r8152: data corruption in various scenarios
> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>
> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
>> Mark Lord
>> wrote:
>> ..
There is even now a special hack in the upstream r8152.c to attempt to
detect
a Dell TB16 dock and disable RX Aggregation in the driver to prevent such
issues.
Well.. I have a WD15 dock, not a TB16, and that same hack also catches my
dock
in its net:
[5.794641] usb 4-1.2: Dell TB16 Dock, disable RX aggregation
>>>
>>> The serial should be unique according to Dell.
>>>
So one issue is that the code is not correctly identifying the dock,
and the WD15 is claimed to be immune from the r8152 issues.
>>>
>>> The WD15 I tested didn't use that serial number though...
>>
>> What info do you need from me about the WD15 so this can be corrected?
>>
xhci_hcd :39:00.0: ERROR Transfer event TRB DMA ptr not part of
current TD ep_index 13
comp_code 1
>>>
>>> This is probably an xHC bug. A similar issue is fixed by commit 9da5a1092b13
>>> ("xhci: Bad Ethernet performance plugged in ASM1042A host”).
>>>
I just got that exact message above, with the r8152 in my 1-day old WD15
dock,
with the TB16 "workaround" enabled in Linux kernel 4.20.0.
>>>
>>> Is the xHC WD15 connected an ASMedia one?
>>
>> I don't know. I *think* it identifies as a DSL6340 (see below).
>>
>> Here is lspci and lsusb:
>>
>> $ lspci -vt
>> -[:00]-+-00.0 Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor
>> Host Bridge/DRAM Registers
>> +-02.0 Intel Corporation UHD Graphics 620
>> +-04.0 Intel Corporation Skylake Processor Thermal Subsystem
>> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller
>> +-14.2 Intel Corporation Sunrise Point-LP Thermal subsystem
>> +-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C
>> Controller #0
>> +-15.1 Intel Corporation Sunrise Point-LP Serial IO I2C
>> Controller #1
>> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI #1
>> +-1c.0-[01-39]00.0-[02-39]--+-00.0-[03]--
>> | +-01.0-[04-38]--
>> | \-02.0-[39]00.0 Intel
>> Corporation DSL6340 USB 3.1
>> Controller [Alpine Ridge]
>> +-1c.4-[3a]00.0 Qualcomm Atheros QCA6174 802.11ac Wireless
>> Network Adapter
>> +-1d.0-[3b]00.0 Samsung Electronics Co Ltd Device a808
>> +-1f.0 Intel Corporation Device 9d4e
>> +-1f.2 Intel Corporation Sunrise Point-LP PMC
>> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio
>> \-1f.4 Intel Corporation Sunrise Point-LP SMBus
>
>
> Mmm.. lspci -vt isn't as verbose as I thought, so here is plain lspci to fill
> in the blanks:
>
> $ lspci
> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor
> Host Bridge/DRAM
> Registers (rev 08)
> 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
>
> 00:04.0 Signal processing controller: Intel Corporation Skylake Processor
> Thermal Subsystem (rev 08)
>
> 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
> Controller (rev 21)
>
> 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP
> Thermal subsystem (rev 21)
>
> 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP
> Serial IO I2C Controller #0
> (rev 21)
> 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP
> Serial IO I2C Controller #1
> (rev 21)
> 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME
> HECI #1 (rev 21)
>
> 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port
> (rev f1)
>
> 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port
> #5 (rev f1)
>
> 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port
> #9 (rev f1)
>
> 00:1f.0 ISA bridge: Intel Corporation Device 9d4e (rev 21)
>
> 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
>
> 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
>
> 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
>
> 01:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
> Ridge 2C 2015]
>
> 02:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
> Ridge 2C 2015]
>
> 02:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
> Ridge 2C 2015]
>
> 02:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine
> Ridge 2C 2015]
>
> 39:00.0 USB controller: Intel Corporation DSL6340 USB 3.1 Controller [Alpine
> Ridge]
So it’s not an ASMedia one.
Before digging further, please make sure the system firmware (BIOS),
Thunderbolt controller NVM and W
linux-next: Tree for Jan 7
Hi all, Changes since 20190103: The vfs tree still had its build failure for which I applied a patch. The akpm-current tree gained a conflict against Linus' tree. The akpm tree lost several patches that turned up in Linus' tree. Non-merge commits (relative to Linus' tree): 473 523 files changed, 19075 insertions(+), 7565 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 293 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (574823bfab82 Change mincore() to count "mapped" pages rather than "cached" pages) Merging fixes/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/fixes (3fed6ae4b027 ia64: fix compile without swiotlb) Merging arc-current/for-curr (5fac3149be6f ARC: adjust memblock_reserve of kernel memory) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (3238c359acee arm64: dma-mapping: Fix FORCE_CONTIGUOUS buffer clearing) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (074400a7be61 powerpc: Drop use of 'type' from access_ok()) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (d4a7e9bb74b5 ipv6: Take rcu_read_lock in __inet6_bind for mapped addresses) Merging bpf/master (97274b612619 Merge branch 'reject-ptr-scalar-mix') Merging ipsec/master (3061169a47ee Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging netfilter/master (a007232066f6 netfilter: nf_conncount: fix argument order to find_next_bit) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53884577fbce ath10k: skip sending quiet mode cmd for WCN3990) Merging mac80211/master (1d51b4b1d3f2 Merge tag 'm68k-for-v4.20-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging rdma-fixes/for-rc (9c6260de505b infiniband/qedr: Potential null ptr dereference of qp) Merging sound-current/for-linus (3e9ad24b0e91 ALSA: hda - Revert DSP detection on legacy HD-audio driver) Merging sound-asoc-fixes/for-linus (19d8d182ea8a Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (8fe28cb58bcb Linux 4.20) Merging regulator-fixes/for-linus (c8c6b9fda37f Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (3cfb7c367d66 Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (1063a5148ac9 PCI/AER: Queue one GHES event, not several uninitialized ones) Merging driver-core.current/driver-core-linus (b5aef86e089a Merge tag 'docs-5.0-fixes' of git://git.lwn.net/linux) Merging tty.current/tty-linus (96d4f267e40f Remove 'type' argument from access_ok() function) Merging usb.current/usb-linus (96d4f267e40f Remove 'type' argument from access_ok() function) Merging usb-gadget-fixes/fixes (069caf5950df USB: omap_udc: fix rejection of out transfers when DMA is used) Merging usb-serial-fixes/usb-linus (28a86092b175 USB: serial: option: add Telit LN940 series)
Re: [PATCH RFC 1/2] virtio-net: bql support
On Mon, Jan 07, 2019 at 11:51:55AM +0800, Jason Wang wrote:
>
> On 2019/1/7 上午11:17, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 10:14:37AM +0800, Jason Wang wrote:
> > > On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
> > > > On Wed, Jan 02, 2019 at 11:28:43AM +0800, Jason Wang wrote:
> > > > > On 2018/12/31 上午2:45, Michael S. Tsirkin wrote:
> > > > > > On Thu, Dec 27, 2018 at 06:00:36PM +0800, Jason Wang wrote:
> > > > > > > On 2018/12/26 下午11:19, Michael S. Tsirkin wrote:
> > > > > > > > On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:
> > > > > > > > > On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:
> > > > > > > > > > When use_napi is set, let's enable BQLs. Note: some of the
> > > > > > > > > > issues are
> > > > > > > > > > similar to wifi. It's worth considering whether something
> > > > > > > > > > similar to
> > > > > > > > > > commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift")
> > > > > > > > > > might be
> > > > > > > > > > benefitial.
> > > > > > > > > I've played a similar patch several days before. The tricky
> > > > > > > > > part is the mode
> > > > > > > > > switching between napi and no napi. We should make sure when
> > > > > > > > > the packet is
> > > > > > > > > sent and trakced by BQL, it should be consumed by BQL as
> > > > > > > > > well. I did it by
> > > > > > > > > tracking it through skb->cb. And deal with the freeze by
> > > > > > > > > reset the BQL
> > > > > > > > > status. Patch attached.
> > > > > > > > >
> > > > > > > > > But when testing with vhost-net, I don't very a stable
> > > > > > > > > performance,
> > > > > > > > So how about increasing TSQ pacing shift then?
> > > > > > > I can test this. But changing default TCP value is much more than
> > > > > > > a
> > > > > > > virtio-net specific thing.
> > > > > > Well same logic as wifi applies. Unpredictable latencies related
> > > > > > to radio in one case, to host scheduler in the other.
> > > > > >
> > > > > > > > > it was
> > > > > > > > > probably because we batch the used ring updating so tx
> > > > > > > > > interrupt may come
> > > > > > > > > randomly. We probably need to implement time bounded
> > > > > > > > > coalescing mechanism
> > > > > > > > > which could be configured from userspace.
> > > > > > > > I don't think it's reasonable to expect userspace to be that
> > > > > > > > smart ...
> > > > > > > > Why do we need time bounded? used ring is always updated when
> > > > > > > > ring
> > > > > > > > becomes empty.
> > > > > > > We don't add used when means BQL may not see the consumed packet
> > > > > > > in time.
> > > > > > > And the delay varies based on the workload since we count packets
> > > > > > > not bytes
> > > > > > > or time before doing the batched updating.
> > > > > > >
> > > > > > > Thanks
> > > > > > Sorry I still don't get it.
> > > > > > When nothing is outstanding then we do update the used.
> > > > > > So if BQL stops userspace from sending packets then
> > > > > > we get an interrupt and packets start flowing again.
> > > > > Yes, but how about the cases of multiple flows. That's where I see
> > > > > unstable
> > > > > results.
> > > > >
> > > > >
> > > > > > It might be suboptimal, we might need to tune it but I doubt running
> > > > > > timers is a solution, timer interrupts cause VM exits.
> > > > > Probably not a timer but a time counter (or event byte counter) in
> > > > > vhost to
> > > > > add used and signal guest if it exceeds a value instead of waiting the
> > > > > number of packets.
> > > > >
> > > > >
> > > > > Thanks
> > > > Well we already have VHOST_NET_WEIGHT - is it too big then?
> > >
> > > I'm not sure, it might be too big.
> > >
> > >
> > > > And maybe we should expose the "MORE" flag in the descriptor -
> > > > do you think that will help?
> > > >
> > > I don't know. But how a "more" flag can help here?
> > >
> > > Thanks
> > It sounds like we should be a bit more aggressive in updating used ring.
> > But if we just do it naively we will harm performance for sure as that
> > is how we are doing batching right now.
>
>
> I agree but the problem is to balance the PPS and throughput. More batching
> helps for PPS but may damage TCP throughput.
That is what more flag is supposed to be I think - it is only set if
there's a socket that actually needs the skb freed in order to go on.
>
> > Instead we could make guest
> > control batching using the more flag - if that's not set we write out
> > the used ring.
>
>
> It's under the control of guest, so I'm afraid we still need some more guard
> (e.g time/bytes counters) on host.
>
> Thanks
Point is if guest does not care about the skb being freed, then there is no
rush host side to mark buffer used.
>
> >
Re: [PATCH v5 1/2] drm/amd: validate user pitch alignment
On Thu, Jan 03, 2019 at 05:33:19PM +0100, Michel Dänzer wrote:
> On 2018-12-30 2:00 a.m., Yu Zhao wrote:
> > Userspace may request pitch alignment that is not supported by GPU.
> > Some requests 32, but GPU ignores it and uses default 64 when cpp is
> > 4. If GEM object is allocated based on the smaller alignment, GPU
> > DMA will go out of bound.
> >
> > Cc: sta...@vger.kernel.org # v4.2+
> > Signed-off-by: Yu Zhao
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > index 15ce7e681d67..16af80ccd0a0 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > @@ -527,6 +527,22 @@ amdgpu_display_user_framebuffer_create(struct
> > drm_device *dev,
> > struct drm_gem_object *obj;
> > struct amdgpu_framebuffer *amdgpu_fb;
> > int ret;
> > + struct amdgpu_device *adev = dev->dev_private;
> > + int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
> > + int pitch = mode_cmd->pitches[0] / cpp;
> > +
> > + if (pitch < mode_cmd->width) {
> > + DRM_DEBUG_KMS("Expecting pitch(%d)/cpp(%d) >= width(%d)\n",
> > + mode_cmd->pitches[0], cpp, mode_cmd->width);
> > + return ERR_PTR(-EINVAL);
> > + }
>
> This should possibly be tested in drm_internal_framebuffer_create instead.
It seems to me drm_format_info_min_pitch() in framebuffer_check()
already does it. We could just remove the check here?
Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency
On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
It's not uncommon to have two access two unrelated memory locations in a
specific order. At the moment one has to use a memory barrier for this.
However, if the first access was a read and the second used an address
depending on the first one we would have a data dependency and no
barrier would be necessary.
This adds a new interface: dependent_ptr_mb which does exactly this: it
returns a pointer with a data dependency on the supplied value.
Signed-off-by: Michael S. Tsirkin
---
Documentation/memory-barriers.txt | 20
arch/alpha/include/asm/barrier.h | 1 +
include/asm-generic/barrier.h | 18 ++
include/linux/compiler.h | 4
4 files changed, 43 insertions(+)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index c1d913944ad8..9dbaa2e1dbf6 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -691,6 +691,18 @@ case what's actually required is:
p = READ_ONCE(b);
}
+Alternatively, a control dependency can be converted to a data dependency,
+e.g.:
+
+ q = READ_ONCE(a);
+ if (q) {
+ b = dependent_ptr_mb(b, q);
+ p = READ_ONCE(b);
+ }
+
+Note how the result of dependent_ptr_mb must be used with the following
+accesses in order to have an effect.
+
However, stores are not speculated. This means that ordering -is- provided
for load-store control dependencies, as in the following example:
@@ -836,6 +848,12 @@ out-guess your code. More generally, although READ_ONCE() does force
the compiler to actually emit code for a given load, it does not force
the compiler to use the results.
+Converting to a data dependency helps with this too:
+
+ q = READ_ONCE(a);
+ b = dependent_ptr_mb(b, q);
+ WRITE_ONCE(b, 1);
+
In addition, control dependencies apply only to the then-clause and
else-clause of the if-statement in question. In particular, it does
not necessarily apply to code following the if-statement:
@@ -875,6 +893,8 @@ to the CPU containing it. See the section on "Multicopy
atomicity"
for more information.
+
+
In summary:
(*) Control dependencies can order prior loads against later stores.
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index 92ec486a4f9e..b4934e8c551b 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -59,6 +59,7 @@
* as Alpha, "y" could be set to 3 and "x" to 0. Use rmb()
* in cases like this where there are no data dependencies.
*/
+#define ARCH_NEEDS_READ_BARRIER_DEPENDS 1
#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
#ifdef CONFIG_SMP
diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 2cafdbb9ae4c..fa2e2ef72b68 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -70,6 +70,24 @@
#define __smp_read_barrier_depends() read_barrier_depends()
#endif
+#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \
+ !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS)
+
+#define dependent_ptr_mb(ptr, val) ({ \
+ long dependent_ptr_mb_val = (long)(val);\
+ long dependent_ptr_mb_ptr = (long)(ptr) - dependent_ptr_mb_val; \
+ \
+ BUILD_BUG_ON(sizeof(val) > sizeof(long));\
+ OPTIMIZER_HIDE_VAR(dependent_ptr_mb_val); \
+ (typeof(ptr))(dependent_ptr_mb_ptr + dependent_ptr_mb_val); \
+})
+
+#else
+
+#define dependent_ptr_mb(ptr, val) ({ mb(); (ptr); })
So for the example of patch 4, we'd better fall back to rmb() or need a
dependent_ptr_rmb()?
Thanks
+
+#endif
+
#ifdef CONFIG_SMP
#ifndef smp_mb
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 6601d39e8c48..f599c30f1b28 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -152,9 +152,13 @@ void ftrace_likely_update(struct ftrace_likely_data *f,
int val,
#endif
#ifndef OPTIMIZER_HIDE_VAR
+
/* Make the optimizer believe the variable can be manipulated arbitrarily. */
#define OPTIMIZER_HIDE_VAR(var)
\
__asm__ ("" : "=rm" (var) : "0" (var))
+
+#define COMPILER_HAS_OPTIMIZER_HIDE_VAR 1
+
#endif
/* Not-quite-unique ID. */
Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls
On 12/12/18 8:51 PM, Paul Kocialkowski wrote:
Hi,
On Wed, 2018-12-05 at 21:59 +0100, Jernej Škrabec wrote:
+
+#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE 0x01
+#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER 0x02
+#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
+
+#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX 16
+
+struct v4l2_hevc_dpb_entry {
+ __u32 buffer_tag;
+ __u8rps;
+ __u8field_pic;
+ __u16 pic_order_cnt[2];
+};
Please add a property for reference index, if that rps is not used for
this, some device would request that(not the rockchip one). And
Rockchip's VDPU1 and VDPU2 for AVC would request a similar property.
Adding another buffer_tag for referring the memory of the motion vectors
for each frames. Or a better method is add a meta data to echo picture
buffer, since the picture output is just the same as the original,
display won't care whether the motion vectors are written the button of
picture or somewhere else.
+
+struct v4l2_hevc_pred_weight_table {
+ __u8luma_log2_weight_denom;
+ __s8delta_chroma_log2_weight_denom;
+
+ __s8delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+ __s8chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+
+ __s8delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __s8delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+ __s8chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
+};
+
Those properties I think are not necessary are applying for the
Rockchip's device, may not work for the others.
+struct v4l2_ctrl_hevc_slice_params {
+ __u32 bit_size;
+ __u32 data_bit_offset;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
+ __u8nal_unit_type;
+ __u8nuh_temporal_id_plus1;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
+ __u8slice_type;
+ __u8colour_plane_id;
+ __u16 slice_pic_order_cnt;
+ __u8slice_sao_luma_flag;
+ __u8slice_sao_chroma_flag;
+ __u8slice_temporal_mvp_enabled_flag;
+ __u8num_ref_idx_l0_active_minus1;
+ __u8num_ref_idx_l1_active_minus1;
Rockchip's decoder doesn't use this part.
+ __u8mvd_l1_zero_flag;
+ __u8cabac_init_flag;
+ __u8collocated_from_l0_flag;
+ __u8collocated_ref_idx;
+ __u8five_minus_max_num_merge_cand;
+ __u8use_integer_mv_flag;
+ __s8slice_qp_delta;
+ __s8slice_cb_qp_offset;
+ __s8slice_cr_qp_offset;
+ __s8slice_act_y_qp_offset;
+ __s8slice_act_cb_qp_offset;
+ __s8slice_act_cr_qp_offset;
+ __u8slice_deblocking_filter_disabled_flag;
+ __s8slice_beta_offset_div2;
+ __s8slice_tc_offset_div2;
+ __u8slice_loop_filter_across_slices_enabled_flag;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI message */
+ __u8pic_struct;
I think the decoder doesn't care about this, it is used for display.
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
+ struct v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __u8num_active_dpb_entries;
+ __u8ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+ __u8ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+
+ __u8num_rps_poc_st_curr_before;
+ __u8num_rps_poc_st_curr_after;
+ __u8num_rps_poc_lt_curr;
+
+ /* ISO/IEC 23008-2, ITU-T Rec. H.265: Weighted prediction parameter */
+ struct v4l2_hevc_pred_weight_table pred_weight_table;
+};
+
#endif
Re: [RFC PATCH V3 0/5] Hi:
On 2019/1/7 上午11:28, Michael S. Tsirkin wrote: On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: On 2019/1/3 上午4:47, Michael S. Tsirkin wrote: On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: This series tries to access virtqueue metadata through kernel virtual address instead of copy_user() friends since they had too much overheads like checks, spec barriers or even hardware feature toggling. Will review, thanks! One questions that comes to mind is whether it's all about bypassing stac/clac. Could you please include a performance comparison with nosmap? On machine without SMAP (Sandy Bridge): Before: 4.8Mpps After: 5.2Mpps OK so would you say it's really unsafe versus safe accesses? Or would you say it's just a better written code? It's the effect of removing speculation barrier. On machine with SMAP (Broadwell): Before: 5.0Mpps After: 6.1Mpps No smap: 7.5Mpps Thanks no smap being before or after? Let me clarify: Before (SMAP on): 5.0Mpps Before (SMAP off): 7.5Mpps After (SMAP on): 6.1Mpps Thanks
RE: r8152: data corruption in various scenarios
Monday, January 07, 2019 5:17 AM
[...]
>> This is probably an xHC bug. A similar issue is fixed by commit 9da5a1092b13
>> ("xhci: Bad Ethernet performance plugged in ASM1042A host”).
>>
>>> I just got that exact message above, with the r8152 in my 1-day old WD15
>>> dock,
>>> with the TB16 "workaround" enabled in Linux kernel 4.20.0.
>>
>> Is the xHC WD15 connected an ASMedia one?
>
> I don't know. I *think* it identifies as a DSL6340 (see below).
>
According to our record, it is relative to the asmedia.
Best Regards,
Hayes
Re: [PATCH RFC 1/2] virtio-net: bql support
On 2019/1/7 上午11:17, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 10:14:37AM +0800, Jason Wang wrote:
On 2019/1/2 下午9:59, Michael S. Tsirkin wrote:
On Wed, Jan 02, 2019 at 11:28:43AM +0800, Jason Wang wrote:
On 2018/12/31 上午2:45, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 06:00:36PM +0800, Jason Wang wrote:
On 2018/12/26 下午11:19, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:
On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:
When use_napi is set, let's enable BQLs. Note: some of the issues are
similar to wifi. It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.
I've played a similar patch several days before. The tricky part is the mode
switching between napi and no napi. We should make sure when the packet is
sent and trakced by BQL, it should be consumed by BQL as well. I did it by
tracking it through skb->cb. And deal with the freeze by reset the BQL
status. Patch attached.
But when testing with vhost-net, I don't very a stable performance,
So how about increasing TSQ pacing shift then?
I can test this. But changing default TCP value is much more than a
virtio-net specific thing.
Well same logic as wifi applies. Unpredictable latencies related
to radio in one case, to host scheduler in the other.
it was
probably because we batch the used ring updating so tx interrupt may come
randomly. We probably need to implement time bounded coalescing mechanism
which could be configured from userspace.
I don't think it's reasonable to expect userspace to be that smart ...
Why do we need time bounded? used ring is always updated when ring
becomes empty.
We don't add used when means BQL may not see the consumed packet in time.
And the delay varies based on the workload since we count packets not bytes
or time before doing the batched updating.
Thanks
Sorry I still don't get it.
When nothing is outstanding then we do update the used.
So if BQL stops userspace from sending packets then
we get an interrupt and packets start flowing again.
Yes, but how about the cases of multiple flows. That's where I see unstable
results.
It might be suboptimal, we might need to tune it but I doubt running
timers is a solution, timer interrupts cause VM exits.
Probably not a timer but a time counter (or event byte counter) in vhost to
add used and signal guest if it exceeds a value instead of waiting the
number of packets.
Thanks
Well we already have VHOST_NET_WEIGHT - is it too big then?
I'm not sure, it might be too big.
And maybe we should expose the "MORE" flag in the descriptor -
do you think that will help?
I don't know. But how a "more" flag can help here?
Thanks
It sounds like we should be a bit more aggressive in updating used ring.
But if we just do it naively we will harm performance for sure as that
is how we are doing batching right now.
I agree but the problem is to balance the PPS and throughput. More
batching helps for PPS but may damage TCP throughput.
Instead we could make guest
control batching using the more flag - if that's not set we write out
the used ring.
It's under the control of guest, so I'm afraid we still need some more
guard (e.g time/bytes counters) on host.
Thanks
Re: APIC timer checked before it is set up, boot fails on Connex L1430
On Fri, Dec 28, 2018 at 2:11 PM Daniel Drake wrote:
> On the Connex L1430 laptop based on Intel Apollo Lake N3350, Linux
> doesn't boot. It hangs early on a blank screen. Reproduced with Linus
> git, 4.18 and 4.19 (there is no previous known working kernel
> version). EFI earlyprintk shows:
>
> APIC: switch to symmetric I/O mode setup
> x2apic: IRQ remapping doesn't support X2APIC mode
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> ...tryign to set up timer (IRQ0) through the 8259A ...
> . (found apic 0 pin 2) ...
> ... failed.
> ...trying to set up timer as Virtual Wire IRQ...
> . failed.
> ...trying to set up timer as ExtINT IRQ...
> do_IRQ: 0.55 No irq handler for vector
> . failed :(.
> Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with
> apic=debug and send a report.
>
> Looking closer, check_timer() is observing that the IOAPIC timer
> doesn't tick, so it then tries some other approaches but doesn't
> manage to get them working either.
>
> The strange thing is, I booted with the no_timer_check parameter and
> the system works fine! With this parameter it assumes the IOAPIC timer
> is ticking and just continues the boot sequence anyway. Here is the
> boot log with apic=debug no_timer_check:
> https://gist.github.com/dsd/6f40d8ecc7102dd5dcb90c5dedc69214#file-dmesg-txt
>
> /proc/interrupts shows that APIC Local timer interrupts are working
> fine on both CPUs:
> https://gist.github.com/dsd/6f40d8ecc7102dd5dcb90c5dedc69214#file-interrupts-txt
>
> So, check_timer() is incorrectly deducing that the IOAPIC timer isn't
> working. The way it checks this is to do a delay loop and then check
> if jiffies has advanced. I presume the expectation here is that during
> this delay, the hardware IRQ will invoke local_apic_timer_interrupt()
> which will then increment jiffies. Indeed, during check_timer()
> execution this interrupt does not fire, however by using
> no_timer_check and adding a log message I can see that it fires for
> the first time quite some time after check_timer() is done:
>
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> clocksource: tsc-early: mask: 0x max_cycles:
> 0xfc66f4fc7c, max_idle_ns: 440795224246 ns
> Calibrating delay loop (skipped), value calculated using timer
> frequency.. 2188.80 BogoMIPS (lpj=1094400)
> pid_max: default: 32768 minimum: 301
> LSM: Security Framework initializing
> SELinux: Initializing.
> Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
> Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
> mce: CPU supports 7 MCE banks
> mce: CPU0: Thermal monitoring enabled (TM1)
> Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0
> Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
> Spectre V2 : Spectre mitigation: kernel not compiled with retpoline;
> no mitigation available!
> Freeing SMP alternatives memory: 44K
> TSC deadline timer enabled
> smpboot: CPU0: Intel(R) Celeron(R) CPU N3350 @ 1.10GHz (family: 0x6,
> model: 0x5c, stepping: 0x9)
> Performance Events: PEBS fmt3+, Goldmont events, 32-deep LBR,
> full-width counters, Intel PMU driver.
> ... version:4
> ... bit width: 48
> ... generic registers: 4
> ... value mask:
> ... max period: 7fff
> ... fixed-purpose events: 3
> ... event mask: 0007000f
> rcu: Hierarchical SRCU implementation.
> smp: Bringing up secondary CPUs ...
> !!! local_apic_timer_interrupt for the first time cpu0 !!!
>
> Experimenting further, I used the same approach of adding delays and
> checking for the interrupt during the delay to figure out at which
> precise point during the boot sequence the timer interrupt starts
> working. It's here:
>
> static void setup_APIC_timer(void)
> {
> [...]
> if (this_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER)) {
> [...]
> clockevents_config_and_register(levt,
> tsc_khz * (1000 / TSC_DIVISOR),
> 0xF, ~0UL);
> }
> }
>
> We reach clockevents_register_device() which does:
> 1. Take a spinlock and disable IRQs
> 2. lapic_set_oneshot() which leads to "TSC deadline timer enabled" message
> 3. lapic_next_deadline()
> 4. Spin unlock & re-enable IRQs
>
> At the exact point where IRQs are re-enabled above, which is at the
> time of return from clockevents_config_and_register(), timer
> interrupts start working.
>
>
> The overall ordering here seems surprising. check_timer() is probing
> whether the APIC timer works well before setup_APIC_timer() has been
> called. Shouldn't the timer be checked only after it has been set up?
>
> Or is Linux assuming that the BIOS will boot with the APIC timer
> already running?
Sorry for the rambling there - having in
Re: [PATCH net 1/4] umh: add exit routine for UMH process
On Mon, 7 Jan 2019 at 01:55, David Miller wrote: > > From: Taehee Yoo > Date: Sun, 6 Jan 2019 14:34:52 +0900 > > > How about adding a new PF_UMH flag for task_struct->flags to identify > > UMH process? > > By using this flag, the exit_umh() can avoid unnecessary lookups. > > Yes, that might be more efficient and eliminate the high cost for > non-UMH tasks. I will send a v3 patch. Thank you!
Re: [PATCH 11/11] KVM/MMU: Flush tlb in the kvm_age_rmapp()
Hi Sean:
Thanks for your review.
On Sat, Jan 5, 2019 at 12:12 AM Sean Christopherson
wrote:
>
> On Fri, Jan 04, 2019 at 04:54:05PM +0800, lantianyu1...@gmail.com wrote:
> > From: Lan Tianyu
> >
> > This patch is to flush tlb in the kvm_age_rmapp() when tlb range flush
> > is available and flush request is true.
> >
> > Signed-off-by: Lan Tianyu
> > ---
> > arch/x86/kvm/mmu.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index a5728f51bf7d..bc402a72956a 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -1958,10 +1958,17 @@ static int kvm_age_rmapp(struct kvm *kvm, struct
> > kvm_rmap_head *rmap_head,
> > u64 *sptep;
> > struct rmap_iterator uninitialized_var(iter);
> > int young = 0;
> > + bool flush = (bool)data;
> >
> > for_each_rmap_spte(rmap_head, &iter, sptep)
> > young |= mmu_spte_age(sptep);
> >
> > + if (young && flush) {
> > + kvm_flush_remote_tlbs_with_address(kvm, gfn,
> > + KVM_PAGES_PER_HPAGE(level));
> > + young = 0;
> > + }
> > +
>
> young shouldn't be cleared, the tracing will be wrong and the caller
> might actually care about the return value.
Yes, this is wrong and will update.
> I'm assuming you're
> clearing young to avoid the flush in kvm_mmu_notifier_clear_flush_young(),
> but keeping that flush is silly since it will never be invoked. Just
> squash this patch with patch 10/11 so that you can remove the unnecessary
> flush in kvm_mmu_notifier_clear_flush_young() and preserve young.
>
The platform may provide tlb flush with address range as granularity. My changes
are to use range flush when it's available. kvm_mmu_notifier_clear_flush_young()
is common function for all platforms and most platforms still need the
flush in the
kvm_mmu_notifier_clear_flush_young(). I think it's better to separate
flush request and
"young" from return value of kvm_age_hva(). New flush parameter I
added in the patch 10
can be changed to a pointer and kvm_age_hva() can use it to return
flush request.
--
Best regards
Tianyu Lan
[PATCH] kaslr: fix incorrect i8254 outb parameters
The outb call takes parameters value and port, in that order.
Fix the parameters used in the kalsr i8254 fallback code.
Signed-off-by: Daniel Drake
---
arch/x86/lib/kaslr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/kaslr.c b/arch/x86/lib/kaslr.c
index 79778ab200e4..a53665116458 100644
--- a/arch/x86/lib/kaslr.c
+++ b/arch/x86/lib/kaslr.c
@@ -36,8 +36,8 @@ static inline u16 i8254(void)
u16 status, timer;
do {
- outb(I8254_PORT_CONTROL,
-I8254_CMD_READBACK | I8254_SELECT_COUNTER0);
+ outb(I8254_CMD_READBACK | I8254_SELECT_COUNTER0,
+I8254_PORT_CONTROL);
status = inb(I8254_PORT_COUNTER0);
timer = inb(I8254_PORT_COUNTER0);
timer |= inb(I8254_PORT_COUNTER0) << 8;
--
2.19.1
linux-next: clean up time
Hi all, Now that v5.0-rc1 is out, it is a good time to clean up your linux-next included trees with respect to your upstream trees. Thanks in anticipation. ;-) -- Cheers, Stephen Rothwell pgp9tF4_8oGhj.pgp Description: OpenPGP digital signature
Re: [RFC PATCH V3 0/5] Hi:
On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: > > On 2019/1/3 上午4:47, Michael S. Tsirkin wrote: > > On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: > > > This series tries to access virtqueue metadata through kernel virtual > > > address instead of copy_user() friends since they had too much > > > overheads like checks, spec barriers or even hardware feature > > > toggling. > > Will review, thanks! > > One questions that comes to mind is whether it's all about bypassing > > stac/clac. Could you please include a performance comparison with > > nosmap? > > > > On machine without SMAP (Sandy Bridge): > > Before: 4.8Mpps > > After: 5.2Mpps OK so would you say it's really unsafe versus safe accesses? Or would you say it's just a better written code? > On machine with SMAP (Broadwell): > > Before: 5.0Mpps > > After: 6.1Mpps > > No smap: 7.5Mpps > > > Thanks no smap being before or after? -- MST
[PATCH 1/6] dt-bindings: timer: add Tegra210 timer
The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
(TMR10-TMR13). Each TMR can be programmed to generate one-shot periodic,
or watchdog interrupts.
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Joseph Lo
---
.../bindings/timer/nvidia,tegra210-timer.txt | 25 +++
1 file changed, 25 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt
b/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt
new file mode 100644
index ..ba511220a669
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt
@@ -0,0 +1,25 @@
+NVIDIA Tegra210 timer
+
+The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
+timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
+from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
+(TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic,
+or watchdog interrupts.
+
+Required properties:
+- compatible : "nvidia,tegra210-timer".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 4 interrupts; one per each of TMR10 through TMR13.
+- clocks : Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+
+timer@60005000 {
+ compatible = "nvidia,tegra210-timer";
+ reg = <0x0 0x60005000 0x0 0x400>;
+ interrupts = ,
+,
+,
+;
+ clocks = <&tegra_car TEGRA210_CLK_TIMER>;
+ clock-names = "timer";
+};
--
2.20.1
[PATCH 2/6] clocksource: tegra: add Tegra210 timer driver
Add support for the Tegra210 timer that runs at oscillator clock
(TMR10-TMR13). We need these timers to work as clock event device and to
replace the ARMv8 architected timer due to it can't survive across the
power cycle of the CPU core or CPUPORESET signal. So it can't be a wake-up
source when CPU suspends in power down state.
Based on the work of Antti P Miettinen
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joseph Lo
---
drivers/clocksource/Kconfig | 3 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-tegra210.c | 240 +++
include/linux/cpuhotplug.h | 1 +
4 files changed, 245 insertions(+)
create mode 100644 drivers/clocksource/timer-tegra210.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a9e26f6a81a1..e6e3e64b6320 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -135,6 +135,9 @@ config TEGRA_TIMER
help
Enables support for the Tegra driver.
+config TEGRA210_TIMER
+ def_bool ARCH_TEGRA_210_SOC
+
config VT8500_TIMER
bool "VT8500 timer driver" if COMPILE_TEST
depends on HAS_IOMEM
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index cdd210ff89ea..95de59c8a47b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_SUN4I_TIMER) += timer-sun4i.o
obj-$(CONFIG_SUN5I_HSTIMER)+= timer-sun5i.o
obj-$(CONFIG_MESON6_TIMER) += timer-meson6.o
obj-$(CONFIG_TEGRA_TIMER) += timer-tegra20.o
+obj-$(CONFIG_TEGRA210_TIMER) += timer-tegra210.o
obj-$(CONFIG_VT8500_TIMER) += timer-vt8500.o
obj-$(CONFIG_NSPIRE_TIMER) += timer-zevio.o
obj-$(CONFIG_BCM_KONA_TIMER) += bcm_kona_timer.o
diff --git a/drivers/clocksource/timer-tegra210.c
b/drivers/clocksource/timer-tegra210.c
new file mode 100644
index ..d88c127d3b3b
--- /dev/null
+++ b/drivers/clocksource/timer-tegra210.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2014-2019, NVIDIA CORPORATION. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static u32 tegra210_timer_freq;
+static void __iomem *tegra210_timer_reg_base;
+static u32 usec_config;
+
+#define TIMER_PTV 0x0
+#define TIMER_PTV_EN BIT(31)
+#define TIMER_PTV_PER BIT(30)
+#define TIMER_PCR 0x4
+#define TIMER_PCR_INTR_CLR BIT(30)
+#define TIMERUS_CNTR_1US 0x10
+#define TIMERUS_USEC_CFG 0x14
+
+#define TIMER10_OFFSET 0x90
+
+#define TIMER_FOR_CPU(cpu) (TIMER10_OFFSET + (cpu) * 8)
+
+struct tegra210_clockevent {
+ struct clock_event_device evt;
+ char name[20];
+ void __iomem *reg_base;
+};
+#define to_tegra_cevt(p) (container_of(p, struct tegra210_clockevent, evt))
+
+static struct tegra210_clockevent __percpu *tegra210_evt;
+
+static int tegra210_timer_set_next_event(unsigned long cycles,
+struct clock_event_device *evt)
+{
+ struct tegra210_clockevent *tevt;
+
+ tevt = to_tegra_cevt(evt);
+ writel(TIMER_PTV_EN |
+ ((cycles > 1) ? (cycles - 1) : 0), /* n+1 scheme */
+ tevt->reg_base + TIMER_PTV);
+
+ return 0;
+}
+
+static inline void timer_shutdown(struct tegra210_clockevent *tevt)
+{
+ writel(0, tevt->reg_base + TIMER_PTV);
+}
+
+static int tegra210_timer_shutdown(struct clock_event_device *evt)
+{
+ struct tegra210_clockevent *tevt;
+
+ tevt = to_tegra_cevt(evt);
+ timer_shutdown(tevt);
+
+ return 0;
+}
+
+static int tegra210_timer_set_periodic(struct clock_event_device *evt)
+{
+ struct tegra210_clockevent *tevt;
+
+ tevt = to_tegra_cevt(evt);
+ writel(TIMER_PTV_EN | TIMER_PTV_PER | ((tegra210_timer_freq / HZ) - 1),
+ tevt->reg_base + TIMER_PTV);
+
+ return 0;
+}
+
+static irqreturn_t tegra210_timer_isr(int irq, void *dev_id)
+{
+ struct tegra210_clockevent *tevt;
+
+ tevt = dev_id;
+ writel(TIMER_PCR_INTR_CLR, tevt->reg_base + TIMER_PCR);
+ tevt->evt.event_handler(&tevt->evt);
+
+ return IRQ_HANDLED;
+}
+
+static int tegra210_timer_setup(unsigned int cpu)
+{
+ struct tegra210_clockevent *tevt = per_cpu_ptr(tegra210_evt, cpu);
+
+ irq_force_affinity(tevt->evt.irq, cpumask_of(cpu));
+ enable_irq(tevt->evt.irq);
+
+ clockevents_config_and_register(&tevt->evt, tegra210_timer_freq,
+ 1, /* min */
+ 0x1fff); /* 29 bits */
+
+ return 0;
+}
+
+static int tegra210_timer_stop(unsigned int cpu)
+{
+ struct tegra210_clockevent *tevt = per_cpu_ptr(tegra210_evt, cpu);
+
+ tevt->evt.set_state_shutdown(&tevt->evt);
+ disable_irq_nosync(tevt->evt.irq);
+
+ r
[PATCH v15 3/6] x86/boot: Introduce efi_get_rsdp_addr() to find RSDP from EFI table
Memory information in SRAT is necessary to fix the conflict between
KASLR and memory-hotremove. So RSDP and SRAT should be parsed.
When booting form KEXEC/EFI/BIOS, the methods to compute RSDP
are different. When booting from EFI, EFI table points to RSDP.
So parse the EFI table and find the RSDP.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/acpi.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
index 7ca5001d7639..f74c5d033d79 100644
--- a/arch/x86/boot/compressed/acpi.c
+++ b/arch/x86/boot/compressed/acpi.c
@@ -5,6 +5,8 @@
#include "../string.h"
#include
+#include
+#include
/*
* Max length of 64-bit hex address string is 19, prefix "0x" + 16 hex
@@ -28,3 +30,84 @@ static acpi_physical_address get_acpi_rsdp(void)
#endif
return 0;
}
+
+/* Search EFI table for RSDP. */
+static acpi_physical_address efi_get_rsdp_addr(void)
+{
+ acpi_physical_address rsdp_addr = 0;
+#ifdef CONFIG_EFI
+ efi_system_table_t *systab;
+ struct efi_info *ei;
+ bool efi_64;
+ char *sig;
+ int size;
+ int i;
+
+ ei = &boot_params->efi_info;
+ sig = (char *)&ei->efi_loader_signature;
+
+ if (!strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) {
+ efi_64 = true;
+ } else if (!strncmp(sig, EFI32_LOADER_SIGNATURE, 4)) {
+ efi_64 = false;
+ } else {
+ debug_putstr("Wrong EFI loader signature.\n");
+ return 0;
+ }
+
+ /* Get systab from boot params. Based on efi_init(). */
+#ifdef CONFIG_X86_64
+ systab = (efi_system_table_t *)(ei->efi_systab |
((__u64)ei->efi_systab_hi<<32));
+#else
+ if (ei->efi_systab_hi || ei->efi_memmap_hi) {
+ debug_putstr("Error getting RSDP address: EFI system table
located above 4GB.\n");
+ return 0;
+ }
+ systab = (efi_system_table_t *)ei->efi_systab;
+#endif
+
+ if (!systab)
+ error("EFI system table is not found.");
+
+ /*
+* Get EFI tables from systab. Based on efi_config_init() and
+* efi_config_parse_tables().
+*/
+ size = efi_64 ? sizeof(efi_config_table_64_t) :
+ sizeof(efi_config_table_32_t);
+
+ for (i = 0; i < systab->nr_tables; i++) {
+ void *config_tables;
+ unsigned long table;
+ efi_guid_t guid;
+
+ config_tables = (void *)(systab->tables + size * i);
+ if (efi_64) {
+ efi_config_table_64_t *tmp_table;
+ u64 table64;
+
+ tmp_table = config_tables;
+ guid = tmp_table->guid;
+ table64 = tmp_table->table;
+ table = table64;
+
+ if (!IS_ENABLED(CONFIG_X86_64) && table64 >> 32) {
+ debug_putstr("Error getting RSDP address: EFI
config table located above 4GB.\n");
+ return 0;
+ }
+ } else {
+ efi_config_table_32_t *tmp_table;
+
+ tmp_table = config_tables;
+ guid = tmp_table->guid;
+ table = tmp_table->table;
+ }
+
+ if (!(efi_guidcmp(guid, ACPI_TABLE_GUID)))
+ rsdp_addr = table;
+ else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID)))
+ return table;
+ }
+#endif
+ return rsdp_addr;
+}
--
2.20.1
