[v2] mtd: rawnand: Change calculating of position page containing BBM
Change calculating of position page containing BBM If none of BBM flags are set then function nand_bbm_get_next_page reports EINVAL. It causes that BBM is not read at all during scanning factory bad blocks. The result is that the BBT table is build without checking factory BBM at all. For Micron flash memories none of these flags are set if page size is different than 2048 bytes. Address this regression by: - adding NAND_BBM_FIRSTPAGE chip flag without any condition. It solves issue only for Micron devices. - changing the nand_bbm_get_next_page_function. It will return 0 if no of BBM flag is set and page parameter is 0. After that modification way of discovering factory bad blocks will work similar as in kernel version 5.1. Cc: sta...@vger.kernel.org Fixes: f90da7818b14 (mtd: rawnand: Support bad block markers in first, second or last page) Signed-off-by: Piotr Sroka Reviewed-by: Frieder Schrempf --- Changes for v2: - add fix for micron nand driver - add fixes and stable tags --- drivers/mtd/nand/raw/nand_base.c | 8 ++-- drivers/mtd/nand/raw/nand_micron.c | 4 +++- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 5c2c30a7dffa..f64e3b6605c6 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -292,12 +292,16 @@ int nand_bbm_get_next_page(struct nand_chip *chip, int page) struct mtd_info *mtd = nand_to_mtd(chip); int last_page = ((mtd->erasesize - mtd->writesize) >> chip->page_shift) & chip->pagemask; + unsigned int bbm_flags = NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE + | NAND_BBM_LASTPAGE; + if (page == 0 && !(chip->options & bbm_flags)) + return 0; if (page == 0 && chip->options & NAND_BBM_FIRSTPAGE) return 0; - else if (page <= 1 && chip->options & NAND_BBM_SECONDPAGE) + if (page <= 1 && chip->options & NAND_BBM_SECONDPAGE) return 1; - else if (page <= last_page && chip->options & NAND_BBM_LASTPAGE) + if (page <= last_page && chip->options & NAND_BBM_LASTPAGE) return last_page; return -EINVAL; diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c index 1622d3145587..913f42854563 100644 --- a/drivers/mtd/nand/raw/nand_micron.c +++ b/drivers/mtd/nand/raw/nand_micron.c @@ -438,8 +438,10 @@ static int micron_nand_init(struct nand_chip *chip) if (ret) goto err_free_manuf_data; + chip->options |= NAND_BBM_FIRSTPAGE; + if (mtd->writesize == 2048) - chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE; + chip->options |= NAND_BBM_SECONDPAGE; ondie = micron_supports_on_die_ecc(chip); -- 2.15.0
Re: [PATCH v7 00/12] implement KASLR for powerpc/fsl_booke/32
Hi Scott, Can you test v7 to see if it works to load a kernel at a non-zero address? Thanks, On 2019/9/20 17:45, Jason Yan wrote: This series implements KASLR for powerpc/fsl_booke/32, as a security feature that deters exploit attempts relying on knowledge of the location of kernel internals. Since CONFIG_RELOCATABLE has already supported, what we need to do is map or copy kernel to a proper place and relocate. Freescale Book-E parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 entries are not suitable to map the kernel directly in a randomized region, so we chose to copy the kernel to a proper place and restart to relocate. Entropy is derived from the banner and timer base, which will change every build and boot. This not so much safe so additionally the bootloader may pass entropy via the /chosen/kaslr-seed node in device tree. We will use the first 512M of the low memory to randomize the kernel image. The memory will be split in 64M zones. We will use the lower 8 bit of the entropy to decide the index of the 64M zone. Then we chose a 16K aligned offset inside the 64M zone to put the kernel in. KERNELBASE |--> 64M <--| | | +---+++---+ | |||kernel|| | +---+++---+ | | |-> offset<-| kernstart_virt_addr We also check if we will overlap with some areas like the dtb area, the initrd area or the crashkernel area. If we cannot find a proper area, kaslr will be disabled and boot from the original kernel. Changes since v6: - Rename create_tlb_entry() to create_kaslr_tlb_entry() - Remove MAS2_VAL since there is no more users. - Move kaslr_booke.c to arch/powerpc/mm/nohash. - Call flush_icache_range() after copying the kernel. - Warning if no kaslr-seed provided by the bootloader - Use the right physical address when checking if the new position will overlap with other regions. - Do not clear bss for the second pass because some global variables will not be initialized again - Use tabs instead of spaces between the mnemonic and the arguments(in fsl_booke_entry_mapping.S). Changes since v5: - Rename M_IF_NEEDED to MAS2_M_IF_NEEDED - Define some global variable as __ro_after_init - Replace kimage_vaddr with kernstart_virt_addr - Depend on RELOCATABLE, not select it - Modify the comment block below the SPDX tag - Remove some useless headers in kaslr_booke.c and move is_second_reloc declarationto mmu_decl.h - Remove DBG() and use pr_debug() and rewrite comment above get_boot_seed(). - Add a patch to document the KASLR implementation. - Split a patch from patch #10 which exports kaslr offset in VMCOREINFO ELF notes. - Remove extra logic around finding nokaslr string in cmdline. - Make regions static global and __initdata Changes since v4: - Add Reviewed-by tag from Christophe - Remove an unnecessary cast - Remove unnecessary parenthesis - Fix checkpatch warning Changes since v3: - Add Reviewed-by and Tested-by tag from Diana - Change the comment in fsl_booke_entry_mapping.S to be consistent with the new code. Changes since v2: - Remove unnecessary #ifdef - Use SZ_64M instead of0x400 - Call early_init_dt_scan_chosen() to init boot_command_line - Rename kaslr_second_init() to kaslr_late_init() Changes since v1: - Remove some useless 'extern' keyword. - Replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL - Improve some assembly code - Use memzero_explicit instead of memset - Use boot_command_line and remove early_command_line - Do not print kaslr offset if kaslr is disabled Jason Yan (12): powerpc: unify definition of M_IF_NEEDED powerpc: move memstart_addr and kernstart_addr to init-common.c powerpc: introduce kernstart_virt_addr to store the kernel base powerpc/fsl_booke/32: introduce create_kaslr_tlb_entry() helper powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper powerpc/fsl_booke/32: implement KASLR infrastructure powerpc/fsl_booke/32: randomize the kernel image offset powerpc/fsl_booke/kaslr: clear the original kernel if randomized powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter powerpc/fsl_booke/kaslr: dump out kernel offset information on panic powerpc/fsl_booke/kaslr: export offset in VMCOREINFO ELF notes powerpc/fsl_booke/32: Document KASLR implementation Documentation/powerpc/kaslr-booke32.rst | 42 ++ arch/powerpc/Kconfig | 11 + arch/powerpc/include/asm/nohash/mmu-book3e.h | 11 +- arch/powerpc/include/asm/page.h | 7 + arch/powerpc/kernel/early_32.c| 5 +- arch/powerpc/kernel/exceptions-64e.S | 12 +- arch/powerpc/kernel/fsl_booke_entry_mapping.S | 25 +-
Re: Ben sent 132 patches and Sasa sent 203 patches..woohooo!
On Tue, Sep 24, 2019 at 11:00:06AM +0530, Bhaskar Chowdhury wrote:
> Is this kind of heaving patching done before?? I can't recollect.
Yes it's being done, and quite frankly Bhaskar, this e-mail as well as
all your other automated ones ("thanks a bunch") after each and every
release do not bring any value and only add noise, particularly when
developers are directly CCed. You should avoid this because you're
training developers to systematically ignore your messages and the day
you have a real question or issue to report, nobody will notice nor
respond.
Just my two cents,
Willy
Re: [PATCH 1/2] pwm: Add different PWM output types support
On Mon, Sep 16, 2019 at 04:01:46PM +0200, Thierry Reding wrote: > On Fri, Sep 13, 2019 at 03:57:43PM -0700, Guru Das Srinagesh wrote: > > From: Fenglin Wu > > > > Normally, PWM channel has fixed output until software request to change > > its settings. There are some PWM devices which their outputs could be > > changed autonomously according to a predefined pattern programmed in > > hardware. Add pwm_output_type enum type to identify these two different > > PWM types and add relevant helper functions to set and get PWM output > > types and pattern. > > > > Change-Id: Ia1f914a45ab4f4dd7be037a395eeb89d0e65a80e > > Signed-off-by: Fenglin Wu > > Signed-off-by: Guru Das Srinagesh > > --- > > drivers/pwm/core.c | 26 > > drivers/pwm/sysfs.c | 50 ++ > > include/linux/pwm.h | 70 > > + > > 3 files changed, 146 insertions(+) > > This doesn't seem right to me. Are you describing a PWM pin that's > actually driven in GPIO mode? We usually configure that using pinctrl. > > Thierry Sorry, let me clarify. Some Qualcomm PMICs have a PWM block called the Light Pulse Generator (LPG). This block allows for the generation of a HW-controlled PWM "pattern", i.e. a sequential altering of duty cycle, in addition to the normal PWM "fixed" duty cycle operation, which is what the framework does currently. This pattern is user-configurable in the form of a look-up table in the devicetree. The LPG's registers have to be configured with the data in the look up table in order to start the generation of the pattern. An example of a pattern is the "breath" pattern, which simply ramps up the duty cycle and then ramps it down. This "pattern" mode is what has been defined as PWM_OUTPUT_MODULATED in this patch. I see that the use of the term "modulated" is misleading - a more accurate term would be PWM_OUTPUT_PATTERN perhaps. This patch merely adds framework support to differentiate between the "fixed" and "pattern" modes of operation. Actions such as configuring the LPG with the devicetree pattern and setting it up for generating the pattern are performed in the driver only if the output type is read as "pattern" and not otherwise.
[RESEND v7 1/2] media: venus: Add codec data table
Add vpp cycles for different types of codec.
It indicates the cycles required by video hardware
to process each macroblock. Add vsp cycles, cycles
required by stream processor. Initialize the codec
data with core resources.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/core.c| 13 +
drivers/media/platform/qcom/venus/core.h| 16 +++
drivers/media/platform/qcom/venus/helpers.c | 30 +
drivers/media/platform/qcom/venus/helpers.h | 1 +
drivers/media/platform/qcom/venus/vdec.c| 4
drivers/media/platform/qcom/venus/venc.c| 4
6 files changed, 68 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 19cbe9d..49d32b2 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -480,6 +480,17 @@ static __maybe_unused int venus_runtime_resume(struct
device *dev)
{ 244800, 1 }, /* 1920x1080@30 */
};
+static struct codec_freq_data sdm845_codec_freq_data[] = {
+ { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_ENC, 675, 10 },
+ { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_ENC, 675, 10 },
+ { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_ENC, 675, 10 },
+ { V4L2_PIX_FMT_MPEG2, VIDC_SESSION_TYPE_DEC, 200, 10 },
+ { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_DEC, 200, 10 },
+ { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_DEC, 200, 10 },
+ { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_DEC, 200, 10 },
+ { V4L2_PIX_FMT_VP9, VIDC_SESSION_TYPE_DEC, 200, 10 },
+};
+
static const struct bw_tbl sdm845_bw_table_enc[] = {
{ 1944000, 1612000, 0, 2416000, 0 },/* 3840x2160@60 */
{ 972000, 951000, 0, 1434000, 0 },/* 3840x2160@30 */
@@ -501,6 +512,8 @@ static __maybe_unused int venus_runtime_resume(struct
device *dev)
.bw_tbl_enc_size = ARRAY_SIZE(sdm845_bw_table_enc),
.bw_tbl_dec = sdm845_bw_table_dec,
.bw_tbl_dec_size = ARRAY_SIZE(sdm845_bw_table_dec),
+ .codec_freq_data = sdm845_codec_freq_data,
+ .codec_freq_data_size = ARRAY_SIZE(sdm845_codec_freq_data),
.clks = {"core", "iface", "bus" },
.clks_num = 3,
.max_load = 3110400,/* 4096x2160@90 */
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 13e35f3..684a950 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -26,6 +26,13 @@ struct reg_val {
u32 value;
};
+struct codec_freq_data {
+ u32 pixfmt;
+ u32 session_type;
+ unsigned long vpp_freq;
+ unsigned long vsp_freq;
+};
+
struct bw_tbl {
u32 mbs_per_sec;
u32 avg;
@@ -44,6 +51,8 @@ struct venus_resources {
unsigned int bw_tbl_dec_size;
const struct reg_val *reg_tbl;
unsigned int reg_tbl_size;
+ const struct codec_freq_data *codec_freq_data;
+ unsigned int codec_freq_data_size;
const char * const clks[VIDC_CLKS_NUM_MAX];
unsigned int clks_num;
enum hfi_version hfi_version;
@@ -221,6 +230,12 @@ struct venus_buffer {
struct list_head ref_list;
};
+struct clock_data {
+ u32 core_id;
+ unsigned long freq;
+ const struct codec_freq_data *codec_freq_data;
+};
+
#define to_venus_buffer(ptr) container_of(ptr, struct venus_buffer, vb)
enum venus_dec_state {
@@ -301,6 +316,7 @@ struct venus_inst {
struct list_head list;
struct mutex lock;
struct venus_core *core;
+ struct clock_data clk_data;
struct list_head dpbbufs;
struct list_head internalbufs;
struct list_head registeredbufs;
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 4320ea9..71af237 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -883,6 +883,36 @@ int venus_helper_set_core_usage(struct venus_inst *inst,
u32 usage)
}
EXPORT_SYMBOL_GPL(venus_helper_set_core_usage);
+int venus_helper_init_codec_freq_data(struct venus_inst *inst)
+{
+ const struct codec_freq_data *data;
+ unsigned int i, data_size;
+ u32 pixfmt;
+ int ret = 0;
+
+ if (!IS_V4(inst->core))
+ return 0;
+
+ data = inst->core->res->codec_freq_data;
+ data_size = inst->core->res->codec_freq_data_size;
+ pixfmt = inst->session_type == VIDC_SESSION_TYPE_DEC ?
+ inst->fmt_out->pixfmt : inst->fmt_cap->pixfmt;
+
+ for (i = 0; i < data_size; i++) {
+ if (data[i].pixfmt == pixfmt &&
+ data[i].session_type == inst->session_type) {
+ inst->clk_data.codec_freq_data = [i];
+ break;
+ }
+ }
+
+ if (!inst->clk_data.codec_freq_data)
+ ret = -EINVAL;
+
+ return ret;
+}
[RESEND v7 2/2] media: venus: Update clock scaling
Current clock scaling calculations are same for vpu4 and
previous versions. For vpu4, Clock scaling calculations
are updated with cycles/mb and bitrate. This helps in
getting precise clock required.
Signed-off-by: Aniket Masule
---
drivers/media/platform/qcom/venus/helpers.c | 157
drivers/media/platform/qcom/venus/helpers.h | 2 +-
drivers/media/platform/qcom/venus/vdec.c| 4 +-
3 files changed, 140 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 71af237..e8476f5 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -448,12 +448,32 @@ static int load_scale_bw(struct venus_core *core)
return icc_set_bw(core->video_path, total_avg, total_peak);
}
-int venus_helper_load_scale_clocks(struct venus_core *core)
+static int set_clk_freq(struct venus_core *core, unsigned long freq)
{
+ struct clk *clk = core->clks[0];
+ int ret;
+
+ ret = clk_set_rate(clk, freq);
+ if (ret)
+ return ret;
+
+ ret = clk_set_rate(core->core0_clk, freq);
+ if (ret)
+ return ret;
+
+ ret = clk_set_rate(core->core1_clk, freq);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int scale_clocks(struct venus_inst *inst)
+{
+ struct venus_core *core = inst->core;
const struct freq_tbl *table = core->res->freq_tbl;
unsigned int num_rows = core->res->freq_tbl_size;
unsigned long freq = table[0].freq;
- struct clk *clk = core->clks[0];
struct device *dev = core->dev;
u32 mbs_per_sec;
unsigned int i;
@@ -479,28 +499,123 @@ int venus_helper_load_scale_clocks(struct venus_core
*core)
set_freq:
- ret = clk_set_rate(clk, freq);
- if (ret)
- goto err;
+ ret = set_clk_freq(core, freq);
+ if (ret) {
+ dev_err(dev, "failed to set clock rate %lu (%d)\n",
+ freq, ret);
+ return ret;
+ }
- ret = clk_set_rate(core->core0_clk, freq);
- if (ret)
- goto err;
+ ret = load_scale_bw(core);
+ if (ret) {
+ dev_err(dev, "failed to set bandwidth (%d)\n",
+ ret);
+ return ret;
+ }
- ret = clk_set_rate(core->core1_clk, freq);
- if (ret)
- goto err;
+ return 0;
+}
+
+static unsigned long calculate_inst_freq(struct venus_inst *inst,
+unsigned long filled_len)
+{
+ unsigned long vpp_freq = 0, vsp_freq = 0;
+ u64 fps = inst->fps;
+ u32 mbs_per_sec;
+
+ mbs_per_sec = load_per_instance(inst) / inst->fps;
+ vpp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vpp_freq;
+ /* 21 / 20 is overhead factor */
+ vpp_freq += vpp_freq / 20;
+ vsp_freq = mbs_per_sec * inst->clk_data.codec_freq_data->vsp_freq;
+
+ /* 10 / 7 is overhead factor */
+ if (inst->session_type == VIDC_SESSION_TYPE_ENC)
+ vsp_freq += (inst->controls.enc.bitrate * 10) / 7;
+ else
+ vsp_freq += ((fps * filled_len * 8) * 10) / 7;
+
+ return max(vpp_freq, vsp_freq);
+}
+
+static int scale_clocks_v4(struct venus_inst *inst)
+{
+ struct venus_core *core = inst->core;
+ const struct freq_tbl *table = core->res->freq_tbl;
+ unsigned int num_rows = core->res->freq_tbl_size;
+ struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
+ struct device *dev = core->dev;
+ unsigned long freq = 0, freq_core1 = 0, freq_core2 = 0;
+ unsigned long filled_len = 0;
+ struct venus_buffer *buf, *n;
+ struct vb2_buffer *vb;
+ int i, ret;
+
+ v4l2_m2m_for_each_src_buf_safe(m2m_ctx, buf, n) {
+ vb = >vb.vb2_buf;
+ filled_len = max(filled_len, vb2_get_plane_payload(vb, 0));
+ }
+
+ if (inst->session_type == VIDC_SESSION_TYPE_DEC && !filled_len)
+ return 0;
+
+ freq = calculate_inst_freq(inst, filled_len);
+ inst->clk_data.freq = freq;
+
+ mutex_lock(>lock);
+ list_for_each_entry(inst, >instances, list) {
+ if (inst->clk_data.core_id == VIDC_CORE_ID_1) {
+ freq_core1 += inst->clk_data.freq;
+ } else if (inst->clk_data.core_id == VIDC_CORE_ID_2) {
+ freq_core2 += inst->clk_data.freq;
+ } else if (inst->clk_data.core_id == VIDC_CORE_ID_3) {
+ freq_core1 += inst->clk_data.freq;
+ freq_core2 += inst->clk_data.freq;
+ }
+ }
+ mutex_unlock(>lock);
+
+ freq = max(freq_core1, freq_core2);
+
+ if (freq >= table[0].freq) {
+ freq = table[0].freq;
+ dev_warn(dev, "HW is overloaded, needed: %lu max:
[RESEND v7 0/2]media: venus: Update clock scaling
In this patch series, clock scaling and core selection methods are updated. Current clock scaling is same for vpu4 and previous versions. Introducing load calculations using vpp cycles, which indicates the cycles required by video hardware to process each macroblock. Also adding vsp cycles, cycles require by stream processor. Clock scaling is now done more precisely using vpp and vsp cycles. Removing core selection from this series, there will be separate patch once issue related to power domain is fixed. This patch depends on the following patch: https://patchwork.kernel.org/patch/11142557/ - Venus interconnect support for sdm845 Changes since v6: - Removed core selection. - Corrected frequency calculations. - Removed instance lock used while iterating over buffers. Changes since v5: - Corrected load_per_core calculations. Changes since v4: - Added call to load_scale_clocks from venus_helper_vb2_buf_queue. - Modified check to match core_id in core_selection. Changes since v3: - vsp_cycles and vpp_cyles are now unsigned long. - Core number counting aligned with VIDC_CORE_ID_. - Aligned hardware overload handling of scale_clocks_v4 with scale_clocks. - Added bitrate based clock scaling patch in this patch series. - Instance state check is now moved from scale_clocks to load_scale_clocks Aniket Masule (2): media: venus: Add codec data table media: venus: Update clock scaling drivers/media/platform/qcom/venus/core.c| 13 ++ drivers/media/platform/qcom/venus/core.h| 16 +++ drivers/media/platform/qcom/venus/helpers.c | 187 +--- drivers/media/platform/qcom/venus/helpers.h | 3 +- drivers/media/platform/qcom/venus/vdec.c| 8 +- drivers/media/platform/qcom/venus/venc.c| 4 + 6 files changed, 208 insertions(+), 23 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Ben sent 132 patches and Sasa sent 203 patches..woohooo!
Is this kind of heaving patching done before?? I can't recollect. Thanks, Bhaskar signature.asc Description: PGP signature
Re: [PATCH V7 0/2] mailbox: arm: introduce smc triggered mailbox
On 23/09/2019 07:36, Peng Fan wrote: Hi Peng, thanks for the update! > From: Peng Fan > > V7: > Typo fix > #mbox-cells changed to 0 > Add a new header file arm-smccc-mbox.h > Use ARM_SMCCC_IS_64 > > Andre, > The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id > property is optional, so clients could pass function_id to mbox driver. Well, to be honest, this is the main thing I am opposing: It should *not* be optional. The controller driver DT node should *always* contain the function ID. The reasons for that I explained in the other emails to Jassi: We can't safely execute smc calls from the Linux kernel, unless we also comply with the SMCCC standard. So we should not leave the choice of the function ID to the mailbox client. Also this much better separates the mailbox controller driver from the client. So I think we should reach an agreement here. Cheers, Andre > V6: > Switch to per-channel a mbox controller > Drop arm,num-chans, transports, method > Add arm,hvc-mbox compatible > Fix smc/hvc args, drop client id and use correct type. > https://patchwork.kernel.org/cover/11146641/ > > V5: > yaml fix > https://patchwork.kernel.org/cover/7741/ > > V4: > yaml fix for num-chans in patch 1/2. > https://patchwork.kernel.org/cover/6521/ > > V3: > Drop interrupt > Introduce transports for mem/reg usage > Add chan-id for mem usage > Convert to yaml format > https://patchwork.kernel.org/cover/11043541/ > > V2: > This is a modified version from Andre Przywara's patch series > https://lore.kernel.org/patchwork/cover/812997/. > The modification are mostly: > Introduce arm,num-chans > Introduce arm_smccc_mbox_cmd > txdone_poll and txdone_irq are both set to false > arm,func-ids are kept, but as an optional property. > Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. > Introduce interrupts notification. > > [1] is a draft implementation of i.MX8MM SCMI ATF implementation that > use smc as mailbox, power/clk is included, but only part of clk has been > implemented to work with hardware, power domain only supports get name > for now. > > The traditional Linux mailbox mechanism uses some kind of dedicated hardware > IP to signal a condition to some other processing unit, typically a dedicated > management processor. > This mailbox feature is used for instance by the SCMI protocol to signal a > request for some action to be taken by the management processor. > However some SoCs does not have a dedicated management core to provide > those services. In order to service TEE and to avoid linux shutdown > power and clock that used by TEE, need let firmware to handle power > and clock, the firmware here is ARM Trusted Firmware that could also > run SCMI service. > > The existing SCMI implementation uses a rather flexible shared memory > region to communicate commands and their parameters, it still requires a > mailbox to actually trigger the action. > > This patch series provides a Linux mailbox compatible service which uses > smc calls to invoke firmware code, for instance taking care of SCMI requests. > The actual requests are still communicated using the standard SCMI way of > shared memory regions, but a dedicated mailbox hardware IP can be replaced via > this new driver. > > This simple driver uses the architected SMC calling convention to trigger > firmware services, also allows for using "HVC" calls to call into hypervisors > or firmware layers running in the EL2 exception level. > > Patch 1 contains the device tree binding documentation, patch 2 introduces > the actual mailbox driver. > > Please note that this driver just provides a generic mailbox mechanism, > It could support synchronous TX/RX, or synchronous TX with asynchronous > RX. And while providing SCMI services was the reason for this exercise, > this driver is in no way bound to this use case, but can be used generically > where the OS wants to signal a mailbox condition to firmware or a > hypervisor. > Also the driver is in no way meant to replace any existing firmware > interface, but actually to complement existing interfaces. > > [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi > > > > Peng Fan (2): > dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox > mailbox: introduce ARM SMC based mailbox > > .../devicetree/bindings/mailbox/arm-smc.yaml | 95 > drivers/mailbox/Kconfig| 7 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/arm-smc-mailbox.c | 168 > + > 4 files changed, 272 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > create mode 100644 drivers/mailbox/arm-smc-mailbox.c >
Re: [PATCH] ARM: don't export unused return_address()
On Sat, Sep 7, 2019 at 12:47 AM Arnd Bergmann wrote: > > Without the frame pointer enabled, return_address() is an inline > function and does not need to be exported, as shown by this warning: > > WARNING: "return_address" [vmlinux] is a static EXPORT_SYMBOL_GPL > > Move the EXPORT_SYMBOL_GPL() into the #ifdef as well. > > Signed-off-by: Arnd Bergmann Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
Re: [PATCH v7 10/21] RISC-V: KVM: Handle MMIO exits for VCPU
On Mon, Sep 23, 2019 at 7:03 PM Paolo Bonzini wrote: > > On 23/09/19 15:09, Anup Patel wrote: > >>> +#ifndef CONFIG_RISCV_ISA_C > >>> + "li %[tilen], 4\n" > >>> +#else > >>> + "li %[tilen], 2\n" > >>> +#endif > >> > >> Can you use an assembler directive to force using a non-compressed > >> format for ld and lw? This would get rid of tilen, which is costing 6 > >> bytes (if I did the RVC math right) in order to save two. :) > > > > I tried looking for it but could not find any assembler directive > > to selectively turn-off instruction compression. > > ".option norvc"? Thanks for the hint. I will try ".option norvc" Regards, Anup > > Paolo
Re: general protection fault in xsk_map_update_elem
On 2019-09-24 00:50, Daniel Borkmann wrote: On Mon, Sep 23, 2019 at 08:49:11AM -0700, syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:b41dae06 Merge tag 'xfs-5.4-merge-7' of git://git.kernel.o.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=130b25ad60 kernel config: https://syzkaller.appspot.com/x/.config?x=dfcf592db22b9132 dashboard link: https://syzkaller.appspot.com/bug?extid=491c1b7565ba9069ecae compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=155a0c2960 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172bf6d960 The bug was bisected to: commit 0402acd683c678874df6bdbc23530ca07ea19353 Author: Björn Töpel Date: Thu Aug 15 09:30:13 2019 + xsk: remove AF_XDP socket from map when the socket is released Bjorn, PTAL, thanks. I'm on it! Thanks for the poke.
Re: [PATCH] base: soc: Export soc_device_to_device API
On Mon, Sep 23, 2019 at 02:35:33PM -0700, mnala...@codeaurora.org wrote:
> On 2019-09-19 23:10, Greg KH wrote:
> > On Thu, Sep 19, 2019 at 08:36:51PM -0700, Bjorn Andersson wrote:
> > > On Thu 19 Sep 15:45 PDT 2019, Greg KH wrote:
> > >
> > > > On Thu, Sep 19, 2019 at 03:40:17PM -0700, Bjorn Andersson wrote:
> > > > > On Thu 19 Sep 15:25 PDT 2019, Greg KH wrote:
> > > > >
> > > > > > On Thu, Sep 19, 2019 at 03:14:56PM -0700, Bjorn Andersson wrote:
> > > > > > > On Thu 19 Sep 14:58 PDT 2019, Greg KH wrote:
> > > > > > >
> > > > > > > > On Thu, Sep 19, 2019 at 02:53:00PM -0700, Bjorn Andersson wrote:
> > > > > > > > > On Thu 19 Sep 14:32 PDT 2019, Greg KH wrote:
> > > > > > > > >
> > > > > > > > > > On Thu, Sep 19, 2019 at 02:13:44PM -0700, Murali Nalajala
> > > > > > > > > > wrote:
> > > > > > > > > > > If the soc drivers want to add custom sysfs entries it
> > > > > > > > > > > needs to
> > > > > > > > > > > access "dev" field in "struct soc_device". This can be
> > > > > > > > > > > achieved
> > > > > > > > > > > by "soc_device_to_device" API. Soc drivers which are
> > > > > > > > > > > built as a
> > > > > > > > > > > module they need above API to be exported. Otherwise one
> > > > > > > > > > > can
> > > > > > > > > > > observe compilation issues.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Murali Nalajala
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/base/soc.c | 1 +
> > > > > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> > > > > > > > > > > index 7c0c5ca..4ad52f6 100644
> > > > > > > > > > > --- a/drivers/base/soc.c
> > > > > > > > > > > +++ b/drivers/base/soc.c
> > > > > > > > > > > @@ -41,6 +41,7 @@ struct device
> > > > > > > > > > > *soc_device_to_device(struct soc_device *soc_dev)
> > > > > > > > > > > {
> > > > > > > > > > > return _dev->dev;
> > > > > > > > > > > }
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(soc_device_to_device);
> > > > > > > > > > >
> > > > > > > > > > > static umode_t soc_attribute_mode(struct kobject *kobj,
> > > > > > > > > > > struct attribute *attr,
> > > > > > > > > >
> > > > > > > > > > What in-kernel driver needs this?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Half of the drivers interacting with the soc driver calls
> > > > > > > > > this API,
> > > > > > > > > several of these I see no reason for being builtin (e.g.
> > > > > > > > > ux500 andversatile). So I think this patch makes sense to
> > > > > > > > > allow us to
> > > > > > > > > build these as modules.
> > > > > > > > >
> > > > > > > > > > Is linux-next breaking without this?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > No, we postponed the addition of any sysfs attributes in the
> > > > > > > > > Qualcomm
> > > > > > > > > socinfo driver.
> > > > > > > > >
> > > > > > > > > > We don't export things unless we have a user of the export.
> > > > > > > > > >
> > > > > > > > > > Also, adding "custom" sysfs attributes is almost always not
> > > > > > > > > > the correct
> > > > > > > > > > thing to do at all. The driver should be doing it, by
> > > > > > > > > > setting up the
> > > > > > > > > > attribute group properly so that the driver core can do it
> > > > > > > > > > automatically
> > > > > > > > > > for it.
> > > > > > > > > >
> > > > > > > > > > No driver should be doing individual add/remove of sysfs
> > > > > > > > > > files. If it
> > > > > > > > > > does so, it is almost guaranteed to be doing it incorrectly
> > > > > > > > > > and racing
> > > > > > > > > > userspace.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The problem here is that the attributes are expected to be
> > > > > > > > > attached to
> > > > > > > > > the soc driver, which is separate from the platform-specific
> > > > > > > > > drivers. So
> > > > > > > > > there's no way to do platform specific attributes the right
> > > > > > > > > way.
> > > > > > > > >
> > > > > > > > > > And yes, there's loads of in-kernel examples of doing this
> > > > > > > > > > wrong, I've
> > > > > > > > > > been working on fixing that up, look at the patches now in
> > > > > > > > > > Linus's tree
> > > > > > > > > > for platform and USB drivers that do this as examples of
> > > > > > > > > > how to do it
> > > > > > > > > > right.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Agreed, this patch should not be used as an approval for any
> > > > > > > > > crazy
> > > > > > > > > attributes; but it's necessary in order to extend the soc
> > > > > > > > > device's
> > > > > > > > > attributes, per the current design.
> > > > > > > >
> > > > > > > > Wait, no, let's not let the "current design" remain if it is
> > > > > > > > broken!
> > > > > > > >
> > > > > > > > Why can't the soc driver handle the attributes properly so that
> > > > > > > > the
> > > > > > > > individual driver doesn't have to do the create/remove?
> > > > > > > >
>
[PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings
gawk 5.0.1 generates the regexp warnings shown below:
GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c
awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape
sequence `\:' is not a known regexp operator
awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350:
(FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape
sequence `\&' is not a known regexp operator
Ealier versions of gawk are not known to generate these warnings.
The gawk manual referenced below does not list characters ':' and '&'
as needing escaping, so 'unescape' them.
https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html
Running diff on the output generated by the script before and after
applying the patch reported no differences.
Signed-off-by: Alexander Kapshuk
Reported-by: kbuild test robot
Reviewed-by: Borislav Petkov
Acked-by: Masami Hiramatsu
---
arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
tools/arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/tools/arch/x86/tools/gen-insn-attr-x86.awk
b/tools/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
--
2.23.0
Re: [PATCH] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()
On 09/23/2019 04:24 PM, David Hildenbrand wrote:
> On 23.09.19 12:52, Michal Hocko wrote:
>> On Mon 16-09-19 11:17:37, Anshuman Khandual wrote:
>>> In add_memory_resource() the memory range to be hot added first gets into
>>> the memblock via memblock_add() before arch_add_memory() is called on it.
>>> Reverse sequence should be followed during memory hot removal which already
>>> is being followed in add_memory_resource() error path. This now ensures
>>> required re-order between memblock_[free|remove]() and arch_remove_memory()
>>> during memory hot-remove.
>>
>> This changelog is not really easy to follow. First of all please make
>> sure to explain whether there is any actual problem to solve or this is
>> an aesthetic matter. Please think of people reading this changelog in
>> few years and scratching their heads what you were thinking back then...
>>
>
> I think it would make sense to just draft the current call sequence in
> the add and the removal path (instead of describing it) - then it
> becomes obvious why this is a cosmetic change.
Does this look okay ?
mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()
Currently during memory hot add procedure, memory gets into memblock before
calling arch_add_memory() which creates it's linear mapping.
add_memory_resource() {
..
memblock_add_node()
..
arch_add_memory()
..
}
But during memory hot remove procedure, removal from memblock happens first
before it's linear mapping gets teared down with arch_remove_memory() which
is not coherent. Resource removal should happen in reverse order as they
were added.
try_remove_memory() {
..
memblock_free()
memblock_remove()
..
arch_remove_memory()
..
}
This changes the sequence of resource removal including memblock and linear
mapping tear down during memory hot remove which will now be the reverse
order in which they were added during memory hot add. The changed removal
order looks like the following.
try_remove_memory() {
..
arch_remove_memory()
..
memblock_free()
memblock_remove()
..
}
[rcu:dev.2019.09.23a 50/77] kernel//rcu/update.c:871:3: note: in expansion of macro 'kfree_rcu'
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2019.09.23a
head: 97de53b94582c208ee239178b208b8e8b9472585
commit: 89538f9f8dda5e7738d71f179f9321740b680734 [50/77] rcu: Add crude
self-test for early boot kfree_rcu()
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 89538f9f8dda5e7738d71f179f9321740b680734
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Note: the rcu/dev.2019.09.23a HEAD 97de53b94582c208ee239178b208b8e8b9472585
builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
kernel//rcu/update.c: In function 'early_boot_test_call_rcu':
>> kernel//rcu/update.c:869:8: error: implicit declaration of function
>> 'kmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration]
rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
^~~
kvmalloc
>> kernel//rcu/update.c:869:6: warning: assignment makes pointer from integer
>> without a cast [-Wint-conversion]
rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
^
In file included from include/linux/rbtree.h:22:0,
from include/linux/hrtimer.h:16,
from include/linux/interrupt.h:13,
from kernel//rcu/update.c:25:
>> include/linux/rcupdate.h:840:15: error: passing argument 1 of
>> 'kfree_call_rcu' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
__kfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \
^
include/linux/rcupdate.h:806:18: note: in definition of macro '__kfree_rcu'
kfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \
^~~~
>> kernel//rcu/update.c:871:3: note: in expansion of macro 'kfree_rcu'
kfree_rcu(rhp, rh);
^
In file included from include/linux/rcupdate.h:171:0,
from include/linux/rbtree.h:22,
from include/linux/hrtimer.h:16,
from include/linux/interrupt.h:13,
from kernel//rcu/update.c:25:
include/linux/rcutree.h:36:6: note: expected 'struct callback_head *' but
argument is of type 'struct callback_head **'
void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
^~
cc1: some warnings being treated as errors
--
kernel/rcu/update.c: In function 'early_boot_test_call_rcu':
kernel/rcu/update.c:869:8: error: implicit declaration of function
'kmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration]
rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
^~~
kvmalloc
kernel/rcu/update.c:869:6: warning: assignment makes pointer from integer
without a cast [-Wint-conversion]
rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
^
In file included from include/linux/rbtree.h:22:0,
from include/linux/hrtimer.h:16,
from include/linux/interrupt.h:13,
from kernel/rcu/update.c:25:
>> include/linux/rcupdate.h:840:15: error: passing argument 1 of
>> 'kfree_call_rcu' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
__kfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \
^
include/linux/rcupdate.h:806:18: note: in definition of macro '__kfree_rcu'
kfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \
^~~~
kernel/rcu/update.c:871:3: note: in expansion of macro 'kfree_rcu'
kfree_rcu(rhp, rh);
^
In file included from include/linux/rcupdate.h:171:0,
from include/linux/rbtree.h:22,
from include/linux/hrtimer.h:16,
from include/linux/interrupt.h:13,
from kernel/rcu/update.c:25:
include/linux/rcutree.h:36:6: note: expected 'struct callback_head *' but
argument is of type 'struct callback_head **'
void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
^~
cc1: some warnings being treated as errors
vim +/kfree_rcu +871 kernel//rcu/update.c
859
860 static void early_boot_test_call_rcu(void)
861 {
862 static struct rcu_head head;
863 static struct rcu_head shead;
864 struct early_boot_kfree_rcu *rhp;
865
866 call_rcu(, test_callback);
867 if (IS_ENABLED(CONFIG_SRCU))
868 call_srcu(_srcu, , test_callback);
> 869 rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
870 if (!WARN_ON_ONCE(!rhp))
> 871 kfree_rcu(rhp, rh);
872 }
873
RE: [PATCH] usb: hub add filter for device with specific VID
Hi Alan,
On Monday, September 23, 2019 23:01, Alan Stern wrote:
>
> On Mon, 23 Sep 2019, Ran Wang wrote:
>
> > USB 2.0 Embedded Host PET Automated Test (CH6) 6.7.23 A-UUT
> > "Unsupported Device" Message require to stop enumerating device with
> > VID=0x1a0a PID=0x0201 and pop message to declare this device is not
> supported.
> >
> > Signed-off-by: Ran Wang
> > ---
> > drivers/usb/core/hub.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> > bbcfa63..3cda0da 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -4982,6 +4982,18 @@ static void hub_port_connect(struct usb_hub *hub,
> int port1, u16 portstatus,
> > if (status < 0)
> > goto loop;
> >
> > +/* USB 2.0 Embedded Host PET Automated Test (CH6)
> > +* 6.7.23 A-UUT "Unsupported Device" Message
> > +* require to filter out below device when enumeration
> > +*/
> > + if ((udev->descriptor.idVendor == 0x1a0a)
> > +&& (udev->descriptor.idProduct == 0x0201)) {
> > + dev_err(>dev, "This device is not supported:
> idVendor=0x%x idProduct=0x%x\n",
> > + udev->descriptor.idVendor,
> > + udev->descriptor.idProduct);
>
> There's no need to write out the Vendor and Product IDs. They already appear
> in the "New device" message.
OK
> > + goto done;
> > + }
> > +
> > if (udev->quirks & USB_QUIRK_DELAY_INIT)
> > msleep(2000);
>
> Shouldn't this be implemented as a device quirk?
Yes, I was also looking for the way in quirk but not quite sure currently.
So we can stop initializing a device (with specific VID) in quirk, right?
Actually in drivers/usb/core/hub.c function usb_enumerate_device(), it will
call is_targeted(udev) which has below implementation:
54 /* OTG PET device is always targeted (see OTG 2.0 ECN 6.4.2) */
55 if ((le16_to_cpu(dev->descriptor.idVendor) == 0x1a0a &&
56 le16_to_cpu(dev->descriptor.idProduct) == 0x0200))
57 return 1;
The ID is very close to what I need to response. So, do I need to add code here?
Thanks.
Ran
Re: [GIT PULL] SafeSetID LSM changes for 5.4
On Mon, Sep 23, 2019 at 5:45 PM Linus Torvalds wrote: > > On Mon, Sep 23, 2019 at 4:35 PM James Morris > wrote: > > > > My understanding is that SafeSetID is shipping in ChromeOS -- this was > > part of the rationale for merging it. > > Well, if even the developer didn't test it for two months, I don't > think "it's in upstream" makes any sense or difference. > > Linus Yes, SafeSetID is shipping on Chrome OS, although I agree having that bug in 5.3 without anyone noticing is bad. When Jann sent the last round of patches for 5.3 he had tested the code and everything looked good, although I unfortunately neglected to test it again after a tweak to one of the patches, which of course broke stuff when the patches ultimately went in. Even though this is enabled in production for Chrome OS, none of the Chrome OS devices are using version 5.3 yet, so it went unnoticed on Chrome OS so far. In general the fact that a kernel feature is shipping on Chrome OS isn't an up-to-date assurance that the feature works in the most recent Linux release, as it would likely be months (at least) from when a change makes it into the kernel until that kernel release is ever run on a Chrome OS device (right now the most recent kernel we ship on Chrome OS is 4.19, so I've had to backport the SafeSetID stuff). We've found this SafeSetID LSM to be pretty useful on Chrome OS, and more use cases have popped up than we had in mind when writing it, which suggests others would potentially find it useful as well. But I understand for it to be useful to others it needs to be stable and functional on every release. The best way I know of ensuring this is for me to personally run the SafeSetID selftest (in tools/testing/selftests/safesetid/) every release, regardless of whether we make any changes to SafeSetID itself. Does this sound sufficient or are there more formal guidelines/processes here that I'm not aware of?
RE: [PATCH v2] usb: dwc3: enable otg mode for dwc3 usb ip on layerscape
Hi,
Change in v2:
move the otg property from dtsi to dts.
Regards,
Yinbo Zhu.
-Original Message-
From: Yinbo Zhu
Sent: 2019年9月24日 11:29
To: Shawn Guo ; Leo Li ; Rob Herring
; Mark Rutland
Cc: Yinbo Zhu ; Xiaobo Xie ; Jiafei Pan
; Ran Wang ;
linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: [PATCH v2] usb: dwc3: enable otg mode for dwc3 usb ip on layerscape
layerscape otg function should be supported HNP SRP and ADP protocol accroing
to rm doc, but dwc3 code not realize it and use id pin to detect who is host or
device(0 is host 1 is device) this patch is to enable OTG mode on ls1028ardb
ls1088ardb and ls1046ardb in dts
Signed-off-by: Yinbo Zhu
---
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 4
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 4
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 1 +
3 files changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 9fb9113..076cac6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -171,3 +171,7 @@
{
status = "okay";
};
+
+ {
+ dr_mode = "otg";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 6a6514d..0c742be 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -122,6 +122,10 @@
};
};
+ {
+ dr_mode = "otg";
+};
+
#include "fsl-ls1046-post.dtsi"
{
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 8e925df..90b1989 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -95,5 +95,6 @@
};
{
+ dr_mode = "otg";
status = "okay";
};
--
2.9.5
Re: [PATCH 1/1] PCI: iproc: Invalidate PAXB address mapping before programming it
Hi Bjorn/Lorenzo,
Can you please help review this patch?
Regards,
Abhishek
On Fri, Sep 6, 2019 at 7:41 PM Abhishek Shah wrote:
>
> Hi Andrew,
>
>
> On Fri, Sep 6, 2019 at 3:31 PM Andrew Murray wrote:
> >
> > On Fri, Sep 06, 2019 at 02:55:19PM +0530, Abhishek Shah wrote:
> > > Hi Andrew,
> > >
> > > Thanks for the review. Please see my response inline:
> > >
> > > On Fri, Sep 6, 2019 at 2:08 PM Andrew Murray
> > > wrote:
> > > >
> > > > On Fri, Sep 06, 2019 at 09:28:13AM +0530, Abhishek Shah wrote:
> > > > > Invalidate PAXB inbound/outbound address mapping each time before
> > > > > programming it. This is helpful for the cases where we need to
> > > > > reprogram inbound/outbound address mapping without resetting PAXB.
> > > > > kexec kernel is one such example.
> > > >
> > > > Why is this approach better than resetting the PAXB (I assume that's
> > > > the PCI controller IP)? Wouldn't resetting the PAXB address this issue,
> > > > and ensure that no other configuration is left behind?
> > > >
> > > We normally reset PAXB in the firmware(ATF). But for cases like kexec
> > > kernel boot,
> > > we do not execute any firmware code and directly boot into kernel.
> > >
> > > We could have done PAXB reset in the driver itself as you have suggested
> > > here.
> > > But note that this detail could vary for each SoC, because these
> > > registers are not part
> > > of PAXB register space itself, rather exists in a register space
> > > responsible for
> > > controlling power to various wrappers in PCIe IP. Normally, this kind
> > > of SoC specific
> > > details are handled in firmware itself, we don't bring them to driver
> > > level.
> >
> > OK understood.
> >
> > >
> > > > Or is this related to earlier boot stages loading firmware for the
> > > > emulated
> > > > downstream endpoints (ep_is_internal)?
> > > >
> > > > Finally, in the case where ep_is_internal do you need to disable
> > > > anything
> > > > prior to invalidating the mappings?
> > > >
> > > No, ep_is_internal is indicator for PAXC IP. It does not have
> > > mappings as in PAXB.
> >
> > I think I meant !ep_is_internal. I.e. is there possibility of inbound
> > traffic
> > prior to invalidating the mappings. I'd assume not, but that's an
> > assumption.
> >
> No, EP devices are not even enumerated yet.
>
> > Either way:
> >
> > Reviewed-by: Andrew Murray
> >
> > >
> > >
> > > Regards,
> > > Abhishek
> > > > >
> > > > > Signed-off-by: Abhishek Shah
> > > > > Reviewed-by: Ray Jui
> > > > > Reviewed-by: Vikram Mysore Prakash
> > > > > ---
> > > > > drivers/pci/controller/pcie-iproc.c | 28
> > > > > 1 file changed, 28 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/controller/pcie-iproc.c
> > > > > b/drivers/pci/controller/pcie-iproc.c
> > > > > index e3ca46497470..99a9521ba7ab 100644
> > > > > --- a/drivers/pci/controller/pcie-iproc.c
> > > > > +++ b/drivers/pci/controller/pcie-iproc.c
> > > > > @@ -1245,6 +1245,32 @@ static int iproc_pcie_map_dma_ranges(struct
> > > > > iproc_pcie *pcie)
> > > > > return ret;
> > > > > }
> > > > >
> > > > > +static void iproc_pcie_invalidate_mapping(struct iproc_pcie *pcie)
> > > > > +{
> > > > > + struct iproc_pcie_ib *ib = >ib;
> > > > > + struct iproc_pcie_ob *ob = >ob;
> > > > > + int idx;
> > > > > +
> > > > > + if (pcie->ep_is_internal)
> > > > > + return;
> > > > > +
> > > > > + if (pcie->need_ob_cfg) {
> > > > > + /* iterate through all OARR mapping regions */
> > > > > + for (idx = ob->nr_windows - 1; idx >= 0; idx--) {
> > > > > + iproc_pcie_write_reg(pcie,
> > > > > + MAP_REG(IPROC_PCIE_OARR0,
> > > > > idx), 0);
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + if (pcie->need_ib_cfg) {
> > > > > + /* iterate through all IARR mapping regions */
> > > > > + for (idx = 0; idx < ib->nr_regions; idx++) {
> > > > > + iproc_pcie_write_reg(pcie,
> > > > > + MAP_REG(IPROC_PCIE_IARR0,
> > > > > idx), 0);
> > > > > + }
> > > > > + }
> > > > > +}
> > > > > +
> > > > > static int iproce_pcie_get_msi(struct iproc_pcie *pcie,
> > > > > struct device_node *msi_node,
> > > > > u64 *msi_addr)
> > > > > @@ -1517,6 +1543,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie,
> > > > > struct list_head *res)
> > > > > iproc_pcie_perst_ctrl(pcie, true);
> > > > > iproc_pcie_perst_ctrl(pcie, false);
> > > > >
> > > > > + iproc_pcie_invalidate_mapping(pcie);
> > > > > +
> > > > > if (pcie->need_ob_cfg) {
> > > > > ret = iproc_pcie_map_ranges(pcie, res);
> > > > > if (ret) {
> > > >
> > > > The code changes look good to me.
> > > >
> > > > Thanks,
> > > >
> > > > Andrew Murray
> > > >
> > > > > --
> > > > > 2.17.1
> > >
[PATCH v2] usb: dwc3: enable otg mode for dwc3 usb ip on layerscape
layerscape otg function should be supported HNP SRP and ADP protocol
accroing to rm doc, but dwc3 code not realize it and use id pin to
detect who is host or device(0 is host 1 is device) this patch is to
enable OTG mode on ls1028ardb ls1088ardb and ls1046ardb in dts
Signed-off-by: Yinbo Zhu
---
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 4
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 4
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 1 +
3 files changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 9fb9113..076cac6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -171,3 +171,7 @@
{
status = "okay";
};
+
+ {
+ dr_mode = "otg";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 6a6514d..0c742be 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -122,6 +122,10 @@
};
};
+ {
+ dr_mode = "otg";
+};
+
#include "fsl-ls1046-post.dtsi"
{
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 8e925df..90b1989 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -95,5 +95,6 @@
};
{
+ dr_mode = "otg";
status = "okay";
};
--
2.9.5
[PATCH v2] thermal: qoriq: add thermal monitor unit version 2 support
Thermal Monitor Unit v2 is introduced on new Layscape SoC.
Compared to v1, TMUv2 has a little different register layout
and digital output is fairly linear.
Signed-off-by: Yuantian Tang
---
v2:
- refine the code: remove redundant variable, rename variable etc.
drivers/thermal/qoriq_thermal.c | 121 +---
1 file changed, 97 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 7b364933bfb1..43617e53554b 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -12,7 +12,16 @@
#include "thermal_core.h"
-#define SITES_MAX 16
+#define SITES_MAX 16
+#define TMR_DISABLE0x0
+#define TMR_ME 0x8000
+#define TMR_ALPF 0x0c00
+#define TMR_ALPF_V20x0300
+#define TMTMIR_DEFAULT 0x000f
+#define TIER_DISABLE 0x0
+#define TEUMR0_V2 0x51009c00
+#define TMU_VER1 0x1
+#define TMU_VER2 0x2
/*
* QorIQ TMU Registers
@@ -23,17 +32,55 @@ struct qoriq_tmu_site_regs {
u8 res0[0x8];
};
-struct qoriq_tmu_regs {
+struct qoriq_tmu_regs_v2 {
+ u32 tmr;/* Mode Register */
+ u32 tsr;/* Status Register */
+ u32 tmsr; /* monitor site register */
+ u32 tmtmir; /* Temperature measurement interval Register */
+ u8 res0[0x10];
+ u32 tier; /* Interrupt Enable Register */
+ u32 tidr; /* Interrupt Detect Register */
+ u8 res1[0x8];
+ u32 tiiscr; /* interrupt immediate site capture register */
+ u32 tiascr; /* interrupt average site capture register */
+ u32 ticscr; /* Interrupt Critical Site Capture Register */
+ u32 res2;
+ u32 tmhtcr; /* monitor high temperature capture register */
+ u32 tmltcr; /* monitor low temperature capture register */
+ u32 tmrtrcr;/* monitor rising temperature rate capture register */
+ u32 tmftrcr;/* monitor falling temperature rate capture register */
+ u32 tmhtitr;/* High Temperature Immediate Threshold */
+ u32 tmhtatr;/* High Temperature Average Threshold */
+ u32 tmhtactr; /* High Temperature Average Crit Threshold */
+ u32 res3;
+ u32 tmltitr;/* monitor low temperature immediate threshold */
+ u32 tmltatr;/* monitor low temperature average threshold register */
+ u32 tmltactr; /* monitor low temperature average critical threshold */
+ u32 res4;
+ u32 tmrtrctr; /* monitor rising temperature rate critical threshold */
+ u32 tmftrctr; /* monitor falling temperature rate critical threshold*/
+ u8 res5[0x8];
+ u32 ttcfgr; /* Temperature Configuration Register */
+ u32 tscfgr; /* Sensor Configuration Register */
+ u8 res6[0x78];
+ struct qoriq_tmu_site_regs site[SITES_MAX];
+ u8 res7[0x9f8];
+ u32 ipbrr0; /* IP Block Revision Register 0 */
+ u32 ipbrr1; /* IP Block Revision Register 1 */
+ u8 res8[0x300];
+ u32 teumr0;
+ u32 teumr1;
+ u32 teumr2;
+ u32 res9;
+ u32 ttrcr[4]; /* Temperature Range Control Register */
+};
+
+struct qoriq_tmu_regs_v1 {
u32 tmr;/* Mode Register */
-#define TMR_DISABLE0x0
-#define TMR_ME 0x8000
-#define TMR_ALPF 0x0c00
u32 tsr;/* Status Register */
u32 tmtmir; /* Temperature measurement interval Register */
-#define TMTMIR_DEFAULT 0x000f
u8 res0[0x14];
u32 tier; /* Interrupt Enable Register */
-#define TIER_DISABLE 0x0
u32 tidr; /* Interrupt Detect Register */
u32 tiscr; /* Interrupt Site Capture Register */
u32 ticscr; /* Interrupt Critical Site Capture Register */
@@ -53,10 +100,7 @@ struct qoriq_tmu_regs {
u32 ipbrr0; /* IP Block Revision Register 0 */
u32 ipbrr1; /* IP Block Revision Register 1 */
u8 res6[0x310];
- u32 ttr0cr; /* Temperature Range 0 Control Register */
- u32 ttr1cr; /* Temperature Range 1 Control Register */
- u32 ttr2cr; /* Temperature Range 2 Control Register */
- u32 ttr3cr; /* Temperature Range 3 Control Register */
+ u32 ttrcr[4]; /* Temperature Range Control Register */
};
struct qoriq_tmu_data;
@@ -71,7 +115,9 @@ struct qoriq_sensor {
};
struct qoriq_tmu_data {
- struct qoriq_tmu_regs __iomem *regs;
+ int ver;
+ struct qoriq_tmu_regs_v1 __iomem *regs;
+ struct qoriq_tmu_regs_v2 __iomem *regs_v2;
bool little_endian;
struct qoriq_sensor *sensor[SITES_MAX];
};
@@ -130,12
RE: [PATCH] usb: hub add filter for device with specific VID
Hi Greg,
On Monday, September 23, 2019 19:07, Greg Kroah-Hartman wrote:
>
> On Mon, Sep 23, 2019 at 06:51:02PM +0800, Ran Wang wrote:
> > USB 2.0 Embedded Host PET Automated Test (CH6) 6.7.23 A-UUT
> > "Unsupported Device" Message require to stop enumerating device with
> > VID=0x1a0a PID=0x0201 and pop message to declare this device is not
> supported.
>
> Why is this a requirement?
This comes from
Below is related description I quote from it:
6.7.23 A-UUT "Unsupported Device" Message
Purpose: This test verifies that an A-UUT produces a device non-supported error
message
when a device it doesn't recognize, and does not support HNP, connects
to it.
Applies to: All Targeted Hosts
Description: Get VBUS turned on, and connect to the A-UUT. Get enumerated and
respond
as an unknown device not supporting HNP. Check that a suitable error
message is generated.
Pass Criteria: Message "Unsupported Device"or similar is displayed on UUT
6.7.23.1 Test Procedure
1. Start with cable still attached, PET applying 10μF capacitance and 10kΩ
pull-down
resistance between VBUS and ground, data lines not pulled up.
2. Get VBUS turned on, using the method described in Section6.7.1.
3. Wait for almost TB_SVLD_BCON max (1s - 0.1s = 0.9s) from VBUS reaching
VOTG_SESS_VLD max.
4. Connect PET using D+ pull-up.
5. Allow A-UUT to enumerate PET, responding with a VID / PID combination not on
the TPL
of the UUT and also with the OTG descriptor stating that it does not
support HNP.
6. Start 30s timer when Device Descriptor is read.
7. Display Message "Click OK if 'Unsupported Device' indication displayed on
UUT".
8. If operator clicks OK before 30s timer expires, then UUT passes test.
9. If 30selapses first, then UUT fails test.
10. PET disconnects by removing any termination on the data lines, but leaves a
capacitance of
10μF and a pull-down resistance of 10kΩ connected across VBUS.
11. Wait 2s to allow disconnection to be detected.
End of Test.
> And why those specific vid/pid values? What do they refer to?
For step 5, we got the VID / PID number from USB IF certified lab(Allion.inc at
Taiwang). Looks like
this is a reserved ID pair and will not be allocated to any vendor for their
products. So it's hence used for this
case test (like saying: you should be able to pop a not-support message for
this reserved VID).
> >
> > Signed-off-by: Ran Wang
> > ---
> > drivers/usb/core/hub.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> > bbcfa63..3cda0da 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -4982,6 +4982,18 @@ static void hub_port_connect(struct usb_hub *hub,
> int port1, u16 portstatus,
> > if (status < 0)
> > goto loop;
> >
> > +/* USB 2.0 Embedded Host PET Automated Test (CH6)
> > +* 6.7.23 A-UUT "Unsupported Device" Message
> > +* require to filter out below device when enumeration
> > +*/
>
> Nit, can you align your comment lines, to match the other multi-line comments
> in this file? Otherwise it starts to look bad over time.
Yes, will update.
>
>
> > + if ((udev->descriptor.idVendor == 0x1a0a)
> > +&& (udev->descriptor.idProduct == 0x0201)) {
>
> Are you sure you don't have to convert this value into cpu endian before
> checking it?
Thanks for pointing out, how about this:
if ((le16_to_cpu(udev->descriptor.idVendor) == 0x1a0a)
&& (le16_to_cpu(udev->descriptor.idProduct) == 0x0201)) {
Regards,
Ran
Re: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
Hi Peng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Peng-Fan/mailbox-arm-introduce-smc-triggered-mailbox/20190924-091652
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.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.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from :0:0:
>> include/linux/mailbox/arm-smccc-mbox.h:17:3: error: unknown type name 'u32'
u32 args_smccc32[6];
^~~
>> include/linux/mailbox/arm-smccc-mbox.h:18:3: error: unknown type name 'u64'
u64 args_smccc64[6];
^~~
vim +/u32 +17 include/linux/mailbox/arm-smccc-mbox.h
5
6 /**
7 * struct arm_smccc_mbox_cmd - ARM SMCCC message structure
8 * @function_id:function id passed from client, If mbox
9 * DT has arm,func-id property, the driver will use
10 * that one.
11 * @args_smccc32/64:actual usage of registers is up to the protocol
12 * (within the SMCCC limits)
13 */
14 struct arm_smccc_mbox_cmd {
15 unsigned int function_id;
16 union {
> 17 u32 args_smccc32[6];
> 18 u64 args_smccc64[6];
19 };
20 };
21
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v4 05/10] mm: Return faster for non-fatal signals in user mode faults
On Mon, Sep 23, 2019 at 07:54:47PM -0700, Matthew Wilcox wrote:
> On Tue, Sep 24, 2019 at 10:47:21AM +0800, Peter Xu wrote:
> > On Mon, Sep 23, 2019 at 11:03:49AM -0700, Linus Torvalds wrote:
> > > On Sun, Sep 22, 2019 at 9:26 PM Peter Xu wrote:
> > > >
> > > > This patch is a preparation of removing that special path by allowing
> > > > the page fault to return even faster if we were interrupted by a
> > > > non-fatal signal during a user-mode page fault handling routine.
> > >
> > > So I really wish saome other vm person would also review these things,
> > > but looking over this series once more, this is the patch I probably
> > > like the least.
> > >
> > > And the reason I like it the least is that I have a hard time
> > > explaining to myself what the code does and why, and why it's so full
> > > of this pattern:
> > >
> > > > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> > > > + if ((fault & VM_FAULT_RETRY) &&
> > > > + fault_should_check_signal(user_mode(regs)))
> > > > return;
> > >
> > > which isn't all that pretty.
> > >
> > > Why isn't this just
> > >
> > > static bool fault_signal_pending(unsigned int fault_flags, struct
> > > pt_regs *regs)
> > > {
> > > return (fault_flags & VM_FAULT_RETRY) &&
> > > (fatal_signal_pending(current) ||
> > > (user_mode(regs) && signal_pending(current)));
> > > }
> > >
> > > and then most of the users would be something like
> > >
> > > if (fault_signal_pending(fault, regs))
> > > return;
> > >
> > > and the exceptions could do their own thing.
> > >
> > > Now the code is prettier and more understandable, I feel.
> > >
> > > And if something doesn't follow this pattern, maybe it either _should_
> > > follow that pattern or it should just not use the helper but explain
> > > why it has an unusual pattern.
>
> > +++ b/arch/alpha/mm/fault.c
> > @@ -150,7 +150,7 @@ do_page_fault(unsigned long address, unsigned long
> > mmcsr,
> >the fault. */
> > fault = handle_mm_fault(vma, address, flags);
> >
> > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> > + if (fault_signal_pending(fault, regs))
> > return;
> >
> > if (unlikely(fault & VM_FAULT_ERROR)) {
>
> > +++ b/arch/arm/mm/fault.c
> > @@ -301,6 +301,11 @@ do_page_fault(unsigned long addr, unsigned int fsr,
> > struct pt_regs *regs)
> > return 0;
> > }
> >
> > + /* Fast path to handle user mode signals */
> > + if ((fault & VM_FAULT_RETRY) && user_mode(regs) &&
> > + signal_pending(current))
> > + return 0;
>
> But _why_ are they different? This is a good opportunity to make more
> code the same between architectures.
(Thanks for joining the discussion)
I'd like to do these - my only worry is that I can't really test them
well simply because I don't have all the hardwares. For now the
changes are mostly straightforward so I'm relatively confident (not to
mention the code needs proper reviews too, and of course I would
appreciate much if anyone wants to smoke test it). If I change it in
a drastic way, I won't be that confident without some tests at least
on multiple archs (not to mention that even smoke testing across major
archs will be a huge amount of work...). So IMHO those might be more
suitable as follow-up for per-arch developers if we can at least reach
a consensus on the whole idea of this patchset.
Thanks,
--
Peter Xu
RE: [PATCH v5 2/3] dmaengine: imx-sdma: fix dma freezes
On 2019-9-23 21:58 Philipp Puschmann wrote:
> For some years and since many kernel versions there are reports that the RX
> UART SDMA channel stops working at some point. The workaround was to
> disable DMA for RX. This commit fixes the problem itself. Cyclic DMA transfers
> are used by uart and other drivers and these can fail in at least two cases
> where we can run out of descriptors available to the
> engine:
> - Interrupts are disabled for too long and all buffers are filled with
> data, especially in a setup where many small dma transfers are being
> executed only using a tiny part of a single buffer
> - DMA errors (such as generated by baud rate mismatch with imx-uart)
> use up all descriptors before we can react.
>
> In this case, SDMA stops the channel and no further transfers are done until
> the respective channel is disabled and re-enabled. We can check if the
> channel has been stopped and re-enable it then. To distinguish from the the
> case that the channel was stopped by upper-level driver we introduce new
> flag IMX_DMA_ACTIVE.
>
> As sdmac->desc is constant we can move desc out of the loop.
>
> Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
> Signed-off-by: Philipp Puschmann
> Signed-off-by: Jan Luebbe
> Reviewed-by: Lucas Stach
> ---
>
> Changelog v5:
> - join with patch version from Jan Luebbe
> - adapt comments and patch descriptions
>
> Changelog v4:
> - fixed the fixes tag
>
> Changelog v3:
> - use correct dma_wmb() instead of dma_wb()
> - add fixes tag
>
> Changelog v2:
> - clarify comment and commit description
>
> drivers/dma/imx-sdma.c | 26 ++
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
> b42281604e54..0b1d6a62423d 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -383,6 +383,7 @@ struct sdma_channel { };
>
> #define IMX_DMA_SG_LOOP BIT(0)
> +#define IMX_DMA_ACTIVE BIT(1)
>
> #define MAX_DMA_CHANNELS 32
> #define MXC_SDMA_DEFAULT_PRIORITY 1
> @@ -658,6 +659,9 @@ static int sdma_config_ownership(struct
> sdma_channel *sdmac,
>
> static void sdma_enable_channel(struct sdma_engine *sdma, int channel) {
> + struct sdma_channel *sdmac = >channel[channel];
> +
> + sdmac->flags |= IMX_DMA_ACTIVE;
Add spin_lock_irq protect this flags.
> writel(BIT(channel), sdma->regs + SDMA_H_START); }
>
> @@ -774,16 +778,17 @@ static void sdma_start_desc(struct sdma_channel
> *sdmac)
>
> static void sdma_update_channel_loop(struct sdma_channel *sdmac) {
> + struct sdma_engine *sdma = sdmac->sdma;
> struct sdma_buffer_descriptor *bd;
> + struct sdma_desc *desc = sdmac->desc;
> int error = 0;
> - enum dma_status old_status = sdmac->status;
> + enum dma_status old_status = sdmac->status;
>
> /*
>* loop mode. Iterate over descriptors, re-setup them and
>* call callback function.
>*/
> - while (sdmac->desc) {
> - struct sdma_desc *desc = sdmac->desc;
> + while (desc) {
>
> bd = >bd[desc->buf_tail];
>
> @@ -822,6 +827,18 @@ static void sdma_update_channel_loop(struct
> sdma_channel *sdmac)
> if (error)
> sdmac->status = old_status;
> }
> +
> + /* In some situations it may happen that the sdma does not find any
> + * usable descriptor in the ring to put data into. The channel is
> + * stopped then and after having freed some buffers we have to restart
> + * it manually.
> + */
> + if ((sdmac->flags & IMX_DMA_ACTIVE) &&
> + !(readl_relaxed(sdma->regs + SDMA_H_STATSTOP) &
> BIT(sdmac->channel))) {
Seems duplicate checking here, IMX_DMA_ACTIVE is enough.
> + dev_err_ratelimited(sdma->dev, "SDMA channel %d: cyclic transfer
> disabled by HW, reenabling\n",
Would you change the print log to below:
"cyclic bds consumed all,reenableing".?
> + sdmac->channel);
> + writel(BIT(sdmac->channel), sdma->regs + SDMA_H_START);
> + };
> }
>
> static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
> @@ -1051,7 +1068,8 @@ static int sdma_disable_channel(struct dma_chan
> *chan)
> struct sdma_engine *sdma = sdmac->sdma;
> int channel = sdmac->channel;
>
> - writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
> + sdmac->flags &= ~IMX_DMA_ACTIVE;
> + writel(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
> sdmac->status = DMA_ERROR;
>
> return 0;
> --
> 2.23.0
RE: [EXT] Re: [PATCH v5] arm64: dts: ls1028a: Add esdhc node in dts
Hi Shawn Guo, I see that you had merged my patch, but I don't see that in url = git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git master branch. Please help check. Regards, Yinbo Zhu -Original Message- From: Shawn Guo Sent: 2019年8月19日 21:11 To: Yinbo Zhu Cc: Leo Li ; Rob Herring ; Mark Rutland ; linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Xiaobo Xie ; Jiafei Pan ; Y.b. Lu ; Ashish Kumar Subject: [EXT] Re: [PATCH v5] arm64: dts: ls1028a: Add esdhc node in dts Caution: EXT Email On Thu, Aug 15, 2019 at 11:39:01AM +0800, Yinbo Zhu wrote: > From: Ashish Kumar > > This patch is to add esdhc node and enable SD UHS-I, eMMC HS200 for > ls1028ardb/ls1028aqds board. > > Signed-off-by: Ashish Kumar > Signed-off-by: Yangbo Lu > Signed-off-by: Yinbo Zhu Applied, thanks.
Re: [PATCH V8 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
On 9/23/2019 6:14 PM, Peng Fan wrote: > From: Peng Fan > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > actions in software layers running in the EL2 or EL3 exception levels. > The term "ARM" here relates to the SMC instruction as part of the ARM > instruction set, not as a standard endorsed by ARM Ltd. > > Signed-off-by: Peng Fan Reviewed-by: Florian Fainelli Thanks! -- Florian
[PATCH] remoteproc: debug: Remove unneeded NULL check
debugfs_remove_recursive will do NULL check, so remove
the redundant null check
Signed-off-by: Ding Xiang
---
drivers/remoteproc/remoteproc_debugfs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index 8cd4a0a..dd93cf0 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -333,9 +333,6 @@ struct dentry *rproc_create_trace_file(const char *name,
struct rproc *rproc,
void rproc_delete_debug_dir(struct rproc *rproc)
{
- if (!rproc->dbg_dir)
- return;
-
debugfs_remove_recursive(rproc->dbg_dir);
}
--
1.9.1
Re: [PATCH -next] scsi: hisi_sas: Make three functions static
YueHaibing, > Fix sparse warnings: > > drivers/scsi/hisi_sas/hisi_sas_main.c:3686:6: > warning: symbol 'hisi_sas_debugfs_release' was not declared. Should it be > static? > drivers/scsi/hisi_sas/hisi_sas_main.c:3708:5: > warning: symbol 'hisi_sas_debugfs_alloc' was not declared. Should it be > static? > drivers/scsi/hisi_sas/hisi_sas_main.c:3799:6: > warning: symbol 'hisi_sas_debugfs_bist_init' was not declared. Should it be > static? Applied to 5.4/scsi-fixes, thanks! -- Martin K. Petersen Oracle Linux Engineering
[v3,2/3] arm: dts: ls1021a: fix that FlexTimer cannot wakeup system in deep sleep
The patch fix a bug that FlexTimer cannot
wakeup system in deep sleep.
Signed-off-by: Biwen Li
---
Change in v3:
- update property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- None
arch/arm/boot/dts/ls1021a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index e3973b611c3a..383b2dcd5720 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -1000,6 +1000,7 @@
compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
reg = <0x0 0x1ee2140 0x0 0x8>;
#fsl,rcpm-wakeup-cells = <2>;
+ fsl,ippdexpcr-alt-addr = < 0x0 0x51c>; /*
SCFG_SPARECR8 */
};
ftm_alarm0: timer0@29d {
--
2.17.1
[v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
The 'fsl,ippdexpcr-alt-addr' property is used to handle an errata A-008646
on LS1021A
Signed-off-by: Biwen Li
---
Change in v3:
- rename property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- update desc of the property 'fsl,rcpm-scfg'
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index 5a33619d881d..157dcf6da17c 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -34,6 +34,11 @@ Chassis Version Example Chips
Optional properties:
- little-endian : RCPM register block is Little Endian. Without it RCPM
will be Big Endian (default case).
+ - fsl,ippdexpcr-alt-addr : Must add the property for SoC LS1021A,
+ Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
+ #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).
+ The first entry must be a link to the SCFG device node.
+ The non-first entry must be offset of registers of SCFG.
Example:
The RCPM node for T4240:
@@ -43,6 +48,15 @@ The RCPM node for T4240:
#fsl,rcpm-wakeup-cells = <2>;
};
+The RCPM node for LS1021A:
+ rcpm: rcpm@1ee2140 {
+ compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
+ reg = <0x0 0x1ee2140 0x0 0x8>;
+ #fsl,rcpm-wakeup-cells = <2>;
+ fsl,ippdexpcr-alt-addr = < 0x0 0x51c>; /* SCFG_SPARECR8 */
+ };
+
+
* Freescale RCPM Wakeup Source Device Tree Bindings
---
Required fsl,rcpm-wakeup property should be added to a device node if the
device
--
2.17.1
[v3,1/3] soc: fsl: handle RCPM errata A-008646 on SoC LS1021A
Description:
- Reading configuration register RCPM_IPPDEXPCR1
always return zero
Workaround:
- Save register RCPM_IPPDEXPCR1's value to
register SCFG_SPARECR8.(uboot's psci also
need reading value from the register SCFG_SPARECR8
to set register RCPM_IPPDEXPCR1)
Impact:
- FlexTimer module will cannot wakeup system in
deep sleep on SoC LS1021A
Signed-off-by: Biwen Li
---
Change in v3:
- update commit message
- rename property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- fix stype problems
drivers/soc/fsl/rcpm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index 82c0ad5e663e..7f42b17d3f29 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#define RCPM_WAKEUP_CELL_MAX_SIZE 7
@@ -29,6 +31,9 @@ static int rcpm_pm_prepare(struct device *dev)
struct rcpm *rcpm;
u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
int i, ret, idx;
+ struct regmap * scfg_addr_regmap = NULL;
+ u32 reg_offset[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
+ u32 reg_value = 0;
rcpm = dev_get_drvdata(dev);
if (!rcpm)
@@ -63,6 +68,22 @@ static int rcpm_pm_prepare(struct device *dev)
tmp |= value[i + 1];
iowrite32be(tmp, rcpm->ippdexpcr_base +
i * 4);
}
+ /* Workaround of errata A-008646 on SoC
LS1021A: There is a bug of
+* register ippdexpcr1. Reading configuration
register RCPM_IPPDEXPCR1
+* always return zero. So save ippdexpcr1's
value to register SCFG_SPARECR8.
+* And the value of ippdexpcr1 will be read
from SCFG_SPARECR8.
+*/
+ scfg_addr_regmap =
syscon_regmap_lookup_by_phandle(np, "fsl,ippdexpcr-alt-addr");
+ if (scfg_addr_regmap) {
+ if
(of_property_read_u32_array(dev->of_node,
+ "fsl,ippdexpcr-alt-addr",
reg_offset, rcpm->wakeup_cells + 1)) {
+ scfg_addr_regmap = NULL;
+ continue;
+ }
+ regmap_read(scfg_addr_regmap,
reg_offset[i + 1], _value);
+ /* Write value to register
SCFG_SPARECR8 */
+ regmap_write(scfg_addr_regmap,
reg_offset[i + 1], tmp | reg_value);
+ }
}
}
} while (ws = wakeup_source_get_next(ws));
--
2.17.1
Re: [PATCH 14/17] KVM: monolithic: x86: inline more exit handlers in vmx.c
On Mon, Sep 23, 2019 at 09:55:27PM -0400, Andrea Arcangeli wrote: > This commit I reverted adds literally 3 inlines called by 3 functions, > in a very fast path, how many bytes of .text difference did you expect > by dropping some call/ret from a very fast path when you asked me to > test it? I mean it's just a couple of insn each. > > I thought the question was if gcc was already inlining without the > hint or not or if it actually grew in size in case I got it wrong and > there were many callers and it was better off not inline, so now I > don't get what was the point of this test if with the result that > confirms it's needed, the patch should be dropped. > > It's possible that this patch may not be relevant anymore with the > rename in place of the vmx/svm functions, but if this patch is to be > dropped with the optimal result, then I recommend you to go ahead and > submit a patch to drop __always_inline from the whole kernel because > if it's not good to use it here in a extreme fast path like > handle_external_interrupt and handle_halt, then I don't know what > __always_inline is good for anywhere else in the kernel. Thinking more at this I don't think the result of the size check was nearly enough to come to any conclusion. The only probably conclusion one can take is that if the size didn't change it was a fail, because there would be high probability that it wouldn't be beneficial because it was a noop (even that wouldn't be 100% certain). One needs to look at why it changed to take any conclusion, and the reason it got smaller is that all dynamic tracing for ftrace was dropped, the functions were already inlined fine in the RETPOLINE case. Those are tiny functions so it looks a positive thing to make them as small as possible, there are already proper tracepoints in kvm_exit/kvm_entry for bpf tracing all all KVM events so there's no need of the fentry in those tiny functions with just an instruction that are only ever compiled as static because of the pointer to function. This however also means it helps the CONFIG_RETPOLINE=n case and it doesn't help at all the CONFIG_RETPOLINE=y case, so it's fully orthogonal to the patchset and can be splitted off but I think it's worth it. Thanks, Andrea
RE: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
Hi Florian > Subject: Re: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox > > Hi Peng, > > On 9/23/2019 6:14 PM, Peng Fan wrote: > > From: Peng Fan > > > > This mailbox driver implements a mailbox which signals transmitted > > data via an ARM smc (secure monitor call) instruction. The mailbox > > receiver is implemented in firmware and can synchronously return data > > when it returns execution to the non-secure world again. > > An asynchronous receive path is not implemented. > > This allows the usage of a mailbox to trigger firmware actions on SoCs > > which either don't have a separate management processor or on which > > such a core is not available. A user of this mailbox could be the SCP > > interface. > > > > Modified from Andre Przywara's v2 patch > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7 > Cpeng.fa > > > n%40nxp.com%7C296c7cd2225e4ca32bb808d74099afb2%7C686ea1d3bc2b4 > c6fa92cd > > > 99c5c301635%7C0%7C0%7C637048901144091126sdata=JDo%2Be7Tt > hoi4jve0O > > S8qe3%2Fpji4g8CgRxL7ntCQx3Fg%3Dreserved=0 > > > > Cc: Andre Przywara > > Signed-off-by: Peng Fan > > --- > > [snip] > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > > + unsigned long, unsigned long, > > + unsigned long, unsigned long, > > + unsigned long); > > +static smc_mbox_fn *invoke_smc_mbox_fn; > > Sorry for spotting this so late, the only thing that concerns me here with > this > singleton is if we happen to have both an arm,smc-mbox and arm,hvc-mbox > configured in the system, this would not work. Yes. Thanks for spotting this. I do not believe this could be a > functional use case, but we should probably guard against that or better yet, > move that into the arm_smc_chan_data private structure? Agree. Will Fix in v9. Thanks, Peng. > -- > Florian
Re: [PATCH v4 05/10] mm: Return faster for non-fatal signals in user mode faults
On Tue, Sep 24, 2019 at 10:47:21AM +0800, Peter Xu wrote:
> On Mon, Sep 23, 2019 at 11:03:49AM -0700, Linus Torvalds wrote:
> > On Sun, Sep 22, 2019 at 9:26 PM Peter Xu wrote:
> > >
> > > This patch is a preparation of removing that special path by allowing
> > > the page fault to return even faster if we were interrupted by a
> > > non-fatal signal during a user-mode page fault handling routine.
> >
> > So I really wish saome other vm person would also review these things,
> > but looking over this series once more, this is the patch I probably
> > like the least.
> >
> > And the reason I like it the least is that I have a hard time
> > explaining to myself what the code does and why, and why it's so full
> > of this pattern:
> >
> > > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> > > + if ((fault & VM_FAULT_RETRY) &&
> > > + fault_should_check_signal(user_mode(regs)))
> > > return;
> >
> > which isn't all that pretty.
> >
> > Why isn't this just
> >
> > static bool fault_signal_pending(unsigned int fault_flags, struct
> > pt_regs *regs)
> > {
> > return (fault_flags & VM_FAULT_RETRY) &&
> > (fatal_signal_pending(current) ||
> > (user_mode(regs) && signal_pending(current)));
> > }
> >
> > and then most of the users would be something like
> >
> > if (fault_signal_pending(fault, regs))
> > return;
> >
> > and the exceptions could do their own thing.
> >
> > Now the code is prettier and more understandable, I feel.
> >
> > And if something doesn't follow this pattern, maybe it either _should_
> > follow that pattern or it should just not use the helper but explain
> > why it has an unusual pattern.
> +++ b/arch/alpha/mm/fault.c
> @@ -150,7 +150,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
> the fault. */
> fault = handle_mm_fault(vma, address, flags);
>
> - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> + if (fault_signal_pending(fault, regs))
> return;
>
> if (unlikely(fault & VM_FAULT_ERROR)) {
> +++ b/arch/arm/mm/fault.c
> @@ -301,6 +301,11 @@ do_page_fault(unsigned long addr, unsigned int fsr,
> struct pt_regs *regs)
> return 0;
> }
>
> + /* Fast path to handle user mode signals */
> + if ((fault & VM_FAULT_RETRY) && user_mode(regs) &&
> + signal_pending(current))
> + return 0;
But _why_ are they different? This is a good opportunity to make more
code the same between architectures.
Re: [Patch v4] storvsc: setup 1:1 mapping between hardware queue and CPU queue
Long, > storvsc doesn't use a dedicated hardware queue for a given CPU > queue. When issuing I/O, it selects returning CPU (hardware queue) > dynamically based on vmbus channel usage across all channels. Applied to 5.4/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH v5 5/6] platform/x86: huawei-wmi: Add fn-lock support
Huawei Matebook laptops uses Fn key and toggle to access F1-F12 keys.
Along with that, there is this feature called fn-lock that inverts the
behavior of this Fn key and the F1-F12 row.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 85 +++
1 file changed, 85 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 6e791f9ffc26..d550c63fcba7 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -54,6 +54,7 @@ static struct quirk_entry *quirks;
struct huawei_wmi {
bool battery_available;
+ bool fn_lock_available;
struct input_dev *idev[2];
struct led_classdev cdev;
@@ -509,6 +510,88 @@ static void huawei_wmi_battery_exit(struct device *dev)
}
}
+/* Fn lock */
+
+static int huawei_wmi_fn_lock_get(int *on)
+{
+ u8 ret[0x100] = { 0 };
+ int err, i;
+
+ err = huawei_wmi_cmd(FN_LOCK_GET, ret, 0x100);
+ if (err)
+ return err;
+
+ /* Find the first non-zero value. Return status is ignored. */
+ i = 1;
+ do {
+ if (on)
+ *on = ret[i] - 1; // -1 undefined, 0 off, 1 on.
+ } while (i < 0xff && !ret[i++]);
+
+ return 0;
+}
+
+static int huawei_wmi_fn_lock_set(int on)
+{
+ union hwmi_arg arg;
+
+ arg.cmd = FN_LOCK_SET;
+ arg.args[2] = on + 1; // 0 undefined, 1 off, 2 on.
+
+ return huawei_wmi_cmd(arg.cmd, NULL, 0);
+}
+
+static ssize_t fn_lock_state_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, on;
+
+ err = huawei_wmi_fn_lock_get();
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d\n", on);
+}
+
+static ssize_t fn_lock_state_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int on, err;
+
+ if (kstrtoint(buf, 10, ) ||
+ on < 0 || on > 1)
+ return -EINVAL;
+
+ err = huawei_wmi_fn_lock_set(on);
+ if (err)
+ return err;
+
+ return size;
+}
+
+static DEVICE_ATTR_RW(fn_lock_state);
+
+static void huawei_wmi_fn_lock_setup(struct device *dev)
+{
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
+
+ huawei->fn_lock_available = true;
+ if (huawei_wmi_fn_lock_get(NULL)) {
+ huawei->fn_lock_available = false;
+ return;
+ }
+
+ device_create_file(dev, _attr_fn_lock_state);
+}
+
+static void huawei_wmi_fn_lock_exit(struct device *dev)
+{
+ if (huawei_wmi->fn_lock_available)
+ device_remove_file(dev, _attr_fn_lock_state);
+}
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
@@ -632,6 +715,7 @@ static int huawei_wmi_probe(struct platform_device *pdev)
mutex_init(_wmi->battery_lock);
huawei_wmi_leds_setup(>dev);
+ huawei_wmi_fn_lock_setup(>dev);
huawei_wmi_battery_setup(>dev);
}
@@ -651,6 +735,7 @@ static int huawei_wmi_remove(struct platform_device *pdev)
if (wmi_has_guid(HWMI_METHOD_GUID)) {
huawei_wmi_battery_exit(>dev);
+ huawei_wmi_fn_lock_exit(>dev);
}
return 0;
--
2.21.0
[PATCH] pinctrl: cherryview: restore Strago DMI workaround for all versions
This is essentially a revert of:
e3f72b749da2 pinctrl: cherryview: fix Strago DMI workaround
86c5dd6860a6 pinctrl: cherryview: limit Strago DMI workarounds to version 1.0
because even with 1.1 versions of BIOS there are some pins that are
configured as interrupts but not claimed by any driver, and they
sometimes fire up and result in interrupt storms that cause touchpad
stop functioning and other issues.
Given that we are unlikely to qualify another firmware version for a
while it is better to keep the workaround active on all Strago boards.
Reported-by: Alex Levin
Fixes: 86c5dd6860a6 ("pinctrl: cherryview: limit Strago DMI workarounds to
version 1.0")
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov
---
drivers/pinctrl/intel/pinctrl-cherryview.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c
b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 03ec7a5d9d0b..bf049d1bbb87 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1513,7 +1513,6 @@ static const struct dmi_system_id chv_no_valid_mask[] = {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
DMI_MATCH(DMI_PRODUCT_FAMILY, "Intel_Strago"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
},
},
{
@@ -1521,7 +1520,6 @@ static const struct dmi_system_id chv_no_valid_mask[] = {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "HP"),
DMI_MATCH(DMI_PRODUCT_NAME, "Setzer"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
},
},
{
@@ -1529,7 +1527,6 @@ static const struct dmi_system_id chv_no_valid_mask[] = {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
DMI_MATCH(DMI_PRODUCT_NAME, "Cyan"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
},
},
{
@@ -1537,7 +1534,6 @@ static const struct dmi_system_id chv_no_valid_mask[] = {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
DMI_MATCH(DMI_PRODUCT_NAME, "Celes"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
},
},
{}
--
2.23.0.351.gc4317032e6-goog
--
Dmitry
[PATCH v5 6/6] platform/x86: huawei-wmi: Add debugfs support
Add a debugfs interface that can be used to call the WMI management
interface function if available.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 97 +++
1 file changed, 97 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index d550c63fcba7..6720f78c60c2 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -52,10 +53,16 @@ struct quirk_entry {
static struct quirk_entry *quirks;
+struct huawei_wmi_debug {
+ struct dentry *root;
+ u64 arg;
+};
+
struct huawei_wmi {
bool battery_available;
bool fn_lock_available;
+ struct huawei_wmi_debug debug;
struct input_dev *idev[2];
struct led_classdev cdev;
struct platform_device *pdev;
@@ -592,6 +599,94 @@ static void huawei_wmi_fn_lock_exit(struct device *dev)
device_remove_file(dev, _attr_fn_lock_state);
}
+/* debugfs */
+
+static void huawei_wmi_debugfs_call_dump(struct seq_file *m, void *data,
+ union acpi_object *obj)
+{
+ struct huawei_wmi *huawei = m->private;
+ int i;
+
+ switch (obj->type) {
+ case ACPI_TYPE_INTEGER:
+ seq_printf(m, "0x%llx", obj->integer.value);
+ break;
+ case ACPI_TYPE_STRING:
+ seq_printf(m, "\"%*s\"", obj->string.length,
obj->string.pointer);
+ break;
+ case ACPI_TYPE_BUFFER:
+ seq_puts(m, "{");
+ for (i = 0; i < obj->buffer.length; i++) {
+ seq_printf(m, "0x%02x", obj->buffer.pointer[i]);
+ if (i < obj->buffer.length - 1)
+ seq_puts(m, ",");
+ }
+ seq_puts(m, "}");
+ break;
+ case ACPI_TYPE_PACKAGE:
+ seq_puts(m, "[");
+ for (i = 0; i < obj->package.count; i++) {
+ huawei_wmi_debugfs_call_dump(m, huawei,
>package.elements[i]);
+ if (i < obj->package.count - 1)
+ seq_puts(m, ",");
+ }
+ seq_puts(m, "]");
+ break;
+ default:
+ dev_err(>pdev->dev, "Unexpected obj type, got %d\n",
obj->type);
+ return;
+ }
+}
+
+static int huawei_wmi_debugfs_call_show(struct seq_file *m, void *data)
+{
+ struct huawei_wmi *huawei = m->private;
+ struct acpi_buffer out = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer in;
+ union acpi_object *obj;
+ int err;
+
+ in.length = sizeof(u64);
+ in.pointer = >debug.arg;
+
+ err = huawei_wmi_call(, );
+ if (err)
+ return err;
+
+ obj = out.pointer;
+ if (!obj) {
+ err = -EIO;
+ goto fail_debugfs_call;
+ }
+
+ huawei_wmi_debugfs_call_dump(m, huawei, obj);
+
+fail_debugfs_call:
+ kfree(out.pointer);
+ return err;
+}
+
+DEFINE_SHOW_ATTRIBUTE(huawei_wmi_debugfs_call);
+
+static void huawei_wmi_debugfs_setup(struct device *dev)
+{
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
+
+ huawei->debug.root = debugfs_create_dir("huawei-wmi", NULL);
+
+ debugfs_create_x64("arg", 0644, huawei->debug.root,
+ >debug.arg);
+ debugfs_create_file("call", 0400,
+ huawei->debug.root, huawei, _wmi_debugfs_call_fops);
+}
+
+static void huawei_wmi_debugfs_exit(struct device *dev)
+{
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
+
+ debugfs_remove_recursive(huawei->debug.root);
+}
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
@@ -717,6 +812,7 @@ static int huawei_wmi_probe(struct platform_device *pdev)
huawei_wmi_leds_setup(>dev);
huawei_wmi_fn_lock_setup(>dev);
huawei_wmi_battery_setup(>dev);
+ huawei_wmi_debugfs_setup(>dev);
}
return 0;
@@ -734,6 +830,7 @@ static int huawei_wmi_remove(struct platform_device *pdev)
}
if (wmi_has_guid(HWMI_METHOD_GUID)) {
+ huawei_wmi_debugfs_exit(>dev);
huawei_wmi_battery_exit(>dev);
huawei_wmi_fn_lock_exit(>dev);
}
--
2.21.0
[PATCH v5 4/6] platform/x86: huawei-wmi: Add battery charging thresholds
Control battery charge thresholds through the battery API and driver's
attributes.
Setting battery charging thresholds can introduce a race condition with
MACH-WX9 where two or more threads are trying to read/write values
from/to EC memory.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/huawei-wmi.c | 212 ++
2 files changed, 213 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 754405e19ef1..e64103789885 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1306,6 +1306,7 @@ config INTEL_ATOMISP2_PM
config HUAWEI_WMI
tristate "Huawei WMI laptop extras driver"
+ depends on ACPI_BATTERY
depends on ACPI_WMI
depends on INPUT
select INPUT_SPARSEKMAP
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 41904b1cc284..6e791f9ffc26 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -13,7 +14,10 @@
#include
#include
#include
+#include
+#include
#include
+#include
/*
* Huawei WMI GUIDs
@@ -49,10 +53,13 @@ struct quirk_entry {
static struct quirk_entry *quirks;
struct huawei_wmi {
+ bool battery_available;
+
struct input_dev *idev[2];
struct led_classdev cdev;
struct platform_device *pdev;
+ struct mutex battery_lock;
struct mutex wmi_lock;
};
@@ -300,6 +307,208 @@ static void huawei_wmi_leds_setup(struct device *dev)
devm_led_classdev_register(dev, >cdev);
}
+/* Battery protection */
+
+static int huawei_wmi_battery_get(int *start, int *end)
+{
+ u8 ret[0x100];
+ int err, i;
+
+ err = huawei_wmi_cmd(BATTERY_THRESH_GET, ret, 0x100);
+ if (err)
+ return err;
+
+ /* Find the last two non-zero values. Return status is ignored. */
+ i = 0xff;
+ do {
+ if (start)
+ *start = ret[i-1];
+ if (end)
+ *end = ret[i];
+ } while (i > 2 && !ret[i--]);
+
+ return 0;
+}
+
+static int huawei_wmi_battery_set(int start, int end)
+{
+ union hwmi_arg arg;
+ int err;
+
+ if (start < 0 || end > 100)
+ return -EINVAL;
+
+ arg.cmd = BATTERY_THRESH_SET;
+ arg.args[2] = start;
+ arg.args[3] = end;
+
+ /* This is an edge case were some models turn battery protection
+* off without changing their thresholds values. We clear the
+* values before turning off protection. Sometimes we need a sleep
delay to
+* make sure these values make their way to EC memory.
+*/
+ if (quirks && quirks->battery_reset && start == 0 && end == 100) {
+ err = huawei_wmi_battery_set(0, 0);
+ if (err)
+ return err;
+
+ msleep(1000);
+ }
+
+ err = huawei_wmi_cmd(arg.cmd, NULL, 0);
+
+ return err;
+}
+
+static ssize_t charge_control_start_threshold_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, start;
+
+ err = huawei_wmi_battery_get(, NULL);
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d\n", start);
+}
+
+static ssize_t charge_control_end_threshold_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, end;
+
+ err = huawei_wmi_battery_get(NULL, );
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d\n", end);
+}
+
+static ssize_t charge_control_thresholds_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, start, end;
+
+ err = huawei_wmi_battery_get(, );
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d %d\n", start, end);
+}
+
+static ssize_t charge_control_start_threshold_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int err, start, end;
+
+ err = huawei_wmi_battery_get(NULL, );
+ if (err)
+ return err;
+
+ if (sscanf(buf, "%d", ) != 1)
+ return -EINVAL;
+
+ err = huawei_wmi_battery_set(start, end);
+ if (err)
+ return err;
+
+ return size;
+}
+
+static ssize_t charge_control_end_threshold_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int err, start, end;
+
+ err = huawei_wmi_battery_get(, NULL);
+ if (err)
+ return err;
+
+ if (sscanf(buf, "%d", ) != 1)
+ return -EINVAL;
+
+ err = huawei_wmi_battery_set(start, end);
+ if (err)
+
[PATCH v5 1/6] platform/x86: huawei-wmi: Move to platform driver
Move from WMI driver to platform driver. This move is necessary since
the driver is no longer a hotkeys driver only. Platform driver makes it
easier for users to access sysfs attributes under (i.e.
/sys/devices/platform/huawei-wmi) compared to wmi driver.
Use WMI device UID, AMW0 has a UID of HWMI. WMI0 is the device name
and doesn't have a UID so keep it as it is.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 7 +-
drivers/platform/x86/huawei-wmi.c | 226 --
2 files changed, 156 insertions(+), 77 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ae21d08c65e8..754405e19ef1 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1305,7 +1305,7 @@ config INTEL_ATOMISP2_PM
will be called intel_atomisp2_pm.
config HUAWEI_WMI
- tristate "Huawei WMI hotkeys driver"
+ tristate "Huawei WMI laptop extras driver"
depends on ACPI_WMI
depends on INPUT
select INPUT_SPARSEKMAP
@@ -1314,9 +1314,8 @@ config HUAWEI_WMI
select LEDS_TRIGGER_AUDIO
select NEW_LEDS
help
- This driver provides support for Huawei WMI hotkeys.
- It enables the missing keys and adds support to the micmute
- LED found on some of these laptops.
+ This driver provides support for Huawei WMI hotkeys, battery charge
+ control, fn-lock, mic-mute LED, and other extra features.
To compile this driver as a module, choose M here: the module
will be called huawei-wmi.
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 195a7f3638cb..9496ea3c78b5 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Huawei WMI hotkeys
+ * Huawei WMI laptop extras driver
*
* Copyright (C) 2018 Ayman Bagabas
*/
@@ -10,23 +10,28 @@
#include
#include
#include
+#include
#include
/*
* Huawei WMI GUIDs
*/
-#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
-#define AMW0_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+#define HWMI_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+/* Legacy GUIDs */
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
+#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
-struct huawei_wmi_priv {
- struct input_dev *idev;
+struct huawei_wmi {
+ struct input_dev *idev[2];
struct led_classdev cdev;
+ struct platform_device *pdev;
acpi_handle handle;
char *acpi_method;
};
+struct huawei_wmi *huawei_wmi;
+
static const struct key_entry huawei_wmi_keymap[] = {
{ KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
{ KE_KEY,0x282, { KEY_BRIGHTNESSUP } },
@@ -37,7 +42,7 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_KEY,0x289, { KEY_WLAN } },
// Huawei |M| key
{ KE_KEY,0x28a, { KEY_CONFIG } },
- // Keyboard backlight
+ // Keyboard backlit
{ KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } },
{ KE_IGNORE, 0x294, { KEY_KBDILLUMUP } },
{ KE_IGNORE, 0x295, { KEY_KBDILLUMUP } },
@@ -47,7 +52,7 @@ static const struct key_entry huawei_wmi_keymap[] = {
static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(led_cdev->dev->parent);
+ struct huawei_wmi *huawei = dev_get_drvdata(led_cdev->dev->parent);
acpi_status status;
union acpi_object args[3];
struct acpi_object_list arg_list = {
@@ -58,52 +63,53 @@ static int huawei_wmi_micmute_led_set(struct led_classdev
*led_cdev,
args[0].type = args[1].type = args[2].type = ACPI_TYPE_INTEGER;
args[1].integer.value = 0x04;
- if (strcmp(priv->acpi_method, "SPIN") == 0) {
+ if (strcmp(huawei->acpi_method, "SPIN") == 0) {
args[0].integer.value = 0;
args[2].integer.value = brightness ? 1 : 0;
- } else if (strcmp(priv->acpi_method, "WPIN") == 0) {
+ } else if (strcmp(huawei->acpi_method, "WPIN") == 0) {
args[0].integer.value = 1;
args[2].integer.value = brightness ? 0 : 1;
} else {
return -EINVAL;
}
- status = acpi_evaluate_object(priv->handle, priv->acpi_method,
_list, NULL);
+ status = acpi_evaluate_object(huawei->handle, huawei->acpi_method,
_list, NULL);
if (ACPI_FAILURE(status))
return -ENXIO;
return 0;
}
-static int huawei_wmi_leds_setup(struct wmi_device *wdev)
+static void huawei_wmi_leds_setup(struct device *dev)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(>dev);
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
- priv->handle = ec_get_handle();
- if
[PATCH v5 0/6] platform/x86: Huawei WMI laptop extras driver
Changes in v5: * Fix a possible buffer overflow error. Changes in v4: * Use int and bint for module params. Changes in v3: * Kconfig changes * Fix NULL cast to int warning. * Add ACPI_BATTERY as a dependency. Changes in v2: * Use battery charge control API. This patch series introduce changes to huawei-wmi driver that includes: * Move to platform driver * Implement driver quirks and parameters * Implement WMI management interface * Add micmute LED support through WMI * Add battery charging protection support through WMI * Add fn-lock support through WMI * Add a debugfs interface to WMI # Move to platform driver The current driver offers hotkeys and micmute led support only. With these changes, a platform driver makes more sense since it handles these changes pretty nicely. # Implement WMI management interface Huawei Matebook laptops come with two WMI interfaces. The first being WMI0 which is considered "legacy" and AFAIK only found on the Matebook X released in 2017. The second has a UID of "HWMI" and is found in pretty much all models with a slight difference in implementation except for the Matebook X (2017). Since this model has two interfaces, some aspects are controlled through the legacy interface and some through the other interface. Currently, the legacy interface is not fully implemented and is only used for hotkeys and further debugging has to be done. The WMI interface takes a 64 bit integer, although uses 32 bits most of the time, and returns a 256-260 bytes buffer consists of either one ACPI buffer of 260 bytes, in the case of Matebook X (2017), or one ACPI package of two buffers, one with 4 bytes, and the other with 256 bytes. We only care about the latter 256 buffer in both cases since the 4 bytes always return zeros. The first byte of this 256 buffer always has the return status where 1 indicated error. Some models require calling the WMI interface twice to execute a command. # Add micmute LED support through WMI After implementing the WMI interface, micmute LED can be controlled easily. Models with the legacy interface fall back to ACPI EC method control since the legacy interface is not implemented. # Add battery charging protection support through WMI Most models, that has the WMI interface, are capable of battery protection where it can control battery charging thresholds and limits charging the battery to certain values. # Add fn-lock support through WMI The behavior of hotkeys is not the same among all models. Some models require fn-lock to do things like `Ctrl-Ins` or `Alt-PrtSc`. By default, hotkeys behave as special keys (media keys, Ins, etc), but if a modifier is used (ctrl, alt, shift) these keys behave as F1-F12 keys. If the Fn key is toggled on, the hotkeys with or without a modifier, behave as F1-F12 keys. This makes it impossible to use a modifier and `PrtSc` or `Ins`. Now, some models fix this by excluding `PrtSc` and `Ins` keys from being treated as F11 and F12 keys with the use of a modifier. However, some models do not, and fixes this by the so called fn-lock. Fn-lock inverts the behavior of the top row from special keys to F1-F12 keys. So a modifier and a special key would be possible which make things like `Alt-Ins` possible. Now, with fn-lock we would have 4 modes: * Fn-key off & fn-lock off - hotkeys treated as special keys using a modifier gives F1-F12 keys. * Fn-key on & fn-lock off - hotkeys treated as F1-F12 keys and using a modifier gives F1-F12. * Fn-key off & fn-lock on - hotkeys are treated as F1-F12 keys and using a modifier gives special keys. * Fn-key on & fn-lock on - hotkeys are treated as special keys and using a modifier gives special keys. # Implement driver quirks and parameters The driver introduces 3 quirks and 2 parameters that can change the driver's behavior. These quirks being as: 1. Fixes reporting brightness keys twice since it's already handled by acpi-video. 2. Some models need a short delay when setting battery thresholds to prevent a race condition when two processes read/write. 3. Matebook X (2017) handles micmute led through the "legacy" interface which is not currently implemented. Use ACPI EC method to control this led. and the 2 parameters can enforce the behavior of quirk 1 & 2. # Add a debugfs interface to WMI An interface to the WMI management interface that allows easier debugging. Ayman Bagabas (6): platform/x86: huawei-wmi: Move to platform driver platform/x86: huawei-wmi: Add quirks and module parameters platform/x86: huawei-wmi: Implement huawei wmi management platform/x86: huawei-wmi: Add battery charging thresholds platform/x86: huawei-wmi: Add fn-lock support platform/x86: huawei-wmi: Add debugfs support drivers/platform/x86/Kconfig | 8 +- drivers/platform/x86/huawei-wmi.c | 874 ++ 2 files changed, 786 insertions(+), 96 deletions(-) base-commit: b5b3bd898ba99fb0fb6aed3b23ec6353a1724d6f -- 2.21.0
[PATCH v5 2/6] platform/x86: huawei-wmi: Add quirks and module parameters
Introduce quirks and module parameters. 3 quirks are added:
1. Fixes reporting brightness keys twice since it's already handled by
acpi-video.
2. Some models need a short delay when setting battery thresholds to
prevent a race condition when two processes read/write. (will be used later)
3. Matebook X (2017) handles micmute led through the "legacy" interface
which is not currently implemented. Use ACPI EC method to control
this led. (will be used later)
2 module parameters are added to enable this short delay and/or report
brightness keys through this driver.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 9496ea3c78b5..0e919bf56ad1 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -22,6 +23,14 @@
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+struct quirk_entry {
+ bool battery_reset;
+ bool ec_micmute;
+ bool report_brightness;
+};
+
+static struct quirk_entry *quirks;
+
struct huawei_wmi {
struct input_dev *idev[2];
struct led_classdev cdev;
@@ -49,6 +58,58 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_END,0 }
};
+static int battery_reset = -1;
+static int report_brightness = -1;
+
+module_param(battery_reset, bint, 0444);
+MODULE_PARM_DESC(battery_reset,
+ "Reset battery charge values to (0-0) before disabling it using
(0-100)");
+module_param(report_brightness, bint, 0444);
+MODULE_PARM_DESC(report_brightness,
+ "Report brightness keys.");
+
+/* Quirks */
+
+static int __init dmi_matched(const struct dmi_system_id *dmi)
+{
+ quirks = dmi->driver_data;
+ return 1;
+}
+
+static struct quirk_entry quirk_unknown = {
+};
+
+static struct quirk_entry quirk_battery_reset = {
+ .battery_reset = true,
+};
+
+static struct quirk_entry quirk_matebook_x = {
+ .ec_micmute = true,
+ .report_brightness = true,
+};
+
+static const struct dmi_system_id huawei_quirks[] = {
+ {
+ .callback = dmi_matched,
+ .ident = "Huawei MACH-WX9",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MACH-WX9"),
+ },
+ .driver_data = _battery_reset
+ },
+ {
+ .callback = dmi_matched,
+ .ident = "Huawei MateBook X",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HUAWEI MateBook X")
+ },
+ .driver_data = _matebook_x
+ },
+ { }
+};
+
static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -139,6 +200,11 @@ static void huawei_wmi_process_key(struct input_dev *idev,
int code)
return;
}
+ if (quirks && !quirks->report_brightness &&
+ (key->sw.code == KEY_BRIGHTNESSDOWN ||
+ key->sw.code == KEY_BRIGHTNESSUP))
+ return;
+
sparse_keymap_report_entry(idev, key, 1, true);
}
@@ -253,6 +319,13 @@ static __init int huawei_wmi_init(void)
if (!huawei_wmi)
return -ENOMEM;
+ quirks = _unknown;
+ dmi_check_system(huawei_quirks);
+ if (battery_reset != -1)
+ quirks->battery_reset = battery_reset;
+ if (report_brightness != -1)
+ quirks->report_brightness = report_brightness;
+
err = platform_driver_register(_wmi_driver);
if (err)
goto pdrv_err;
--
2.21.0
[PATCH v5 3/6] platform/x86: huawei-wmi: Implement huawei wmi management
Huawei Matebook laptops come with a WMI management interface that can
control various aspects of the device. This interface is also found on
the old Matebook X released in 2017.
Use that to control the mic mute LED.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 217 +-
1 file changed, 180 insertions(+), 37 deletions(-)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 0e919bf56ad1..41904b1cc284 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -11,18 +11,35 @@
#include
#include
#include
+#include
#include
#include
/*
* Huawei WMI GUIDs
*/
+#define HWMI_METHOD_GUID "ABBC0F5B-8EA1-11D1-A000-C9062910"
#define HWMI_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
/* Legacy GUIDs */
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+/* HWMI commands */
+
+enum {
+ BATTERY_THRESH_GET = 0x1103, /* \GBTT */
+ BATTERY_THRESH_SET = 0x1003, /* \SBTT */
+ FN_LOCK_GET = 0x0604, /* \GFRS */
+ FN_LOCK_SET = 0x0704, /* \SFRS */
+ MICMUTE_LED_SET = 0x0b04, /* \SMLS */
+};
+
+union hwmi_arg {
+ u64 cmd;
+ u8 args[8];
+};
+
struct quirk_entry {
bool battery_reset;
bool ec_micmute;
@@ -35,8 +52,8 @@ struct huawei_wmi {
struct input_dev *idev[2];
struct led_classdev cdev;
struct platform_device *pdev;
- acpi_handle handle;
- char *acpi_method;
+
+ struct mutex wmi_lock;
};
struct huawei_wmi *huawei_wmi;
@@ -110,52 +127,168 @@ static const struct dmi_system_id huawei_quirks[] = {
{ }
};
+/* Utils */
+
+static int huawei_wmi_call(struct acpi_buffer *in, struct acpi_buffer *out)
+{
+ acpi_status status;
+
+ mutex_lock(_wmi->wmi_lock);
+ status = wmi_evaluate_method(HWMI_METHOD_GUID, 0, 1, in, out);
+ mutex_unlock(_wmi->wmi_lock);
+ if (ACPI_FAILURE(status)) {
+ dev_err(_wmi->pdev->dev, "Failed to evaluate wmi
method\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/* HWMI takes a 64 bit input and returns either a package with 2 buffers, one
of
+ * 4 bytes and the other of 256 bytes, or one buffer of size 0x104 (260) bytes.
+ * The first 4 bytes are ignored, we ignore the first 4 bytes buffer if we got
a
+ * package, or skip the first 4 if a buffer of 0x104 is used. The first byte of
+ * the remaining 0x100 sized buffer has the return status of every call. In
case
+ * the return status is non-zero, we return -ENODEV but still copy the returned
+ * buffer to the given buffer parameter (buf).
+ */
+static int huawei_wmi_cmd(u64 arg, u8 *buf, size_t buflen)
+{
+ struct acpi_buffer out = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer in;
+ union acpi_object *obj;
+ size_t len;
+ int err, i;
+
+ in.length = sizeof(arg);
+ in.pointer =
+
+ /* Some models require calling HWMI twice to execute a command. We
evaluate
+* HWMI and if we get a non-zero return status we evaluate it again.
+*/
+ for (i = 0; i < 2; i++) {
+ err = huawei_wmi_call(, );
+ if (err)
+ goto fail_cmd;
+
+ obj = out.pointer;
+ if (!obj) {
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ switch (obj->type) {
+ /* Models that implement both "legacy" and HWMI tend to return
a 0x104
+* sized buffer instead of a package of 0x4 and 0x100 buffers.
+*/
+ case ACPI_TYPE_BUFFER:
+ if (obj->buffer.length == 0x104) {
+ // Skip the first 4 bytes.
+ obj->buffer.pointer += 4;
+ len = 0x100;
+ } else {
+ dev_err(_wmi->pdev->dev, "Bad buffer
length, got %d\n", obj->buffer.length);
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ break;
+ /* HWMI returns a package with 2 buffer elements, one of 4
bytes and the
+* other is 256 bytes.
+*/
+ case ACPI_TYPE_PACKAGE:
+ if (obj->package.count != 2) {
+ dev_err(_wmi->pdev->dev, "Bad package
count, got %d\n", obj->package.count);
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ obj = >package.elements[1];
+ if (obj->type != ACPI_TYPE_BUFFER) {
+
Re: [PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
Hi Peng, On 9/23/2019 6:14 PM, Peng Fan wrote: > From: Peng Fan > > This mailbox driver implements a mailbox which signals transmitted data > via an ARM smc (secure monitor call) instruction. The mailbox receiver > is implemented in firmware and can synchronously return data when it > returns execution to the non-secure world again. > An asynchronous receive path is not implemented. > This allows the usage of a mailbox to trigger firmware actions on SoCs > which either don't have a separate management processor or on which such > a core is not available. A user of this mailbox could be the SCP > interface. > > Modified from Andre Przywara's v2 patch > https://lore.kernel.org/patchwork/patch/812999/ > > Cc: Andre Przywara > Signed-off-by: Peng Fan > --- [snip] > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long, > + unsigned long, unsigned long, > + unsigned long, unsigned long, > + unsigned long); > +static smc_mbox_fn *invoke_smc_mbox_fn; Sorry for spotting this so late, the only thing that concerns me here with this singleton is if we happen to have both an arm,smc-mbox and arm,hvc-mbox configured in the system, this would not work. I do not believe this could be a functional use case, but we should probably guard against that or better yet, move that into the arm_smc_chan_data private structure? -- Florian
Re: [PATCH v4 05/10] mm: Return faster for non-fatal signals in user mode faults
On Mon, Sep 23, 2019 at 11:03:49AM -0700, Linus Torvalds wrote:
> On Sun, Sep 22, 2019 at 9:26 PM Peter Xu wrote:
> >
> > This patch is a preparation of removing that special path by allowing
> > the page fault to return even faster if we were interrupted by a
> > non-fatal signal during a user-mode page fault handling routine.
>
> So I really wish saome other vm person would also review these things,
> but looking over this series once more, this is the patch I probably
> like the least.
>
> And the reason I like it the least is that I have a hard time
> explaining to myself what the code does and why, and why it's so full
> of this pattern:
>
> > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> > + if ((fault & VM_FAULT_RETRY) &&
> > + fault_should_check_signal(user_mode(regs)))
> > return;
>
> which isn't all that pretty.
>
> Why isn't this just
>
> static bool fault_signal_pending(unsigned int fault_flags, struct
> pt_regs *regs)
> {
> return (fault_flags & VM_FAULT_RETRY) &&
> (fatal_signal_pending(current) ||
> (user_mode(regs) && signal_pending(current)));
> }
>
> and then most of the users would be something like
>
> if (fault_signal_pending(fault, regs))
> return;
>
> and the exceptions could do their own thing.
>
> Now the code is prettier and more understandable, I feel.
>
> And if something doesn't follow this pattern, maybe it either _should_
> follow that pattern or it should just not use the helper but explain
> why it has an unusual pattern.
I see the point on why this patch is disliked - Yeh it should look
better to have a single function to cover the most common cases.
Besides, I attempted to squash the extra signal_pending() check into
some existing code path but maybe it's not really benefiting much
while instead it makes the review even harder. So I plan to isolate
those paths out too, from something like:
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -291,14 +291,15 @@ do_page_fault(unsigned long addr, unsigned int fsr,
struct pt_regs *regs)
fault = __do_page_fault(mm, addr, fsr, flags, tsk);
- /* If we need to retry but a fatal signal is pending, handle the
+ /* If we need to retry but a signal is pending, try to handle the
* signal first. We do not need to release the mmap_sem because
* it would already be released in __lock_page_or_retry in
* mm/filemap.c. */
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
- if (!user_mode(regs))
+ if (unlikely(fault & VM_FAULT_RETRY && signal_pending(current))) {
+ if (fatal_signal_pending(current) && !user_mode(regs))
goto no_context;
- return 0;
+ if (user_mode(regs))
+ return 0;
}
into:
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -301,6 +301,11 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
return 0;
}
+ /* Fast path to handle user mode signals */
+ if ((fault & VM_FAULT_RETRY) && user_mode(regs) &&
+ signal_pending(current))
+ return 0;
+
/*
* Major/minor page fault accounting is only done on the
* initial attempt. If we go through a retry, it is extremely
I hope it'll be better with that. A complete patch attached too.
Thanks,
--
Peter Xu
>From 2583226afc24bb51b78cf36484f0c5b064b1f75d Mon Sep 17 00:00:00 2001
From: Peter Xu
Date: Thu, 1 Nov 2018 09:55:29 +0800
Subject: [PATCH] mm: Return faster for non-fatal signals in user mode faults
The idea comes from the upstream discussion between Linus and Andrea:
https://lore.kernel.org/lkml/20171102193644.gb22...@redhat.com/
A summary to the issue: there was a special path in handle_userfault()
in the past that we'll return a VM_FAULT_NOPAGE when we detected
non-fatal signals when waiting for userfault handling. We did that by
reacquiring the mmap_sem before returning. However that brings a risk
in that the vmas might have changed when we retake the mmap_sem and
even we could be holding an invalid vma structure.
This patch is a preparation of removing that special path by allowing
the page fault to return even faster if we were interrupted by a
non-fatal signal during a user-mode page fault handling routine.
Suggested-by: Linus Torvalds
Suggested-by: Andrea Arcangeli
Signed-off-by: Peter Xu
---
arch/alpha/mm/fault.c| 2 +-
arch/arc/mm/fault.c | 5 +
arch/arm/mm/fault.c | 5 +
arch/arm64/mm/fault.c| 4
arch/hexagon/mm/vm_fault.c | 2 +-
arch/ia64/mm/fault.c | 2 +-
arch/m68k/mm/fault.c | 2 +-
Re: [GIT PULL] Backlight for v5.4
The pull request you sent on Tue, 24 Sep 2019 00:05:54 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git > tags/backlight-next-5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d0b3cfee333eb7eecb6ce72f06f5a02d249b9bdf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] MFD for v5.4
The pull request you sent on Tue, 24 Sep 2019 00:08:48 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git mfd-next-5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4c07e2ddab5b6b57dbcb09aedbda1f484d5940cc Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] PCI changes for v5.4
The pull request you sent on Mon, 23 Sep 2019 17:58:22 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > tags/pci-v5.4-changes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/299d14d4c31aff3b37a03894e012edf8421676ee Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[RESEND PATCH RFC] rtc: Fix the AltCentury value on AMD/Hygon platform
When using following operations:
date -s "21190910 19:20:00"
hwclock -w
to change date from 2019 to 2119 for test, it will fail on Hygon
Dhyana and AMD Zen CPUs, while the same operations run ok on Intel i7
platform.
MC146818 driver use function mc146818_set_time() to set register
RTC_FREQ_SELECT(RTC_REG_A)'s bit4-bit6 field which means divider stage
reset value on Intel platform to 0x7.
While AMD/Hygon RTC_REG_A(0Ah)'s bit4 is defined as DV0 [Reference]:
DV0 = 0 selects Bank 0, DV0 = 1 selects Bank 1. Bit5-bit6 is defined
as reserved.
DV0 is set to 1, it will select Bank 1, which will disable AltCentury
register(0x32) access. As UEFI pass acpi_gbl_FADT.century 0x32
(AltCentury), the CMOS write will be failed on code:
CMOS_WRITE(century, acpi_gbl_FADT.century).
Correct RTC_REG_A bank select bit(DV0) to 0 on AMD/Hygon CPUs, it will
enable AltCentury(0x32) register writing and finally setup century as
expected.
Test results on AMD/Hygon machine show that it works as expected.
Reference:
https://www.amd.com/system/files/TechDocs/51192_Bolton_FCH_RRG.pdf
section: 3.13 Real Time Clock (RTC)
Signed-off-by: Jinke Fan
---
drivers/rtc/rtc-mc146818-lib.c | 9 +++--
include/linux/mc146818rtc.h| 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index 2ecd8752b088..c09fe486ae67 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -170,9 +170,14 @@ int mc146818_set_time(struct rtc_time *time)
}
save_control = CMOS_READ(RTC_CONTROL);
- CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
+ CMOS_WRITE((save_control | RTC_SET), RTC_CONTROL);
save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
- CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
+
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+ CMOS_WRITE((save_freq_select & (~RTC_DV0)), RTC_FREQ_SELECT);
+ else
+ CMOS_WRITE((save_freq_select | RTC_DIV_RESET2),
RTC_FREQ_SELECT);
#ifdef CONFIG_MACH_DECSTATION
CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index 0661af17a758..b8ba6556c371 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -86,6 +86,8 @@ struct cmos_rtc_board_info {
/* 2 values for divider stage reset, others for "testing purposes only" */
# define RTC_DIV_RESET1 0x60
# define RTC_DIV_RESET2 0x70
+ /* DV0 = 0 selects Bank 0, DV0 = 1 selects Bank 1 on AMD/Hygon platform */
+# define RTC_DV0 0x10
/* Periodic intr. / Square wave rate select. 0=none, 1=32.8kHz,... 15=2Hz */
# define RTC_RATE_SELECT 0x0F
--
2.17.1
Re: [PATCH] scsi: qedf: Remove always false 'tmp_prio < 0' statement
Austin, > Since tmp_prio is declared as u8, the following statement is always false. >tmp_prio < 0 > > So remove 'always false' statement. Applied to 5.4/scsi-fixes, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH v4 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
Add PCIe EP mode support for ls1088a and ls2088a, there are some
difference between LS1 and LS2 platform, so refactor the code of
the EP driver.
Signed-off-by: Xiaowei Bao
---
v2:
- This is a new patch for supporting the ls1088a and ls2088a platform.
v3:
- Adjust the some struct assignment order in probe function.
v4:
- No change.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 72 +++---
1 file changed, 53 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index 5f0cb99..723bbe5 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -20,27 +20,29 @@
#define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
-struct ls_pcie_ep {
- struct dw_pcie *pci;
- struct pci_epc_features *ls_epc;
+#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
+
+struct ls_pcie_ep_drvdata {
+ u32 func_offset;
+ const struct dw_pcie_ep_ops *ops;
+ const struct dw_pcie_ops*dw_pcie_ops;
};
-#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
+struct ls_pcie_ep {
+ struct dw_pcie *pci;
+ struct pci_epc_features *ls_epc;
+ const struct ls_pcie_ep_drvdata *drvdata;
+};
static int ls_pcie_establish_link(struct dw_pcie *pci)
{
return 0;
}
-static const struct dw_pcie_ops ls_pcie_ep_ops = {
+static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
.start_link = ls_pcie_establish_link,
};
-static const struct of_device_id ls_pcie_ep_of_match[] = {
- { .compatible = "fsl,ls-pcie-ep",},
- { },
-};
-
static const struct pci_epc_features*
ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
{
@@ -87,10 +89,39 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8
func_no,
}
}
-static const struct dw_pcie_ep_ops pcie_ep_ops = {
+static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
+ u8 func_no)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
+
+ WARN_ON(func_no && !pcie->drvdata->func_offset);
+ return pcie->drvdata->func_offset * func_no;
+}
+
+static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
.ep_init = ls_pcie_ep_init,
.raise_irq = ls_pcie_ep_raise_irq,
.get_features = ls_pcie_ep_get_features,
+ .func_conf_select = ls_pcie_ep_func_conf_select,
+};
+
+static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
+ .ops = _pcie_ep_ops,
+ .dw_pcie_ops = _ls_pcie_ep_ops,
+};
+
+static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
+ .func_offset = 0x2,
+ .ops = _pcie_ep_ops,
+ .dw_pcie_ops = _ls_pcie_ep_ops,
+};
+
+static const struct of_device_id ls_pcie_ep_of_match[] = {
+ { .compatible = "fsl,ls1046a-pcie-ep", .data = _ep_drvdata },
+ { .compatible = "fsl,ls1088a-pcie-ep", .data = _ep_drvdata },
+ { .compatible = "fsl,ls2088a-pcie-ep", .data = _ep_drvdata },
+ { },
};
static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
@@ -103,7 +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
int ret;
ep = >ep;
- ep->ops = _ep_ops;
+ ep->ops = pcie->drvdata->ops;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
if (!res)
@@ -142,20 +173,23 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
if (!ls_epc)
return -ENOMEM;
- dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
- pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
- if (IS_ERR(pci->dbi_base))
- return PTR_ERR(pci->dbi_base);
+ pcie->drvdata = of_device_get_match_data(dev);
- pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
pci->dev = dev;
- pci->ops = _pcie_ep_ops;
- pcie->pci = pci;
+ pci->ops = pcie->drvdata->dw_pcie_ops;
ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
+ pcie->pci = pci;
pcie->ls_epc = ls_epc;
+ dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
+ pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
+ if (IS_ERR(pci->dbi_base))
+ return PTR_ERR(pci->dbi_base);
+
+ pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
+
platform_set_drvdata(pdev, pcie);
ret = ls_add_pcie_ep(pcie, pdev);
--
2.9.5
[PATCH v4 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a
Add PCIe EP node for ls1088a to support EP mode.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove the pf-offset proparty.
v3:
- No change.
v4:
- No change.
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 ++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index c676d07..da246ab 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -483,6 +483,17 @@
status = "disabled";
};
+ pcie_ep@340 {
+ compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
+ reg = <0x00 0x0340 0x0 0x0010
+ 0x20 0x 0x8 0x>;
+ reg-names = "regs", "addr_space";
+ num-ib-windows = <24>;
+ num-ob-windows = <128>;
+ max-functions = /bits/ 8 <2>;
+ status = "disabled";
+ };
+
pcie@350 {
compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
@@ -508,6 +519,16 @@
status = "disabled";
};
+ pcie_ep@350 {
+ compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
+ reg = <0x00 0x0350 0x0 0x0010
+ 0x28 0x 0x8 0x>;
+ reg-names = "regs", "addr_space";
+ num-ib-windows = <6>;
+ num-ob-windows = <8>;
+ status = "disabled";
+ };
+
pcie@360 {
compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
@@ -533,6 +554,16 @@
status = "disabled";
};
+ pcie_ep@360 {
+ compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
+ reg = <0x00 0x0360 0x0 0x0010
+ 0x30 0x 0x8 0x>;
+ reg-names = "regs", "addr_space";
+ num-ib-windows = <6>;
+ num-ob-windows = <8>;
+ status = "disabled";
+ };
+
smmu: iommu@500 {
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
--
2.9.5
[PATCH v4 02/11] PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
Add the doorbell mode of MSI-X in DWC EP driver.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- Remove the macro of no used.
v3:
- No change.
v4:
- Modify the commit message.
drivers/pci/controller/dwc/pcie-designware-ep.c | 14 ++
drivers/pci/controller/dwc/pcie-designware.h| 12
2 files changed, 26 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index eb851c2..55b23ce 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -449,6 +449,20 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8
func_no,
return 0;
}
+int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
+ u16 interrupt_num)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ u32 msg_data;
+
+ msg_data = (func_no << PCIE_MSIX_DOORBELL_PF_SHIFT) |
+ (interrupt_num - 1);
+
+ dw_pcie_writel_dbi(pci, PCIE_MSIX_DOORBELL, msg_data);
+
+ return 0;
+}
+
int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
u16 interrupt_num)
{
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 6aca0bb..56789be 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -88,6 +88,9 @@
#define PCIE_MISC_CONTROL_1_OFF0x8BC
#define PCIE_DBI_RO_WR_EN BIT(0)
+#define PCIE_MSIX_DOORBELL 0x948
+#define PCIE_MSIX_DOORBELL_PF_SHIFT24
+
#define PCIE_PL_CHK_REG_CONTROL_STATUS 0xB20
#define PCIE_PL_CHK_REG_CHK_REG_START BIT(0)
#define PCIE_PL_CHK_REG_CHK_REG_CONTINUOUS BIT(1)
@@ -419,6 +422,8 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8
func_no,
u8 interrupt_num);
int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
u16 interrupt_num);
+int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
+ u16 interrupt_num);
void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
#else
static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
@@ -451,6 +456,13 @@ static inline int dw_pcie_ep_raise_msix_irq(struct
dw_pcie_ep *ep, u8 func_no,
return 0;
}
+static inline int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep,
+u8 func_no,
+u16 interrupt_num)
+{
+ return 0;
+}
+
static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
bar)
{
}
--
2.9.5
[PATCH v4 01/11] PCI: designware-ep: Add multiple PFs support for DWC
Add multiple PFs support for DWC, due to different PF have different
config space, we use func_conf_select callback function to access
the different PF's config space, the different chip company need to
implement this callback function when use the DWC IP core and intend
to support multiple PFs feature.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove duplicate redundant code.
- Reimplement the PF config space access way.
v3:
- Integrate duplicate code for func_select.
- Move PCIE_ATU_FUNC_NUM(pf) (pf << 20) to ((pf) << 20).
- Add the comments for func_conf_select function.
v4:
- Correct the commit message.
drivers/pci/controller/dwc/pcie-designware-ep.c | 123
drivers/pci/controller/dwc/pcie-designware.c| 59
drivers/pci/controller/dwc/pcie-designware.h| 18 +++-
3 files changed, 142 insertions(+), 58 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 65f4792..eb851c2 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -19,12 +19,26 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
pci_epc_linkup(epc);
}
-static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar,
- int flags)
+static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8 func_no)
+{
+ unsigned int func_offset = 0;
+
+ if (ep->ops->func_conf_select)
+ func_offset = ep->ops->func_conf_select(ep, func_no);
+
+ return func_offset;
+}
+
+static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
+ enum pci_barno bar, int flags)
{
u32 reg;
+ unsigned int func_offset = 0;
+ struct dw_pcie_ep *ep = >ep;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = PCI_BASE_ADDRESS_0 + (4 * bar);
+ reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
dw_pcie_dbi_ro_wr_en(pci);
dw_pcie_writel_dbi2(pci, reg, 0x0);
dw_pcie_writel_dbi(pci, reg, 0x0);
@@ -37,7 +51,12 @@ static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
pci_barno bar,
void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
{
- __dw_pcie_ep_reset_bar(pci, bar, 0);
+ u8 func_no, funcs;
+
+ funcs = pci->ep.epc->max_functions;
+
+ for (func_no = 0; func_no < funcs; func_no++)
+ __dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
}
static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
@@ -45,28 +64,31 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, u8
func_no,
{
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ unsigned int func_offset = 0;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
dw_pcie_dbi_ro_wr_en(pci);
- dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
- dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
- dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
- dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
- dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
+ dw_pcie_writew_dbi(pci, func_offset + PCI_VENDOR_ID, hdr->vendorid);
+ dw_pcie_writew_dbi(pci, func_offset + PCI_DEVICE_ID, hdr->deviceid);
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_REVISION_ID, hdr->revid);
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_CLASS_PROG, hdr->progif_code);
+ dw_pcie_writew_dbi(pci, func_offset + PCI_CLASS_DEVICE,
hdr->subclass_code | hdr->baseclass_code << 8);
- dw_pcie_writeb_dbi(pci, PCI_CACHE_LINE_SIZE,
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_CACHE_LINE_SIZE,
hdr->cache_line_size);
- dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_VENDOR_ID,
+ dw_pcie_writew_dbi(pci, func_offset + PCI_SUBSYSTEM_VENDOR_ID,
hdr->subsys_vendor_id);
- dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
- dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
+ dw_pcie_writew_dbi(pci, func_offset + PCI_SUBSYSTEM_ID, hdr->subsys_id);
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_INTERRUPT_PIN,
hdr->interrupt_pin);
dw_pcie_dbi_ro_wr_dis(pci);
return 0;
}
-static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
- dma_addr_t cpu_addr,
+static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no,
+ enum pci_barno bar, dma_addr_t cpu_addr,
enum dw_pcie_as_type as_type)
{
int ret;
@@ -79,7 +101,7 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep,
enum pci_barno bar,
return -EINVAL;
}
- ret = dw_pcie_prog_inbound_atu(pci, free_win, bar,
[PATCH v4 03/11] PCI: designware-ep: Move the function of getting MSI capability forward
Move the function of getting MSI capability to the front of init
function, because the init function of the EP platform driver will use
the return value by the function of getting MSI capability.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- No change.
v3:
- No change.
v4:
- No change.
drivers/pci/controller/dwc/pcie-designware-ep.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 55b23ce..c3bc7bd 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -624,6 +624,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
if (ret < 0)
epc->max_functions = 1;
+ ep->msi_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
+
+ ep->msix_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSIX);
+
if (ep->ops->ep_init)
ep->ops->ep_init(ep);
@@ -640,9 +644,6 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
dev_err(dev, "Failed to reserve memory for MSI/MSI-X\n");
return -ENOMEM;
}
- ep->msi_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
-
- ep->msix_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSIX);
offset = dw_pcie_ep_find_ext_capability(pci, PCI_EXT_CAP_ID_REBAR);
if (offset) {
--
2.9.5
[PATCH v4 04/11] PCI: designware-ep: Modify MSI and MSIX CAP way of finding
Each PF of EP device should have it's own MSI or MSIX capabitily
struct, so create a dw_pcie_ep_func struct and remove the msi_cap
and msix_cap to this struct from dw_pcie_ep, and manage the PFs
with a list.
Signed-off-by: Xiaowei Bao
---
v3:
- This is a new patch, to fix the issue of MSI and MSIX CAP way of
finding.
v4:
- Correct some word of commit message.
drivers/pci/controller/dwc/pcie-designware-ep.c | 135 +---
drivers/pci/controller/dwc/pcie-designware.h| 18 +++-
2 files changed, 134 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index c3bc7bd..144eb12 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -19,6 +19,19 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
pci_epc_linkup(epc);
}
+struct dw_pcie_ep_func *
+dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no)
+{
+ struct dw_pcie_ep_func *ep_func;
+
+ list_for_each_entry(ep_func, >func_list, list) {
+ if (ep_func->func_no == func_no)
+ return ep_func;
+ }
+
+ return NULL;
+}
+
static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8 func_no)
{
unsigned int func_offset = 0;
@@ -59,6 +72,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
pci_barno bar)
__dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
}
+static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8 func_no,
+ u8 cap_ptr, u8 cap)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ unsigned int func_offset = 0;
+ u8 cap_id, next_cap_ptr;
+ u16 reg;
+
+ if (!cap_ptr)
+ return 0;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
+
+ reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
+ cap_id = (reg & 0x00ff);
+
+ if (cap_id > PCI_CAP_ID_MAX)
+ return 0;
+
+ if (cap_id == cap)
+ return cap_ptr;
+
+ next_cap_ptr = (reg & 0xff00) >> 8;
+ return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap);
+}
+
+static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8 func_no, u8 cap)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ unsigned int func_offset = 0;
+ u8 next_cap_ptr;
+ u16 reg;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
+
+ reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
+ next_cap_ptr = (reg & 0x00ff);
+
+ return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap);
+}
+
static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
struct pci_epf_header *hdr)
{
@@ -246,13 +300,18 @@ static int dw_pcie_ep_get_msi(struct pci_epc *epc, u8
func_no)
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
u32 val, reg;
unsigned int func_offset = 0;
+ struct dw_pcie_ep_func *ep_func;
- if (!ep->msi_cap)
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ if (!ep_func)
+ return -EINVAL;
+
+ if (!ep_func->msi_cap)
return -EINVAL;
func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
+ reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
val = dw_pcie_readw_dbi(pci, reg);
if (!(val & PCI_MSI_FLAGS_ENABLE))
return -EINVAL;
@@ -268,13 +327,18 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8
func_no, u8 interrupts)
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
u32 val, reg;
unsigned int func_offset = 0;
+ struct dw_pcie_ep_func *ep_func;
+
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ if (!ep_func)
+ return -EINVAL;
- if (!ep->msi_cap)
+ if (!ep_func->msi_cap)
return -EINVAL;
func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
+ reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
val = dw_pcie_readw_dbi(pci, reg);
val &= ~PCI_MSI_FLAGS_QMASK;
val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK;
@@ -291,13 +355,18 @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8
func_no)
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
u32 val, reg;
unsigned int func_offset = 0;
+ struct dw_pcie_ep_func *ep_func;
+
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ if (!ep_func)
+ return -EINVAL;
- if (!ep->msix_cap)
+ if (!ep_func->msix_cap)
return -EINVAL;
func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
+ reg = ep_func->msix_cap + func_offset + PCI_MSIX_FLAGS;
[PATCH v4 00/11] Add the multiple PF support for DWC and Layerscape
Add the PCIe EP multiple PF support for DWC and Layerscape, add the doorbell MSIX function for DWC, use list to manage the PF of one PCIe controller, and refactor the Layerscape EP driver due to some platforms difference. Xiaowei Bao (11): PCI: designware-ep: Add multiple PFs support for DWC PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode PCI: designware-ep: Move the function of getting MSI capability forward PCI: designware-ep: Modify MSI and MSIX CAP way of finding dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a PCI: layerscape: Fix some format issue of the code PCI: layerscape: Modify the way of getting capability with different PEX PCI: layerscape: Modify the MSIX to the doorbell mode PCI: layerscape: Add EP mode support for ls1088a and ls2088a arm64: dts: layerscape: Add PCIe EP node for ls1088a misc: pci_endpoint_test: Add LS1088a in pci_device_id table .../devicetree/bindings/pci/layerscape-pci.txt | 2 + arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 +++ drivers/misc/pci_endpoint_test.c | 2 + drivers/pci/controller/dwc/pci-layerscape-ep.c | 100 ++-- drivers/pci/controller/dwc/pcie-designware-ep.c| 255 + drivers/pci/controller/dwc/pcie-designware.c | 59 +++-- drivers/pci/controller/dwc/pcie-designware.h | 48 +++- 7 files changed, 404 insertions(+), 93 deletions(-) -- 2.9.5
[PATCH v4 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table
Add LS1088a in pci_device_id table so that pci-epf-test can be used
for testing PCIe EP in LS1088a.
Signed-off-by: Xiaowei Bao
---
v2:
- No change.
v3:
- No change.
v4:
- Use a maco to define the LS1088a device ID.
drivers/misc/pci_endpoint_test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 6e208a0..8c222a6 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -65,6 +65,7 @@
#define PCI_ENDPOINT_TEST_IRQ_NUMBER 0x28
#define PCI_DEVICE_ID_TI_AM654 0xb00c
+#define PCI_DEVICE_ID_LS1088A 0x80c0
#define is_am654_pci_dev(pdev) \
((pdev)->device == PCI_DEVICE_ID_TI_AM654)
@@ -793,6 +794,7 @@ static const struct pci_device_id pci_endpoint_test_tbl[] =
{
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
{ PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_LS1088A) },
{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
.driver_data = (kernel_ulong_t)_data
--
2.9.5
[PATCH v4 07/11] PCI: layerscape: Modify the way of getting capability with different PEX
The different PCIe controller in one board may be have different
capability of MSI or MSIX, so change the way of getting the MSI
capability, make it more flexible.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove the repeated assignment code.
v3:
- Use ep_func msi_cap and msix_cap to decide the msi_capable and
msix_capable of pci_epc_features struct.
v4:
- No change.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 31 +++---
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index a9c552e..1e07287 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -22,6 +22,7 @@
struct ls_pcie_ep {
struct dw_pcie *pci;
+ struct pci_epc_features *ls_epc;
};
#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
@@ -40,26 +41,31 @@ static const struct of_device_id ls_pcie_ep_of_match[] = {
{ },
};
-static const struct pci_epc_features ls_pcie_epc_features = {
- .linkup_notifier = false,
- .msi_capable = true,
- .msix_capable = false,
- .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
-};
-
static const struct pci_epc_features*
ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
{
- return _pcie_epc_features;
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
+
+ return pcie->ls_epc;
}
static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
+ struct dw_pcie_ep_func *ep_func;
enum pci_barno bar;
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, 0);
+ if (!ep_func)
+ return;
+
for (bar = BAR_0; bar <= BAR_5; bar++)
dw_pcie_ep_reset_bar(pci, bar);
+
+ pcie->ls_epc->msi_capable = ep_func->msi_cap ? true : false;
+ pcie->ls_epc->msix_capable = ep_func->msix_cap ? true : false;
}
static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
@@ -119,6 +125,7 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct dw_pcie *pci;
struct ls_pcie_ep *pcie;
+ struct pci_epc_features *ls_epc;
struct resource *dbi_base;
int ret;
@@ -130,6 +137,10 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
if (!pci)
return -ENOMEM;
+ ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
+ if (!ls_epc)
+ return -ENOMEM;
+
dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
if (IS_ERR(pci->dbi_base))
@@ -140,6 +151,10 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
pci->ops = _pcie_ep_ops;
pcie->pci = pci;
+ ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
+
+ pcie->ls_epc = ls_epc;
+
platform_set_drvdata(pdev, pcie);
ret = ls_add_pcie_ep(pcie, pdev);
--
2.9.5
[PATCH v4 08/11] PCI: layerscape: Modify the MSIX to the doorbell mode
dw_pcie_ep_raise_msix_irq was never called in the exisitng driver before, because the ls1046a platform don't support the MSIX feature and msix_capable was always set to false. Now that add the ls1088a platform with MSIX support, but the existing dw_pcie_ep_raise_msix_irq doesn't work, so use the doorbell method to support the MSIX feature. Signed-off-by: Xiaowei Bao Reviewed-by: Andrew Murray --- v2: - No change v3: - Modify the commit message make it clearly. v4: - No change drivers/pci/controller/dwc/pci-layerscape-ep.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c index 1e07287..5f0cb99 100644 --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c @@ -79,7 +79,8 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no, case PCI_EPC_IRQ_MSI: return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num); case PCI_EPC_IRQ_MSIX: - return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num); + return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no, + interrupt_num); default: dev_err(pci->dev, "UNKNOWN IRQ type\n"); return -EINVAL; -- 2.9.5
[PATCH v4 06/11] PCI: layerscape: Fix some format issue of the code
Fix some format issue of the code in EP driver.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- No change.
v3:
- No change.
v4:
- No change.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index ca9aa45..a9c552e 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -63,7 +63,7 @@ static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
}
static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
- enum pci_epc_irq_type type, u16 interrupt_num)
+ enum pci_epc_irq_type type, u16 interrupt_num)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
@@ -87,7 +87,7 @@ static const struct dw_pcie_ep_ops pcie_ep_ops = {
};
static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
- struct platform_device *pdev)
+struct platform_device *pdev)
{
struct dw_pcie *pci = pcie->pci;
struct device *dev = pci->dev;
--
2.9.5
[PATCH v4 05/11] dt-bindings: pci: layerscape-pci: Add compatible strings for ls1088a and ls2088a
Add compatible strings for ls1088a and ls2088a. Signed-off-by: Xiaowei Bao --- v2: - No change. v3: - Use one valid combination of compatible strings. v4: - Add the comma between the two compatible. Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index e20ceaa..3717e3d 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -23,6 +23,8 @@ Required properties: "fsl,ls1012a-pcie" EP mode: "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep" + "fsl,ls1088a-pcie-ep", "fsl,ls-pcie-ep" + "fsl,ls2088a-pcie-ep", "fsl,ls-pcie-ep" - reg: base addresses and lengths of the PCIe controller register blocks. - interrupts: A list of interrupt outputs of the controller. Must contain an entry for each entry in the interrupt-names property. -- 2.9.5
[rcu:dev.2019.09.23a 61/77] htmldocs: kernel/rcu/tree.c:2706: warning: Function parameter or member 'krcp' not described in 'kfree_rcu_cpu_work'
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2019.09.23a head: 97de53b94582c208ee239178b208b8e8b9472585 commit: 3cc794ad18bfc6e46d58411b53f2784388d5bb85 [61/77] rcu: Add multiple in-flight batches of kfree_rcu() work reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' mm/util.c:1: warning: 'get_user_pages_fast' not found mm/slab.c:4215: warning: Function parameter or member 'objp' not described in '__ksize' drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found include/linux/w1.h:272: warning: Function parameter or member 'of_match_table' not described in 'w1_family' include/linux/input/sparse-keymap.h:43: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/mod_devicetable.h:822: warning: Function parameter or member 'context' not described in 'wmi_device_id' drivers/gpu/drm/mcde/mcde_drv.c:1: warning: 'ST-Ericsson MCDE DRM Driver' not found lib/genalloc.c:1: warning: 'gen_pool_add_virt' not found lib/genalloc.c:1: warning: 'gen_pool_alloc' not found lib/genalloc.c:1: warning: 'gen_pool_free' not found lib/genalloc.c:1: warning: 'gen_pool_alloc_algo' not found include/linux/clk.h:381: warning: Function parameter or member 'num_clks' not described in 'devm_clk_bulk_get_optional' >> kernel/rcu/tree.c:2706: warning: Function parameter or member 'krcp' not >> described in 'kfree_rcu_cpu_work' include/linux/rculist.h:374: warning: Excess function parameter 'cond' description in 'list_for_each_entry_rcu' include/linux/rculist.h:651: warning: Excess function parameter 'cond' description in 'hlist_for_each_entry_rcu' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:142: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:347: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:348: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:494: warning: Function parameter or member 'start' not described in 'amdgpu_vm_pt_first_dfs' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'adev' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'vm' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'start' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'cursor' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'entry' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:823: warning: Function parameter or member 'level' not described in 'amdgpu_vm_bo_param' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'params' not described in 'amdgpu_vm_update_flags'
Re: [PATCH v3 18/26] scsi: pm80xx: Use PCI_STD_NUM_BARS
Denis, > Replace the magic constant (6) with define PCI_STD_NUM_BARS > representing the number of PCI BARs. Applied to 5.4/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[rcu:dev.2019.09.23a 65/77] kernel//rcu/tree.c:2770:3: error: implicit declaration of function 'kfree'; did you mean 'kvfree'?
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2019.09.23a
head: 97de53b94582c208ee239178b208b8e8b9472585
commit: 06b68648e6084488b79de47a2cfa307a1b9668b9 [65/77] rcu: Remove
kfree_rcu() special casing and lazy-callback handling
config: x86_64-randconfig-c004-201938 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
git checkout 06b68648e6084488b79de47a2cfa307a1b9668b9
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
kernel//rcu/tree.c: In function 'kfree_rcu_work':
>> kernel//rcu/tree.c:2770:3: error: implicit declaration of function 'kfree';
>> did you mean 'kvfree'? [-Werror=implicit-function-declaration]
kfree((void *)head - offset);
^
kvfree
cc1: some warnings being treated as errors
vim +2770 kernel//rcu/tree.c
2739
2740 /*
2741 * This function is invoked in workqueue context after a grace period.
2742 * It frees all the objects queued on ->head_free.
2743 */
2744 static void kfree_rcu_work(struct work_struct *work)
2745 {
2746 unsigned long flags;
2747 struct rcu_head *head, *next;
2748 struct kfree_rcu_cpu *krcp;
2749 struct kfree_rcu_cpu_work *krwp;
2750
2751 krwp = container_of(to_rcu_work(work),
2752 struct kfree_rcu_cpu_work, rcu_work);
2753 krcp = krwp->krcp;
2754 spin_lock_irqsave(>lock, flags);
2755 head = krwp->head_free;
2756 krwp->head_free = NULL;
2757 spin_unlock_irqrestore(>lock, flags);
2758
2759 // List "head" is now private, so traverse locklessly.
2760 for (; head; head = next) {
2761 unsigned long offset = (unsigned long)head->func;
2762
2763 next = head->next;
2764 // Potentially optimize with kfree_bulk in future.
2765 debug_rcu_head_unqueue(head);
2766 rcu_lock_acquire(_callback_map);
2767 trace_rcu_invoke_kfree_callback(rcu_state.name, head,
offset);
2768
2769 /* Could be possible to optimize with kfree_bulk in
future */
> 2770 kfree((void *)head - offset);
2771
2772 rcu_lock_release(_callback_map);
2773 cond_resched_tasks_rcu_qs();
2774 }
2775 }
2776
---
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 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
> -Original Message-
> From: Catalin Marinas
> Sent: 2019年9月24日 0:18
> To: Justin He (Arm Technology China)
> Cc: Will Deacon ; Mark Rutland
> ; James Morse ; Marc
> Zyngier ; Matthew Wilcox ; Kirill A.
> Shutemov ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@kvack.org; Suzuki Poulose ; Punit
> Agrawal ; Anshuman Khandual
> ; Alex Van Brunt
> ; Robin Murphy ;
> Thomas Gleixner ; Andrew Morton foundation.org>; Jérôme Glisse ; Ralph Campbell
> ; hejia...@gmail.com; Kaly Xin (Arm Technology
> China) ; nd
> Subject: Re: [PATCH v8 2/3] arm64: mm: implement
> arch_faults_on_old_pte() on arm64
>
> On Sat, Sep 21, 2019 at 09:50:53PM +0800, Jia He wrote:
> > diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> > index e09760ece844..4a9939615e41 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct
> vm_area_struct *vma,
> > #define phys_to_ttbr(addr) (addr)
> > #endif
> >
> > +/*
> > + * On arm64 without hardware Access Flag, copying fromuser will fail
> because
>
>from user
>
Ok
> > + * the pte is old and cannot be marked young. So we always end up with
> zeroed
> > + * page after fork() + CoW for pfn mappings. we don't always have a
> ^^
> We
>
Ok
> > + * hardware-managed access flag on arm64.
> > + */
> > +static inline bool arch_faults_on_old_pte(void)
> > +{
> > + return !cpu_has_hw_af();
>
> I saw an early incarnation of your patch having a
> WARN_ON(preemptible()). I think we need this back just in case this
> function will be used elsewhere in the future.
Okay
--
Cheers,
Justin (Jia He)
>
> > +}
> > +#define arch_faults_on_old_pte arch_faults_on_old_pte
>
> Otherwise,
>
> Reviewed-by: Catalin Marinas
Re: WARNING: locking bug in selinux_netlbl_socket_connect
On Sat, Sep 21, 2019 at 11:50 AM syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:f97c81dc Merge tag 'armsoc-late' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=127b709d60 > kernel config: https://syzkaller.appspot.com/x/.config?x=10283c2b00ab4cd7 > dashboard link: https://syzkaller.appspot.com/bug?extid=5fa07e4e18e4eb1ccb12 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1299684160 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+5fa07e4e18e4eb1cc...@syzkaller.appspotmail.com > > WARNING: CPU: 0 PID: 10315 at kernel/locking/lockdep.c:840 > look_up_lock_class kernel/locking/lockdep.c:840 [inline] > WARNING: CPU: 0 PID: 10315 at kernel/locking/lockdep.c:840 > register_lock_class+0x206/0x1850 kernel/locking/lockdep.c:1185 > Kernel panic - not syncing: panic_on_warn set ... > CPU: 0 PID: 10315 Comm: syz-executor.0 Not tainted 5.3.0+ #0 > 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+0x172/0x1f0 lib/dump_stack.c:113 > panic+0x2dc/0x755 kernel/panic.c:219 > __warn.cold+0x20/0x4c kernel/panic.c:576 > report_bug+0x263/0x2b0 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:179 [inline] > fixup_bug arch/x86/kernel/traps.c:174 [inline] > do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272 > do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291 > invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028 > RIP: 0010:look_up_lock_class kernel/locking/lockdep.c:840 [inline] > RIP: 0010:register_lock_class+0x206/0x1850 kernel/locking/lockdep.c:1185 > Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 aa 10 00 00 4c 3b 7b > 18 44 8b 35 d5 de 55 09 74 0b 48 81 3b a0 65 06 8a 74 02 <0f> 0b 45 85 ed > 0f 84 71 03 00 00 f6 85 70 ff ff ff 01 0f 85 64 03 > RSP: 0018:888096777a48 EFLAGS: 00010002 > RAX: dc00 RBX: 888093ff78e0 RCX: > RDX: 1110127fef1f RSI: RDI: 888093ff78f8 > RBP: 888096777b10 R08: 111012ceef51 R09: 8aaea0e0 > R10: 8a7753c8 R11: R12: 8a7b5d20 > R13: R14: R15: 884766e0 > __lock_acquire+0xf4/0x4e70 kernel/locking/lockdep.c:3837 > lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487 > __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] > _raw_spin_lock_bh+0x33/0x50 kernel/locking/spinlock.c:175 > spin_lock_bh include/linux/spinlock.h:343 [inline] > lock_sock_nested+0x41/0x120 net/core/sock.c:2929 > lock_sock include/net/sock.h:1522 [inline] > selinux_netlbl_socket_connect+0x20/0xc0 security/selinux/netlabel.c:607 > selinux_socket_connect+0x6a/0x90 security/selinux/hooks.c:4745 > security_socket_connect+0x77/0xc0 security/security.c:1958 > __sys_connect+0x19d/0x330 net/socket.c:1824 > __do_sys_connect net/socket.c:1839 [inline] > __se_sys_connect net/socket.c:1836 [inline] > __x64_sys_connect+0x73/0xb0 net/socket.c:1836 > do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x459a09 > Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fc302ec5c78 EFLAGS: 0246 ORIG_RAX: 002a > RAX: ffda RBX: 0003 RCX: 00459a09 > RDX: 001c RSI: 2080 RDI: 0005 > RBP: 0075bf20 R08: R09: > R10: R11: 0246 R12: 7fc302ec66d4 > R13: 004bff42 R14: 004d1eb0 R15: > Kernel Offset: disabled > Rebooting in 86400 seconds.. This doesn't appear to be related to selinux_netlbl_socket_connect(); I believe it should be okay to call lock_sock() in that context. -- paul moore www.paul-moore.com
RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2 support
Hi Anson,
Points are taken. Will send out the next version.
Thanks,
Andy
> -Original Message-
> From: Anson Huang
> Sent: 2019年9月24日 10:11
> To: Andy Tang ; Zhang Rui ;
> edubez...@gmail.com
> Cc: daniel.lezc...@linaro.org; Leo Li ;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2
> support
>
> Hi, Andy
>
> > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit version
> > 2 support
> >
> > Hi Anson,
> >
> > Thanks for your review. Please see my reply inline.
> >
> > > -Original Message-
> > > From: Anson Huang
> > > Sent: 2019年9月24日 9:17
> > > To: Zhang Rui ; Andy Tang ;
> > > edubez...@gmail.com
> > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > version
> > > 2 support
> > >
> > > Hi, Andy
> > >
> > >
> > > > On Mon, 2019-09-23 at 09:24 +, Andy Tang wrote:
> > > > > Hi Rui, Edubezval,
> > > > >
> > > > > Would you please review this patch?
> > > > >
> > > > CC Anson Huang.
> > > > I'd prefer all the qoriq thermal patches go through his review first.
> > > >
> > > > thanks,
> > > > rui
> > > >
> > > > > BR,
> > > > > Andy
> > > > >
> > > > > > -Original Message-
> > > > > > From: Andy Tang
> > > > > > Sent: 2019年8月29日 16:38
> > > > > > To: 'edubez...@gmail.com' ;
> > > > > > 'rui.zh...@intel.com'
> > > > > >
> > > > > > Cc: 'daniel.lezc...@linaro.org' ;
> > > > > > Leo Li ; 'linux...@vger.kernel.org'
> > > > > > ; 'linux-kernel@vger.kernel.org'
> > > > > >
> > > > > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > > version 2 support
> > > > > >
> > > > > > Hi Rui, Edubezval,
> > > > > >
> > > > > > Almost three monthes passed, I have not got your comments from
> > you.
> > > > > > Could you please take a look at this patch?
> > > > > >
> > > > > > BR,
> > > > > > Andy
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Andy Tang
> > > > > > > Sent: 2019年8月6日 10:57
> > > > > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > > > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > > > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor
> > > > > > > unit version
> > > > > > > 2 support
> > > > > > >
> > > > > > > Any comments?
> > > > > > >
> > > > > > > BR,
> > > > > > > Andy
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Yuantian Tang
> > > > > > > > Sent: 2019年6月4日 10:51
> > > > > > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > > > > > Cc: daniel.lezc...@linaro.org; Leo Li
> > > > > > > > ; linux...@vger.kernel.org;
> > > > > > > > linux-kernel@vger.kernel.org; Andy Tang
> > > > > > > >
> > > > > > > > Subject: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > > > > version 2 support
> > > > > > > >
> > > > > > > > Thermal Monitor Unit v2 is introduced on new Layscape SoC.
> > > > > > > > Compared to v1, TMUv2 has a little different register
> > > > > > > > layout and digital output is fairly linear.
> > > > > > > >
> > > > > > > > Signed-off-by: Yuantian Tang
> > > > > > > > ---
> > > > > > > > drivers/thermal/qoriq_thermal.c | 122
> > > > > > > > +---
> > > > > > > > 1 file changed, 98 insertions(+), 24 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/thermal/qoriq_thermal.c
> > > > > > > > b/drivers/thermal/qoriq_thermal.c index
> > > > > > > > 3b5f5b3fb1bc..0df6dfddf804
> > > > > > > > 100644
> > > > > > > > --- a/drivers/thermal/qoriq_thermal.c
> > > > > > > > +++ b/drivers/thermal/qoriq_thermal.c
> > > > > > > > @@ -13,6 +13,15 @@
> > > > > > > > #include "thermal_core.h"
> > > > > > > >
> > > > > > > > #define SITES_MAX 16
> > > > > > > > +#define TMR_DISABLE0x0
> > > > > > > > +#define TMR_ME 0x8000
> > > > > > > > +#define TMR_ALPF 0x0c00
> > > > > > > > +#define TMR_ALPF_V20x0300
> > > > > > > > +#define TMTMIR_DEFAULT 0x000f
> > > > > > > > +#define TIER_DISABLE 0x0
> > > > > > > > +#define TEUMR0_V2 0x51009C00
> > >
> > > Better to use either lower case or capital letter for all macro
> > > definitions, some are lower case and some are capital letter look
> > > like NOT
> > aligned.
> > I always use capital letter to define a macro.
> > Did I use lower letter somewhere?
>
> I meant below:
>
> +#define TMTMIR_DEFAULT 0x000f
> +#define TEUMR0_V20x51009C00
>
> 'f' is lower case while 'C' is capital letter.
>
> >
> > >
> > > > > > > > +#define TMU_VER1 0x1
> > > > > > > > +#define TMU_VER2 0x2
> > > > > > > >
> > > > > > > > /*
> > > > > > > > * QorIQ TMU Registers
> > > > > > > > @@ -23,17 +32,55 @@ struct qoriq_tmu_site_regs {
> > > > > > > > u8 res0[0x8];
> > > > > > > > };
> > > > > > > >
> > > > > > > > -struct
RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2 support
Hi, Andy
> Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2
> support
>
> Hi Anson,
>
> Thanks for your review. Please see my reply inline.
>
> > -Original Message-
> > From: Anson Huang
> > Sent: 2019年9月24日 9:17
> > To: Zhang Rui ; Andy Tang ;
> > edubez...@gmail.com
> > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit version
> > 2 support
> >
> > Hi, Andy
> >
> >
> > > On Mon, 2019-09-23 at 09:24 +, Andy Tang wrote:
> > > > Hi Rui, Edubezval,
> > > >
> > > > Would you please review this patch?
> > > >
> > > CC Anson Huang.
> > > I'd prefer all the qoriq thermal patches go through his review first.
> > >
> > > thanks,
> > > rui
> > >
> > > > BR,
> > > > Andy
> > > >
> > > > > -Original Message-
> > > > > From: Andy Tang
> > > > > Sent: 2019年8月29日 16:38
> > > > > To: 'edubez...@gmail.com' ;
> > > > > 'rui.zh...@intel.com'
> > > > >
> > > > > Cc: 'daniel.lezc...@linaro.org' ; Leo
> > > > > Li ; 'linux...@vger.kernel.org'
> > > > > ; 'linux-kernel@vger.kernel.org'
> > > > >
> > > > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > version 2 support
> > > > >
> > > > > Hi Rui, Edubezval,
> > > > >
> > > > > Almost three monthes passed, I have not got your comments from
> you.
> > > > > Could you please take a look at this patch?
> > > > >
> > > > > BR,
> > > > > Andy
> > > > >
> > > > > > -Original Message-
> > > > > > From: Andy Tang
> > > > > > Sent: 2019年8月6日 10:57
> > > > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > > version
> > > > > > 2 support
> > > > > >
> > > > > > Any comments?
> > > > > >
> > > > > > BR,
> > > > > > Andy
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Yuantian Tang
> > > > > > > Sent: 2019年6月4日 10:51
> > > > > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > > > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > > > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy
> > > > > > > Tang
> > > > > > > Subject: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > > > version 2 support
> > > > > > >
> > > > > > > Thermal Monitor Unit v2 is introduced on new Layscape SoC.
> > > > > > > Compared to v1, TMUv2 has a little different register layout
> > > > > > > and digital output is fairly linear.
> > > > > > >
> > > > > > > Signed-off-by: Yuantian Tang
> > > > > > > ---
> > > > > > > drivers/thermal/qoriq_thermal.c | 122
> > > > > > > +---
> > > > > > > 1 file changed, 98 insertions(+), 24 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/thermal/qoriq_thermal.c
> > > > > > > b/drivers/thermal/qoriq_thermal.c index
> > > > > > > 3b5f5b3fb1bc..0df6dfddf804
> > > > > > > 100644
> > > > > > > --- a/drivers/thermal/qoriq_thermal.c
> > > > > > > +++ b/drivers/thermal/qoriq_thermal.c
> > > > > > > @@ -13,6 +13,15 @@
> > > > > > > #include "thermal_core.h"
> > > > > > >
> > > > > > > #define SITES_MAX16
> > > > > > > +#define TMR_DISABLE 0x0
> > > > > > > +#define TMR_ME 0x8000
> > > > > > > +#define TMR_ALPF 0x0c00
> > > > > > > +#define TMR_ALPF_V2 0x0300
> > > > > > > +#define TMTMIR_DEFAULT 0x000f
> > > > > > > +#define TIER_DISABLE 0x0
> > > > > > > +#define TEUMR0_V20x51009C00
> >
> > Better to use either lower case or capital letter for all macro
> > definitions, some are lower case and some are capital letter look like NOT
> aligned.
> I always use capital letter to define a macro.
> Did I use lower letter somewhere?
I meant below:
+#define TMTMIR_DEFAULT 0x000f
+#define TEUMR0_V2 0x51009C00
'f' is lower case while 'C' is capital letter.
>
> >
> > > > > > > +#define TMU_VER1 0x1
> > > > > > > +#define TMU_VER2 0x2
> > > > > > >
> > > > > > > /*
> > > > > > > * QorIQ TMU Registers
> > > > > > > @@ -23,17 +32,55 @@ struct qoriq_tmu_site_regs {
> > > > > > > u8 res0[0x8];
> > > > > > > };
> > > > > > >
> > > > > > > -struct qoriq_tmu_regs {
> > > > > > > +struct qoriq_tmu_regs_v2 {
> > > > > > > + u32 tmr;/* Mode Register */
> > > > > > > + u32 tsr;/* Status Register */
> > > > > > > + u32 tmsr; /* monitor site register */
> > > > > > > + u32 tmtmir; /* Temperature measurement
> > > > > > > interval Register
> > > > >
> > > > > */
> > > > > > > + u8 res0[0x10];
> > > > > > > + u32 tier; /* Interrupt Enable Register */
> > > > > > > + u32 tidr; /* Interrupt Detect Register */
> > > > > > > + u8 res1[0x8];
> > > > > > > + u32 tiiscr; /* interrupt immediate site
> > > > > > > capture register */
> > > > > > > + u32 tiascr;
[WTF?] aafs_create_symlink() weirdness
static struct dentry *aafs_create_symlink(const char *name,
struct dentry *parent,
const char *target,
void *private,
const struct inode_operations *iops)
{
struct dentry *dent;
char *link = NULL;
if (target) {
if (!link)
return ERR_PTR(-ENOMEM);
}
Er... That's an odd way to spell
if (target)
return ERR_PTR(-ENOMEM);
(and an odd error value to use). Especially since all callers are passing
NULL as target.
Why is that code even there, why does that argument still exist and
how many people have actually read that function?
RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2 support
Hi Anson,
Thanks for your review. Please see my reply inline.
> -Original Message-
> From: Anson Huang
> Sent: 2019年9月24日 9:17
> To: Zhang Rui ; Andy Tang ;
> edubez...@gmail.com
> Cc: daniel.lezc...@linaro.org; Leo Li ;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2
> support
>
> Hi, Andy
>
>
> > On Mon, 2019-09-23 at 09:24 +, Andy Tang wrote:
> > > Hi Rui, Edubezval,
> > >
> > > Would you please review this patch?
> > >
> > CC Anson Huang.
> > I'd prefer all the qoriq thermal patches go through his review first.
> >
> > thanks,
> > rui
> >
> > > BR,
> > > Andy
> > >
> > > > -Original Message-
> > > > From: Andy Tang
> > > > Sent: 2019年8月29日 16:38
> > > > To: 'edubez...@gmail.com' ;
> > > > 'rui.zh...@intel.com'
> > > >
> > > > Cc: 'daniel.lezc...@linaro.org' ; Leo
> > > > Li ; 'linux...@vger.kernel.org'
> > > > ; 'linux-kernel@vger.kernel.org'
> > > >
> > > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > version 2 support
> > > >
> > > > Hi Rui, Edubezval,
> > > >
> > > > Almost three monthes passed, I have not got your comments from you.
> > > > Could you please take a look at this patch?
> > > >
> > > > BR,
> > > > Andy
> > > >
> > > > > -Original Message-
> > > > > From: Andy Tang
> > > > > Sent: 2019年8月6日 10:57
> > > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > version
> > > > > 2 support
> > > > >
> > > > > Any comments?
> > > > >
> > > > > BR,
> > > > > Andy
> > > > >
> > > > > > -Original Message-
> > > > > > From: Yuantian Tang
> > > > > > Sent: 2019年6月4日 10:51
> > > > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy
> > > > > > Tang
> > > > > > Subject: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > > version 2 support
> > > > > >
> > > > > > Thermal Monitor Unit v2 is introduced on new Layscape SoC.
> > > > > > Compared to v1, TMUv2 has a little different register layout
> > > > > > and digital output is fairly linear.
> > > > > >
> > > > > > Signed-off-by: Yuantian Tang
> > > > > > ---
> > > > > > drivers/thermal/qoriq_thermal.c | 122
> > > > > > +---
> > > > > > 1 file changed, 98 insertions(+), 24 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/thermal/qoriq_thermal.c
> > > > > > b/drivers/thermal/qoriq_thermal.c index
> > > > > > 3b5f5b3fb1bc..0df6dfddf804
> > > > > > 100644
> > > > > > --- a/drivers/thermal/qoriq_thermal.c
> > > > > > +++ b/drivers/thermal/qoriq_thermal.c
> > > > > > @@ -13,6 +13,15 @@
> > > > > > #include "thermal_core.h"
> > > > > >
> > > > > > #define SITES_MAX 16
> > > > > > +#define TMR_DISABLE0x0
> > > > > > +#define TMR_ME 0x8000
> > > > > > +#define TMR_ALPF 0x0c00
> > > > > > +#define TMR_ALPF_V20x0300
> > > > > > +#define TMTMIR_DEFAULT 0x000f
> > > > > > +#define TIER_DISABLE 0x0
> > > > > > +#define TEUMR0_V2 0x51009C00
>
> Better to use either lower case or capital letter for all macro definitions,
> some are lower case and some are capital letter look like NOT aligned.
I always use capital letter to define a macro.
Did I use lower letter somewhere?
>
> > > > > > +#define TMU_VER1 0x1
> > > > > > +#define TMU_VER2 0x2
> > > > > >
> > > > > > /*
> > > > > > * QorIQ TMU Registers
> > > > > > @@ -23,17 +32,55 @@ struct qoriq_tmu_site_regs {
> > > > > > u8 res0[0x8];
> > > > > > };
> > > > > >
> > > > > > -struct qoriq_tmu_regs {
> > > > > > +struct qoriq_tmu_regs_v2 {
> > > > > > + u32 tmr;/* Mode Register */
> > > > > > + u32 tsr;/* Status Register */
> > > > > > + u32 tmsr; /* monitor site register */
> > > > > > + u32 tmtmir; /* Temperature measurement
> > > > > > interval Register
> > > >
> > > > */
> > > > > > + u8 res0[0x10];
> > > > > > + u32 tier; /* Interrupt Enable Register */
> > > > > > + u32 tidr; /* Interrupt Detect Register */
> > > > > > + u8 res1[0x8];
> > > > > > + u32 tiiscr; /* interrupt immediate site
> > > > > > capture register */
> > > > > > + u32 tiascr; /* interrupt average site
> > > > > > capture register */
> > > > > > + u32 ticscr; /* Interrupt Critical Site
> > > > > > Capture Register */
> > > > > > + u32 res2;
> > > > > > + u32 tmhtcr; /* monitor high temperature
> > > > > > capture register */
> > > > > > + u32 tmltcr; /* monitor low temperature
> > > > > > capture register */
> > > > > > + u32 tmrtrcr;/* monitor rising temperature rate
> > > > > > capture
[no subject]
-- One million two hundred thousand euros (1,200,000 €) has been donated to you by Frances and Patrick Connolly, we are from County Armagh in Northern Ireland, We won the EuroMillions lottery jackpot of 115 million euros. Email us for more details: frances.connoll...@gmail.com
Re: [PATCH 14/17] KVM: monolithic: x86: inline more exit handlers in vmx.c
On Tue, Sep 24, 2019 at 03:25:34AM +0200, Paolo Bonzini wrote: > On 24/09/19 03:00, Andrea Arcangeli wrote: > > Before and after this specific commit there is a difference with gcc 8.3. > > > > full patchset applied > > > > 753699 879719616 851286 cfd56 build/arch/x86/kvm/kvm-intel.ko > > > > git revert > > > > 753739 879719616 851326 cfd7e build/arch/x86/kvm/kvm-intel.ko > > > > git reset --hard HEAD^ > > > > 753699 879719616 851286 cfd56 build/arch/x86/kvm/kvm-intel.ko > > > > git revert > > > > 753739 879719616 851326 cfd7e build/arch/x86/kvm/kvm-intel.ko > > So it's forty bytes. I think we can leave this out. This commit I reverted adds literally 3 inlines called by 3 functions, in a very fast path, how many bytes of .text difference did you expect by dropping some call/ret from a very fast path when you asked me to test it? I mean it's just a couple of insn each. I thought the question was if gcc was already inlining without the hint or not or if it actually grew in size in case I got it wrong and there were many callers and it was better off not inline, so now I don't get what was the point of this test if with the result that confirms it's needed, the patch should be dropped. It's possible that this patch may not be relevant anymore with the rename in place of the vmx/svm functions, but if this patch is to be dropped with the optimal result, then I recommend you to go ahead and submit a patch to drop __always_inline from the whole kernel because if it's not good to use it here in a extreme fast path like handle_external_interrupt and handle_halt, then I don't know what __always_inline is good for anywhere else in the kernel. Thanks, Andrea
RE: [PATCH v8 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
Hi Catalin
> -Original Message-
> From: Catalin Marinas
> Sent: 2019年9月24日 0:07
> To: Justin He (Arm Technology China)
> Cc: Will Deacon ; Mark Rutland
> ; James Morse ; Marc
> Zyngier ; Matthew Wilcox ; Kirill A.
> Shutemov ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@kvack.org; Suzuki Poulose ; Punit
> Agrawal ; Anshuman Khandual
> ; Alex Van Brunt
> ; Robin Murphy ;
> Thomas Gleixner ; Andrew Morton foundation.org>; Jérôme Glisse ; Ralph Campbell
> ; hejia...@gmail.com; Kaly Xin (Arm Technology
> China) ; nd
> Subject: Re: [PATCH v8 1/3] arm64: cpufeature: introduce helper
> cpu_has_hw_af()
>
> On Sat, Sep 21, 2019 at 09:50:52PM +0800, Jia He wrote:
> > We unconditionally set the HW_AFDBM capability and only enable it on
> > CPUs which really have the feature. But sometimes we need to know
> > whether this cpu has the capability of HW AF. So decouple AF from
> > DBM by new helper cpu_has_hw_af().
> >
> > Reported-by: kbuild test robot
> > Suggested-by: Suzuki Poulose
> > Signed-off-by: Jia He
> > ---
> > arch/arm64/include/asm/cpufeature.h | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/cpufeature.h
> b/arch/arm64/include/asm/cpufeature.h
> > index c96ffa4722d3..46caf934ba4e 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -667,6 +667,16 @@ static inline u32
> id_aa64mmfr0_parange_to_phys_shift(int parange)
> > default: return CONFIG_ARM64_PA_BITS;
> > }
> > }
> > +
> > +/* Decouple AF from AFDBM. */
>
> We could do with a better comment here or just remove it altogether. The
> aim of the patch was to decouple AF check from the AF+DBM but the
> comment here should describe what the function does. Maybe something
> like: "Check whether hardware update of the Access flag is supported".
>
Okay, I will update it
--
Cheers,
Justin (Jia He)
> > +static inline bool cpu_has_hw_af(void)
> > +{
> > + if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
> > + return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
> > +
> > + return false;
> > +}
>
> Other than the comment above,
>
> Reviewed-by: Catalin Marinas
RE: [PATCH v4 2/3] dmaengine: imx-sdma: fix dma freezes
On 2019-9-19 22:30 Philipp Puschmann wrote
> For some years and since many kernel versions there are reports that the RX
> UART SDMA channel stops working at some point. The workaround was to
> disable DMA for RX. This commit tries to fix the problem itself.
>
> Due to its license i wasn't able to debug the sdma script itself but it
> somehow
> leads to blocking the scheduling of the channel script when a running sdma
> script does not find any free descriptor in the ring to put its data into.
>
> If we detect such a potential case we manually restart the channel.
>
> As sdmac->desc is constant we can move desc out of the loop.
>
> Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
In fact, it's a refine patch rather than bug fix, just restore cyclic transfer
back in the corner case. There are two causes for such 'corner case':
1. improper number of BD or length of BD setting for cyclic, so that BD could
be consumed very quickly, worst case is uart Aging timer which one byte
may consume one BD. So for such case, enlarge more BDs is the right way as
your UART patch.
2. High cpu loading so that SDMA interrupt handler can't run in time to set
BD_DONE flag back again, at last all BDs consumed. In such case, this patch
may blind other coding issues such as long time window of disable
irq(spin_lock_irq)
. So I think this patch is much like a refine/restore patch, and it's better to
add
a clear print information to hint user channel is restoring and unexpected high
cpu
loading is coming...
> Signed-off-by: Philipp Puschmann
> Reviewed-by: Lucas Stach
> ---
>
> Changelog v4:
> - fixed the fixes tag
>
> Changelog v3:
> - use correct dma_wmb() instead of dma_wb()
> - add fixes tag
>
> Changelog v2:
> - clarify comment and commit description
>
> drivers/dma/imx-sdma.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
> e029a2443cfc..a32b5962630e 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -775,21 +775,23 @@ static void sdma_start_desc(struct sdma_channel
> *sdmac) static void sdma_update_channel_loop(struct sdma_channel
> *sdmac) {
> struct sdma_buffer_descriptor *bd;
> - int error = 0;
> - enum dma_status old_status = sdmac->status;
> + struct sdma_desc *desc = sdmac->desc;
> + int error = 0, cnt = 0;
> + enum dma_status old_status = sdmac->status;
>
> /*
>* loop mode. Iterate over descriptors, re-setup them and
>* call callback function.
>*/
> - while (sdmac->desc) {
> - struct sdma_desc *desc = sdmac->desc;
> + while (desc) {
>
> bd = >bd[desc->buf_tail];
>
> if (bd->mode.status & BD_DONE)
> break;
>
> + cnt++;
> +
> if (bd->mode.status & BD_RROR) {
> bd->mode.status &= ~BD_RROR;
> sdmac->status = DMA_ERROR;
> @@ -822,6 +824,17 @@ static void sdma_update_channel_loop(struct
> sdma_channel *sdmac)
> if (error)
> sdmac->status = old_status;
> }
> +
> + /* In some situations it may happen that the sdma does not found any
> + * usable descriptor in the ring to put data into. The channel is
> + * stopped then. While there is no specific error condition we can
> + * check for, a necessary condition is that all available buffers for
> + * the current channel have been written to by the sdma script. In
> + * this case and after we have made the buffers available again,
> + * we restart the channel.
> + */
> + if (cnt >= desc->num_bd)
> + sdma_enable_channel(sdmac->sdma, sdmac->channel);
> }
>
> static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
> --
> 2.23.0
Re: [PATCH v3 1/2] memory_hotplug: Add a bounds check to check_hotplug_memory_range()
On Mon, 2019-09-23 at 14:25 +0200, Michal Hocko wrote:
> On Tue 17-09-19 11:07:47, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > On PowerPC, the address ranges allocated to OpenCAPI LPC memory
> > are allocated from firmware. These address ranges may be higher
> > than what older kernels permit, as we increased the maximum
> > permissable address in commit 4ffe713b7587
> > ("powerpc/mm: Increase the max addressable memory to 2PB"). It is
> > possible that the addressable range may change again in the
> > future.
> >
> > In this scenario, we end up with a bogus section returned from
> > __section_nr (see the discussion on the thread "mm: Trigger bug on
> > if a section is not found in __section_nr").
> >
> > Adding a check here means that we fail early and have an
> > opportunity to handle the error gracefully, rather than rumbling
> > on and potentially accessing an incorrect section.
> >
> > Further discussion is also on the thread ("powerpc: Perform a
> > bounds
> > check in arch_add_memory").
>
> It would be nicer to refer to this by a message-id based url.
> E.g.
> http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
>
Ok.
> > Signed-off-by: Alastair D'Silva
> > ---
> > include/linux/memory_hotplug.h | 1 +
> > mm/memory_hotplug.c| 13 -
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/memory_hotplug.h
> > b/include/linux/memory_hotplug.h
> > index f46ea71b4ffd..bc477e98a310 100644
> > --- a/include/linux/memory_hotplug.h
> > +++ b/include/linux/memory_hotplug.h
> > @@ -110,6 +110,7 @@ extern void
> > __online_page_increment_counters(struct page *page);
> > extern void __online_page_free(struct page *page);
> >
> > extern int try_online_node(int nid);
> > +int check_hotplug_memory_addressable(u64 start, u64 size);
> >
> > extern int arch_add_memory(int nid, u64 start, u64 size,
> > struct mhp_restrictions *restrictions);
> > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > index c73f09913165..02cb9a74f561 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1030,6 +1030,17 @@ int try_online_node(int nid)
> > return ret;
> > }
> >
> > +int check_hotplug_memory_addressable(u64 start, u64 size)
> > +{
> > +#ifdef MAX_PHYSMEM_BITS
> > + if ((start + size - 1) >> MAX_PHYSMEM_BITS)
> > + return -E2BIG;
> > +#endif
>
> Is there any arch which doesn't define this? We seemed to be using
> this
> in sparsemem code without any ifdefs.
A few, but none of them would be enabling hotplug (which depends on
sparsemem), so you're right, the ifdef could be removed.
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(check_hotplug_memory_addressable);
>
> If you squashed the patch 2 then it would become clear why this needs
> to
> be exported because you would have a driver user. I find it a bit
> unfortunate to expect that any driver which uses the hotplug code is
> expected to know that this check should be called. This sounds too
> error
> prone. Why hasn't been this done at __add_pages layer?
>
It seemed that is should be a peer of check_hotplug_memory_range(), as
it gives similar feedback (whether the provided range is suitable).
If we did the check in __add_pages, wouldn't we potentially lose bits
from the LSBs of start & size, or is there some other requirement that
already ensures start & size are always page aligned?
It appears this patch has been accepted - if we were to make this
change, does it go as another spin on this series or a new series?
> > +
> > static int check_hotplug_memory_range(u64 start, u64 size)
> > {
> > /* memory range must be block size aligned */
> > @@ -1040,7 +1051,7 @@ static int check_hotplug_memory_range(u64
> > start, u64 size)
> > return -EINVAL;
> > }
> >
> > - return 0;
> > + return check_hotplug_memory_addressable(start, size);
>
> This will result in a silent failure (unlike misaligned case). Is
> this
> what we want?
Good point - I guess it comes down to, is there anything we expect an
end user to do about it? I'm not sure there is, in which case the bad
RC, which is reported up every call chain that I can see, should be
sufficient.
> > }
> >
> > static int online_memory_block(struct memory_block *mem, void
> > *arg)
> > --
> > 2.21.0
> >
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org
Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
On (09/23/19 14:58), Petr Mladek wrote: > > If I understand it correctly then this is the re-appearing problem. > The only systematic solution with the current approach is to > take port->lock in printk_safe/printk_deferred context. It probably is. We have a number of reverse paths. TTY invokes MM under port->lock, UART invokes TTY under port->lock, MM invokes UART under zone->lock, UART invokes sched under port->lock, shced invokes UART, UART invokes UART under port->lock (!), and so on. > But this is a massive change that almost nobody wants. Instead, > we want the changes that were discussed on Plumbers. > > Now, the question is what to do with existing kernels. There were > several lockdep reports. And I am a bit lost. Did anyone seen > real deadlocks or just the lockdep reports? I think so. Qian Cai mentioned "a hang" in one of his reports (was it unseeded random()?). I'll send a formal patch maybe, since there were no objections. > To be clear. I would feel more comfortable when there are no > deadlocks. But I also do not want to invest too much time > into old kernels. All these problems were there for ages. > We could finally see them because lockdep was enabled in printk() > thanks to printk_safe. True. Everyone was so much happier when printk() used to do lockdep_off(); call_console_drivers(); lockdep_on(); Now we can have lockdep and RCU checks enabled, yet somehow printk_safe is still "a terrible thing" :) -ss
Re: [PATCH 14/17] KVM: monolithic: x86: inline more exit handlers in vmx.c
On 24/09/19 03:00, Andrea Arcangeli wrote: > Before and after this specific commit there is a difference with gcc 8.3. > > full patchset applied > > 753699 879719616 851286 cfd56 build/arch/x86/kvm/kvm-intel.ko > > git revert > > 753739 879719616 851326 cfd7e build/arch/x86/kvm/kvm-intel.ko > > git reset --hard HEAD^ > > 753699 879719616 851286 cfd56 build/arch/x86/kvm/kvm-intel.ko > > git revert > > 753739 879719616 851326 cfd7e build/arch/x86/kvm/kvm-intel.ko So it's forty bytes. I think we can leave this out. Paolo
Re: [GIT PULL] Smack patches for v5.4
The pull request you sent on Mon, 23 Sep 2019 10:24:21 -0700: > https://github.com/cschaufler/smack-next.git smack-for-5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e94f8ccde4710f9a3e51dd3bc6134c96e33f29b3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 13/17] KVM: monolithic: x86: drop the kvm_pmu_ops structure
On 24/09/19 02:51, Andrea Arcangeli wrote: > This was covered in the commit header of patch 2: Oops, sorry. > Lot more patches are needed to get rid of kvm_x86_ops entirely because > there are lots of places checking the actual value of the method > before making the indirect call. I tried to start that, but then it > got into potentially heavily rejecting territory, so I thought it was > simpler to start with what I had, considering from a performance > standpoint it's optimal already as far as retpolines are concerned. The performance may be good enough, but the maintainability is bad. Let's make a list of function pointers that are checked, and function pointers that are written at init time. For the former, it should be possible to make them __weak symbols so that they are NULL if undeclared. For the latter, module parameters can be made extern and then you can have checks like kvm_x86_has_...() in inline functions in a header file. Paolo
Re: [PATCH] smack: include linux/watch_queue.h
On Mon, Sep 23, 2019 at 2:50 PM Casey Schaufler wrote: > > On 9/9/2019 1:46 PM, Arnd Bergmann wrote: > > In some randconfig builds, the lack of an explicit #include > > in smack_lsm.c causes a build failure: > > What tree/branch are you working with? I don't see this. It was in the latest linux-next at the time I posted the patch. It's possible that the patch causing the problem got removed in the meantime. Arnd
Re: [PATCH 1/1] powerpc: kvm: Reduce calls to get current->mm by storing the value locally
I have done a very simple comparison with gdb disassemble:
By applying this patch, there was a reduction in the function size from
882 to 878 instructions.
(It's a resend, due to not having all the correct lists on my previous
mail)
On Mon, 2019-09-23 at 18:30 -0300, Leonardo Bras wrote:
> Reduces the number of calls to get_current() in order to get the value of
> current->mm by doing it once and storing the value, since it is not
> supposed to change inside the same process).
>
> Signed-off-by: Leonardo Bras
> ---
> Re-sending to all lists involved. (I missed kvm ones)
>
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 9a75f0e1933b..f2b9aea43216 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -508,6 +508,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> struct vm_area_struct *vma;
> unsigned long rcbits;
> long mmio_update;
> + struct mm_struct *mm;
>
> if (kvm_is_radix(kvm))
> return kvmppc_book3s_radix_page_fault(run, vcpu, ea, dsisr);
> @@ -584,6 +585,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> is_ci = false;
> pfn = 0;
> page = NULL;
> + mm = current->mm;
> pte_size = PAGE_SIZE;
> writing = (dsisr & DSISR_ISSTORE) != 0;
> /* If writing != 0, then the HPTE must allow writing, if we get here */
> @@ -592,8 +594,8 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> npages = get_user_pages_fast(hva, 1, writing ? FOLL_WRITE : 0, pages);
> if (npages < 1) {
> /* Check if it's an I/O mapping */
> - down_read(>mm->mmap_sem);
> - vma = find_vma(current->mm, hva);
> + down_read(>mmap_sem);
> + vma = find_vma(mm, hva);
> if (vma && vma->vm_start <= hva && hva + psize <= vma->vm_end &&
> (vma->vm_flags & VM_PFNMAP)) {
> pfn = vma->vm_pgoff +
> @@ -602,7 +604,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> is_ci = pte_ci(__pte((pgprot_val(vma->vm_page_prot;
> write_ok = vma->vm_flags & VM_WRITE;
> }
> - up_read(>mm->mmap_sem);
> + up_read(>mmap_sem);
> if (!pfn)
> goto out_put;
> } else {
> @@ -621,8 +623,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
>* hugepage split and collapse.
>*/
> local_irq_save(flags);
> - ptep = find_current_mm_pte(current->mm->pgd,
> -hva, NULL, NULL);
> + ptep = find_current_mm_pte(mm->pgd, hva, NULL, NULL);
> if (ptep) {
> pte = kvmppc_read_update_linux_pte(ptep, 1);
> if (__pte_write(pte))
signature.asc
Description: This is a digitally signed message part
RE: [PATCH] rtlwifi: rtl8723ae: Remove unused 'rtstatus' variable
> -Original Message- > From: Austin Kim [mailto:austindh@gmail.com] > Sent: Monday, September 23, 2019 9:35 PM > To: Pkshih; kv...@codeaurora.org; da...@davemloft.net > Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH] rtlwifi: rtl8723ae: Remove unused 'rtstatus' variable > > Hello, Maintainers... > Would you please review above patch if you are available? > You can check status of your patch here https://patchwork.kernel.org/project/linux-wireless/list/?series=174859 If your patch is existing in patchwork, maintainer doesn't forget it. Another thing is to avoid top posting that makes maintainer hard to read mail. --- PK
RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2 support
Hi, Andy
> On Mon, 2019-09-23 at 09:24 +, Andy Tang wrote:
> > Hi Rui, Edubezval,
> >
> > Would you please review this patch?
> >
> CC Anson Huang.
> I'd prefer all the qoriq thermal patches go through his review first.
>
> thanks,
> rui
>
> > BR,
> > Andy
> >
> > > -Original Message-
> > > From: Andy Tang
> > > Sent: 2019年8月29日 16:38
> > > To: 'edubez...@gmail.com' ;
> > > 'rui.zh...@intel.com'
> > >
> > > Cc: 'daniel.lezc...@linaro.org' ; Leo Li
> > > ; 'linux...@vger.kernel.org'
> > > ; 'linux-kernel@vger.kernel.org'
> > >
> > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > version 2 support
> > >
> > > Hi Rui, Edubezval,
> > >
> > > Almost three monthes passed, I have not got your comments from you.
> > > Could you please take a look at this patch?
> > >
> > > BR,
> > > Andy
> > >
> > > > -Original Message-
> > > > From: Andy Tang
> > > > Sent: 2019年8月6日 10:57
> > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > version
> > > > 2 support
> > > >
> > > > Any comments?
> > > >
> > > > BR,
> > > > Andy
> > > >
> > > > > -Original Message-
> > > > > From: Yuantian Tang
> > > > > Sent: 2019年6月4日 10:51
> > > > > To: edubez...@gmail.com; rui.zh...@intel.com
> > > > > Cc: daniel.lezc...@linaro.org; Leo Li ;
> > > > > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy
> > > > > Tang
> > > > > Subject: [PATCH] thermal: qoriq: add thermal monitor unit
> > > > > version 2 support
> > > > >
> > > > > Thermal Monitor Unit v2 is introduced on new Layscape SoC.
> > > > > Compared to v1, TMUv2 has a little different register layout and
> > > > > digital output is fairly linear.
> > > > >
> > > > > Signed-off-by: Yuantian Tang
> > > > > ---
> > > > > drivers/thermal/qoriq_thermal.c | 122
> > > > > +---
> > > > > 1 file changed, 98 insertions(+), 24 deletions(-)
> > > > >
> > > > > diff --git a/drivers/thermal/qoriq_thermal.c
> > > > > b/drivers/thermal/qoriq_thermal.c index
> > > > > 3b5f5b3fb1bc..0df6dfddf804
> > > > > 100644
> > > > > --- a/drivers/thermal/qoriq_thermal.c
> > > > > +++ b/drivers/thermal/qoriq_thermal.c
> > > > > @@ -13,6 +13,15 @@
> > > > > #include "thermal_core.h"
> > > > >
> > > > > #define SITES_MAX16
> > > > > +#define TMR_DISABLE 0x0
> > > > > +#define TMR_ME 0x8000
> > > > > +#define TMR_ALPF 0x0c00
> > > > > +#define TMR_ALPF_V2 0x0300
> > > > > +#define TMTMIR_DEFAULT 0x000f
> > > > > +#define TIER_DISABLE 0x0
> > > > > +#define TEUMR0_V20x51009C00
Better to use either lower case or capital letter for all macro definitions,
some are lower case and some are capital letter look like NOT aligned.
> > > > > +#define TMU_VER1 0x1
> > > > > +#define TMU_VER2 0x2
> > > > >
> > > > > /*
> > > > > * QorIQ TMU Registers
> > > > > @@ -23,17 +32,55 @@ struct qoriq_tmu_site_regs {
> > > > > u8 res0[0x8];
> > > > > };
> > > > >
> > > > > -struct qoriq_tmu_regs {
> > > > > +struct qoriq_tmu_regs_v2 {
> > > > > + u32 tmr;/* Mode Register */
> > > > > + u32 tsr;/* Status Register */
> > > > > + u32 tmsr; /* monitor site register */
> > > > > + u32 tmtmir; /* Temperature measurement
> > > > > interval Register
> > >
> > > */
> > > > > + u8 res0[0x10];
> > > > > + u32 tier; /* Interrupt Enable Register */
> > > > > + u32 tidr; /* Interrupt Detect Register */
> > > > > + u8 res1[0x8];
> > > > > + u32 tiiscr; /* interrupt immediate site
> > > > > capture register */
> > > > > + u32 tiascr; /* interrupt average site
> > > > > capture register */
> > > > > + u32 ticscr; /* Interrupt Critical Site
> > > > > Capture Register */
> > > > > + u32 res2;
> > > > > + u32 tmhtcr; /* monitor high temperature
> > > > > capture register */
> > > > > + u32 tmltcr; /* monitor low temperature
> > > > > capture register */
> > > > > + u32 tmrtrcr;/* monitor rising temperature rate
> > > > > capture register
> > >
> > > */
> > > > > + u32 tmftrcr;/* monitor falling temperature rate
> > > > > capture register
> > >
> > > */
> > > > > + u32 tmhtitr;/* High Temperature Immediate Threshold
> > > > > */
> > > > > + u32 tmhtatr;/* High Temperature Average Threshold
> > > > > */
> > > > > + u32 tmhtactr; /* High Temperature Average Crit
> > > > > Threshold */
> > > > > + u32 res3;
> > > > > + u32 tmltitr;/* monitor low temperature immediate
> > > > > threshold */
> > > > > + u32 tmltatr;/* monitor low temperature average
> > > > > threshold
> > >
> > > register */
> > > > > + u32 tmltactr; /* monitor low temperature average
RE: [Patch v4] storvsc: setup 1:1 mapping between hardware queue and CPU queue
>Subject: RE: [Patch v4] storvsc: setup 1:1 mapping between hardware queue >and CPU queue > >>Subject: Re: [Patch v4] storvsc: setup 1:1 mapping between hardware >>queue and CPU queue >> >>On Fri, Sep 06, 2019 at 10:24:20AM -0700, lon...@linuxonhyperv.com wrote: >>>From: Long Li >>> >>>storvsc doesn't use a dedicated hardware queue for a given CPU queue. >>>When issuing I/O, it selects returning CPU (hardware queue) >>>dynamically based on vmbus channel usage across all channels. >>> >>>This patch advertises num_present_cpus() as number of hardware queues. >>>This will have upper layer setup 1:1 mapping between hardware queue >>>and CPU queue and avoid unnecessary locking when issuing I/O. >>> >>>Signed-off-by: Long Li Hi Martin, I have addressed all comments on this patch. Can you merge it to SCSI? If there is anything else I need to change, please let me know. Thanks Long >>>--- >>> >>>Changes: >>>v2: rely on default upper layer function to map queues. (suggested by >>>Ming Lei >>>) >>>v3: use num_present_cpus() instead of num_online_cpus(). Hyper-v >>>doesn't support hot-add CPUs. (suggested by Michael Kelley >>>) >>>v4: move change logs to after Signed-of-by >>> >>> drivers/scsi/storvsc_drv.c | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>>diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c >>>index b89269120a2d..cf987712041a 100644 >>>--- a/drivers/scsi/storvsc_drv.c >>>+++ b/drivers/scsi/storvsc_drv.c >>>@@ -1836,8 +1836,7 @@ static int storvsc_probe(struct hv_device *device, >>> /* >>> * Set the number of HW queues we are supporting. >>> */ >>>-if (stor_device->num_sc != 0) >>>-host->nr_hw_queues = stor_device->num_sc + 1; >>>+host->nr_hw_queues = num_present_cpus(); >> >>Just looking at the change notes for v3: why isn't this >>num_active_cpus() then? One can still isolate CPUs on hyper-v, no? > >The isolated CPU can be made online at run time. For example, even >maxcpus=x is put on the boot line, individual CPUs can still be made >online/offline. > >> >>-- >>Thanks, >>Sasha
[PATCH V8 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan V8: Add missed arm-smccc-mbox.h V7: Typo fix #mbox-cells changed to 0 Add a new header file arm-smccc-mbox.h Use ARM_SMCCC_IS_64 Andre, The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id property is optional, so clients could pass function_id to mbox driver. V6: Switch to per-channel a mbox controller Drop arm,num-chans, transports, method Add arm,hvc-mbox compatible Fix smc/hvc args, drop client id and use correct type. https://patchwork.kernel.org/cover/11146641/ V5: yaml fix https://patchwork.kernel.org/cover/7741/ V4: yaml fix for num-chans in patch 1/2. https://patchwork.kernel.org/cover/6521/ V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format https://patchwork.kernel.org/cover/11043541/ V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 95 drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 168 + include/linux/mailbox/arm-smccc-mbox.h | 22 +++ 5 files changed, 294 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smccc-mbox.h -- 2.16.4
[PATCH V8 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 95 ++
1 file changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..8764ad2726b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) or hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. The value of r0/w0/x0
+ the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so synchronous communication can be
+ established. The exact meaning of the action the mailbox triggers as
+ well as the return value is defined by their users and is not subject
+ to this binding.
+
+ One example use case of this mailbox is the SCMI interface, which uses
+ shared memory to transfer commands and parameters, and a mailbox to
+ trigger a function call. This allows SoCs without a separate management
+ processor (or when such a processor is not available or used) to use
+ this standardized interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using the described SMC function identifier, the
+ firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifier are passed from consumers, or listed in the the arm,func-id
+ property as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long
+ as a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+oneOf:
+ - description:
+ For implementations using ARM SMC instruction.
+const: arm,smc-mbox
+
+ - description:
+ For implementations using ARM HVC instruction.
+const: arm,hvc-mbox
+
+ "#mbox-cells":
+const: 0
+
+ arm,func-id:
+description: |
+ An single 32-bit value specifying the function ID used by the mailbox.
+ The function ID follows the ARM SMC calling convention standard.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - "#mbox-cells"
+
+examples:
+ - |
+sram@93f000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+compatible = "arm,scmi-shmem";
+reg = <0x0 0x200>;
+ };
+};
+
+smc_tx_mbox: tx_mbox {
+ #mbox-cells = <0>;
+ compatible = "arm,smc-mbox";
+ arm,func-id = <0xc2fe>;
+};
+
+firmware {
+ scmi {
+compatible = "arm,scmi";
+mboxes = <_tx_mbox>;
+mbox-names = "tx";
+shmem = <_scp_lpri>;
+ };
+};
+
+...
--
2.16.4
[PATCH V8 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara
Signed-off-by: Peng Fan
---
drivers/mailbox/Kconfig| 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 168 +
include/linux/mailbox/arm-smccc-mbox.h | 22 +
4 files changed, 199 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
create mode 100644 include/linux/mailbox/arm-smccc-mbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..664c8b4a0ed0
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct arm_smc_chan_data {
+ unsigned int function_id;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+
+ function_id = chan_data->function_id;
+ if (!function_id)
+ function_id = cmd->function_id;
+
+ if (ARM_SMCCC_IS_64(function_id)) {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
+cmd->args_smccc64[1],
+cmd->args_smccc64[2],
+cmd->args_smccc64[3],
+cmd->args_smccc64[4],
+cmd->args_smccc64[5]);
+ } else {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
+cmd->args_smccc32[1],
+cmd->args_smccc32[2],
+cmd->args_smccc32[3],
+cmd->args_smccc32[4],
+cmd->args_smccc32[5]);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, );
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+
Re: [PATCH] writeback: fix use-after-free in finish_writeback_work()
On 9/23/19 7:06 PM, Tejun Heo wrote:
> finish_writeback_work() reads @done->waitq after decrementing
> @done->cnt. However, once @done->cnt reaches zero, @done may be freed
> (from stack) at any moment and @done->waitq can contain something
> unrelated by the time finish_writeback_work() tries to read it. This
> led to the following crash.
>
>"BUG: kernel NULL pointer dereference, address: 0002"
>#PF: supervisor write access in kernel mode
>#PF: error_code(0x0002) - not-present page
>PGD 0 P4D 0
>Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
>CPU: 40 PID: 555153 Comm: kworker/u98:50 Kdump: loaded Not tainted
>...
>Workqueue: writeback wb_workfn (flush-btrfs-1)
>RIP: 0010:_raw_spin_lock_irqsave+0x10/0x30
>Code: 48 89 d8 5b c3 e8 50 db 6b ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00
> 00 00 00 0f 1f 44 00 00 53 9c 5b fa 31 c0 ba 01 00 00 00 0f b1 17 75 05
> 48 89 d8 5b c3 89 c6 e8 fe ca 6b ff eb f2 66 90
>RSP: 0018:c90049b27d98 EFLAGS: 00010046
>RAX: RBX: 0246 RCX:
>RDX: 0001 RSI: 0003 RDI: 0002
>RBP: R08: R09: 0001
>R10: 889fff407600 R11: 88ba9395d740 R12: e300
>R13: 0003 R14: R15:
>FS: () GS:88bfdfa0()
> knlGS:
>CS: 0010 DS: ES: CR0: 80050033
>CR2: 0002 CR3: 02409005 CR4: 001606e0
>Call Trace:
> __wake_up_common_lock+0x63/0xc0
> wb_workfn+0xd2/0x3e0
> process_one_work+0x1f5/0x3f0
> worker_thread+0x2d/0x3d0
> kthread+0x111/0x130
> ret_from_fork+0x1f/0x30
>
> Fix it by reading and caching @done->waitq before decrementing
> @done->cnt.
That's some nice debugging work.
Reviewed-by: Jens Axboe
> Signed-off-by: Tejun Heo
> Debugged-by: Chris Mason
> Fixes: 30638b0125e1 ("writeback: Generalize and expose wb_completion")
This seems wrong, though:
commit 5b9cce4c7eb0696558dfd4946074ae1fb9d8f05d
Author: Tejun Heo
Date: Mon Aug 26 09:06:52 2019 -0700
writeback: Generalize and expose wb_completion
--
Jens Axboe
Re: [PATCH] printk: Fix unnecessary returning broken pipe error from devkmsg_read
On (09/23/19 18:45), He Zhe wrote: > I think it is NOT necessary to inform user-space, when it just wants to read > from the beginning of the buffer, that the buffer has changed since the time > point when it issues the action of reading. The point here is not to notify user space that the logbuf has changed, but to notify user space that unseen messages are gone, we lost them, user space will never read them. -ss
[PATCH] writeback: fix use-after-free in finish_writeback_work()
finish_writeback_work() reads @done->waitq after decrementing
@done->cnt. However, once @done->cnt reaches zero, @done may be freed
(from stack) at any moment and @done->waitq can contain something
unrelated by the time finish_writeback_work() tries to read it. This
led to the following crash.
"BUG: kernel NULL pointer dereference, address: 0002"
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
CPU: 40 PID: 555153 Comm: kworker/u98:50 Kdump: loaded Not tainted
...
Workqueue: writeback wb_workfn (flush-btrfs-1)
RIP: 0010:_raw_spin_lock_irqsave+0x10/0x30
Code: 48 89 d8 5b c3 e8 50 db 6b ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00
00 00 0f 1f 44 00 00 53 9c 5b fa 31 c0 ba 01 00 00 00 0f b1 17 75 05 48 89
d8 5b c3 89 c6 e8 fe ca 6b ff eb f2 66 90
RSP: 0018:c90049b27d98 EFLAGS: 00010046
RAX: RBX: 0246 RCX:
RDX: 0001 RSI: 0003 RDI: 0002
RBP: R08: R09: 0001
R10: 889fff407600 R11: 88ba9395d740 R12: e300
R13: 0003 R14: R15:
FS: () GS:88bfdfa0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0002 CR3: 02409005 CR4: 001606e0
Call Trace:
__wake_up_common_lock+0x63/0xc0
wb_workfn+0xd2/0x3e0
process_one_work+0x1f5/0x3f0
worker_thread+0x2d/0x3d0
kthread+0x111/0x130
ret_from_fork+0x1f/0x30
Fix it by reading and caching @done->waitq before decrementing
@done->cnt.
Signed-off-by: Tejun Heo
Debugged-by: Chris Mason
Fixes: 30638b0125e1 ("writeback: Generalize and expose wb_completion")
Cc: sta...@vger.kernel.org # v5.2+
---
fs/fs-writeback.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 8aaa7eec7b74..e88421d9a48d 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -164,8 +164,13 @@ static void finish_writeback_work(struct bdi_writeback *wb,
if (work->auto_free)
kfree(work);
- if (done && atomic_dec_and_test(>cnt))
- wake_up_all(done->waitq);
+ if (done) {
+ wait_queue_head_t *waitq = done->waitq;
+
+ /* @done can't be accessed after the following dec */
+ if (atomic_dec_and_test(>cnt))
+ wake_up_all(waitq);
+ }
}
static void wb_queue_work(struct bdi_writeback *wb,
[GIT PULL] Hyper-V commits for 5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-next-signed for you to fetch changes up to d8bd2d442bb2688b428ac7164e5dc6d95d4fa65b: Drivers: hv: vmbus: Resume after fixing up old primary channels (2019-09-06 14:52:44 -0400) - - - First round of vmbus hibernation support from Dexuan Cui. - - Removal of dependencies on PAGE_SIZE by Maya Nakamura. - - Moving the hyper-v tools/ code into the tools build system by Andy Shevchenko. - - hyper-v balloon cleanups by Dexuan Cui. - Andy Shevchenko (1): Tools: hv: move to tools buildsystem Dexuan Cui (11): hv_balloon: Use a static page for the balloon_up send buffer hv_balloon: Reorganize the probe function Drivers: hv: vmbus: Break out synic enable and disable operations Drivers: hv: vmbus: Suspend/resume the synic for hibernation Drivers: hv: vmbus: Add a helper function is_sub_channel() Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for hibernation Drivers: hv: vmbus: Ignore the offers when resuming from hibernation Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation Drivers: hv: vmbus: Clean up hv_sock channels by force upon suspend Drivers: hv: vmbus: Suspend after cleaning up hv_sock and sub channels Drivers: hv: vmbus: Resume after fixing up old primary channels Maya Nakamura (1): HID: hv: Remove dependencies on PAGE_SIZE for ring buffer drivers/hid/hid-hyperv.c | 4 +- drivers/hv/channel_mgmt.c | 161 +--- drivers/hv/connection.c | 8 +- drivers/hv/hv.c | 66 +++- drivers/hv/hv_balloon.c | 143 - drivers/hv/hyperv_vmbus.h | 30 ++ drivers/hv/vmbus_drv.c| 265 ++ include/linux/hyperv.h| 16 ++- tools/hv/Build| 3 + tools/hv/Makefile | 51 +++-- 10 files changed, 613 insertions(+), 134 deletions(-) create mode 100644 tools/hv/Build -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAl2Jaw0ACgkQ3qZv95d3 LNx6xg//WxLzQxi8rnxO2vYFWL9/Hq0ZZfUTHVE3FuRYJdI/IZlFhR0Kw/5MOcT3 PmAFuLNbGFDbDTP21oI+eXVHbrp8mWbSfNRR9EN/BGCErB6WAVTJlrm8ImEe8aBj yDU4PjMp7gHwSCcuyYh813Uj9jlPybISyroCBnJ2q2M7iSLSb/wlUR+3KB+p99eS ScyAl0KS7f/hUI1MRUEJ/0i+buEGwG9uBGsEFcicVLqNwD1Mly1ulmyXY6oQm+QZ P7/PO7k3h/nlCr5QI9rJVsZqy0pZcRp5RI9JIriPHyCQNxy2V7bpvl979XtrODv6 3F2UNBw4I73XUZ4GcQlGeM7kVAc6CuuyiKnbRqa58e4Bjnhzj+VDbk5Brf4LFyYl ZG4rDuBTBU5cfKi2fjmasYjgfGtQdWdhTeJM+aqsT7ScyevH/8N7k1Vte9K1s5O8 xx1MszBQ27/KxMqKD8TiL2GKQU036FiQdEnnS8We1XD1ryCR6EA+WgWRQennsZa0 jUbGJOTI3SPcjxM8oHzuiJSIK6gKRq+zKY51EVeTNwEOCPnp+WwqVO9I8inVSN0m WwJd84pxGXuqjjIe8FvmtUE3B0AF7bW8bPV+aNeDEtPOPMPzSW9HHKWS+rllKnsA 3Z4ktdCl1Al8dsKU9mJPuzAGn0Sxg3zKQ9VPTvZUQt2WYRWjKi4= =y2xA -END PGP SIGNATURE-
Re: [PATCH 14/17] KVM: monolithic: x86: inline more exit handlers in vmx.c
On Mon, Sep 23, 2019 at 12:19:12PM +0200, Paolo Bonzini wrote: > On 20/09/19 23:25, Andrea Arcangeli wrote: > > They can be called directly more efficiently, so we can as well mark > > some of them inline in case gcc doesn't decide to inline them. > > What is the output of size(1) before and after? Before and after this specific commit there is a difference with gcc 8.3. full patchset applied 753699 879719616 851286 cfd56 build/arch/x86/kvm/kvm-intel.ko git revert 753739 879719616 851326 cfd7e build/arch/x86/kvm/kvm-intel.ko git reset --hard HEAD^ 753699 879719616 851286 cfd56 build/arch/x86/kvm/kvm-intel.ko git revert 753739 879719616 851326 cfd7e build/arch/x86/kvm/kvm-intel.ko
Re: allow larger than require DMA masks
On Mon, 2019-09-23 at 23:14 +0200, Sven Schnelle wrote: > Hi, > > On Fri, Feb 15, 2019 at 03:45:54PM +0100, Christoph Hellwig wrote: > > Hi all, > > > > this series finishes off converting our dma mask model to split > > between device capabilities (dev->dma_mask and dev- > > >coherent_dma_mask) and system limitations (dev->bus_dma_mask). We > > already accept larger than required masks in most dma_map_ops > > implementation, in case of x86 and implementations based on it > > since the dawn of time. Only one parisc and two sparc64 instances > > failed larger than required DMA masks, and this series fixes that > > up and updates the documentation that devices don't need to handle > > DMA mask fallbacks. > > > > I just tried latest linux-5.4 git on my hp c8000 (parisc), and got > the following > error: > > [ 27.246866] sata_sil24 :00:01.0: Applying completion IRQ loss > on PCI-X errata fix > [ 27.336968] sata_sil24 :00:01.0: DMA enable failed > [ 27.476922] sata_sil24: probe of :00:01.0 failed with error -5 > > This is caused by commit dcc02c19cc06bd7bc1b6db0aa0087a2b6eb05b94: > Author: Christoph Hellwig > Date: Mon Aug 26 12:57:24 2019 +0200 > > sata_sil24: use dma_set_mask_and_coherent > > Use the dma_set_mask_and_coherent helper to set the DMA mask. > Rely > on the relatively recent change that setting a larger than > required > mask will never fail to avoid the need for the boilerplate 32-bit > fallback code. > > Signed-off-by: Christoph Hellwig > Signed-off-by: Jens Axboe > > However, the real problem seems to be in sba_dma_supported(): > > » /* Documentation/DMA-API-HOWTO.txt tells drivers to try > »* first, then fall back to 32-bit if that fails. > »* We are just "encouraging" 32-bit DMA masks here since we > can > »* never allow IOMMU bypass unless we add special support for > ZX1. > »*/ > if (mask > ~0U) > » » return 0; > > Removing the if() makes the DMA mapping work. It's almost midnight > here, so i won't look into that any further today. Does anyone have > an opinion on this behaviour? Otherwise i will look a bit more into > this in the next days. The reason for the if was to kick the device into 32 bit descriptors, which are usually more efficient, especially with older dual descriptor format cards like we have on parisc systems. Nothing should go wrong if we don't fail the larger mask request except that the card uses the inefficient descriptors whereas we'll only supply it with 32 bit addresses. James
RE: [PATCH 1/4] softirq: implement IRQ flood detection mechanism
>Thanks for the clarification. > >The problem with what Ming is proposing in my mind (and its an existing >problem that exists today), is that nvme is taking precedence over anything >else until it absolutely cannot hog the cpu in hardirq. > >In the thread Ming referenced a case where today if the cpu core has a net >softirq activity it cannot make forward progress. So with Ming's suggestion, >net softirq will eventually make progress, but it creates an inherent fairness >issue. Who said that nvme completions should come faster then the net rx/tx >or another I/O device (or hrtimers or sched events...)? > >As much as I'd like nvme to complete as soon as possible, I might have other >activities in the system that are as important if not more. So I don't think we >can solve this with something that is not cooperative or fair with the rest of >the system. > >>> If we are context switching too much, it means the soft-irq operation >>> is not efficient, not necessarily the fact that the completion path >>> is running in soft- irq.. >>> >>> Is your kernel compiled with full preemption or voluntary preemption? >> >> The tests are based on Ubuntu 18.04 kernel configuration. Here are the >parameters: >> >> # CONFIG_PREEMPT_NONE is not set >> CONFIG_PREEMPT_VOLUNTARY=y >> # CONFIG_PREEMPT is not set > >I see, so it still seems that irq_poll_softirq is still not efficient in >reaping >completions. reaping the completions on its own is pretty much the same in >hard and soft irq, so its really the scheduling part that is creating the >overhead >(which does not exist in hard irq). > >Question: >when you test with without the patch (completions are coming in hard-irq), >do the fio threads that run on the cpu cores that are assigned to the cores >that >are handling interrupts get substantially lower throughput than the rest of the >fio threads? I would expect that the fio threads that are running on the first >32 >cores to get very low iops (overpowered by the nvme interrupts) and the rest >doing much more given that nvme has almost no limits to how much time it >can spend on processing completions. > >If need_resched() is causing us to context switch too aggressively, does >changing that to local_softirq_pending() make things better? >-- >diff --git a/lib/irq_poll.c b/lib/irq_poll.c index d8eab563fa77..05d524fcaf04 >100644 >--- a/lib/irq_poll.c >+++ b/lib/irq_poll.c >@@ -116,7 +116,7 @@ static void __latent_entropy irq_poll_softirq(struct >softirq_action *h) > /* > * If softirq window is exhausted then punt. > */ >- if (need_resched()) >+ if (local_softirq_pending()) > break; > } >-- > >Although, this can potentially cause other threads from making forward >progress.. If it is better, perhaps we also need a time limit as well. Thanks for this patch. The IOPS was about the same. (it tends to fluctuate more but within 3% variation) I captured the following from one of the CPUs. All CPUs tend to have similar numbers. The following numbers are captured during 5 seconds and averaged: Context switches/s: Without any patch: 5 With the previous patch: 640 With this patch: 522 Process migrated/s: Without any patch: 0.6 With the previous patch: 104 With this patch: 121 > >Perhaps we should add statistics/tracing on how many completions we are >reaping per invocation... I'll look into a bit more on completion. From the numbers I think the increased number of context switches/migrations are hurting most on performance. Thanks Long
Re: [PATCH 13/17] KVM: monolithic: x86: drop the kvm_pmu_ops structure
On Mon, Sep 23, 2019 at 12:21:43PM +0200, Paolo Bonzini wrote: > On 20/09/19 23:25, Andrea Arcangeli wrote: > > Cleanup after this was finally left fully unused. > > > > Signed-off-by: Andrea Arcangeli > > --- > > arch/x86/include/asm/kvm_host.h | 3 --- > > arch/x86/kvm/pmu.h | 19 --- > > arch/x86/kvm/pmu_amd.c | 15 --- > > arch/x86/kvm/svm.c | 1 - > > arch/x86/kvm/vmx/pmu_intel.c| 15 --- > > arch/x86/kvm/vmx/vmx.c | 2 -- > > 6 files changed, 55 deletions(-) > > Is there any reason not to do the same for kvm_x86_ops? This was covered in the commit header of patch 2: To reduce the rejecting parts while tracking upstream, this doesn't attempt to entirely remove the kvm_x86_ops structure yet, that is meant for a later cleanup. The pmu ops have been already cleaned up in this patchset because it was left completely unused right after the conversion from pointer to functions to external functions. Lot more patches are needed to get rid of kvm_x86_ops entirely because there are lots of places checking the actual value of the method before making the indirect call. I tried to start that, but then it got into potentially heavily rejecting territory, so I thought it was simpler to start with what I had, considering from a performance standpoint it's optimal already as far as retpolines are concerned. > (As an aside, patch 2 is not copying over the comments in the struct > kvm_x86_ops declarations. Granted there aren't many, but we should not > lose the few that exist). Yes sorry, this was actually unintentional and the comment need to be retained in the header declaration. Thanks, Andrea
Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
On Tue, Sep 24, 2019 at 02:15:39AM +0200, Paolo Bonzini wrote:
> On 23/09/19 22:23, Sean Christopherson wrote:
> >
> > +int nested_vmx_handle_vmx_instruction(struct kvm_vcpu *vcpu)
> > +{
> > + switch (to_vmx(vcpu)->exit_reason) {
> > + case EXIT_REASON_VMCLEAR:
> > + return handle_vmclear(vcpu);
> > + case EXIT_REASON_VMLAUNCH:
> > + return handle_vmlaunch(vcpu);
> > + case EXIT_REASON_VMPTRLD:
> > + return handle_vmptrld(vcpu);
> > + case EXIT_REASON_VMPTRST:
> > + return handle_vmptrst(vcpu);
> > + case EXIT_REASON_VMREAD:
> > + return handle_vmread(vcpu);
> > + case EXIT_REASON_VMRESUME:
> > + return handle_vmresume(vcpu);
> > + case EXIT_REASON_VMWRITE:
> > + return handle_vmwrite(vcpu);
> > + case EXIT_REASON_VMOFF:
> > + return handle_vmoff(vcpu);
> > + case EXIT_REASON_VMON:
> > + return handle_vmon(vcpu);
> > + case EXIT_REASON_INVEPT:
> > + return handle_invept(vcpu);
> > + case EXIT_REASON_INVVPID:
> > + return handle_invvpid(vcpu);
> > + case EXIT_REASON_VMFUNC:
> > + return handle_vmfunc(vcpu);
> > + }
> > +
>
> Do you really need that? Why couldn't the handle_* functions simply be
> exported from nested.c to vmx.c?
Nope, just personal preference to keep the nested code as isolated as
possible. We use a similar approach for vmx_{g,s}et_vmx_msr().
Though if we do want to go this route, it'd be better to simply move
handle_vmx_instruction() to nested.c instead of bouncing through that
and nested_vmx_handle_vmx_instruction().
Re: [GIT PULL] SafeSetID LSM changes for 5.4
On Mon, Sep 23, 2019 at 4:35 PM James Morris wrote: > > My understanding is that SafeSetID is shipping in ChromeOS -- this was > part of the rationale for merging it. Well, if even the developer didn't test it for two months, I don't think "it's in upstream" makes any sense or difference. Linus
